Tesztgyártás és minőségbiztosítás

Nyereség:

• Képes egységtesztelés, szélső esetek és lefedettségi réselemzés készítésére AI segítségével
• Lehetőség a teszt elvárások kinyomtatására a specifikáció alapján, nem pedig a kód aktuális viselkedése alapján
• Lehetőség annak tesztelésére, hogy a teszt valóban véd-e a hibák beszúrásával

A tesztek írása az egyik leginkább értéktermelő feladat, amelyet a legtöbb fejlesztő halogat. Egy jó tesztkészlet bizonyítja, hogy a kód megfelelően működik, és mentőöv a jövőbeni változtatásokhoz. A probléma az, hogy a tesztek írása ismétlődő és időigényes – pontosan az a fajta munka, ahol az AI ragyog. De van egy bökkenő: az AI gyakran a kód meglévő viselkedését teszteli, nem pedig azt, amilyennek lennie kellene. Ennek a különbségnek a kezelése ennek az egységnek a lényege.

Ebben az egységben elsajátíthatja az egységtesztet (olyan tesztelést, amely egy funkciót önmagában, elszigetelten tesztel), az éles esetteszteket és tesztadatok generálását AI-val; hiányosságok megszüntetése a teszt lefedettségében; és miért veszélyes vakon bízni az AI-tesztekben.

A tesztelés két oldala: A viselkedés javítása kontra ellenőrzés

Egy teszt két különböző célt szolgálhat. Az első az ellenőrzés: azt teszteli, hogy a kód helyes-e, megfelel-e a specifikációnak. A második a regressziós védelem: ma lefagyasztja a kód viselkedését, így ha valaki véletlenül holnap megváltoztatja, a teszt megszakad és értesít.

Az AI nagyon jó az utóbbiban; Megnézi a kódot, és olyan eseteket generál, amelyek tesztelik, hogy „mit csinál éppen”. De ha a kód kezdettől fogva hibás, a mesterséges intelligencia ezt a hibás viselkedést „helyesnek” minősítheti. Tehát át kell tekintenie az AI által készített minden teszt állítását: "A kód 42-t ad vissza, a teszt pedig 42-t vár" nem jelenti azt, hogy a 42 a helyes válasz.

Vigyázat: Ha az AI átmegy a teszten, ez nem jelenti azt, hogy a kód "működik"; ez csak azt jelenti, hogy "úgy viselkedik, ahogy az AI elvárja". A specifikáció alapján dönti el, hogy az elvárás helyes-e vagy sem.

Lépésről lépésre: Robusztus tesztek írása mesterséges intelligencia segítségével

1. Adja meg a specifikációt, ne csak a kódot. Ha hozzáadja az "Ennek a funkciónak ezt kell tennie" információt, az AI meg tudja írni a helyes elvárást; Az aktuális viselkedést teszteli, ha csak megadja a kódot.
2. Kérjen éles tokot. Üres, nulla, nulla, negatív, túl nagy, rossz formátum, egyidejűség – kifejezetten állítsa le a boldog útról.
3. Adja meg a tesztelési keretet és stílust. "pytest használata", "Arrange-Act-Assert minta", "minden teszt teszteljen egy dolgot" stb.
4. Ellenőrizze az elvárásokat (állítás). Hasonlítsa össze a specifikációval, amelyet minden állítás ellenőrzi a helyes érték szempontjából.
5. Szorítsa be a hatókör hiányosságait. Adja meg a meglévő teszteket, és kérdezze meg, hogy "mely ágakat és eseteket nem tesztelték?" kérdezz rá; majd ellenőrizze a további teszteket.

Három mini tok

1. eset – Lefedettség 52%-ról 85%-ra. Egy szolgáltatási modul tesztlefedettsége 52% volt. A csapat betáplálta a meglévő teszteket az MI-be, listáztatta a nem tesztelt ágakat, és teszteket generált hozzájuk. Emberi felülvizsgálattal a lefedettség 85%-ra nőtt; A folyamat során az AI tényleges hibát (egy olyan útvonalat, amely rossz hibakódot adott vissza) feltárt egy korábban soha nem tesztelt hibaágban.

