Anotace. Abstract. Keywords: Automatic testing, voice dialogue systems, automatic speech recognition, speech synthesis, digital character recognition.

Transkript

1 PROHLÁŠENÍ Předkládám tímto k posouzení a obhajobě bakalářskou práci práci zpracovanou na závěr studia na Fakultě aplikovaných věd Západočeské univerzity v Plzni. Prohlašuji, že jsem bakalářskou práci vypracoval samostatně a výhradně s použitím odborné literatury a pramenů, jejichž úplný seznam je její součástí Rád bych na tomto místě poděkoval především svému vedoucímu bakalářské práce panu Ing. Janu Švecovi, jehož rady a připomínky mě donutily dívat se na věci z různých úhlů. Významnou měrou tak přispěl ke zdárnému dokončení této práce.

2 Anotace Práce se zabývá možnostmi automatického testování multimediálních zařízení jakožto kybernetické úlohy verifikace modelu pomocí dialogu. Zvláštní zřetel je kladen na řečová rozhraní. Obecně popisuje nejběžnější postupy automatického rozpoznávání a syntézy řeči a formuluje způsob jejich začlenění do vyvíjeného nástroje automatického testování. Klíčová slova: Automatické testování, hlasové dialogové systémy, automatické rozpoznávání řeči, syntéza řeči, digitální rozpoznávání obrazu. Abstract Bachelor thesis deals with automatic testing of multimedia devices, especially as a cybernetic problem of a model verification with use of dialogue. At first, it focuses on speech interfaces. In general, it describes practice of an automatic speech recognition and speech synthesis and its usage in an automatic testing toolkit development. Keywords: Automatic testing, voice dialogue systems, automatic speech recognition, speech synthesis, digital character recognition.

3 Obsah 1 Úvod 1 2 Teorie Dialogové systémy Rozpoznávání řeči Syntéza řeči Testování Motivace Příklad zadání Způsob testování Automatické testování s pomocí rozpoznávání a syntézy řeči Automatické testování s pomocí rozpoznávání a syntézy řeči a rozpoznávání obrazu Analýza Programovací jazyk Syntéza řeči Rozpoznávání řeči Rozpoznávání obrazu Jednotný přístup k výsledkům Implementace Přístup k funkcím Funkce syntézy řeči Funkce rozpoznávání řeči Funkce rozpoznávání obrazu Třída Result jako jednotný přístup k výsledkům Záznam (logování) během testu I

4 5.7 Příklady Závěr 36 II

5 1 Úvod Obrovský rozvoj výpočetní techniky v několika posledních desetiletích nám umožnil řešit stále složitější a často i dříve jinak neřešitelné problémy. Denně, ať už vědomě či nikoliv, ke své práci ale i zábavě používáme různá zařízení - počítače nejrůznějších druhů a velikostí. Jejich ovládání (je-li vůbec potřeba) je stále snadnější a komfortnější. To ale zároveň znamená enormní nárůst složitosti a s ním také náchylnost k chybám. Důležitou roli jejich vývoje - snad více než kdy předtím - tedy hraje jejich testování. Začátkem Ledna roku 1999 vyslala NASA k Marsu družici Mars Polar Lander. Ta po jedenácti měsících skutečně k Marsu dorazila. Během přistávání však došlo k přerušení spojení a nepodařilo se ho již znovu obnovit. Závěry vyšetřování popisuje ve své knize jako motivační příklad [2]. Výsledkem byla katastrofa, ale její příčina byla mimořádně jednoduchá. Přistávací modul testovalo několik týmů. Jeden tým testoval mechanismus vysouvání nohy a jiný tým testoval přistávání od tohoto okamžiku dále. První tým se tedy nikdy nedíval, jestli se náhodou nenastavil bit odvozený od dotykového kontaktu - to přece nebyla jejich práce - a druhý tým zase před zahájením testů vždy resetoval počítač a bit tím vymazal. Obě části fungovaly samy o sobě bezvadně, ale už ne poté, co byly vzájemně spojeny. Při vývoji a s ním spojeným testováním nového produktu se často naším schopným pomocníkem stávají jednotkové testy (angl. unit tests) [3]. Díky nim můžeme snadno a rychle rozhodnout, jestli část na které zrovna pracujeme plní správně svoji úlohu - tedy jestli odpovídá specifikaci produktu [2]. Nic nám ale ze své podstaty neřeknou o tom, jak se bude chovat produkt jako celek. Tato informace však, jak dokazuje citace výše, může být stěžejní. Představme si například vývoj nového mobilního telefonu. Testování je náročné, nákladné a nepřináší snadno viditelné zisky. Mohli bychom snad vzít hotový přístroj, vhodným rozhraním ho připojit k počítači a ten pak za 1

6 nás nechat zkontrolovat správnou funkčnost? Můžeme potom říci, že je vše v pořádku, a s klidným svědomím pustit náš telefon na trh? Odpověď na tuto otázku není tak prostá, jak by se na první pohled mohlo zdát. Důležitou roli zde totiž bude hrát ekonomická stránka věci. Zcela zřejmě jsme při testování opomenuli fakt, že většina uživatelů bude k telefonu přistupovat přes jeho klávesnici či dotykovou obrazovku a mikrofon. Pokud jsme tedy udělali chybu ještě před místem, kde se oba signály z klávesnice a z počítače spojí a pokračují pak už stejně, zůstane neodhalena a narazí na ni až naši zákazníci. Na druhou stranu je ale dost dobře možné, že opravdu komplexní testování by bylo příliš pomalé či nákladné. Navíc ani takový postup nám zcela nezaručí, že k žádnému selhání nedojde. Můžeme pouze říci, že jsme chybu neobjevili, nikoliv, že tam není. I zde tedy, asi jako ve všem v životě, musí být naše rozhodnutí kompromisem. 2

7 2 Teorie 2.1 Dialogové systémy Mluvíme-li o plnohodnotné komunikaci člověka s člověkem pomocí řeči, nazýváme ji obvykle dialogem. Stejně tak ale můžeme použít výraz hlasový dialog pro komunikaci pomocí řeči člověka se strojem, či dokonce stroje se strojem [7]. Dialog započne tím, že jeden z účastníků předá zvolené sdělení druhému. Ten k němu zaujme určité stanovisko, formuluje své sdělení a to předá zpět. Poté opět následuje tah prvního účastníka. Představme si nyní, že cílem prvního účastníka ve vzešlé diskuzi je přesvědčit druhého o pravdivosti svého předchozího tvrzení, které diskuzi vyvolalo. Sleduje odpovědi svého partnera (oponenta), porovnává je s tím, co sám považuje za správné a pravdivé a volí své další zásahy do diskuze tak, aby dosáhl vytyčeného cíle. Dvojice popsaná v předcházejícím odstavci ne náhodou nápadně připomíná systém tvořený regulátorem a regulovaným procesem. I v klasické regulaci, pokud ji diskretizujeme na jednotlivé kroky, totiž provádíme tyto činnosti. Změříme hodnotu regulované veličiny, což odpovídá vyslechnutí odpovědi (či námitek) našeho partnera (oponenta), porovnáme její hodnotu s požadovanou a na základě toho (a naší strategie) volíme další řízení - vstup regulovaného systému tak, abychom regulovaný proces přivedli do požadovaného stavu. Tedy - volněji řečeno - přinutili zaujmout námi zvolené stanovisko. Taková úloha zcela jistě spadá do oblasti zájmu kybernetiky. Na obrázku 1 vidíme model hlasového dialogového systému. Informace od uživatele prochází přes akustický kanál 1 (nechtěné zkreslení) přes moduly rozpoznávání a porozumění řeči. Modul řízení dialogu následně na základě svého stavu a strategie řízení za spoluúčasti modelu úlohy zvolí vhodné řízení. Modul generování odpovědi sestaví textovou reprezentaci, která je modulem syntézy řeči převedena do řečové reprezentace a přes akustický kanál 2 předána zpět uživateli. 3

