zisky:
- Schopnosť vytvárať robustný testovací kód používateľského rozhrania s umelou inteligenciou, vrátane testovania údajov, otvoreného čakania a tvrdenia, ktoré overuje skutočný používateľský výsledok
- Schopnosť vyhnúť sa krehkým testom (zlý selektor, slepé čakanie) a zjednodušiť údržbu testov v štruktúre modelu objektu stránky
- Schopnosť otestovať každý test používateľského rozhrania vytvorený prelomením kódu a odhaliť a opraviť falošné testy
Každé kliknutie, každé vyplnenie formulára, každý prechod stránky, ktorý používateľ vykoná v prehliadači, nie je možné znova a znova otestovať ručne – preto existuje automatizácia testovania používateľského rozhrania (používateľské rozhranie; tieto testy napodobňujú správanie používateľa programovým riadením skutočného prehliadača). Selén, dramatik a cyprus sú najbežnejšie nástroje pre túto prácu. Umelá inteligencia (AI) je vysoko kvalifikovaná pri písaní kódu pre tieto nástroje: opíšete testovací prípad, AI vám poskytne návrh funkčného automatizačného skriptu. Tu však opäť vstupuje do hry ústredné varovanie tohto modulu: testovací kód používateľského rozhrania, ktorý vytvára AI, môžu byť často krehké testy, ktoré „sa rozsvietia na zeleno, ale overia nesprávnu vec“ alebo sa rozochvejú vo vetre. Vašou úlohou nie je spustiť tento kód, ale uistiť sa, že skutočne robustne overuje správnu vec.
V tejto jednotke je naším cieľom vytvoriť robustné, udržiavateľné a skutočne overujúce testy používateľského rozhrania s AI; Naučíte sa vyhýbať krehkým testom.
Tri piliere spoľahlivého testovania používateľského rozhrania
1. Správny lokátor prvkov. Test používa selektor na nájdenie prvku na stránke. Umelá inteligencia často vytvára krehké selektory: dlhé cesty XPath (adresa príliš závisí od štruktúry stránky), selektory založené na názvoch tried CSS (prerušenie pri zmene dizajnu). Robustným spôsobom sú stabilné atribúty ako data-testid, ktoré vývojár pridal na testovanie. Explicitne to uložte AI.
2. Explicitné čakanie. Zdrojom zraniteľnosti číslo jedna pri testovaní používateľského rozhrania je načasovanie. Neustály spánok(3) (čakanie naslepo) je zlá prax: niekedy nestačí, niekedy stráca čas. Správny spôsob je použiť explicitné čakanie, ktoré hovorí „čakajte, kým sa tento prvok neobjaví“. Dramatik to robí do značnej miery automaticky; V Seleniu o to musíte výslovne požiadať.
3. Zmysluplné tvrdenie. Test by mal overiť výsledok, ktorý používateľ skutočne uvidí – napríklad „číslo objednávky sa objavilo na obrazovke“, nielen „stránka načítaná“. Ak test vytvorený AI nemá tvrdenie alebo je nedôležitý, tento test vytvorí pseudo-úspech (1. jednotka).
Upozornenie: Keď prvýkrát uvidíte test používateľského rozhrania vygenerovaného AI, skontrolujte maximálne tri veci: sú selektory potvrdené (test údajov), sú zapnuté čakania (bez slepého spánku) a overuje tvrdenie skutočný používateľský výsledok? Ak sú tieto tri v poriadku, test je pravdepodobne solídny.
Model objektu stránky
Ako sa testy zväčšujú, písanie voličov v každom teste sa stáva nočnou morou údržby. Objektový model stránky (POM – návrhový vzor, ktorý zhromažďuje selektory a akcie pre každú stránku/obrazovku do jednej triedy) udržuje selektor na jednom mieste; Keď sa rozhranie zmení, aktualizujete ho v jednom súbore. Nechajte AI produkovať testy v štruktúre POM, a nie priamo; To radikálne uľahčuje údržbu.
Slabá výzva / Silná výzva
Slabé: "Napíšte test Selenium na prihlasovaciu stránku."
Strong: "Napíšte test toku prihlásenia pomocou Playwright (TypeScript). Selektory používajú iba test údajov; nepoužívajte kontrolu nad tým, čo používateľ vidí, nie názov stránky."
Výkonná výzva; Nástroj poskytuje jazyk, politiku výberu, stratégiu čakania, architektúru (POM) a expresívne očakávania.
Testovacie údaje a nezávislosť prostredia
Solídny test používateľského rozhrania je nielen napísaný správne, ale tiež vytvára a čistí svoje vlastné testovacie údaje. Testy generované AI často odkazujú na používateľa alebo záznam, o ktorom sa predpokladá, že už v prostredí existuje („prihláste sa ako správca“). Tento predpoklad sa preruší, keď sa test spustí v inom prostredí alebo po inom teste (problém so závislosťou od objednávky v jednotke 9). Pravdou je, že každý test si na začiatku testu vytvorí potrebné dáta (alebo ich pripraví volaním API) a na konci ich vyčistí. Explicitne povedzte AI, aby „nastavila akékoľvek údaje, od ktorých tento test závisí v rámci testu; nepredpokladajte hotové údaje zvonku“.
Ďalším kritickým bodom nie je testovanie používateľského rozhrania so skutočnými používateľskými údajmi. Ak sa v testovacom prostredí použije kópia produkčnej databázy, tieto záznamy sú údajmi skutočných osôb; snímky obrazovky a záznamy testov môžu tieto údaje odhaliť. Používajte syntetické (fiktívne) testovacie účty; chráni dôvernosť a zároveň umožňuje reprodukovateľnosť testov. Uskutočniť test „stornovania objednávky“ so skutočným zákazníckym účtom je etickou aj prevádzkovou chybou.
Tip: Udržujte čo najmenej testov používateľského rozhrania; Samotné overenie nechajte na API a unit testy, ktoré sú rýchle a stabilné. Testovanie používateľského rozhrania je drahé a krehké – používajte ho iba na overenie skutočného toku koncového používateľa (testovacia pyramídová logika).
Porovnanie vozidiel
vlastnosť
selén
dramatik
cyprus
jazykoch
Java, C#, Python, JS
JS/TS, Python, .NET, Java
JavaScript/TypeScript
automatický pohotovostný režim
Nie (ručne)
áno (silný)
áno
Viac prehliadačov
široký
Chromium/Firefox/WebKit
Dominantný chróm
sklon k krehkosti
Vysoká (ručný pohotovostný režim)
nízka
nízka
Jednoduchosť učenia
stredná
ľahké
ľahké
paralelná prevádzka
Vyžaduje sa mriežka
vstavaný
Rezident/platený
Pri vyžiadaní kódu od AI jasne uveďte, ktorému vozidlu patrí; V opačnom prípade môže vytvoriť mätúci, nefunkčný kód.
Štyri kopírovateľné šablóny
1) Pevné generovanie testu používateľského rozhrania:
Vaša rola: senior technik pre automatizáciu testov.Píšte testy pomocou [nástroj + jazyk] pre nasledujúci postup: [tok].Pravidlá:- Iba výberové údaje; Použitie triedy XPath/CSS. - Žiadny slepý spánok; Použite explicitné/automatické čakanie. - Použiť objektový model stránky. - Nechajte každé tvrdenie overiť skutočný používateľský výsledok. Na začiatku každého testu uveďte, ktoré kritériá prijatia overujete.
2) Kontrola krehkosti:
Skontrolujte krehkosť nasledujúceho testu používateľského rozhrania:- Existuje nestabilný volič (dlhý
3) Konverzia na objekt stránky:
Preveďte nasledujúci obyčajný testovací kód do štruktúry modelu objektu stránky. Presuňte selektory a akcie do tried stránok; Nechajte testovací súbor čítať iba tok scenára. [Nástroj/jazyk]. Kód: [prilepiť kód]
4) Dôkaz pseudoprechodu:
Dokážte, že tento test používateľského rozhrania skutočne potvrdzuje: Akú jedinú zmenu vykonám v kóde aplikácie, ktorá zmení tento test na ČERVENÚ? Ak nemôžete nájsť zmenu, ktorá preruší test, test je neadekvátny; pridať chýbajúce tvrdenia.Test: [prilepiť test]
tri mini prípady
Prípad 1 – Oslobodenie od krehkého voliča. Zo 40 testov, ktoré jeden tím vyrobil s AI, bolo 70 % poškodených po aktualizácii rozhrania; žiadna z nich nebola skutočná chyba, všetko boli krehké selektory XPath. Tím previedol testy na datatestovú základňu so šablónou „kontroly krehkosti“. Počas nasledujúcich troch aktualizácií rozhrania klesol počet falošných prerušení na nulu; čas údržby sa znížil zo 6 hodín na 30 minút týždenne.
Prípad 2 – Falošný test používateľského rozhrania. AI vytvorila test „pridať do košíka“; test bol zelený. Keď bola spustená šablóna „falošný dôkaz o prechode“, zdá sa, že test skontroloval iba kliknutie na tlačidlo a názov stránky, pričom sa nikdy neoverilo, či sa počítadlo košíka zvýšilo alebo nie. Aj keď bola logika košíka úplne zlomená, test prešiel. Pridané pravdivé tvrdenie (odznak košíka je „1“).
Prípad 3 – Slepá čakacia pasca. V selénovom teste produkovanom AI bol spánok(2) po každom kroku; 60 testov trvalo 14 minút a stále sa občas zlomili. Po prepnutí do otvoreného čakania (čakajte na kliknutie prvku) sa čas skrátil na 5 minút a krehkosť zmizla. Čakanie naslepo bolo pomalé a nespoľahlivé.
Časté chyby
- Súhlas s krehkými voličmi. Používanie dlhých ciest XPath generovaných AI tak, ako sú; Testy zlyhajú pri prvej zmene rozhrania.
- Nechať slepého „spať“. "Vyriešenie" načasovania s pevným čakaním; pomalé aj nerozhodné.
- Triviálne tvrdenie. Stačí overiť, či sa stránka načítala; nekontroluje skutočný používateľský výsledok (falošný prechod).
- Pestujte bez POM. Rozdeľte selektory do každého testu; Manuálna aktualizácia desiatok súborov pri zmene rozhrania.
- Bez špecifikácie nástroja. Nehovoríte AI, aký nástroj/jazyk chcete; dostať chaotický, nefunkčný kód.
- Dôverovať pri spustení vygenerovaného kódu a odovzdaní. Netestovať prelomením kódu.
V súhrne
Automatizácia testovania používateľského rozhrania overuje správanie používateľa riadením skutočného prehliadača s programom. AI generuje tento kód rýchlo, ale sú tu dve veľké úskalia: krehké testy (zlý selektor, slepé čakanie) a falošné testy (neúplné/triviálne tvrdenie). Tri piliere spoľahlivého testovania používateľského rozhrania sú selektor odovzdania (test údajov), explicitné čakanie a tvrdenie, ktoré overuje skutočný používateľský výsledok. Vygenerovanie testov v objektovom modeli stránky radikálne zjednodušuje údržbu. Otestujte každý vygenerovaný test otázkou „aká zmena toto prelomí?“
Aplikačná úloha
Vyberte tok používateľov z vášho vlastného projektu (napr. prihlásenie alebo vyhľadávanie). Nechajte AI napísať testy pomocou šablóny „robust UI test generation“. Potom: (1) skontrolujte a opravte voliče a počkajte s „kontrolou krehkosti“, (2) dokážte, že každý test je skutočne validovaný pomocou „pseudo-pass proof“, (3) rozbite kód a pozorujte, že test sa zmení na červenú. Nahláste počet vytvorených a opravených testov a počet nájdených zraniteľností a pseudopriechodov.
kontrolný zoznam
- [ ] AI som jasne uviedol nástroj, jazyk, politiku výberu a architektúru (POM).
- [ ] Overil som, že selektory sú testované na základe údajov.
- [ ] Uistil som sa, že namiesto slepého spánku použijem explicitné/automatické čakanie.
- [ ] Skontroloval som, že každé tvrdenie overuje skutočný používateľský výsledok.
- [ ] Testoval som každý test prelomením kódu; Videl som, ako sa zmenil na červenú.
- [ ] Testy som zhromaždil v štruktúre Page Object Model.