Nyereség:
- Képes megakadályozni, hogy a mesterséges intelligencia „helyesként” fogadja el a hibás viselkedést úgy, hogy az egységtesztekben az elfogadási szabálytól függetlenül kiszámítja a várható értéket
- Gyors, független és megismételhető tesztek nyomtatása az AAA és FIRST elvek alkalmazásával és a külső függőségek gúnyolásával
- Képes mutációval (kódtöréssel) végzett tesztek tesztelésére és a nehezen tesztelhető kód tervezési szagaként való felismerésére
A tesztelési piramis legnagyobb és leggyorsabb rétege az egységtesztelés – olyan tesztelés, amely egy funkciót vagy egy kis kódrészletet minden mástól elkülönítve ellenőriz. Egységtesztek ezrei futnak le másodpercek alatt, és hibát észlelnek, miközben a kód még mindig a fejlesztő képernyőjén van. A mesterséges intelligencia (AI) talán a legjártasabb az egységtesztek előállításában: te adsz neki egy funkciót, az AI pedig tesztek tucatjait készíti. De éppen ez a kényelem okozza a legnagyobb csapdát: az AI könnyen készít teszteket, amelyek „zölden világítanak, de nem ellenőriznek semmit”, vagy elfogadják a kód jelenlegi (talán hibás) viselkedését „helyesnek”. Ebben az egységben megtanulhatja, hogyan kell valóban védő egységteszteket írni AI-val, valamint a tesztelhető kód és az AI közötti kapcsolatot.
A jó egységteszt tulajdonságai: ELSŐ
A jó egységtesztek a FIRST elveket követik: gyors, független (a tesztek nem függhetnek egymástól), megismételhető (megismételhető – ugyanaz az eredmény bármilyen környezetben), önellenőrző (egyértelműen megfelelt/nem), időszerű (időben). Emlékeztesd magad ezekre az elvekre, amikor a mesterséges intelligencia teszteket készít; külön kérje meg, hogy a teszt ne függjön a külvilágtól (tényleges adatbázis, hálózat, óra), legyen "független" és "ismételhető".
AAA minta és kifejező hatás
A szilárd egységteszt az AAA struktúrát követi: Elrendezés (előkészítés – bemenetek és függőségek beállítása), Act (végrehajtás – tesztelés alatt álló függvény meghívása), Assert (érvényesítés – az eredmény összehasonlítása a várt értékkel). A kritikus az érvényesülés. A mesterséges intelligencia leggyakoribb hibája az, hogy az állítást a tesztelt kód kimenetéből vezeti le – a „bármit a kód visszaad, az igaz” logika. Ez értelmetlenné teszi a tesztet. A helyes módszer a várható érték önálló meghatározása (az elfogadási kritériumok alapján manuálisan számítja ki).
Figyelem: Ha azt mondja az AI-nak, hogy "írjon tesztet ehhez a funkcióhoz", az AI futtathatja a függvényt, és a kimenetét "elvárt"-ként írja ki. Ez a teszt akkor is sikeres, ha a függvény hamis. Ehelyett mondja azt, hogy "a várt eredményeket ezeknek a szabályoknak megfelelően számítja ki, ne hivatkozzon a függvény aktuális kimenetére."
Gúnyok, csonkok és függőségek
Az egység tesztelése elszigetelést igényel. Ha a függvény egy adatbázistól vagy API-tól függ, akkor azokat a tesztelés során álobjektumokkal (mock/stub – a valódi függőség ellenőrzött, ál-helyettesítője) helyettesítjük. Ezáltal a teszt gyors, független és reprodukálható. A mesterséges intelligencia áltelepítést készíthet; De óvakodj a túlzott gúnyolódástól: ha mindent kigúnyol, a teszt csak azt fogja ellenőrizni, hogy "mit ad vissza a gúny", nem a tényleges logikát. Egyensúly: emulálja a külvilágot, hajtsa végre a tesztelés alatt álló valódi logikát.
Tesztelhetőség és AI
Van egy érdekes visszajelzés: a nehezen tesztelhető kód gyakran rosszul megtervezett kód. Ha az AI-nak problémái vannak a tesztek írásával egy függvényhez (túl sok függőség, rejtett globális állapot, mellékhatások), ez tervezési szaga. Ha megkérdezzük az AI-tól, hogy „hogyan alakítaná át ezt a kódot, hogy tesztelhető legyen” – jobb tesztelést és jobb kódot eredményez.
Paraméterezett tesztek és adatdiverzitás
Minden alkalommal külön tesztet írni, hogy ugyanazt a szabályt különböző bemenetekkel ellenőrizzük, fárasztó és nehéz karbantartani. A paraméterezett tesztelés – egy olyan struktúra, amely ismételten ugyanazt a tesztlogikát futtatja a bemenetek és a várt eredmények listáján – kiküszöböli ezt az ismétlést: egyetlen teszttestet több tucat bemeneti párral táplálunk. Az AI nagyon hatékonyan állítja elő ezeket a bemeneti elvárt eredmény táblázatokat, ha megadja neki az elfogadási szabályokat; Különösen szisztematikusan táblázatba foglalja a határértékeket és az egyenértékűségi osztályokat.
De itt is van egy csapda: az AI hajlamos a tesztelt kódból levezetni a generált táblázatban a várt eredményeket. Ez a hiba még veszélyesebb a paraméterezett tesztelésnél, mert egyetlen hibás logika több tucat sort érvénytelenít. Ezért a várható eredmény oszlopát mindig önállóan számítsa ki az elfogadási szabály szerint, és legalább néhány sort manuálisan érvényesítsen. Kérjen egy leírás oszlopot is: "mit jelképeznek az egyes sorok"; így ha egy sor megszakad, azonnal láthatja, hogy melyik állapot tört meg.
Tipp: Szándékosan adjon hozzá egy „csapdasort” a paraméterezett teszttáblázathoz – vagyis tudatosan félreírja az eredményt. Ha ez a vonal nem válik pirosra a teszt futtatásakor, akkor a teszt valójában nem igazolja a helyzetet. Ez egy gyors ál-pass ellenőrzés.
Gyenge felszólítás / Erős felszólítás
Gyenge: "Írjon egységtesztet ehhez a függvényhez."
Erős: Írjon [nyelv/keret] egységteszteket a "taxCalculate(összeg, kulcs) függvényhez. Elfogadási szabály: eredmény = összeg * kulcs, 2 tizedesjegyre kerekítve; negatív összeg vagy arány hibát dob; 0-t ad vissza, ha az arány 0. Használja az AAA struktúrát. Számítsa ki manuálisan a várható értékeket EZEK a szabályok szerint. tizedesjegyig) írja le az általa ellenőrzött szabályt.
Erőteljes felszólítás; Megadja az elfogadási szabályt, a független várható érték elvárást, a szerkezetet és az éleseteket. Így a teszt a szabály őre lesz, nem pedig a kód tükre.
Egységteszt minőségi táblázat
tünet
Rossz teszt (hamis bizalom)
jó teszt
állítja
Nincs vagy "nem null"
Várható konkrét érték
Várható értékforrás
A függvény kimenete
Átvételi szabály / kézi számítás
függőség
Tényleges DB/hálózat/óra
Szigetelve álfallal/csonkkal
éles tok
Csak boldog út
határérték, negatív, hiba
Amikor feltöri a kódot
zöld marad
pirosra vált
Név
teszt1, tesztmódszer
leírja az általa megerősített szabályt
Négy másolható sablon
1) Szabályvezérelt egység tesztelése:
Az Ön szerepköre: vezető szoftvertesztmérnök. Írjon egységtesztet a következő függvényre [nyelv/keretrendszer]: [aláírás].Elfogadási szabályok: [szabályok].- Használjon AAA-struktúrát.- Várható értékek manuális kiszámítása EZEK a szabályok szerint; NE hivatkozzon a funkció aktuális kimenetére. - Fedje le a határértéket, a negatívot, a hibát és a boldog utat külön tesztekkel. - Minden tesztnév írja le az általa ellenőrzött szabályt. - A külső függőségek gúnyolódása; Működtesse a tényleges logikát.
2) Mutációs ellenállás szabályozása:
Tekintse meg ezeket az egységteszteket. Soroljon fel 5 kisebb módosítást, amit a tesztelés alatt álló kódon végezhetek (a - a + helyett, a >= a > helyett, egy határeltolódás), és mindegyikhez mondja meg, hogy ezek közül a tesztek közül melyik fog pirosra váltani? Ha egyiket sem adják vissza, a teszt nem elegendő. Kód + tesztek: [beillesztés]
3) Tesztelhetőség áttekintése:
Miért nehéz egységtesztet írni ehhez a függvényhez? Rejtett függőség, globális státusz, mellékhatások, sok a felelősség? Javasoljon minimális átalakítást, hogy tesztelhető legyen; ne változtasson viselkedésén. Kód: [beillesztés]
4) A forgatókönyv befejezetlen befejezése:
A következő funkciót és elérhető teszteket adjuk meg. Sorolja fel, hogy mely viselkedést/éleseteket SOHA nem tesztelték (hatókörrés), és mindegyikhez adjon hozzá egy tesztet. Funkció+tesztek: [beillesztés]
három mini tok
1. eset – A kód tükrözésének tesztelése. Egy fejlesztő megkérte az AI-t, hogy tesztet írjon a kerekítési funkcióhoz; 10 teszt zöld volt. Valójában a függvény rossz irányba kerekített, de az AI a várt értékeket vette ki a függvény kimenetéből, így a tesztek "igaznak" ítélték a hibát. Amikor a várt értékeket manuálisan kiszámítottuk a "szabályvezérelt" sablonnal, 4 teszt vált pirosra, és kiderült a valódi hiba.
2. eset – A mutációkontroll értéke. Az egyik csapat 45 egységtesztre támaszkodott. Kipróbáltam 20 kisebb módosítást a kódon a "mutációs robusztusság ellenőrzésével"; a tesztek közülük csak 11-et fogtak ki. A fennmaradó 9 fennakadás csendben elmúlt. A csapat erősített gyenge teszteket; Ezek a továbbfejlesztett tesztek tényleges számítási hibát észleltek a következő kiadásban.
3. eset – A tesztelhetetlenség dizájnszag. Az AI nem tudott teszteket írni egy rendelési függvényhez, folyamatosan szüksége volt a valódi adatbázisra. A "tesztelhetőségi áttekintés" sablon azt mutatta, hogy a funkció beágyazott adatbázis-hozzáférést tartalmaz. Amikor a függőségi injekciót eltávolították, teszteket lehetett írni, és a kód tisztább lett.
Gyakori hibák
- A várható érték levezetése kódból. Az AI „helyesként” fogadja el a függvény kimenetét; teszt, amely megerősíti a hibás kódot.
- Teszt állítás nélkül vagy triviális állítással. "Nem dobott hibát, átment" logika; Nem erősít meg semmit.
- Extrém gúny. Mindent kigúnyolni és csak azt tesztelni, amit a gúny visszaad; a valódi logika nincs tesztelve.
- Csak a boldog út. Határérték, negatív és hibaállapotok megkerülése.
- Nem a kód feltörésével tesztel. A zöldben bízva mutáció ellenőrzése nélkül.
- A tesztelhetetlenség figyelmen kívül hagyása. Nem ismeri fel és nem javítja ki a rossz tervezést, ahelyett, hogy kemény tesztelést hajtana végre.
Összefoglalva
Az egységtesztek a tesztelési piramis leggyorsabb és legnagyobb rétege; A hibát a legolcsóbb pillanatban fogja el. A mesterséges intelligencia nagyon képes egységteszteket készíteni, de a legnagyobb buktatója olyan tesztek írása, amelyek a hibás viselkedést "helyesnek" feltételezik azáltal, hogy magából a kódból származtatják a várt értéket. Megoldás: adja meg az elfogadási szabályokat, számolja ki manuálisan a várható értékeket, érvényesítse az AAA és FIRST elvet, gúnyolja ki a külvilágot és futtassa le a tényleges logikát, és mutációval tesztelje le (a kód feltörése). A nehezen tesztelhető kód egy tervezési jel, amelyet javítani kell.
Pályázati feladat
Válasszon ki egy függvényt, amely üzleti szabályt tartalmaz a saját projektjéből. Írjon elfogadási szabályokat, és írja be az AI-teszteket a „szabályvezérelt egységteszt” sablonnal; Számítsa ki manuálisan a várható értékeket. Ezután alkalmazza a „mutációs robusztussági ellenőrzést”: legalább 5 kis törést tegyünk a kódban, és mérjük meg, hány teszt vált pirosra. Adjon hozzá új tesztet az el nem fogott korrupciókhoz. Jelentse, hány zavart észleltek (például mutációs pontszámot).
ellenőrző lista
- [ ] Megadtam az elfogadási szabályokat, és manuálisan kiszámoltam a várható értékeket.
- [ ] Megbizonyosodtam arról, hogy a tesztek nem a kódból származtatták a várt értéket.
- [ ] Független tesztelést hoztam létre az AAA és a FIRST irányelvek alapján.
- [ ] Megcsúfoltam a külső függőségeket, és lefuttattam a tényleges logikát.
- [ ] Kitértem a limit-, negatív- és hibaesetekre.
- [ ] A kód feltörésével (mutáció) bebizonyítottam, hogy a tesztek valóban védenek.