8 Obrázek 1: Model hlasového dialogového systému [7] Jedná se zjevně o komplexní kybernetický systém a návrh efektivního řízení dialogu bez znalosti ostatních modelů není možný. Pro návrh komponent můžeme použít v zásadě dva přístupy, a to znalostní přístup a statistický přístup [7]. Znalostní přístup je historicky starší avšak velmi populární. Využívá znalostí a zkušeností člověka - experta. Ten své znalosti vkládá do systému za pomoci určitých heuristických pravidel. V tomto přístupu přímo neuvažujeme model uživatele ani konkrétní cíl řízení dialogu. Jsou však implicitně obsaženy v použitých pravidlech. Statistický přístup oproti tomu využívá explicitní pravidla jen minimálně. Většina je odvozena z trénovacích dat. To zároveň implikuje největší slabinu tohoto přístupu. Pro trénování je obvykle potřeba velký objem dat, který z různých důvodů nemusí být k dispozici. Tato data je navíc potřeba anotovat - doplnit o tzv. informaci od učitele, aby systém věděl, jaká je správná reakce na daný vstup a mohl se tak z dat učit. Anotaci obvykle provádí proškolená osoba nebo skupina osob, což podstatně zvyšuje naše náklady. Pro řízení dialogu se obvykle používají dva přístupy, a to řízení dialogu s konečným počtem stavů a řízení dialogu založené na rámcových strukturách [7]. Obecně vzato je však možných přístupů více [1]. Řízení dialogu s konečným počtem stavů je velice oblíbeným přístupem, což vyústilo ve standardizaci programovacího jazyka VoiceXML [7, 8]. Tento 4

9 přístup se hodí téměř výlučně pouze pro implementaci systému s iniciativou hlasového agenta [7], tedy dialogů, jejichž vedení je zcela v kompetenci řízení dialogového systému a uživatel dostává pouze na výběr z daných možností. Model takového řízení dialogového systému v podstatě odpovídá modelu konečného automatu. Poznamenejme, že největší výhodou tohoto přístupu je jednoduchost návrhu a testování. Dialogový systém využívající strukturu rámců nabízí uživateli větší volnost a tím pádem činí jeho dialog se systémem příjemnější. Jeho realizace a testování je však oproti řízení dialogu s konečným počtem stavů mnohem náročnější. Klade také vysoké nároky na modul rozpoznávání a porozumění řeči [7]. Rámce si lze představit jako v informatice často používané objekty. Každý rámec (objekt) má předem definovány sloty (vlastnosti). Rámec také může obsahovat určitou procedurální znalost (metody) navázané na jednotlivé sloty nebo obecně změny stavu rámce. Pomocí této procedurální znalosti lze například komunikovat s modelem úlohy (viz obr. 1) a dále ovlivňovat obsah slotů [7]. Sloty se mohou nacházet ve čtyřech následujících stavech: nevyplněný, nepotvrzený, potvrzený, nekonzistentní [7]. Je-li rozpoznána promluva uživatele, systém se na jejím základě pokusí co nejvíce slotů vyplnit. Následně položí uživateli doplňující dotaz, ve kterém jsou již vyplněné sloty implicitně zahrnuty a na základě odpovědi uživatele přechází buďto do stavu potvrzený, nebo do stavu nekonzistentní. Po potvrzení a vyřešení nekonzistence všech slotů, které systém pro vyřešení požadavku považuje za povinné, lze formulovat konečnou odpověď. 5

10 Příklad: ˆ Systém: Dobrý den, dovolali jste se na automatický systém, poskytující informace o vlakových spojeních. Jak vám můžeme pomoci? ˆ Uživatel: Kdy jede nejbližší vlak do Prahy? ˆ Systém: V jaké stanici chcete nastoupit na na nejbližší vlak do stanice Praha hlavní nádraží? ˆ Uživatel: V Plzni. ˆ Systém: Nejbližší vlak ze stanice Plzeň hlavní nádraží do stanice Praha hlavní nádraží jede dnes v 16: Rozpoznávání řeči Rozpoznávání řeči je velmi složitou úlohou umělé inteligence. Promluva je po cestě od řečníka k modulu rozpoznávání řeči mnohokrát zkreslena. Způsobuje to vliv prostředí, kterým se zvuk šíří, stejně jako vlastnosti mikrofonu nebo analogově-digitálního převodníku, použitého pro reprezentaci řeči v počítači. I když pomineme tyto faktory, stále zde zůstává veliký problém. Řeč každého člověka se totiž liší. Na základě toho můžeme v praxi systémy rozpoznávání řeči rozlišit na systémy na řečníku závislé a systémy na řečníku nezávislé. Pro účely dialogového systému, který má sloužit předem neznámému uživateli tedy přichází v úvahu pouze systémy na řečníku nezávislé [7, 1]. Složitost rozpoznávání souvislé řeči je enormní, obzvláště bereme-li v úvahu, že se bude jednat o řeč spontánní, ve které se často objevují různé neřečové události. Za neřečové události zde můžeme považovat například různé přeřeky, nedořeky nebo váhání. Proto se často při rozpoznávání řeči omezujeme na rozpoznáváním izolovaných slov popřípadě sousloví. Za nejjednodušší způsob rozpoznávání řeči můžeme považovat porovnávání se vzory. Takový modul má k dispozici sadu vzorů příslušejících po 6

11 skupinách nebo jednotlivě zvoleným třídám. Příchozí promluva se po úpravě (např. odstranění šumů) obvykle za pomoci klasifikace podle nejmenší vzdálenosti těmto třídám přiřazuje. Takový přístup lze jen stěží použít pro rozsáhlé slovníky, ovšem pro rozpoznávání několika málo promluv může být dostačující. Oproti tomu samozřejmě existuje přístup využívající statistických metod. Jednotlivé promluvy se pak modelují pomocí skrytých Markovových modelů [7, 1], přičemž výsledný model se získá jejich zřetězením. Právě díky možnosti řetězení lze na rozdíl od metody porovnávání se vzory rozpoznávat i promluvy, které nebyly ve trénovací množině obsaženy. Rozpoznávání řeči využívající statistických metod lze formulovat jako úlohu dekódování podle maximální aposteriorní pravděpodobnosti [1, 7]. Jeli W posloupnost slov a O posloupnost vektorů příznaků odvozených z řečové reprezentace promluvy, pak je cílem posloupnost slov ˆW, která maximalizuje podmíněnou pravděpodobnost P (W O). Pomocí Bayesova pravidla a na základě faktu, že pravděpodobnost P (O) není funkcí W můžeme psát ˆW = arg max W P (W O) = arg max P (W )P (O W ). W Z rovnice vyplývá, že problém stanovení nejlepší posloupnosti slov ˆW lze řešit pomocí dvou oddělených pravděpodobností P (O W ) a P (W ), které lze modelovat a trénovat nezávisle na sobě [1, 7]. Pravděpodobnost P (O W ) nazveme akustickým modelem a P (W ) jazykovým modelem. Parametry akustického modelu se odhadují v procesu trénování využívajícím nejčastěji metodu odhadu parametrů podle maximální věrohodnosti. Parametry jazykového modelu lze určit jak znalostním přístupem, tak i statistickým přístupem na základě trénovacích dat [7]. V případě znalostního přístupu lze použít například bezkontextové gramatiky. 7

