Dobički:
- Sposobnost prepoznavanja treh obrazov psevdozaupanja (neasertivnega, samozavestnega, trivialnega zatrjevanja) in uporabe protistrupov
- Sposobnost uporabe testiranja mutacije in ocene mutacije kot natančnejšega merila kakovosti kot odstotek pokritosti z orodjem ali roko
- Sposobnost postaviti AI kot rdečo ekipo proti testiranju in loviti vrzeli v testiranju, ne da bi se ujeli v past pohval
At the heart of this module is a recurring warning: a green glowing test panel is not evidence of quality. If your tests give you confidence, you need to know whether that confidence is real or fake. V dobi umetne inteligence (AI) je to vprašanje bolj kritično kot kdaj koli prej, saj je AI spreten pri izdelavi tekočih, gladkih, a votlih testov. Lažno zaupanje – verjeti, da je programska oprema pravilna, ker so testi zeleni, čeprav v resnici testi ne potrdijo ničesar – je najnevarnejša stvar, ki se lahko zgodi ekipi za zagotavljanje kakovosti; because it hides not that there are no errors, but that you cannot see the errors. This unit brings together the validation philosophy of the entire module into one discipline: testing your tests.
The gold standard for measuring the quality of testing: mutation testing
Najmočnejši način za razumevanje, ali test dejansko ščiti ali ne, je testiranje mutacij (testiranje mutacij – tehnika, ki proizvaja namerna majhna popačenja/mutacije v izvorni kodi in meri, ali testi zaznajo ta izkrivljanja). Logika je preprosta: če namenoma zlomite kodo (pretvorite + v -, > v >=, resnično v napačno), bi moral dober testni paket ujeti to pokvarjenost in postati rdeč. Če se ne zgodi, je ta motnja preživeli mutant – torej vaši testi dejansko ne ohranjajo tega vedenja.
Rezultat mutacije = uničena mutacija / skupna mutacija. Paket z 90-odstotno pokritostjo linije ima lahko oceno mutacije 40 %; To pomeni, da linije delujejo, vendar vedenje ni preverjeno. Rezultat mutacije je veliko bolj pošteno merilo kakovosti kot odstotek pokritosti.
Nasvet: Obstajajo orodja za samodejno mutacijo (PIT/Pitest za Javo, Stryker za JavaScript/TypeScript, Stryker.NET za .NET, mutmut za Python). Te samodejno ustvarijo in testirajo na stotine mutacij. Če nimate orodja, je za kritične funkcije neprecenljiva tudi ročna metoda "preizkusa kode".
Trije obrazi psevdozaupanja in njegov protistrup
Obrazec psevdozaupanja
simptom
antidote
Test without assert
Koda deluje, nič ni potrjeno
Resnična trditev v vsakem testu; test with mutation
self-confirming test
Pričakovano = izpis kode
Pričakovano vrednost izračunajte neodvisno
Trivial assert
"ni nič", "200 vrnjenih"
Potrdite poslovno pravilo/dejanski rezultat
High scope fallacy
90 % vrvic, nizka zaščita
Poglej rezultat mutacije
Fragile test tolerance
"Stuck again, pass"
Osnovni vzrok + deterministično testiranje
Uporaba AI kot "rdeča ekipa"
Umetna inteligenca lahko ustvari psevdozaupanje in je močan zaveznik pri njegovem lovljenju. Uporabite AI kot rdečo ekipo proti lastnim testom: prosite »napišite kodo, ki prestane te teste, a je napačna« ali »poiščite subverzijo, ki bo preslepila te teste«. Če umetna inteligenca najde vrzeli v vaših testih, so te vrzeli resnično tveganje.
Pozor: Ne sprašujte AI "Ali je kakovost mojega testa dobra?" in vzemite odgovor "da, odlično" kot zagotovilo. AI tends to be kind. Namesto tega izzovite AI na konkretno nalogo: "izdelajte hrošča, ki prestane te teste." Če jo lahko ustvari, so vaši testi slepi za to napako.
Enakovredne mutacije in meje rezultata
Testiranje mutacij je zmogljivo, vendar ima ulov: nekatere mutacije sploh ne spremenijo obnašanja kode. Te se imenujejo enakovredne mutacije (ekvivalentni mutant — pokvarjena koda, mutacija, ki daje popolnoma enak rezultat kot izvirnik). Na primer, spreminjanje začetne vrednosti spremenljivke, ki ni nikoli uporabljena, ne vpliva na izhod; Noben test tega ne more in ne sme ujeti. Zato je 100-odstotna ocena mutacije v praksi pogosto nedosegljiva in ni cilj. Ročno odstranjevanje enakovrednih mutacij je delovno intenzivno; Torej ne berite ocene mutacije kot absolutne ocene na izpitu, temveč kot pošten pokazatelj "ali moji testi res ščitijo?"
Praktični pristop je naslednji: namesto nenehnega izvajanja testiranja mutacije v celotni bazi kode, ga izvajajte na modulih, ki vsebujejo največje tveganje in najbolj zapletena poslovna pravila. Preglejte preživele mutacije v teh modulih eno za drugo; If it is a real gap, add a test; če gre za enakovredno mutacijo, jo označi z utemeljitvijo in opravi. AI lahko izvede začetni pregled pri ocenjevanju, ali je preživela mutacija enakovredna; vendar končno odločitev sprejmete vi, ki veste, kaj koda počne.
Pozor: Testiranje mutacij je računsko drago (vsi ustrezni testi se znova izvedejo za vsako mutacijo). Običajna in razumna strategija je torej, da ga načrtujete kot tedensko ali temeljito preverjanje kritičnih modulov pred objavo, ne pa vsako spajanje.
Šibek poziv/močan poziv
Weak: "Are my tests sufficient?"
Močno: "Delujte kot rdeča ekipa za to funkcijo in testni paket. (1) Ustvarite 8 mutacij v kodi, ki jih je mogoče uničiti (zamenjava operaterja, premik meje, inverzija pogoja, zamenjava vrnjene vrednosti). (2) Za vsako mutacijo navedite, kateri od obstoječih testov jo bo ujel in kateri NE. (3) Za vsako mutacijo, ki preživi, napišite nov test, ki jo bo uničil. (4) Pokažite tudi, ali lahko ustvarite kodo primer, ki prestane vse te teste, vendar krši poslovno pravilo Code+tests: [prilepi]"
Močan poziv; Umetno inteligenco postavlja kot izpraševalca, ki opravlja teste, in ne kot stroj za pohvale.
Štiri predloge za kopiranje
1) Manual mutation control:
Ustvari 8 pomembnih mutacij (manjše namerne motnje) za to kodo: zamenjava aritmetičnega operatorja, meja primerjave (> vs >=), logična inverzija, zamenjava vrnitve/konstante, preskok pogoja. Za vsako mutacijo predvidite, kateri od razpoložljivih testov jo bo ujel ali ne. Code+tests: [paste]
2) Killing the surviving mutation:
Naslednje poročilo o testu mutacije vsebuje preživele (neulovljene) mutacije: [seznam/poročilo]. Za vsako napišite minimalni test, ki bo uničil to mutacijo (koda bo rdeča, če jo tako zlomite). Komentirajte, kakšno vedenje potrdi test.
3) Red team — blood the test:
Ali lahko napišete kodo, ki PRESTANE VSE naslednje teste, vendar krši naslednje poslovno pravilo: [poslovno pravilo]. Če da, katera vrzel v teh testih to omogoča? Dodajte test, ki bo zapolnil to vrzel. Tests: [paste]
4) Test kakovosti pregled:
Preverite kakovost tega testnega paketa. Označite za vsak preizkus: - Ali obstaja resnična trditev ali je rekvizit? - Ali je pričakovana vrednost neodvisna, izpeljana iz kode? - Ali preverja poslovno pravilo ali kaj trivialnega? Na koncu podajte ocenjeno "resno trditev" in 3 najšibkejše teste. Tests: [paste]
trije mini kovčki
Case 1 — Coverage 92%, mutation score 38%. One team relied on high coverage. Pri testiranju mutacij s Strykerjem je bil rezultat 38 %: večina ustvarjenih mutacij je preživela. To je bil dokaz, da testi niso izvajali linij in preverjali obnašanja. Ekipa je vložila tri tedne v testiranje kakovosti; Rezultat mutacije se je povečal na 81 % in ti izboljšani testi v naslednji izdaji so odkrili dve resnični računski napaki.
Case 2 — AI tricked the test. S predlogo »rdeče ekipe« je strokovnjak od umetne inteligence zahteval kodo, ki je prestala obstoječe teste, vendar je kršila pravilo popusta. AI je napisal kodo, ki je vedno vrnila popust nič — in vsi testi so ostali zeleni, ker noben test ni preverjal dejanske vrednosti popusta. Gap seen, real asserts added.
Case 3 — The praise trap. Mladi tester je vprašal AI: "Ali so moji testi dobri?" in je bil olajšan, ko je slišal odgovor: "Zelo izčrpno." Njegov starejši kolega je imel enake teste revidirane z uporabo predloge "revizija kakovosti testa"; Izkazalo se je, da je bilo 12 od 20 testov dekor (brez assert ali junk). The right question brought the right answer.
Pogoste napake
- Mistaking scope for quality. Zanaša se na visoko pokritost vrstic in sploh ne gleda na oceno mutacije.
- Zaupam pohvalam AI. Asking "Are your tests good?" in upoštevajte pozitiven odgovor kot zagotovilo.
- Izpeljava pričakovane vrednosti iz kode. Self-verifying tests that confirm faulty code.
- Be content with trivial assertions. Preverjanja, ki ne potrdijo dejanskega pravila, na primer »not null«, »200 returned«.
- Ignoring surviving mutations. Ignoriranje tistega, kar ni bilo ujeto v poročilu o mutaciji.
- Sploh ne poskušam ročno spremeniti kritične kode. Preskok koraka "razbije kodo in preizkusi", če orodje ni na voljo.
Če povzamem
Pseudo-zaupanje je prepričanje, da je programska oprema pravilna, ker so testi zeleni; medtem ko testi morda ne bodo potrdili ničesar. Zlati standard za merjenje tega je testiranje mutacij: namerno zlom kode in merjenje, ali jo testi ujamejo. Rezultat mutacije je veliko bolj pošteno merilo kakovosti kot odstotek pokritosti. Umetna inteligenca ustvari psevdozaupanje in postane močna rdeča ekipa pri lovu nanj – vprašajte »izdelajte hrošča, ki prestane te teste«. Preizkusite svoje teste: resnična trditev, neodvisna pričakovana vrednost, potrditev poslovnih pravil in uničene mutacije.
Aplikacijska naloga
Uvozite funkcijo, ki vsebuje poslovno pravilo in njegove teste iz vašega projekta. Če je mogoče, zaženite orodje za mutacijo (Stryker/Pitest/mutmut) in izmerite rezultat mutacije; Če ni orodja, ustvarite vsaj 8 mutacij s predlogo "ročni nadzor mutacij" in jih poskusite ročno. Za vsako preživelo mutacijo napišite nov test s predlogo "uniči preživelo mutacijo". Nazadnje z vzorcem »rdeče ekipe« preverite, ali lahko AI ustvari kodo, ki preslepi vaše teste. Sporočite svoj začetni in končni rezultat mutacije (ali stopnjo ujetih/skupnih mutacij).
kontrolni seznam
- [ ] Kakovost testa sem ocenil z oceno mutacije, ne po pokritosti.
- [ ] Izvedel sem testiranje mutacij (bodisi z orodjem bodisi ročno) za kritično kodo.
- [ ] Napisal sem nove teste za vsako preživelo mutacijo.
- [ ] Uporabil sem AI kot rdečo ekipo in iskal vrzeli v svojih testih.
- [ ] Pohval AI "vaši testi so dobri" nisem jemal kot pomiritev.
- [ ] Preveril sem, ali vsak test preverja dejansko trditev, neodvisno pričakovano vrednost in poslovno pravilo.