Nyereség:
- Képes az olyan mutatók olvasására, mint a vonal-, ág- és állapotlefedettség térképként, nem pedig bizalom, és megérteni, hogy a magas lefedettség álbizalmat kelthet
- Képes a követelmény hatókörét a kód hatóköre mellé helyezni, és mesterséges intelligenciával láthatóvá tenni a nyomon követhetőségi hiányosságokat
- Képesség a jellemzők pontozására a kockázat = valószínűség × hatás képlettel, a korlátozott tesztelési erőfeszítés a legmagasabb kockázatra irányítani, és a szándékosan kívül eső esetek dokumentálása
Nem tesztelhet minden szoftvert örökké; Az idő és az erőforrások korlátozottak. Tehát az igazi kérdés az: hová helyezzük a korlátozott tesztelési erőfeszítést? Két fogalom válaszol erre a kérdésre. A tesztlefedettség – egy olyan mérőszám, amely azt méri, hogy a kód vagy a követelmények mennyi részét érintik a tesztek – a tesztelt tartalmat mutatja. A kockázat alapú tesztelés – a vizsgálati prioritás meghatározása a terület állapotromlásának valószínűsége és a romlása során okozott károk alapján – a legnagyobb kockázatra irányítja az erőfeszítést. A mesterséges intelligencia (AI) mindkettőben hatékony elemzési partner: láthatóvá teszi a lefedettség hiányosságait, kockázati területeket javasol. De a központi figyelmeztetés megmarad: az AI által látott hatótávolságok száma félrevezető lehet; A semmit sem igazoló tesztekkel akár 100%-os sorlefedettség is elérhető. Az Ön feladata, hogy a hatókört térképként olvassa, nem pedig bizalmat.
A lefedettségi mutatók helyes olvasása
Többféle hatókör létezik, és nem mindegyik egyformán értelmes:
- Vonalfedettség: Hány kódsort hajtottak végre legalább egyszer. A leggyakoribb, de leggyengébb kritérium; Csak azért, mert egy vonal működik, még nem bizonyíték arra, hogy megfelelően viselkedik.
- Ágak lefedettsége: Minden if-ágat (igaz és hamis) teszteltek-e. Értelmesebb, mint egy sor.
- Feltételek lefedettsége: Minden részfeltétel külön-külön tesztelése összetett körülmények között.
- Útvonal lefedettség: A kódon belüli logikai útvonalak kombinációi. Ez a legátfogóbb, de a gyakorlatban nehezen elérhető.
Figyelem: A lefedettségi százalék nem „minőségi pontszám”. A 100%-os sorlefedettség azt jelzi, hogy a sorok működnek; nem mintha a helyes eredményt adja (az álpassz az 1. egységben). Használja a hatókört a „hol nem néztem soha” kérdésre adott válaszként, ne pedig annak biztosítékaként, hogy „mindent teszteltek”.
Határozza meg a vakfoltokat
A lefedettségi mérőszámok csak azt mérik, hogy a kód mennyi részét hajtották végre; nem látja a következőket: (1) nem tesztelt követelmények (a kód létezik, de az üzleti szabály hibás), (2) hiányzó kód (nincs mozgástér a soha meg nem írt vezérlőhöz), (3) adat/állapot kombinációk, (4) használhatóság, teljesítmény, biztonság. Ezért a követelménylefedettséget (minden elfogadási kritériumnak legalább egy tesztnek meg kell felelnie) a kódlefedettség mellé kell helyezni. Az AI nagyon hasznos a követelmény-teszt leképezés (nyomkövetési mátrix) létrehozásában.
Kockázatalapú tesztelés: hová tegyük az erőfeszítést?
Kockázat = valószínűség (a törés valószínűsége) × behatás (törés esetén kár). Az AI segítségével ezen a két tengelyen pontozhat egy jellemzőlistát, és létrehozhat egy hőtérképet. Nagy valószínűség × magas tartományok (fizetés, hitelesítés, adatintegritás) érdemlik meg a legintenzívebb tesztelést; alacsony × alacsony területek (ritkán használt preferenciaképernyő) fényteszt elegendő.
területen
valószínűsége
Hatás
Kockázat
Tesztsűrűség
Fizetési folyamat
közepes
nagyon magas
magas
Mély + automatizálás
hitelesítés
közepes
nagyon magas
magas
Mély + biztonság
Termékkeresés
magas
közepes
Közepes-magas
Automatizálás + felfedezés
Profilfotó
alacsony
alacsony
alacsony
fényvezérlés
Súgó oldal
alacsony
túl alacsony
túl alacsony
felülvizsgálatát
Az üldözés csapdája
A lefedettségi százalék célként való kitűzése (például a „csapatnak 90%-os lefedettséget kell teljesítenie” szabály) veszélyes mellékhatással jár: a fejlesztők és a tesztelők a százalék növelésére összpontosítanak, nem pedig a tényleges kockázat kezelésére. Az eredmény gyakran egy felduzzadt távcső állítások vagy triviális tesztek nélkül – a szám szépnek tűnik, de nincs védelem. Ez az a jelenség, amikor a kritérium megsérül, amikor maga válik céllá: "amikor egy intézkedésből cél lesz, megszűnik jó mérték lenni." Használja a hatókört diagnosztikai eszközként, ne teljesítményjelentés kártyaként.
Egészségesebb megközelítés, ha a hatókört irányítottan olvassuk: "Miért ragadt meg a fióklefedettség 40%-on a kritikus fizetési modulban?" A kérdés az, hogy "a teljes lefedettség 90%-os?" Sokkal értékesebb, mint a kérdés. A mesterséges intelligencia modulonként és kockázati szintenként bontsa le a hatóköri jelentést; Emelje ki a magas kockázatú területeket alacsony lefedettséggel. Így a hatókör inkább iránytűvé válik, amely irányítja a munkát, nem pedig egy vak százalékot.
Vigyázat: A „100%-os lefedettség” szlogen csapda. Egyes kódok tesztelése (egyszerű kiegészítők, automatikusan generált alkatrészek) alacsony értékű; az ott elköltött erőfeszítést ellopják a magas kockázatú üzleti szabályoktól. A cél minden fontos viselkedés és kockázat tesztelése, nem minden sor.
Gyenge felszólítás / Erős felszólítás
Gyenge: „Növelje a tesztelési lefedettséget.”
Erős: "Tekintettel az elfogadási kritériumok ezen listájára és ezekre a meglévő tesztesetekre. (1) Táblázza meg, hogy mely elfogadási kritériumok nem feleltek meg egyetlen tesztnek sem (követelménylefedettségi rés). (2) Pontozzon minden jellemzőt 1-től 5-ig a valószínűségi és hatástengelyeken; rangsorolás kockázat szerint = valószínűség × hatás. (3) Korlátozott időmben javasolja, melyik kezdő 5-öt zárja be a legnagyobb kockázatot, mivel ne vegyem be a kód lefedettségét. kritérium az üzleti kockázat prioritása: [...] Tesztek: [...]"
Erőteljes felszólítás; ötvözi a hatókört az üzleti kockázattal, és előnyben részesíti a korlátozott munkaerőt.
Négy másolható sablon
1) Követelmények hatóköre:
Adott a következő elfogadási kritériumok és ezek a tesztesetek. Készítsen nyomon követhetőségi táblázatot: minden kritérium -> teszt(ek), amelyek megfelelnek ennek. Azokat a kritériumokat, amelyeknek nincs tesztje, "FEDETÉSI HIÁNY"-nak, azokat a teszteket pedig, amelyek semmilyen kritériumhoz nem kapcsolódnak, "SZÜKSÉGES?" Jelölés: Kritériumok: [...] / Tesztek: [...]
2) Kockázati pontozás:
A jellemzők/modulok listáját 1-5 pontozással értékelje a valószínűség (törés valószínűsége) és az ütközés (sérülés, ha eltörik) tengelyei alapján. Kockázat = valószínűség × hatás. Rendezzen egy táblázatot, és adja meg az ajánlott tesztelési típust (egység/API/UI/felderítés/biztonság) minden egyes magas kockázatú területhez. Lista: [...]
3) A hatály értelmezése:
A következő lefedettségi jelentés készült (sor %, ág %). Mondja el nekem ezt:- Mit NEM bizonyítanak ezek a számok?- Melyek azok a területek, amelyek veszélyben lehetnek a magas sorlefedettség ellenére?- Milyen további vizsgálatokat javasolna olyan hiányosságok esetén, amelyeket a lefedettség nem lát (követelmény, adatkombináció, biztonság)?Jelentés: [beillesztés]
4) Korlátozott időterv:
[X óra] van hátra az adásig. A következő kockázati rangsort és fedezeti réseket adjuk meg. Ebben az időszakban prioritási sorrendben készül el a maximális kockázatot csökkentő tesztterv. Világosan fogalmazza meg, hogy mit NE teszteljen tudatosan, és ennek vállalt kockázatát. Adatok: [...]
három mini tok
1. eset – 100%-os lefedettség, nulla bizalom. Az egyik csapat 94%-os vonallefedettséggel büszkélkedhetett. A "hatókör értelmezése" elemzése azt mutatta, hogy a legtöbb teszt állítás nélküli volt, azaz sorokat futtattak, de nem ellenőriztek semmit. A tényleges védelem sokkal alacsonyabb volt. A csapat nem a számokra, hanem a mutációk tesztelésére összpontosított (10. egység); a tényleges hibafogási arány megduplázódott.
2. eset – A kockázati térképen korrigált prioritás. Az egyik csapat tesztelési erőfeszítéseinek 40%-át egy ritkán használt jelentéskészítési képernyőn költötte, és kihagyta a fizetési folyamatot, mert „csak működik”. Az AI kockázati pontozása ezt az egyensúlyhiányt mutatta. A munkaerőt újra elosztották; Két héttel később nagy hatást kiváltó hibát találtak a fizetési folyamatban, amelyet az éles előtt lezártak.
3. eset – Tudatosan kívül esik a hatókörön. 4 órával a megjelenés után a csapat eldöntötte, hogy mit teszteljen és mit hagyjon ki tudatosan a „korlátozott ütemterv” sablon segítségével. Két nagy kockázatú patakot teszteltek mélyen; az alacsony kockázatú preferencia képernyőt „elfogadott kockázatként” dokumentálták, és kihagyták. A döntés átlátható és indokolt volt; A verzió épségben kijött.
Gyakori hibák
- A lefedettség százalékos tévedése a minőséggel. A nagy sorok lefedettségének olvasása „tesztelt” biztosítékként.
- Csak nézzük a kód lefedettségét. A követelmények lefedettségének kihagyása (az egyes elfogadási kritériumok tesztelése).
- Tesztelés ugyanúgy kockázat figyelembe vétele nélkül. Munkaerő beosztása alacsony kockázatú területekre és a kritikus áramlások figyelmen kívül hagyása.
- Elrejtőzés a hatókörön kívül. Nem dokumentálni azt, amit nem teszteltek, amikor nem volt elég idő; Meglepetések a megjelenés után.
- Az AI kockázati pontszámának kérdés nélküli elfogadása. A mesterséges intelligencia nem ismeri teljesen a termékkörnyezetet; Állítsa be a pontszámokat szakértő szemmel.
Összefoglalva
A tesztlefedettség és a kockázatalapú tesztelés két eszköz a korlátozott erőfeszítések megfelelő helyre történő irányítására. A lefedettségi mutatók (vonal, elágazás, állapot, útvonal) megmutatják, hogy mit érintettek, de nem igazolják, hogy helyesen viselkedett; A hatókör egy térkép, a bizalom nem. Tegye a követelmények lefedettségét a kódlefedettség mellé. Pontozd a jellemzőket a kockázat = valószínűség × hatás képlettel, és irányítsd az erőfeszítést a legnagyobb kockázatra. Az AI láthatóvá teszi a hiányosságokat, felméri a kockázatokat, korlátozott ideig tervez; de a végső prioritás és a „tudatos opt-out” döntés az üzleti kontextust ismerő szakértőé.
Pályázati feladat
Válasszon egy modult a saját projektjéből. Futtassa a „requirements range gap” sablont az AI-val, és derítse ki, mely elfogadási feltételek nincsenek tesztelve. Ezután rangsorolja a modul résztulajdonságait a valószínűség × ütközési tengelyeken a „kockázati pontozással”. Ossza el a (hipotetikus) 3 órás tesztelési időt a "korlátozott ütemterv" szerint; Írja le, hogy mit nem fog tudatosan tesztelni, és az elfogadott kockázatot. Adjon hozzá egy konkrét tesztet, amely megszünteti a legmagasabb kockázatú lefedettségi rést.
ellenőrző lista
- [ ] A lefedettségi százalékot térképnek olvasom, nem minőséget.
- [ ] A kódlefedettség mellett a követelménylefedettséget is megszüntettem.
- [ ] A jellemzőket valószínűség × hatás alapján pontoztam és kockázat szerint rangsoroltam.
- [ ] A tesztelést a legmagasabb kockázatra irányítottam át.
- [ ] Dokumentáltam a tudatosan nem tesztelt területeket és elismertem a kockázatot.
- [ ] Áttekintettem az AI kockázati pontszámait a termékkörnyezetem alapján.