Testování desktop aplikací

Proč nestavět desktopové testy na souřadnicích a obrázcích

Nahrání kliknutí je rychlý způsob, jak vytvořit první automatizovaný scénář. Pokud si však test pamatuje pouze pozici kurzoru nebo obrázek tlačítka, reaguje na vzhled obrazovky, nikoli na význam prvku. Pro dlouhodobou regresní sadu proto potřebujeme stabilnější základ.

Proč testy začnou selhávat bez chyby v aplikaci

Test, který klikne na bod 412 × 260, neví, zda je na tomto místě tlačítko „Uložit“. Posunutí okna, jiné rozlišení, škálování ve Windows nebo nový řádek ve formuláři mohou způsobit, že klikne vedle. Někdy test selže, jindy provede nesprávnou akci a vytvoří zavádějící výsledek.

Vyhledávání podle obrázku je o něco pružnější, ale stále závisí na písmu, barvě, motivu, rozlišení a kvalitě vykreslení. Problém se projevuje zejména tehdy, když testy běží na jiném počítači než u autora nebo se aplikace vizuálně upraví bez změny funkce.

To neznamená, že vizuální porovnání je špatné. Je vhodné, když je vzhled předmětem kontroly — například u grafu, náhledu dokumentu nebo tiskové sestavy. Jako hlavní způsob ovládání formulářů však obvykle přináší zbytečně mnoho údržby.

Jak funguje stabilnější přístup

Windows UI Automation poskytuje strukturovaný strom prvků aplikace. Test dokáže rozlišit okno, textové pole, tabulku a tlačítko a pracovat s jejich vlastnostmi. Místo polohy hledá například tlačítko s konkrétním identifikátorem v určeném okně.

Při návrhu lokátorů postupujeme od nejstabilnějších údajů:

1. jednoznačný AutomationId ve správném okně nebo kontejneru;
2. typ prvku spolu se stabilním názvem či další vlastností;
3. vztah k nadřazenému prvku, pokud samotný identifikátor nestačí;
4. pořadí nebo souřadnice pouze jako poslední, vědomě přijatou možnost.

Samotný AutomationId nemusí být jedinečný v celé aplikaci, proto je důležitý také rozsah vyhledávání. Přístupy k obrazovkám soustředíme do společných komponent testovací sady, aby změna jednoho prvku nevyžadovala úpravu desítek scénářů. Test zároveň čeká na konkrétní stav aplikace, nikoli pevně stanovený počet sekund.

Kde jsou omezení UI Automation

Ne každý vlastní grafický prvek poskytuje systému dostatek informací. Před zahájením je proto třeba aplikaci zkontrolovat inspekčním nástrojem. Někdy pomůže doplnění názvů, rolí nebo identifikátorů ve vývojovém kódu; jindy je nutný kombinovaný přístup.

Změna barvy nebo polohy potom test zpravidla neovlivní, změna názvu či struktury prvku však může. UI Automation tedy neodstraní údržbu, pouze ji naváže na smysluplné změny rozhraní. Dobrá dostupnost prvků může zároveň pomoci asistenčním technologiím, ale sama o sobě nenahrazuje testování přístupnosti.

Co tím získáte

Testy budou méně citlivé na rozlišení, motiv a drobné vizuální úpravy. Když scénář selže, je větší pravděpodobnost, že upozorňuje na změnu chování nebo struktury aplikace, nikoli na posunutý pixel.

Tým také získá předvídatelnější údržbu. Stabilní lokátory a společné objekty obrazovek zkracují opravu po redesignu a usnadňují rozlišení chyby aplikace od chyby testu.

Další krok

Na jedné důležité obrazovce porovnejte, co vidí uživatel a co ukazuje strom Windows UI Automation. Pokud v něm najdete stabilní názvy, typy a identifikátory, přepište jeden často selhávající scénář a sledujte jeho výsledky při opakovaném běhu. Pro WPF a WinForms pokračujte tématem jak ověřit technickou vhodnost aplikace.