zisky:
- Schopnost rozpoznat tři tváře pseudodůvěry (neasertivní, sebeprosazující se, triviální tvrzení) a aplikovat protijedy
- Schopnost používat testování mutací a skóre mutací jako přesnější měřítko kvality než procento pokrytí nástrojem nebo rukou
- Schopnost postavit AI jako červený tým proti testování a hledat mezery v testování, aniž byste se dostali do pasti chvály
Jádrem tohoto modulu je opakující se varování: zeleně zářící testovací panel není důkazem kvality. Pokud vám testy dávají důvěru, musíte vědět, zda je tato důvěra skutečná nebo falešná. Ve věku umělé inteligence (AI) je tato otázka kritičtější než kdy jindy, protože umělá inteligence je zběhlá ve vytváření tekutých, hladce vypadajících, ale dutých testů. Falešná důvěra – věřit, že software je správný, protože testy jsou zelené, i když ve skutečnosti testy nic neověřují – je nejnebezpečnější věc, která se může týmu QA stát; protože neskrývá, že neexistují žádné chyby, ale že chyby nevidíte. Tato jednotka spojuje filozofii ověřování celého modulu do jedné disciplíny: testování vašich testů.
Zlatý standard pro měření kvality testování: testování mutací
Nejúčinnějším způsobem, jak pochopit, zda test skutečně chrání nebo ne, je testování mutací (testování mutací – technika, která vytváří záměrná malá zkreslení/mutace ve zdrojovém kódu a měří, zda testy tato zkreslení detekují). Logika je jednoduchá: pokud úmyslně rozbijete kód (z + uděláte -, z > z >=, z true na nepravdu), dobrá testovací sada by měla toto poškození zachytit a zčervenat. Pokud ne, je to narušení přežitým mutantem – takže vaše testy ve skutečnosti toto chování nezachovávají.
Skóre mutace = zabitá mutace / celková mutace. Balíček s 90% pokrytím linky může mít skóre mutace 40%; To znamená, že řádky fungují, ale chování není ověřeno. Skóre mutace je mnohem poctivějším měřítkem kvality než procentuální pokrytí.
Tip: Existují nástroje pro automatické mutace (PIT/Pitest pro Javu, Stryker pro JavaScript/TypeScript, Stryker.NET pro .NET, mutmut pro Python). Ty automaticky generují a testují stovky mutací. Pokud nástroj nemáte, je pro kritické funkce neocenitelná i ruční metoda „prolomit test kódu“.
Tři tváře pseudodůvěry a její protijed
Forma pseudodůvěry
symptom
protijed
Test bez tvrzení
Kód funguje, nic není ověřeno
Pravdivé tvrzení v každém testu; test s mutací
sebepotvrzující test
Očekávaný = výstup kódu
Vypočítejte očekávanou hodnotu nezávisle
Triviální tvrzení
"není null", "200 vráceno"
Ověřte obchodní pravidlo / skutečný výsledek
Chyba velkého rozsahu
90% vedení, nízká ochrana
Podívejte se na skóre mutací
Tolerance křehkého testu
"Zase zaseknutý, projít"
Hlavní příčina + deterministické testování
Používání umělé inteligence jako „červeného týmu“
Umělá inteligence může vytvářet pseudodůvěru a být mocným spojencem při jejím hledání. Použijte umělou inteligenci jako červený tým proti svým vlastním testům: zeptejte se „napište kód, který projde těmito testy, ale je špatný“ nebo „najděte podvrat, který tyto testy oklame“. Pokud AI ve vašich testech najde mezery, jsou tyto mezery skutečným rizikem.
Upozornění: Neptejte se AI "Je kvalita mého testu dobrá?" a odpověď „ano, skvělé“ berte jako ujištění. AI bývá laskavá. Místo toho vyzvěte AI ke konkrétnímu úkolu: „vyrobte chybu, která projde těmito testy“. Pokud to dokáže vyrobit, vaše testy jsou vůči této chybě slepé.
Ekvivalentní mutace a limity skóre
Testování mutací je mocné, ale má to háček: některé mutace vůbec nemění chování kódu. Tyto mutace se nazývají ekvivalentní mutace (ekvivalentní mutant — poškozený kód, mutace, která produkuje přesně stejný výsledek jako originál). Například změna počáteční hodnoty proměnné, která se nikdy nepoužívá, neovlivní výstup; Žádný test to nemůže a neměl by zachytit. Proto je 100% skóre mutace v praxi často nedosažitelné a není cílem. Ruční odstranění ekvivalentních mutací je náročné na práci; Nečtěte tedy skóre mutací jako absolutní výsledek zkoušky, ale jako poctivý ukazatel „opravdu mé testy chrání?“
Praktický přístup je tento: místo neustálého testování mutací napříč celou kódovou základnou je spouštějte na modulech, které obsahují nejrizikovější a nejsložitější obchodní pravidla. Prozkoumejte přežívající mutace v těchto modulech jednu po druhé; Pokud se jedná o skutečnou mezeru, přidejte test; pokud se jedná o ekvivalentní mutaci, označte ji zdůvodněním a vyhoďte. AI může provádět počáteční screening při hodnocení, zda je přežívající mutace ekvivalentní; ale konečné rozhodnutí uděláte vy, kdo víte, co kód dělá.
Upozornění: Testování mutací je výpočetně nákladné (všechny relevantní testy se pro každou mutaci opakují). Běžnou a rozumnou strategií je tedy naplánovat to jako týdenní nebo předběžnou hloubkovou kontrolu kritických modulů, spíše než každé sloučení.
Slabá výzva / Silná výzva
Slabý: "Jsou mé testy dostatečné?"
Strong: "Chovejte se jako červený tým pro tuto funkci a testovací sadu. (1) Vygenerujte 8 mutací v kódu, které lze zabít (záměna operátora, posun hranice, inverze podmínky, substituce návratové hodnoty). (2) U každé mutace označte, který z existujících testů ji zachytí a který NE. (3) Pro každou mutaci, která přežije, napište nový test, který prokáže všechny tyto testy, ale také prokáže, že je všechny tyto testy poruší. (4) obchodní pravidlo. Kód+testy: [vložit]"
Výkonná výzva; Staví umělou inteligenci jako zkoušejícího, který testuje, nikoli jako stroj na chválu.
Čtyři kopírovatelné šablony
1) Manuální kontrola mutace:
Vygenerujte 8 významných mutací (menších záměrných narušení) pro tento kód: substituce aritmetickým operátorem, limit porovnání (> vs >=), logická inverze, návrat/konstantní substituce, přeskočení podmínky. U každé mutace předpovězte, který z dostupných testů ji zachytí nebo ne. Kód+testy: [vložit]
2) Zabití přeživší mutace:
Následující zpráva o testu mutace obsahuje přežívající (nezachycené) mutace: [seznam/zpráva]. Pro každý napište minimální test, který tuto mutaci zabije (kód zčervená, když je takto porušen). Komentujte, jaké chování test potvrzuje.
3) Červený tým – krevní test:
Můžete napsat kód, který PROSPĚL VŠEMI následujícími testy, ale porušuje následující obchodní pravidlo: [obchodní pravidlo]. Pokud ano, jaká mezera v těchto testech to umožňuje? Přidejte test, který tuto mezeru uzavře. Testy: [vložit]
4) Kontrola kvality testu:
Zkontrolujte kvalitu této testovací sady. Zaškrtněte u každého testu:- Existuje pravdivé tvrzení nebo je to rekvizita?- Je očekávaná hodnota nezávislá, odvozená od kódu?- Ověřuje obchodní pravidlo nebo něco triviálního? Nakonec uveďte odhadované „skutečné skóre pro uplatnění“ a 3 nejslabší testy. Testy: [vložit]
tři mini pouzdra
Případ 1 — Pokrytí 92 %, skóre mutace 38 %. Jeden tým spoléhal na vysoké pokrytí. Při testování mutací pomocí Stryker bylo skóre 38 %: většina vytvořených mutací přežila. To byl důkaz, že testy nespouštěly linky a neověřovaly chování. Tým investoval tři týdny do testování kvality; Skóre mutací se zvýšilo na 81 % a tyto vylepšené testy v příštím vydání zachytily dvě skutečné chyby ve výpočtu.
Případ 2 – AI test oklamala. Pomocí šablony „červeného týmu“ odborník požádal AI o kód, který prošel existujícími testy, ale porušil pravidlo slevy. Umělá inteligence napsala kód, který vždy vrátil slevu nula – a všechny testy zůstaly zelené, protože žádné testy neověřovaly skutečnou hodnotu slevy. Viditelná mezera, přidána skutečná tvrzení.
Případ 3 – Past chvály. Mladší tester se zeptal AI: "Jsou moje testy dobré?" a s úlevou slyšel odpověď: "Velmi obsáhlá." Jeho starší kolega nechal stejné testy auditovat pomocí šablony „test kvality auditu“; Ukázalo se, že 12 z 20 testů bylo dekorováno (bez tvrzení nebo odpadu). Správná otázka přinesla správnou odpověď.
Časté chyby
- Záměna prostoru za kvalitu. Spoléhat se na vysoké pokrytí řádků a vůbec se nedívat na skóre mutace.
- Důvěřovat chvále AI. Dotaz "Jsou vaše testy dobré?" a kladnou odpověď považovat za ujištění.
- Odvození očekávané hodnoty z kódu. Samoověřovací testy, které potvrzují chybný kód.
- Spokojte se s triviálními tvrzeními. Kontroly, které neověřují skutečné pravidlo, například „není null“, „200 vráceno“.
- Ignorování přežívajících mutací. Ignorování toho, co nebylo zachyceno ve zprávě o mutaci.
- Ani se nesnažím ručně mutovat kritický kód. Pokud nástroj není k dispozici, přeskočte krok „rozbít kód a otestovat“.
V souhrnu
Pseudodůvěra je přesvědčení, že software je správný, protože testy jsou zelené; zatímco testy nemusí nic potvrdit. Zlatým standardem pro měření tohoto je testování mutací: záměrné prolomení kódu a měření, zda jej testy zachytí. Skóre mutace je mnohem poctivějším měřítkem kvality než procentuální pokrytí. Umělá inteligence vytváří pseudodůvěru a stává se mocným červeným týmem při jejím hledání – zeptejte se „vyrobte chybu, která projde těmito testy“. Otestujte své testy: pravdivé tvrzení, nezávislá očekávaná hodnota, ověření obchodních pravidel a zabité mutace.
Aplikační úkol
Importujte funkci obsahující obchodní pravidlo a jeho testy z vašeho vlastního projektu. Pokud je to možné, spusťte mutační nástroj (Stryker/Pitest/mutmut) a změřte skóre mutace; Pokud neexistuje žádný nástroj, vygenerujte alespoň 8 mutací pomocí šablony „manual mutation control“ a vyzkoušejte je ručně. Pro každou přežívající mutaci napište nový test pomocí šablony „zabít přežívající mutaci“. Nakonec se vzorem „červeného týmu“ zjistěte, zda AI dokáže vytvořit kód, který oklame vaše testy. Nahlaste své počáteční a konečné skóre mutace (nebo zachycenou/celkovou míru mutace).
kontrolní seznam
- [ ] Kvalitu testu jsem hodnotil podle skóre mutace, nikoli pokrytí.
- [ ] Provedl jsem testování mutací (buď pomocí nástroje nebo ručně) pro kritický kód.
- [ ] Napsal jsem nové testy pro každou přežívající mutaci.
- [ ] Použil jsem AI jako červený tým a hledal jsem mezery ve svých testech.
- [ ] Chválu AI „vaše testy jsou dobré“ jsem nebral jako ujištění.
- [ ] Zkontroloval jsem, že každý test ověřuje skutečné tvrzení, nezávislou očekávanou hodnotu a obchodní pravidlo.