Üksus 8 / 11

Testi ulatuse analüüs ja riskipõhine testimine: tehisintellektiga õige eesmärk

Kasu:

  • Võimalus lugeda mõõdikuid, nagu liinide, harude ja seisundite katvus kaardina, mitte usaldusena, ja mõista, et suur katvus võib anda pseudousalduse
  • Võimalus panna koodi ulatuse kõrvale nõuete ulatus ja teha tehisintellekti abil jälgitavuse lüngad nähtavaks
  • Võimalus hinnata omadusi valemiga risk = tõenäosus × mõju, suunata piiratud testimistöö kõrgeima riskini ja dokumenteerida tahtlik väljaspool kohaldamisala

Iga tarkvara ei saa igavesti testida; Aeg ja ressursid on piiratud. Seega on tõeline küsimus: kuhu panna piiratud testimisjõud? Sellele küsimusele vastavad kaks mõistet. Testi katvus – mõõdik, mis mõõdab, kui suurt osa koodist või nõuetest testid puudutavad – esindab testitavat. Riskipõhine testimine – lähenemine testimise prioriteedi määramiseks vastavalt piirkonna seisundi halvenemise tõenäosusele ja kahjule, mida see halvenedes tekitab – suunab jõupingutused kõige suurema riskini. Tehisintellekt (AI) on mõlemas võimas analüüsipartner: teeb nähtavaks katvuse lüngad, soovitab riskipiirkondi. Kuid keskne hoiatus jääb alles: tehisintellekti nähtavate ulatuste arv võib olla eksitav; Isegi 100% rea katvuse saab saavutada testidega, mis ei kontrolli midagi. Teie ülesanne on lugeda ulatust kaarti, mitte usaldust.

Katvuse mõõdikute õige lugemine

Reguleerimisala on mitut tüüpi ja mitte kõik pole võrdselt tähendusrikkad:

  • Rea katvus: mitu koodirida vähemalt korra käivitati. Kõige tavalisem, kuid nõrgim kriteerium; See, et liin töötab, ei ole tõend selle korrektsest käitumisest.
  • Haru katvus: kas iga if-haru (nii tõene kui ka vale) on testitud. Mõttekam kui rida.
  • Tingimuste katvus: iga alamtingimuse katsetamine keerulistes tingimustes eraldi.
  • Tee katvus: loogiliste teede kombinatsioonid koodi sees. See on kõige põhjalikum, kuid praktikas raskesti saavutatav.
Ettevaatust. Katvuse protsent ei ole "kvaliteediskoor". 100% rea katvus näitab, et read töötavad; mitte, et see annaks õige tulemuse (pseudopääs üksuses 1). Kasutage ulatust vastusena küsimusele "kuhu ma pole kunagi vaadanud", mitte kinnitusena, et "kõik on testitud".

Uurige pimedaid kohti

Katvuse mõõdikud mõõdavad ainult seda, kui suur osa koodist on täidetud; ei näe: (1) testimata nõudeid (kood on olemas, kuid ärireegel on vale), (2) puuduv kood (pole ruumi juhtelemendi jaoks, mida pole kunagi kirjutatud), (3) andmete/oleku kombinatsioonid, (4) kasutatavus, jõudlus, turvalisus. Seetõttu tuleks koodi katvuse kõrvale asetada nõuete katvus (iga aktsepteerimiskriteerium peab olema täidetud vähemalt ühe testiga). AI on nõuete-testi kaardistamise (jälgitavusmaatriksi) loomisel väga abiks.

Riskipõhine testimine: kuhu me pingutame?

Risk = tõenäosus (purunemise võimalus) × mõju (kahju purunemisel). AI abil saate nendel kahel teljel hinnata funktsioonide loendit ja luua soojuskaardi. Suure tõenäosusega × kõrged domeenid (makse, autentimine, andmete terviklikkus) väärivad kõige intensiivsemat testimist; madala × madala ala (harva kasutatav eelistusekraan) valguse testimisest piisab.

ala

tõenäosus

Mõju

Risk

Testi tihedus

Maksevoog

keskmine

väga kõrge

kõrge

Sügav + automatiseerimine

autentimine

keskmine

väga kõrge

kõrge

Sügav + turvalisus

Tooteotsing

kõrge

keskmine

