zisky:
- Schopnosť čítať metriky, ako je pokrytie linky, pobočky a stavu, ako mapu, nie ako dôveryhodnosť, a pochopiť, že vysoké pokrytie môže poskytnúť pseudodôveru
- Schopnosť umiestniť rozsah požiadaviek vedľa rozsahu kódu a zviditeľniť medzery v sledovateľnosti pomocou umelej inteligencie
- Schopnosť hodnotiť prvky pomocou vzorca riziko = pravdepodobnosť × vplyv, nasmerovať obmedzené testovacie úsilie na najvyššie riziko a zámerné zdokumentovanie mimo rozsah
Nemôžete testovať každý softvér navždy; Čas a zdroje sú obmedzené. Skutočná otázka teda znie: kam umiestniť obmedzené úsilie pri testovaní? Na túto otázku odpovedajú dva pojmy. Testovacie pokrytie – metrika, ktorá meria, koľko kódu alebo požiadaviek sa dotknú testami – predstavuje to, čo sa testuje. Testovanie založené na riziku – prístup určovania priority testu podľa pravdepodobnosti zhoršenia oblasti a škôd, ktoré spôsobí, keď sa zhorší – smeruje úsilie k najväčšiemu riziku. Umelá inteligencia (AI) je silným partnerom pri analýze v oboch: zviditeľňuje medzery v pokrytí, naznačuje rizikové oblasti. Hlavná výhrada však zostáva: počet rozsahov, ktoré AI vidí, môže byť zavádzajúci; Dokonca 100% pokrytie riadkov je možné dosiahnuť testami, ktoré nič neoveria. Vašou úlohou je čítať rozsah ako mapu, nie dôveru.
Správne čítanie metrík pokrytia
Existuje niekoľko typov rozsahu a nie všetky sú rovnako zmysluplné:
- Pokrytie riadkov: Koľko riadkov kódu bolo vykonaných aspoň raz. Najbežnejšie, ale najslabšie kritérium; To, že linka funguje, nie je dôkazom, že sa správa správne.
- Pokrytie vetvy: Či bola testovaná každá vetva if (pravda aj nepravda). Zmysluplnejšie ako riadok.
- Pokrytie podmienok: Testovanie každej čiastkovej podmienky v zložitých podmienkach samostatne.
- Pokrytie cesty: Kombinácie logických ciest v rámci kódu. Je najkomplexnejšia, no v praxi ťažko dosiahnuteľná.
Upozornenie: Percento pokrytia nie je „skóre kvality“. 100% pokrytie riadkov vám povie, že riadky fungujú; nie, že produkuje správny výsledok (pseudo-priechod v jednotke 1). Použite rozsah ako odpoveď na otázku „kam som sa nikdy nepozeral“, nie ako uistenie, že „všetko bolo odskúšané“.
Rozsah slepých miest
Metriky pokrytia merajú iba to, aká časť kódu bola vykonaná; nevidí: (1) netestované požiadavky (kód existuje, ale obchodné pravidlo je nesprávne), (2) chýbajúci kód (žiadny priestor na kontrolu, ktorá nebola nikdy napísaná), (3) kombinácie údajov a stavu, (4) použiteľnosť, výkon, bezpečnosť. Pokrytie požiadaviek (každé akceptačné kritérium musí byť splnené aspoň jedným testom) by preto malo byť umiestnené vedľa pokrytia kódom. AI je veľmi nápomocná pri vytváraní mapovania požiadaviek a testov (matice sledovateľnosti).
Testovanie založené na riziku: kam vynakladáme úsilie?
Riziko = pravdepodobnosť (pravdepodobnosť rozbitia) × dopad (poškodenie pri rozbití). S AI môžete získať zoznam funkcií na týchto dvoch osiach a vytvoriť tepelnú mapu. Vysoká pravdepodobnosť × vysoké domény (platba, autentifikácia, integrita údajov) si zaslúžia najintenzívnejšie testovanie; nízke × nízke oblasti (zriedka používaná preferenčná obrazovka) testovanie svetla je dostatočné.
oblasť
pravdepodobnosť
Vplyv
Riziko
Testovacia hustota
Platobný tok
stredná
veľmi vysoká
vysoká
Hlboká + automatizácia
autentifikácia
stredná
veľmi vysoká
vysoká
Hlboké + bezpečnosť
Vyhľadávanie produktov
vysoká
stredná
Stredne vysoké
Automatizácia + objavovanie
Profilová fotka
nízka
nízka
nízka
ovládanie svetla
Stránka pomocníka
nízka
príliš nízka
príliš nízka
recenzia
Pasca prenasledovania rozsahu
Stanovenie percenta pokrytia za cieľ (napr. pravidlo „tím musí prejsť na 90 % pokrytie“) má nebezpečný vedľajší účinok: vývojári a testeri sa zameriavajú na zvýšenie percenta, a nie na riešenie skutočného rizika. Výsledkom je často nafúknutý rozsah bez tvrdení alebo triviálnych testov - číslo vyzerá pekne, ale neexistuje žiadna ochrana. Toto je jav, keď sa kritérium pokazí, keď sa samo stane cieľom: „keď sa opatrenie stane cieľom, prestane byť dobrým opatrením“. Použite rozsah ako diagnostický nástroj, nie ako prehľad výkonnosti.
Zdravším prístupom je čítať rozsah priamo: "Prečo je pokrytie pobočky uviaznuté na 40% v module kritických platieb?" Otázka znie "je celkové pokrytie 90%?" Je to oveľa cennejšie ako otázka. Nechajte AI rozčleniť správu o rozsahu podľa modulu a úrovne rizika; Zvýraznite vysoko rizikové oblasti s nízkym pokrytím. Rozsah sa tak stáva kompasom, ktorý riadi prácu, a nie slepé percento.
Pozor: Slogan „100% pokrytie“ je pasca. Testovanie nejakého kódu (jednoduché prístupové prvky, automaticky generované časti) má nízku hodnotu; vynaložené úsilie je ukradnuté vysoko rizikovým obchodným pravidlám. Cieľom je otestovať každé dôležité správanie a riziko, nie každý riadok.
Slabá výzva / Silná výzva
Slabé: „Zvýšiť pokrytie testovaním.“
Strong: "Vzhľadom na tento zoznam akceptačných kritérií a tieto existujúce testovacie prípady. (1) Tabuľka, ktoré akceptačné kritériá neboli splnené žiadnymi testami (medzera pokrytia požiadaviek). (2) Ohodnoťte každú funkciu 1-5 na osi pravdepodobnosti a vplyvu; zoradenie podľa rizika = pravdepodobnosť × vplyv. (3) Počas môjho obmedzeného času navrhnite, ktorých 5 medzier by som mal uzavrieť ako prvý, začnite s najvyšším rizikom pre obchodnú líniu. Kritéria neberte ako jediné; [...] Testy: [...]"
Výkonná výzva; kombinuje rozsah s podnikateľským rizikom a uprednostňuje obmedzenú prácu.
Štyri kopírovateľné šablóny
1) Medzera v rozsahu požiadavky:
Vzhľadom na nasledujúce kritériá prijatia a tieto testovacie prípady. Vytvorte tabuľku sledovateľnosti: každé kritérium -> test(y), ktoré ho spĺňajú. Kritériá, ktoré neobsahujú žiadne testy, sa nazývajú "POKRYTIE GAP" a testy, ktoré sa nepripájajú k žiadnym kritériám, sa nazývajú "POTREBNÉ?" Známka: Kritériá: [...] / Testy: [...]
2) Hodnotenie rizika:
Ohodnoťte tento zoznam funkcií/modulov 1-5 na osi pravdepodobnosti (pravdepodobnosť zlomenia) a nárazu (poškodenie, ak sa zlomí). Riziko = pravdepodobnosť × dopad. Zoraďte v tabuľke a špecifikujte odporúčaný typ testovania (jednotka/API/UI/prieskum/zabezpečenie) pre každú oblasť s vysokým rizikom. Zoznam: [...]
3) Výklad rozsahu:
Bola uvedená nasledujúca správa o pokrytí (riadok %, pobočka %). Povedzte mi toto:- Čo tieto čísla NEDOkazujú?- Aké oblasti môžu byť ohrozené napriek vysokému pokrytiu riadkov?- Aké dodatočné testovanie by ste odporučili pre medzery, ktoré pokrytie nevidí (požiadavka, kombinácia údajov, bezpečnosť)? Správa: [prilepiť]
4) Časovo obmedzený plán:
Do vysielania zostáva [X hodín]. Uvádza sa nasledujúce hodnotenie rizika a medzery v pokrytí. Počas tohto obdobia sa v poradí podľa priority pripraví plán testov, ktorý zníži maximálne riziko. Jasne uveďte, čo vedome NEtestovať a akceptované riziko, že tak urobíte. Údaje: [...]
tri mini prípady
Prípad 1 – 100 % pokrytie, nulová dôvera. Jeden tím sa mohol pochváliť 94% pokrytím linky. Analýza "interpretácie rozsahu" ukázala, že väčšina testov bola bez tvrdenia, čo znamená, že prebiehali riadky, ale nič neoverili. Skutočné ochranné pokrytie bolo oveľa nižšie. Tím sa nezameral na čísla, ale na testovanie mutácií (jednotka 10); skutočná miera zachytenia chýb sa zdvojnásobila.
Prípad 2 – Opravená priorita mapy rizika. Jeden tím vynaložil 40 % svojho testovacieho úsilia na zriedkavo používanú obrazovku prehľadov, pričom vynechal tok platieb, pretože to „jednoducho funguje“. Skóre rizika AI ukázalo túto nerovnováhu. Práca bola prerozdelená; O dva týždne neskôr bola v platobnom toku zistená chyba s vysokým dopadom a bola uzavretá pred spustením.
Prípad 3 – Vedomie mimo rozsah. 4 hodiny po vydaní sa tím rozhodol, čo otestovať a čo vedome preskočiť pomocou šablóny „obmedzený rozvrh“. Dva vysoko rizikové toky boli testované hlboko; obrazovka preferencií s nízkym rizikom bola zdokumentovaná ako „akceptované riziko“ a preskočená. Rozhodnutie bolo transparentné a odôvodnené; Verzia vyšla bezpečne.
Časté chyby
- Chybné percento pokrytia za kvalitu. Čítanie vysokého pokrytia riadkov ako "testované" uistenie.
- Stačí sa pozrieť na pokrytie kódu. Pokrytie požiadaviek na preskočenie (testovanie každého kritéria prijatia).
- Testovanie rovnako bez zohľadnenia rizika. Prideľovanie pracovnej sily do oblastí s nízkym rizikom a zanedbávanie kritických tokov.
- Skrytie mimo rozsah. Nedokumentovanie toho, čo nebolo testované, keď nebol dostatok času; Prekvapenia po vydaní.
- Prijímanie rizikového skóre AI bez akýchkoľvek otázok. AI úplne nepozná kontext produktu; Upravte skóre odborným okom.
V súhrne
Pokrytie testov a testovanie založené na rizikách sú dva nástroje na nasmerovanie obmedzeného úsilia na správne miesto. Metriky pokrytia (čiara, vetva, stav, cesta) ukazujú, čoho sa dotkli, ale nedokazujú, že sa správali správne; Rozsah je mapa, dôvera nie. Pokrytie požiadaviek umiestnite vedľa pokrytia kódu. Ohodnoťte vlastnosti pomocou vzorca riziko = pravdepodobnosť × vplyv a nasmerujte úsilie na najväčšie riziko. AI zviditeľňuje medzery, boduje riziko, plánuje na obmedzený čas; ale konečná priorita a rozhodnutie o „vedomom odstúpení“ je na odborníkovi, ktorý pozná obchodný kontext.
Aplikačná úloha
Vyberte si modul z vlastného projektu. Spustite šablónu „medzera rozsahu požiadaviek“ s AI a zistite, ktoré kritériá prijatia nie sú testované. Potom zoraďte čiastkové vlastnosti modulu na osi pravdepodobnosti × dopad pomocou „bodovania rizika“. Rozdeľte (hypotetické) 3 hodiny testovacieho času, ktorý máte s „obmedzeným rozvrhom“; Zapíšte si, čo vedome nebudete testovať a akceptované riziko. Pridajte konkrétny test, ktorý odstráni medzeru v pokrytí s najvyšším rizikom, ktorú nájdete.
kontrolný zoznam
- [ ] Percento pokrytia vnímam ako mapu, nie kvalitu.
- [ ] Okrem pokrytia kódom som odstránil aj pokrytie požiadaviek.
- [ ] Prvky som ohodnotil podľa pravdepodobnosti × vplyvu a zoradil som ich podľa rizika.
- [ ] Testovacie úsilie som presmeroval na najvyššie riziko.
- [ ] Zdokumentoval som oblasti, ktoré neboli vedome testované a uznal som riziko.
- [ ] Skontroloval som skóre rizika AI na základe kontextu môjho produktu.