Voitot:
- Kyky tuottaa yksikkötestauksia, reunatapauksia ja peittovälianalyysiä tekoälyn avulla
- Mahdollisuus tulostaa testiodotukset spesifikaatioiden perusteella, ei koodin nykyisen käyttäytymisen perusteella
- Kyky testata, suojaako testi todella lisäämällä virheitä
Testien kirjoittaminen on yksi arvoa tuottavimmista tehtävistä, jonka useimmat kehittäjät lykkäävät. Hyvä testisarja on todiste siitä, että koodi toimii odotetusti, ja pelastusköydet tuleville muutoksille. Ongelmana on, että testien kirjoittaminen on toistuvaa ja aikaa vievää – juuri sellaista työtä, jossa tekoäly loistaa. Mutta siinä on saalis: tekoäly testaa usein koodin olemassa olevaa toimintaa, ei sitä, mitä sen pitäisi olla. Tämän eron hallinta on tämän yksikön ydin.
Tässä osiossa opit yksikkötestauksen (testaus, joka testaa funktiota yksin, erillään), reunatapausten testejä ja testidatan luomista tekoälyllä; aukkojen sulkeminen testin kattavuudessa; ja miksi tekoälytesteihin sokeasti luottaminen on vaarallista.
Testauksen kaksi puolta: käyttäytymisen korjaaminen vs. vahvistaminen
Testillä voi olla kaksi eri tarkoitusta. Ensimmäinen on todentaminen: se testaa, että koodi on oikea, että se on määritelmien mukainen. Toinen on regressiosuojaus: se pysäyttää koodin käyttäytymisen tänään, joten jos joku vahingossa muuttaa sitä huomenna, testi katkeaa ja ilmoittaa.
AI on erittäin hyvä jälkimmäisessä; Se tarkastelee koodia ja luo tapauksia, jotka testaavat "mitä se tekee juuri nyt". Mutta jos koodi on alusta alkaen väärä, tekoäly voi merkitä väärän käytöksen "oikeaksi". Joten sinun on tarkistettava jokaisen tekoälyn tuottaman testin väite: "Koodi palauttaa 42 ja testi odottaa 42" ei tarkoita, että 42 on oikea vastaus.
Varoitus: Jos tekoäly läpäisee testin, se ei tarkoita, että koodi "toimii"; se tarkoittaa vain "se käyttäytyy kuten tekoäly odottaa". Päätät, ovatko odotukset oikeat vai eivät, katsomalla eritelmiä.
Askel askeleelta: Vahvien testien kirjoittaminen tekoälyllä
- Anna tiedot, älä vain koodia. Jos lisäät tiedot "Tämän toiminnon pitäisi tehdä tämä", tekoäly voi kirjoittaa oikean odotuksen; Se testaa nykyisen toiminnan, jos annat vain koodin.
- Pyydä reunalaukkuja. Tyhjä, tyhjä, nolla, negatiivinen, liian suuri, huono muoto, samanaikaisuus – väitä nimenomaisesti pois onnelliselta tieltä.
- Määritä testauskehys ja tyyli. "käytä pytestiä", "Arrange-Act-Assert pattern", "Anna jokaisen testin testata yksi asia" jne.
- Tarkista odotukset (väite). Vertaa spesifikaatioon, jonka jokainen väite tarkistaa oikean arvon.
- Sulje laajuuden aukot. Anna olemassa olevat testit ja kysy "mitä haaroja ja tapauksia ei ole testattu?" saada kysymään; tarkista sitten tuotetut lisätestit.
Kolme minikoteloa
Tapaus 1 – Kattavuus 52–85 %. Yhden palvelumoduulin testikattavuus oli 52 %. Tiimi syötti olemassa olevat testit tekoälylle, sai sen luetteloimaan testaamattomat haarat ja luomaan niille testejä. Ihmisten tarkastelun avulla kattavuus kasvoi 85 prosenttiin; Tässä prosessissa tekoäly paljasti todellisen virheen (polun, joka palautti väärän virhekoodin) virhehaarassa, jota ei ollut koskaan aiemmin testattu.
Tapaus 2 – Väärän odotuksen kiinnitysloukku. Rahan pyöristystoiminto oli itse asiassa väärä; Sen sijaan, että se pyöristää 2,675:stä 2,67:ään, se pyöristää 2,67:n 2,68:n sijaan. Tekoäly katsoi koodia ja kirjoitti assert round_money(2.675) == 2.67 — jäädytti virheen "tosi". Kun kehittäjä luki eritelmän, hän korjasi odotukset ja havaitsi todellisen virheen. Säännön testaus, ei koodin, teki eron.
Tapaus 3 – Reunatilan räjähdys. Kun kysytään tekoälyltä vain "reunatapauksia" päivämäärävälitoiminnolle; Se tuotti 8 tapausta, kuten aloitus = loppu, käänteinen aikaväli, karkausvuosi 29. helmikuuta, eri aikavyöhykkeet ja nollaväli. Kaksi näistä (käänteinen väli ja karkausvuosi) aiheutti itse asiassa virheen. Näiden tapausten manuaalinen käsittely ohitetaan usein; Tekoälystä tuli tässä "edge-case-aivoriihi" -kumppani.
Neljä kopioitavaa mallia
Spesifikaatioihin perustuva testisukupolvi:
Rooli: Kehittäjä, joka kirjoittaa testejä. Framework: {{pytest/JUnit/Jest...}}.Mitä funktion PITÄÄ TEHDÄ (erittely): {{sääntö}}Kirjoita testit seuraavalle funktiolle. Kirjoita odotukset määrittelyn mukaan, EI koodin nykyistä lähtöä. Hyvää polkua + lisää vähintään 4 reunakoteloa. Testaa jokainen testi yksi asia, käytä kuvaavaa nimeä. {{toiminto}}
Edge-tapauksen aivoriihi:
Listaa reuna-/virhetapaukset, joita tulisi kokeilla tämän funktion testauksessa (nolla, nolla, keskeytyskohdat, huono muoto, samanaikaisuus, ulkoinen virhe). Jokaiselle tapaukselle: syöte, odotettu toiminta. ÄLÄ kirjoita vielä koodia, vaan luettele.{{funktio}}
Kattavuusvaje-analyysi:
Alla on toiminnot ja käytettävissä olevat testit. Mitä oksia, ehtoja ja tapauksia ei ole testattu? Listaa puutteet ja kirjoita uudet testit vain puutteille. Älä toista olemassa olevia. Toiminto:{{function}}Testit:{{existing_tests}}
Testitietojen / valeobjektin luominen:
Luo realistisia testitietoja {{function/service}}-testeille: kelvolliset näytteet, reunanäytteet ja virheelliset näytteet erikseen. Ehdota yksinkertaista tekotapaa ulkoiselle riippuvuudelle {{X}}. Todellisten luottamuksellisten tietojen/PII:n käyttäminen; Luo väärennettyjä tietoja.
Heikko kehote / Vahva kehote
Heikko: "Kirjoita testi tälle funktiolle."
Vahva: "pytestillä. Funktio apply_discount(yhteensä, prosenttia) — sääntö: alennuksen on oltava 0%–30%, rajojen ulkopuolella pitäisi heittää ValueError, tulos tulee pyöristää 2 desimaaliin. Kirjoita odotukset tällä säännöllä (ei koodilla). Hyvää polkua + nämä reunatapaukset: 0%, 30%, 31% (virhe).]
Hän antaa vahvan julkaisusäännön ja sanoo "kirjoita odotus säännön mukaan, ei koodia"; Tämä yksittäinen lause sulkee tekoälyn ansan korjata väärinkäytöksiä.
Testityyppi
AI panos
ihmisen hallinta
Hyvää tieyksikkötestausta
nopea luuranko
Onko odotus oikea?
Reunakotelot
Laaja aivoriihi
Poista epäolennainen
Laajuuden aukkojen täyttö
Löytää ohitetut oksat
Vahvista merkitys
Testitiedot/pilkka
Tuottaa realistisen näytteen
Ei henkilökohtaisia tunnistetietoja, realismin hallinta
Testit hallitsevat laatua, eivät takaa sitä
Korkea testikattavuus antaa luottamusta, mutta se voi myös olla harhaanjohtavaa: 100-prosenttinen kattavuus tarkoittaa, että "jokainen rivi suoritettiin", ei "jokainen rivi on oikein". Tekoälyn kattavuutta on helppo lisätä; Todellinen arvo on merkityksellisten odotusten kirjoittaminen. Testin arvo on sen kyky rikkoa ja varoittaa, kun koodi on rikki. Siksi tekoälyn luomat testit perustuvat kysymykseen "rikkoutuuko koodi todella muuttuessaan?" Testaa sitä kysymyksellä; Viivan tahallinen katkaisu ja testikatkon näkeminen (mutaatioidea) on todiste siitä, että testi toimi.
Vinkki: Jos haluat nähdä, toimiiko tekoälyn kirjoittama testi, luo koodiin pieni bugi (esim. vaihda + merkiksi -) ja katso, katkeaako testi. Jos se ei hajoa, se testi ei suojaa sinua.
Yleisiä virheitä
- Pyytää koetta antamatta sääntöä. Malli pysäyttää nykyisen käyttäytymisen; korjaa virheen "tosi".
- Odotusten hyväksyminen lukematta niitä. Testaus on harhaanjohtavaa, jos et tarkista, että väitteet tarkistavat oikean arvon.
- Testaillaan vain onnellista tietä. Todelliset virheet elävät marginaaleissa; Pyydä reunatapauksia nimenomaisesti.
- Väärennetään laajuus tarkoitukseen. Suuri prosenttiosuus ei takaa oikeaa käyttäytymistä.
- Todellisen/piilotetun datan tekeminen testidataksi. Asiakastietoja tai salaisuuksia ei saa päästää testaukseen ja tallennustilaan; Luo synteettistä dataa.
Yhteenvetona
AI poistaa suuren osan toistuvasta taakasta testien kirjoittamisesta: se tuottaa nopeita luurankoja, suuria luetteloita reunatapauksista ja kattavuusraja-analyysejä. Mutta kriittisin kohta ovat odotukset: AI pyrkii testaamaan koodin nykyistä käyttäytymistä, kun taas testaus tulee kirjoittaa spesifikaatioiden mukaan. Anna sääntö, tarkista odotukset, pakota reunatapaukset voimaan ja testaa, suojaavatko testit todella lisäämällä vian. Testin kattavuus on työkalu, ei tavoite.
Sovellustehtävä
Valitse toiminto ja tulosta ensin testi tekoälylle antamalla sen koodi; Huomioi odotukset. Tulosta sitten testi uudelleen ja anna samalle toiminnolle spesifikaatio (pakollinen toiminta). Vertaa näiden kahden testisarjan odotuksia: onko eroja, kumpi paljastaa todellisen virheen? Varmista lopuksi, että jokin luoduista testeistä toimi lisäämällä koodiin tarkoituksellinen bugi ja katsomalla testikatkon.
tarkistuslista
- [ ] Erotan, onko testin tarkoitus korjata vai tarkistaa käyttäytyminen.
- [ ] Kun pyydän testiä, annan säännön (määrittelyn), jonka pitäisi olla paikallaan, en koodia.
- [ ] Vertailen jokaista luotua väitettä spesifikaatioon.
- [ ] Pyydän nimenomaisesti reuna- ja vikatapauksia.
- [ ] Pidän prosenttiosuutta työkaluna, en tavoitteena.
- [ ] Testaan, suojaako testi todella lisäämällä virheitä.