zisky:
- Schopnosť vytvárať jednotkové, integračné a UI testy s umelou inteligenciou v súlade s testovacou pyramídou a pokrývať limitné a chybové situácie, ako aj šťastné scenáre
- Schopnosť vyradiť prázdne/zbytočné testy a nafúknuté pokrytie kontrolou, že každý vygenerovaný test skutočne potvrdzuje správanie
- Zabezpečte, aby test zachytil chybu a zabránil jej v oprave chyby tým, že povie AI, čo má kód robiť
Písanie kódu je polovica práce; Dokázanie, že kód funguje správne, je druhá polovica. Mobilné aplikácie sa stretávajú so stovkami rôznych zariadení, veľkostí obrazovky, verzií operačného systému a správania používateľov. Nie je možné otestovať všetky tieto manuálne; To je dôvod, prečo je automatizované testovanie (kód na testovanie kódu — testovanie, ktoré prebieha bez ľudského kliknutia) chrbtovou kosťou mobilnej kvality. Umelá inteligencia je neuveriteľne efektívna pri písaní testov, pretože písanie testov je presne ten typ vzorovej práce, ktorú má rád: overovanie špecifického správania pre konkrétne vstupy. V tejto lekcii sa naučíme, ako urýchliť testovanie jednotiek, testovanie rozhrania a automatizáciu s AI, ale zabezpečiť kvalitu testu ľudskými očami.
Testovacia pyramída: čo testovať a koľko
Stratégia zdravého testovania pripomína pyramídu. Základ obsahuje veľké množstvo jednotkových testov (rýchle testovanie, ktoré testuje jedinú funkciu alebo triedu v izolácii); sú rýchle a lacné. V strede je menšie testovanie integrácie (testovanie toho, ako viaceré časti spolupracujú). V hornej časti je minimálne testovanie používateľského rozhrania/end-to-end (testovanie sa vykonáva kliknutím na obrazovku, ako to robí používateľ); sú realistické, ale pomalé a krehké. Umelá inteligencia pomáha na každej úrovni, ale najväčšia hodnota je v základni: rýchle vytváranie jednotkových testov obchodnej logiky.
Typ testu
Rozsah
rýchlosť
Účinnosť AI
jednotkové testovanie
Jedna funkcia/trieda
veľmi rýchlo
veľmi vysoká
integrácia
medzivrstva
stredná
vysoká
UI / end-to-end
Celý stream obrazovky
pomaly
Stredný (krehký)
Tip: Keď hovoríte AI, aby „vygenerovalo testy pre túto funkciu“, výslovne požiadajte o okrajové prípady: prázdny vstup, null, záporné číslo, veľmi veľká hodnota, chyba siete. AI vytvára šťastnú cestu ľahko; Skutočné chyby sa skrývajú v hraniciach a vyskakujú, ak ich tam nechcete.
Kroky písania testov s AI
- Definujte správanie, ktoré sa má testovať. "Táto funkcia by mala dať tento výstup tomuto vstupu."
- Špecifikujte rámec. JUnit + MockK na Androide, XCTest na iOS, Espresso (Android) alebo XCUITest (iOS) pre používateľské rozhranie.
- Požiadajte o medzné stavy. Šťastný scenár + chyba + body zlomu.
- Spravujte falošné objekty. Externé závislosti, ako je sieť a databáza, sú na testovanie emulované (napodobenina – kontrolovaný mock namiesto skutočnej služby).
- Spustite test a overte. Vyhovuje test, potvrdzuje niečo skutočne zmysluplné?
Piaty krok je kritický. AI niekedy produkuje zbytočné testy, ktoré „vždy prejdú“; napríklad test, ktorý nič neoveruje alebo kontroluje vlastné falošné údaje. Úspešný test a hodnotný test sú rôzne veci.
Upozornenie: To, že AI dokáže produkovať, neznamená, že test je správny. Niekedy AI akceptuje aktuálne (možno chybné) správanie kódu ako „správne“ a podľa toho píše testy. Takéto testovanie chybu skôr opravuje, ako ju zachytáva. Vy určíte, čo test očakáva; Povedzte AI, čo má robiť, nie čo robí kód.
Miera pokrytia testov a omyl
Testovacie pokrytie (aké percento kódu je spustené testami) je užitočná, no zavádzajúca metrika. 90% pokrytie znamená, že 90% kódu bolo vykonaných; ale nebolo overené, či tieto linky fungujú správne. Test, ktorý spustí linku a nekontroluje výsledok, nafúkne rozsah, ale neposkytuje bezpečnosť. Cieľom nie sú vysoké čísla, ale zmysluplné overenie. Pomocou AI môžete rýchlo škálovať, ale uistite sa, že každý test skutočne testuje správanie.
tri mini prípady
Prípad 1 – Zachytená hraničná situácia. AI bola požiadaná o testy funkcie prevodu peňazí v bankovej aplikácii a konkrétne boli pridané scenáre „záporná suma“ a „viac ako zostatok“. Test odhalil, že prevod nebol zablokovaný so zápornou sumou; to by bola hlavná bezpečnostná chyba vo výrobe. Uzavreté pridaním jednoriadkového ovládacieho prvku. Ponaučenie: hraničné testy sú najhodnotnejšie testy.
Prípad 2 – Falošný test. Jednému tímu sa uľavilo, keď zvýšil pokrytie na 85 % pomocou 40 testov jednotiek vyrobených AI. Počas kontroly sa ukázalo, že väčšina testov v skutočnosti neoverila žiadny výstup, iba zavolali funkciu a napísali asertTrue(true). Pokrytie bolo vysoké, ale ochrana bola nulová. Testy boli prepracované a prepísané so skutočnými validáciami. Ponaučenie: čísla pokrytia môžu klamať.
Prípad 3 – zrýchlené testovanie používateľského rozhrania. Tím elektronického obchodu napísal skript XCUITest postupu pridávania do košíka s AI za 20 minút; Keby sa to písalo rukou, trvalo by to pol dňa. AI uhádnuté identifikátory prvkov obrazovky; Tím ich spároval so skutočným kódom a opravil ich. Rýchlosť návrhu je skutočná, ale overenie identifikátora je ľudská práca.
Slabá výzva / Silná výzva
Slabá výzva: "Napíšte test pre túto funkciu."
Výkonná výzva: "Vyrobte testy jednotiek pre túto funkciu Kotlin pomocou JUnit5 + MockK. Funkcia: prevod peňazí (suma, zdroj, cieľ). Testovacie správanie (čo má kód ROBIŤ):- Platný prevod musí byť úspešný- Záporná alebo nulová čiastka musí byť odmietnutá- Čiastka väčšia ako zostatok musí byť odmietnutá- Chyba siete musí vyvolať príslušnú externú výnimku Každý test by mal overiť iba jednu vec, ich názvy by mali byť prázdne."
Kopírovateľné šablóny
Šablóna testovania jednotiek: „Vygenerujte testy jednotiek [JUnit/XCTest] pre túto funkciu pre [jazyk]. Očakávané správanie: [čo robiť]. Zahrňte: šťastný scenár, nulový vstup, body prerušenia, prípad chyby. Nechajte každý test overiť jedno správanie; použite zmysluplné tvrdenie; zosmiešňovanie. [kód]“
Šablóna testovania používateľského rozhrania: „Napíšte test používateľského rozhrania nasledujúceho postupu pomocou [Espresso/XCUITest]: [postup používateľa krok za krokom]. Vyberte prvky obrazovky s ID dostupnosti, namiesto textu použite ID. Pridajte stratégiu čakania. Pripomeňte mi, aby som priradil ID prvkov k skutočnému kódu.“
Šablóna testovacieho auditu: „Preskúmajte tieto testy: 1) Skutočne overujú výstup/správanie alebo sú nulové? 2) Pokrývajú limitné prípady? 3) Opravujú kód alebo očakávajú správne správanie? Označte a posilnite slabé testy. [testy]“
Šablóna optimalizácie pokrytia: „Identifikujte netestované časti tejto triedy a navrhnite zmysluplné testy. Uprednostnite cesty so skutočným rizikom, nielen počet pokrytí. [kód]“
Časté chyby
- Len testovanie šťastného scenára. Chyby sú uložené v medzných stavoch; Požiadajte o ne otvorene.
- Prijatie prázdneho/zbytočného testu. Testy typu sustainTrue(true) nafukujú rozsah a neposkytujú žiadnu ochranu.
- Po overení toho, čo kód robí, AI. Testovanie by malo očakávať, čo by mal kód robiť; inak to opravuje chybu.
- Zámena čísla rozsahu pre daný účel. 90% pokrytie neznamená 90% presnosť.
- Prepojenie s textom pri testovaní používateľského rozhrania. Test sa preruší pri zmene textu; Použite stabilný identifikátor (id).
- Nesprávne nastavenie zosmiešňovania. „Test jednotky“, ktorý zavolá skutočnú službu, bude pomalý a krehký.
V súhrne
Testovanie je chrbtovou kosťou mobilnej kvality a AI je v tejto oblasti veľmi efektívna, najmä pri testovaní jednotiek. Postupujte podľa testovacej pyramídy: veľa jednotiek, stredná integrácia, málo testovania používateľského rozhrania. Explicitne požiadajte AI o šťastný scenár, ako aj o limitné prípady a chybové cesty. Uistite sa, že každý vygenerovaný test skutočne potvrdzuje správanie; Prázdne testy a nafúknuté pokrytie sú zavádzajúce. A čo je najdôležitejšie, povedzte AI, čo má kód robiť, nie čo robí, aby test zachytil chybu, nie ju opravil.
Aplikačná úloha
Vyžiadajte si testy od AI pomocou „šablóny testovania jednotiek“ pre funkciu obchodnej logiky (napr. výpočet zľavy alebo overenie formulára) a explicitne špecifikujte limitné prípady (nulové, negatívne, príliš veľké). Spustite vygenerované testy a potom nechajte tie isté testy auditovať pomocou šablóny testovacieho auditu. Nájdite aspoň jeden slabý test, posilnite ho a otestujte, či testy zachytia skutočnú chybu funkcie (pridaním malej chyby).
kontrolný zoznam
- [ ] Vybral som vhodnú vrstvu pre testovaciu pyramídu (prioritná jednotka)
- [ ] Chcel som okrem šťastného scenára aj prípady limitov a chýb
- [ ] Overil som si, že každý test obsahuje zmysluplné tvrdenie
- [ ] Povedal som AI, čo má kód robiť, nie čo robí
- [ ] Zameral som sa na skutočné rizikové cesty, nie na počet krytí
- [ ] V testoch používateľského rozhrania som použil stabilný identifikátor, neviazal som sa na text