Szerkesztő:MklosL/Teszteset
A szoftvermérnöki területen a teszteset egy olyan specifikáció, amely meghatározza a bemeneteket, végrehajtási feltételeket, tesztelési eljárást és várt eredményeket, ami egyetlen teszt végrehajtásához szükséges egy adott szoftvertesztelési cél eléréséhez, például egy adott programútvonal megvalósításának teszteléséhez vagy egy specifikus követelmény teljesítésének ellenőrzéséhez. [1] A tesztesetek a módszeres, nem pedig véletlenszerű tesztelés alapját képezik. A tesztelés alatt álló szoftver kívánt lefedettségének eléréséhez egy tesztesetek akkumulátora építhető fel. A formálisan meghatározott tesztesetek lehetővé teszik ugyanazon tesztek ismételt futtatását a szoftver egymást követő verzióival szemben, ami hatékony és következetes regressziós tesztelést tesz lehetővé. [2]
Formális tesztesetek
szerkesztésAz alkalmazás összes követelményének teljes körű teszteléséhez legalább két tesztesetnek kell lennie minden egyes követelményre: egy pozitív teszt és egy negatív teszt.[3] Ha egy követelménynek alkövetelményei vannak, akkor minden alkövetelménynek legalább két tesztesettel kell rendelkeznie. A követelmény és a teszt közötti kapcsolat nyomon követését gyakran traceability mátrix segítségével végzik. A írott tesztesetek tartalmazzák a tesztelendő funkcionalitás leírását, valamint azt a felkészülést, amely szükséges annak biztosításához, hogy a tesztet lehessen végrehajtani.
Egy formális írott tesztesetet az jellemzi, hogy ismert bemenettel és a teszt végrehajtása előtt kidolgozott várt kimenettel rendelkezik. [4]A ismert bemenetnek egy előfeltételt kell tesztelnie, és a várt kimenetnek egy utófeltételt kell tesztelnie.
Informális tesztesetek
szerkesztésAzokban az alkalmazásokban vagy rendszerekben, amelyek nem rendelkeznek formális követelményekkel, a teszteseteket az elfogadott normál működés alapján írhatják meg hasonló osztályú programokra. Néhány tesztelési iskola szerint egyáltalán nem írnak teszteseteket, hanem a tevékenységeket és eredményeket csak a tesztek lefutása után jelentik.
A forgatókönyv tesztelés során hipotetikus történeteket használnak, hogy segítsék a tesztelőt egy bonyolult probléma vagy rendszer átgondolásában. Ezeket a forgatókönyveket általában nem részletezik részletesen. Lehetnek egyszerűek, mint például egy diagram a tesztelési környezet számára, vagy lehetnek prózában írt leírások. Az ideális forgatókönyv teszt egy olyan történet, amely motiváló, hihető, bonyolult, és könnyen értékelhető. Általában különböznek a tesztesetektől abban, hogy a tesztesetek egyetlen lépéseket tartalmaznak, míg a forgatókönyvek több kulcsfontosságú lépést is lefednek. [5] [6]
Tipikus írásbeli teszteset formátum
szerkesztésA teszteset általában egyetlen lépést vagy lépéssorozatot tartalmaz, hogy tesztelje az alkalmazás helyes viselkedését/funkcionalitását és jellemzőit. Általában megadják az elvárt eredményt vagy kimenetet.
További információk, amelyek szerepelhetnek: [7]
- Teszteset azonosítója (ID) - Ez a mező egyedileg azonosítja a tesztesetet.
- Teszteset Leírása/Összefoglalása - Ez a mező leírja a teszteset célját.
- Tesztlépések - Ebben a mezőben az adott teszteset végrehajtásához szükséges pontos lépések vannak felsorolva.
- Várt eredmény - Ebben a mezőben kell definiálni, hogy mit vársz látni, és ez alapján döntöd el, hogy a teszt sikeres vagy sikertelen.
- Tényleges eredmény - Ebben a mezőben kell meghatározni az aktuális eredményeket, hogy el tudd dönteni, hogy a teszt sikeres vagy sikertelen volt.
- Előfeltételek - Ebben a mezőben meghatározzák azokat a feltételeket vagy lépéseket, amelyeket a tesztlépések végrehajtása előtt be kell tartani.
- Tesztkategória
- Szerző – A tesztelő neve.
- Automatizálás – Ez a teszteset automatizált-e vagy sem.
- Megfelelt/nem sikerült
- Megjegyzések
A nagyobb tesztesetek tartalmazhatnak előfeltételeket vagy lépéseket, valamint leírásokat is. [7]
Egy írott tesztesetnek tartalmaznia kell egy helyet a tényleges eredmény számára is.
Ezeket a lépéseket tárolhatjuk szövegszerkesztő dokumentumban, táblázatkezelőben, adatbázisban vagy más gyakran használt tárolóhelyen.
Adatbázisrendszerben az előző teszteredményeket és azokat az eredményeket generáló személyeket, valamint az eredmények generálásához használt rendszerkonfigurációt is láthatod. Ezek az előző eredmények általában külön táblában lennének tárolva.
A tesztcsomagok gyakran tartalmaznak [8]
- Teszt összefoglaló
- Konfiguráció
A teszteset legidőigényesebb része azon túl, hogy leírja a tesztelendő funkcionalitást és az ahhoz szükséges előkészületeket, maguknak a teszteknek a létrehozása és módosítása a rendszer változásai esetén.
Különleges körülmények között előfordulhat, hogy szükség van a teszt végrehajtására, az eredmények előállítására, majd egy szakértői csapat értékeli, hogy az eredményeket tekintetbe lehet-e venni sikeresnek. Ez gyakran előfordul az új termékek teljesítményszámának meghatározásakor. Az első tesztet alapnak veszik a későbbi tesztekhez és termékkiadási ciklusokhoz.
Elfogadási tesztek, amelyek egy írott teszteset változatát használják, általában egy végfelhasználókból vagy a rendszer ügyfeleiből álló csoport által végrehajtottak annak érdekében, hogy biztosítsák, hogy a fejlesztett rendszer megfelel a meghatározott követelményeknek vagy a szerződésnek. [9] [10]A felhasználói elfogadási tesztek (UAT) jellemzően a boldog útvonalra vagy pozitív tesztesetekre összpontosítanak, és szinte teljesen kizárják a negatív teszteseteket
Lásd még
szerkesztésHivatkozások
szerkesztésKülső linkek
szerkesztés- Software Test Case Engineering – Ajay Bhagwat
Sablon:Software engineering [[Kategória:Szoftvertesztelés]]
- ↑ Systems and software engineering -- Vocabulary. Iso/Iec/IEEE 24765:2010(E), 1–418. o.. DOI: 10.1109/IEEESTD.2010.5733835 (2010. december 1.). ISBN 978-0-7381-6205-8
- ↑ Kaner (2003. május 1.). „What Is a Good Test Case?”. STAR East, 2. o.
- ↑ Writing Test Rules to Verify Stakeholder Requirements. StickyMinds
- ↑ Beizer, Boris. Black Box Testing. New York: Wiley, 3. o. (1995. május 22.). ISBN 9780471120940
- ↑ An Introduction to Scenario Testing. Cem Kaner. (Hozzáférés: 2009. május 7.)
- ↑ Crispin, Lisa. Agile Testing: A Practical Guide for Testers and Agile Teams. Addison-Wesley, 192–5. o. (2009). ISBN 978-81-317-3068-3
- ↑ a b Liu, Juan. Equilibrium of Decision-Making Process in Financial Market, 2014 International Conference on Computational Science and Computational Intelligence, 113–121. o.. DOI: 10.1109/CSCI.2014.104 (2014). ISBN 9781605951676. Hozzáférés ideje: 2019. október 22.Liu, Juan (2014). "Equilibrium of Decision-Making Process in Financial Market". 2014 International Conference on Computational Science and Computational Intelligence. pp. 113–121. doi:10.1109/CSCI.2014.104. ISBN 9781605951676. S2CID 15204091. Retrieved 2019-10-22. Forráshivatkozás-hiba: Érvénytelen
<ref>címke, „Liu” nevű forráshivatkozás többször van definiálva eltérő tartalommal - ↑ Kaner, Cem. Testing Computer Software, 2nd, Boston: Thomson Computer Press, 123–4. o. (1993). ISBN 1-85032-847-1
- ↑ Hambling, Brian. User Acceptance Testing: A Step-by-step Guide. BCS Learning & Development Limited (2013). ISBN 9781780171678
- ↑ Black, Rex. Managing the Testing Process: Practical Tools and Techniques for Managing Hardware and Software Testing. Hoboken, NJ: Wiley (2009. augusztus 1.). ISBN 978-0-470-40415-7