Ieguvumi:
- Spēja izveidot stabilu lietotāja interfeisa testa kodu ar mākslīgo intelektu, tostarp datu pārbaudi, atvērtu gaidīšanu un apgalvojumu, kas pārbauda reālo lietotāja rezultātu
- Iespēja izvairīties no trausliem testiem (slikts atlasītājs, akla gaidīšana) un padarīt testus viegli uzturējamus lapas objekta modeļa struktūrā
- Iespēja pārbaudīt katru lietotāja interfeisa testu, kas izveidots, pārkāpjot kodu, un atklāt un labot viltus izturētus testus
Katru klikšķi, katru veidlapas aizpildīšanu, katru lapas pāreju, ko lietotājs veic pārlūkprogrammā, nevar atkal un atkal ar rokām pārbaudīt — tāpēc pastāv lietotāja interfeisa pārbaudes automatizācija (lietotāja interfeiss; šie testi atdarina lietotāja uzvedību, programmatiski vadot īstu pārlūkprogrammu). Selēns, dramaturgs un ciprese ir visizplatītākie šī darba rīki. Mākslīgais intelekts (AI) ir augsti kvalificēts šo rīku koda rakstīšanā: jūs aprakstāt testa gadījumu, AI sniedz jums praktiski izmantojama automatizācijas skripta uzmetumu. Bet šeit atkal stājas spēkā šī moduļa centrālais brīdinājums: AI testa kods, ko rada AI, bieži var būt trausli testi, kas “iedegas zaļā krāsā, bet pārbauda nepareizo lietu” vai vējā. Jūsu uzdevums nav palaist šo kodu, bet gan pārliecināties, ka tas patiešām stingri pārbauda pareizo lietu.
Šajā vienībā mūsu mērķis ir izveidot stabilus, uzturējamus un patiesi apstiprinošus lietotāja interfeisa testus ar AI; Jūs iemācīsities izvairīties no trausliem pārbaudījumiem.
Trīs stabilas lietotāja saskarnes testēšanas pīlāri
1. Pareizs elementu lokators. Pārbaudē tiek izmantots atlasītājs, lai lapā atrastu elementu. AI bieži rada trauslus atlasītājus: garus XPath ceļus (adrese ir pārāk atkarīga no lapas struktūras), atlasītājus, kuru pamatā ir CSS klašu nosaukumi (pārtraukt, kad dizains mainās). Spēcīgākais veids ir stabili atribūti, piemēram, data-testid, ko izstrādātājs pievienoja testēšanai. Skaidri uzliek to AI.
2. Nepārprotama gaidīšana. Galvenais ievainojamības avots UI testēšanā ir laiks. Pastāvīgs miegs (3) (akla gaidīšana) ir slikta prakse: dažreiz ar to nepietiek, dažreiz tas tērē laiku. Pareizais veids ir izmantot skaidru gaidīšanu, kas saka "pagaidiet, līdz parādās šis elements". Dramaturgs to dara lielākoties automātiski; Selēnā jums tas ir skaidri jāpieprasa.
3. Jēgpilns apgalvojums. Pārbaudei ir jāpārbauda rezultāts, ko lietotājs redzēs, piemēram, “ekrānā parādījās pasūtījuma numurs”, nevis tikai “lapa ir ielādēta”. Ja AI izveidotajā testā nav apgalvojuma vai tas ir nesvarīgs, šis tests rada pseido-nokārtojumu (1. vienība).
Uzmanību! Kad pirmo reizi redzat mākslīgā intelekta ģenerētu lietotāja interfeisa testu, pārbaudiet ne vairāk kā trīs lietas: vai atlasītāji ir noteikti (datu testēšana), vai ir ieslēgta gaidīšana (nav akla miega) un vai apgalvojums pārbauda faktisko lietotāja rezultātu? Ja šie trīs ir labi, tests, iespējams, ir stabils.
Lapas objekta modelis
Tā kā testi kļūst arvien lielāki, atlasītāju rakstīšana katrā testā kļūst par uzturēšanas murgu. Lapas objekta modelis (POM — dizaina modelis, kas apkopo atlasītājus un darbības katrai lapai/ekrānam vienā klasē) notur atlasītāju vienuviet; Kad saskarne mainās, jūs to atjaunināt vienā failā. Ļaujiet AI veikt testus POM struktūrā, nevis tieši; Tas ievērojami atvieglo apkopi.
Vāja uzvedne / spēcīga uzvedne
Vāji: "Uzrakstiet pieteikšanās lapai Selēna testu."
Spēcīgs: "Uzrakstiet pieteikšanās plūsmas testu, izmantojot Playwright (TypeScript). Atlasītāji izmanto tikai datu testu; neizmanto kontroli, ko lietotājs redz, nevis lapas nosaukumu."
Spēcīga uzvedne; Šis rīks sniedz valodu, atlasītāja politiku, gaidīšanas stratēģiju, arhitektūru (POM) un izteiksmīgu apgalvojumu.
Testa dati un vides neatkarība
Ciets lietotāja interfeisa tests ir ne tikai pareizi uzrakstīts, bet arī veido un notīra savus testa datus. AI ģenerētie testi bieži ir saistīti ar lietotāju vai ierakstu, kas, domājams, jau pastāv vidē (“piesakieties kā administratora lietotājs”). Šis pieņēmums tiek pārtraukts, kad tests tiek izpildīts citā vidē vai pēc citas pārbaudes (pasūtījuma atkarības problēma 9. vienībā). Patiesība ir tāda, ka katrs tests izveido nepieciešamos datus testa sākumā (vai sagatavo tos ar API izsaukumu) un notīra tos beigās. Skaidri norādiet AI "testā iestatīt visus datus, no kuriem atkarīgs šis tests; neuzņemieties gatavus datus no ārpuses".
Vēl viens kritisks punkts ir neveikt lietotāja interfeisa testēšanu ar reāliem lietotāja datiem. Ja testa vidē tiek izmantota ražošanas datu bāzes kopija, šie ieraksti ir reālu personu dati; ekrānuzņēmumi un testa ieraksti var atklāt šos datus. Izmantojiet sintētiskos (izdomātus) testa kontus; tas gan aizsargā konfidencialitāti, gan padara testus reproducējamus. "Pasūtījuma atcelšanas" testa veikšana ar īstu klienta kontu ir gan ētiska, gan darbības kļūda.
Padoms. Saglabājiet pēc iespējas mazāk lietotāja interfeisa testu; Atstājiet faktisko verifikāciju API un vienību testiem, kas ir ātri un stabili. UI testēšana ir dārga un trausla — izmantojiet to tikai, lai apstiprinātu patiesu lietotāju plūsmu no gala līdz galam (pārbaudes piramīdas loģika).
Transportlīdzekļu salīdzinājums
funkciju
selēns
dramaturgs
ciprese
valodas
Java, C#, Python, JS
JS/TS, Python, .NET, Java
JavaScript/TypeScript
automātiskais gaidīšanas režīms
Nē (ar roku)
Jā (spēcīgs)
Jā
Vairāku pārlūkprogrammu
plats
Chromium/Firefox/WebKit
Dominē hroms
tendence uz trauslumu
Augsts (manuālais gaidīšanas režīms)
zems
zems
Mācīšanās vieglums
vidējs
viegli
viegli
paralēla darbība
Nepieciešams režģis
iebūvēts
Iedzīvotājs/maksāts
Pieprasot kodu no AI, skaidri norādiet, kuram transportlīdzeklim tas pieder; Pretējā gadījumā tas var radīt mulsinošu, nestrādājošu kodu.
Četras kopējamas veidnes
1) Cietā lietotāja saskarnes testa ģenerēšana:
Jūsu loma: vecākais testēšanas automatizācijas inženieris.Rakstiet testus, izmantojot [rīks + valoda] šādai plūsmai: [plūsma]. Noteikumi:- Tikai atlasītāju dati-testid; Izmantojot XPath/CSS klasi. - Nav akla miega; Izmantojiet skaidru/automātisku gaidīšanu. - Lietot lapas objekta modeli. - Ļaujiet katram apgalvojumam pārbaudīt faktisko lietotāja rezultātu. Katra testa sākumā komentējiet, kādus pieņemšanas kritērijus vēlaties apstiprināt.
2) Trausluma kontrole:
Pārbaudiet šo lietotāja interfeisa testu, lai noteiktu trauslumu:- vai ir nestabils selektors (garš
3) Pārvēršana par lapas objektu:
Konvertējiet šādu vienkāršu testa kodu lapas objekta modeļa struktūrā. Pārvietot atlasītājus un darbības uz lapu klasēm; Ļaujiet testa failam lasīt tikai scenārija plūsmu. [Rīks/valoda]. Kods: [ielīmēt kodu]
4) Pseidopārejas pierādījums:
Pierādiet, ka šis lietotāja interfeisa tests patiešām apstiprina: Kādas izmaiņas man jāveic lietojumprogrammas kodā, lai šī pārbaude kļūtu SARKANA? Ja nevarat atrast izmaiņas, kas izjauktu pārbaudi, tests ir neadekvāts; pievienojiet trūkstošos apgalvojumus.Pārbaude: [ielīmēt testu]
trīs mini futrāļi
1. gadījums — atbrīvošanās no trauslā selektora. No 40 testiem, ko viena komanda veica ar AI, 70% tika bojāti pēc saskarnes atjaunināšanas; neviena no tām nebija īstas kļūdas, tās visas bija trauslas XPath atlasītāji. Komanda pārveidoja testus par datu testēšanas bāzi, izmantojot "trausluma pārbaudes" veidni. Nākamo trīs interfeisa atjauninājumu laikā viltus pārtraukumu skaits samazinājās līdz nullei; apkopes laiks samazinājās no 6 stundām līdz 30 minūtēm nedēļā.
2. gadījums — viltus sekmīgas lietotāja saskarnes tests. AI izveidoja “pievienot grozam” testu; tests bija zaļš. Kad tika izpildīta veidne “Viltus caurbraukšanas pierādījums”, izrādījās, ka testā tika pārbaudīts tikai pogas klikšķis un lapas nosaukums, nekad nepārbaudot, vai groza skaitītājs ir palielinājies vai nē. Pat ja ratu loģika bija pilnībā salauzta, pārbaude izturēja. Pievienots patiess apgalvojums (groza emblēma ir “1”).
3. gadījums — akls gaidīšanas slazds. AI veiktajā Selēna testā pēc katra soļa bija miegs (2); 60 pārbaudes aizņēma 14 minūtes un joprojām ik pa laikam sabojājās. Pēc pārslēgšanas uz atvērtu gaidīšanu (pagaidiet, līdz elements būs noklikšķināms) laiks samazinājās līdz 5 minūtēm un trauslums pazuda. Aklā gaidīšana bija gan lēna, gan neuzticama.
Biežas kļūdas
- Piekrītu trauslajiem atlasītājiem. Izmantojot AI ģenerētos garos XPaths tādus, kādi tie ir; Pārbaudes avarē pirmajā saskarnes maiņas reizē.
- Atstājot aklu `miegu`. Laika "atrisināšana" ar fiksētu gaidīšanu; gan lēni, gan neizlēmīgi.
- Triviāls apgalvojums. Vienkārši pārbaudiet, vai lapa ir ielādēta; faktiskā lietotāja rezultāta nepārbaudīšana (fake-pass).
- Audzējiet bez POM. Izdaliet selektorus katram testam; Manuāla desmitiem failu atjaunināšana, mainoties saskarnei.
- Nav norādīts rīks. Nenorādīt AI, kādu rīku/valodu vēlaties; kļūst netīrs, nestrādājošs kods.
- Uzticēšanās, kad palaižat ģenerēto kodu un nododat to. Nepārbauda, pārtraucot kodu.
Rezumējot
UI testēšanas automatizācija pārbauda lietotāja uzvedību, izmantojot programmu, izmantojot faktisko pārlūkprogrammu. AI ātri ģenerē šo kodu, taču ir divas lielas nepilnības: trausli testi (slikts atlasītājs, akls gaidīšanas laiks) un viltus izturēšanas testi (nepilnīgs/triviāls apgalvojums). Trīs stabilas lietotāja saskarnes testēšanas pīlāri ir apņemšanās atlasītājs (data-testid), skaidra gaidīšana un apstiprinājums, kas pārbauda faktisko lietotāja rezultātu. Lapas objekta modelī ģenerēti testi ievērojami vienkāršo apkopi. Pārbaudiet katru ģenerēto testu ar jautājumu "kādas izmaiņas to izjauks?"
Lietojumprogrammas uzdevums
Izvēlieties lietotāja plūsmu no sava projekta (piemēram, pieteikšanās vai meklēšana). Veiciet AI rakstīšanas testus, izmantojot veidni “izturīgā lietotāja saskarnes testa paaudzes”. Pēc tam: (1) pārbaudiet un salabojiet atlasītājus un gaidiet ar "trausluma pārbaudi", (2) pierādiet, ka katrs tests faktiski tiek apstiprināts ar "pseido-pass proof", (3) pārtrauciet kodu un novērojiet, ka tests kļūst sarkans. Ziņojiet par veikto un laboto testu skaitu, kā arī par atrasto ievainojamību un pseidopāreju skaitu.
kontrolsaraksts
- [ ] Es skaidri norādīju AI rīku, valodu, atlasītāja politiku un arhitektūru (POM).
- [ ] Es pārbaudīju, vai atlasītāji ir pārbaudīti ar datiem.
- [ ] Es noteikti izmantoju skaidru/automātisku gaidīšanu, nevis aklu miegu.
- [ ] Es pārbaudīju, vai katrs apgalvojums pārbauda faktisko lietotāja rezultātu.
- [ ] Es pārbaudīju katru testu, pārtraucot kodu; Es redzēju, kā tas kļūst sarkans.
- [ ] Es apkopoju testus Page Object Model struktūrā.