2. eset – A hamis elvárások rögzítésének csapdája. A pénzkerekítési függvény valójában hibás volt; Ahelyett, hogy 2,675-öt 2,67-re kerekített volna, 2,68 helyett 2,67-et kerekített. Az AI megnézte a kódot, és kiírta, hogy assert round_money(2.675) == 2.67 – a hibát „igaz”-ként rögzíti. Amikor a fejlesztő elolvasta a specifikációt, korrigálta a várakozást, és elkapta a valódi hibát. Nem a kód, hanem a szabály tesztelése hozta meg a különbséget.

3. eset – Élállapot-robbanás. Amikor a mesterséges intelligencia csak „éleseteket” kér egy dátumtartomány funkcióhoz; 8 esetet produkált, például start=end, fordított intervallum, szökőév február 29., különböző időzónák és null intervallum. Ezek közül kettő (fordított térköz és szökőév) okozta a hibát. Ezen esetek kézi mérlegelése gyakran kimarad; A mesterséges intelligencia itt az „éles esetek ötletbörze” partnerévé vált.

Négy másolható sablon

Specifikáció alapú tesztgenerálás:

Szerep: fejlesztő, aki teszteket ír. Keretrendszer: {{pytest/JUnit/Jest...}}.Mit KELL TENNI a függvénynek (specifikáció): {{rule}}Írjon teszteket a következő függvényhez. Elvárásokat írj a specifikáció szerint, NE a kód aktuális kimenetét. Happy path + adjunk hozzá legalább 4 éles esetet. Minden teszt teszteljen egy dolgot, használjon leíró nevet. {{funkció}}

Edge case brainstorming:

Sorolja fel az él/hiba eseteket, amelyeket meg kell próbálni ennek a függvénynek a tesztelése során (null, null, töréspontok, rossz formátum, egyidejűség, külső hiba). Minden esetre: bemenet, várható viselkedés. Még NE írjon kódot, csak listázzon.{{function}}

Lefedettségi rés elemzése:

Az alábbiakban a funkciók és a rendelkezésre álló tesztek láthatók. Mely ágakat, feltételeket és eseteket nem tesztelték? Sorolja fel a hiányosságokat, és csak a hiányosságokra írjon új teszteket! Ne ismételje meg a meglévőket. Funkció:{{function}}Tesztek:{{existing_tests}}

Tesztadatok / hamis objektumok generálása:

Reális tesztadatok létrehozása a {{function/service}} tesztekhez: érvényes minták, határminták és érvénytelen minták külön-külön. Javasoljon egy egyszerű álviselkedést a(z) {{X}} külső függőséghez. Valódi bizalmas adatok/PII használata; Hamis adatok generálása.

Gyenge felszólítás / Erős felszólítás

Gyenge: "Írjon tesztet ehhez a függvényhez."

Erős: "pytesttel. Applikáció_kedvezmény(összesen, százalék) — szabály: a kedvezménynek 0%–30%-nak kell lennie, a határokon kívül ValueError-t kell dobni, az eredményt 2 tizedesjegyre kell kerekíteni. Az elvárásokat ezzel a SZABÁLYZALRA írjuk (nem kód szerint). Happy path + ezek a szélső esetek: 0%, 30%, 31% (hiba.]) összesen

Megadja az erős kiadási szabályt, és azt mondja, hogy "az elvárást a szabály szerint írd, ne a kódot"; Ez az egyetlen mondat bezárja a mesterséges intelligencia helytelen viselkedésének javításának csapdáját.

Teszt típusa

AI hozzájárulás

emberi kontroll

Boldog útegység tesztelést

gyors csontváz

Helyes az elvárás?

Edge tokok

Kiterjedt ötletbörze

