Câștiguri:
- Capacitatea de a produce cod robust de testare a interfeței de utilizare cu inteligență artificială, inclusiv testarea datelor, așteptarea deschisă și afirmația care verifică rezultatul real al utilizatorului
- Abilitatea de a evita testele fragile (selector prost, așteptare oarbă) și de a face testele ușor de întreținut în structura modelului de obiecte de pagină
- Abilitatea de a testa fiecare test de interfață de utilizator produs prin spargerea codului și de a detecta și remedia testele false trecute
Fiecare clic, fiecare completare a formularului, fiecare tranziție de pagină pe care o face un utilizator într-un browser nu poate fi testată manual, de aceea, automatizarea testului UI (interfață cu utilizatorul; aceste teste imită comportamentul utilizatorului prin conducerea programatică a unui browser real) există. Seleniul, dramaturgul și Cypress sunt cele mai comune instrumente pentru această meserie. Inteligența artificială (AI) este foarte abil în scrierea codului pentru aceste instrumente: descrieți un caz de testare, AI vă oferă o schiță a unui script de automatizare funcțional. Dar aici intră din nou în joc avertismentul central al acestui modul: codul de testare al UI pe care AI-ul îl produce poate fi adesea teste fragile care „se aprind în verde, dar verifică lucrul greșit” sau clapă în vânt. Sarcina ta nu este să rulezi acest cod, ci să te asiguri că de fapt verifică în mod solid ceea ce trebuie.
În această unitate, ne propunem să producem teste de UI robuste, menținute și cu adevărat validate cu AI; Veți învăța să evitați testele fragile.
Cei trei piloni ai testării solide UI
1. Localizator corect de elemente. Un test folosește un selector pentru a găsi elementul pe pagină. AI produce adesea selectoare fragile: căi XPath lungi (adresa dependentă excesiv de structura paginii), selectoare bazate pe numele claselor CSS (se întrerupe atunci când designul se modifică). Modul robust este atributele stabile precum data-testid pe care dezvoltatorul le-a adăugat pentru testare. Impune acest lucru în mod explicit AI.
2. Așteptați explicit. Sursa numărul unu de vulnerabilitate în testarea UI este sincronizarea. Somnul constant(3) (așteptare oarbă) este o practică proastă: uneori nu este suficient, alteori pierde timpul. Modul corect este să folosiți așteptarea explicită, care spune „așteptați până când apare acest element”. Dramaturgul face acest lucru în mare parte automat; În Selenium trebuie să îl solicitați în mod explicit.
3. Afirmație semnificativă. Testul ar trebui să verifice rezultatul pe care utilizatorul îl va vedea de fapt, cum ar fi „numărul comenzii a apărut pe ecran”, nu doar „pagina încărcată”. Dacă testul produs de AI nu are o aserțiune sau este lipsit de importanță, acel test produce o pseudo-procesare (unitatea I).
Atenție: Când vedeți pentru prima dată un test de interfață de utilizator generat de AI, verificați cel mult trei lucruri: sunt selectorii activați (data-testid), sunt așteptări activate (fără repaus orb) și asserția verifică rezultatul real al utilizatorului? Dacă aceste trei sunt OK, testul este probabil solid.
Modelul obiectului paginii
Pe măsură ce testele cresc, scrierea selectoarelor în interiorul fiecărui test devine un coșmar de întreținere. Modelul de obiecte de pagină (POM — model de design care colectează selectoare și acțiuni pentru fiecare pagină/ecran într-o singură clasă) păstrează selectorul într-un singur loc; Când interfața se schimbă, o actualizați într-un singur fișier. Puneți AI să producă testele într-o structură POM, mai degrabă decât direct; Acest lucru face întreținerea radical mai ușoară.
Prompt slab / Prompt puternic
Slab: „Scrieți un test Selenium pentru pagina de conectare”.
Puternic: „Scrieți un test de flux de conectare cu Playwright (TypeScript). Selectoarele folosesc numai data-testid; nu utilizați controlul a ceea ce vede utilizatorul, nu titlul paginii.”
prompt puternic; Instrumentul oferă limbajului, politica de selecție, strategia de așteptare, arhitectura (POM) și așteptările expresive de afirmare.
Datele de testare și independența mediului
Un test de interfață de utilizare solid nu este doar scris corect, ci și construiește și curățește propriile date de testare. Testele generate de AI se leagă adesea la un utilizator sau o înregistrare despre care se presupune că există deja în mediu („conectați-vă ca utilizator admin”). Această ipoteză se întrerupe atunci când testul rulează într-un alt mediu sau după un alt test (problema de dependență a comenzii din unitatea 9). Adevărul este că fiecare test creează datele de care are nevoie la începutul testului (sau le pregătește cu un apel API) și le curăță la sfârșit. Instruiți în mod explicit AI „să configureze orice date de care depinde acest test în cadrul testului; nu presupuneți date gata făcute din exterior”.
Un alt punct critic este să nu faceți testarea UI cu date reale ale utilizatorilor. Dacă în mediul de testare se utilizează o copie a bazei de date de producție, aceste înregistrări sunt date ale unor persoane reale; capturile de ecran și înregistrările de testare pot dezvălui aceste date. Utilizați conturi de testare sintetice (fictive); atât protejează confidențialitatea, cât și face testele reproductibile. Efectuarea unui test de „anulare a comenzii” cu un cont real de client este atât o greșeală etică, cât și operațională.
Sfat: păstrați testele UI cât mai puține posibil; Lăsați verificarea efectivă pe seama API-ului și a testelor unitare, care sunt rapide și stabile. Testarea interfeței de utilizator este costisitoare și fragilă - utilizați-o doar pentru a valida fluxul utilizatorului cu adevărat end-to-end (logica piramidei de testare).
Comparație de vehicule
caracteristică
seleniu
dramaturg
chiparos
limbi
Java, C#, Python, JS
JS/TS, Python, .NET, Java
JavaScript/TypeScript
standby automat
Nu (de mână)
Da (puternic)
Da
Multi browser
larg
Chromium/Firefox/WebKit
Crom-dominant
tendință la fragilitate
Ridicat (mod standby manual)
scăzută
scăzută
Ușurința de a învăța
mediu
usor
usor
funcționare în paralel
Grilă necesară
încorporat
Rezident/plătit
Când solicitați un cod de la AI, precizați clar cărui vehicul îi aparține; În caz contrar, poate produce cod confuz, care nu funcționează.
Patru șabloane copiabile
1) Generare solidă de testare a interfeței de utilizare:
Rolul dvs.: inginer senior de automatizare a testelor. Scrieți teste cu [instrument + limbă] pentru următorul flux: [flux].Reguli: - Selectoare numai pentru testid; Folosind clasa XPath/CSS. - Fără somn orb; Utilizați așteptarea explicită/automată. - Aplicați modelul obiectului paginii. - Lăsați fiecare afirmație să verifice rezultatul real al utilizatorului. Comentați la începutul fiecărui test ce criterii de acceptare validați.
2) Controlul fragilității:
Examinați următorul test UI pentru fragilitate: - Există un selector instabil (lung
3) Conversie în obiect pagină:
Convertiți următorul cod simplu de testare în structura Page Object Model. Mutați selectoare și acțiuni în clase de pagină; Lăsați fișierul de testare să citească doar fluxul scenariului. [Instrument/limbă].Cod: [paste code]
4) Dovada pseudo-tranziției:
Demonstrați că acest test de interfață de utilizator validează de fapt: Ce modificare unică fac codului aplicației care va transforma acest test în ROȘU? Dacă nu puteți găsi o modificare care va întrerupe testul, testul este inadecvat; adăugați afirmațiile lipsă.Test: [paste test]
trei mini cutii
Cazul 1 — Eliberarea de selectorul fragil. Din cele 40 de teste pe care o echipă le-a produs cu inteligență artificială, 70% au fost întrerupte după o actualizare a interfeței; niciunul dintre ele nu era bug-uri reale, toate erau selectoare XPath fragile. Echipa a convertit testele într-o bază de date-testid cu șablonul „verificarea fragilității”. În următoarele trei actualizări ale interfeței, numărul de întreruperi false a scăzut la zero; timpul de întreținere a scăzut de la 6 ore la 30 de minute pe săptămână.
Cazul 2 — Test de interfață de utilizare falsă. AI a produs un test „adăugați în coș”; testul a fost verde. Când a fost rulat șablonul „dovada de trecere falsă”, testul a părut să verifice doar clicul butonului și titlul paginii, fără a verifica niciodată dacă contorul coșului a crescut sau nu. Chiar dacă logica căruciorului a fost complet ruptă, testul a trecut. S-a adăugat afirmația adevărată (insigna coșului fiind „1”).
Cazul 3 — Capcană de așteptare oarbă. În testul Selenium produs de AI, a existat somn(2) după fiecare pas; 60 de teste au durat 14 minute și încă s-au rupt ocazional. După trecerea la deschidere așteptați (așteptați ca elementul să fie clicat) timpul a scăzut la 5 minute și fragilitatea a dispărut. Așteptarea oarbă a fost atât lentă, cât și nesigură.
Greșeli comune
- De acord cu selectorii fragili. Folosind XPath-urile lungi generate de AI ca atare; Testele se blochează la prima modificare a interfeței.
- Lăsând „somnul” orb. „Rezolvarea” timpului cu o așteptare fixă; atât lent, cât și nehotărât.
- Afirmație banală. Doar verificați dacă pagina s-a încărcat; nu se verifică rezultatul real al utilizatorului (fake-pass).
- Creșteți fără POM. Distribuiți selectoare pentru fiecare test; Actualizarea manuală a zeci de fișiere atunci când interfața se schimbă.
- Nu se specifică instrumentul. Nu spuneți AI ce instrument/limbă doriți; devine cod dezordonat, care nu funcționează.
- Încredere când rulați codul generat și treceți. Nu testează prin spargerea codului.
În concluzie
Automatizarea testării UI verifică comportamentul utilizatorului prin conducerea browserului real cu programul. AI generează acest cod rapid, dar există două mari capcane: teste fragile (selector prost, așteptare oarbă) și teste false de trecere (afirmare incompletă/trivială). Cei trei piloni ai testării solide UI sunt selectorul de comitere (data-testid), așteptarea explicită și afirmația care verifică rezultatul real al utilizatorului. Testele generate în modelul de obiecte de pagină simplifică radical întreținerea. Testați fiecare test generat cu întrebarea „ce schimbare va distruge asta?”
Sarcina de aplicare
Selectați un flux de utilizator din propriul proiect (de exemplu, autentificare sau căutare). Puneți AI să scrie teste cu șablonul „generare robustă a testelor UI”. Apoi: (1) verificați și fixați selectoarele și așteaptă cu un „verificare de fragilitate”, (2) dovediți că fiecare test validează efectiv cu o „dovadă de pseudo-trecere”, (3) spargeți codul și observați că testul devine roșu. Raportați numărul de teste produse și corectate, precum și numărul de vulnerabilități și pseudo-passări pe care le-ați găsit.
lista de verificare
- [ ] Am oferit AI instrumentul, limbajul, politica de selecție și arhitectura (POM) în mod clar.
- [ ] Am verificat că selectoarele sunt testate de date.
- [ ] M-am asigurat că folosesc așteptarea explicită/automată în loc de somn orb.
- [ ] Am verificat că fiecare afirmație verifică rezultatul real al utilizatorului.
- [ ] Am testat fiecare test prin spargerea codului; Am văzut că s-a făcut roșu.
- [ ] Am colectat testele în structura Page Object Model.