Voitot:
- Kyky tunnistaa näennäisluottamuksen kolme puolta (ei-vakuuttava, itsevakuuttava, triviaali väittämä) ja käyttää vastalääkkeitä
- Kyky käyttää mutaatiotestausta ja mutaatiopisteitä tarkempana laadun mittana kuin prosentuaalinen peitto työkalulla tai käsin
- Kyky asettaa tekoäly punaiseksi tiimiksi testaamista vastaan ja etsiä porsaanreikiä putoamatta kehujen ansaan
Tämän moduulin ytimessä on toistuva varoitus: vihreä hehkuva testipaneeli ei ole todiste laadusta. Jos testisi antavat sinulle luottamusta, sinun on tiedettävä, onko luottamus aitoa vai väärennettyä. Tekoälyn (AI) aikakaudella tämä kysymys on kriittisempi kuin koskaan, koska tekoäly on taitava tuottamaan sulavia, sileän näköisiä mutta onttoja testejä. Väärä luottamus – uskoa, että ohjelmisto on oikea, koska testit ovat vihreitä, vaikka testit eivät itse asiassa varmista mitään – on vaarallisin asia, mitä laadunvarmistustiimille voi tapahtua; koska se ei piilota sitä, että virheitä ei ole, vaan sitä, että et näe virheitä. Tämä yksikkö yhdistää koko moduulin validointifilosofian yhdeksi tieteenalaksi: testien testaamiseen.
Testauksen laadun mittaamisen kultastandardi: mutaatiotestaus
Tehokkain tapa ymmärtää, suojaako testi todella vai ei, on mutaatiotestaus (mutaatiotestaus – tekniikka, joka tuottaa tahallisia pieniä vääristymiä/mutaatioita lähdekoodiin ja mittaa, havaitsevatko testit nämä vääristymät). Logiikka on yksinkertainen: jos rikot koodin tarkoituksella (muistat +:n merkiksi -, >:stä >=:sta ja true:sta false), hyvän testipaketin pitäisi saada kiinni tuosta korruptiosta ja muuttua punaiseksi. Jos ei, tämä häiriö on selvinnyt mutantti - joten testisi eivät itse asiassa säilytä tätä käyttäytymistä.
Mutaatiopisteet = tapettu mutaatio / kokonaismutaatio. Paketissa, jonka linjapeitto on 90 %, mutaatiopistemäärä voi olla 40 %; Tämä osoittaa, että linjat toimivat, mutta toimintaa ei ole vahvistettu. Mutaatiopisteet ovat paljon rehellisempi laadun mitta kuin prosenttiosuus.
Vinkki: On olemassa automaattisia mutaatiotyökaluja (PIT/Pitest Javalle, Stryker JavaScriptille/TypeScriptille, Stryker.NET .NETille, mutmut Pythonille). Nämä luovat ja testaavat automaattisesti satoja mutaatioita. Jos sinulla ei ole työkalua, jopa manuaalinen "break the code test" -menetelmä on korvaamaton kriittisten toimintojen kannalta.
Pseudo-luottamuksen kolme puolta ja sen vastalääke
Pseudo-luottamusmuoto
oire
vastalääke
Testaa ilman väitettä
Koodi toimii, mitään ei ole vahvistettu
Todellinen väite jokaisessa testissä; testi mutaatiolla
itseään vahvistava testi
Odotettu = koodin tulos
Laske odotusarvo itsenäisesti
Triviaali väite
"ei tyhjä", "200 palautettu"
Vahvista liiketoimintasääntö/todellinen tulos
Suuri laajuus virhe
90 % viivoja, matala suojaus
Katso mutaatiopisteet
Hauras testitoleranssi
"Jossa taas, ohita"
Perimmäinen syy + deterministinen testaus
Tekoälyn käyttäminen "punaisena tiiminä"
Tekoäly voi sekä luoda näennäisluottamusta että olla tehokas liittolainen sen metsästämisessä. Käytä tekoälyä punaisena tiiminä omia testejäsi vastaan: pyydä "kirjoita koodi, joka läpäisee nämä testit, mutta on väärä" tai "etsi versio, joka huijaa nämä testit". Jos tekoäly löytää porsaanreikiä testeissäsi, ne ovat todellisia riskejä.
Varoitus: Älä kysy tekoälyltä "Onko testini laatu hyvä?" ja ota vastaus "kyllä, hienoa" vakuutuksena. AI on taipumus olla kiltti. Sen sijaan haasta tekoäly konkreettiseen tehtävään: "tuo bugi, joka läpäisee nämä testit." Jos se voi tuottaa sen, testisi ovat sokeita tälle virheelle.
Vastaavat mutaatiot ja pistemäärän rajat
Mutaatiotestaus on tehokasta, mutta siinä on saalis: jotkut mutaatiot eivät muuta koodin käyttäytymistä ollenkaan. Näitä kutsutaan vastaaviksi mutaatioiksi (ekvivalenttinen mutantti - vioittunut koodi, mutaatio, joka tuottaa täsmälleen saman tuloksen kuin alkuperäinen). Esimerkiksi sellaisen muuttujan alkuarvon muuttaminen, jota ei koskaan käytetä, ei vaikuta lähtöön; Mikään testi ei voi eikä saa saada tätä kiinni. Siksi 100 %:n mutaatiopistemäärä on usein mahdoton saavuttaa käytännössä eikä se ole tavoite. Vastaavien mutaatioiden kitkeminen käsin on työvoimavaltaista; Älä siis lue mutaatiopisteitä absoluuttisena koepisteenä, vaan rehellisenä indikaattorina "suojaavatko testini todella?"
Käytännön lähestymistapa on seuraava: sen sijaan, että suoritat jatkuvasti mutaatiotestausta koko koodikannassa, suorita se moduuleissa, jotka sisältävät suurimman riskin ja monimutkaisimmat liiketoimintasäännöt. Tutki näiden moduulien eloonjääneet mutaatiot yksitellen; Jos se on todellinen aukko, lisää testi; jos se on vastaava mutaatio, merkitse se perustelulla ja hyväksy. Tekoäly voi suorittaa alustavan seulonnan arvioidakseen, onko elossa oleva mutaatio vastaava; mutta lopullisen päätöksen teet sinä, joka tietää mitä koodi tekee.
Varoitus: Mutaatiotestaus on laskennallisesti kallista (kaikki asiaankuuluvat testit suoritetaan uudelleen jokaiselle mutaatiolle). Joten yleinen ja järkevä strategia on ajoittaa se kriittisten moduulien viikoittaiseksi tai julkaisua edeltäväksi perusteelliseksi tarkistukseksi jokaisen yhdistämisen sijaan.
Heikko kehote / Vahva kehote
Heikko: "Ovatko testini riittävät?"
Vahva: "Toimi punaisena tiiminä tälle toiminnolle ja testisarjalle. (1) Luo koodiin 8 mutaatiota, jotka voidaan tappaa (operaattorin korvaaminen, rajan siirto, ehdon käännös, palautusarvon korvaaminen). (2) Ilmoita jokaiselle mutaatiolle myös, mikä olemassa olevista testeistä saa sen kiinni ja mikä EI. (3) Jokaiselle selviytyvälle mutaatiolle, joka selviää, kirjoita uusi testi, jos se onnistuu, kirjoita uusi testi. kaikki nämä testit, mutta rikkovat liiketoimintasääntöä Koodi+testit: [liitä]"
Tehokas kehote; Se asettaa tekoälyn kokeen rikkovaksi tutkijaksi, ei ylistyskoneeksi.
Neljä kopioitavaa mallia
1) Manuaalinen mutaatiohallinta:
Luo 8 merkittävää mutaatiota (pieniä tahallisia häiriöitä) tälle koodille: aritmeettinen operaattorin korvaaminen, vertailuraja (> vs >=), looginen inversio, paluu/vakiokorvaus, ehtojen ohittaminen. Ennusta jokaiselle mutaatiolle, mikä käytettävissä olevista testeistä saa sen kiinni vai ei. Koodi + testit: [liitä]
2) Selviytyneen mutaation tappaminen:
Seuraava mutaatiotestiraportti sisältää eloonjääneitä (saamattomia) mutaatioita: [luettelo/raportti]. Kirjoita kullekin minimitesti, joka tappaa kyseisen mutaation (koodi muuttuu punaiseksi, kun se rikotaan tällä tavalla). Kommentoi, minkä käyttäytymisen testi vahvistaa.
3) Punainen joukkue – veritesti:
Voitko kirjoittaa koodin, joka läpäisee KAIKKI seuraavat testit, mutta rikkoo seuraavaa liiketoimintasääntöä: [liiketoimintasääntö]. Jos näin on, mikä näiden testien porsaanreikä sallii tämän? Lisää testi, joka sulkee porsaanreiän. Testit: [liitä]
4) Testin laadun tarkastus:
Tarkista tämän testipaketin laatu. Rasti jokaiseen testiin:- Onko olemassa oikea väite vai onko se rekvisiitta?- Onko odotusarvo riippumaton, johdettu koodista?- Vahvistaako se liiketoimintasäännön tai jotain triviaalia? Anna lopuksi arvioitu "true assert score" ja 3 heikointa testiä. Testit: [liitä]
kolme minilaukkua
Tapaus 1 – Kattavuus 92 %, mutaatiopistemäärä 38 %. Yksi joukkue luotti korkeaan kattavuuteen. Kun mutaatiotesti suoritettiin Strykerillä, tulos oli 38 %: suurin osa syntyneistä mutaatioista selvisi. Tämä oli todiste siitä, että testit eivät ajaneet linjoja ja varmistaneet käyttäytymistä. Tiimi investoi kolme viikkoa laadun testaamiseen; Mutaatiopistemäärä nousi 81 prosenttiin, ja nämä tehostetut testit havaitsivat kaksi todellista laskentavirhettä seuraavassa julkaisussa.
Tapaus 2 – AI huijasi testin. "Punaisen tiimin" mallilla asiantuntija pyysi tekoälyltä koodia, joka läpäisi olemassa olevat testit, mutta rikkoi alennussääntöä. Tekoäly kirjoitti koodin, joka palautti aina nollaalennuksen – ja kaikki testit pysyivät vihreinä, koska mikään testi ei vahvistanut todellista alennuksen arvoa. Aukko nähty, oikeita väitteitä lisätty.
Tapaus 3 – Ylistysloukku. Nuorempi testaaja kysyi tekoälyltä: "Ovatko testini hyviä?" ja oli helpottunut kuultuaan vastauksen: "Erittäin kattava." Hänen vanhempi kollegansa auditoi samat testit käyttämällä "testin laadun tarkastus" -mallia; Kävi ilmi, että 12 testistä 20:stä oli sisustusta (ilman väitettä tai roskaa). Oikea kysymys toi oikean vastauksen.
Yleisiä virheitä
- Väärät mahdollisuudet laatuun. Luotetaan korkeaan rivipeittoon eikä katsota mutaatiopisteitä ollenkaan.
- Tekoälyn kehuihin luottaminen. Kysymys "Ovatko testisi hyviä?" ja pitää myönteinen vastaus vakuutena.
- Odotetun arvon johtaminen koodista. Itsevarmentavat testit, jotka vahvistavat virheellisen koodin.
- Tyytykää vähäpätöisiin väitteisiin. Tarkistukset, jotka eivät vahvista varsinaista sääntöä, kuten "ei tyhjä", "200 palautettu".
- Eloonjääneiden mutaatioiden huomioimatta. Jätetään huomiotta se, mitä mutaatioraportissa ei havaittu.
- Ei edes yritä muuttaa kriittistä koodia manuaalisesti. "Katkaise koodi ja testaa" -vaihe ohitetaan, jos työkalua ei ole saatavilla.
Yhteenvetona
Pseudo-luottamus uskoo, että ohjelmistot ovat oikein, koska testit ovat vihreitä; kun taas testit eivät välttämättä vahvista mitään. Kultastandardi tämän mittaamisessa on mutaatiotestaus: koodin tahallinen rikkominen ja sen mittaaminen, saavatko testit sen kiinni. Mutaatiopisteet ovat paljon rehellisempi laadun mitta kuin prosenttiosuus. Tekoäly tuottaa näennäisluottamusta ja siitä tulee voimakas punainen tiimi sen metsästämisessä – pyydä "tuottamaan bugi, joka läpäisee nämä testit". Testaa testisi: todellinen väite, riippumaton odotusarvo, liiketoimintasäännön validointi ja tapetut mutaatiot.
Sovellustehtävä
Tuo liiketoimintasäännön ja sen testit sisältävä funktio omasta projektistasi. Jos mahdollista, suorita mutaatiotyökalu (Stryker/Pitest/mutmut) ja mittaa mutaatiopisteet; Jos työkalua ei ole, luo vähintään 8 mutaatiota "manuaalinen mutaatiohallinta" -mallilla ja kokeile niitä manuaalisesti. Kirjoita jokaiselle eloonjääneelle mutaatiolle uusi testi "tappaa elossa oleva mutaatio" -mallilla. Lopuksi katso "punaisen tiimin" mallilla, pystyykö tekoäly tuottamaan koodia, joka huijaa testisi. Ilmoita aloitus- ja loppumutaatiopisteesi (tai kiinni-/kokonaismutaatioaste).
tarkistuslista
- [ ] Arvioin testin laatua mutaatiopisteiden, en kattavuuden perusteella.
- [ ] Tein mutaatiotestauksen (joko työkalulla tai manuaalisesti) kriittiselle koodille.
- [ ] Kirjoitin uudet testit jokaiselle elossa olevalle mutaatiolle.
- [ ] Käytin tekoälyä punaisena tiiminä ja etsin porsaanreikiä testeissäni.
- [ ] En ottanut tekoälyn "testisi ovat hyviä" -kiitoksia vakuutuksena.
- [ ] Tarkistin, että jokainen testi vahvistaa todellisen väitteen, riippumattoman odotusarvon ja liiketoimintasäännön.