Távolítsa el a lényegtelent

Hatókör rés kitöltése

Kihagyott ágakat talál

Erősítse meg a jelentőségét

Tesztadatok/álca

Reális mintát készít

Nincs személyazonosító adat, realizmus ellenőrzés

A tesztek irányítják a minőséget, nem garantálják

A magas tesztlefedettség magabiztosságot ad, de félrevezető is lehet: a 100 százalékos lefedettség azt jelenti, hogy "minden sor lefutott", nem pedig "minden sor helyes". Könnyen növelhető a lefedettség AI-val; Az igazi érték az értelmes elvárások írása. A teszt értéke abban rejlik, hogy képes feltörni és figyelmeztetni, ha a kód meghibásodik. Ezért a mesterséges intelligencia által generált tesztek azon a kérdésen alapulnak, hogy "a kód valóban eltörik, amikor megváltozik?" Teszteld a kérdéssel; Szándékos vonaltörés és a teszttörés (mutációs ötlet) látása a teszt működésének bizonyítéka.

Tipp: Ha látni szeretné, hogy az AI által írt teszt működik-e, hozzon létre egy kis hibát a kódban (pl. módosítsa a + jelet -ra), és nézze meg, hogy a teszt megszakad-e. Ha nem törik el, a teszt nem véd meg.

Gyakori hibák

• Teszt kérése a szabály megadása nélkül. A modell leállítja az aktuális viselkedést; "igaz"-ként javítja a hibát.
• Elfogadja az elvárásokat anélkül, hogy elolvasná azokat. A tesztelés félrevezető, ha nem ellenőrzi, hogy az állítások a megfelelő értéket ellenőrzik-e.
• Csak tesztelem a boldog utat. A valódi hibák a margón élnek; Kérjen éles eseteket kifejezetten.
• A terjedelem összetévesztése a céllal. A magas százalék nem garancia a helyes viselkedésre.
• Valós/rejtett adatok készítése tesztadatként. Az ügyféladatok vagy titkok nem kerülhetnek tesztelésre és tárolásra; Szintetikus adatok generálása.

Összefoglalva

Az AI leveszi a tesztírással járó ismétlődő terhek nagy részét: gyors vázakat, szélső esetek nagy listáit és lefedettségi hiányelemzéseket készít. De a legkritikusabb pont az elvárások: az AI hajlamos a kód aktuális viselkedését tesztelni, míg a tesztelést a specifikációnak megfelelően kell megírni. Adja meg a szabályt, ellenőrizze az elvárásokat, érvényesítse az éles eseteket, és tesztelje, hogy a tesztek valóban védenek-e egy hiba beszúrásával. A tesztek lefedettsége eszköz, nem cél.

Pályázati feladat

Válasszon ki egy funkciót, és először nyomtasson egy tesztet az AI-nak, egyszerűen megadva a kódját; Vegye figyelembe az elvárásokat. Ezután nyomtassa ki újra a tesztet, megadva ugyanannak a függvénynek a specifikációját (szükséges viselkedés). Hasonlítsa össze a két tesztkészlet elvárásait: van-e különbség, melyik mutat valódi hibát? Végül ellenőrizze, hogy az egyik generált teszt működött-e úgy, hogy szándékos hibát ad hozzá a kódhoz, és látja a tesztszünetet.

ellenőrző lista

• [ ] Megkülönböztetem, hogy a teszt a viselkedés javítását vagy ellenőrzését szolgálja.
• [ ] Amikor tesztet kérek, azt a szabályt (specifikációt) adom meg, aminek a helyén kell lennie, nem a kódot.
• [ ] Az egyes generált állításokat összehasonlítom a specifikációval.
• [ ] Kifejezetten él- és hibaeseteket kérek.
• [ ] A százalékos lefedettséget eszköznek tekintem, nem célnak.
• [ ] Azt tesztelem, hogy a teszt valóban véd-e a hibák beszúrásával.