12 2.3 Syntéza řeči Obrázek 2: Ukázka segmentace řečového signálu [1] Úlohou počítačové syntézy řeči je převod textu (eventuálně textu obohaceného o prozodické informace) na odpovídající řečovou reprezentaci. Přístupy k syntéze řeči se nejčastěji dělí podle způsobu modelování použitého při vytváření výsledné řeči na tři typy: artikulační, formantovou a konkatenační syntézu [1, 7]. V případě artikulační syntézy se snažíme vytvořit přímo fyzikální model produkce řeči odpovídající způsobu, jakým řeč vytváří člověk. Formantová syntéza je založena na teorii zdroje a filtru. Těšila se oblibě především v minulosti, kdy se lidé snažili uměle tvořit řeč za pomoci mechanických, nebo elektrických zařízení. V současné době je však nejpoužívanější metodou konkatenační syntéza (konkatenace = zřetězení, spojování) [7, 1]. Během syntézy jsou z předem vytvořeného inventáře řečových jednotek [1] jednotlivé prvky vybírány a zřetězeny tak, aby utvořily žádanou promluvu. Realizace řečových jednotek jsou ovšem v inventáři uloženy s různou prozódií. Proto se sestavený řetězec ještě dále upravuje, abychom dosáhli větší plynulosti a přirozenosti řeči. Nejmenší nároky na konečnou úpravu (vyhlazení) řetězců by samozřejmě kladlo řetězení celých slov. Tento přístup lze ovšem použít pouze v případě, že máme v úmyslu syntetizovat nepříliš rozsáhlou skupinu slov, které budeme předem znát. Takovou úlohu nazýváme syntéza s omezeným slovníkem [1]. Zahrnout do inventáře veškerá možná slova, která bude chtít uživatel eventu- 8

