zisky:
- Schopnost vytvářet robustní testovací kód uživatelského rozhraní s umělou inteligencí, včetně testování dat, otevřeného čekání a tvrzení, které ověřuje skutečný uživatelský výsledek
- Schopnost vyhnout se křehkým testům (špatný selektor, slepé čekání) a usnadnit údržbu testů ve struktuře Page Object Model
- Schopnost otestovat každý test uživatelského rozhraní vytvořený prolomením kódu a zjistit a opravit falešně prošlé testy
Každé kliknutí, každé vyplnění formuláře, každý přechod stránky, který uživatel provede v prohlížeči, nelze znovu a znovu testovat ručně – proto existuje automatizace testování uživatelského rozhraní (uživatelské rozhraní; tyto testy napodobují chování uživatele programovým řízením skutečného prohlížeče). Selen, dramatik a cypřiš jsou nejběžnějšími nástroji pro tuto práci. Umělá inteligence (AI) je vysoce kvalifikovaná při psaní kódu pro tyto nástroje: popíšete testovací případ, AI vám poskytne návrh funkčního automatizačního skriptu. Zde však znovu vstupuje do hry ústřední varování tohoto modulu: testovací kód uživatelského rozhraní, který AI vytváří, mohou být často křehké testy, které „svítí zeleně, ale ověřují špatnou věc“ nebo klapou ve větru. Vaším úkolem není spouštět tento kód, ale ujistit se, že skutečně robustně ověřuje správnou věc.
V této jednotce se snažíme vytvářet robustní, udržovatelné a skutečně ověřující testy uživatelského rozhraní s AI; Naučíte se vyhýbat křehkým testům.
Tři pilíře solidního testování uživatelského rozhraní
1. Opravte lokátor prvků. Test používá selektor k nalezení prvku na stránce. AI často vytváří křehké selektory: dlouhé cesty XPath (adresa příliš závislá na struktuře stránky), selektory založené na názvech tříd CSS (přerušení při změně návrhu). Robustním způsobem jsou stabilní atributy jako data-testid, které vývojář přidal pro testování. Explicitně to uvalit na AI.
2. Explicitní čekání. Zdrojem zranitelnosti číslo jedna při testování uživatelského rozhraní je načasování. Neustálý spánek(3) (slepé čekání) je špatná praxe: někdy to nestačí, někdy to ztrácí čas. Správným způsobem je použít explicitní čekání, které říká „počkejte, až se objeví tento prvek“. Dramatik to dělá do značné míry automaticky; V Selenium o to musíte výslovně požádat.
3. Smysluplné tvrzení. Test by měl ověřit výsledek, který uživatel skutečně uvidí – například „číslo objednávky se objevilo na obrazovce“, nikoli pouze „stránka načtena“. Pokud test vytvořený umělou inteligencí nemá tvrzení nebo je nedůležitý, tento test vytvoří pseudoprůchod (1. jednotka).
Upozornění: Když poprvé uvidíte test uživatelského rozhraní generovaného umělou inteligencí, zkontrolujte maximálně tři věci: jsou selektory potvrzeny (test dat), jsou zapnuté čekání (žádný slepý spánek) a ověřuje deklarace skutečný uživatelský výsledek? Pokud jsou tyto tři v pořádku, je test pravděpodobně solidní.
Objektový model stránky
Jak se testy zvětšují, psaní selektorů v každém testu se stává noční můrou údržby. Objektový model stránky (POM — návrhový vzor, který shromažďuje selektory a akce pro každou stránku/obrazovku do jediné třídy) udržuje selektor na jednom místě; Když se rozhraní změní, aktualizujete jej v jediném souboru. Nechte AI produkovat testy ve struktuře POM, spíše než přímo; To radikálně usnadňuje údržbu.
Slabá výzva / Silná výzva
Slabé: "Napište test selenu pro přihlašovací stránku."
Strong: "Napište test toku přihlášení pomocí Playwright (TypeScript). Selektory používají pouze data-testid; nepoužívejte kontrolu nad tím, co uživatel vidí, nikoli s názvem stránky."
Výkonná výzva; Nástroj poskytuje jazyk, politiku výběru, strategii čekání, architekturu (POM) a expresivní očekávání tvrzení.
Testovací data a nezávislost na prostředí
Solidní test uživatelského rozhraní je nejen napsán správně, ale také vytváří a čistí svá vlastní testovací data. Testy generované umělou inteligencí často odkazují na uživatele nebo záznam, o kterém se předpokládá, že již v daném prostředí existuje („přihlaste se jako administrátor“). Tento předpoklad se přeruší, když test běží v jiném prostředí nebo po jiném testu (problém se závislostí na objednávce v jednotce 9). Pravdou je, že každý test si na začátku testu vytvoří potřebná data (nebo je připraví voláním API) a na konci je vyčistí. Explicitně instruujte AI, aby „nastavila jakákoli data, na kterých tento test závisí v rámci testu; nepředpokládejte hotová data zvenčí“.
Dalším kritickým bodem je neprovádět testování uživatelského rozhraní se skutečnými uživatelskými daty. Pokud je v testovacím prostředí použita kopie produkční databáze, jsou tyto záznamy daty skutečných osob; snímky obrazovky a testovací nahrávky mohou tato data odhalit. Používejte syntetické (fiktivní) testovací účty; chrání důvěrnost a umožňuje reprodukovatelnost testů. Provedení testu „storna objednávky“ se skutečným zákaznickým účtem je etickou i provozní chybou.
Tip: Udržujte co nejméně testů uživatelského rozhraní; Samotné ověření nechte na API a unit testech, které jsou rychlé a stabilní. Testování uživatelského rozhraní je drahé a křehké – použijte jej pouze k ověření skutečného toku koncových uživatelů (testovací pyramidová logika).
Srovnání vozidel
funkce
selen
dramatik
cypřiš
jazyky
Java, C#, Python, JS
JS/TS, Python, .NET, Java
JavaScript/TypeScript
automatický pohotovostní režim
Ne (ručně)
ano (silný)
Ano
Více prohlížečů
široký
Chromium/Firefox/WebKit
Dominantní chrom
sklon ke křehkosti
Vysoká (ruční pohotovostní režim)
nízká
nízká
Snadnost učení
střední
snadné
snadné
paralelní provoz
Je vyžadována mřížka
vestavěný
Rezident/placený
Při žádosti o kód od AI jasně uveďte, kterému vozidlu patří; V opačném případě může vytvořit matoucí, nefunkční kód.
Čtyři kopírovatelné šablony
1) Solidní generování testu uživatelského rozhraní:
Vaše role: vedoucí technik automatizace testů.Psejte testy pomocí [nástroj + jazyk] pro následující postup: [tok].Pravidla:- Pouze selektory data-testid; Použití třídy XPath/CSS. - Žádný slepý spánek; Použijte explicitní/automatické čekání. - Použít objektový model stránky. - Nechte každé tvrzení ověřit skutečný uživatelský výsledek. Na začátku každého testu uveďte, která kritéria přijetí ověřujete.
2) Kontrola křehkosti:
Prohlédněte si následující test uživatelského rozhraní na křehkost:- Existuje nestabilní volič (dlouhý
3) Převod na objekt stránky:
Převeďte následující prostý testovací kód do struktury Page Object Model. Přesunout selektory a akce do tříd stránek; Nechte testovací soubor číst pouze tok scénáře. [Nástroj/jazyk]. Kód: [vložit kód]
4) Důkaz pseudopřechodu:
Dokažte, že tento test uživatelského rozhraní skutečně ověřuje: Jakou jedinou změnu provedu v kódu aplikace, která změní tento test na ČERVENOU? Pokud nemůžete najít změnu, která by test narušila, je test nedostatečný; přidat chybějící tvrzení.Test: [vložit test]
tři mini pouzdra
Případ 1 — Osvobození od křehkého voliče. Ze 40 testů, které jeden tým provedl s umělou inteligencí, bylo 70 % porušeno po aktualizaci rozhraní; žádná z nich nebyla skutečná chyba, všechny byly křehké selektory XPath. Tým převedl testy do databáze testů pomocí šablony „kontrola křehkosti“. Během následujících tří aktualizací rozhraní klesl počet falešných přerušení na nulu; doba údržby se snížila z 6 hodin na 30 minut týdně.
Případ 2 – falešný test uživatelského rozhraní. AI vytvořila test „přidání do košíku“; test byl zelený. Když byla spuštěna šablona "fake-proof-of-passage", test se zdál kontrolovat pouze kliknutí na tlačítko a název stránky, nikdy neověřoval, zda se počítadlo košíku zvýšilo nebo ne. I když byla logika košíku zcela porušena, test prošel. Přidáno true statement (odznak košíku je "1").
Případ 3 – Slepá vyčkávací past. V selenovém testu produkovaném AI byl spánek(2) po každém kroku; 60 testů trvalo 14 minut a stále se občas zlomilo. Po přepnutí do otevřeného čekání (čekejte, až bude prvek klikatelný) se čas zkrátil na 5 minut a křehkost zmizela. Čekání naslepo bylo pomalé a nespolehlivé.
Časté chyby
- Souhlas s křehkými voliči. Použití dlouhých cest XPath generovaných AI tak, jak jsou; Testy selžou při první změně rozhraní.
- Nechání slepého „spát“. "Vyřešení" načasování s pevným čekáním; jak pomalé, tak nerozhodné.
- Triviální tvrzení. Stačí ověřit, že se stránka načetla; nekontroluje skutečný uživatelský výsledek (falešný průchod).
- Pěstujte bez POM. Distribuujte selektory do každého testu; Ruční aktualizace desítek souborů při změně rozhraní.
- Bez určení nástroje. Neříkat AI, jaký nástroj/jazyk chcete; dostat chaotický, nefunkční kód.
- Důvěřovat, když spustíte vygenerovaný kód a předáte. Netestování porušením kódu.
V souhrnu
Automatizace testování uživatelského rozhraní ověřuje chování uživatele řízením skutečného prohlížeče s programem. Umělá inteligence generuje tento kód rychle, ale jsou zde dvě velká úskalí: křehké testy (špatný volič, slepé čekání) a testy falešného procházení (neúplné/triviální tvrzení). Tři pilíře solidního testování uživatelského rozhraní jsou selektor potvrzení (data-testid), explicitní čekání a tvrzení, které ověřuje skutečný uživatelský výsledek. Vygenerování testů v modelu objektu stránky radikálně zjednodušuje údržbu. Otestujte každý vygenerovaný test otázkou "jaká změna to poruší?"
Aplikační úkol
Vyberte uživatelský tok ze svého vlastního projektu (např. přihlášení nebo vyhledávání). Nechte AI napsat testy pomocí šablony „generování testu robustního uživatelského rozhraní“. Poté: (1) zkontrolujte a opravte voliče a počkejte s „kontrolou křehkosti“, (2) prokažte, že každý test je skutečně validován „pseudo-úspěšným důkazem“, (3) rozbijte kód a pozorujte, že test zčervená. Nahlaste počet vytvořených a opravených testů a počet nalezených zranitelností a pseudoprůchodů.
kontrolní seznam
- [ ] AI jsem jasně uvedl nástroj, jazyk, politiku výběru a architekturu (POM).
- [ ] Ověřil jsem, že selektory jsou testovány daty.
- [ ] Ujistil jsem se, že místo slepého spánku použiji explicitní/automatické čekání.
- [ ] Zkontroloval jsem, že každé tvrzení ověřuje skutečný uživatelský výsledek.
- [ ] Testoval jsem každý test porušením kódu; Viděl jsem, jak zčervenal.
- [ ] Testy jsem shromáždil ve struktuře Page Object Model.