Kasu:
- Oskus ära tunda pseudousalduse kolm palet (mittekehtestav, ennastkehtestav, triviaalne väide) ja rakendada vastumürke
- Võimalus kasutada mutatsioonitesti ja mutatsiooniskoori täpsema kvaliteedinäitajana kui tööriista või käsitsi katvuse protsent
- Võimalus positsioneerida tehisintellekti punase meeskonnana testimise vastu ja jahtida katselünki ilma kiituselõksu langemata
Selle mooduli keskmes on korduv hoiatus: roheline helendav testpaneel ei tõenda kvaliteeti. Kui teie testid annavad teile kindlustunde, peate teadma, kas see usaldus on tõeline või võlts. Tehisintellekti (AI) ajastul on see küsimus kriitilisem kui kunagi varem, sest tehisintellekt on osav tootma sujuvaid, sileda välimusega, kuid õõnsaid teste. Vale usaldus – tarkvara õigeks uskumine, kuna testid on rohelised, kuigi tegelikult testid midagi ei kontrolli – on kõige ohtlikum asi, mis kvaliteedikontrolli meeskonnaga juhtuda võib; sest see ei varja mitte seda, et vigu pole, vaid seda, et te ei näe vigu. See üksus koondab kogu mooduli valideerimisfilosoofia ühte distsipliini: testide testimine.
Testimise kvaliteedi mõõtmise kuldstandard: mutatsioonide testimine
Kõige võimsam viis mõista, kas test tegelikult kaitseb või mitte, on mutatsioonitestimine (mutatsioonitestimine – meetod, mis tekitab lähtekoodis tahtlikke väikseid moonutusi/mutatsioone ja mõõdab, kas testid neid moonutusi tuvastavad). Loogika on lihtne: kui murrate koodi tahtlikult (muutes + väärtuseks -, a > väärtuseks >=, tõest valeks), peaks hea testkomplekt selle korruptsiooni tabama ja punaseks muutuma. Kui seda ei juhtu, on see häire ellujäänud mutant - nii et teie testid ei säilita seda käitumist.
Mutatsiooniskoor = tapetud mutatsioon / kogumutatsioon. 90% liini katvusega paketil võib mutatsiooniskoor olla 40%; See näitab, et liinid töötavad, kuid käitumist ei kontrollita. Mutatsiooniskoor on palju ausam kvaliteedinäitaja kui protsentuaalne katvus.
Näpunäide: on olemas automaatsed mutatsioonitööriistad (PIT/Pitest Java jaoks, Stryker JavaScripti/TypeScripti jaoks, Stryker.NET .NET jaoks, mutmut Pythoni jaoks). Need genereerivad ja testivad automaatselt sadu mutatsioone. Kui teil pole tööriista, on kriitiliste funktsioonide jaoks hindamatu väärtusega isegi manuaalne "koodi testi katkestamise" meetod.
Pseudousalduse kolm palet ja selle vastumürk
Pseudo-usalduse vorm
sümptom
vastumürk
Test ilma väiteta
Kood töötab, midagi pole kinnitatud
Tõeline väide igas testis; test mutatsiooniga
ennast kinnitav test
Oodatav = koodi väljund
Arvutage eeldatav väärtus iseseisvalt
Triviaalne väide
"pole null", "200 tagastatud"
Kinnitage ärieeskiri/tegelik tulemus
Suure ulatusega eksitus
90% jooned, madal kaitse
Vaadake mutatsiooni skoori
Habras testitaluvus
"Jälle kinni, passi"
Algpõhjus + deterministlik testimine
AI kasutamine "punase meeskonnana"
AI võib nii tekitada pseudousaldust kui ka olla võimas liitlane selle jahtimisel. Kasutage tehisintellekti punase meeskonnana omaenda testide vastu: paluge "kirjutada kood, mis läbib need testid, kuid on vale" või "leidke õõnestus, mis need testid lolliks teeb". Kui tehisintellekt leiab teie testides lünki, on need lüngad tõelised riskid.
Ettevaatust: ärge küsige AI-lt "Kas minu testi kvaliteet on hea?" ja võtke vastust "jah, suurepärane" kindlusena. AI kipub olema lahke. Selle asemel esitage tehisintellektile väljakutse konkreetsele ülesandele: "toota viga, mis läbib need testid." Kui see suudab seda tekitada, on teie testid selle vea suhtes pimedad.
Samaväärsed mutatsioonid ja skoori piirid
Mutatsioonide testimine on võimas, kuid sellel on konks: mõned mutatsioonid ei muuda koodi käitumist üldse. Neid nimetatakse samaväärseteks mutatsioonideks (ekvivalentne mutant - rikutud kood, mutatsioon, mis annab täpselt sama tulemuse kui originaal). Näiteks muutuja algväärtuse muutmine, mida kunagi ei kasutata, ei mõjuta väljundit; Ükski test ei saa ega tohiks seda tabada. Seetõttu on 100% mutatsiooniskoor praktikas sageli saavutamatu ega ole eesmärk. Samaväärsete mutatsioonide käsitsi väljarookimine on töömahukas; Nii et ärge lugege mutatsiooniskoori absoluutse eksamitulemusena, vaid kui ausat näitajat "kas minu testid tõesti kaitsevad?"
Praktiline lähenemine on järgmine: selle asemel, et pidevalt kogu koodibaasi mutatsioonitesti teha, käivitage see moodulitel, mis sisaldavad suurimat riski ja kõige keerukamaid ärireegleid. Uurige ükshaaval nendes moodulites säilinud mutatsioone; Kui see on tõeline lünk, lisage test; kui tegemist on samaväärse mutatsiooniga, märgi see põhjendusega ja läbi. AI saab läbi viia esialgse skriinimise, et hinnata, kas ellujäänud mutatsioon on samaväärne; kuid lõpliku otsuse teete teie, kes teate, mida kood teeb.
Ettevaatust: mutatsioonide testimine on arvutuslikult kallis (kõik asjakohased testid tehakse iga mutatsiooni jaoks uuesti). Nii et tavaline ja mõistlik strateegia on ajastada see iganädalase või väljalaskeeelse kriitiliste moodulite põhjaliku kontrollina, mitte iga ühendamisena.
Nõrk viip / Tugev viip
Nõrk: "Kas minu testid on piisavad?"
Tugev: "Tegutsege selle funktsiooni ja testikomplekti jaoks punase meeskonnana. (1) Looge koodis 8 mutatsiooni, mida saab tappa (operaatori asendus, piiride nihe, tingimuste inversioon, tagastatud väärtuse asendamine). (2) Märkige iga mutatsiooni puhul ka, milline olemasolevatest testidest selle kinni püüab ja milline MITTE. (3) Iga ellujäänud mutatsiooni puhul kirjutage uus kood, kui see läbib. kõik need testid, kuid rikuvad ärireeglit Code+tests: [kleebi]"
Võimas viip; See positsioneerib tehisintellekti testi rikkuva eksamineerijana, mitte kiitusmasinana.
Neli kopeeritavat malli
1) Käsitsi mutatsioonide juhtimine:
Genereerige selle koodi jaoks 8 olulist mutatsiooni (väikesed tahtlikud häired): aritmeetilise operaatori asendamine, võrdluspiir (> vs >=), loogiline inversioon, tagastamine/konstantne asendamine, tingimuste vahelejätmine. Iga mutatsiooni puhul ennustage, milline saadaolevatest testidest seda tabab või mitte. Kood + testid: [kleebi]
2) Ellujäänud mutatsiooni tapmine:
Järgmine mutatsioonitesti aruanne sisaldab ellujäänud (tabamata) mutatsioone: [loend/aruanne]. Kirjutage igaühe jaoks minimaalne test, mis tapab selle mutatsiooni (kood muutub sel viisil purunemisel punaseks). Kommenteerige, millist käitumist test kinnitab.
3) Punane meeskond – vereanalüüs:
Kas saate kirjutada koodi, mis LÄBIB KÕIK järgmised testid, kuid rikub järgmist ärireeglit: [ärireegel]. Kui jah, siis milline lünk nendes testides seda võimaldab? Lisage test, mis selle lünka sulgeb. Testid: [kleebi]
4) Testi kvaliteedi kontroll:
Kontrollige selle testikomplekti kvaliteeti. Märkige iga testi juures linnuke:- Kas on tõene väide või on see rekvisiit?- Kas eeldatav väärtus on sõltumatu, tuletatakse koodist?- Kas see kontrollib ärireeglit või midagi triviaalset? Lõpuks andke hinnanguline tõene kinnitusskoor ja 3 nõrgimat testi. Testid: [kleebi]
kolm minikarpi
Juhtum 1 – katvus 92%, mutatsiooniskoor 38%. Üks meeskond tugines kõrgele katvusele. Kui mutatsioonitesti viidi läbi Strykeriga, oli skoor 38%: enamik toodetud mutatsioone jäi ellu. See oli tõend selle kohta, et testid ei jooksnud liine ega kontrollinud käitumist. Meeskond investeeris kolm nädalat kvaliteedi testimisse; Mutatsiooniskoor tõusis 81% -ni ja need täiustatud testid tuvastasid järgmises versioonis kaks tõelist arvutusviga.
Juhtum 2 – AI pettis testi. “Punase meeskonna” malliga küsis ekspert AI-lt koodi, mis läbis olemasolevad testid, kuid rikkus allahindlusreeglit. AI kirjutas koodi, mis tagastas alati nulli allahindluse – ja kõik testid jäid roheliseks, kuna ükski test ei kontrollinud tegelikku allahindluse väärtust. Lünk nähtud, tõelised väited lisatud.
Juhtum 3 – kiituslõks. Noorem testija küsis tehisintellektilt: "Kas mu testid on head?" ja tundis kergendust, kui kuulis vastust: "Väga kõikehõlmav." Tema vanem kolleeg lasi samu teste auditeerida, kasutades malli "testikvaliteedi audit"; Selgus, et 20-st testist 12 olid dekoratsioonid (ilma väite või rämpsuta). Õige küsimus tõi õige vastuse.
Levinud vead
- Kvaliteedi eksimine. Tuginedes suurele rea katvusele ja mitte vaadates mutatsiooni skoori üldse.
- Usaldades tehisintellekti kiitust. Küsib "Kas teie testid on head?" ja pidada positiivset vastust kindluseks.
- Eeldatava väärtuse tuletamine koodist. Isekontrollivad testid, mis kinnitavad vigast koodi.
- Olge rahul tühiste väidetega. Kontrollid, mis ei kinnita tegelikku reeglit, näiteks "ei ole null", "200 tagastatud".
- Ellujäänud mutatsioonide ignoreerimine. Ignoreerides seda, mida mutatsiooniraportis ei leitud.
- Isegi mitte üritada kriitilist koodi käsitsi muteerida. Kui tööriist pole saadaval, jätke vahele sammu "murdke kood ja testige".
Kokkuvõttes
Pseudousaldus usub, et tarkvara on õige, kuna testid on rohelised; kusjuures testid ei pruugi midagi kinnitada. Selle mõõtmise kuldstandardiks on mutatsioonide testimine: koodi tahtlik murdmine ja mõõtmine, kas testid selle kinni püüavad. Mutatsiooniskoor on palju ausam kvaliteedinäitaja kui protsentuaalne katvus. Tehisintellekt tekitab pseudousaldust ja muutub selle jahtimisel võimsaks punaseks meeskonnaks – paluge "toota välja viga, mis need testid läbib". Testige oma teste: tõene väide, sõltumatu eeldatav väärtus, ärireeglite valideerimine ja tapetud mutatsioonid.
Rakenduse ülesanne
Importige oma projektist ärireeglit ja selle teste sisaldav funktsioon. Võimalusel käivitage mutatsioonitööriist (Stryker/Pitest/mutmut) ja mõõtke mutatsiooniskoor; Kui tööriista pole, genereerige malliga "käsitsi mutatsioonide juhtimine" vähemalt 8 mutatsiooni ja proovige neid käsitsi. Kirjutage iga ellujäänud mutatsiooni jaoks uus test malliga "tappa ellujäänud mutatsioon". Lõpuks vaadake "punase meeskonna" mustriga, kas AI suudab toota koodi, mis teie testid lolliks teeb. Teatage oma mutatsiooni alguse ja lõpu skoor (või tabatud/kogu mutatsioonimäär).
kontrollnimekiri
- [ ] Hindasin testi kvaliteeti mutatsiooni skoori, mitte katvuse järgi.
- [ ] Käivitasin kriitilise koodi mutatsioonitesti (kas tööriista abil või käsitsi).
- [ ] Kirjutasin iga ellujäänud mutatsiooni jaoks uued testid.
- [ ] Kasutasin AI-d punase meeskonnana ja otsisin oma testides lünki.
- [ ] Ma ei võtnud AI kiitust "teie testid on head" kindlustundena.
- [ ] Kontrollisin, et iga test kontrolliks tegelikku väidet, sõltumatut eeldatavat väärtust ja ärireeglit.