13 álně syntetizovat je vzhledem k jejich množství prakticky nemožné. Prohledávání tak rozsáhlé databáze by navíc bylo výpočetně velmi náročné. Přirozeně se tedy snažíme v případě syntézy s neomezeným slovníkem používat menší subslovní jednotky (viz obr. 2) [1]. Použití slabik by se mohlo zdát přirozenou volbou potom, co jsme zamítli použití celých slov. Jedná se o přirozené řečové jednotky. Dělení slov na slabiky je ale provázeno určitou nejednoznačností, neboť některá slova lze slabikovat více způsoby. Navíc se ještě stále jedná o poměrně dlouhé jednotky, jejichž počet ve většině jazyků přesahuje [1]. Nejmenší přirozené jednotky řeči se nazývají fonémy. Jsou to jednotky které při tvorbě řeči reálně vyslovujeme (slovo oběd vyslovujeme jako objet ). Mohlo by se zdát, že takové dělení je pro naše potřeby optimální. S jejich pomocí lze sestavit jakékoliv slovo daného jazyka a jejich počet je relativně nízký. V češtině používáme 40 fonémů, popř. 49 hlásek a tento počet by tedy stačil pro syntetizaci jakéhokoliv slova [1]. Ukazuje se však, že v závislosti na kontextu existuje velké množství realizací těchto jednotek a řeč z nich skládaná bez zřetele na kontext by byla nesrozumitelná. Namísto nich se proto používají jednotky srovnatelné velikosti, ovšem kontextově závislé. Mezi ty patří např. difony. Vraťme se nyní k obrázku 2. Oproti přirozenému dělení slova na fonémy nyní použijeme poněkud jiný postup. Místa, kde jsme dělení provedli v případě fonému přibližně o polovinu posuneme a získáme tak zcela jiné jednotky, které však bude možné stejně jako fonémy řetězit a získávat tak celá slova. Slovo vánoce rozdělíme na [#-v v-á á-n n-o o-c c-e e-#]. Každá jednotka (krom první a poslední) nyní obsahuje přibližně polovinu předcházejícího fonému, místo, kde se fonémy spojují a opět přibližně polovinu fonému následujícího. Rozdíl je zásadní. Tímto posunem jsme totiž dělení provedli v oblasti spektrálně relativně stabilního signálu. Přechody mezi hláskami tedy zachováváme a částečně tak postihujeme koartikulační jevy [1]. Skládá-li se fonetická abeceda z N hlásek, existuje teoreticky N 2 difonů. 9

14 Velké množství takových spojení se navíc v praxi nevyskytuje a pro češtinu tak obdržíme přibližně jednotek. Inventář řečových jednotek takového rozsahu je realizovatelný a řetězením difonů lze oproti řetězení fonémů tvořit poměrně srozumitelnou řeč [1]. Postupem času se však ukázalo, že mnoho koartikulačních jevů postihuje spíše celou hlásku (obzvláště v případě samohlásek). Pro další zkvalitnění syntetizované řeči se difonové inventáře začali doplňovat dalšími jednotkami (např. trifony, demislabikami nebo i celými slabikami). Nazýváme je proto rozšířené difonové inventáře [1]. 2.4 Testování Testování produktů již během jejich vývoje a samozřejmě i před uvedením na trh hraje v současné době důležitou roli, což neplatí pouze pro software. Mnohé z velkých softwarových společností jsou myšlence kvality natolik oddány, že na každého programátora mají zaměstnaného jednoho nebo i více testerů [2]. V souvislosti s tím v sobě samotné testování zahrnuje nepřeberné množství technik a přístupů, ať bereme v úvahu proces testování jako takový či následné vyhodnocení testů. S tím souvisí také celá řada publikací, které se problémem testování zabývají. Některé z těchto metod (především ty, které jsou v práci zmíněny) si zde přesto trochu přiblížíme. Ukazuje se, že nejvíce chyb vzniká kvůli chybné nebo nedostatečné specifikaci produktu [2]. Z toho vyplývá jak důležité je plánování vývoje. Vývojáři nemusí pochopit specifikaci (zadání) správně - nebo hůře - každý z nich ji pochopí trochu jinak. Druhým nejčastějším zdrojem chyb je návrh (tedy konkrétní návrh realizace) a to ze stejného důvodu, jako v případě specifikace [2]. Uspěchaný nebo nedostatečně prodiskutovaný návrh vývoj zpomaluje a v horším případě i zanáší do systémů zbytečné a často těžko odhalitelné chyby. V terminologii testování se často setkáme s pojmy testování černé a bílé skříňky [2]. Rozdíl je na snadě. Při testování černé skříňky máme k dispo- 10

15 zici pouze znalost vstupu a výstupu a o vnitřních pochodech zařízení (jeho stavu) nevíme nic. Oproti tomu při testování bílé skříňky (někdy též testování průhledné skříňky [2]) máme možnost nahlédnout dovnitř, což nám může pomoci odhalit rizikové oblasti, kde by mohlo docházet k chybám. Tento přístup však přináší i jisté riziko. Na základě znalosti vnitřních pochodů se totiž může stát, že jim naše testy až přespříliš přizpůsobíme a produkt nebude otestován opravdu objektivně [2]. Testování můžeme také dělit podle našeho přístupu na testy splněním a testy selháním [2]. Analogií testů splněním v případě hlasových dialogových systémů může být testování s použitím validních vstupů bez postranních šumů a s dobrou výslovností. Testy selháním si naopak můžeme představit jako použití vstupů, o kterých víme, že je systém nezná, popřípadě použijeme vstupy systému známé, ale záměrně je poškodíme různými hluky a šumy. Rozdílem tedy je, jestli testujeme chování zařízení v ideálních nebo běžných podmínkách, nebo se snažíme dostat až na hranici únosnosti. Dalším dělením v přístupu k testování mohou být invazivní a neinvazivní testy [2]. V případě invazivních testů běží obvykle test na stejném zařízení jako testovaná aplikace. Typickým příkladem jsou jednotkové testy. To ale často není možné, obzvláště testujeme-li celé multimediální zařízení, popřípadě nějakou vzdálenou hlasovou aplikaci. Takový případ, kdy je náš test spuštěn na vlastním hardwaru a k testovanému objektu je připojen pomocí vhodného rozhraní nazýváme neinvazivní testy. Testování a následné vyhodnocení testů hlasových dialogových systémů by vzhledem ke svému rozsahu mohlo být zvláštní kapitolou. Uveďme však jen několik málo pojmů. Prvním krokem v testování hlasového dialogového systému nejspíše bude testování jeho modulu rozpoznávání řeči. Nejjednodušším avšak užitečným testem je testování přesnosti rozpoznávání izolovaných slov [7]. V tomto případě aplikujeme na modul určitou množinu slov, které by měl správně rozpoznat a přesnost Acc W získáme jako poměr slov správně rozpoznaných vůči 11

16 kardinalitě celé množiny, kde Acc W < 0; 1 >. Obdobně můžeme definovat větnou přesnost Acc S [7]. Stejným způsobem můžeme testovat modul porozumění řeči v úloze přesnosti porozumění přirozenému jazyku, kdy od modulu očekáváme přiřazení sémantických konceptů C daným slovům W. Následně samozřejmě můžeme testovat moduly rozpoznávání a porozumění řeči jako modul jeden. V tom případě sledujeme, zda modul přiřazuje správné sémantické koncepty C daným akustickým signálům (příznakům akustického signálu) O [7]. Po otestování jednotlivých modulů logicky následuje testování dialogového systému jako celku. Jak jsme již naznačili v kapitole 2.1 je testování dialogů s konečným počtem stavů poměrně snadné. Vzhledem ke konečnému počtu stavů lze totiž navrhnout test, který dialogový systém přiměje též v konečném čase všemi stavy projít. Oproti tomu testování dialogového systému s řízením založeným na rámcových strukturách již nemusí být triviální. Vzhledem ke konceptu řešení úlohy bude pravděpodobně vhodným postupem simulace reálného uživatele. Nelze však již zaručit, že dojde k otestování systému ve všech jeho možných stavech. 12

17 3 Motivace Mluvíme-li o testování multimediálního zařízení (popř. hlasové aplikace), nemáme tím na mysli nic jiného, než ověření, že jeho chování odpovídá specifikaci. V podstatě se tedy jedná o úlohu, ve které na základě specifikace produktu sestavíme model chování zařízení a s pomocí vhodného dialogového systému provedeme ověření jeho platnosti. Snažíme-li se o automatizaci takového procesu, jde tedy (jak jsme ukázali již v kapitole 2.1) o úlohu spadající především do oblasti kybernetiky. 3.1 Příklad zadání Představme si nyní situaci, kdy dostaneme za úkol otestovat určitou telefonní aplikaci. Řekněme, že se jedná o systém, který má po telefonu zpřístupnit odjezdy a příjezdy vlaků. Vezmeme si tedy k ruce jeho specifikaci, abychom věděli, jaké chování máme považovat za správné, a jízdní řády, se kterými budeme odpovědi systému též konfrontovat. Pak už nám zbývá jen vzít telefon, vytočit číslo, na kterém je aplikace k dispozici, a začít klást všemožné všetečné otázky. Začneme testy splněním [2], a proto vždy po několika dotazech zavěsíme a zavoláme znovu, abychom co nejlépe simulovali reálný provoz. Navíc by pro opravdu komplexní otestování bylo dobré, abychom si vždy někam poznamenali náš dotaz a jak na něj aplikace odpověděla, nebo přinejmenším zda odpověděla správně. Jak vidíme, už teď začíná být takovéto manuální testování poměrně náročné. Je také velmi pravděpodobné, že by naše aplikace měla zvládnout obsloužit v jednu chvíli více než jednoho volajícího. Museli bychom tedy najmout odpovídající počet lidí, abychom mohli takové zatížení testovat. To vše by samozřejmě bylo velice náročné a nákladné. Zcela přirozeně tak přichází na scénu myšlenka automatického testování [2, 3]. Obrátíme teď poněkud náš předchozí postup a začneme testem selháním [2], protože se jeho automatizace jeví jako nejjednodušší. Prvním krokem by tedy mohlo být sestavení našich požadavků jako nahrávek zvuku. S pomocí 13

18 vhodně zvoleného softwaru bychom pak s aplikací navázali potřebný počet spojení, použili nahrávky a ověřili, že aplikace takovou zátěž zvládne. Takový test se obvykle nazývá test s opakováním [2]. Tím, že použijeme větší počet uživatelů zároveň provádíme i zátěžový test [2]. Stále však před námi leží nelehký úkol. Každou sekvenci povelů, kterou budeme chtít otestovat, bude třeba předem nahrát. Pro opravdové zatížení aplikace by bylo lépe používat směs různých požadavků, což už nejspíše bude pouze za pomoci nahrávek náročné. Zde nám pomůže syntéza řeči (TTS - Text To Speech) [1]. Ze specifikace produktu víme, jaké povely dokáže aplikace zpracovat. Připravíme tedy generátor jejich textové reprezentace, provedeme syntézu do řeči a necháme naše uživatele, aby je aplikaci předkládali. Ta tedy bude zatěžována různorodou směsí povelů od celé řady uživatelů, což už můžeme považovat za dobrý zátěžový test. Ověření stability a případné nalezení chyby by tedy při vhodném záznamu testů neměl být problém. Stále však nevíme, zda aplikace na naše povely odpovídá správně. Bude tedy potřeba začlenit do našich testů technologii, která je nejspíše i srdcem testované aplikace. Automatické rozpoznávání řeči (ASR - Automatic Speech Recognition) [1]. Zcela správnou námitkou by na tomto místě mohlo být, že ASR použité k testování by muselo být výrazně kvalitnější, než to v testované aplikaci. To by pro nás jistě bylo ideálním řešením. Na druhou stranu ale není možné se na to spoléhat. V náš prospěch však hrají dva důležité fakty. Prvním z nich je, že výpočetní výkon hardwaru, na kterém aplikace běží je omezený. Aby bylo možné aplikaci reálně používat, musí být schopna reagovat na povely s určitým maximálním zpožděním. Uživatel by jistě nebyl příliš nadšený, pokud by na každou odpověď musel čekat např. minutu [7]. My na druhou stranu nejsme takto přímo omezeni. Druhým a možná ještě důležitějším faktem je rozdíl ve velikosti prohledávaných prostorů [1]. Aplikace dopředu neví jistě, na co se jí chceme zeptat, a musí proto zkontrolovat celou množinu přípustných řešení, než bude schopna náš dotaz určit. Náš testovací uživatel ovšem ví přesně, na co ze- 14

19 Obrázek 3: Schéma komunikace - Tester v1 ptal a ví také díky specifikaci produktu (modelu testované aplikace), jak má vypadat správná odpověď. Množina přípustných řešení, kterou musí prohledat, bude jistě mnohem méně rozsáhlá a on tak může ve stejném čase provést výrazně přesnější porovnání. I při použití ASR srovnatelných úrovní by tedy měl náš test vykazovat lepší výsledky. 3.2 Způsob testování Automatické testování s pomocí rozpoznávání a syntézy řeči Co do rozsahu a složitosti použitých technologií jsme v tomto místě dospěli do úrovně reálné aplikace, kterou jsme již dříve sestavili a použili pro testování multimediálního zařízení. Testy probíhali za pomoci ASR a TTS. Aplikaci jsme pro naše interní účely nazvali Tester v1. Testované zařízení samozřejmě neumožňovalo, abychom testy spustili přímo na něm. Byl proto použit neinvazivní přístup (viz kapitola 2.4). Pro syntézu řeči byla použita technologie SpeechTech TTS [4] verze 2.6. Tato verze oproti verzím 2.9 a 2.10 nedosahuje takové kvality syntetizované řeči. Je však rychlejší a klade menší nároky na hardware a co do kvality se ukázala dostačující. Pro rozpoznávání řeči byla použita technologie SpeechTech ASR [4]. Používané hlasové povely nebyly nijak složité, a proto jsme se spokojili s rozpoznáváním klíčových slov (KWS - angl. KeyWord Spotting). Struktura testů 15

20 Obrázek 4: Diagram testování v aplikaci Tester v1 je na obr. 4, schéma komunikace s testovaným zařízením na obr Automatické testování s pomocí rozpoznávání a syntézy řeči a rozpoznávání obrazu Probrali jsme již, jaké jsou možnosti automatického testování ryze řečových aplikací. Multimediální zařízení ovšem obvykle dává uživateli na výběr jak komunikaci akustickou, tak i vizuální. Použitím rozpoznávání obrazu je tedy možné výrazně zvýšit kvalitu (přesnost) testování. Proto jsme se jej rozhodli 16

21 Obrázek 5: Schéma komunikace - Tester v2 začlenit do vyvíjené aplikace a uvažované schéma komunikace se tak oproti Testeru v1 rozšířilo (viz obr. 5). Pro rozpoznávání obrazu se obecně vžilo označení OCR (angl. Optical Character Recognition - optické rozpoznávání znaků). Poznamenejme ovšem, že toto označení není v našem případě přesné. OCR v sobě už z logiky svého názvu ukrývá technologii převodu obrazu do digitální podoby. Tento převod aplikace přímo neřeší a namísto toho předpokládá, že se stejně jako v případě akustického kanálu 2 o digitalizaci přijímané informace postará nějaké externí zařízení (na obr. 5 ukryté ve vizuálním kanálu) a my již dále budeme zpracovávat pouze tuto digitální reprezentaci. Méně rozšířené, avšak mnohem přesnější by tedy v našem případě bylo označením DCR jako Digital Character Recognition - Digitální rozpoznávání znaků. 17

22 4 Analýza Shrňme nyní, co je vlastně naším úkolem. Máme-li testovat nějaké blíže nespecifikované multimediální zařízení, je třeba vhodným způsobem sestavit jeho model. K němu následně vytvoříme odpovídající tester - regulátor a s jeho pomocí ověříme platnost tohoto modelu. Ocitáme se teď ovšem ve slepé uličce, protože o modelech zařízení, které budeme chtít v budoucnu testovat nemáme téměř žádnou informaci. V podstatě jediným platným předpokladem, ze kterého můžeme vycházet je, že se bude jednat o multimediální zařízení (resp. hlasovou aplikaci) schopné komunikovat podle schéma na obr. 5 (resp. obr. 3). Jedinou naší možností je tedy navrhnout a sestavit vhodné metody - formalismy, s jejichž pomocí bude možné po obeznámení s modelem testovaného zařízení aplikaci vhodně doplnit (konkretizovat) a sestavit tak dialogový systém schopný provést automaticky ověření platnosti daného modelu. Vznikne tak komplexní systém, jehož schéma vidíme na obr

23 Obrázek 6: Schéma Tester v2 - testované zařízeni 19

24 Obrázek 7: Struktura modulů v aplikaci Tester v2 4.1 Programovací jazyk Python je moderní programovací jazyk vyšší úrovně. Snadný na pochopení a příjemný na užívání. Jak se můžeme dočíst v [6], ukazuje se navíc jako ideální jazyk pro výuku základů programování. V kombinaci s našimi vlastními zkušenostmi s ním se tedy jevil jako ideální kandidát a byl také použit jako nejvyšší jazyk implementace. Právě v něm jsou napsány ukázkové testy využívající vytvořenou knihovnu funkcí, kterou budeme pro naše účely nazývat Tester v2. Kód je psán primárně pro Python v2.5, ale je možné použít i další vyšší verze řady Syntéza řeči V Testeru v2 je použita syntéza řeči SpeechTech TTS [4] verze 2.6, stejně jako v Testeru v1. Jak již bylo zmíněno dříve, tato verze je oproti novějším implementacím rychlejší, ovšem méně kvalitní. Pro naše účely se však nejedná o nijak závažnou vadu, a proto jsme se rozhodli u této verze zůstat. Funkce DLL knihovny TTS jsou do Pythonu namapovány za pomoci modulu ctypes. Následně je ještě použit obalový modul ttsframework. Tato struktura nám umožňuje zachovat přehlednost programu, kdy modul tts 20

25 Algoritmus 1 Příklad použití modulu ttsframework from ttsframework import TTSFramework tts_framework = TTSFramework () tts_framework. speak ( " asynchronní promluva" ) tts_framework. speakandwait ( " synchronní promluva" ) (v obr. 7 vlevo dole značen tts (dll) ) zůstává v podstatě pouze přístupovou vrstvou k DLL knihovně a další potřebné úpravy jsou provedeny až v ttsframework (viz obr. 7). Ve výpisu zdrojového kódu označeném jako algoritmus 1 vidíme reálné použití modulu ttsframework, respektive jeho jediné třídy TTSFramework. Bezprostředně po inicializaci jsou použity obě metody označené jako veřejné (public). Jak napovídá samotný příklad, metoda speak provádí asynchronní syntézu řeči. Provede syntézu předaného textu a spustí její přehrávání. Pak okamžitě předá řízení programu zpět, lhostejno, zdali již došlo k vyslovení celé promluvy, nebo přehrávání ještě probíhá. Je zřejmé, že tuto metodu využijeme pouze v případě, že chceme testovanému zařízení něco oznámit, ale nezajímá nás jeho reakce. Ve většině případu během testování používáme metodu speakandwait, která předává řízení zpět až ve chvíli, kdy je celá promluva vyslovena a mnohem lépe se tak hodí pro vedení dialogu, jímž v podstatě tento způsob testování také je. 4.3 Rozpoznávání řeči Rozpoznávání řeči je v Tester v2 řešeno pomocí SpeechTech ASR [4], rozpoznávajícím fráze popsané jak pomocí KWS (KeyWord Spotting - rozpoznávání klíčových slov), tak i pomocí ESGF gramatik [9] (dále značeno GRM). Můžeme tedy rozpoznávat jak jednotlivá klíčová slova, tak i složité fráze popsané gramatikami. Po zpřístupnění DLL knihovny ASR modulem pyasr4ivr dochází (jako v případě TTS) k obalení dalším modulem. 21

26 Tentokrát asrframework (viz obr. 7). 4.4 Rozpoznávání obrazu Jak jsme již dříve poznamenali, je při testování multimediálních zařízení rozpoznávání obrazu vhodným doplňkem, který může testy značně zkvalitnit. Náš modul rozpoznávání obrazu (DCR) předpokládá obraz ve formě digitálního obrázku (např. PNG) i informace o rozložení textu. Dále dochází k odstranění pozadí a rozřezání obrazovky na jednotlivé oblasti, kde se podle předané informace mají nacházet slova, která chceme rozpoznat. Slova se pak dále dělí na jednotlivé znaky, které se na základě znalosti používaných fontů porovnávají se vzory. Rozpoznávání tak probíhá klasifikací podle nejmenší vzdálenosti (viz kapitola 2.2, kde jsme tuto metodu krátce popsali pro případ rozpoznávání řeči). 4.5 Jednotný přístup k výsledkům Poslední součástí druhé úrovně (v obr. 7 druhý řádek) je modul result (resp. třída Result). Při použití modulů asrframework a ocrframework přímo by uživatel obdržel výsledky rozpoznávání vždy v příslušné třídě (instanci). V případě asrframework dokonce na dvou různých místech i v rámci této třídy, protože výsledky rozpoznávání podle KWS a GRM přicházejí odděleně. Řešení přináší právě třída Result. V každém testu je zpřístupněna instance třídy Result (značena jako result), do které jsou všechny obdržené výsledky automaticky přeposílány. Uživatel tak nemusí procházet jednotlivé instance. Má jednoduchý a především jednotný přístup ke všem výsledkům. Algoritmus 2 je příkladem typického použití instance result v testu. Nejprve se ptáme, zdali bylo rozpoznáno klíčové slovo praha. V dalším řádku se zase dotazujeme, zdali byla v promluvě rozpoznána fráze odbočte doprava popsaná gramatikou (GRM). Strukturu dat v instanci result za předpokladu, 22

27 Algoritmus 2 Příklad použití instance result v testech i f "praha" in r e s u l t. source (KWS) : print " Slovo praha bylo rozpoznáno. " i f "odbočte doprava" in r e s u l t. source (GRM) : print "Rozpoznána direktiva odbočte doprava. " source item_id phrase confidence KWS 1 praha 0.7 GRM 2 odbočte doprava 1 Obrázek 8: Obsah instance result že obě dotazované fráze byly rozpoznány ukazuje tabulka na obr

28 5 Implementace 5.1 Přístup k funkcím Podívejme se nyní, jak vypadá použití aplikace Tester v2 v praxi. Jak již bylo dříve řečeno, aplikace je určena primárně pro jazyk Python 2.5 a v tomto jazyku předpokládá i test předaný k provedení. Stejně dobře však lze použít i libovolnou vyšší verzi jazyka řady 2 (např. Python 2.6 nebo Python 2.7). Hotový test test.py je možné spustit příkazem: $python exec_test.py test.py Díky tomu, že je test spouštěn přes jiný program (exec_test.py), může být uživateli přístup k funkcím knihovny maximálně zjednodušen. Není dokonce ani potřeba provádět pro Python typický import. Veškeré funkce jsou k dispozici přímo, tak jako jiné vestavěné (built-in) funkce (např. print()). Projděme si teď jednotlivé funkce, které má uživatel k dispozici a povězme si něco o jejich použití. 5.2 Funkce syntézy řeči Z instance třídy TTSFramework (z modulu ttsframework) jsou jako funkce zpřístupněny metody: ˆ speak jako speak ˆ speakandwait jako speakandwait Obě metody předpokládají předání jednoho argumentu a to libovolného řetězce typu unicode. Typ unicode zaručuje správné zpracování české diakritiky. Funkce speak provádí asynchronní přehrávání. Syntetizovaná promluva je tedy předána k přehrávání a bez čekání je řízení předáno zpět programu. Naopak funkce speakandwait pracuje synchronně, tedy před předáním řízení zpět počká na konec přehrávání. Příklad použití ukazuje algoritmus 3. 24

29 Algoritmus 3 Příklad použití funkcí syntézy řeči speak ( "Tato věta bude přehrána asynchronně. " ) speakandwait ( "Tato věta bude přehrána synchronně. " ) Je na něm též (oproti algoritmu 1) vidět rozdílný přístup k funkcím zmíněný v kapitole 5.1. V tomto příkladu je nejprve volána funkce speak. K přehrání obou vět tedy (v závislosti na výpočetním výkonu hardwaru) dojde téměř v tu samou chvíli. 5.3 Funkce rozpoznávání řeči Z instance třídy ASRFramework (z modulu asrframework) jsou jako funkce zpřístupněny metody: ˆ register jako register ˆ start jako startasr ˆ stop jako stopasr ˆ waitforresponse jako waitforasrresponse Dále jsou zpřístupněny konstanty: ˆ KWS ˆ GRM První funkce má deklaraci register(source, value, permanent=false). S její pomocí říkáme instanci třídy ASRFramework jaké fráze chceme rozpoznávat. Můžeme registrovat klíčová slova (KWS), nebo gramatiky (GRM) a to trvale, nebo s platností pouze pro první následující blok rozpoznávání. První argument funkce (source) udává typ fráze, kterou chceme rozpoznávat. Uvedeme-li na jeho místě konstantu KWS, dáváme tím najevo, že 25

30 Algoritmus 4 Příklad použití funkce register r e g i s t e r (KWS, u"praha" ) r e g i s t e r (GRM, u"seznam_prikazu. esgf " ) chceme registrovat klíčové slovo a funkce tedy bude očekávat na místě druhého argumentu value řetězec typu unicode. Naopak použijeme-li konstantu GRM, chceme registrovat soubor gramatiky a na místě argumentu value by se tedy měla objevit cesta k danému souboru. Jakékoliv rozpoznávání řeči vždy probíhá v bloku mezi příkazy startasr() a stopasr(). Třetí parametr permanent nám umožňuje definovat jak dlouho má námi registrovaná fráze platit. Pokud parametr vynecháme (což je možné, protože má nastavenou implicitní hodnotu False), nebo pokud explicitně zadáme jeho hodnotu jako False (popřípadě permanent=false), bude námi registrované fráze platit pouze v prvním následujícím bloku příkazů startasr() a stopasr(). To je užitečné především pro fráze platné pouze po jednu iteraci testu. Pokud naopak máme některé fráze, které budeme používat v každé iteraci testu, má smysl registrovat je s parametrem permanent=true. Ačkoliv je možné vynechat jméno parametru a předat pouze hodnotu True, vřele doporučujeme používat kvůli čitelnosti dříve uvedený způsob. Takto registrovaná fráze bude platná v každém následujícím bloku rozpoznávání řeči. V případě několika málo klíčových slov nebude nejspíše rozdíl patrný. V případě rozsáhlé gramatiky však jistě oceníme její zpracování pouze jednou v záhlaví testu a nikoliv v každé z tisíce následujících iterací. V algoritmech a 5 je použita instance result. K té se ještě vrátíme později. Pro tuto chvíli je důležité vědět pouze, že má přístup ke všem výsledkům rozpoznávání a její metoda source vrací seznam výsledků odpovídajících zadanému zdroji. Funkci waitforasrresponse taktéž probereme později. Ta, jednoduše řečeno, čeká na odpověď testovaného zařízení. Algoritmus 4 ukazuje typické použití funkce, algoritmus 5 vliv použití parametru permanent. 26

31 Algoritmus 5 Příklad použití parametru permanent funkce register r e g i s t e r (KWS, "praha" ) r e g i s t e r (KWS, " plzeň ", permanent=true ) startasr () waitforasrresponse () stopasr () i f "praha" in r e s u l t. source (KWS) : print " Klíčové slovo praha rozpoznáno. " i f " plzeň " in r e s u l t. source (KWS) : print " Klíčové slovo plzeň rozpoznáno. " startasr () waitforasrresponse () stopasr () i f "praha" in r e s u l t. source (KWS) : # Dotaz nemá smysl! print " Klíčové slovo praha rozpoznáno. " i f " plzeň " in r e s u l t. source (KWS) : print " Klíčové slovo plzeň rozpoznáno. " 27

32 Již jsme zmínili funkce startasr a stopasr. Jejich smysl odpovídá přesně jejich názvům. Nemají za úkol nic jiného než spustit (startasr) a následně ukončit (stopasr) rozpoznávání řeči. Je třeba pouze poznamenat, že funkce startasr vždy vymaže z instance result všechny dříve získané výsledky. Pokud je i přesto chceme používat, je třeba si pořídit před voláním startasr jejich kopii. Poslední funkcí poskytovanou třídou ASRFramework, o které jsme ještě nemluvili, je waitforasrresponse. Je deklarována jako waitforasrresponse(min_speech_duration=0.3, min_silence_duration=0.4, time_step=0.1) Její název opět odpovídá jejímu smyslu. Jakmile je zavolána, čeká, dokud nezaznamená promluvu. Fakticky čeká na sekvenci signálů ticho - zvuk - ticho. Všechny parametry mají nastaveny implicitní hodnoty a je možné ji volat jako waitforasrresponse(). Pro jemnější nastavení v případě potřeby jsou ovšem k dispozici parametry: ˆ min_speech_duration jako minimální délka zvuku, který bude považován za odpověď ˆ min_silence_duration jako minimální délka ticha, která bude považována za konec odpovědi ˆ time_step jako délka čekacího kroku Předpokládá se, že parametry min_speech_duration a min_silence_duration budou celočíselné násobky parametru time_step. Všechny hodnoty jsou uvedeny v sekundách. 5.4 Funkce rozpoznávání obrazu Třída OCRFramework (z modulu ocrframework) dává uživateli přístup ke dvěma stěžejním funkcím, a to: ˆ waitforscreenchange() 28

33 ˆ doocr() Funkce waitforscreenchange je obdobou funkce waitforasrresponse. Po svém zavolání tedy bude čekat, dokud nedojde k překreslení (změně) obrazovky - sleduje změny vizuálního kanálu (viz obr. 6). Funkce doocr následně sejme obrazovku, provede analýzu snímku a předá výsledky instanci result. Tato funkce však předpokládá přístup k zařízení označenému na obr. 7 jako grabber. Jde vlastně o již dříve zmiňované externí zařízení ukryté na obr. 5 a 6 ve vizuálním kanálu. Při volání je nutné specifikovat o kterou již dříve v konfiguračním souboru definovanou obrazovku (angl. screen - druh rozložení textu) jde. 5.5 Třída Result jako jednotný přístup k výsledkům Pro přístup k výsledkům rozpoznávání byla použita samostatná třída (resp. instance třídy) Result (resp. result). Kdekoliv v testu může uživatel přistupovat k instanci result, která obsahuje veškeré výsledky získané v bezprostředně předcházejícím bloku rozpoznávání. Veškeré výsledky jsou instanci result předávány automaticky bezprostředně po jejich získání. Její metody jsou: ˆ containsphrase(phrase) ˆ source(source) ˆ confidence(confidence) Metoda containsphrase(phrase) vrací hodnoty True, nebo False podle toho, zda je v instanci (eventuálně v použitém filtru) fráze k dispozici. Od ní je také odvozena konstrukce phrase in result. Metodu source jsme si již rámcově představili dříve. Pokud je zavolána, projde systematicky všechny možné výsledky a vrátí opět instanci třídy Result ovšem pouze s výsledky, které odpovídají zadanému zdroji. Volání 29

34 Algoritmus 6 Příklad použití instance result # Je mezi výsledky f r á z e "praha "? "praha" in r e s u l t # Nebo jinak : r e s u l t. containsphrase ( "praha" ) # Je mezi rozpoznanými klíčovými s l o v y "praha "? "praha" in r e s u l t. source (KWS) # Je mezi rozpoznanými klíčovými s l o v y s důvěryhodností # v ě t š í nebo rovnou 0.6 slovo "praha "? "praha" in r e s u l t. source (KWS). confidence ( 0. 6 ) result.source(grm) tedy vrátí instanci třídy Result, která bude obsahovat pouze rozpoznané gramatiky. Tato metoda je typickým příkladem výše zmíněného filtru. Metoda confidence(confidence) je opět filtrem. Každý výsledek rozpoznávání má přiřazenu určitou hodnotu důvěryhodnosti - confidence. Voláním tohoto filtru tedy obdržíme nazpět opět instanci třídy Result ovšem pouze s výsledky, které mají stejnou nebo vyšší hodnotu důvěryhodnosti, než zadaná confidence. 5.6 Záznam (logování) během testu Je velmi pravděpodobné, že uživatel bude chtít své testy nějak ladit, popřípadě během testu nechat vypisovat chybové nebo informační hlášky. Z toho důvodu jsou také jako funkce k dispozici metody instance třídy Logger a několik potřebných konstant z modulu logging: ˆ DEBUG ˆ INFO ˆ WARNING ˆ ERROR 30

35 ˆ CRITICAL ˆ setlogginglevel() ˆ debug() ˆ info() ˆ warning() ˆ error() ˆ critical() Konstanty jsou psány velkými písmeny a představují různé úrovně logování. Úroveň DEBUG je nejnižší a po nastavení příkazem setlogginglevel(debug) se budou vypisovat všechny hlášky. Oproti tomu je úroveň CRITICAL nejvyšší a je-li nastavena, budou vypisovány pouze hlášky této úrovně (tedy volání funkce critical(message)). Funkce setlogginglevel() tedy očekává jednu z dostupných konstant úrovně logování. Všechny ostatní funkce logování očekávají jako parametr řetězec typu unicode. 5.7 Příklady Na obr. 9 vidíme diagram, jak by mohla vypadat struktura jednoduchého testu s použitím funkcí TTS a ASR. Příklad vlastně odpovídá manuálnímu testování telefonní aplikace, zmíněnému v kapitole 3.1. Uveďme si teď příklad více konkrétní. Pro jednoduchost uvažujme zařízení bez obrazovky pouze se zvukovým vstupem a výstupem, jehož úkolem bude zopakovat slovo, které uslyší. Můžeme mu říkat např. ozvěna. Obě zařízení propojíme vhodným rozhraním (kanály). Potom již příkazem python exec_test.py test.py test spustíme a můžeme sledovat výsledky. Obsah souboru test.py zobrazuje algoritmus 7. 31

36 Obrázek 9: Příklad jednoduchého testu s použitím TTS a ASR 32

37 Algoritmus 7 Skript testu pro zařízení ozvěna. # filename : t e s t. py znama_slova = [ " karel ", " jarmila ", " franta ", "pepa" ] setlogginglevel (INFO) for slovo in znama_slova : r e g i s t e r (KWS, slovo ) startasr () speakandwait ( slovo ) waitforasrresponse () stopasr () i f slovo in r e s u l t : info ( " Slovo bylo rozpoznáno správně! " ) else : warning ( " Slovo %s nebylo rozpoznáno! " % slovo ) Podívejme se nyní na skript v algoritmu 7 podrobněji. Začíná definicí listu znama_slova. To jsou slova, která by mělo zařízení v pořádku rozeznat. V obr. 9 odpovídá list pojmu testovací data. Následuje nastavení hlášek na úroveň INFO (setlogginglevel(info)). Následně proběhne registrace právě testovaného slova a spustí se rozpoznávání. Předáme povel (slovo) testovanému zařízení, počkáme na odpověď, ukončíme rozpoznávání a provedeme záznam obdrženého výsledku. V tomto případě pouze vypíšeme, jestli bylo slovo rozeznáno správně, či nikoliv. Správné rozpoznání slova jistě očekáváme, a proto je použita funkce info. Oproti tomu selhání je stav, který by měl upoutat naši pozornost. V tomto případě je tedy použita funkce s vyšší úrovní (warning). Provedli jsme testy splněním. Nyní pro změnu provedeme na zařízení ozvěna několik testů selháním. Ze specifikace víme, že obdrží-li zařízení vstup, který nezná, mělo by namísto zopakování říci: Takové slovo neznám. Tato fráze už je poněkud složitější, a proto namísto odstranění mezer (stažení do jediného slova) a použití rozpo- 33

38 Algoritmus 8 Příklad ESGF gramatiky pro test zařízení ozvěna # filename : gramatika1. esgf #ESGF V1.0 grammar gramatika1 ; <begin> = <BEGIN_GRAMMAR>; <end> = <END_GRAMMAR>; public <gramatika1> = <begin> Takové slovo neznám <end>; znávání klíčových slov využijeme gramatiku. Příklad ESGF gramatiky s touto jedinou frází je v algoritmu 8. Skript testu potom najdeme v algoritmu 9. Test bychom spustili příkazem: python exec_test.py test_selhanim.py. Podívejme se na tento příklad opět podrobněji. Slova, která zařízení zná jsme nahradili slovy (jmény), které by podle specifikace znát nemělo (list neznama_slova) a mělo by zareagovat chybovou hláškou chybova_hlaska. Oproti předchozímu příkladu jsme ale nastavili úroveň logování na WARNING. Vzhledem k tomu, že normální (správné) chování je hlášeno funkcí info(), obdržíme během testu pouze hlášky o selhání. Funkce info() bude ignorována. Zásadním rozdílem oproti předcházejícímu příkladu je také umístění funkce register(). Tentokrát je totiž volána ještě před započetím testů. Není to ale nic překvapivého. Ve všech testech se přeci dotazujeme na existenci jediné a stále stejné fráze: Takové slovo neznám. Bylo by tedy zbytečné registrovat ji v každé iteraci testu. Mnohem lepším postupem je zaregistrovat ji hned na začátku s parametrem permanent=true. 34

39 Algoritmus 9 Test zařízení ozvěna - selháním # filename : test_selhanim. py znama_slova = [ " karel ", " jarmila ", " franta ", "pepa" ] neznama_slova = [ "máša", " jan ", " lenka ", "david" ] chybova_hlaska = "Takové s l o v o neznám" setlogginglevel (WARNING) r e g i s t e r (GRM, "gramatika1. esgf ", permanent=true ) for slovo in neznama_slova : startasr () speakandwait ( slovo ) waitforasrresponse () stopasr () i f chybova_hlaska in r e s u l t : info ( " Zarizeni zareagovalo spravne! " ) else : warning ( " Zarizeni zareagovalo chybne! " ) 35

40 6 Závěr V práci jsme se seznámili se základy počítačového rozpoznávání a syntézy řeči. Načrtli jsme též možnost jejich doplnění o rozpoznávání obrazu (znaků) a uvedli automatické testování s využitím dialogového systému jako prakticky jediný možný postup komplexního testování multimediálních zařízení a řečových aplikací. V kapitole 2.4 jsme uvedli několik možných přístupů k vyhodnocení výsledků testování modulů rozpoznávání a porozumění řeči. Testování multimediálních zařízení a řečových aplikací jsme následně uvedli jako kybernetickou úlohu ověření planosti modelu zařízení (aplikace). Úspěšně jsme analyzovali a sestavili systém umožňující uživateli psát jednoduchým způsobem automatické testy využívající funkcionalitu modulů rozpoznávání a syntézy řeči. Jinými slovy navrhovat vnitřní modely dialogových systémů, umožňující kromě testování jednotlivých modulů testovaného zařízení i ověření platnosti jeho uvažovaného modelu. Funkčnost systémů byla ověřena na několika jednoduchých modelových úlohách, z nichž některé jsme zmínili v kapitole 5.7. V těchto případech obvykle nahradil testované zařízení člověk, který se choval a odpovídal na dotazy systému podle předem daného scénáře - modelu testované úlohy. Systém byl též úspěšně použit v praktické úloze testování multimediálního zařízení s navigační jednotkou, které je určeno pro osobní automobil. 36