Câștiguri:
- Abilitatea de a transforma o cerință și un criteriu de acceptare în cazuri de testare cuprinzătoare cu tehnici precum clase de echivalență, analiză a valorii limită și tabele de decizie, cu sprijinul inteligenței artificiale
- Abilitatea de a produce separat scenarii pozitive, negative și marginale și de a completa cazurile marginale ratate de inteligența artificială cu informații despre produs
- Capacitatea de a stabili trasabilitatea și de a elimina golurile de acoperire și balonarea inutilă prin legarea cazurilor de testare la criteriile de acceptare
Treaba testerului începe adesea cu această tablă goală: are o cerință („utilizatorul trebuie să-și poată reseta parola”) și trebuie să transforme această singură propoziție în zeci de verificări concrete care să demonstreze că software-ul funcționează de fapt corect. Această transformare se numește proiectare de testare. Cunoașterea diferenței dintre un scenariu de testare – un obiectiv de nivel înalt care descrie ce trebuie testat, cum ar fi „parola invalidă ar trebui respinsă” – și un caz de testare – o unitate executabilă care detaliază acel scenariu cu pași concreti, intrări și rezultatul așteptat este esențială. Inteligența artificială (AI) accelerează exact acest moment de pagină goală: transformând o cerință în zeci de scenarii schițe în câteva secunde. Dar amintiți-vă — AI reproduce situațiile la care vă puteți gândi; Tu alegi cu cunoștințele tale despre produs care situații sunt cu adevărat importante.
În această unitate, veți învăța pas cu pas cum să transformați o cerință într-o suită de testare cuprinzătoare, dar fără dezordine, cu suport AI.
Pas cu pas: de la cerință la set de testare
Pasul 1 — Clarificați cerința. Colectați criteriile de acceptare (condiții pe care trebuie să le îndeplinească un loc de muncă pentru a fi considerat „terminat”) înainte de a oferi IA cerința brută. „Parola trebuie să fie resetabilă” nu este suficient; Reguli precum „linkul de resetare este valabil timp de 30 de minute”, „aceeași parolă nu poate fi reutilizată” sunt sursa testului real.
Pasul 2 — Implementați tehnici de testare. Nu spune doar „scrie un script” despre AI; Solicitați tehnici clasice de proiectare a testelor după nume:
- Clase de echivalență (partiționare de echivalență): Împărțirea intrărilor în grupuri despre care se așteaptă să producă același comportament. De exemplu, pentru câmpul de vârstă, „interval valid”, „prea mic” și „prea mare” sunt clase; Testarea unui exemplu din fiecare clasă este suficientă.
- Analiza valorii limită: testarea valorilor prag pe baza faptului că erorile apar cel mai mult la granițe. Este ca și cum ai testa 17, 18, 19 ani separat pentru limita de vârstă de 18 ani.
- Tabel de decizie: Tabularea combinațiilor de mai multe condiții și rezultatul așteptat al fiecărei combinații.
- Tranziție de stare: testarea tranzițiilor sistemului de la stare la stare (de exemplu, comandă: creat → plătit → expediat) și tranziții invalide.
Pasul 3 — Separați stările pozitive, negative și marginale. Solicitați un test pozitiv (rezultat așteptat cu introducere corectă), un test negativ (eroare corectă cu introducere nevalidă) și un caz marginal - cazuri limită sau neobișnuite. AI accentuează în general pozitivul; Cazurile negative și marginale sunt incomplete, cu excepția cazului în care le solicitați în mod explicit.
Pasul 4 — Prioritizează și tunde. AI poate genera 60 de scenarii; Nu sunt toate de aceeași valoare. Acordați prioritate celor cu risc ridicat (bani, securitate, pierderi de date) și combinați-le pe cele care sunt duplicate.
Sfat: Trimiteți o solicitare separată către AI, spunând „generați 5 cazuri marginale de neconceput din această cerință”. Cea mai valoroasă contribuție a AI este că îți amintește adesea de situații extraordinare pe care le-ai trecut cu vederea.
Prompt slab / Prompt puternic
Slab: „Scrieți cazuri de testare pentru resetarea parolei”.
Puternic: „Generează cazuri de testare pentru caracteristica „resetare parolă” cu următoarele criterii de acceptare: link valabil timp de 30 de minute, de unică folosință, ultimele 3 parole nu pot fi reutilizate, contul blocat timp de 15 minute după 5 încercări incorecte. Aplicați clase de echivalență și analiza valorii limită. Dați cazuri pozitive, negative și marginale în titluri separate, date așteptate, pasul de identificare a rezultatului, precondiție: Evidențiați scenariile de securitate/blocare.
prompt puternic; Oferă reguli, tehnici, format de ieșire și ordine de prioritate. Astfel, AI produce cazuri de testare executabile și urmăribile, nu decorative.
Format de ieșire a cazului de testare
Solicitați un format structurat care poate fi importat direct în instrumentul de gestionare a testelor al echipei dvs. (de exemplu, TestRail, Zephyr, Xray). Următorul tabel prezintă componentele unui caz de testare bun:
zona
Descriere
exemplu
ID
ID unic
TC-PWD-014
Titlu
scop scurt
Linkul expirat va fi respins
condiție prealabilă
Condiție necesară înainte de testare
Linkul de resetare a fost generat acum 31 de minute
trepte
Acțiuni secvențiale
1. Faceți clic pe linkul 2. Introduceți o nouă parolă
date de testare
Valori concrete utilizate
link vechi, parolă nouă „Abc!2345”
rezultatul așteptat
Comportament de verificat
Eroare „Link a expirat”, parola nu se modifică
Criterii de acceptare
legătura de trasabilitate
AK-3: link valabil 30 de minute
prioritate
Nivel de risc
înalt
Patru șabloane copiabile
1) Producție de scenarii bazate pe tehnică:
Rolul dvs.: designer senior de testare. Generați cazuri de testare pentru caracteristică: [funcție și criterii de acceptare]. Aplicați: clase de echivalență, analiză puncte de întrerupere, tabel de decizie. Oferiți rezultate în 3 grupuri: Pozitiv / Negativ / Caz marginal. Fiecare caz: ID, precondiție, pași, date de testare, rezultat așteptat, criterii de acceptare asociate, prioritate (Ridicat/Mediu/Scăzut).
2) Vanator de cazuri Edge:
Listați 10 cazuri de margine care în mod normal sunt trecute cu vederea pentru următoarea caracteristică: [funcție]. Scrieți într-o singură propoziție de ce este riscant pentru fiecare. Gândiți-vă la axe precum gol/null, introducere prea lungă, concurență, timeout, erori de format, Unicode/emoji, negativ/zero, întrerupere a rețelei.
3) Producerea tabelului de decizie:
Creați tabel de decizie pentru următoarea regulă de afaceri: [reguli].Coloane: combinații de condiții; rânduri: fiecare condiție și acțiune așteptată. Semnalați combinații irealizabile sau conflictuale. Apoi propuneți un caz de testare pentru fiecare combinație.
4) Controlul trasabilității:
Având în vedere următoarea listă de criterii de acceptare și următoarele cazuri de testare: [criterii] / [cazuri]. Arătați în formă tabelară care criterii de acceptare sunt îndeplinite de NU cazuri de testare (decalaj de acoperire) și care cazuri nu sunt îndeplinite de niciun criteriu (caz redundant).
trei mini cutii
Cazul 1 — Valoarea stărilor marginilor. Un expert dintr-o echipă fintech a scris 18 scripturi pentru funcția de transfer de bani. El a aplicat șablonul „edge case hunter” la AI; AI a reamintit situația „transferării aceluiași sold de pe două dispozitive în același timp” (concurență). Când acest scenariu a fost testat, a fost găsită o vulnerabilitate de cheltuieli duble și a fost închisă înainte de a intra în funcțiune. O singură situație marginală a prevenit o potențială pierdere de șase cifre.
Cazul 2 — Tăierea umflăturii. O echipă a solicitat AI să producă un scenariu pentru formularul de membru și au ajuns 74 de cazuri. Rularea șablonului de trasabilitate a constatat că 74 de cazuri au îndeplinit doar 9 criterii de acceptare, multe dintre acestea retestând aceeași clasă de echivalență. Setul a fost redus de la 74 la 23 de cazuri semnificative; timpul de rulare a scăzut cu 68%, acoperirea nu a scăzut.
Cazul 3 — Ipoteza greșită. AI a sugerat testarea unor date nevalide precum „31 februarie” pentru un câmp de dată, dar nu știa că componenta de calendar pe care o folosea echipa a blocat deja acest lucru. Expertul a eliminat 4 din cele 6 scenarii de date produse de AI ca fiind inutile în contextul produsului. posibilități generate de AI; a făcut o selecție de informații despre produs.
Greșeli comune
- Solicitarea unui script fără a oferi criterii de acceptare. Fără să știe ce este adevărat, AI produce scenarii superficiale care deseori scapă riscul real.
- Mă mulțumesc doar cu testele pozitive. Nu doresc în mod explicit cazuri negative și marginale. Aici se află adesea erorile.
- Acceptând ceea ce este produs așa cum este. Uitând că AI nu cunoaște contextul produsului și lăsând scenarii inutile sau imposibile pe platou.
- Ocolind trasabilitatea. Nelegarea cazurilor cu criteriile de acceptare; ca urmare, nu se vede care criteriu nu este testat (decalaj de acoperire).
- Eroare de cantitate. Fiind fericit pentru că „au fost lansate 60 de scenarii”. Valoarea nu este în număr, ci în sfera care acoperă riscul.
În concluzie
Proiectarea testului se referă la traducerea unei cerințe de o singură propoziție în cazuri concrete, executabile, care dovedesc corectitudinea software-ului. AI accelerează foarte mult această transformare: produce planuri cuprinzătoare atunci când îi oferiți criterii de acceptare, tehnici clasice de testare (clase de echivalență, punct de întrerupere, tabel de decizie, tranziție de stări) și un format de ieșire clar. Dar AI este părtinitoare spre pozitiv, nu cunoaște contextul produsului și poate produce balonare inutilă. Sarcina ta este de a solicita în mod explicit cazuri negative și marginale, de a stabili trasabilitatea, de a prioritiza în funcție de risc și de a tăia.
Sarcina de aplicare
Alegeți o caracteristică din propriul proiect și notați criteriile de acceptare. Puneți AI să genereze cazuri de testare cu șablonul „generare de scenarii bazate pe tehnică”. Apoi aplicați șabloanele „vânător de cazuri marginale” și „verificarea trasabilității”. Ca rezultat: (1) adăugați cel puțin 3 cazuri marginale pe care AI le omite, (2) tăiați cazurile care nu se conectează la niciun criteriu de acceptare, (3) scrieți cazuri noi dacă există criterii de acceptare rămase netestate. Turnați setul final într-o foaie de calcul.
lista de verificare
- [ ] Înainte de a solicita un script, am clarificat criteriile de acceptare.
- [ ] I-am cerut lui YZ clase de echivalență și analiza valorii la limită după nume.
- [ ] Am generat separat stări pozitive, negative și margine.
- [ ] Am legat fiecare caz de testare la un criteriu de acceptare (trasabilitate).
- [ ] Am verificat decalajul domeniului de aplicare și cazurile inutile cu tabelul.
- [ ] Am prioritizat după risc și am tăiat setul umflat.