Přejít na obsah|Přejít k hlavnímu menu|Přejít k vyhledávání

edhouse-CookieGdpr-Policy-s
0863043
0
/cz/gdpr/
186650B6B

Zpět na Blog

SQA

Identifikace UI prvků pro automatické testování

Tech_blog

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é.

Jak získat parametry elementů?

Webové aplikace

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 CSS, ale to bych u testerů webových aplikací považoval za samozřejmost.

Zobrazení HTML v prohlížeči Chrome
Zobrazení HTML v prohlížeči Chrome

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ů.

Rozšíření Robocorp Recorder
Rozšíření Robocorp Recorder

Desktopové aplikace

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.

Microsoft Accessibility Insights
Microsoft Accessibility Insights

Jak přistupovat k elementům?

Test/Automation ID

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>

Automation Id
Automation Id

Kombinace atributů

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.

Kontext

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.

Více elementů se stejnými vlastnostmi
Více elementů se stejnými vlastnostmi

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říliš stabilní pravidla

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.

Různé přístupy

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

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.

Ukázka použití FlaUI v Robot Frameworku
Ukázka použití FlaUI v Robot Frameworku

Sdílet článek

Autor

Jan Zatloukal

Jan ZatloukalTester a vývojář se zálibou v automatizaci a zlepšování procesu vývoje. Aktuálně pracuji na projektu automatizace elektronových mikroskopů v Pythonu.

Edhouse newsletter

Získejte aktuální info ze světa Edhouse - novinky, setkávání, aktuální trendy softwarové i hardwarové.

Registrací vyjadřujete souhlas se zpracováním osobních údajů.

Děkujeme! Odebírání newsletteru bylo úspěšně přihlášeno.