Keskmine-kõrge

Automatiseerimine + avastamine

Profiilifoto

madal

madal

madal

valguse juhtimine

Abi leht

madal

liiga madal

liiga madal

arvustus

Ulatuse tagaajamise lõks

Katvusprotsendi seadmisel eesmärgiks (nt reegel "meeskond peab läbima 90% katvuse") on ohtlik kõrvalmõju: arendajad ja testijad keskenduvad protsendi suurendamisele, mitte tegeliku riskiga tegelemisele. Tulemuseks on sageli ülespuhutud ulatus ilma väidete või triviaalsete testideta – number näeb kena välja, kuid kaitse puudub. See on nähtus, kus kriteerium on rikutud, kui ta ise muutub eesmärgiks: "kui mõõt saab eesmärgiks, lakkab see olemast hea mõõt." Kasutage ulatust diagnostikavahendina, mitte toimivusaruande kaardina.

Tervislikum lähenemine on lugeda ulatust suunatult: "Miks on filiaali katvus kriitilises maksemoodulis 40% kinni?" Küsimus on "kas üldine katvus on 90%?" See on palju väärtuslikum kui küsimus. Laske tehisintellektil jagada ulatuse aruanne moodulite ja riskitasemete kaupa; Tõstke esile madala katvusega kõrge riskiga alad. Seega muutub ulatus pigem tööjõudu suunavaks kompassiks kui pimedaks protsendiks.

Ettevaatust: loosung "100% katvus" on lõks. Mõne koodi testimine (lihtsad lisaseadmed, automaatselt genereeritud osad) on madala väärtusega; seal kulutatud vaev on varastatud kõrge riskiga ärireeglitest. Eesmärk on testida iga olulist käitumist ja riski, mitte iga rida.

Nõrk viip / Tugev viip

Nõrk: "Suurendage minu testimise ulatust."
Tugev: "Arvestades seda aktsepteerimiskriteeriumide loendit ja neid olemasolevaid testjuhtumeid. (1) Tabel, millised aktsepteerimiskriteeriumid ei vastanud ühelegi testile (nõude katvuse lünk). (2) Hinda iga omaduse tõenäosuse ja mõju telgede järgi 1–5; järjestus riski järgi = tõenäosus × mõju. (3) Minu piiratud aja puhul soovitage, millised 5 algusrida sulgeda esimesena, nii et mitte võtta koodiga lünki. kriteerium äririski tähtsuse järjekorda seadmine: [...] Testid: [...]"

Võimas viip; ühendab ulatuse äririskiga ja eelistab piiratud tööjõudu.

Neli kopeeritavat malli

1) Nõuete ulatuse lünk:

Arvestades järgmisi aktsepteerimiskriteeriume ja neid katsejuhtumeid. Koostage jälgitavuse tabel: iga kriteerium -> test(id), mis sellele vastavad. Kriteeriume, millel pole ühtegi testi, nimetatakse "KAtvuse lõheks" ja teste, mis ei seostu ühegi kriteeriumiga, nimetatakse "VAJAD?" Mark: Kriteeriumid: [...] / Testid: [...]

2) Riski hindamine:

Hinda seda funktsioonide/moodulite loendit 1–5 telgede tõenäosuse (katkenemise tõenäosus) ja löögi (kahjustuste korral purunemise korral) järgi. Risk = tõenäosus × mõju. Sorteerige tabelisse ja määrake iga kõrge riskiga piirkonna jaoks soovitatav testimise tüüp (üksus/API/UI/luure/turvalisus). Nimekiri: [...]

3) Reguleerimisala tõlgendamine:

Esitati järgmine katvuse aruanne (rida %, haru %). Ütle mulle seda:- Mida need numbrid EI tõenda?- Millised on piirkonnad, mis võivad olla ohus vaatamata suurele ridade katvusele?- Milliseid täiendavaid katseid soovitaksite lünkade puhul, mida katvus ei näe (nõue, andmekombinatsioon, turvalisus)?Aruanne: [kleebi]

4) Piiratud ajakava:

Edastuseni on jäänud [X tundi]. Esitatakse järgmine riskide järjestus ja katvuse lüngad. Sel perioodil koostatakse prioriteetsuse järjekorras testiplaan, mis vähendab maksimaalset riski. Märkige selgelt, mida MITTE teadlikult testida, ja selle tegemise aktsepteeritud risk.Andmed: [...]

