zisky:
- Schopnost vytvářet testy jednotek, integrace a uživatelského rozhraní s umělou inteligencí v souladu s testovací pyramidou a pokrývat limitní a chybové situace, stejně jako šťastné scénáře
- Schopnost vyřadit prázdné/zbytečné testy a nabubřelé pokrytí kontrolou, že každý vygenerovaný test skutečně ověřuje chování
- Zajištění, že test zachytí chybu a zabrání jí opravit chybu tím, že řekne AI, co má kód dělat
Psaní kódu je polovina práce; Dokázat, že kód funguje správně, je druhá polovina. Mobilní aplikace se setkávají se stovkami různých zařízení, velikostí obrazovky, verzí operačního systému a chování uživatelů. Je nemožné otestovat všechny tyto ručně; Proto je automatizované testování (kód testování kódu — testování, které běží bez lidského kliknutí) páteří mobilní kvality. Umělá inteligence je neuvěřitelně efektivní při psaní testů, protože psaní testů je přesně ten typ práce se vzorem, který má ráda: ověřování specifického chování pro konkrétní vstupy. V této jednotce se naučíme, jak urychlit testování jednotek, testování rozhraní a automatizaci s AI, ale zajistit kvalitu testu lidskýma očima.
Testovací pyramida: co testovat a kolik
Strategie zdravého testování připomíná pyramidu. Základ zahrnuje velké množství jednotkových testů (rychlé testování, které testuje jednu funkci nebo třídu v izolaci); jsou rychlé a levné. Uprostřed je menší integrační testování (testování toho, jak více částí spolupracuje). Nahoře je minimální UI/end-to-end testování (testování se provádí kliknutím na obrazovku jako uživatel); jsou realistické, ale pomalé a křehké. Umělá inteligence pomáhá na každé vrstvě, ale největší hodnotu má základ: rychlé vytváření jednotkových testů obchodní logiky.
Typ testu
Rozsah
rychlost
Účinnost AI
testování jednotky
Jediná funkce/třída
velmi rychle
velmi vysoká
integrace
mezivrstva
střední
vysoká
UI / end-to-end
Celý stream obrazovky
pomalý
Střední (křehké)
Tip: Když říkáte AI, aby „vygenerovalo testy pro tuto funkci“, výslovně požádejte o okrajové případy: prázdný vstup, null, záporné číslo, velmi velká hodnota, chyba sítě. AI snadno vytváří šťastnou cestu; Skutečné chyby se schovávají v hranicích a vyskakují, pokud je tam nechcete.
Kroky psaní testů s AI
- Definujte chování, které má být testováno. "Tato funkce by měla dát tento výstup tomuto vstupu."
- Určete rámec. JUnit + MockK na Androidu, XCTest na iOS, Espresso (Android) nebo XCUITest (iOS) pro uživatelské rozhraní.
- Zeptejte se na mezní stavy. Šťastný scénář + chyba + body přerušení.
- Správa falešných objektů. Externí závislosti, jako je síť a databáze, jsou pro testování emulovány (mock — řízený mock namísto skutečné služby).
- Spusťte test a ověřte. Projde test, potvrdí něco skutečně smysluplného?
Pátý krok je kritický. AI někdy produkuje zbytečné testy, které „vždy projdou“; například test, který nic neověřuje nebo kontroluje vlastní falešná data. Úspěšný test a hodnotný test jsou různé věci.
Upozornění: To, že umělá inteligence dokáže produkovat, neznamená, že je test správný. Někdy AI přijme aktuální (možná chybné) chování kódu jako „správné“ a podle toho zapíše testy. Takové testování chybu spíše opravuje, než že by ji zachytilo. Vy určíte, co test očekává; Řekněte AI, co má dělat, ne co dělá kód.
Míra pokrytí testu a omyl
Pokrytí testem (jaké procento kódu je spuštěno testy) je užitečná, ale zavádějící metrika. 90% pokrytí znamená, že 90% kódu bylo provedeno; ale nebylo ověřeno, že tyto linky fungují správně. Test, který spustí linku a nezkontroluje výsledek, nafoukne rozsah, ale neposkytuje zabezpečení. Cílem nejsou vysoká čísla, ale smysluplné ověření. Pomocí AI můžete rychle škálovat, ale ujistěte se, že každý test skutečně testuje chování.
tři mini pouzdra
Případ 1 – Zachycena hraniční situace. AI byla požádána o testy funkce převodu peněz v bankovní aplikaci a konkrétně byly přidány scénáře „záporná částka“ a „více než zůstatek“. Test odhalil, že převod nebyl zablokován zápornou částkou; to by byla hlavní bezpečnostní chyba ve výrobě. Uzavřeno přidáním jednořádkového ovládacího prvku. Poučení: hraniční testy jsou nejcennější testy.
Případ 2 – Falešný test. Jeden tým získal úlevu a zvýšil pokrytí na 85 % pomocí 40 testů jednotek vytvořených AI. Během inspekce bylo vidět, že většina testů ve skutečnosti žádný výstup neověřovala, pouze zavolala funkci a napsala sustainTrue(true). Pokrytí bylo vysoké, ale ochrana byla nulová. Testy byly přepracovány a přepsány se skutečnými validacemi. Poučení: čísla pokrytí mohou lhát.
Případ 3 – Urychlené testování uživatelského rozhraní. Tým elektronického obchodu napsal skript XCUITest postupu přidávání do košíku s umělou inteligencí za 20 minut; Kdyby se to psalo ručně, trvalo by to půl dne. AI uhádla identifikátory prvků obrazovky; Tým je spojil se skutečným kódem a opravil je. Rychlost návrhu je skutečná, ale ověření identifikátoru je lidská práce.
Slabá výzva / Silná výzva
Slabá výzva: "Napište test pro tuto funkci."
Výkonná výzva: "Vytvářejte testy jednotek pro tuto funkci Kotlin pomocí JUnit5 + MockK. Funkce: převod peněz (částka, zdroj, cíl). Chování k testování (co by měl kód DĚLAT):- Platný převod musí být úspěšný- Záporná nebo nulová částka musí být odmítnuta- Částka větší než zůstatek musí být odmítnuta- Chyba sítě musí vyvolat příslušnou externí výjimku Každý test by měl ověřovat pouze jednu věc, jejich jména by měla být prázdná."
Kopírovatelné šablony
Šablona testu jednotek: "Generovat [JUnit/XCTest] testy jednotek pro tuto funkci pro [jazyk]. Očekávané chování: [co dělat]. Zahrnout: šťastný scénář, nulový vstup, body přerušení, případ chyby. Nechte každý test ověřit jediné chování; použijte smysluplné tvrzení; zesměšněte. [kód]“
Šablona testování uživatelského rozhraní: "Napište test uživatelského rozhraní následujícího toku pomocí [Espresso/XCUITest]: [postup uživatele krok za krokem]. Vyberte prvky obrazovky s ID přístupnosti, místo textu použijte id. Přidejte strategii čekání. Připomeňte mi, že mám přiřadit ID prvků ke skutečnému kódu."
Šablona auditu testu: „Prozkoumejte tyto testy: 1) Skutečně ověřují výstup/chování, nebo jsou nulové?2) Pokrývají limitní případy?3) Opravují chyby v kódu nebo očekávají správné chování? Označte a posílí slabé testy. [testy]“
Šablona optimalizace pokrytí: "Identifikujte netestované části této třídy a navrhněte smysluplné testy. Upřednostňujte cesty se skutečným rizikem, nikoli pouze počet pokrytí." [kód]"
Časté chyby
- Jen testování šťastného scénáře. Chyby jsou uloženy v mezních stavech; Požádejte o ně otevřeně.
- Přijetí prázdného/neužitečného testu. Testy typu sustainTrue(true) zvětšují rozsah a neposkytují žádnou ochranu.
- Nechat AI ověřit, co kód dělá. Testování by mělo očekávat, co by měl kód dělat; jinak chybu opravuje.
- Záměna čísla oboru pro daný účel. 90% pokrytí neznamená 90% přesnost.
- Odkazování na text v testování uživatelského rozhraní. Test je přerušen při změně textu; Použijte stabilní identifikátor (id).
- Nesprávné nastavení zesměšňování. "Test jednotky", který volá skutečnou službu, bude pomalý a křehký.
V souhrnu
Testování je páteří mobilní kvality a AI je v této oblasti velmi efektivní, zejména při testování jednotek. Postupujte podle testovací pyramidy: mnoho jednotek, střední integrace, malé testování uživatelského rozhraní. Explicitně požádejte AI o šťastný scénář, stejně jako limitní případy a chybové cesty. Ujistěte se, že každý vygenerovaný test skutečně ověřuje chování; Prázdné testy a nafouknuté krytí jsou zavádějící. A co je nejdůležitější, řekněte AI, co má kód dělat, ne co dělá, aby test zachytil chybu, ne ji opravil.
Aplikační úkol
Vyžádejte si testy od AI pomocí „šablony testu jednotek“ pro funkci obchodní logiky (např. výpočet slevy nebo ověření formuláře) a explicitně specifikujte limitní případy (null, negativní, příliš velký). Spusťte vygenerované testy a poté nechte stejné testy auditovat pomocí šablony Test auditu. Najděte alespoň jeden slabý test, posilněte jej a otestujte, zda testy zachytí skutečnou chybu funkce (přidáním malé chyby).
kontrolní seznam
- [ ] Vybral jsem vhodnou vrstvu pro testovací pyramidu (prioritní jednotka)
- [ ] Kromě šťastného scénáře jsem chtěl limitní a chybové případy
- [ ] Ověřil jsem, že každý test obsahuje smysluplné tvrzení
- [ ] Řekl jsem AI, co má kód dělat, ne co dělá
- [ ] Zaměřil jsem se na skutečné rizikové cesty, nikoli na počet krytí
- [ ] V testech uživatelského rozhraní jsem použil stabilní identifikátor, nevázal jsem se na text