VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY FAKULTA INFORMAČNÍCH TECHNOLOGIÍ FACULTY OF INFORMATION TECHNOLOGY ÚSTAV POČÍTAČOVÝCH SYSTÉMŮ DEPARTMENT OF COMPUTER SYSTEMS TESTOVÁNÍ GUI POMOCÍ BITMAPOVÝCH VZORŮ A ROZPOZNÁVÁNÍ TEXTU V JAZYCE PYTHON TESTING GUI USING BITMAP PATTERNS AND TEXT RECOGNITION IN PYTHON BAKALÁŘSKÁ PRÁCE BACHELOR’S THESIS AUTOR PRÁCE MAREK ŠPIRKA AUTHOR VEDOUCÍ PRÁCE Ing. JOSEF STRNADEL, Ph.D. SUPERVISOR BRNO 2025   Ústav: Ústav počítačových systémů (UPSY)   Student: Špirka Marek   Program: Informační technologie     Kategorie: Analýza a testování softwaru   Akademický rok: 2024/25    Zadání:   1. Seznamte se s oblastmi grafických uživatelských rozhraní (GUI) a testování programového vybavení. 2. Seznamte se s problematikou testování GUI, přičemž se zaměřte na konkrétní třídu GUI, např. GUI pro desktopové aplikace, a na možnosti využít pro testování GUI bitmapové vzory a rozpoznávání textu. 3. Shrňte požadavky kladené na testování GUI pomocí bitmapových vzorů a rozpoznávání textu (TGBR), dle zaměření z bodu 2, a očekávané případy užití tohoto testování. Navrhněte řešení TGBR s požadavkem modulární a rozšiřitelné implementace v jazyce Python zahrnující uživatelské rozhraní pro nastavení, ovládání a sledování procesu testování a pro shrnutí výsledků testování. 4. Navržené řešení implementujte v jazyce Python a připravte data a podmínky pro jeho zhodnocení. 5. Zhodnoťte implementované řešení, zejména co se týká splnění požadavků v případech užití z bodu 3; identifikujte silné a slabé stránky implementace. 6. Diskutujte možné směry pokračování v řešení a rozveďte ty, které považujete za nejvíce perspektivní.   Literatura: • Alégroth, E., Feldt, R. On the Long-term Use of Visual GUI Testing in Industrial Practice: A Case Study. Empir Software Eng 22, 2017, pp. 2937–2971. DOI: 10.1007/s10664-016-9497-6. • Bauer, A., Coppola, R., Alégroth, E., Gorschek, T.: Code Review Guidelines for GUI-based Testing Artifacts. Information and Software Technology, Vol. 163, 2023, 23. p. DOI: 10.1016/j.infsof.2023.107299. Při obhajobě semestrální části projektu je požadováno: • Splnění bodů 1 až 3 zadání. Podrobné závazné pokyny pro vypracování práce viz https://www.fit.vut.cz/study/theses/   Vedoucí práce: Strnadel Josef, Ing., Ph.D.   Vedoucí ústavu: Sekanina Lukáš, prof. Ing., Ph.D.   Datum zadání: 1.11.2024   Termín pro odevzdání: 14.5.2025   Datum schválení: 31.10.2024 Zadání bakalářské práce 163039 Testování GUI pomocí bitmapových vzorů a rozpoznávání textu v jazyce PythonNázev: Fakulta informačních technologií, Vysoké učení technické v Brně / Božetěchova 1/2 / 612 66 / Brno Abstrakt Táto práca sa zaoberá testovaním grafických používateľských rozhraní pomocou bitmapo- vých vzorov a rozpoznávania textu v jazyku Python. Cieľom práce je navrhnúť a implemen- tovať modulárne a rozšíriteľné riešenie pre testovanie desktopových aplikácií, ktoré umožní automatizované overovanie vizuálnych prvkov a textového obsahu. Súčasťou je aj použí- vateľské rozhranie pre jednoduché nastavenie testovacích parametrov a sledovanie výsled- kov testov. Implementované riešenie je analyzované na základe reálnych prípadov použitia a zhodnotené z hľadiska jeho efektivity a možností ďalšieho rozšírenia. Abstract This thesis focuses on testing graphical user interfaces using bitmap patterns and text re- cognition in Python. The aim of the thesis is to design and implement a modular and extensible solution for testing desktop applications, enabling the automated verification of visual elements and textual content. The solution also includes a user interface for easy configuration of testing parameters and monitoring of test results. The implemented solu- tion is analyzed based on real-world use cases and evaluated in terms of its efficiency and potential for further extension. Kľúčové slová testovanie, grafické používateľské rozhrania, python, rozpoznávanie textu, bitmapové vzory, automatizácia testovania, desktopové aplikácie, overovanie vizuálnych prvkov, pixel, po- rovnávanie obrázkov, štrukturálna podobnosť, perceptuálna podobnosť, aliasy, zakázané oblasti, vizualizácia rozdielov, interaktívne rozhranie, porovnanie textového výstupu, tes- tovanie GUI, vizuálne regresné testovanie Keywords testing, graphical user interfaces, Python, text recognition, bitmap patterns, test automa- tion, desktop applications, visual element verification, pixel, image comparison, structural similarity, perceptual similarity, aliases, forbidden regions, difference visualization, interac- tive interface, text output comparison, GUI testing, visual regression testing Citácia ŠPIRKA, Marek. Testování GUI pomocí bitmapových vzorů a rozpoznávání textu v jazyce Python. Bakalářská práce. Vedoucí práce Ing. Josef Strnadel, Ph.D.. Brno: Vysoké učení technické v Brně, Fakulta informačních technologií, 2025. Testování GUI pomocí bitmapových vzorů a roz- poznávání textu v jazyce Python Prehlásenie Prehlasujem, že som túto bakalársku prácu vypracoval samostatne pod vedením pána Ing. Josefa Strnadela, Ph.D. Ďalšie odborné informácie a konzultácie mi poskytli Ing. Dominik Müller a Ing. Josef Bednařík, Ph.D. zo spoločnosti Bender Robotics s.r.o. Uviedol som všetky literárne pramene, publikácie a ďalšie zdroje z ktorých som čerpal. . . . . . . . . . . . . . . . . . . . . . . . Marek Špirka 8. mája 2025 Poďakovanie Rád by som poďakoval vedúcemu mojej bakalárskej práce pánovi Ing. Josefovi Strnadelovi, Ph.D. za odborné konzultácie, cenné rady a ochotu byť mi nápomocný počas celého pro- cesu písania práce. Zároveň ďakujem firme Bender Robotics s.r.o. za poskytnuté materiály a podporu, ktorá bola neoceniteľná pri realizácii tejto práce. Obsah 1 Úvod 7 2 Teoretický základ 8 2.1 Softvérové testovanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2 Grafické užívateľské rozhrania . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3 Testovanie grafických užívateľských rozhraní . . . . . . . . . . . . . . . . . . 10 2.4 Výzvy a problémy v GUI testovaní . . . . . . . . . . . . . . . . . . . . . . . 13 2.5 Definícia Bitmapových vzorov . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.6 Bitmapové vzory v testovaní grafických prvkov . . . . . . . . . . . . . . . . 14 2.7 Porovnávanie Bitmapových vzorov . . . . . . . . . . . . . . . . . . . . . . . 14 2.8 Optické rozpoznávanie znakov . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.9 OCR v automatizovanom testovaní . . . . . . . . . . . . . . . . . . . . . . . 17 2.10 Princíp fungovania OCR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.11 Praktické príklady a aplikácie . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3 Návrh softvérovej implementácie 21 3.1 Vstupný modul a spracovanie dát . . . . . . . . . . . . . . . . . . . . . . . . 21 3.2 Testovací modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.3 Výstupný modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4 Implementácia 26 4.1 Vstupné dáta a spustenie systému . . . . . . . . . . . . . . . . . . . . . . . . 26 4.2 Výber testovacích regiónov . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.3 Riadiaci modul testovacieho systému . . . . . . . . . . . . . . . . . . . . . . 31 4.4 Modul vizuálneho testovania . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.5 Modul OCR testovania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.6 Interaktívny výstup a zobrazenie výsledkov . . . . . . . . . . . . . . . . . . 40 5 Testovanie 44 5.1 Testovanie aplikácie ExpenseTracker . . . . . . . . . . . . . . . . . . . . . . 44 5.2 Testovanie aplikácie Halt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 5.3 Testovanie aplikácie TimeManager . . . . . . . . . . . . . . . . . . . . . . . . 48 5.4 Súhrn testovania a vyhodnotenie výkonu . . . . . . . . . . . . . . . . . . . . 50 5.5 Zistené obmedzenia a návrhy na zlepšenie . . . . . . . . . . . . . . . . . . . 52 6 Záver 53 Literatúra 55 1 A Výstup z EasyOCR 58 B Testovanie aplikácie ExpenseTracker 59 C Testovanie aplikácie Halt. 68 D Testovanie aplikácie TimeManager. 77 2 Zoznam obrázkov 2.1 Princíp regresívneho testovania po implementácii zmien v softvéri1. . . . . . 9 2.2 Príklad vývoja grafického užívateľského rozhrania: porovnanie vzhľadu pr- vých desktopových prostredí (Macintosh 1984) so súčasnými systémami (napr. Windows 11) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.3 Príklad konečného automatu (FSM), ktorý reprezentuje stavové prechody v jednoduchej GUI aplikácii galérie. Každý stav zodpovedá konkrétnej obra- zovke a prechody sú vyvolané používateľskými akciami2. . . . . . . . . . . . 12 2.4 Zobrazenie princípu bitmapovej reprezentácie obrázka: vizuálny obraz (vľavo) je prevedený do binárnej matice (vpravo), kde 1 označuje čierny pixel a 0 biely pixel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.5 Príklad porovnania bitmapových obrázkov na úrovni pixelov. . . . . . . . . 15 2.6 Ukážka použitia OCR na skenovanom papierovom dokumente. Obrázok zná- zorňuje vizuálnu detekciu znakov (zelené a modré rámčeky) a výsledok roz- poznaného textu (červené nápisy). . . . . . . . . . . . . . . . . . . . . . . . 17 2.7 Obrázok znázorňuje pôvodný farebný vstup (vľavo) a jeho binárizovanú ver- zia (vpravo), ktorá zvýrazňuje text pre následné spracovanie pomocou OCR. Binarizácia je dôležitým predspracovacím krokom v OCR, pretože umožňuje efektívnejšiu segmentáciu znakov. . . . . . . . . . . . . . . . . . . . . . . . . 19 3.1 Návrh implementácie systému rozdeleného na vstupný, testovací a výstupný modul. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.2 Ukážka konfiguračného súboru vo formáte JSON so zadefinovanými testova- cími, OCR a zakázanými regiónmi. . . . . . . . . . . . . . . . . . . . . . . . 23 4.1 Ukážka používateľského rozhrania nástroja na výber regiónov. Zobrazené sú všetky implementované typy regiónov: základné regióny Visual (zelená) a OCR (modrá), ako aj rozšírený typ Forbidden (fialová). V prípade OCR regiónov je možné zadať alternatívne textové varianty, ako vidno v dolnej časti obrázku. Každý región je vizuálne zvýraznený a podporuje interakciu podľa aktuálne zvoleného režimu. . . . . . . . . . . . . . . . . . . . . . . . . 30 4.2 Zobrazenie používateľského rozhrania nástroja pri výbere regiónov. V hornej časti obrazovky sa nachádza informačný panel s popisom ovládacích kláves. Tento panel slúži ako vizuálna pomôcka počas interakcie so systémom. . . . 31 4.3 Vývojový diagram spracovania testu. Zobrazuje rozhodovanie podľa typu de- finovaných regiónov a výsledok testovania s výstupom do JSON súboru. . . 33 3 4.4 Porovnanie výstupu pri vizuálnom testovaní: na ľavo je výstup v režime validated, ktorý zvýrazňuje len vizuálne významné rozdiely. Vpravo je vý- stup z režimu precise, ktorý zaznamenáva všetky pixelové odchýlky. Na obrázku je viditeľné,že validated režim ignoruje drobné odchýlky, ktoré nie sú postrehnuteľné ľudským okom, zatiaľ čo precise režim ich zvýrazní ako rozdiel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.5 Naľavo sa nachádza predspracovaná bitmapa pripravená na OCR. Na pravej strane je výstup z knižnice Pytesseract, ktorý demonštruje nízku presnosť rozpoznávania. Viditeľné sú vynechané znaky, nesprávne rozpoznané číslice a chybné identifikované textové časti. . . . . . . . . . . . . . . . . . . . . . . 38 4.6 Ukážka vnútornej dátovej štruktúry test_ocr_data, ktorá uchováva vý- sledky OCR spracovania. Obsahuje rozpoznané texty a ich súradnicové in- formácie (left, top, width, height), dôveryhodnosť rozpoznania (conf) a doplňujúce atribúty ako alias a forbidden, ktoré slúžia na špecifické spra- covanie počas porovnávania. . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.7 Ukážka interaktívneho porovnávania. Pravá strana zobrazuje pôvodný refe- renčný obrázok, zatiaľ čo ľavá časť (od deliacej línie) odhaľuje testovaný obraz spolu so zvýraznenými rozdielmi. Červené regiony označujú textové (OCR) odchýlky, modré regióny reprezentujú vizuálne rozdiely na úrovni pixelov. . 42 4.8 Výpis jedného konkrétneho testu z modulu. Zobrazený test test_3 obsahuje dve testované oblasti typu Visual Test a jeden typu OCR Test. . . . . . . 43 4.9 Súhrnný výpis všetkých vykonaných testov. Každý riadok reprezentuje jeden test, pričom v stĺpcoch sú uvedené informácie o stave testu, identifikačné číslo úspešných a neúspešných regiónov (OCR aj vizuálnych), ako aj zhrnutie. . . 43 A.1 Rozpoznaný text z rovnakého vstupného obrazu pomocou EasyOCR. Kniž- nica správne zachytil čísla aj diakritiku. . . . . . . . . . . . . . . . . . . . . 58 B.1 Porovnanie referenčného a testovacieho obrázka. Naľavo je zobrazený refe- renčný obrázok, napravo je testovací obrázok bez zistených odchýlok. . . . . 59 B.2 Porovnanie referenčného a testovacieho obrázka pre test s vizuálnymi a tex- tovými regiónmi. Naľavo je referenčný obrázok so vstupnými regiónmi vrá- tane vizuálnych, zakázaných a OCR oblastí. Napravo je testovací výstup so zvýraznenými chybami podľa typu zistených chýb. . . . . . . . . . . . . . . 60 B.3 Porovnanie referenčného a testovacieho obrázka. Naľavo sa nachádza refe- renčný obrázok, napravo je testovací výstup v ktorom bola identifikovaná OCR chyba v hodnote sumy za automobil. . . . . . . . . . . . . . . . . . . . 61 B.4 Porovnanie referenčného a testovacieho obrázka. Naľavo je referenčný obrá- zok, napravo testovací výstup bez zistených chýb vďaka využitiu forbidden regiónu v oblasti času. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 B.5 Porovnanie referenčného a testovacieho obrázka. Naľavo je referenčný obrá- zok, napravo testovací výstup s OCR chybou v oblasti názvu a vizuálnou chybou tlačidla pre pridávanie transakcie. . . . . . . . . . . . . . . . . . . . 63 B.6 Porovnanie referenčného a testovacieho obrázka. Naľavo je referenčný ob- rázok, napravo testovací obrázok v ktorom bola zistená vizuálna chyba v názve, keďže sa v tejto oblasti nenachádzal OCR región. Zároveň bola za- chytená zmena farby pri tlačidle pridávania transakcie a ďalšia odchýlka v spodnej časti v oblasti grafického prvku. . . . . . . . . . . . . . . . . . . . . 64 4 B.7 Porovnanie referenčného a testovacieho obrázka. Naľavo je referenčný obrá- zok, napravo testovací výstup v ktorom bola zachytená odchýlka spôsobená posunutím oranžového grafu, čo viedlo k pixelovým rozdielom. Zároveň boli identifikované chyby v OCR rozpoznaní hodnôt na osi y, ktoré sa líšili od očakávaných. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 B.8 Porovnanie referenčného a testovacieho obrázka. Naľavo je referenčný obrá- zok, napravo testovací výstup s viacerými vizuálnymi a textovými chybami. Hodnoty na osi y nezodpovedajú očakávanému výstupu (OCR chyby), v ob- lasti spodnej navigácie sa vyskytla malá pixelová odchýlka a niektoré drobné vizuálne chyby boli nesprávne zachytené. . . . . . . . . . . . . . . . . . . . . 66 B.9 Porovnanie referenčného a testovacieho obrázka. Naľavo je referenčný obrá- zok, napravo testovací obrázok bez zistených vizuálnych ani textových chýb. Ide o ukážku správne prebehnutého testu bez zachytených odchýlok. . . . . 67 C.1 Porovnanie referenčného a testovacieho obrázka. Referenčný obrázok je na- ľavo, testovací obrázok napravo obsahuje jednu vizuálnu chybu a to zmenu farby, ktorú bolo možné zaznamenať len vo vizuálnom regióne. . . . . . . . 68 C.2 Porovnanie referenčného a testovacieho obrázka. Referenčný obrázok je na- ľavo, testovací obrázok napravo obsahuje chyby v čísliciach. Tieto chyby od- halilo vizuálne testovanie, nie však OCR, ktoré navyše zaznamenalo neexis- tujúce chyby. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 C.3 Porovnanie referenčného a testovacieho obrázka. Referenčný obrázok je na- ľavo, testovací obrázok napravo obsahuje zmenu farby označených číslic v hre Sudoku. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 C.4 Porovnanie referenčného a testovacieho obrázka. Referenčný obrázok je na- ľavo, testovací obrázok napravo obsahuje OCR chybu spôsobenú odstránením názvu aplikácie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 C.5 Porovnanie referenčného a testovacieho obrázka. Referenčný obrázok je na- ľavo, testovací obrázok napravo obsahuje vizuálnu aj OCR chybu spôsobenú odstránením vrchného riadku hádania slova. Niektoré OCR regióny boli pre- kryté vizuálnymi, avšak písmeno L nebolo správne označené. . . . . . . . . 72 C.6 Porovnanie referenčného a testovacieho obrázka. Referenčný obrázok je na- ľavo, testovací obrázok napravo zobrazuje chybu spôsobenú odstránením textu Štart a grafického prvku. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 C.7 Porovnanie referenčného a testovacieho obrázka. Referenčný obrázok je na- ľavo, testovací obrázok napravo zobrazuje chybu spôsobenú vymazaním textu Konec. Ide o OCR chybu, ktorá bola zaznamenaná aj vizuálnym testovaním. 74 C.8 Porovnanie referenčného a testovacieho obrázka. Referenčný obrázok je na- ľavo, testovací obrázok napravo zobrazuje odstránenie prvku časovača a ná- sledné posunutie všetkých vizuálnych a textových prvkov smerom nahor. . . 75 C.9 Porovnanie referenčného a testovacieho obrázka. Referenčný obrázok je na- ľavo, testovací obrázok napravo nezobrazuje žiadne rozdiely – obe snímky sú totožné. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 D.1 Porovnanie referenčného a testovacieho obrázka. Referenčný obrázok je hore, testovací obrázok je dole, kde boli vymazaní dvaja užívatelia, čím došlo k posunu do ľavej strany. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 5 D.2 Porovnanie referenčného a testovacieho obrázka. Referenčný obrázok je hore, testovací obrázok je dole, kde bola zistená vizuálna chyba v podobe zväčšenia šípky. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 D.3 Porovnanie referenčného a testovacieho obrázka. Referenčný obrázok je hore, testovací obrázok je dole, kde boli nájdené zmeny v čase (OCR chyba) a zároveň posun tlačidiel na opačnú stranu bitmapy (vizuálna chyba). . . . . 79 D.4 Porovnanie referenčného a testovacieho obrázka. Referenčný obrázok je hore, testovací obrázok je dole, kde došlo k vizuálnej chybe a to zmene farby tla- čidiel Edit a Delete. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 D.5 Porovnanie referenčného a testovacieho obrázka. Referenčný obrázok je hore, testovací obrázok je dole, kde bola zistená OCR chyba vo vyplnení vstupného poľa a vo vizuálnej a OCR chybe odstránenia textu v tlačidlách. . . . . . . 81 D.6 Porovnanie referenčného a testovacieho obrázka. Referenčný obrázok je hore, testovací obrázok je dole, kde neboli zistené žiadne zmeny. Obe bitmapy sú zhodné. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 D.7 Porovnanie referenčného a testovacieho obrázka. Referenčný obrázok je hore, testovací obrázok je dole, kde bola zistená vizuálna chyba spôsobená odstrá- nením tlačidiel, ako aj OCR chyba, ktorá bola prekrytá vizuálnym regiónom. 83 D.8 Porovnanie referenčného a testovacieho obrázka. Referenčný obrázok je hore, testovací obrázok je dole, kde boli zistené vizuálne chyby v podobe zmene- ného pozadia vstupných polí. . . . . . . . . . . . . . . . . . . . . . . . . . . 84 D.9 Porovnanie referenčného a testovacieho obrázka. Referenčný obrázok je hore, testovací obrázok je dole, kde bola zistená OCR chyba spôsobená odstráne- ním názvu aplikácie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 6 Kapitola 1 Úvod Testovanie softvérových aplikácií a najmä ich grafických užívateľských rozhraní zohráva kľú- čovú úlohu v zabezpečení kvality a používateľskej skúsenosti. Vzhľadom na rastúcu zložitosť moderných používateľských rozhraní, ako aj tlak na rýchle a časté aktualizácie softvéru sa manuálne testovanie javí ako neefektívne, časovo náročné a náchylné na chyby. Tento problém viedol k rozvoju a implementácii automatizovaných testovacích prístupov, ktoré umožňujú spoľahlivé a opakovateľné overovanie správania aplikácií pri rôznych scenároch použitia. Medzi tieto automatizované techniky patrí aj porovnávanie bitmapových obrazov, ktoré umožňuje rozpoznať vizuálne zmeny medzi dvomi stavmi rozhrania a optické rozpoznáva- nie textu, ktoré slúži na overenie správnosti zobrazovaného textového obsahu. Tieto metódy sú obzvlášť užitočné pri testovaní dynamických prvkov grafiky, lokalizácií, textových výstu- pov či špecifických vizuálnych detailov, ktoré môžu mať zásadný vplyv na správnosť alebo použiteľnosť aplikácie. Táto bakalárska práca sa zameriava na implementáciu a experimentálne overenie týchto techník v prostredí programovacieho jazyka Python, ktorý vďaka svojej čitateľnosti, širokej podpore knižníc a univerzálnosti predstavuje vhodnú voľbu pre rýchly vývoj a testovanie softvérových nástrojov. Cieľom práce je vytvoriť funkčný, flexibilný a prakticky využiteľný nástroj na automatizované testovanie grafických rozhraní, ktorý bude reagovať na potreby vývojárov v reálnych projektoch. Navrhované riešenie je koncipované ako modulárny systém v ktorom možno nezávisle pracovať s rôznymi komponentmi – ako sú vizuálne porovnávanie, analýza optického roz- poznávania znakov, definovanie testovacích oblastí, zakázaných regiónov alebo prispôsobe- nie citlivosti porovnávania. Používateľ má možnosť jasne definovať, ktoré časti rozhrania sa majú testovať a zároveň vylúčiť oblasti, kde sa zmeny očakávajú alebo sú irelevantné (napr. dynamické časové pečiatky, animácie a pod.). V práci je kladený dôraz nielen na technickú realizáciu nástroja, ale aj na jeho pou- žiteľnosť v kontexte reálnych vývojových scenárov. Nástroj je navrhnutý tak, aby ho bolo možné jednoducho rozšíriť a prispôsobiť konkrétnym požiadavkám projektu. Súčasťou rieše- nia je aj vizualizácia výsledkov porovnávania, ktorá umožňuje rýchlu identifikáciu odchýlok a chýb, čím sa zvyšuje efektivita analýzy výstupov testov. Cieľom tejto práce je preto nielen overiť technickú realizovateľnosť testovania pomocou bitmapových máp a optické rozpoznávanie znakov v jazyku Python, ale zároveň ukázať ich praktickú hodnotu pri testovaní používateľských rozhraní. Výsledkom je komplexné riešenie, ktoré môže slúžiť ako základ pre ďalší rozvoj, prípadne byť využité v rôznych typoch softvérových projektov, kde sa kladie dôraz na kvalitu grafického výstupu. 7 Kapitola 2 Teoretický základ Táto kapitola poskytuje nevyhnutný teoretický základ pre pochopenie problematiky tes- tovania grafických užívateľských rozhraní a techník, ktoré sa pri tom používajú. Skúma význam grafických užívateľských rozhraní ako mosta medzi technickou zložitosťou systému a jeho používateľským prostredím, pričom zdôrazňuje potrebu testovania vizuálnych a tex- tových prvkov. Prehľad metód zahŕňa automatizované prístupy, ako sú bitmapové porov- návanie obrazov a optické rozpoznávanie znakov. Dôležitý je aj pohľad na nástroje, ktoré zvládajú dynamické rozhrania moderných desktopových aplikácií. Tieto poznatky sú kľú- čové pre návrh efektívnych riešení v oblasti automatizovaného testovania a zvyšovanie spo- ľahlivosti aplikácií. 2.1 Softvérové testovanie Softvérové testovanie je proces hodnotenia a overovania softvérového produktu alebo ap- likácie s cieľom zabezpečiť, že spĺňa požadované špecifikácie a funguje správne. V typic- kej komerčnej vývojovej organizácii môže náklad na zabezpečenie kvality prostredníctvom vhodného ladenia, testovania a overovacích aktivít predstavovať 50 až 75 % celkových ná- kladov na vývoj [8, 31]. V rámci vývoja softvéru sa testovanie a návrh testovacích prípadov zvyčajne realizuje na štyroch hlavných úrovniach [8]: • Jednotkové testovanie: Ide o najmenšiu vykonateľnú časť zdrojového kódu naprí- klad metódu alebo funkciu. Jednotkové testovanie sa zameriava na testovanie jed- notlivých podprogramov a menších stavebných blokov namiesto celého systému [11]. Niekedy vyžaduje vytvorenie dočasného ovládača a často sa vykonáva v ladiacom programe [31]. • Integračné testovanie: Testuje viaceré komponenty, ktoré už predtým samostatne prešli jednotkovým testovaním [31]. Cieľom je overiť ich vzájomnú spoluprácu. Tento typ testovania sa realizuje buď metódou zhora nadol, alebo zdola nahor [11]. • Systémové testovanie: Overuje, či softvér plní svoju funkcionalitu ako celok. Pri- pravujú sa testovacie plány, ktoré pokrývajú požiadavky špecifikované v návrhu [11]. Tento typ testovania je obzvlášť dôležitý pri kontrole rozhrania aplikácie, pretože veľká časť systémových testov sa realizuje priamo nad používateľským rozhraním [31]. 8 • Akceptačné testovanie: Overuje, či softvér spĺňa požiadavky a očakávania zákaz- níka. Tento typ testovania často vykonávajú samotní koncoví používatelia alebo sa vy- konáva v ich prítomnosti [11]. Popri vyššie uvedených testovacích úrovniach je dôležitou súčasťou životného cyklu soft- véru aj tzv. regresívne testovanie. Jeho cieľom je zabezpečiť aby zmeny v kóde – na- príklad opravy chýb alebo nové funkcionality nespôsobili vedľajšie negatívne efekty v iných častiach systému. Overuje sa teda, či aktualizovaný softvér zachováva funkcionalitu, ktorá bola správna v predchádzajúcich verziách [31]. Princíp tohto typu testovania znázorňuje obrázok 2.1. Po identifikácii chyby a jej oprave vývojárom sa nová verzia opätovne testuje, často pomocou predtým definovaných testovacích prípadov. Tento proces sa opakuje, až kým sa nepotvrdí, že všetky pôvodne funkčné časti systému fungujú aj po zmene [8]. Regresívne testovanie tiež pomáha identifikovať problémy spätnej kompatibility a je ne- vyhnutné pre udržanie stability systému počas jeho vývoja [8]. Optimalizácia tohto typu testovania má preto zásadný význam z hľadiska dlhodobej udržateľnosti a efektívnosti vý- voja softvéru [31]. Softvérová aplikácia Implementácia nových funkcií Spustenie regresívných testov Ovplyvnený existujúci modul Žiadne chyby Nájdenie chýb Opravenie chýb Spustenie regresívnych testov Žiadne chybySkončenie procesu Obr. 2.1: Princíp regresívneho testovania po implementácii zmien v softvéri1. 2.2 Grafické užívateľské rozhrania Grafické užívateľské rozhranie (ďalej GUI) je spôsob komunikácie medzi používateľom a po- čítačom, ktorý využíva vizuálne prvky ako sú okná, ikony, menu, tlačidlá, rozbaľovacie zoznamy či dialógové okná. Hlavným cieľom je zjednodušiť interakciu medzi človekom a po- čítačom tým, že skryje zložitosť programovania a ponúka intuitívny prístup k aplikáciám. GUI umožňuje používateľovi vykonávať úlohy, ako je napríklad formátovanie textu alebo výber súborov pomocou jednoduchých kliknutí na ikony či výberov z menu, čo je na rozdiel od príkazového riadku, kde sa používajú textové príkazy. Grafické užívateľské rozhrania sú navyše typicky riadené udalosťami, takže akcia ako kliknutie na tlačidlo alebo výber položky spustí vykonanie príslušnej úlohy [15, 16]. 1Prekreslené a preložené do slovenčiny, prevzaté z webu https://www.educba.com/regression-testing/. 9 https://www.educba.com/regression-testing/ GUI rieši tzv. problém prázdnej obrazovky, ktorý bol typický pre skoré počítače, kde sa používateľ stretával iba s príkazovým riadkom bez akýchkoľvek vizuálnych nástrojov. Jeho hlavné prvky zahŕňajú systém okien, model zobrazovania a aplikačné programové rozhranie, ktoré umožňujú efektívne prepojenie používateľa s potenciálom počítača. GUI tak odstraňuje prekážky v komunikácii a umožňuje používateľovi sústrediť sa na hlavnú úlohu, nie na samotné ovládanie systému [12, 16]. História GUI Prvé grafické užívateľské rozhranie bolo vyvinuté v roku 1977 vo výskumnom centre Xe- rox Palo Alto Research Center pre systém Xerox Star. Tento systém bol unikátny tým, že vývojári sa sústredili na návrh užívateľského rozhrania ešte pred navrhnutím vnútornej architektúry aplikácie. Napriek inováciám však Xerox Star nebol komerčne úspešný kvôli svojej nízkej výkonnosti [12]. Steve Jobs, inšpirovaný prácou v Xerox Palo Alto Research Center, následne priniesol koncept GUI do Apple čo viedlo k vývoju systému Apple Lisa. Ten nebol úspešný, ale v roku 1984 spoločnosť Apple uviedla na trh Macintosh, ktorý definoval základné princípy moder- ného GUI. Neskôr sa objavili ďalšie významné štandardy GUI ako IBM Systems Application Architecture (SAA) a MIT X-Windowing System, obľúbený pre UNIX systémy Evolúcia grafických rozhraní je znázornená na obr. 2.2 [12]. Obr. 2.2: Príklad vývoja grafického užívateľského rozhrania: porovnanie vzhľadu prvých desktopových prostredí (Macintosh 1984) so súčasnými systémami (napr. Windows 11). Obrázok znázorňuje výrazný posun v dizajne, prehľadnosti a komplexnosti grafického ro- zhrania, od jednoduchých čiernobielych ikon a obmedzenej funkcionality až po moderné vizuálne bohaté rozhrania so širokým spektrom interakčných prvkov a responzívnym dizaj- nom3. 2.3 Testovanie grafických užívateľských rozhraní Testovanie grafických užívateľských rozhraní je proces, pri ktorom sa aplikácia testuje vý- hradne vykonávaním sekvencií udalostí na GUI prvkoch ako sú tlačidlá, textové polia alebo iné ovládacie prvky. Správnosť aplikácie sa určuje skúmaním stavu GUI prvkov po vykonaní 3Ilustrácia vytvorená na základe obrazkov zo stránok https://www.cio.com/article/284864/ the-evolution-of-the-desktop-gui.html a https://www.itprotoday.com/windows-11/windows-11- interface-and-visual-changes-for-enterprise-users. 10 https://www.cio.com/article/284864/the-evolution-of-the-desktop-gui.html https://www.cio.com/article/284864/the-evolution-of-the-desktop-gui.html https://www.itprotoday.com/windows-11/windows-11-interface-and-visual-changes-for-enterprise-users https://www.itprotoday.com/windows-11/windows-11-interface-and-visual-changes-for-enterprise-users týchto akcií. Hoci tento typ testovania pracuje iba s rozhraním, môže odhaliť rôzne typy chýb, vrátane tých, ktoré súvisia s podkladovou biznis logikou aplikácie, nie len s rozhraním samotným [32]. Testovanie GUI je špecifické tým, že správanie aplikácie je úzko prepojené s kontex- tom, v ktorom sa udalosti vykonávajú. Sekvencie udalostí môžu meniť stav softvéru a tým ovplyvniť následné správanie aplikácie. To znamená, že každý prvok GUI musí byť testovaný v rôznych kontextoch, čo pridáva na zložitosti testovania [32]. Význam testovania GUI Grafické užívateľské rozhrania sú neoddeliteľnou súčasťou moderných softvérových aplikácií. S narastajúcou veľkosťou a zložitosťou kódu sa zvyšuje aj náročnosť ich testovania. Viac ako polovica kódu GUI je zameraná na zobrazovanie, zatiaľ čo funkcionalita ostáva často v pozadí. Táto situácia si vyžaduje špecifické testovacie prístupy, aby sa zabezpečila správna funkčnosť, bezpečnosť a použiteľnosť. Tradičné metódy testovania kódu sú pri aplikovaní na GUI systémy často neefektívne, najmä pre ich udalosťami riadený charakter a obrovský vstupný priestor. Synchronizácie a závislosti medzi objektmi, ako aj rôznorodé možnosti interakcie používateľa zvyšujú komplexnosť testovania [16, 18]. Kvalitné testovanie GUI je preto kľúčové pre odhalenie chýb, ktoré môžu narušiť konzis- tenciu údajov alebo znížiť spokojnosť používateľov. Efektívne testovanie pomáha identifiko- vať problémy už v raných fázach vývoja, čím znižuje náklady na budúcu údržbu a zlepšuje celkovú kvalitu softvéru. V prostredí agilného vývoja, kde sa aplikácie často menia je testo- vanie nevyhnutné na zaistenie stability a kompatibility s rôznymi zariadeniami a operačnými systémami [16, 14]. Dôležitou súčasťou testovania GUI sú modely, ako sú konečné automaty (FSM) zo- brazený na obrázku 2.3 a diagramy sekvencií udalostí (ESD). Tieto nástroje umožňujú systematickú analýzu správania GUI a jeho interakcií, pričom poskytujú štruktúrovaný spôsob reprezentácie celého systému. Modely rozdeľujú GUI na dve úrovne: komponentovú a systémovú. Na komponentovej úrovni sa testuje správna funkčnosť jednotlivých prvkov, zatiaľ čo na systémovej úrovni sa skúma, ako tieto komponenty spolupracujú. Tento prí- stup nielen zefektívňuje odhaľovanie chýb, ale tiež zlepšuje konzistenciu a spoľahlivosť celého systému [14]. Automatizované testovanie výrazne urýchľuje proces identifikácie chýb, keďže umožňuje opakovane a konzistentne overovať správanie aplikácie bez potreby manuálneho zásahu. Vďaka tomu sú vývojári schopní získať okamžitú spätnú väzbu o funkčnosti používateľ- ského rozhrania po každej zmene v kóde, čo znižuje riziko zanesenia regresií a skracuje čas potrebný na opravu. Táto schopnosť rýchlej detekcie problémov je obzvlášť cenná v kon- kurenčnom prostredí, kde aj malé chyby môžu negatívne ovplyvniť používateľský zážitok a tým aj celkový úspech aplikácie na trhu. Testovanie GUI preto nemožno vnímať len ako technický krok v záverečnej fáze vývoja, ale ako integrálnu súčasť celého vývojového cyklu. Plní dôležitú úlohu pri zabezpečovaní funkčnej správnosti, odolnosti voči zlyhaniam, ako aj celkovej spokojnosti koncového používateľa [14, 16]. 11 VyhľadávanieChyba Vyhľadávanie Vybrať fotografiu Galéria Zavrieť fotografiu Fotografia Hľadanie chyby Hľadanie úspešné, zrušenie hľadania Načítavanie Vyhľadávanie Štart Obr. 2.3: Príklad konečného automatu (FSM), ktorý reprezentuje stavové prechody v jed- noduchej GUI aplikácii galérie. Každý stav zodpovedá konkrétnej obrazovke a prechody sú vyvolané používateľskými akciami5. Metódy testovania GUI Informácie o metódach testovania som čerpal z [29]. • Manuálne testovanie: Tento prístup zahŕňa ľudského testera, ktorý ručne kontro- luje každú obrazovku aplikácie, aby overil funkčnosť a použiteľnosť dizajnových prv- kov. Manuálne testovanie je užitočné najmä v počiatočných fázach vývoja, keď sa prav- depodobnosť chýb zvyšuje a je potrebný ľudský zásah na overenie dizajnových ele- mentov. • Testovanie s použitím nahrávania a prehrávania: Tento prístup využíva nástroje na nahrávanie a prehrávanie, ktoré zaznamenávajú interakciu užívateľa s aplikáciou. Testeri spustia aplikáciu a zaznamenajú akcie, ktoré môžu byť následne opakovane prehrávané na odhalenie problémov v užívateľskom rozhraní. • Modelovo orientované testovanie: Táto metóda zahŕňa vytvorenie modelu, ktorý pomáha pochopiť a vyhodnotiť správanie systému. Model môže generovať testovacie prípady na základe systémových požiadaviek. Existujú rôzne aspekty, ktoré sa v mo- delovo orientovanom testovaní zohľadňujú, vrátane automaticky generovaných testo- vacích prípadov a meraní pokrytia modelu a požiadaviek. • Hybridné prístupy: Tieto prístupy kombinujú rôzne metódy testovania ako je ma- nuálne testovanie s automatizovanými technikami, čím využívajú silné stránky oboch prístupov. 5Prekreslené a preložené do slovenčiny, prevzaté z webu https://css-tricks.com/robust-react-user- interfaces-with-finite-state-machines/. 12 https://css-tricks.com/robust-react-user-interfaces-with-finite-state-machines/ https://css-tricks.com/robust-react-user-interfaces-with-finite-state-machines/ 2.4 Výzvy a problémy v GUI testovaní Automatizované testovanie GUI sa za posledné desaťročia stalo dôležitou súčasťou vývoja softvéru. Napriek pokroku v tejto oblasti však GUI testovanie čelí významným výzvam a problémom, ktoré často bránia jeho efektívnemu využitiu. Hlavné problémy testovania som čerpal z [18]. • Krehkosť testov spôsobená zmenami v aplikácii: Jednou z najčastejšie spomí- naných výziev je, že zmeny v GUI často vedú k zlyhaniu testovacích skriptov. Zmeny ako napríklad preskupenie alebo odstránenie widgetov, vyžadujú prepracovanie tes- tovacích prípadov, čo zvyšuje náklady na údržbu. • Synchronizácia medzi testami a systémom: Automatizované testy môžu zlyhať, ak sa testovací skript spustí skôr, než je systém pripravený. Tento problém môže spôsobiť falošné pozitíva, ktoré vedú k časovo náročným analýzam chýb. • Spoľahlivé rozpoznávanie GUI prvkov: Identifikácia prvkov v GUI je základným problémom, pretože menšie zmeny, ako zmena veľkosti alebo pozície prvku, môžu na- rušiť testovanie. Kombinácia rôznych metód, napríklad identifikátorov a kontextových vodítok, môže tento problém zmierniť. • Testovanie dynamických aplikácií: Dynamický obsah, meniace sa databázy alebo závislosti od externých systémov robia automatizáciu GUI náročnou. Aplikácie vyža- dujú komplexné prípravy prostredia a stabilné predpoklady pre testovanie. • Explózia stavového priestoru: Počet možných interakcií v GUI môže byť prakticky nekonečný, čo komplikuje snahy o kompletné pokrytie všetkých možných scenárov. • Požiadavky na odborné znalosti: Automatizácia GUI často vyžaduje znalosti programovania alebo skúsenosti s nástrojmi na testovanie, čo môže byť pre niektoré tímy prekážkou. • Problémy s nástrojmi: Nedostatky testovacích nástrojov, ako je zložitá inštalácia, slabá dokumentácia alebo obmedzená podpora určitých platforiem znižujú efektívnosť testovania. 2.5 Definícia Bitmapových vzorov Bitmapové vzory sú digitálne obrazové formáty založené na rastri, kde sa obraz skladá z množstva malých štvorcov/pixelov zobrazených na obrázku 2.4. Každý pixel predstavuje jeden bod obrazu, pričom jeho farba je definovaná určitým počtom bitov dát. Bitmapy sú často používané na ukladanie fotografií a grafiky, podporujú formáty ako BMP, JPEG, PNG či GIF [23]. Charakteristiky bitmapových vzorov [23]: • Pixely ako základ: Bitmapa je mriežka pixelov, kde každý pixel má svoju presnú polohu a farbu. To umožňuje presné zobrazenie detailov. • Rozlíšenie: Počet pixelov (šírka x výška) určuje rozlíšenie. Vyššie rozlíšenie znamená viac detailov, ale aj väčšiu veľkosť súboru. 13 • Farebná hĺbka: Udáva, koľko farieb môže každý pixel zobrazovať. Napríklad 24 bitová farebná hĺbka umožňuje milióny farieb. • Závislosť na rozlíšení: Pri zväčšení bitmapového vzoru dochádza k strate kvality, pretože pixely sú pevne dané. • Ukladanie a pamäť: Bitmapové súbory často zaberajú veľa miesta v pamäti, pretože ukladajú údaje o každom jednotlivom pixeli. Obr. 2.4: Zobrazenie princípu bitmapovej reprezentácie obrázka: vizuálny obraz (vľavo) je prevedený do binárnej matice (vpravo), kde 1 označuje čierny pixel a 0 biely pixel. Takáto forma sa využíva pri analýze a porovnávaní bitmap v GUI testovaní7. 2.6 Bitmapové vzory v testovaní grafických prvkov Bitmapové vzory v kontexte testovania GUI predstavujú prístup k interakcii so softvéro- vými systémami, ktorý využíva obrazové dáta na identifikáciu a manipuláciu s komponentmi grafického užívateľského rozhrania. Tento spôsob testovania sa odlišuje od tradičných me- tód, ktoré pracujú buď s kódom aplikácie alebo s pevne danými súradnicami prvkov GUI na obrazovke. Na rozdiel od nich sa bitmapové vzory zameriavajú na vizuálne rozpoznanie komponentov pomocou ich obrazovej reprezentácie, čo umožňuje identifikovať každý prvok na základe jeho vzhľadu [3]. Výhodou bitmapových vzorov je ich flexibilita pri zmene rozloženia GUI. Vyhľadáva- nie komponentov nie je závislé na presnej polohe, ale na ich vizuálnych charakteristikách, čo znižuje citlivosť na zmeny v usporiadaní. Tento proces je ideálny pre širokú škálu prvkov, ako sú tlačidlá, statické obrázky alebo pohyblivé objekty a umožňuje efektívne testovanie aj v aplikáciách s nenatívnymi či ručne kreslenými prvkami [17]. 2.7 Porovnávanie Bitmapových vzorov Porovnávanie bitmapových máp je dôležitou metódou používanou pri testovaní grafických používateľských rozhraní, ktorá umožňuje analyzovať vizuálne rozdiely medzi očakávaným 7Obrázok bol prevzatý zo stránky https://www.scan2cad.com/blog/tips/bitmap-vs-vector/. 14 https://www.scan2cad.com/blog/tips/bitmap-vs-vector/ a aktuálnym stavom rozhrania. Táto technika využíva snímky obrazovky ako vizuálne re- ferencie na identifikáciu zmien v štruktúre alebo funkcii jednotlivých prvkov GUI [7]. Základný princíp bitmapového porovnania je znázornený na obrázku 2.5. Obraz je roz- delený na mriežku pixelov, ktoré sú analyzované po jednom. Obr. 2.5: Príklad porovnania bitmapových obrázkov na úrovni pixelov. Prvý a druhý ob- rázok predstavujú dve farebné bitmapy, ktoré sú porovnávané. Tretí obrázok zobrazuje výsledok porovnania – červenou farbou sú vyznačené pixely, kde došlo k rozdielu9. Proces porovnávania bitmapových máp 1. Tvorba referenčných máp: Na začiatku procesu sa vytvárajú referenčné bitmapové mapy, ktoré zachytávajú ideálny stav GUI. Tieto mapy môžu obsahovať textové polia, tlačidlá, obrázky alebo iné prvky, ktoré sú dôležité pre vizuálnu konzistenciu aplikácie. Tieto referencie slúžia na porovnanie so snímkami vytvorenými počas testovania [6]. 2. Automatizované snímanie obrazovky: Počas testovania sa generujú aktuálne snímky obrazovky, ktoré sa porovnávajú s referenčnými mapami. Automatizované nástroje dokážu z týchto snímok extrahovať dôležité vizuálne charakteristiky a iden- tifikovať homogénne aj heterogénne oblasti [7]. 3. Použitie algoritmov na porovnávanie: Pri analýze rozdielov medzi bitmapovými mapami sa využívajú rôzne algoritmy: • Pixelové porovnanie: Priame porovnanie farebných hodnôt pixelov medzi re- ferenčnými a aktuálnymi snímkami [7]. • Stredná kvadratická chyba (ďalej MSE): Metóda, ktorá spočíva vo výpočte priemerného kvadratického rozdielu medzi zodpovedajúcimi pixelmi referenčného a testovaného obrázka zobrazená v rovnici 2.1. Čím je výsledná hodnota MSE nižšia, tým je obraz považovaný za kvalitnejší, teda vernejšie zodpovedá originálu. MSE = 1 𝑛 𝑛∑︁ 𝑖=1 (𝐼1(𝑖)− 𝐼2(𝑖)) 2 (2.1) 9Obrázok bol prekleslený a prevzatý zo stránky https://applitools.com/blog/visual-ai-vs-pixel- matching-dom-based-comparisons/. 15 https://applitools.com/blog/visual-ai-vs-pixel-matching-dom-based-comparisons/ https://applitools.com/blog/visual-ai-vs-pixel-matching-dom-based-comparisons/ Kde 𝐼1(𝑖) a 𝐼2(𝑖) predstavujú intenzitu pixela na pozícii 𝑖 v referenčnom a testo- vanom obrázku a 𝑛 je celkový počet pixelov. Výsledkom je priemerný kvadratický rozdiel medzi dvoma obrazmi – čím nižšia hodnota, tým väčšia zhoda [2]. • Index štrukturálnej podobnosti (ďalej SSIM): Metrika určená na hod- notenie kvality obrazov, ktorá zohľadňuje štruktúru, jas a kontrast namiesto porovnávania jednotlivých pixelov. SSIM sa počíta v lokálnych oknách obrazov na základe priemeru (luminancie), štandardnej odchýlky (kontrastu) a kovarian- cie (štruktúry). Výsledná hodnota sa pohybuje v intervale [−1, 1], pričom vyššie hodnoty indikujú väčšiu podobnosť medzi porovnávanými obrazmi. Matematicky je SSIM modelovaný ako súčin troch komponentov – luminančnej, kontrastnej a štrukturálnej časti umocnených príslušnými váhovými exponentmi, ako je znázornené v rovnici 2.2: SSIM(𝑥, 𝑦) = [𝑙(𝑥, 𝑦)]𝛼 · [𝑐(𝑥, 𝑦)]𝛽 · [𝑠(𝑥, 𝑦)]𝛾 (2.2) kde 𝑥 a 𝑦 predstavujú porovnávané obrazy, pričom 𝑙(𝑥, 𝑦) je luminančná zložka (jas), 𝑐(𝑥, 𝑦) vyjadruje kontrast a 𝑠(𝑥, 𝑦) zachytáva štrukturálnu podobnosť. Exponenty 𝛼, 𝛽 a 𝛾 sú kladné konštanty, ktorými možno ovplyvniť váhu jed- notlivých komponentov v celkovom hodnotení podobnosti [2]. • Učená percepčná podobnosť obrazových výrezov (ďalej LPIPS): Je metrika hodnotiaca vizuálnu podobnosť obrazov na základe príznakov extra- hovaných z hlbokých neurónových sietí. Namiesto priameho porovnania pixelov porovnáva LPIPS výstupy z viacerých vrstiev konvolučnej siete, čím lepšie zod- povedá ľudskému vnímaniu vizuálnych rozdielov. Výpočet prebieha ako vážená euklidovská vzdialenosť medzi normalizovanými príznakmi, ako je znázornené v rovnici 2.3: 𝑑(𝑥, 𝑥0) = ∑︁ 𝑙 1 𝐻𝑙𝑊𝑙 ∑︁ ℎ,𝑤 ⃒⃒⃒ 𝑤𝑙 ⊙ (︁ 𝑦𝑙ℎ𝑤 − 𝑦𝑙0ℎ𝑤 )︁⃒⃒⃒2 2 (2.3) kde 𝑦𝑙ℎ𝑤 a 𝑦𝑙0ℎ𝑤 sú príznaky z vrstvy 𝑙 pre vstupné obrazy 𝑥 a 𝑥0, 𝐻𝑙 a 𝑊𝑙 sú rozmery príznakov a 𝑤𝑙 je váhový vektor [2]. 2.8 Optické rozpoznávanie znakov Optické rozpoznávanie znakov (ďalej OCR) je technológia, ktorá umožňuje automatické rozpoznávanie a prevod textu z obrázkov, skenovaných dokumentov alebo rukopisov do digi- tálnej a editovateľnej podoby. Cieľom OCR je extrahovať text z rôznych zdrojov, ako sú tla- čené, rukou písané alebo skenované dokumenty a previesť ho do formátu, ktorý je strojovo čitateľný a môže byť ďalej spracovávaný. Tento proces zahŕňa niekoľko fáz, vrátane pred- spracovania obrazu na odstránenie šumu a zlepšenie kvality, segmentácie textu na jednotlivé znaky alebo bloky, extrakcie vlastností a následnej klasifikácie rozpoznaného textu [9]. OCR využíva metódy digitálneho spracovania obrazu, aby dokázala identifikovať a pre- viesť text z obrázkov do strojovo čitateľného formátu. Predspracovanie zahŕňa operácie, ako je odstránenie šumu, korekcia sklonu a vyrovnanie jasu, čím sa zlepšuje kvalita obrazu pre ďalšie kroky. Segmentácia umožňuje rozdeliť text na jednotlivé znaky, ktoré sú základom pre presné rozpoznávanie [26]. 16 Extrakcia vlastností zohráva kľúčovú úlohu pri identifikácii znakov. Využívajú sa rôzne techniky, ako je identifikácia okrajov, analýza hustoty alebo detekcia geometrických vlast- ností. Klasifikácia na základe extrahovaných vlastností priraďuje každému segmentu kon- krétny znak, pričom využíva algoritmy, ako sú neurónové siete alebo štatistické modely [4]. OCR sa široko používa v rôznych oblastiach, ako je digitalizácia knižničných dokumen- tov, spracovanie faktúr a úradných dokumentov, či automatizované testovanie softvéru. Jednou z významných výhod OCR je jeho schopnosť uľahčiť vyhľadávanie a prácu s tex- tom, ktorý bol predtým dostupný len v obrazovej forme alebo papierovej, ako je zobrazené na obrázku 2.6 [1, 4]. Moderné OCR systémy dokážu dosiahnuť presnosť až 99 %, avšak pri historických alebo poškodených dokumentoch môže byť táto presnosť nižšia. Vďaka neustálemu vývoju algorit- mov a metód je OCR technológia schopná zvládnuť aj zložité písma, rukopisy či viacjazyčné texty, čím sa stáva nevyhnutnou súčasťou moderných digitálnych riešení [9]. Obr. 2.6: Ukážka použitia OCR na skenovanom papierovom dokumente. Obrázok znázor- ňuje vizuálnu detekciu znakov (zelené a modré rámčeky) a výsledok rozpoznaného textu (červené nápisy). Viditeľné sú aj chyby v rozpoznaní, ktoré vznikli v dôsledku kvality pred- lohy alebo štruktúry textu11. 2.9 OCR v automatizovanom testovaní V kontexte automatizovaného testovania GUI aplikácií je OCR využívaná na lokalizáciu grafických prvok podľa textových označení, napríklad tlačidiel, položiek v menu alebo titul- kov okien. Tento prístup umožňuje vyhľadávať a interagovať s komponentmi na základe ich textového obsahu, čím sa eliminuje potreba závislosti na vnútorných štruktúrach GUI [21]. OCR technológie v tomto prostredí umožňujú testovacím nástrojom identifikovať a ma- nipulovať s grafickými prvkami nezávisle od použitých softvérových rámcov alebo knižníc, čo je výhodné najmä pri multiplatformovom testovaní. V porovnaní s prístupmi založenými 11Obrázok bol upravený a prevzatý zo stránky https://www.edenai.co/post/how-to-use-ocr-with- javascript. 17 https://www.edenai.co/post/how-to-use-ocr-with-javascript https://www.edenai.co/post/how-to-use-ocr-with-javascript na šablónovom zhodnocovaní obrazu ponúka OCR väčšiu stabilitu, pretože textové vlast- nosti sú menej náchylné na zmeny vo vzhľade grafických ovládacich prkov, ako sú farby, veľkosti alebo fonty, ktoré sa môžu meniť počas aktualizácií aplikácií. To zvyšuje robustnosť testovacích skriptov a znižuje potrebu ich častých úprav [21, 4]. Výhody OCR v testovaní GUI zahŕňajú jeho schopnosť fungovať na rôznych plat- formách, ako sú Android, iOS, Windows alebo Linux, bez potreby špecifických vrstiev pre jednotlivé platformy. Tým sa uľahčuje automatizované testovanie aj v prípadoch, keď GUI obsahuje neštandardné alebo vlastné komponenty vytvorené v menej bežných knižni- ciach [21, 25]. Integrácia OCR do automatizovaného testovania prináša možnosť výrazného zlepšenia efektivity a presnosti testov, avšak vyžaduje dôkladnú optimalizáciu technológie, aby sa eli- minovali jej súčasné obmedzenia, ako sú nízka rýchlosť spracovania alebo závislosť od kvality vstupného obrazu [21]. 2.10 Princíp fungovania OCR Optické rozpoznávanie znakov je proces, ktorý umožňuje transformovať obrazový obsah (napríklad texty na obrazovke, v naskenovaných dokumentoch či farebných snímkach ob- razovky) na strojovo čitateľné textové formáty. Tento proces zahŕňa viacero krokov, ktoré sú kľúčové pre úspešnú interpretáciu znakov [4]. Tento text bol prevzatý z [4, 5, 28]. • Analýza rozloženia stránky: OCR začína analýzou rozloženia stránky, ktorá iden- tifikuje oblasti obsahujúce text a tie následne segmentuje na riadky alebo jednotlivé znaky. Táto etapa je nevyhnutná, pretože zaisťuje, že text je izolovaný od pozadia a iných grafických prvkov. • Binarizácia obrazu: Text z farebných alebo sivých obrázkov je transformovaný na čierno-biely (binarizovaný) obraz, ako ukazuje obrázok 2.7. Tým sa zvýraznia znaky a zníži vplyv farebného pozadia. Tradičné algoritmy, ako je prahovanie podľa Otsuovej metódy, však môžu zlyhávať v prípadoch, kde pozadie a text majú podobné farby. Pokročilé algoritmy, ako je FBCITextBin identifikujú textové oblasti nezávisle od farby a pozadia. • Segmentácia znakov: Segmentácia rozdeľuje obraz na menšie časti, ktoré reprezen- tujú jednotlivé znaky alebo ich časti. Tento krok je kľúčový pre ďalšie spracovanie, ale môže byť komplikovaný pri prekrývajúcich sa alebo zle čitateľných znakoch. • Extrakcia vlastností: Každý znak sa analyzuje na základe jeho tvarových a geomet- rických charakteristík. Tieto vlastnosti zahŕňajú línie, oblúky, uhly či krivky, ktoré sú jedinečné pre každý znak. Moderné OCR systémy využívajú aj metódy zalo- žené na hlbokých neurónových sieťach, ktoré umožňujú analyzovať znaky ako celok aj v kontexte riadku textu. • Rozpoznávanie textu: Na základe extrahovaných vlastností sa znaky porovnávajú s databázou znakov alebo trénovacím modelom. Tesseract je jeden z najpoužíva- nejších OCR nástrojov, využíva hlboké neurónové siete na rozpoznanie textu a jeho konverziu do digitálnej podoby. Tento krok je ovplyvnený kvalitou predchádzajúcich etáp, ako je binarizácia a segmentácia. 18 • Následné spracovanie: Po rozpoznaní textu sú výsledky preverené a opravené na zá- klade kontextových pravidiel. Napríklad slovníky môžu pomôcť opraviť nesprávne roz- poznané slová. Tento krok je obzvlášť dôležitý pri textoch, ktoré musia mať vysokú presnosť (napr. sériové čísla alebo kódy). Obr. 2.7: Obrázok znázorňuje pôvodný farebný vstup (vľavo) a jeho binárizovanú verzia (vpravo), ktorá zvýrazňuje text pre následné spracovanie pomocou OCR. Binarizácia je dôležitým predspracovacím krokom v OCR, pretože umožňuje efektívnejšiu segmentáciu znakov13. 2.11 Praktické príklady a aplikácie Testovanie GUI pomocou techník OCR a porovnávania bitmapových vzorov je užitočné v si- tuáciách, kde tradičné metódy identifikácie prvkov zlyhávajú. Tieto techniky sa využívajú pri automatizácii aplikácií, ktoré nemajú prístupný zdrojový kód, neponúkajú jedinečné identifikátory pre svoje prvky alebo testovanie by bolo časovo a peňažne náročné [13, 29]. Konkrétne príklady aplikácií: • Automatizácia desktopových aplikácií: Nástroje ako SikuliX umožňujú auto- matizovať interakcie s desktopovými aplikáciami prostredníctvom rozpoznávania ob- razových vzorov a OCR. To je užitočné pri testovaní aplikácií bez prístupu k ich zdro- jovému kódu alebo API [27]. • Testovanie hier: Mnohé hry neposkytujú tradičné prvky používateľského rozhrania, ktoré by bolo možné identifikovať pomocou štandardných nástrojov. Použitím porov- návania bitmapových vzorov je možné identifikovať grafické prvky a automatizovať testovanie herných scenárov [19]. • Automatizácia vzdialených desktopov: Pri práci s virtuálnymi strojmi alebo vzdialenými desktopmi, kde nie je priamy prístup k prvkom GUI je možné použiť OCR a porovnávanie obrázkov na identifikáciu a interakciu s prvkami na obrazovke [20]. 13Obrázok bol prevzatý zo stránky https://www.mathworks.com/help/vision/ug/recognize-text- using-craft-model-and-ocr.html. 19 https://www.mathworks.com/help/vision/ug/recognize-text-using-craft-model-and-ocr.html https://www.mathworks.com/help/vision/ug/recognize-text-using-craft-model-and-ocr.html Implementácia v testovacích nástrojov: • SikuliX: Tento nástroj využíva techniky rozpoznávania obrazových vzorov na iden- tifikáciu prvkov na obrazovke. Umožňuje používateľom vytvárať skripty, ktoré inte- ragujú s prvkami na základe ich vizuálneho vzhľadu. SikuliX tiež integruje OCR na rozpoznávanie textu na obrazovke, čo umožňuje interakciu s textovými prvkami bez potreby presných obrázkových vzorov [10]. • PyAutoGUI: Primárne poskytuje funkcie na automatizáciu myši a klávesnice, môže byť rozšírený o OCR pomocou knižníc ako Pytesseract. To umožňuje identifikovať textové prvky na obrazovke a interagovať s nimi na základe rozpoznaného textu [24]. • Selenium: Primárne určený na automatizáciu webových aplikácií prostredníctvom prístupu k prvkom DOM. V prípadoch, kde nie je možné identifikovať prvky tradič- nými metódami, je možné integrovať nástroje ako SikuliX na rozpoznávanie obrazo- vých vzorov a tým rozšíriť možnosti automatizácie [22]. 20 Kapitola 3 Návrh softvérovej implementácie Táto kapitola sa venuje návrhu implementácie systému na automatizované testovanie GUI prostredníctvom bitmapových vzorov a technológie OCR, pričom jeho architektúra je sche- maticky znázornená na obrázku 3.1. Hlavným cieľom návrhu je vytvoriť modulárny systém, ktorý bude schopný efektívne analyzovať grafické výstupy aplikácií a overovať ich správnosť na základe vizuálnych a textových údajov. Návrh riešenia som koncipoval tak, aby bol systém rozdelený na samostatné jasne defi- nované komponenty, ktoré je možné nezávisle používať, testovať a rozširovať. Tento prístup zabezpečuje vysokú mieru flexibility, opakovateľnosti a prispôsobiteľnosti špecifickým po- žiadavkám používateľa. Vstupné dáta som v rámci systému považoval za pripravené. Z tohto dôvodu sa návrh implementácie nezaoberá spôsobom ich získavania, ale sústreďuje sa na spracovanie týchto dát, testovanie vizuálnych a textových vlastností GUI prvkov a generovanie výstupov, ktoré umožňujú rýchlu identifikáciu odchýlok od očakávaného stavu aplikácie. Spracovanie vstupov Referenčné bitmapy Testovacie bitmapy Konfiguračný JSON Áno NiePrvé spustenie alebo edit_mode Nastavenie regiónov Spracovanie testov Vizuálne testovanie OCR testovanie Spracovanie výsledkov Vizuálne spracovanie výsledkov Výstupný JSON Vstupný modul Testovací modul Výstupný modul Obr. 3.1: Návrh implementácie systému rozdeleného na vstupný, testovací a výstupný mo- dul. 3.1 Vstupný modul a spracovanie dát Tento modul predstavuje vstupný bod celého systému automatizovaného testovania GUI. Zodpovedá za načítanie, overenie a spracovanie vstupných dát vrátane testovacích scená- rov, referenčných výstupov a konfiguračných súborov. Na základe poskytnutej špecifikácie následne inicializuje potrebné komponenty a pripravuje ich na vykonanie testovacej logiky. 21 Vďaka centralizovanému prístupu k vstupom zabezpečuje jednotnosť, predvídateľnosť a mi- nimalizuje riziko nekonzistencií v ďalších fázach spracovania. Základnými vstupmi sú: • Referenčné bitmapy – reprezentuje očakávaný, správny stav GUI. • Testovacie bitmapy – výstupný snímok z aktuálneho behu testovanej aplikácie. • Konfiguračný súbor vo formáte JSON – obsahuje podrobné nastavenia testov, vrátane regiónov, typu testov a iných doplnkových atribútov. Konfiguračný JSON, zobrazený na obrázku 3.2, ktorý predstavuje základnú riadiacu jed- notku testovacieho procesu. Pre každý testovací prípad som definoval množinu testovacích regiónov, ktoré predstavujú špecifické oblasti GUI podliehajúce analýze. Každý región je definovaný ako dvojica súradníc – top_left a bottom_right, ktoré určujú jeho priestorové ohraničenie v podobe obdĺžnika. Okrem toho môže záznam obsahovať aj ďalšie doplnkové atribúty. Po načítaní konfigurácie systém automaticky vykreslí definované regióny nad testovacími bitmapami. Tento krok umožňuje používateľovi vizuálnu kontrolu nad tým, ktoré časti roz- hrania budú analyzované, čím sa zvyšuje transparentnosť celého procesu. Ak konfiguračný súbor pri prvom spustení chýba alebo ak v ňom absentujú regióny, systém automaticky prejde do tzv. editačného režimu (edit_mode), ktorý umožňuje ručné pridávanie, úpravu a odstraňovanie regiónov. Tento režim predstavuje používateľsky orientované rozhranie, v ktorom môže tester jed- noducho definovať požadované výrezy, a tým ovplyvniť, čo bude počas testovania vyhod- nocované. Regióny vytvorené počas tohto režimu sú následne uložené do konfiguračného súboru, ktorý je pripravený na opätovné použitie v ďalších cykloch testovania. V systéme sa rozlišujú dva hlavné typy regiónov: • OCR regióny – slúžia na extrakciu textu z bitmapy pomocou technológie optického rozpoznávania znakov. Výsledný text sa porovnáva s referenčným zápisom. • Testovacie regióny – sú vyhodnocované vizuálne, zvyčajne prostredníctvom po- rovnania s referenčnou bitmapou. Pri porovnávaní sa môže uplatniť viacero metód, ako napríklad metrika SSIM (angl. Structural Similarity Index), MSE (angl. Mean Squared Error) alebo priamo pixelové porovnanie. Tieto regióny sú využívané pre- dovšetkým na detekciu zmien v grafickej časti rozhrania, ako sú ikony, tlačidlá či vizuálne komponenty. Cieľom vstupného modulu je zabezpečiť jednotný a robustný vstupný formát pre ďalšie testovacie a výstupné moduly. Validáciou a predspracovaním dát sa minimalizuje riziko chýb počas vykonávania samotného testovania a zvyšuje sa celková spoľahlivosť a opakovateľnosť procesu. 22 Obr. 3.2: Ukážka konfiguračného súboru vo formáte JSON so zadefinovanými testovacími, OCR a zakázanými regiónmi. 3.2 Testovací modul Testovací modul predstavuje centrálnu komponentu systému, ktorá je zodpovedná za vy- hodnocovanie správnosti grafického používateľského rozhrania na základe vstupných bitmáp a údajov o testovacích regiónoch. Tento modul nadväzuje na vstupný modul, ktorý zabez- pečí načítanie a prípravu údajov a následne na ich základe spustí jednotlivé testy. Hlavnou úlohou testovacieho modulu je prevziať zoznam definovaných testovacích prí- padov z konfiguračného súboru, identifikovať všetky typy regiónov a na základe ich klasi- fikácie odovzdať spracovanie konkrétnym podmodulom. Modul tak zabezpečuje samotnú logiku testovania a koordináciu nad vykonávaním testov. Testovací modul som navrhol ako univerzálny riadiaci komponent, ktorý bude volaný pri každom spustení testovania – či už ide o úplné testovanie, testovanie vybraných regiónov alebo len opakovanie predchádzajúcich testov s upravenými parametrami (napr. visualmode alebo threshold). Pre správne fungovanie musí byť testovací modul nezávislý od konkrétnej testovacej techniky, pričom podrobnú implementáciu vyhodnocovania prenecháva samostat- ným podmodulom. Podmodul grafického testovania Grafické testovanie je vykonávané nad regiónmi typu Testing, ktoré reprezentujú oblasti GUI, kde sa očakáva presná vizuálna zhoda medzi referenčným a testovacím obrázkom. Podmodul pre grafické testovanie som navrhol tak, aby podporoval rôzne metódy porovná- vania, konkrétne priame pixelové porovnanie, SSIM, LPIPS a MSE. Podmodul najprv extrahuje výrezy zo vstupných bitmáp na základe súradníc regiónov a následne na nich aplikuje zvolenú porovnávaciu metódu. V prípade, že žiadne regióny typu Testing nie sú v konfigurácii zadané, predpokladá sa porovnanie celej bitmapy ako jedného celku. Výsledkom je číselné skóre podobnosti a rozhodnutie, či výrez (alebo celkový obraz) prešiel alebo zlyhal podľa nastaveného prahu. Bude tiež možné kombinovať viacero metrík 23 pre zvýšenie presnosti a spoľahlivosti rozhodovania v prípadoch, kde jednoduché porovnanie nestačí. Výstupom sú aj grafické informácie o rozdieloch, ktoré môžu byť použité v interaktívnej vizualizácii, ako aj súhrnné hodnotenia úspešnosti pre každý región. Podmodul OCR testovania OCR testovanie je realizované na regiónoch typu OCR. Cieľom tohto podmodulu je analyzo- vať obsah daných oblastí a získať z nich textové informácie pomocou technológie optického rozpoznávania znakov. Podmodul najprv zodpovedajúce výrezy predspracuje (napr. binarizáciou alebo norma- lizáciou kontrastu) a následne na ne aplikuje OCR algoritmus. Výsledný text sa potom porovnáva s očakávanými hodnotami. Zhoda môže byť stanovená buď ako presná textová zhoda alebo na základe prahovej podobnosti (napr. 90 %). OCR testovanie je navrhnuté ako doplnkové k bitmapovým metódam a umožňuje ove- renie dynamického alebo jazykovo lokalizovaného obsahu, ktorý sa nemusí dať spoľahlivo testovať pomocou vizuálneho porovnania. 3.3 Výstupný modul Výstupný modul predstavuje komponentu zodpovednú za spracovanie výsledkov testovania a ich uchovávanie vo formáte .json. Zároveň zabezpečuje vizuálnu reprezentáciu výsledkov testov, čo výrazne uľahčuje ich vyhodnocovanie a analýzu. Po ukončení každého testu sa vygeneruje výstupný záznam, ktorý obsahuje: • test_name – identifikátor testu, • status – celkové vyhodnotenie testu (napr. PASS, FAIL), • failed_regions – zoznam neúspešných regiónov, • tested_regions – zoznam vizuálne testovaných regiónov vrátane typu testu, • forbidden_regions – regióny, ktoré boli počas testovania zámerne vynechané z va- lidácie, • highlighted_image_path – cesta k obrázku s vizuálne vyznačenými rozdielmi pre celý test, • test_ocr_data a ref_ocr_data – testovacie a referenčné OCR výstupy obsahujúce zoznam textových reťazcov spolu s ich súradnicami, rozmermi a dôveryhodnosťou, • voliteľné pole forbidden – ktoré identifikujú, či bola chyba nájdena v regióne, ktorý sa nemá testovať. V prípade zistených rozdielov sú tieto vizuálne zvýraznené ako ohraničené oblasti priamo na výsledných obrázkoch. Ide o presné výrezy z testovaných snímok, kde bol rozpoznaný nesúlad medzi referenčným a testovacím stavom GUI. OCR výstupy sú rozdelené na referenčné a aktuálne testované texty a každý z nich obsahuje: 24 • rozpoznaný text (text), • pozíciu na obrázku (left, top), • rozmery (width, height), • hodnotu dôvery (conf), • voliteľné príznaky ako forbidden. Záverom testovania je teda komplexný výstupný súbor vo formáte .json, ktorý obsa- huje všetky potrebné informácie o vykonaných testoch. Tento výstup slúži nielen ako doku- mentačný záznam, ale aj ako vstup pre interaktívne vizualizačné rozhranie, ktoré zobrazí rozdiely priamo na obrázkoch – či už ide o textové odchýlky, zmeny v bitmapovej podobe alebo porušenia pravidiel v zakázaných regiónoch. Výstupný modul zabezpečuje uchovanie a vizualizáciu výsledkov, čím umožňuje efek- tívne a prehľadné vyhodnotenie testovacej procedúry. 25 Kapitola 4 Implementácia Táto kapitola popisuje samotnú realizáciu navrhnutého riešenia pre automatizované testova- nie grafického používateľského rozhrania. Zameriava sa na praktické prevedenie jednotlivých častí systému, ako aj na spôsob akým sa vykonáva testovanie vizuálnych a textových prvkov na základe bitmapových vzorov a optického rozpoznávania textu. 4.1 Vstupné dáta a spustenie systému Kľúčovou súčasťou vytvoreného systému na testovanie grafických používateľských rozhraní je skript bitmaptest.py, ktorý slúži ako hlavný vstupný bod. Tento skript som navrhol a implementoval tak, aby umožňoval efektívne a flexibilné spúšťanie testovacích scenárov prostredníctvom príkazového riadku. Systém pracuje s dvojicou vstupných súborov vo formáte .zip, pričom každý obsahuje sadu bitmapových obrázkov – jeden predstavuje referenčný (očakávaný) stav používateľ- ského rozhrania a druhý zachytáva výstupy z reálneho behu aplikácie. Ak je pri spustení systému zadaný iba jeden vstupný súbor, t. j. archív s referenčnými bitmapami systém automaticky extrahuje obrázky a vytvorí predvolený konfiguračný súbor config.json. V tomto kroku zároveň vygeneruje prednastavené testy bez toho, aby vyko- nával akékoľvek porovnanie. Ide teda o inicializačnú fázu, ktorá pripraví systém na ďalšie použitie. Po pridaní druhého súboru, ktorý obsahuje testovacie snímky, sa systém prepne do tes- tovacieho režimu. Porovnávanie prebieha na základe definovaných regiónov a konfigurácií zo súboru config.json. Dôležitým parametrom testovania je threshold, ktorého hodnotu je možné nastaviť ako percentuálnu mieru zhody medzi referenčnými a testovacími výrezmi. Tým sa určuje citlivosť, s akou systém vyhodnocuje rozdiely v grafickej podobe používateľ- ského rozhrania. Príklad spustenia Skript bitmaptest.py je možné spustiť niekoľkými spôsobmi podľa požadovanej funkciona- lity: • Inicializácia bez testovania: python3 bitmaptest.py reference.zip 26 Tento príkaz slúži na vytvorenie súboru config.json s prednastavenými regiónmi. • Základné testovanie s predvolenou konfiguráciou: python3 bitmaptest.py reference.zip test.zip Porovnáva výrezy z testovacích obrázkov voči referenčným na základe existujúcej konfigurácie. • Testovanie s vlastnou konfiguráciou: python3 bitmaptest.py config.json reference.zip test.zip Umožňuje načítať vlastný .json súbor s definovanými regiónmi a nastaveniami. Voliteľné parametre a rozšírenia Pre zvýšenie flexibility a prispôsobenie systému konkrétnym potrebám som doplnil podporu voliteľných parametrov: • threshold – definuje požadovanú mieru zhody (napr. threshold 90 zna- mená minimálne 90 % vizuálnej podobnosti). • visualmode precise/validated – prepína medzi prísnym pixelovým porovnávaním (ďalej precise) a tolerantnejším režimom (ďalej validated). • edit_mode – umožňuje interaktívne vybrať, ktoré testy budú vykonané. • edit_mode 1,3,5 – vykoná len testy s ID 1, 3 a 5. Funkcionalita searcharea Ako súčasť rozšírenia systému na základe požiadavky spolupracujúcej firmy som implemen- toval voliteľnú funkcionalitu searcharea. Táto funkcionalita umožňuje automatické vyhľa- dávanie textových výrazov v bitmapových snímkach pomocou implementovanej OCR. Používateľ môže zadať ľubovoľný zoznam kľúčových slov oddelených čiarkov, ktoré sys- tém následne deteguje a vizuálne zvýrazní priamo v testovanej oblasti. Táto vlastnosť je uži- točná najmä pri testovaní dynamického alebo lokalizovaného obsahu, kde by bežné vizuálne porovnanie zlyhávalo. Aktivuje sa pridaním kľúčového slova searcharea medzi parametre príkazového riadku. 4.2 Výber testovacích regiónov Presné určenie oblastí, ktoré majú byť podrobené testovaniu, predstavuje kľúčový krok pri validácii obrazových výstupov. Na tento účel som vyvinul a implementoval interaktívny nástroj umožňujúci manuálny výber obdĺžnikových regiónov priamo na vizualizovanom ob- rázku. Tento nástroj, ktorý je implementovaný ako súčasť modulu region_selector.py, umožňuje používateľovi intuitívne definovať testovacie oblasti, a tým výrazne zvyšuje pres- nosť a kontrolu nad priebehom analýzy. 27 Technické riešenie nástroja Pri vývoji nástroja som pôvodne experimentoval s využitím knižnice pygame, ktorá umož- ňuje efektívnu prácu s grafickými udalosťami. Počas testovania sa však ukázalo, že samotné vykresľovanie regiónov prostredníctvom tejto knižnice nie je dostatočne plynulé, čo spôso- bovalo oneskorenia pri zobrazovaní väčšieho množstva interakcií. Z tohto dôvodu som v riešení použil kombináciu knižníc OpenCV (cv2) a pygame. OpenCV zabezpečuje samotné vykresľovanie a zobrazovanie obrázkov vrátane regiónov, zatiaľ čo pygame je využívaný na precíznu detekciu časovania udalostí ako je napríklad dvojklik myšou. Zachytenie vstupných akcií používateľa Interakcia používateľa so systémom som realizoval prostredníctvom myši a klávesnice. Na jej základe je možné nielen vytvárať nové testovacie oblasti, ale aj modifikovať už existujúce re- gióny. Na spracovanie týchto vstupov som implementoval funkciu handle_mouse_events(), ktorá zabezpečuje spracovanie udalostí ako je kliknutie, pohyb alebo dvojklik myšou. Základný mechanizmus spočíva v zaznamenaní počiatočného bodu výberu po kliknutí, aktualizácii jeho súradníc počas ťahania myšou a vo finalizácii výberu po uvoľnení tlačidla. Týmto spôsobom sa definuje nový obdĺžnikový región. Špecifickou funkcionalitou je podpora dvojkliku pre regióny typu OCR, ktorý aktivuje interaktívne pole na zadanie alebo úpravu zoznamu aliasov. Nasledujúca ukážka predstavuje zjednodušený fragment uvedenej funkcie, zachytávajúci základné interakcie používateľa: def handle_mouse_events(event, x, y, flags, param): if event == cv2.EVENT_LBUTTONDOWN: now = time.time() # Detekcia dvojkliku pre úpravu aliasov existujúcich regiónov if now - last_click_time[0] < 0.4: for region in regions_ocr: if is_point_on_border(x, y, region): aliases = prompt_alias_input_overlay( ", ".join(region.get("aliases", {}).get("texts", []))) region["aliases"] = { "active": True, "aliases_texts": [a.strip() for a in aliases.split(",")] }return # Spustenie kreslenia nového regiónu last_click_time[0] = now rect_start[0] = rect_end[0] = (x, y) dragging[0] = True elif event == cv2.EVENT_MOUSEMOVE and dragging[0]: # Dynamická aktualizácia koncového bodu počas ťahania rect_end[0] = (x, y) elif event == cv2.EVENT_LBUTTONUP and dragging[0]: # Po uvoľnení myši sa región uloží do zoznamu (iba v OCR režime) if current_mode[0] == "OCR": regions_ocr.append({ "top_left": list(rect_start[0]), "bottom_right": list(rect_end[0]) }) dragging[0] = False 28 Každý región je možné presúvať, mazať alebo opätovne upravovať bez obmedzenia ich prekrytia. Regióny je teda možné kresliť aj cez seba, čo zvyšuje flexibilitu pri práci so zložitejšími obrazovkami. Na farebné zvýraznenie a popis jednotlivých typov regiónov som použil metódy knižnice cv2, v kombinácii s identifikáciou podľa aktuálneho režimu (napr. OCR, Visual, Forbidden). Typy regiónov V rámci interaktívneho nástroja som pôvodne navrhol a implementoval štyri rôzne typy testovacích regiónov. Tie som rozdelil do dvoch hlavných kategórií: základné regióny a roz- šírené regióny. Základné regióny predstavujú kľúčovú funkcionalitu systému – konkrétne vizuálne porovnávanie a rozpoznávanie textu. Následne som na základe konzultácií s firmou rozšíril funkcionalitu o ďalšie dva typy regiónov forbidden a aliases, ktoré zohľadňovali požiadavky reálneho testovania v praxi. Po ďalšom vyhodnotení používateľskej skúsenosti som sa rozhodol, že samostatný typ regiónu určený pre alternatívne textové výrazy môže znižovať prehľadnosť a komplikovať používateľské rozhranie. Preto som pristúpil k úprave návrhu a to tak, že som funkcionalitu aliasov integroval priamo do existujúcich OCR regiónov. Prehľad implementovaných typov regiónov a ich zobrazenie v grafickom používateľskom rozhraní ilustruje obrázok 4.1. Základné typy regiónov • OCR regióny – oblasti určené na extrakciu a porovnanie textu pomocou optického rozpoznávania znakov. Používajú sa najmä na overenie textového výstupu aplikácie. Od určitého bodu vývoja zároveň podporujú definovanie aliasov – alternatívnych tex- tových reťazcov, ktoré sú pri porovnávaní akceptované ako správne. • Testing regióny – regióny pre vizuálne porovnanie medzi referenčnou a testovacou bitmapou. Tento typ regiónu slúži na detekciu grafických zmien v používateľskom rozhraní. Rozšírený typ regiónu • Forbidden regióny – špeciálne regióny, ktoré sú zo samotného testovania zámerne vylúčené. Ich cieľom je eliminovať falošné pozitíva v oblastiach obsahujúcich dyna- mické údaje (napr. aktuálny dátum, čas, notifikácie). 29 Obr. 4.1: Ukážka používateľského rozhrania nástroja na výber regiónov. Zobrazené sú všetky implementované typy regiónov: základné regióny Visual (zelená) a OCR (modrá), ako aj roz- šírený typ Forbidden (fialová). V prípade OCR regiónov je možné zadať alternatívne tex- tové varianty, ako vidno v dolnej časti obrázku. Každý región je vizuálne zvýraznený a pod- poruje interakciu podľa aktuálne zvoleného režimu. Používateľské rozhranie a ovládanie Interaktívne používateľské rozhranie umožňuje vizuálne vytvárať, upravovať a mazať jednot- livé regióny. Používateľ môže prepínať medzi typmi regiónov pomocou klávesových skratiek: O pre OCR, T pre Testing a F pre Forbidden. Celé rozhranie aj so zobrazením ovládacích prvkov je ilustrované na obrázku 4.2. Nový región sa vytvára potiahnutím myši, pričom sa okamžite zobrazuje jeho typ aj ohraničenie priamo na obrazovke. Funkcionalitu aliasov som navrhol ako rozšírenie existujúcich OCR regiónov, bez po- treby zavádzať samostatný typ regiónu. Tento prístup zjednodušuje ovládanie a zároveň zvyšuje čitateľnosť celého rozhrania. Aliasové výrazy je možné zadať alebo upraviť dvojkli- kom na existujúci OCR región, čím sa otvorí vstupné pole na zadanie požadovaných texto- vých variantov. Tieto hodnoty sa ukladajú spolu s definíciou oblasti a používajú sa pri po- rovnávaní výstupu z OCR analýzy. 30 Interakcia a možnosti úprav Používateľ má možnosť označené regióny: • presúvať – chytením a ťahaním regiónu myšou, • odstrániť – klávesou D, • vymazať všetky regióny – klávesou R, • potvrdiť výber – klávesou Enter, • zrušiť proces – klávesou Q. Obr. 4.2: Zobrazenie používateľského rozhrania nástroja pri výbere regiónov. V hornej časti obrazovky sa nachádza informačný panel s popisom ovládacích kláves. Tento panel slúži ako vizuálna pomôcka počas interakcie so systémom. 4.3 Riadiaci modul testovacieho systému Centrálnym prvkom navrhnutého systému je modul process_testing.py, ktorý som na- vrhol ako hlavný riadiaci komponent zodpovedný za koordináciu všetkých činností súvisia- cich s testovaním. Tento modul zabezpečuje logické riadenie celého procesu od načítania testovacej konfigurácie cez vyhodnotenie jednotlivých testovacích scenárov až po dynamické rozhodovanie o tom, aké typy testovania sa majú v danom prípade vykonať. Architektúra a funkcionalita Na začiatku testovania sa spúšťa funkcia process_testing, ktorá načíta konfiguračný JSON súbor a postupne spracúva všetky testovacie prípady. Každý z týchto prípadov je spracovaný samostatne pomocou funkcie process_single_test, čím som dosiahol lepšiu modularitu a oddelenie zodpovednosti. Modul zároveň predspracováva štruktúry ako zakázané oblasti alebo aliasové výrazy, ktoré sú kľúčové pre presné testovanie. 31 Riadenie priebehu testu V prípade každého testu dochádza k načítaniu referenčného a testovacieho obrázka, pričom na tento účel používam knižnicu OpenCV. Po zabezpečení správneho formátu obrázkov a ich farebnej reprezentácie sa systém rozhoduje, ktoré typy testovania majú byť vykonané. Túto logiku som navrhol tak, aby bolo možné testy vykonávať kombinovane podľa toho, aké regióny sú pre daný test definované. Rozhodovací mechanizmus zjednodušene znázorňuje nasledovný fragment kódu: if not has_regions_testing and not has_regions_ocr: # Ak nie sú definované žiadne oblasti na testovanie ani na OCR, # vykoná sa úplný test obrazu aj úplný OCR test nad celým obrázkom. run_full_image_test = True run_full_ocr_test = True elif has_regions_ocr and not has_regions_testing: # Ak sú definované iba OCR oblasti, ale nie oblasti pre vizuálne testovanie, # vykoná sa úplný test obrazu, ale OCR test len v definovaných oblastiach. run_full_image_test = True run_full_ocr_test = False elif has_regions_testing and not has_regions_ocr: # Ak sú definované iba oblasti pre vizuálne testovanie, ale nie pre OCR, # vykoná sa OCR test nad celým obrázkom, ale vizuálny test len v oblastiach. run_full_image_test = False run_full_ocr_test = True else: # Ak sú definované oblasti pre oba typy testovania, # žiadny test sa nevykonáva nad celým obrázkom, oba prebehnú len v regiónoch. run_full_image_test = False run_full_ocr_test = False Priebeh testovania Pri spracovaní každej testovacej úlohy najskôr zisťujem, aké typy regiónov sú pre daný prípad definované. Na základe tejto informácie rozhodujem o tom, či sa má vykonať vizuálne testovanie, testovanie pomocou optického rozpoznávania znakov, alebo obidve časti. Tento rozhodovací proces je znázornený na obrázku 4.3, ktorý schematicky sumarizuje vetvenie logiky spracovania v závislosti od dostupných vstupov. Ak sú v testovaní prítomné vizuálne regióny volám funckiu run_region_testing, ktorá zabezpečuje porovnanie obsahu medzi referenčným a testovacím obrázkom. Porovnanie pre- bieha po jednotlivých regiónoch a výsledky každého z nich sú spracované samostatne. Bližšie je táto funkcia popísaná v sekcií 4.4. V prípade, že sú definované OCR regióny volám funkciu run_region_ocr, ktorá naj- skôr extrahuje príslušnú oblasť obrázka, aplikuje OCR rozpoznávanie a následne porovná výsledné texty medzi referenčnou a testovanou snímkou. Bližšie je táto funkcia popísaná v sekcií 4.5. Ak testovacia úloha neobsahuje žiadne regióny alebo je zadaný len jeden typ (napríklad len OCR bez vizuálneho porovnania), systém automaticky dopĺňa celoplošné testovanie. V takomto prípade vykonávam porovnanie celého obrázka a to ako z pohľadu vzhľadu, tak aj z hľadiska obsahu rozpoznaného textu. Po vykonaní testov vytváram štruktúrovaný výstup, ktorý obsahuje stav každého re- giónu, informáciu o úspechu alebo zlyhaní, cestu k zvýraznenému obrázku a podrobnosti 32 o nájdených rozdieloch. Ak je výsledkom testovania nezhoda, generujem výstupný obrázok s vizuálnym zvýraznením problémového miesta a priraďujem ho k výsledkom testu. Všetky dáta sú následne uložené do výstupného JSON súboru. Po spracovaní všetkých testovacích prípadov zobrazujem výsledky pomocou interaktív- neho výstupu. V rámci tejto časti používam funkciu interactive_reveal, ktorá je bližšie popísaná v sekcií 4.6. Vstup nového testu Nie Má test dané regióny? Áno Testovanie celej bitmapy podľa typu testu (OCR/Vizuálny) Nie Má test vizuálne regióny? Testovanie vizuálnych regiónov Áno Nie Má test OCR regióny? Testovanie OCR regiónov Áno Nie Áno Bola nájdená chyba? Vytvorenie bitmapy s rozdielmi a pridanie chyby do výstupného JSON súboru Obr. 4.3: Vývojový diagram spracovania testu. Zobrazuje rozhodovanie podľa typu defino- vaných regiónov a výsledok testovania s výstupom do JSON súboru. 4.4 Modul vizuálneho testovania Modul vizuálneho testovania tvorí základnú súčasť navrhnutého systému. Jeho úlohou je de- tekovať zmeny medzi referenčným a testovaným obrazom a to na úrovni celku alebo v rámci presne definovaných oblastí. Pri návrhu a implementácii som kládol dôraz na presnosť vý- stupov, elimináciu falošných detekcií, efektivitu spracovania a možnosť rozšíriteľnosti. Z pohľadu architektúry som modul rozčlenil do dvoch častí. Prvú predstavuje podmo- dul visual_testing.py, ktorý obsahuje implementácie samotných porovnávacích metód. Druhú časť tvorí podmodul process_visual_testing.py, v ktorom spracúvam jednot- livé regióny, aplikujem filtráciu zakázaných oblastí, spájam výsledky a zabezpečujem ich vizualizáciu. Základná funkcionalita Všetky porovnania sú realizované pomocou funkcie region_testing, ktorú som navrhol tak, aby podporovala ako regionálne testovanie, tak aj porovnanie celej bitmapy. Funkcia prijíma referenčný a testovací obrázok, zoznam regiónov (alebo prepínač pre celé zobraze- nie), zoznam zakázaných oblastí a parameter určujúci zvolený režim testovania. Počas spracovania regiónov extrahujem príslušné výrezy z oboch obrázkov, vykonávam ich porovnanie a výsledné odlišnosti následne analyzujem. Zohľadňujem pritom aj zakázané 33 oblasti, ktoré dynamicky upravujem vzhľadom na pozíciu konkrétneho regiónu. Výstupom je zoznam rozpoznaných rozdielov s globálnymi súradnicami a voliteľne aj zvýraznený ob- razový výstup. Režimy porovnávania V úvodnej fáze vývoja som implementoval základný režim porovnávania založený na pria- mom porovnaní hodnôt jednotlivých pixelov. Tento prístup poskytoval maximálnu presnosť, no v praxi sa ukázal ako príliš citlivý na drobné odchýlky, ktoré by bežný používateľ vizuálne vôbec nezaznamenal. Išlo najmä o minimálne posuny, rozdiely v tieňovaní alebo artefakty spôsobené kompresiou. Na základe tejto skúsenosti a po konzultácii s firmou som navrhol druhý, tolerantnejší režim porovnávania, ktorý zohľadňuje vizuálnu vnímateľnosť rozdielov z pohľadu použí- vateľa. Výsledkom sú dva režimy porovnávania, ktoré sa líšia v miere prísnosti a spôsobe analýzy: • Precise režim: vykonáva striktne pixelové porovnanie. Každá odchýlka medzi zod- povedajúcimi pixelmi je považovaná za relevantný rozdiel. Tento režim je vhodný najmä tam, kde sa očakáva úplná zhoda medzi obrázkami (napríklad pri testovaní statických komponentov bez dynamických prvkov). • Validated režim: je založený na kombinácii viacerých metrík a umožňuje filtrovať nepodstatné rozdiely, ktoré by neboli postrehnuteľné ľudským okom. Tento režim som navrhol ako predvolený pre bežné testovanie, pretože poskytuje spoľahlivé výsledky bez preťaženia výstupu falošnými nálezmi. Praktický rozdiel medzi oboma režimami znázorňuje obrázok 4.4, kde som pre účely testovania zámerne mierne posunul a zmenšil graf výdavkov oproti referenčnej bitmape, aby bolo možné pozorovať, ako jednotlivé režimy reagujú na jemné vizuálne odchýlky. Precise režim Precízne porovnanie realizujem na úrovni jednotlivých pixelov. Porovnávanie prebieha sa- mostatne pre každú farebnú zložku (R, G, B). Výsledkom je binárna maska, v ktorej sú za- znamenané všetky odlišné pixely. Tieto pixely následne zoskupujem do kontúr, z ktorých vytváram ohraničené oblasti. Príklad výpočtu: diff = np.abs(img1.astype(np.int16) - img2.astype(np.int16)) diff_mask = np.any(diff > 0, axis=2) Takto získané oblasti ďalej spracúvam, spájam ich do väčších celkov a následne analy- zujem ich význam. Validated režim Validated režim som koncipoval ako robustnejšiu alternatívu, ktorá kombinuje viacero po- hľadov na rozdiel medzi obrazmi. Využívam tri metriky: • SSIM – určuje štruktúrnu podobnosť medzi obrázkami, pričom zohľadňuje kontrast, jas a detaily. 34 • LPIPS – používa hlboké neurónové siete na hodnotenie vizuálnej podobnosti z po- hľadu ľudského vnímania. • MSE – klasická metrika založená na priemernej kvadratickej chybe pixelov. Rozdiel považujem za relevantný iba vtedy, ak aspoň dve z troch metrík prekročia stanovené prahové hodnoty. Táto kombinovaná schéma pomáha zachytiť podstatné rozdiely a zároveň ignorovať vizuálne zanedbateľné zmeny. Ukážka rozhodovacieho mechanizmu: if sim < 0.60: failed += 1 if lpips_score > 0.20: failed += 1 if mse_score > 3500: failed += 1 if failed >= 2: validated_regions.append(region) Adaptácia prahových hodnôt metrík Pri návrhu systému som narazil na výrazné rozdiely medzi hodnotami metrík popisovanými v literatúre a výsledkami nameranými počas reálneho testovania. Napríklad pri metrikách založených na priemernej kvadratickej chybe (MSE) som zaznamenal hodnoty presahujúce 5000, čo výrazne prevyšuje odporúčané prahy, ktoré sa pri štandardizovaných datasetoch bežne pohybujú v rozsahu do 50. Tento nesúlad bol spôsobený predovšetkým: • odlišnou veľkosťou analyzovaných regiónov (často veľmi malé výrezy), • prítomnosťou ostrých pixelových kontrastov v grafických komponentoch GUI, • a dôrazom na vysokú presnosť pri testovaní dynamicky generovaných rozhraní. Z uvedených dôvodov som sa rozhodol pre prístup tzv. lokálneho škálovania metrík, teda stanovenia prahových hodnôt nie na základe absolútnych literárnych odporúčaní, ale na základe reálneho správania metrík v prostredí konkrétnych bitmapových testovacích prí- padov. Výsledné prahy, ktoré lepšie reflektujú charakteristiky testovaných aplikácií, suma- rizuje tabuľka 4.1. Tento prístup je v súlade s odporúčaniami z literatúry, ktorá zdôrazňuje potrebu prispôsobiť posudzovanie kvality obrazu konkrétnemu typu dát a aplikácie [30]. Metrika Rozsah hodnôt Malá chyba Veľká chyba MSE [0,∞) < 2000 > 3500 SSIM [−1, 1] > 0,90 < 0,60 LPIPS [0, 1] < 0,05 > 0,20 Tabuľka 4.1: Prispôsobené prahové hodnoty metrík na základe reálne nameraných výsled- kov. 35 Obr. 4.4: Porovnanie výstupu pri vizuálnom testovaní: na ľavo je výstup v režime validated, ktorý zvýrazňuje len vizuálne významné rozdiely. Vpravo je výstup z re- žimu precise, ktorý zaznamenáva všetky pixelové odchýlky. Na obrázku je viditeľné,že validated režim ignoruje drobné odchýlky, ktoré nie sú postrehnuteľné ľudským okom, zatiaľ čo precise režim ich zvýrazní ako rozdiel. Spracovanie zakázaných oblastí Zakázané oblasti predstavujú špecifické výrezy (napr. čas, dátum), v ktorých môže dochá- dzať k očakávaným zmenám. Počas testovania ich automaticky prispôsobujem aktuálne analyzovanému regiónu. V prípade, že rozpoznaný rozdiel spadá výhradne do zakázanej oblasti, ignorujem ho. Implementáciu tejto logiky ilustruje nasledujúca ukážka: # Prechádzam všetky zakázané oblasti for forbidden in adjusted_forbidden_regions: # Overujem, či je cieľová oblasť (dx1, dy1, dx2, dy2) # úplne zahrnutá v zakázanej oblasti (fx1, fy1, fx2, fy2) if fx1 <= dx1 and fy1 <= dy1 and fx2 >= dx2 and fy2 >= dy2: # Ak áno, označíme túto oblasť na ignorovanie ignore = True Tento spôsob zabezpečuje, že do výsledkov vstupujú len relevantné rozdiely a nevznikajú falošné poplachy v oblastiach s dynamickým obsahom. 36 Zvýraznenie výsledkov a výstup Každý výstupný rozdiel je voliteľne vizualizovaný. Na tento účel som vytvoril funkciu highlight_differences, ktorá zobrazuje rozdiely formou červených rámčekov v testova- com obrázku. Tento obrazový výstup je následne uložený a prehľadne priradený k výsledku testu. Slúži ako podklad pre interaktívne vyhodnotenie, ktoré opisujem v kapitole 4.6. 4.5 Modul OCR testovania Pre automatizované overovanie textového obsahu vo vizuálnych komponentoch som navrhol samostatný modul na báze optického rozpoznávania znakov. Jeho hlavným cieľom je spoľah- livé porovnanie textov medzi referenčnými a testovanými obrazmi s dôrazom na robustnosť voči malým vizuálnym rozdielom, rôznym fontom a dynamickým častiam používateľského rozhrania. Výber OCR knižnice a predspracovanie Na začiatku som implementoval riešenie založené na knižnici pytesseract, ktorá predsta- vuje pythonovské rozhranie pre otvorený nástroj Tesseract OCR. Výber tejto knižnice bol motivovaný najmä jej širokou dostupnosťou, otvorenou licenciou a relatívne jednoduchou integráciou s ďalšími nástrojmi ekosystému Pythonu, ako je napríklad knižnica OpenCV. Vďaka tomu bolo možné veľmi rýchlo vytvoriť funkčný prototyp OCR modulu s minimál- nou úrovňou technickej náročnosti a bez potreby externého trénovania modelov. V praxi sa však ukázalo, že hoci Pytesseract dokáže rozpoznať základné textové ob- lasti, jeho presnosť pri spracovaní reálnych bitmapových vstupov s rôznou kvalitou a typo- grafiou je obmedzená. Výstupy boli často nedostatočné najmä v prípadoch, keď bitmapy obsahovali menšie fonty, slabý kontrast medzi textom a pozadím alebo netypické formáto- vanie znakov. OCR engine mal výrazné problémy najmä pri číselných údajoch – zamieňal znaky ako „O“ a „0“, „1“ a „l“, v niektorých prípadoch úplne vynechával jednotlivé znaky, alebo spájal viacero slov do jedného výrazu bez medzier. Tieto chyby významne narúšali možnosť spoľahlivého porovnania výsledného textu s referenčnými hodnotami, čo viedlo k mnohým falošne negatívnym výsledkom testov. Na obrázku 4.5 je zachytený konkrétny príklad reálneho výstupu získaného pomo- cou Pytesseract. Viditeľné sú vynechané znaky, nesprávne rozpoznané číslice, ako aj zle identifikované alebo zle rozdelené textové bloky. Tieto nedostatky jednoznačne pouka- zujú na potrebu robustnejšieho riešenia, ktoré bude schopné poskytovať konzistentné vý- sledky aj pri menej ideálnych bitmapových vstupoch. 37 Obr. 4.5: Naľavo sa nachádza predspracovaná bitmapa pripravená na OCR. Na pravej strane je výstup z knižnice Pytesseract, ktorý demonštruje nízku presnosť rozpoznávania. Vidi- teľné sú vynechané znaky, nesprávne rozpoznané číslice a chybné identifikované textové časti. Na základe týchto zistení som sa rozhodol prejsť na modernejšie riešenie – knižnicu EasyOCR, ktorá využíva hlboké neurónové siete a poskytuje výrazne lepšie výsledky najmä pri zložitejších fontoch, viacjazyčných textoch a grafických rozhraniach. Knižnicu som ini- cializoval s podporou slovenského, českého a anglického jazyka: reader = easyocr.Reader([’sk’, ’cs’, ’en’], gpu=True) EasyOCR umožňuje rozpoznávanie z farebného alebo šedotónového obrazu bez nutnosti binarizácie. Každý výstup obsahuje okrem samotného textu aj jeho súradnicové ohraničenie a hodnotu dôvery. Základné rozpoznanie vykonávam nasledovne: results = reader.readtext(image, detail=1) Použitie parametra detail=1 zabezpečí, že výsledkom nie je len zoznam textov, ale kompletná informácia o každom zachytenom úseku. Každá položka výstupu má formát tro- jice (bbox, text, confidence), kde bbox predstavuje štyri rohové body vyhodnoteného boxu, text je rozpoznaný reťazec a confidence číselná hodnota vyjadrujúca dôveru mo- delu v správnosť rozpoznania. Táto štruktúra mi umožňuje následné presné zvýraznenie, filtrovanie a analýzu výsledkov. V prípade, že by som použil detail=0, výstupom by bol len jednoduchý zoznam roz- poznaných textov bez akýchkoľvek priestorových informácií či metadát, čo by znemožnilo ich vizualizáciu či presné porovnanie. Z tohto dôvodu používam výhradne režim detail=1. 38 Dôveryhodnosť a opätovné skenovanie Každé rozpoznané slovo obsahuje okrem textu aj súradnicový box a hodnotu dôvery. Slová s dôverou nižšou ako vopred definovaný prah (50 %) som označil na sekundárne spracovanie. Zvolený prístup zabezpečuje vyššiu presnosť rozpoznávania: if conf * 100 < CONFIDENCE_THRESHOLD: # označím pre rescan Z regiónov s nízkou dôverou vytvorím výrez, ktorý zväčším a opätovne analyzujem pomocou EasyOCR. Ak výsledok spĺňa požiadavku na dôveru, nahradím pôvodný výstup novým. CONFIDENCE_THRESHOLD = 50 low_confidence_entries = [] for (bbox, text, conf) in results: if conf * 100 < CONFIDENCE_THRESHOLD: low_confidence_entries.append((bbox, text, conf)) # Rescan výrezov s nízkou dôverou for (bbox, _, _) in low_confidence_entries: (top_left, _, bottom_right, _) = bbox x, y = int(top_left[0]), int(top_left[1]) w = int(bottom_right[0] - top_left[0]) h = int(bottom_right[1] - top_left[1]) cropped = image[y:y+h, x:x+w] upscaled = cv2.resize(cropped, None, fx=2.0, fy=2.0) rescanned = reader.readtext(upscaled) Výsledok tejto techniky je výrazne lepší, čo ilustruje nasledujúci obrázok s výstupom z EasyOCR v prílohe A. Zakázané oblasti (forbidden regions) Niektoré oblasti obrazov obsahujú dynamický obsah ako dátumy, časy alebo identifikátory, ktoré sa prirodzene menia a nemajú byť predmetom analýzy. Takéto oblasti som definoval ako zakázané a pri porovnávaní ich explicitne ignorujem. Počas spracovania kontrolujem, či sa rozpoznaný text nachádza celý v niektorej zaká- zanej oblasti. Ak áno, označím ho ako irelevantný a nezapočítavam ho medzi rozdiely: if x >= rx1 and y >= ry1 and (x + w) <= rx2 and (y + h) <= ry2: continue # ignorujem Súradnice zakázaných oblastí sa dynamicky upravujú podľa pozície analyzovaného re- giónu (napr. ak ide o porovnávanie len určitej časti obrazovky). Podpora aliasov Niektoré textové oblasti môžu mať legitímne variácie – napríklad rôzne skratky, lokalizované názvy dní, meny alebo iný formát čísel. Preto som do systému pridal možnosť definovať tzv. textové aliasy. Každému regiónu je možné priradiť zoznam očakávaných aliasov, ktoré sa porovnávajú s rozpoznaným textom pomocou textovej podobnosti. Ak podobnosť prekročí prah (napr. 0.8), text sa považuje za akceptovateľný: similarity = SequenceMatcher(None, alias.lower(), test_text.lower()).ratio() 39 if similarity >= threshold: return True # nájdený alias Táto funkcionalita znižuje počet falošných rozdielov v prípadoch, kde sa očakávajú va- riácie, čím sa výrazne zvyšuje použiteľnosť modulu v dynamických systémoch. Zvýraznenie výsledkov Pre každé porovnanie môžem voliteľne vizualizovať výsledky priamo v testovanom obrázku, ktorý je zobrazený v prílohe A. Implementoval som farebné zvýraznenie: červené regióny pre rozdiely, zelené pre zhody a žlté pre aliasy. Takto vzniknutý výstup slúži ako podklad pre manuálnu validáciu: cv2.rectangle(highlighted, (x, y), (x + w, y + h), color, 2) Okrem obrazového výstupu vraciam aj rozšírenú dátovú štruktúru uloženú do JSON súboru, ktorá obsahuje príznaky pre aliasy a zakázané oblasti. Príklad takejto internej reprezentácie možno vidieť na obrázku 4.6. Obr. 4.6: Ukážka vnútornej dátovej štruktúry test_ocr_data, ktorá uchováva výsledky OCR spracovania. Obsahuje rozpoznané texty a ich súradnicové informácie (left, top, width, height), dôveryhodnosť rozpoznania (conf) a doplňujúce atribúty ako alias a forbidden, ktoré slúžia na špecifické spracovanie počas porovnávania. 4.6 Interaktívny výstup a zobrazenie výsledkov Na zjednodušenie analýzy výsledkov vizuálneho a OCR testovania som vytvoril dva samos- tatné výstupné moduly – jeden určený na konzolový výpis a druhý na interaktívnu vizuali- záciu výsledkov. Každý z nich pokrýva odlišné potreby, zatiaľ čo show_results.py posky- tuje štruktúrované súhrny testov pre potreby reportingu, modul interactive_reveal.py umožňuje podrobnú vizuálnu kontrolu odhalených rozdielov formou interaktívneho rozhra- nia, zobrazeného na obrázku 4.7. Modul interaktívneho výstupu Tento modul predstavuje kľúčový nástroj pre interaktívne vizuálne odhalenie rozdielov me- dzi referenčným a testovaným obrazom. Vychádza z princípu posuvnej deliacej línie, ktorú môže používateľ ovládať myšou a ktorá odhaľuje obsah testovacieho obrazu postupným presúvaním zľava doprava. Na začiatku je zobrazený celý referenčný obrázok. Akonáhle používateľ začne posúvať vertikálnu líniu doprava do oblasti naľavo od tejto línie sa začne dynamicky vkladať zod- 40 povedajúca časť testovacieho obrázku. Pravá časť obrazu pritom ostáva referenčná, čím vzniká prirodzený a plynulý prechod medzi oboma verziami. Táto forma prezentácie umož- ňuje okamžité vizuálne porovnanie a rýchlu detekciu zmien priamo v kontexte ich výskytu. Rozdiely sú zvýraznené pomocou farebne odlíšených regiónov, ktoré sú doplnené o tex- tové popisky priamo v obraze. Zvolená farebná schéma je konzistentná s ostatnými modulmi systému: • Červené regióny: OCR rozdiely (zaznamenané mimo zakázaných oblastí a mimo aliasov), • Žlté regióny: prípady, kde bol textový rozdiel označený ako alias (t. j. akceptovateľná variácia), • Modré regióny: vizuálne (pixelové) rozdiely vyhodnotené v presnom alebo tolerant- nom režime, • Zelené regióny: výskyty hľadaných výrazov definovaných v testovacom scenári. Vizualizačné prvky a spracovanie kolízií Pre zvýšenie čitateľnosti výstupu som zaviedol viacero doplnkových mechanizmov: • Stmavovanie testovacieho obrazu: časti testovacieho obrazu, ktoré sú aktuálne prekryté, sú zobrazené so zníženým jasom (napr. alpha=0.5). • Posun prekrývajúcich sa oblastí: ak sa viacero rozdielov nachádza na identickej pozícii, algoritmus ich mierne odsunie (shift_pixels=3) tak, aby boli všetky oblasti viditeľné. • Textové popisky s pozadím: každý typ zvýraznenej oblasti je doplnený o štítok (napr. OCR, Alias, Pixel), ktorý sa zobrazí nad alebo pod regiónom. Posúvanie deliacej línie a celkové interaktívne správanie je realizované prostredníctvom spracovania udalostí myši. Základnú obsluhu týchto vstupov zabezpečuje nasledujúca fun- kcia: def on_mouse(event, x, y, flags, param): # ak je stlačené ľavé tlačidlo, aktivujem režim ťahania a nastavím počiatočnú pozíciu if event == cv2.EVENT_LBUTTONDOWN: dragging[0] = True line_pos[0] = x draw_image(x) # Počas pohybu myši so stlačeným tlačidlom aktualizujem pozíciu línie elif event == cv2.EVENT_MOUSEMOVE and dragging[0]: line_pos[0] = x draw_image(x) # Po uvoľnení tlačidla myši deaktivujem režim ťahania elif event == cv2.EVENT_LBUTTONUP: dragging[0] = False Funkcia draw_image(pos) následne vykreslí celý obraz v závislosti od pozície deliacej línie a rozhodne, ktoré vrstvy (referenčná alebo testovacia) majú byť zobrazené. 41 Obr. 4.7: Ukážka interaktívneho porovnávania. Pravá strana zobrazuje pôvodný referenčný obrázok, zatiaľ čo ľavá časť (od deliacej línie) odhaľuje testovaný obraz spolu so zvýrazne- nými rozdielmi. Červené regiony označujú textové (OCR) odchýlky, modré regióny repre- zentujú vizuálne rozdiely na úrovni pixelov. Textová sumarizácia výsledkov Pre prípady kedy nie je možné využiť vizuálny výstup z interaktívneho modulu (napríklad v prostredí bez grafického rozhrania), som vytvoril príkazový nástroj show_results.py. Tento skript slúži na načítanie a textové spracovanie výsledkov z testovania, ktoré sú uložené vo formáte JSON. Po spustení nástroja sa automaticky vyhľadá prvý dostupný výstupný súbor v zada- nom priečinku a následne sa z neho extrahujú všetky údaje o testoch. Výstup je rozdelený do dvoch častí: • Detailný výpis testov: pre každý test sa zobrazí názov, stav, analyzované regi- óny (vizuálne aj OCR) a informácia o tom, či konkrétny región testom prešiel alebo neprešiel. Príklad takéhoto detailného výpisu je znázornený na obrázku 4.8. • Zhrnutie: agregovaný prehľad všetkých testov s počtom úspešných a neúspešných, vrátane celkového súhrnu pre OCR, vizuálne a testy celej bitmapy, ako je viditeľné na obrázku 4.9. 42 Obr. 4.8: Výpis jedného konkrétneho testu z modulu. Zobrazený test test_3 obsahuje dve testované oblasti typu Visual Test a jeden typu OCR Test. Každý analyzovaný región je priradený ku konkrétnemu typu: • OCR Test – textový porovnávací test, • Classic Test – vizuálne (pixelové) porovnanie regiónu, • Full Image / Full OCR – test celej obrazovej plochy. Na formátovanie výstupu slúži knižnica tabulate, ktorá zabezpečuje prehľadnú tabuľ- kovú prezentáciu údajov priamo v konzole. Obr. 4.9: Súhrnný výpis všetkých vykonaných testov. Každý riadok reprezentuje jeden test, pričom v stĺpcoch sú uvedené informácie o stave testu, identifikačné číslo úspešných a neúspešných regiónov (OCR aj vizuálnych), ako aj zhrnutie. 43 Kapitola 5 Testovanie V rámci testovania vyvinutého nástroja som vykonal testy na 28 testovacích scenárov, ktoré pokrývali približne 252 testovacích bitmáp. Cieľom testovania bolo overiť schopnosť systému rozpoznať vizuálne a textové zmeny medzi referenčnými a testovanými obrázkami. Testoval som rôzne typy zmien, vrátane vizuálnych rozdielov, OCR chýb a textových od- chýlok, aby som čo najviac pokryl rôzne scenáre a zároveň otestoval presnosť systému v reálnych podmienkach. Všetky bitmapy boli testované pomocou vizuálneho porovnania v režime validate, ktorý umožňuje určitú mieru tolerancie pri porovnávaní obrazu. V prí- pade, že výsledok v tomto režime zlyhal bol následne vykonaný detailnejší test v presnom režime precise, ktorý porovnáva bitmapy na úrovni jednotlivých pixelov bez akejkoľvek tolerancie. Testovanie som vykonal na osobnom počítači Apple MacBook s operačným systémom macOS. Testy prebiehali v lokálnom prostredí bez využitia externých výpočtových zdrojov. Testované aplikácie boli vybrané tak, aby pokrývali širokú škálu scenárov, ako sú interak- tívne desktopové a mobilné aplikácie. Medzi testované aplikácie patrili ExpenseTracker, Halt. a TimeManager, ktoré som počas štúdia naprogramoval. Tieto aplikácie obsahujú rôznorodé grafické prvky a dynamické komponenty, ktoré umožnili testovať schopnosť ná- stroja zachytiť rôzne druhy zmien. Výsledné bitmapy z testovania sa automaticky ukladajú do priečinka test_results, ktorý sa v prípade neexistencie generuje automaticky. Tento priečinok obsahuje výstupný JSON súbor so zaznamenanými výsledkami testov, ako aj jednotlivé chybové regióny vyre- zané z pôvodných bitmáp. Okrem toho sú celé výsledné bitmapy so zvýraznenými chybnými oblasťami ukladané do priečinka bitmap_summary_result, ktorý slúži na rýchlu vizuálnu orientáciu vo vyhodnotených odchýlkach. V prílohách tejto práce som zahrnul vybraný reprezentatívny vzorový test z každej ap- likácie, ktorý demonštruje typy zistených chýb a odchýlok. Zvyšné testy sú uložené v elek- tronickom archíve, ktorý je súčasťou odovzdanej práce. 5.1 Testovanie aplikácie Expens