Nyereség:
- Képes robusztus felhasználói felület tesztkód előállítására mesterséges intelligenciával, beleértve az adattesztet, a nyílt várakozást és az assert, amely ellenőrzi a valódi felhasználói eredményt
- A törékeny tesztek elkerülése (rossz választó, vak várakozás), és a tesztek könnyen karbantarthatók az oldalobjektum modell szerkezetében
- Lehetőség minden UI-teszt tesztelésére, amelyet a kód feltörése okoz, és észleli és kijavítja a hamisan teljesített teszteket
A felhasználó által a böngészőben végrehajtott minden kattintás, minden űrlap kitöltése, minden oldalváltás nem tesztelhető újra és újra kézzel – ezért létezik a felhasználói felület tesztautomatizálása (felhasználói felület; ezek a tesztek egy valódi böngésző programozásával utánozzák a felhasználói viselkedést). A szelén, a drámaíró és a ciprus a leggyakoribb eszközök ehhez a munkához. A mesterséges intelligencia (AI) magasan képzett ezen eszközök kódjának megírásában: Ön leír egy tesztesetet, az AI pedig egy működőképes automatizálási szkript vázlatát adja meg. De itt ismét megjelenik ennek a modulnak a központi figyelmeztetése: a mesterséges intelligencia által előállított felhasználói felület tesztkód gyakran törékeny tesztek lehetnek, amelyek „zölden világítanak, de igazolják, hogy rossz a dolog”, vagy csapkodnak a szélben. Az Ön feladata nem ennek a kódnak a futtatása, hanem az, hogy megbizonyosodjon arról, hogy valóban megbízhatóan ellenőrzi a helyes dolgot.
Ebben az egységben az a célunk, hogy robusztus, karbantartható és valóban érvényesítő UI-teszteket készítsünk mesterséges intelligencia segítségével; Megtanulod elkerülni a törékeny teszteket.
A szilárd felhasználói felület tesztelésének három pillére
1. Helyes elemkereső. A teszt egy választó segítségével keresi meg az elemet az oldalon. A mesterséges intelligencia gyakran törékeny kijelölőket produkál: hosszú XPath útvonalakat (a cím túlzottan függ az oldal szerkezetétől), CSS-osztályneveken alapuló szelektorokat (a tervezés megváltozásakor megszakad). A robusztus módszer a stabil attribútumok, például a data-testid, amelyeket a fejlesztő hozzáadott a teszteléshez. Ezt kifejezetten elő kell írni az AI-ra.
2. Kifejezett várakozás. A felhasználói felület tesztelésének első számú sebezhetősége az időzítés. Az állandó alvás(3) (vakvárás) rossz gyakorlat: néha nem elég, néha időt veszít. A helyes módszer az explicit várakozás használata, amely azt mondja, hogy "várjon, amíg ez az elem megjelenik". A drámaíró ezt nagyrészt automatikusan teszi; A Seleniumban kifejezetten kérnie kell.
3. Értelmes állítás. A tesztnek ellenőriznie kell a felhasználó által ténylegesen látható eredményt – például „a rendelési szám megjelent a képernyőn”, nem csak az „oldal betöltve”. Ha a mesterséges intelligencia által készített tesztnek nincs állítása, vagy nem fontos, az a teszt pszeudo-pass-t (1. egység) eredményez.
Vigyázat: Amikor először lát egy mesterséges intelligencia által generált felhasználói felülettesztet, legfeljebb három dolgot ellenőrizzen: a kiválasztók készen állnak-e (data-testid), be vannak-e várva (nincs vak alvás), és az állítás ellenőrzi-e a tényleges felhasználói eredményt? Ha ez a három rendben van, a teszt valószínűleg szilárd.
Oldal objektum modell
Ahogy a tesztek egyre nagyobbak lesznek, az egyes teszteken belüli kiválasztók írása karbantartási rémálommá válik. Oldalobjektum-modell (POM – tervezési minta, amely egyetlen osztályba gyűjti a kiválasztókat és a műveleteket minden oldalhoz/képernyőhöz) egy helyen tartja a választót; Amikor az interfész megváltozik, egyetlen fájlban frissíti. Az AI készítse el a teszteket POM-struktúrában, ne közvetlenül; Ez radikálisan megkönnyíti a karbantartást.
Gyenge felszólítás / Erős felszólítás
Gyenge: "Írjon szelén tesztet a bejelentkezési oldalhoz."
Erős: "Írjon bejelentkezési folyamattesztet a Playwright (TypeScript) segítségével. A kiválasztók csak a data-testid-et használják; nem azt szabályozzák, hogy mit lát a felhasználó, nem az oldal címét."
Erőteljes felszólítás; Az eszköz megadja a nyelvet, a kiválasztási szabályzatot, a várakozási stratégiát, az architektúrát (POM) és a kifejező állítási elvárást.
Tesztadatok és környezetfüggetlenség
A szilárd felhasználói felület tesztje nem csak helyesen van megírva, hanem saját tesztadatait is összeállítja és megtisztítja. A mesterséges intelligencia által generált tesztek gyakran hivatkoznak egy olyan felhasználóra vagy rekordra, amelyről feltételezik, hogy már létezik a környezetben („jelentkezzen be rendszergazdaként”). Ez a feltételezés megszakad, amikor a teszt egy másik környezetben fut, vagy egy másik teszt után (rendelésfüggőségi probléma a 9. egységben). Az igazság az, hogy minden teszt a teszt elején hozza létre a szükséges adatokat (vagy API-hívással készíti elő), és a végén megtisztítja. Kifejezetten utasítsa az AI-t, hogy "a teszten belül állítson be minden olyan adatot, amelytől ez a teszt függ; ne feltételezzen kívülről kész adatokat".
Egy másik kritikus pont az, hogy ne végezzünk felhasználói felület tesztelését valós felhasználói adatokkal. Ha a tesztkörnyezetben éles adatbázis-példányt használnak, ezek a rekordok valós személyek adatai; képernyőképek és tesztfelvételek felfedhetik ezeket az adatokat. Szintetikus (fiktív) tesztfiókok használata; egyrészt védi a bizalmasságot, másrészt reprodukálhatóvá teszi a teszteket. A "megrendelés törlési" teszt végrehajtása valódi ügyfélfiókkal etikai és működési hiba egyaránt.
Tipp: A lehető legkevesebb felhasználói felület-teszt legyen; A tényleges ellenőrzést bízza az API-ra és az egységtesztekre, amelyek gyorsak és stabilak. A felhasználói felület tesztelése drága és törékeny – csak a valóban végpontok közötti felhasználói áramlás érvényesítésére használja (tesztpiramis logika).
Járművek összehasonlítása
jellemzője
szelén
drámaíró
ciprus
nyelvek
Java, C#, Python, JS
JS/TS, Python, .NET, Java
JavaScript/TypeScript
automatikus készenlét
Nem (kézzel)
Igen (erős)
Igen
Több böngésző
széles
Chromium/Firefox/WebKit
Króm-domináns
törékenységre való hajlam
Magas (kézi készenlét)
alacsony
alacsony
Könnyű tanulás
közepes
könnyű
könnyű
párhuzamos működés
Rács szükséges
beépített
Lakos/fizetős
Amikor kódot kér az AI-tól, egyértelműen jelezze, hogy melyik járműhöz tartozik; Ellenkező esetben zavaró, nem működő kódot produkálhat.
Négy másolható sablon
1) Szilárd felhasználói felület tesztgenerálása:
Az Ön szerepköre: vezető tesztautomatizálási mérnök. Írjon teszteket [eszköz + nyelv] segítségével a következő folyamathoz: [folyamat]. Szabályok:- Csak szelektorok adat-tesztid; XPath/CSS-osztály használata. - Nincs vak alvás; Használjon kifejezett/automatikus várakozást. - Oldalobjektum modell alkalmazása. - Hagyja, hogy minden állítás ellenőrizze a tényleges felhasználói eredményt. Minden teszt elején jegyezze meg, hogy melyik elfogadási kritériumot szeretné érvényesíteni.
2) Törékenység szabályozás:
Vizsgálja meg a következő UI-tesztet a ridegség szempontjából:- Van-e instabil választó (hosszú
3) Konverzió oldalobjektummá:
Alakítsa át a következő egyszerű tesztkódot oldalobjektum modell szerkezetté. Kijelölők és műveletek áthelyezése oldalosztályokba; Hagyja, hogy a tesztfájl csak a forgatókönyv-folyamatot olvassa. [Eszköz/nyelv]. Kód: [kód beillesztése]
4) Ál-átmeneti bizonyíték:
Bizonyítsa be, hogy ez a felhasználói felület teszt valóban érvényesíti: Milyen egyetlen változtatást kell végrehajtanom az alkalmazás kódjában, amely ezt a tesztet PIROSRA váltja? Ha nem talál olyan változást, amely megszakítja a tesztet, akkor a teszt nem megfelelő; hiányzó állítások hozzáadása.Teszt: [teszt beillesztése]
három mini tok
1. eset – Felszabadulás a törékeny választótól. Az egyik csapat mesterséges intelligenciával készített 40 teszt 70%-a tönkrement a felület frissítése után; egyik sem volt tényleges hiba, mindegyik törékeny XPath választó volt. A csapat a teszteket egy adat-tesztelési bázissá alakította át a „törékenységi ellenőrzés” sablonnal. A következő három kezelőfelület-frissítés során a hamis szünetek száma nullára csökkent; a karbantartási idő heti 6 óráról 30 percre csökkent.
2. eset – Hamisan sikeres UI teszt. A mesterséges intelligencia egy „kosárba helyezés” tesztet készített; a teszt zöld volt. A „hamis áthaladás” sablon futtatásakor úgy tűnt, hogy a teszt csak a gombra kattintást és az oldal címét ellenőrizte, soha nem ellenőrizte, hogy a kosárszámláló nőtt-e vagy sem. Még ha a kosár logikája teljesen megtört is, a teszt sikeres volt. Igaz állítás hozzáadva (a kosár jelvénye "1").
3. eset – Vakváró csapda. Az MI által készített szeléntesztben minden lépés után alvás(2) volt; 60 teszt 14 percig tartott, és még mindig elromlott. Nyitott várakozásra váltás után (várni, amíg az elem kattintható lesz) az idő 5 percre csökkent és a ridegség eltűnt. A vak várakozás lassú és megbízhatatlan volt.
Gyakori hibák
- Egyetért a törékeny választókkal. A mesterséges intelligencia által generált hosszú XPath-ok használata úgy, ahogy van; A tesztek összeomlanak az első interfészváltáskor.
- A vak `alvás` elhagyása. Az időzítés "megoldása" fix várakozással; lassú és határozatlan egyaránt.
- Triviális állítás. Csak ellenőrizze, hogy az oldal betöltődött-e; nem ellenőrzi a tényleges felhasználói eredményt (fake-pass).
- Növekszik POM nélkül. Osszon kiválasztókat az egyes tesztekhez; Több tucat fájl manuális frissítése az interfész megváltozásakor.
- Nem határozza meg az eszközt. Nem mondja meg az AI-nak, hogy milyen eszközt/nyelvet szeretne használni; rendetlen, nem működő kódot kap.
- Megbízni, amikor futtatja a generált kódot és átadja. Nem a kód feltörésével tesztel.
Összefoglalva
A felhasználói felület tesztelési automatizálása ellenőrzi a felhasználói viselkedést azáltal, hogy a tényleges böngészőt a programmal hajtja végre. A mesterséges intelligencia gyorsan generálja ezt a kódot, de két nagy buktatója van: rideg tesztek (rossz választó, vak várakozás) és hamis sikeres tesztek (hiányos/triviális állítás). A szilárd felhasználói felület tesztelésének három pillére a véglegesítési választó (data-testid), az explicit várakozás és az érvényesítés, amely ellenőrzi a tényleges felhasználói eredményt. Az oldalobjektum modellben generált tesztek radikálisan leegyszerűsítik a karbantartást. Teszteljen minden generált tesztet a "milyen változás fogja ezt megszakítani?" kérdéssel.
Pályázati feladat
Válasszon felhasználói folyamatot a saját projektjéből (például bejelentkezés vagy keresés). Készítsen mesterséges intelligencia írási teszteket a „robusztus felhasználói felület tesztgenerálása” sablonnal. Ezután: (1) ellenőrizze és rögzítse a kiválasztókat, és várjon egy "törékenységi ellenőrzéssel", (2) bizonyítsa be, hogy minden teszt valóban érvényes egy "álpass bizonyítással", (3) törje meg a kódot, és figyelje meg, hogy a teszt pirosra vált. Jelentse az elkészített és javított tesztek számát, valamint a talált sebezhetőségek és pszeudo-pass-ok számát.
ellenőrző lista
- [ ] Világosan megadtam az AI-nak az eszközt, a nyelvet, a kiválasztási szabályzatot és az architektúrát (POM).
- [ ] Ellenőriztem, hogy a szelektorok adatteszteltek.
- [ ] Biztosítottam, hogy az explicit/automatikus várakozást használjam a vak alvás helyett.
- [ ] Ellenőriztem, hogy minden állítás ellenőrzi a tényleges felhasználói eredményt.
- [ ] Minden tesztet a kód feltörésével teszteltem; Láttam, hogy pirosra vált.
- [ ] A teszteket a Page Object Model struktúrában gyűjtöttem össze.