kolm minikarpi

Juhtum 1 – 100% katvus, null usaldus. Üks meeskond uhkeldas 94% liini katvusega. Ulatusliku tõlgenduse analüüs näitas, et enamik teste ei sisaldanud väiteid, mis tähendab, et need viisid läbi, kuid ei kontrollinud midagi. Tegelik kaitsekate oli palju väiksem. Töörühm ei keskendunud numbritele, vaid mutatsioonide testimisele (üksus 10); tegelik vigade tabamise määr kahekordistus.

Juhtum 2 – riskikaardiga korrigeeritud prioriteet. Üks meeskond kulutas 40% oma testimisest harva kasutatavale aruandluskuvale, jättes maksevoo vahele, kuna see lihtsalt töötab. AI riskiskoor näitas seda tasakaalustamatust. Tööjõud jagati ümber; Kaks nädalat hiljem leiti maksevoost tugeva mõjuga viga ja see suleti enne levitamist.

Juhtum 3 – teadvusel, väljaspool ulatust. 4 tundi pärast avaldamist otsustas meeskond, mida testida ja mida teadlikult vahele jätta, kasutades malli „piiratud ajakava”. Kahte kõrge riskiga oja testiti sügaval; madala riskiga eelistuste ekraan dokumenteeriti kui "aktsepteeritud risk" ja jäeti vahele. Otsus oli läbipaistev ja põhjendatud; Versioon tuli turvaliselt välja.

Levinud vead

  • Eksitav katvusprotsent kvaliteedi suhtes. Kõrge rea katvuse lugemine "testitud" tagatisena.
  • Lihtsalt vaadates koodi leviala. Nõuete katvuse vahelejätmine (iga aktsepteerimiskriteeriumi testimine).
  • Testimine võrdselt riski arvestamata. Tööjõu jaotamine madala riskiga piirkondadesse ja kriitiliste voogude tähelepanuta jätmine.
  • Varjamine ulatusest väljas. Ei dokumenteerinud seda, mida ei testitud, kui aega polnud piisavalt; Väljalaskejärgsed üllatused.
  • AI riskiskooriga nõustumine ilma kahtluseta. AI ei tunne täielikult toote konteksti; Reguleerige hindeid asjatundliku pilguga.

Kokkuvõttes

Testi katvus ja riskipõhine testimine on kaks vahendit piiratud jõupingutuste suunamiseks õigesse kohta. Katvuse mõõdikud (joon, haru, seisund, tee) näitavad, mida puudutati, kuid ei tõesta, et see käitus õigesti; Ulatus on kaart, usaldus mitte. Pange koodi katvuse kõrvale nõuete katvus. Hinda tunnuseid valemiga risk = tõenäosus × mõju ja suuna pingutus kõige suurema riskini. AI muudab lüngad nähtavaks, hindab riske, planeerib piiratud aja; kuid lõpliku prioriteedi ja "teadliku loobumise" otsuse teeb ärikonteksti tundev ekspert.

Rakenduse ülesanne

Valige oma projektist moodul. Käivitage AI-ga mall „nõuete ulatuse lünk” ja uurige, milliseid aktsepteerimiskriteeriume ei testita. Seejärel reastage mooduli alamfunktsioonid tõenäosuse × mõju telgedel riskiskooriga. Jaotage (hüpoteetiline) 3 tundi testimisaega, mis teil on "piiratud ajakavaga"; Kirjutage üles, mida te teadlikult ei testi ja aktsepteeritud risk. Lisage konkreetne test, mis kõrvaldab teie leitud suurima riskiga katvuse tühimiku.

kontrollnimekiri

  • [ ] Katvuse protsenti loen kaardina, mitte kvaliteedina.
  • [ ] Lisaks koodi katvusele eemaldasin ka nõuete katvuse.
  • [ ] Hindasin tunnused tõenäosuse × mõju alusel ja järjestasin need riski järgi.
  • [ ] Suunasin testimise ümber suurimale riskile.
  • [ ] Olen dokumenteerinud teadlikult testimata valdkonnad ja tunnistanud riske.
  • [ ] Vaatasin tehisintellekti riskiskoorid üle oma toote konteksti põhjal.