Dobički:
- Sposobnost branja meritev, kot so linija, veja in pokritost pogojev, kot zemljevid, ne zaupanje, in razumevanje, da lahko visoka pokritost daje psevdozaupanje
- Zmožnost postaviti obseg zahteve poleg obsega kode in narediti vrzeli v sledljivosti vidne z umetno inteligenco
- Sposobnost točkovanja funkcij s formulo tveganje = verjetnost × vpliv, usmerjanje omejenega testiranja na največje tveganje in dokumentiranje namernega izven obsega
Vsake programske opreme ne morete preizkušati večno; Čas in viri so omejeni. Torej je pravo vprašanje: kam vložiti omejen trud pri testiranju? Na to vprašanje odgovarjata dva koncepta. Pokritost testa – metrika, ki meri, koliko kode ali zahtev se dotaknejo testi – predstavlja, kaj se testira. Testiranje na podlagi tveganja – pristop določanja prioritete testa glede na verjetnost propadanja območja in škodo, ki jo bo povzročilo ob poslabšanju – usmerja trud k največjemu tveganju. Umetna inteligenca (AI) je zmogljiv partner pri analizi pri obeh: naredi vidne vrzeli v pokritosti, predlaga področja tveganja. Toda osrednje opozorilo ostaja: število obsegov, ki jih vidi AI, je lahko zavajajoče; Celo 100-odstotno pokritost vrstic je mogoče doseči s testi, ki ne preverjajo ničesar. Vaša naloga je brati obseg kot zemljevid, ne kot zaupanje.
Pravilno branje meritev pokritosti
Obstaja več vrst obsega in niso vsi enako pomembni:
- Pokritost vrstice: Koliko vrstic kode je bilo izvedenih vsaj enkrat. Najpogostejši, a najšibkejši kriterij; Samo zato, ker linija deluje, še ni dokaz, da se obnaša pravilno.
- Pokritost veje: Ali je bila preizkušena vsaka veja if (tako resnična kot neresnična). Bolj pomenljivo kot črta.
- Pokritost pogojev: Testiranje vsakega podpogoja v zapletenih pogojih posebej.
- Pokritost poti: Kombinacije logičnih poti znotraj kode. Je najobsežnejši, vendar ga je v praksi težko v celoti doseči.
Pozor: odstotek pokritosti ni "ocena kakovosti". 100-odstotna pokritost vrstic vam pove, da vrstice delujejo; ne da daje pravilen rezultat (psevdo-prehod v enoti 1). Uporabite obseg kot odgovor na vprašanje "kje še nisem pogledal", ne kot zagotovilo, da je "vse preizkušeno".
Obseg slepih točk
Meritve pokritosti merijo le, koliko kode je bilo izvedenega; ne vidi: (1) nepreizkušenih zahtev (koda obstaja, vendar je poslovno pravilo napačno), (2) manjkajoče kode (ni možnosti za nadzor, ki ni bil nikoli napisan), (3) kombinacij podatkov/stanja, (4) uporabnosti, zmogljivosti, varnosti. Zato je treba pokritost zahteve (vsako merilo sprejemljivosti mora izpolniti vsaj en test) postaviti poleg pokritosti kode. AI je zelo koristen pri izdelavi preslikave zahtev-test (matrika sledljivosti).
Testiranje na podlagi tveganja: kam vlagamo trud?
Tveganje = verjetnost (možnost zloma) × vpliv (škoda v primeru zloma). Z AI lahko točkujete seznam funkcij na teh dveh oseh in ustvarite toplotni zemljevid. Visoka verjetnost × visoke domene (plačilo, avtentikacija, celovitost podatkov) si zaslužijo najintenzivnejše testiranje; nizka × nizka območja (redko uporabljen zaslon s prednostmi) zadostuje testiranje svetlobe.
območje
verjetnost
Vpliv
Tveganje
Testna gostota
Tok plačila
srednje
zelo visoko
visoka
Globina + avtomatizacija
avtentikacija
srednje
zelo visoko
visoka
Globina + varnost
Iskanje izdelkov
visoka
srednje
Srednje visoka
Avtomatizacija + odkrivanje
Profilna fotografija
nizka
nizka
nizka
nadzor svetlobe
Stran s pomočjo
nizka
prenizka
prenizka
pregled
Past lovljenja obsega
Postavljanje odstotka pokritosti za cilj (npr. pravilo »ekipa mora prestati 90-odstotno pokritost«) ima nevaren stranski učinek: razvijalci in preizkuševalci se osredotočajo na povečanje odstotka, namesto da bi obravnavali dejansko tveganje. Rezultat je pogosto napihnjen obseg brez trditev ali nepomembnih testov - številka je videti lepa, vendar ni zaščite. To je fenomen pokvarjenosti merila, ko sam postane cilj: »ko merilo postane cilj, preneha biti dobro merilo«. Uporabite obseg kot diagnostično orodje, ne kot poročilo o uspešnosti.
Bolj zdrav pristop je usmerjeno branje obsega: "Zakaj je pokritost podružnice obstala pri 40 % v kritičnem plačilnem modulu?" Vprašanje je "ali je skupna pokritost 90%?" To je veliko bolj vredno kot vprašanje. Naj AI razčleni poročilo o obsegu po modulu in ravni tveganja; Označite področja z visokim tveganjem z nizko pokritostjo. Tako obseg postane kompas, ki usmerja delo in ne slepi odstotek.
Pozor: slogan "100% pokritost" je past. Testiranje neke kode (preprosti dostopniki, samodejno generirani deli) je nizke vrednosti; trud, vložen tam, je ukraden iz visoko tveganih poslovnih pravil. Cilj je preizkusiti vsako pomembno vedenje in tveganje, ne vsake vrstice.
Šibek poziv/močan poziv
Šibko: »Povečaj mojo pokritost s testiranjem.«
Močno: "Glede na ta seznam meril sprejemljivosti in te obstoječe preskusne primere. (1) Tabelarično, katera merila sprejemljivosti niso bila izpolnjena z nobenim testom (vrzel v pokritosti zahteve). (2) Vsako funkcijo ocenite z 1-5 na oseh verjetnosti in vpliva; razvrstite glede na tveganje = verjetnost × učinek. (3) Za moj omejen čas predlagajte, katerih 5 vrzeli naj najprej zapolnim, začenši z največjim tveganjem. Ne jemljite pokritosti vrstice kode kot edinega merilo; določite prednostno poslovno tveganje: [...] Testi: [...]"
Močan poziv; združuje obseg s poslovnim tveganjem in daje prednost omejenemu delu.
Štiri predloge za kopiranje
1) Vrzel v obsegu zahteve:
Glede na naslednja merila sprejemljivosti in te testne primere. Izdelajte tabelo sledljivosti: vsak kriterij -> test(-i), ki ga izpolnjujejo. Kriteriji, ki nimajo nobenih preizkusov, se imenujejo "COVEREAGE GAP", testi, ki niso povezani z nobenim kriterijem, pa se imenujejo "POTREBNO?" Ocena: Kriteriji: [...] / Testi: [...]
2) Točkovanje tveganja:
Ta seznam funkcij/modulov ocenite z ocenami 1–5 na oseh verjetnosti (verjetnost zloma) in udarca (poškodba, če se zlomi). Tveganje = verjetnost × učinek. Razvrstite v tabelo in določite priporočeno vrsto testiranja (enota/API/UI/izvidovanje/varnost) za vsako območje z visokim tveganjem. Seznam: [...]
3) Razlaga obsega:
Podano je bilo naslednje poročilo o pokritosti (vrstica %, veja %). Povejte mi naslednje: - Česa te številke NE dokazujejo? - Katera področja bi lahko bila ogrožena kljub visoki pokritosti vrstic? - Kakšno dodatno testiranje bi priporočili za vrzeli, ki jih pokritost ne vidi (zahteva, kombinacija podatkov, varnost)? Poročilo: [prilepi]
4) Časovno omejen načrt:
Še [X ur] do oddaje. Podane so naslednje razvrstitve tveganj in vrzeli v kritju. V tem obdobju se po prioritetnem vrstnem redu pripravi testni načrt, ki bo zmanjšal maksimalno tveganje. Jasno navedite, česa NE zavestno testirati, in sprejeto tveganje pri tem. Podatki: [...]
trije mini kovčki
Primer 1 — 100 % pokritost, nič zaupanja. Ena ekipa se je ponašala s 94-odstotno pokritostjo linije. Analiza "razlage obsega" je pokazala, da je bila večina testov brez trditev, kar pomeni, da so izvajali vrstice, vendar niso ničesar preverjali. Dejanska zaščitna pokritost je bila precej nižja. Ekipa se ni osredotočila na številke, ampak na testiranje mutacij (enota 10); dejanska stopnja ulova napak se je podvojila.
Primer 2 – popravljena prioriteta karte tveganja. Ena ekipa je porabila 40 % svojega truda pri testiranju na redko uporabljenem zaslonu za poročanje, pri čemer je preskočila tok plačila, ker "preprosto deluje". Točkovanje tveganja AI je pokazalo to neravnovesje. Delo je bilo prerazporejeno; Dva tedna kasneje je bila v toku plačila najdena hrošča, ki je močno vplivala, in je bila zaprta pred objavo.
Primer 3 – Zavest izven obsega. 4 ure po izidu se je ekipa odločila, kaj bo testirala in kaj zavestno preskočila s predlogo »omejen urnik«. Globoko sta bila testirana dva toka z visokim tveganjem; zaslon z nizkim tveganjem je bil dokumentiran kot "sprejeto tveganje" in preskočen. Odločitev je bila transparentna in obrazložena; Različica je prišla varno.
Pogoste napake
- Zamenjali odstotek pokritosti s kakovostjo. Branje visoke pokritosti vrstic kot "preizkušenega" zagotovila.
- Samo gledam pokritost kode. Preskok kritja zahtev (testiranje vsakega kriterija sprejemljivosti).
- Enako testiranje brez upoštevanja tveganja. Razporejanje dela na območja z nizkim tveganjem in zanemarjanje kritičnih tokov.
- Skrivanje izven obsega. Nedokumentiranje tistega, kar ni bilo testirano, ko ni bilo dovolj časa; Presenečenja po izidu.
- Brez dvoma sprejema oceno tveganja AI. AI ne pozna v celoti konteksta izdelka; Prilagodite rezultate s strokovnim očesom.
Če povzamem
Pokritost testa in testiranje na podlagi tveganja sta dve orodji za usmerjanje omejenega truda na pravo mesto. Meritve pokritosti (linija, veja, stanje, pot) kažejo, česa so se dotaknili, vendar ne dokazujejo, da se je obnašal pravilno; Obseg je zemljevid, zaupanje pa ne. Pokritost zahtev postavite poleg pokritosti kode. Ocenite funkcije s formulo tveganje = verjetnost × učinek in usmerite prizadevanja na največje tveganje. AI naredi vrzeli vidne, oceni tveganje, načrtuje omejen čas; vendar je končna prednostna odločitev in odločitev o "zavestni zavrnitvi" pri strokovnjaku, ki pozna poslovni kontekst.
Aplikacijska naloga
Izberite modul iz lastnega projekta. Zaženite predlogo »requirements scope gap« z AI in ugotovite, katera merila sprejemljivosti niso testirana. Nato razvrstite podznačilnosti modula na oseh verjetnost × vpliv z "točkovanjem tveganja". Razporedite (hipotetične) 3 ure časa za testiranje, ki ga imate, z "omejenim urnikom"; Zapišite, česa zavestno ne boste testirali, in sprejeto tveganje. Dodajte konkreten test, ki bo zapolnil vrzel v kritju z največjim tveganjem, ki jo najdete.
kontrolni seznam
- [ ] Odstotek pokritosti berem kot zemljevid, ne kot kakovost.
- [ ] Poleg pokritosti kode sem odstranil tudi pokritost z zahtevami.
- [ ] Funkcije sem ocenil glede na verjetnost × učinek in jih razvrstil glede na tveganje.
- [ ] Preizkušanje sem preusmeril na največje tveganje.
- [ ] Dokumentiral sem področja, ki niso zavestno testirana in priznana tveganja.
- [ ] Pregledal sem ocene tveganja umetne inteligence glede na kontekst svojega izdelka.