Fitimet:
- Aftësia për të lexuar metrika të tilla si mbulimi i linjës, degëve dhe kushteve si një hartë, jo një besim, dhe për të kuptuar se mbulimi i lartë mund të japë pseudo-besim
- Aftësia për të vendosur shtrirjen e kërkesave pranë fushës së kodit dhe për të bërë të dukshme boshllëqet e gjurmueshmërisë me inteligjencën artificiale
- Aftësia për të shënuar veçori me formulën rrezik = probabilitet × ndikim, drejton përpjekjet e kufizuara të testimit drejt rrezikut më të lartë dhe dokumentimi i qëllimshëm jashtë fushëveprimit
Ju nuk mund të testoni çdo softuer përgjithmonë; Koha dhe burimet janë të kufizuara. Pra, pyetja e vërtetë është: ku të vendosni përpjekjet e kufizuara të testimit? Dy koncepte i përgjigjen kësaj pyetjeje. Mbulimi i testit - një metrikë që mat se sa nga kodi ose kërkesat preken nga testet - përfaqëson atë që po testohet. Testimi i bazuar në rrezik - qasja e përcaktimit të përparësisë së provës sipas probabilitetit të përkeqësimit të një zone dhe dëmit që do të shkaktojë kur përkeqësohet - e drejton përpjekjen drejt rrezikut më të madh. Inteligjenca artificiale (AI) është një partner i fuqishëm i analizës në të dyja: i bën të dukshme boshllëqet e mbulimit, sugjeron zonat e rrezikut. Por paralajmërimi qendror mbetet: numri i fushëveprimit që AI sheh mund të jetë mashtrues; Edhe mbulimi 100% i rreshtave mund të arrihet me teste që nuk verifikojnë asgjë. Detyra juaj është të lexoni fushëveprimin si një hartë, jo një besim.
Leximi i saktë i metrikës së mbulimit
Ka disa lloje të fushëveprimit, dhe jo të gjitha janë njësoj kuptimplotë:
- Mbulimi i linjës: Sa rreshta kodi janë ekzekutuar të paktën një herë. Kriteri më i zakonshëm, por më i dobët; Vetëm për shkak se një linjë funksionon nuk është provë se ajo sillet siç duhet.
- Mbulimi i degës: Nëse çdo degë nëse (si e vërtetë ashtu edhe e rreme) është testuar. Më kuptimplotë se një rresht.
- Mbulimi i gjendjes: Testimi i secilit nënkusht në kushte komplekse veç e veç.
- Mbulimi i rrugës: Kombinimet e shtigjeve logjike brenda kodit. Është më gjithëpërfshirësi, por i vështirë për t'u arritur plotësisht në praktikë.
Kujdes: Përqindja e mbulimit nuk është një "rezultat i cilësisë". Mbulimi 100% i rreshtave ju tregon se rreshtat po funksionojnë; jo se prodhon rezultatin e saktë (pseudokalimi në njësinë 1). Përdorni shtrirjen si përgjigje për pyetjen "ku nuk kam shikuar kurrë", jo si një siguri se "gjithçka është testuar".
Fusha e pikave të verbër
Metrikat e mbulimit masin vetëm sa nga kodi është ekzekutuar; nuk mund të shohë: (1) kërkesat e patestuara (ekziston kodi, por rregulli i biznesit është i gabuar), (2) kodi që mungon (nuk ka hapësirë për një kontroll që nuk është shkruar kurrë), (3) kombinimet e të dhënave/gjendjes, (4) përdorshmëria, performanca, siguria. Prandaj, mbulimi i kërkesës (çdo kriter pranimi duhet të plotësohet nga të paktën një test) duhet të vendoset pranë mbulimit të kodit. AI është shumë e dobishme në prodhimin e hartës së testit të kërkesave (matrica e gjurmueshmërisë).
Testimi i bazuar në rrezik: ku t'i bëjmë përpjekjet?
Rreziku = probabiliteti (mundësia e thyerjes) × ndikimi (dëm nëse thyhet). Me AI, ju mund të shënoni një listë karakteristikash në këto dy akse dhe të krijoni një hartë të nxehtësisë. Probabiliteti i lartë × domenet e larta (pagesa, vërtetimi, integriteti i të dhënave) meritojnë testimin më intensiv; Zonat e ulëta × të ulëta (një ekran preferencial i përdorur rrallë) është i mjaftueshëm.
zonë
probabiliteti
Ndikimi
Rreziku
Dendësia e provës
Rrjedha e pagesave
e mesme
shumë e lartë
lartë
Automatizimi i thellë +
vërtetimi
e mesme
shumë e lartë
lartë
Thellë + siguri
Kërkimi i produktit
lartë
e mesme
Mesatar-Lartë
Automatizimi + zbulim
Foto e profilit
të ulëta
të ulëta
të ulëta
kontrollin e dritës
Faqja e ndihmës
të ulëta
shumë i ulët
shumë i ulët
rishikim
Kurthi i kërkimit të fushës
Bërja e përqindjes së mbulimit në një objektiv (p.sh. rregulli "ekipi duhet të kalojë 90% mbulim") ka një efekt anësor të rrezikshëm: zhvilluesit dhe testuesit fokusohen në rritjen e përqindjes dhe jo në adresimin e rrezikut aktual. Rezultati është shpesh një hapësirë e fryrë pa pohime ose teste të parëndësishme - numri duket i bukur, por nuk ka mbrojtje. Ky është fenomeni i korruptimit të kriterit kur ai vetë bëhet qëllim: "kur një masë bëhet qëllim, ai pushon së qeni një masë e mirë". Përdorni fushëveprimin si një mjet diagnostikues, jo një kartë raporti të performancës.
Një qasje më e shëndetshme është të lexoni qëllimin në mënyrë të drejtuar: "Pse mbulimi i degës është mbërthyer në 40% në modulin kritik të pagesës?" Pyetja është "a është mbulimi i përgjithshëm 90%?" Është shumë më e vlefshme se pyetja. Lërini AI të zbërthejë raportin e fushëveprimit sipas modulit dhe nivelit të rrezikut; Theksoni zonat me rrezik të lartë me mbulim të ulët. Kështu, qëllimi bëhet një busull që drejton punën dhe jo një përqindje e verbër.
Kujdes: Slogani "mbulim 100%" është një kurth. Testimi i disa kodeve (aksesorë të thjeshtë, pjesë të gjeneruara automatikisht) është me vlerë të ulët; përpjekja e shpenzuar atje është vjedhur nga rregullat e biznesit me rrezik të lartë. Qëllimi është të testoni çdo sjellje dhe rrezik të rëndësishëm, jo çdo linjë.
Prompt i dobët / Prompt i fortë
E dobët: "Rrisni mbulimin tim të testimit."
E fortë: "Duke pasur parasysh këtë listë të kritereve të pranimit dhe këto raste testimi ekzistuese. (1) Tabelore të cilat kritere pranimi nuk janë përmbushur nga asnjë test (hendeku i mbulimit të kërkesës). (2) Vlerëso çdo veçori 1-5 në akset e probabilitetit dhe ndikimit; renditje sipas rrezikut = probabilitetit × ndikimit. (3) Për kohën time të kufizuar, duhet të sugjeroj se cilat gaps të kodit të parë nuk mbulohen nga 5 rreshti më i lartë. kriteri i vetëm për prioritizimin e rrezikut të biznesit: [...] Testet: [...]"
Prompt i fuqishëm; kombinon fushëveprimin me rrezikun e biznesit dhe i jep përparësi punës së kufizuar.
Katër shabllone të kopjueshëm
1) Hendeku i fushës së kërkesës:
Duke pasur parasysh kriteret e mëposhtme të pranimit dhe këto raste testimi. Krijoni një tabelë gjurmueshmërie: çdo kriter -> test(et) që e plotësojnë atë. Kriteret që nuk kanë asnjë test quhen "MBUSHËSIA E MBUSHJES" dhe testet që nuk lidhen me asnjë kriter quhen "NEVOJSHME?" Shënoni: Kriteret: [...] / Testet: [...]
2) Vlerësimi i rrezikut:
Shënoni këtë listë të veçorive/moduleve 1-5 në akset e probabilitetit (mundësisë për t'u thyer) dhe ndikimit (dëmtimi nëse prishet). Rreziku = probabiliteti × ndikimi. Renditni në një tabelë dhe specifikoni llojin e rekomanduar të testimit (njësi/API/UI/zbulim/siguri) për çdo zonë me rrezik të lartë. Lista: [...]
3) Interpretimi i fushëveprimit:
Është dhënë raporti i mëposhtëm i mbulimit (rreshti %, dega %). Më thuaj këtë:- Çfarë NUK vërtetojnë këta numra?- Cilat janë zonat që mund të jenë në rrezik pavarësisht mbulimit të lartë të rreshtave?- Çfarë testimi shtesë do të rekomandonit për boshllëqet që mbulimi nuk i sheh (kërkesa, kombinimi i të dhënave, siguria)? Raportoni: [ngjit]
4) Plani me kohë të kufizuar:
[X orë] kanë mbetur deri në transmetim. Janë dhënë renditjet e mëposhtme të rrezikut dhe boshllëqet e mbulimit. Gjatë kësaj periudhe përgatitet sipas prioritetit plani i testimit që do të ulë rrezikun maksimal. Tregoni qartë se çfarë NUK duhet testuar me vetëdije dhe rrezikun e pranuar për ta bërë këtë. Të dhënat: [...]
tre mini kuti
Rasti 1 — Mbulim 100%, besim zero. Një ekip u mburr me 94% mbulim të linjës. Analiza e "Interpretimit të fushës së veprimit" tregoi se shumica e testeve ishin pa pretendime, që do të thotë se ata kryenin linja, por nuk verifikuan asgjë. Mbulimi aktual mbrojtës ishte shumë më i ulët. Ekipi nuk u përqendrua në numra, por në testimin e mutacioneve (njësia 10); shkalla aktuale e kapjes së gabimit u dyfishua.
Rasti 2 — Prioriteti i korrigjuar i hartës së rrezikut. Një ekip po shpenzonte 40% të përpjekjes së tyre të testimit në një ekran raportimi të përdorur rrallë, duke anashkaluar rrjedhën e pagesave sepse "thjesht funksionon". Vlerësimi i rrezikut të AI tregoi këtë çekuilibër. Puna u rishpërnda; Dy javë më vonë një defekt me ndikim të lartë u gjet në rrjedhën e pagesave dhe u mbyll paraprakisht.
Rasti 3 - I ndërgjegjshëm jashtë fushëveprimit. 4 orë pas publikimit, ekipi vendosi se çfarë të testonte dhe çfarë të kalonte me vetëdije me shabllonin "orari i kufizuar". Dy rryma me rrezik të lartë u testuan thellë; një ekran preferencash me rrezik të ulët u dokumentua si "rreziku i pranuar" dhe u anashkalua. Vendimi ishte transparent dhe i arsyetuar; Versioni doli i sigurt.
Gabimet e zakonshme
- Gabimi i përqindjes së mbulimit për cilësinë. Leximi i mbulimit të rreshtave të lartë si siguri "e testuar".
- Vetëm duke parë mbulimin e kodit. Mbulimi i kërkesave të anashkalimit (testimi i secilit kriter pranimi).
- Testimi në mënyrë të barabartë pa marrë parasysh rrezikun. Shpërndarja e fuqisë punëtore në zona me rrezik të ulët dhe neglizhimi i flukseve kritike.
- Fshehja jashtë fushëveprimit. Mos dokumentimi i asaj që nuk u testua kur nuk kishte kohë të mjaftueshme; Surpriza pas publikimit.
- Pranimi i rezultatit të rrezikut të AI pa diskutim. AI nuk e njeh plotësisht kontekstin e produktit; Rregulloni rezultatet me një sy eksperti.
Në përmbledhje
Mbulimi i testit dhe testimi i bazuar në rrezik janë dy mjete për të drejtuar përpjekjet e kufizuara në vendin e duhur. Metrikat e mbulimit (vija, dega, gjendja, shteg) tregojnë atë që është prekur, por nuk provojnë se është sjellë si duhet; Fushëveprimi është një hartë, besimi nuk është. Vendosni mbulimin e kërkesave pranë mbulimit të kodit. Shënoni tiparet me formulën rrezik = probabilitet × ndikim dhe drejtoni përpjekjet drejt rrezikut më të madh. AI i bën të dukshme boshllëqet, shënon rrezikun, planifikon kohë të kufizuar; por përparësia përfundimtare dhe vendimi i “opt-out” i takon ekspertit që njeh kontekstin e biznesit.
Detyra e aplikimit
Zgjidhni një modul nga projekti juaj. Ekzekutoni shabllonin “Requirements Scope Gap” me AI dhe zbuloni se cilat kritere pranimi nuk janë testuar. Më pas renditni nën-veçoritë e modulit në probabilitetin × boshtet e ndikimit me "pikëzimin e rrezikut". Shpërndani 3 orë (hipotetike) të kohës së testimit që keni me "orar të kufizuar"; Shkruani atë që nuk do të testoni me vetëdije dhe rrezikun e pranuar. Shtoni një test konkret që do të mbyllë hendekun e mbulimit me rrezikun më të lartë që gjeni.
listë kontrolli
- [ ] Unë e lexova përqindjen e mbulimit si hartë, jo si cilësi.
- [ ] Përveç mbulimit të kodit, hoqa gjithashtu mbulimin e kërkesave.
- [ ] I shënova tiparet sipas probabilitetit × ndikimit dhe i rendita sipas rrezikut.
- [ ] Unë e ridrejtova përpjekjen e testimit në rrezikun më të lartë.
- [ ] Unë kam dokumentuar zona që nuk janë testuar me vetëdije dhe nuk e kam pranuar rrezikun.
- [ ] Kam rishikuar rezultatet e rrezikut të AI bazuar në kontekstin e produktit tim.