Nyereség:
- Képesség mesterséges intelligenciával egység-, integrációs és UI tesztek készítésére a tesztelési piramisnak megfelelően, és lefedheti a limit- és hibahelyzeteket, valamint a boldog forgatókönyveket
- Az üres/haszontalan tesztek és a felduzzasztott lefedettség kiszűrésének képessége annak ellenőrzésével, hogy minden generált teszt valóban érvényesít-e egy viselkedést
- Biztosítani kell, hogy a teszt elkapja a hibát, és megakadályozza a hiba kijavítását azáltal, hogy megmondja az AI-nak, hogy mit tegyen a kód
A kód írása fél munka; A kód helyes működésének bizonyítása a másik fele. A mobilalkalmazások több száz különböző eszközzel, képernyőmérettel, operációs rendszer verzióval és felhasználói viselkedéssel találkoznak. Lehetetlen mindezt manuálisan tesztelni; Ezért az automatizált tesztelés (kódtesztelési kód – emberi kattintás nélkül lefutó tesztelés) a mobilminőség gerince. A mesterséges intelligencia hihetetlenül hatékony a tesztek írásában, mert a tesztek írása pontosan az a fajta mintamunka, amelyet szeret: egy adott viselkedés érvényesítése bizonyos bemenetekhez. Ebben az egységben megtanuljuk, hogyan gyorsíthatjuk fel az egységtesztelést, az interfész tesztelését és az automatizálást mesterséges intelligencia segítségével, de biztosíthatjuk a teszt minőségét emberi szemmel.
Tesztpiramis: mit kell tesztelni és mennyit
Az egészséges tesztelési stratégia piramishoz hasonlít. Az alap nagyszámú egységtesztet tartalmaz (gyorsteszt, amely egyetlen funkciót vagy osztályt külön-külön tesztel); gyorsak és olcsók. Középen kevesebb az integrációs tesztelés (több alkatrész együttműködésének tesztelése). A tetején minimális felhasználói felület/végpontok közötti tesztelés található (a tesztelés a képernyőre kattintva történik, ahogy a felhasználó teszi); valósághűek, de lassúak és törékenyek. A mesterséges intelligencia minden rétegben segít, de a legnagyobb érték az alap: az üzleti logika egységtesztjei gyors elkészítése.
Teszt típusa
Hatály
sebesség
AI hatékonyság
egység tesztelése
Egyetlen funkció/osztály
nagyon gyors
nagyon magas
integráció
közbenső réteg
közepes
magas
UI / end-to-end
Teljes képernyős adatfolyam
lassú
Közepes (törékeny)
Tipp: Amikor azt mondja az AI-nak, hogy "generáljon teszteket ehhez a funkcióhoz", kifejezetten kérjen éleseteket: üres bemenet, nulla, negatív szám, nagyon nagy érték, hálózati hiba. A mesterséges intelligencia könnyen boldog utat produkál; Az igazi hibák a szegélyekben bújnak meg, és kiugrik, ha nem akarod, hogy ott legyenek.
A tesztírás lépései AI-val
- Határozza meg a tesztelni kívánt viselkedést. "Ennek a függvénynek ezt a kimenetet kell adnia ehhez a bemenethez."
- Adja meg a keretet. JUnit + MockK Androidon, XCTest iOS-en, Espresso (Android) vagy XCUITest (iOS) felhasználói felületen.
- Kérjen határállapotokat. Boldog forgatókönyv + hiba + töréspontok.
- Hamis objektumok kezelése. A külső függőségeket, például a hálózatot és az adatbázist emulálják a teszteléshez (mock – ellenőrzött modell a tényleges szolgáltatás helyett).
- Futtassa a tesztet és ellenőrizze. Sikerült a teszt, megerősít-e valami igazán értelmeset?
Az ötödik lépés kritikus. A mesterséges intelligencia néha haszontalan teszteket produkál, amelyek „mindig sikeresek”; például egy teszt, amely nem ellenőrzik semmit, vagy ellenőrzi a saját hamis adatait. A sikeres vizsga és az értékes vizsga különböző dolgok.
Figyelem: Csak azért, mert az AI képes produkálni, még nem jelenti azt, hogy a teszt helyes. Néha az AI „helyesként” fogadja el a kód jelenlegi (talán hibás) viselkedését, és ennek megfelelően teszteket ír. Az ilyen tesztelés inkább javítja a hibát, mintsem elkapja. Ön határozza meg, hogy mit vár a teszt; Mondja meg az AI-nak, hogy mit kell tennie, ne azt, hogy a kód mit csinál.
Teszt lefedettség mértéke és tévedés
A tesztlefedettség (a kód hány százalékát futtatják le a tesztek) hasznos, de félrevezető mérőszám. A 90%-os lefedettség azt jelzi, hogy a kód 90%-a végrehajtásra került; de nem ellenőrizték, hogy ezek a vonalak megfelelően működnek-e. Az a teszt, amely egy sort futtat, és nem ellenőrzi az eredményt, megnöveli a hatókört, de nem nyújt biztonságot. A cél nem a magas számok, hanem az értelmes érvényesítés. A mesterséges intelligencia segítségével gyorsan bővíthető, de ügyeljen arra, hogy minden teszt valóban teszteljen egy viselkedést.
három mini tok
1. eset – Elfogták a határhelyzetet. A mesterséges intelligenciát egy banki alkalmazás pénzátutalási funkciójának tesztelésére kérték fel, és konkrétan "negatív összeg" és "több mint egyenleg" forgatókönyveket adtak hozzá. A teszt során kiderült, hogy az utalást nem blokkolták negatív összeggel; ez komoly biztonsági rést jelentene a termelésben. Egysoros vezérlő hozzáadásával zárva. Tanulság: a határtesztek a legértékesebb tesztek.
2. eset – Hamis teszt. Az egyik csapat megkönnyebbült, hogy 85%-ra növelte a lefedettséget az MI által készített 40 egységteszttel. Az ellenőrzés során kiderült, hogy a legtöbb teszt valójában semmilyen kimenetet nem igazolt, csak meghívták a függvényt, és assertTrue(true)-t írtak ki. A lefedettség magas volt, de a védelem nulla. A teszteket felülvizsgálták és valódi validációkkal újraírták. Tanulság: a lefedettségi számok hazudhatnak.
3. eset – A felhasználói felület tesztelése felgyorsult. Egy e-kereskedelmi csapat 20 perc alatt megírta az XCUITest szkriptet a kosárba helyezés folyamatáról mesterséges intelligencia segítségével; Ha kézzel írták volna, fél napig tartana. AI kitalált képernyőelem-azonosítók; A csapat a valódi kóddal párosította és kijavította őket. A huzat sebessége valós, de az azonosító ellenőrzése emberi munka.
Gyenge felszólítás / Erős felszólítás
Gyenge prompt: "Írjon tesztet ehhez a függvényhez."
Hatékony prompt: "Egységtesztek létrehozása ehhez a Kotlin-függvényhez a JUnit5 + MockK segítségével. Funkció: pénzátutalás (összeg, forrás, cél). Tesztelendő viselkedések (mit kell tennie a kódnak): - Az érvényes átutalásnak sikeresnek kell lennie - A negatív vagy nulla összeget el kell utasítani - Az egyenlegnél nagyobb összeget el kell utasítani - Minden egyes dolog, a teszt hibája ellenőrizheti a megfelelőt a külső szolgáltatás ne írjon üres állítást."
Másolható sablonok
Egységteszt-sablon: "[JUnit/XCTest] egységtesztek létrehozása ehhez a funkcióhoz a következőhöz: [nyelv]. Várt viselkedés: [mi a teendő]. Tartalmazza: boldog forgatókönyv, nulla bemenet, töréspontok, hibaeset. Minden teszt ellenőrizhet egyetlen viselkedést; használjon értelmes állítást; gúny. [kód]"
UI-tesztsablon: "Írjon felhasználói felület tesztet a következő folyamathoz az [Espresso/XCUITest] segítségével: [felhasználói folyamat lépésről lépésre]. Válassza ki a képernyőelemeket akadálymentesítési azonosítóval, használja az azonosítót szöveg helyett. Adjon hozzá várakozási stratégiát. Emlékeztessen, hogy az elemazonosítókat a tényleges kódhoz illessem."
Teszt-ellenőrzési sablon: "Vizsgálja meg ezeket a teszteket: 1) Valóban ellenőriznek egy kimenetet/viselkedést, vagy nullák? 2) Lefedik a limites eseteket? 3) Javítják-e a kódot, vagy megfelelő viselkedést várnak el? A gyenge tesztek megjelölése és megerősítése. [tesztek]"
Lefedettség-optimalizálási sablon: "Azonosítsa ennek az osztálynak a nem tesztelt részeit, és javasoljon értelmes teszteket. A valós kockázattal járó útvonalakat rangsorolja, ne csak a lefedettségek számát. [kód]"
Gyakori hibák
- Csak a boldog forgatókönyv tesztelése. A hibákat a rendszer határállapotban tárolja; Kérd meg őket nyíltan.
- Üres/haszontalan teszt elfogadása. Az assertTrue(true) típusú tesztek felfújják a hatókört, és nem nyújtanak védelmet.
- Az AI ellenőrizze, hogy mit csinál a kód. A tesztelés során arra kell számítani, hogy mit kell tennie a kódnak; egyébként kijavítja a hibát.
- A hatókör számának összetévesztése a céllal. A 90%-os lefedettség nem jelent 90%-os pontosságot.
- Szöveghez való hivatkozás a felhasználói felület tesztelésekor. A teszt megszakad, ha a szöveg megváltozik; Használjon stabil azonosítót (id).
- A gúnyok beállítása helytelenül. A tényleges szolgáltatást hívó "egységteszt" lassú és törékeny lesz.
Összefoglalva
A tesztelés a mobilminőség gerince, és az AI nagyon hatékony ezen a területen, különösen az egységteszteknél. Kövesse a tesztelési piramist: sok egység, közepes integráció, kevés felhasználói felület tesztelése. Kifejezetten kérje meg az AI-t a boldog forgatókönyvről, valamint korlátozza az eseteket és a hibaútvonalakat. Győződjön meg arról, hogy minden generált teszt valóban érvényesít egy viselkedést; Az üres tesztek és a felfújt lefedettség félrevezető. A legfontosabb, hogy mondja meg az AI-nak, hogy mit kell tennie a kódnak, nem pedig azt, hogy mit csinál, így a teszt nem javítja, hanem elkapja a hibát.
Pályázati feladat
Kérjen teszteket az MI-től az „Egységteszt sablon” használatával egy üzleti logikai funkcióhoz (például engedményszámításhoz vagy űrlapérvényesítéshez), és kifejezetten határozza meg a határeseteket (null, negatív, túl nagy). Futtassa le a generált teszteket, majd auditálja ugyanazokat a teszteket a „Teszt audit sablonnal”. Keressen legalább egy gyenge tesztet, erősítse meg, és tesztelje, hogy a tesztek észlelik-e a függvény tényleges hibáját (egy kis hiba hozzáadásával).
ellenőrző lista
- [ ] Kiválasztottam a megfelelő réteget a tesztpiramishoz (prioritási egység)
- [ ] Szerettem volna limit- és hibaeseteket a boldog forgatókönyv mellett
- [ ] Ellenőriztem, hogy minden teszt tartalmaz-e értelmes állítást
- [ ] Megmondtam az AI-nak, hogy mit kell tennie a kódnak, nem pedig azt, hogy mit csinál
- [ ] A tényleges kockázati utakra koncentráltam, nem a fedezetek számára
- [ ] UI teszteknél stabil azonosítót használtam, szöveghez nem kötöttem