Teszt szintek s teszt tpusok Cserpk Balzs Fordtotta
Teszt szintek és teszt típusok Cserpák Balázs Fordította: Krizsán Evelin ni. com
Teszt szintek ni. com
Teszt Fázisok vagy szintek § § A szoftver tesztelési szintek, különböző állomások a szoftver fejlesztés életciklusában, ahol a tesztet végzik. Amiről beszélni fogunk § § Tipikus tesztelési célok az egyes szintekben Teszt bázisok az egyes szintekben Eszközök, az egyes szintek környezete Tesztelők az egyes szintekben
Component (Unit) Test - „Alkotóelem” teszt § § § Cél: Bugok megtalálása, a bizalom kiépítése és a kockázat csökkentése a vizsgált rendszer egyes részeiben a rendszerintegráció előtt. Item Under Test (IUT) – vizsgált elemek: függvények, osztályok, vagy nagyobb elemek Bázisok: Kód, technikai követelmények Környezet, eszközök: Fejlesztőkörnyezet, driverek és stubok Felelős: Gyakran programozók, de a jártasság és a végrehajtás mértéke eltérő
Unit/Component Teszt Folyamata § § Gyakran, a bugokat a felfedezés után bármilyen jelentés nélkül javítják, ami csökkenti a fejlesztési folyamat átláthatóságát a minőség szempontjából Test-driven development – Teszt vezérelt fejlesztés (tesztelés, utána fejlesztés) § § § Fejlesztés unit tesztek halmaza Kód készítése és integrálása Teszt futtatása és debuggolása amíg a teszt sikeres nem lesz
Driverek és Stubok § § Az unit, component, és integrációs tesztelés során, gyakran szükséges a hívásáramlás (call flow) részeinek szimulálása, amelyek elérhetőek a tesztelt modul(ok)ról Adatbeállítás néha szükséges Driver: függvény(ek), amely(ek) a tesztelt modulokat hívják meg Stub: függvény(ek) amelyeket – közvetetten vagy közvetlenül– meghívnak a tesztelt modul(ok)
Integraciós Teszt § § § Cél: Bugok megtalálása, a bizalom kiépítése és a kockázat csökkentése a kapcsolatokban és interfészekben az alkotóelem párok, vagy csoportok között a tesztelt rendszerben, amint a darabok összejönnek Vizsgált elemek: 2 vagy több integrált alkotóelem Bázisok: belső szerkezet, technikai követelmények, adatáramlások Környezet, eszközök: Fejlesztőkörnyezet, Tesztkörnyezet, driverek és stubok Felelős: Ideális esetben tesztelők és programozók
Integrációs Technikák I. § Big bang § § Vegyük az összes modult, állítsuk össze és teszt Gyors, de hol a bug? Miért várjunk, amíg az összes kód meg nem íródik az integrációs teszt megkezdéséhez Bottom up § § § Kezdjünk az alsó rétegű modulokkal; használjunk megfelelő drivereket; teszt Folyamat ismétlése; driverek helyettesítése modulokkal; a befejezésig Jó bug szigetelés, de mi van ha a komisz kis bugok a tetején vannak?
Integrációs Technikák II. § Top down § § § Mint a bottom up, de felülről kezdjük és stubokat használunk Jó bug elkülönítés, de mi van ha a piszkos kis bugok az alján vannak? Functional (Funkcionális) vagy Transactional (Tran § § § Integráljuk az egyes függvények vagy tranzakciók végrehajtásához szükséges összetevőket Ismételjük meg a folyamatot; helyettesítsük a stubokat és driverokat az összetevők egy halmazával a következő függvény vagy tranzakció megvalósításához Jó bug elkülönítés, a sorrend kockázatával integrációs bugokat fedez fel
System Test - Rendszerteszt § § § Cél: hibakeresés, bizalomépítés és a kockázat csökkentése a vizsgált rendszer egészének viselkedésében, függvényeiben és reakcióiban Tesztelés alatt álló elem: Az egész rendszer a lehető legreálisabb tesztkörnyezetben, beleértve a felhasználói és üzemeltetői kézikönyvet és a konfigurációs adatokat Bázisok: üzleti követelmények, felhasználói esetek, üzleti/szakterületi ismeretek, józan ész Környezet, eszközök: tesztkörnyezet, GUI (grafikus felhasználói felület) Felelős: általában független tesztelő
Acceptance Test – Elfogadási teszt § § § Cél: Bebizonyítani, hogy a termék készen áll a telepítésre/kiadásra Tesztelés alatt álló elem: Teljesen integrált rendszer, beleértve az üzleti, működési és karbantartási folyamatokat, felhasználói eljárásokat és konfigurációs adatokat Bázisok: Üzleti, felhasználói esetek, üzleti/szakterületi ismeretek, józan ész Környezet, eszközök: GUI (grafikus felhasználói felület) Felelős: Gyakran a felhasználók és az ügyfelek, de akár független tesztelők is.
Variációk az elfogadási tesztelésben § Felhasználói elfogadási tesztelés: Az üzleti felhasználók ellenőrzik, hogy alkalmasak-e funkcionális célokra. § § § Alfa, béta/ mezei próba: Tesztelés és bizalomépítés potenciális vagy már meglévő ügyfelek révén. A béta tesztelést és a mezei próbát a tényleges környezet(ek)ben végzik. Működési tesztelés: Elfogadás a rendszergazdák részéről (pl. biztonsági mentés-visszaállítás, katasztrófa utáni helyreállítás, felhasználói kezelés, karbantartás, adatbetöltés/adatvándorlás, biztonság). Szerződési és szabályozási tesztelés: A szerződésben vagy a törvényben előírt követelményeknek, rendeleteknek vagy szabványoknak való megfelelés ellenőrzése.
Build-time (Építési idő) vs. Run-time tests (Futási idő) § Az építési idő teszteket a fejlesztési folyamat során futtatják § § § Egység/összetevő tesztek, integrációs tesztek Gyors A fejlesztők végzik el Technikai ellenőrzés Mindig automatizált A futási idő tesztet a telepítés után hajtják végre (a szoftver már használatra kész) § § Egység/összetevő tesztek, integrációs tesztek, rendszer tesztek Több időt igényel A tesztelők végzik el Automatizált vagy manuális
Teszt Típusok ni. com
Teszt Típusok § A szoftvertesztelés típusa a különböző tesztelési tevékenységek kategóriákba sorolása, amelyek mindegyike rendelkezik meghatározott teszt céllal, teszt stratégiával és teszt teljesítménnyel.
Statikus tesztelés § A statikus tesztelés a szoftver munkatermékek manuális vagy eszközkészlettel való tesztelése, azonban ezek nem kerülnek végrehajtásra. § Statikus elemzés § § Eszköz használata a vizsgált elem kiértékeléséhez Átvizsgálás § A vizsgált elem manuális kiértékelése
Dinamikus teszt § Fehér doboz teszt vagy strukturált alapú tesztelés § § § A fehér dobozos tesztelés során a tesztelő arra koncentrál, hogy a szoftver hogyan csinálja. A szoftver belső felépítése a tesztelő előtt ismert Fekete doboz teszt vagy specifikáció alapú tesztelés § § A fekete dobozos tesztelés során a tesztelő arra koncentrál, hogy mit csinál a szoftver, nem pedig arra, hogyan. A szoftver belső felépítése a tesztelő előtt ismeretlen
Szürke doboz tesztelés § § § Csak feltételezzük a szoftver belső felépítését Követelmény: Az e-mail mezőjének érvényesnek kell lennie, ha a megadott érték tartalmaz ‚@’-ot, és üzenetet kell adnia a felhasználónak ha nem tartalmaz Teszt: írjuk be a ‘balazs. cserpak_gmail. com’ címet az e-mail mezőbe Várt eredmény: A felhasználót értesítjük, hogy a megadott e-mail cím formátuma helytelen Miért ne teszteljük a következőket: ‘john. doe. at. gmail. com, ‘jane. doegmail. com’, ‘donald. trump_gov. us’ stb. ?
Fekete doboz tesztelés § Funkcionális tesztelés § § § A funkcionális tesztelés egy olyan típusú tesztelés, amely igazolja, hogy a szoftver alkalmazás minden funkciója a követelmény-specifikációnak megfelelően működik-e. Mit csinál a rendszer Nem funkcionális tesztelés § § Olyan típusú tesztelés, amely a szoftver alkalmazás nem funkcionális szempontjainak ellenőrzésére szolgál. Kifejezetten arra tervezték, hogy egy rendszer készségét teszteljék olyan nem működő paraméterek szerint, amelyekre soha nem kerül sor a funkcionális teszteléssel. Mennyire csinálja jól a rendszer
Nem funkcionális tesztelés – Teljesítmény tesztelés § Terhelés-próba – ellenőrzi az alkalmazás képességét a várt felhasználói terhelések mellett. A cél a teljesítmény-akadályok azonosítása, mielőtt a szoftver alkalmazás életbe lép. § Stressz teszt – magában foglalja egy alkalmazás szélsőséges munkaterhelés alatt történő tesztelését, hogy megtudja, hogyan kezeli az a forgalom vagy az adatfeldolgozás. A cél az alkalmazás töréspontjának azonosítása. § Tartóssági tesztelés – annak biztosítása érdekében történik, hogy a szoftver hosszú ideig képes-e kezelni a várt terhelést.
Nem funkcionális tesztelés - Karbantarthatóság tesztelése § Alapvetően meghatározza, mennyire könnyű a rendszert karbantartani, milyen egyszerű az alkalmazás vagy termék elemzése, megváltoztatása és tesztelése. § § A frissítési/javítási telepítési és eltávolítási feladatok nem működnek A konfigurációkat nem lehet megfelelően megváltoztatni A kód nem fenntartható A szoftver nem hatékonyan tesztelhető
Használhatóság tesztelés § A használhatóság tesztelés során gyakorlatilag a tesztelők letesztelik, hogy a felhasználói felületek hogyan használhatók. Leteszteli, hogy az alkalmazás vagy a beépített termék felhasználóbarát-e vagy sem. § § § Tanulhatóság: Mennyire könnyű a felhasználók számára az alapvető feladatok elvégzése, amikor először találkoznak a designnal? Hatékonyság: Milyen gyorsan tudnak a tapasztalt felhasználók feladatokat végrehajtani? Emlékezetesség: Amikor a felhasználók visszatérnek a designhoz, miután egy ideig nem használták azt, vajon a felhasználó hatékonyan el fog boldogulni a következő alkalommal, vagy előröl kell kezdenie mindent megtanulni? Errorok: Mennyi hibát követ el a felhasználó, mennyire súlyosak ezek a hibák és milyen könnyen lehet őket helyreállítani? Elégedettség: Mennyire szereti a felhasználó használni a rendszert?
Portability § Annak tesztelése, hogy a számítógépes szoftverösszetevő vagy alkalmazás hogyan mozgatható az egyik környezetből a másikba § Hardver § Operációs rendszer § Böngésző
Egyéb nem funkcionális tesztelési típusok § § § Katasztrófa utáni helyreállítás Biztonság Lokalizálás Adatminőség És sok más
Változással kapcsolatos tesztek § Megerősítés teszt § § Annak ellenőrzése, hogy a változtatások sikeresen alkalmazva lettek-e (hibajavítás vagy új funkció) Regressziós teszt § Annak ellenőrzése, hogy a változtatások nem szakították meg a már meglévő funkciókat.
- Slides: 27