
Jak posouváme hranice výzkumu
Přiblížit si něco tak moc, že uvidíte atomy? To v dnešní době není problém.
Přejít na obsah | Přejít k hlavnímu menu | Přejít k vyhledávání
Identifikace elementů uživatelského rozhraní je klíčovou částí automatických testů. Abyste mohli vaši aplikaci v testech ovládat, potřebujete předat testovacímu nástroji přesnou a jednoznačnou specifikaci toho, co má na kterém elementu provést. Kliknout na tlačítko, zapsat text nebo získat hodnotu. Testy, které nemají identifikaci nastavenou správně, často padají nebo jsou nespolehlivé.
Jednodušší přístup k atributům a elementům mají testeři webových aplikací. Stačí si zobrazit zdrojový kód stránky a máte vše k dispozici. Vyžaduje to znalost HTML a CSS, ale to bych u testerů webových aplikací považoval za samozřejmost.
Pokud se chystáte testovat webovou aplikaci a znalost HTML nebo CSS vám chybí, doporučuji stránky Jak psát web, kde se dozvíte vše podstatné.
Pomoci v identifikaci vám může i nějaké rozšíření, například Robocorp Recorder umí vypsat všechny elementy na dané stránce pomocí XPath. Je sice určený pro Robot Framework, ale XPath využijete i u ostatních nástrojů.
Testeři desktopových aplikací se bez nějakého dedikovaného nástroje neobejdou. Většina testovacích nástrojů a frameworků má nějaký doporučovaný nástroj uvedený v dokumentaci nebo jej má přímo integrovaný.
Jedním z často zmiňovaných nástrojů je Microsoft Accessibility Insights.
Základní možností, jak lokalizovat jednotlivé elementy, je použití dedikovaného atributu pro automatické testy. To ale vyžaduje, aby vývojáři takové atributy do aplikací během vývoje přidávali . Na toto se však často zapomíná nebo vůbec není součástí vývojového cyklu.
U nových projektů tedy doporučuji zařazení těchto atributů například do akceptačních kritérií. U starších projektů záleží na domluvě, ochotě a někdy také proveditelnosti. Ne vždy se podaří toto prosadit.
Takové atributy by měly být jednoznačné, aby nebylo možné je zaměnit, což by mohlo vést k nepravdivým výsledkům testů.
<button data-test-id="Num9Button">9</button>
Pokud není k dispozici jednoznačný identifikátor, můžeme využít ostatní atributy. V tom případě ale platí pravidlo, že je vždy lepší kombinovat dva a více parametrů, tak abychom skutečně získali požadovaný element.
Identifikace takového elementu desktopové aplikace v RPA frameworku by pak vypadala například následovně:
type:Button and name:OK
V případě webové aplikace a identifikace pomocí XPath potom takto:
//Button[@name="OK"]
Všiměte si, že v obou případech jsme jako jeden z parametrů použili samotný typ elementu Button.
Při identifikaci prvků je také dobrým zvykem přemýšlet nad kontextem, ve kterém daný element hledáme.
Pokud máme na obrazovce například dvě tlačítka OK, musíme v automatizaci použít k identifikaci i nadřazený (rodičovský) prvek.
RPA Window zná koncept tzv. “root locators”, kdy můžete přímo určit “cestu” k vašemu elementu:
type:Form and name:"Form1" > type:Button and name:OK
type:Form and name:"Form2" > type:Button and name:OK
XPath zase umožňuje absolutní nebo relativní zápis. Následujícím zápisem tak získáte stejný výsledek, jako v předchozí ukázce:
//form[@name="Form1"]//button[@name="OK"]
//form[@name="Form2"]//button[@name="OK"]
Kontext bych doporučoval používat vždy. Můžete tím předejít situacím, kdy se v aplikaci objeví nějaké nové prvky, které můžou způsobit, že váš test nebude pracovat s těmi původně testovanými.
Při vytváření pravidel (v angličtině je nejčastěji nazýváme selectors nebo locators) také myslete na to, aby odpovídala skutečnému stavu aplikace. Zdrojový kód aplikace se může měnit a testy by měly novému stavu odpovídat. Může například dojít ke změně chování aplikace, ale vývojáři nechají tlačítku stejné automation ID. Test v takovém případě může skončit falešně pozitivním (false positive) nebo falešně negativním (false negative) výsledkem.
Jak je vidět, různé testovací nástroje mají různé přístupy. Ve výsledku se vždy ale jedná o to stejné, jen zapsané v jiném formátu. Potom je potřeba si pročíst dokumentaci, vyzkoušet ukázkové kódy a případně se nebát zeptat na diskuzních fórech nebo například umělé inteligence.
Xpath je způsob zápisu, který podporuje většina testovacích nástrojů. Ve větší míře se používá pro webové aplikace, ale své místo má i při testování těch desktopových. Přiznám se, že v tomto ohledu nemám velký přehled, ale vyzkoušel jsem tento přístup pomocí knihovny FlaUI v Robot Frameworku – ukázkový test najdete na našem GitHubu.
Jak na XPath, se dozvíte například v návodu od W3C.
Přiblížit si něco tak moc, že uvidíte atomy? To v dnešní době není problém.
Když před dvěma lety OpenAI představila ChatGPT, začaly se objevovat názory, že vývojáři a testeři přijdou o práci. Po dvou letech ale můžeme konstatovat, že tomu tak není. Kde se stala chyba a jaké nové výzvy nám AI představila?
Robot Framework je rozšířený testovací tool založený na pythonu, udržovaný komunitou a zdarma. Poměr cena/výkon tedy vychází velmi výhodně. Syntaxe Robot Frameworku je založená na klíčových slovech (keywords). Poradí si Robot Framework s BDD a s Gherkinem? Pojďme se na to podívat.
Děkujeme za váš zájem o odběr našeho newsletteru! Pro dokončení registrace je potřeba potvrdit vaše přihlášení. Na zadaný e-mail jsme vám právě zaslali potvrzovací odkaz. Klikněte prosím na tento odkaz, aby bylo vaše přihlášení dokončeno. Pokud e-mail nenajdete, zkontrolujte prosím složku nevyžádané pošty (spam) nebo složku hromadné pošty.