Roncsolásmentes szoftvertesztelés (NDT): Mi a tesztelési stratégia?
Thomas Hamilton
⚡ Okos összefoglaló
A roncsolásmentes tesztelés azt ellenőrzi, hogy egy alkalmazás helyesen viselkedik-e, amikor érvényes bemenetet kap, ezért a tesztelők pozitív vagy boldogút tesztelésnek is nevezik. A tesztelés a várt eredményeket a dokumentált követelményekhez viszonyítja.
Mi az a roncsolásmentes szoftvertesztelés?
Roncsolásmentes vizsgálat egy szoftvertesztelési típus, amely magában foglalja a szoftveralkalmazás tesztelését és a megfelelő interakciót. Más szavakkal, a roncsolásmentes szoftvertesztelést (NDT) pozitív tesztelésnek vagy boldog út tesztelésének is nevezhetjük. A várt eredményeket adja, és bizonyítja, hogy a szoftveralkalmazás a várt módon működik.
A név a mérnöki tudományokból származik, ahol a roncsolásmentes vizsgálat egy fizikai alkatrészt vizsgál anélkül, hogy károsítaná azt. A szoftverekben ugyanez az elképzelés érvényesül: az alkalmazást úgy futtatják, ahogyan arra tervezték, és az sértetlenül túléli a tesztet.
Példa: A helyes adatok megadása a bejelentkezési modulban, majd annak ellenőrzése, hogy elfogadja-e a hitelesítő adatokat, és átkerül-e a következő oldalra.
Az alábbi képernyőképen látható a bejelentkezési űrlap, érvényes értékkel a felhasználónév mezőben, mielőtt a teszt végrehajtásra kerülne.
A fenti példán roncsolásmentes tesztelés végrehajtásához adjon meg egy érvényes felhasználónevet és jelszót a bejelentkezési űrlapon. Mivel a bemeneti adatok megegyeznek a követelmény által megengedettekkel, a kívánt eredmény pozitív, és a tesztelő egyszerűen megerősíti, hogy az alkalmazás a következő oldalra lép.
Miért végezzük a roncsolásmentes szoftvertesztet (NDT)?
A roncsolásmentes tesztelés megválaszolja az első kérdést, amelyet minden érdekelt fél feltesz egy builddel kapcsolatban: vajon a funkció valóban azt teszi-e, amire kérték? Ezek az okok, amiért a csapatok lefuttatják.
- Az NDT módszer fő előnye, hogy javítja a szoftverminőséget, mivel a fő folyamatban talált hibákat korábban kijavítják.
- Annak bemutatására, hogy a szoftverfunkciók a specifikációnak megfelelően működnek.
- Annak ellenőrzésére, hogy teljesültek-e a teljesítménykövetelmények.
- Annak ellenőrzése érdekében, hogy a végfelhasználók igényei teljesülnek-e.
- Annak ellenőrzése, hogy egy kis kódrészlet vagy funkció a várt módon működik-e, és nem szakítja-e meg a kapcsolódó funkciókat.
- Olyan bizonyítékot szolgáltatni, amely egy adott időpontban bemutatható felhasználói elfogadási tesztelés jóváhagyás, ahol az ügyfél a meghibásodási módok helyett a tervezett viselkedést szeretné látni.
Mikor végeznek roncsolásmentes vizsgálatot (NDT)?
Az időzítés itt jobban számít, mint a legtöbb technikánál, mert a boldog út mindent a későbbiekben irányít.
- Ez az első tesztelési forma, amelyet egy tesztelő egy alkalmazáson végez, azaz a tesztelés kezdeti szakaszában. SDLC.
- A roncsolásmentes vizsgálatot általában akkor végzik, ha nincs elég idő egy teljes vizsgálati ciklusra, mivel ez még mindig bizonyítja az elfogadási kritériumok teljesülését.
- Negatív és destruktív forgatókönyvek előtt fut le. Ha a fő folyamat megszakad, a hibakezelési tesztek zajt jeleznek valódi hibák helyett.
- Minden hibajavítás után megismétlődik, ahol átfedésben van a következővel: regressziós teszt.
Tesztstratégia roncsolásmentes teszteléshez
A roncsolásmentes vizsgálat stratégiája szándékosan egyszerű, a lényege pedig a pozitív hozzáállás, nem pedig a szerszámok használata.
- A roncsolásmentes vizsgálathoz pozitív megközelítést kell alkalmazni.
- Az NDT technika célja annak bizonyítása, hogy egy alkalmazás érvényes bemeneti adatok esetén működik.
- A roncsolásmentes vizsgálat elvégzéséhez nincs szükség különleges követelményekre vagy környezeti feltételekre.
- A roncsolásmentes vizsgálat legjobb gyakorlata annak ellenőrzése, hogy a rendszer azt teszi-e, amit kell.
Az alábbi ábra összefoglalja, hogyan szerveződik ez a stratégia általában egy tesztciklus során.
Hogyan írjunk roncsolásmentes (pozitív) teszteseteket?
Egy roncsolásmentes teszteset csak akkor hasznos, ha a bemenete bizonyíthatóan érvényes, és a várt eredménye egy követelményből, nem pedig a tesztelő feltételezéséből származik. A következő lépések ezt a fajta eredményt hozzák létre: próbaper.
1. lépés) Válasszon ki egy elfogadási kritériumot. Olvasd el a követelményt, és fogalmazd meg újra egyetlen ellenőrizhető állításként, például: „a felhasználónév mező hattól húszig terjedő alfanumerikus karaktert fogad el”.
2. lépés) Válasszon érvényes bemeneti adatokat. Olyan értékeket válasszon, amelyek kényelmesen a megengedett tartományon belül vannak. Egyenértékű particionálás itt segít — érvényes partíciónként általában elegendő egy reprezentatív érték.
3. lépés) Írd le a várható eredményt a végrehajtás előtt. A várt eredményt a specifikációból kell kiírni. Ha a futtatás után írjuk meg, a teszt a build által végrehajtott műveletek leírásává válik.
4. lépés) Tartsa a lépéseket a felhasználói sorrendben. A sorrendnek meg kell egyeznie azzal, ahogyan egy valódi felhasználó elvégezné a feladatot, mivel a technika lényege a tervezett útvonal megerősítése.
5. lépés) Rögzítse a követelmény azonosítóját. TracAz eset kritériumhoz való visszavezetése teszi lehetővé a csapat számára a lefedettség bizonyítását a felülvizsgálat során.
A bejelentkezési modul egy működőképes példája így néz ki.
| Mező | Roncsolásmentes teszteset |
|---|---|
| Követelmény | A felhasználónév 6–20 alfanumerikus karaktert fogad el |
| Teszt adat | Felhasználónév guru99tester, érvényes, egyező jelszó |
| Lépései | Nyissa meg a bejelentkezési oldalt, adja meg a hitelesítő adatokat, majd válassza a Bejelentkezés lehetőséget. |
| Várható eredmény | A hitelesítő adatok elfogadva, és megjelenik a kezdőlap. |
| típus | Pozitív / boldog út |
Figyeljük meg, hogy az eset mezőben semmi sem próbálja meg áttörni a mezőt. Egy olyan eset, amely öt karaktert ír be a hibaüzenet megjelenítéséhez, egy negatív teszt, nem egy roncsolásmentes.
Példák roncsolásmentes vizsgálatra
Az alábbi példa bemutatja, hogyan viselkedik a roncsolásmentes tesztelés egy többmodulos alkalmazásban egy hiba kijavítása után.
- Egy alkalmazás öt modulból áll: bejelentkezési oldal, kezdőlap, felhasználói adatlap, új felhasználó létrehozása és feladat létrehozása.
- Tegyük fel, hogy hiba van a bejelentkezési oldalon: a felhasználónév mező kevesebb, mint hat alfanumerikus karaktert fogad el. Ez ellentétes a beállított követelménnyel, amely kimondja, hogy a felhasználónév nem fogadhat el kevesebb, mint hat karaktert, így a viselkedés hibás.
- A hibát a szokásos módon jelentik a fejlesztőcsapatnak. hibakezelési folyamat, kijavítják, és a buildet visszaküldik a tesztelőcsapatnak.
- A tesztelőcsapat nemcsak a bejelentkezési oldalt ellenőrzi, ahol a hibát kijavították, hanem a többi modult is teszteli. Az összes érvényes adatokkal rendelkező modul tesztelése során roncsolásmentes tesztelést végez, egyszerűen annak megerősítésére, hogy a teljes alkalmazás továbbra is megfelelően működik.
Roncsolásmentes vizsgálat vs. roncsolásos vizsgálat
A két technikát gyakran együtt tanítják, mivel ugyanazon építménnyel kapcsolatos ellentétes kérdésekre adnak választ. Romboló tesztelés azt a pontot keresi, ahol a szoftver feladja, míg a roncsolásmentes tesztelés megerősíti, hogy a kívánt viselkedés fennáll.
| Aspect | Roncsolásmentes vizsgálat | Pusztító tesztelés |
|---|---|---|
| Szándék | Használja helyesen az alkalmazást, és ellenőrizze a pozitív eredményeket | Szokatlan vagy érvénytelen bemenetet adjon meg a hibapont megtalálásához |
| Beviteli adat | A követelményből származó érvényes adatok | Érvénytelen, sérült vagy sorrenden kívüli adatok |
| Szükséges követelmények | Igen – az eseteket az elfogadási kritériumok alapján írják | Nem feltétlenül; a tesztelők a felhasználói történetek elfogultsága nélkül dolgoznak. |
| Amit leleplez | Funkcionális gyengeségek a specifikációhoz képest | Gyengeségek a tervezésben, a megbízhatóságban és a helyreállíthatóságban |
| Kapcsolódó technikák | Füstvizsgálat, funkcionális tesztelés | Majomtesztelés, feltáró tesztelés |
A kettő inkább kiegészíti, mintsem alternatíva. A roncsolásmentes tesztelés önmagában ellenőrizetlenül hagyja a hibakezelést, és a roncsolásos tesztelés önmagában soha nem bizonyítja, hogy a termék elvégzi a dolgát.
A roncsolásmentes szoftvertesztelés előnyei és korlátai
Ugyanolyan fontos tudni, hogy egy technika hol válik használhatatlanná, mint tudni, hogy mit fed le.
Előnyök
- Gyorsan tervezhető és kivitelezhető, mivel a tesztadatok közvetlenül a specifikációból származnak.
- Nincs szükség speciális környezetre, hibainjektálásra vagy sérült adatkészletre.
- Olyan bizonyítékokat állít elő, amelyek egy az egyhez megfelelnek a követelményeknek, ami megfelel az auditoknak és az engedélyezéseknek.
- Ugyanolyan jól működik, mint kézi tesztelés és ahogy meg van írva automatizálási tesztelés, így ugyanazok az esetek újra felhasználhatók egy regressziós csomagban.
- Korai, őszinte jelzést ad az épület állapotáról bármely szinten, az egységtől a teljes szintig integrációs tesztelés nak nek rendszertesztelés.
korlátozások
- A teljes átmenő hiba semmit sem mond arról, hogyan viselkedik az alkalmazás érvénytelen bemenettel, így a súlyos hibakezelési hibák túlélhetik.
- A lefedettséget a követelmények minősége korlátozza. A meghatározatlan dolgokat soha nem teszteljük.
- Hamis önbizalmat kelthet, ha a boldog út az egyetlen járt út egy kiadás előtt.
- Nem méri a robusztusságot, a regenerálódást vagy a stressz alatti teljesítményt, amelyekhez saját technikákra van szükség a szélesebb körű módszerek közül. szoftvertesztelési típusok.
A roncsolásmentes vizsgálatot minden más technika alapjául szolgáló alapként kell kezelni, és a tágabb vizsgálati folyamatba kell beilleszteni. szoftvertesztelés életciklusa nem pedig egyszeri tevékenységként.
