Szoftvertesztelés - Bevezető

Átírás

1 Szoftvertesztelés - Bevezető Csirmaz Péter Livesoft Kft

2 Bevezetés A szoftvertesztelés egy rendszer vagy program kontrollált körülmények melletti futtatása, és az eredmények kiértékelése. A hagyományos megközelítés szerint a tesztelés célja az, hogy a fejlesztés során létrejövő hibákat minél korábban felfedezze, és ezzel csökkentse azok kijavításának költségeit. Emellett lehetőséget nyújt, hogy leellenőrizzük, hogy az adott szoftver: megfelel a felé támasztott követelményeknek, mind üzleti, mind technológiai szempontból megfelelően működik Implementálható ugyanazokkal a jellemzőkkel (pl: telepítés után is megfelelően viselkedik) A klasszikus szoftvertesztelés célja a szoftverhibák felfedezése. A fejlesztésnek minél korábbi szakaszában derül fény egy hibára, annál olcsóbb annak korrigálása. Újabb keletű elvárás a szoftverminőség mérése. Főleg az Agile Programming módszertanával futó projektek esetén a tesztelés a kockázatok becslését és menedzselését is magába foglalja A tesztelési folyamat egyszerűsített modelljében a megrendelő felállítja a szoftverrel szemben támasztott elvárásait. Ezen elvárásokat a megrendelő megbízottja tolmácsolja a fejlesztők felé a fejlesztő csapat vezető programozójának műszaki segítségével. Ezen munka eredménye a megvalósíthatósági tanulmány, mely az adott üzleti problémára javasol műszaki megoldásokat. A létrejövő programot elkészültekor fejlesztők átadják a tesztelő csapatnak. Az átadásban segíthet az tesztkörnyezet felállításáért felelős csapat és az új szoftver régi környezethez illesztéséért felelős csapat. Az átadás része a funkcionális specifikáció és a technikai specifikáció. A tesztelő csapat az átadott dokumentáció alapján elkészíti a tesztelési tervezetet, valamint becslést ad a tesztelés idő- és munkaerőigényéről. Ezek elfogadása esetén létrehozza a teszt szkripteket, melyek az adott és elvárt mértékben fedik le a tesztelendő funkcionalitásokat. A teszt szkriptek vagy más néven tesztesetek összessége a test suite, ezek összessége a tesztkampány (test campaign).

3 Hibafeltárás Minél körültekintőbb a tesztelés, annál valószínűbb, hogy a programban nem marad hiba. Tehát célszerű végigjárni az összes lehetséges végrehajtási utat, amit a programfutás során előfordulhat. Ha ezt nem tesszük meg, akkor az esetleges hiba csak a program használata során derül ki. A hibák feltárásának módszerei: Statikus tesztelés Statikus tesztelés aklamával a programot nem futtatjuk, hanem a forráskódot elemezzük és a tervezés során írt algoritmussal összehasonlítjuk. Ellenőrizzük, hogy szintaktikusan és szemantikusan helyes-e a program. Tehát a programozási nyelv helyesírási és nyelvtani szabályait betartottuk-e. Számos fejlesztőkörnyezet, illetve a fordítóprogram ezeket észreveszi, az okot és a hiba helyét többnyire jelzi is, tehát viszonylag egyszerű a javítás. Itt beleakadhatunk olyan hibákba is, mint például egy kezdőérték nélküli változó, vagy típuskeveredés, esetleg egy végtelen ciklus. Dinamikus tesztelés A programot működés közben vizsgáljuk. Erre az esetre két módszert ismerünk. Az egyik a fekete doboz módszer. Ekkor a forráskód ismerete nélkül dolgozunk. Mivel a legtöbb esetben minden adatot nem lehet letesztelni, ezért teszt csoportokat hozunk létre, ebbe beleértve olyan csoportokat is, melyek bemenetei érvénytelenek. Ezt követi a tesztelés. Mindemellett itt történik a határeseteket elemzése. A másik eljárás a fehér doboz módszer. Ennél a variációnál ismerjük a kódot. A teszteseteket a program struktúrája alapján választjuk, annak tudatában, hogy nem lehet minden végrehajtási sorrendre kipróbálni. Kipróbálási stratégiák: Utasítás lefedés: minden utasítást legalább egyszer hajtsunk végre. Feltétel lefedés: minden feltétel legyen legalább egyszer igaz, illetve hamis. Részfeltétel lefedés: minden részfeltétel legyen legalább egyszer igaz, illetve hamis. Speciális tesztelés A biztonsági szempontok a speciális esetek közé tartoznak. Itt teszteljük, hogy a nem érvényes adatok ki tudják-e akasztani a programot, és azt is, hogy elegendő ellenőrzésünk

4 van-e. A hatékonyságnál a futási időt és a memóriában elfoglalt helyet vizsgáljuk. Mennyiség tesztnél a szélsőséges adat mennyiséggel teszteljük a programot. Stressz tesztnél kritikus adatokat használunk. A funkció tesztnél pedig, azt, hogy minden funkciót az előírásoknak megfelelően tud-e a programunk. Ide tartozik még annak ellenőrzése is, hogy felhasználóbarát-e az alkalmazás. Érdemes beleépíteni, egy súgó menüpontot is a programba, hogy ne csak a dokumentációban kaphasson választ a felhasználó a felmerülő kérdéseire. A tesztelésnek egy módja az is, hogy megkérünk egy barátot vagy családtagot, hogy próbálja ki a programunk, hiszen mi, készítők akaratlanul is kikerüljük a hibalehetőségeket. Aki először látja a programot, könnyen bele tud botlani annak gyenge pontjaiba. A tesztelés módszereiről, az eddigi elhangzottak mellett, érdemes még konkrét programozási nyelv, és fejlesztői környezet mellett is beszélni, hiszen a nyelvek is, és a fejlesztői környezetek is igen különböző módszereket kínálnak számunkra. Módszertan A tesztelési módszertan a vállalaton belüli tesztelési folyamatok definícióját tartalmazza, vagyis azt, hogy a tesztelés hogyan és milyen formában kapcsolódik a fejlesztési folyamatba. A módszertan segít abban, hogy a jól bevált dolgokat alkalmazzuk a következő projektekben is. Így ha valamelyik munkában új, működő megoldást vezettünk be, akkor azt célszerű beleírni a módszertanba is, hogy majd a többi projektnél is megfelelően tudjuk alkalmazni. Amennyiben több projekt fut egyszerre, akkor nagy segítségünkre válhat egy jól kialakított módszertan. Mivel ez biztosítja majd a projektek közötti könnyebb átjárhatóságot. A projekttagokat igény szerint lehet egyik munkáról a másikra csoportosítani. Az "üzleti ismeretek" betanulási ideje természetesen megmarad, de a "technikai ismeretek" betanulási ideje 0-ra csökken, mivel ugyanazokkal az eszközökkel, környezetekkel, folyamatokkal, sablonokkal kell dolgozniuk a munkatársaknak. Általános nézet, hogy a tesztvezetők, tesztelési szakértők készítik el a módszertant. Ez többnyire igaz is, azzal a kitétellel, hogy a szakértőknek együtt kell dolgozniuk a projektvezetőkkel, menedzsmenttel. Így nagyobb a valószínűsége, hogy a vállalat számára használható, a cég működését legjobban lefedő módszertant tudnak létrehozni.

5 A tesztkörnyezet előnyei A tesztelők és a fejlesztők munkája teljesen elkülönül egymástól. Ha ugyanazon a környezeten kell dolgozniuk a tesztelőknek és a fejlesztőknek, a tesztelők munkája gyakorlatilag semmit sem ér. Időpocséklás az egész, mivel mialatt tesztel, azalatt megváltozhat alatta az alkalmazás. Így az addig lefuttatott tesztjei érvényüket vesztik, a tesztelő kezdheti elölről a munkáját. Folyamatosan kontroll alatt lehet tartani a tesztkörnyezetre kikerült alkalmazás verziókat. Így a hibák rögzítésénél pontosan meg lehet jelölni, melyik verzió, melyik funkciójánál találtuk meg a hibát. Az új verziókat a fejlesztőknek illik dokumentálni, hogy abban milyen új funkciók kerültek bele, illetve milyen eddig ismert hibákat javítottak ki. Ez segít a tesztelőknek az adott verzió feladataira koncentrálni. A verzió számot ismerve a fejlesztőnek pofon egyszerű lesz ismét előidézni a hibát, megtalálni az okát és kijavítani. Ha egy környezeten van a fejlesztés és tesztelés, akkor az egyes verziók nem tudnak elkülönülni egymástól, egyes hibák okát nem lehet majd kideríteni. (Megjegyzem pont azok a hibák a legrosszabbak, amelyek nem reprodukálhatóak, látszólag kijavultak.) A tesztkörnyezetre célszerű stabil verziókat kitenni, hogy amíg a fejlesztés dolgozik, addig a tesztelők is tudjanak haladni a munkájukkal. Így ha a következő verzió instabil, kritikus hibákkal van teli, akkor a fejlesztés egyszerűen tovább dolgozhat anélkül, hogy a tesztelést nagymértékben hátráltatná a feladataiban. (Általában az szokott előfordulni, hogy az egyes verziókat idő hiányában nem tudják teljesen leellenőrizni a tesztelők, az új verzió már készen van, a fejlesztők már tesztelésre akarják adni. Egy hiba kijavítása legtöbbször kevesebb időbe telik, mint a teljes körű tesztelése, ellenőrzése.) Nem utolsó sorban a tesztadatok is tiszták maradhatnak. Míg a fejlesztők tesztelnek a saját adataikkal a fejlesztő környezeten, addig a tesztelők sokkal életszerűbb adatokkal dolgozhatnak. Akár az éles környezetről lehet adatokat migrálni, ezáltal is precízebb tesztelést elérni. Azt már le sem merem írni, hogy igazából több tesztkörnyezetet is lehetne egymás mellett üzemeltetni. Egyiken integrációs tesztek folyhatnak, másikon funkcionális, harmadikon terheléses, stb.

6 Fogalmak Végül álljon itt egy szószedet (a wikipédiáról) hogy az angol terminológiában az egyes fogalmak mit is jelölnek: business A szoftvert megrendelő szervezet business analyst, BA A megrendelő elvárásait közvetítő megbízott business requirements A megfogalmazott elvárások Software Quality Assurance, SQA Szoftverminőség-biztosítás test requirements A tesztelendő funkcionalitások listája test coverage Funkcionalitás tesztekkel való lefedésének mértéke test plan Előzetes tesztelési terv a megfelelő test coverage elérése érdekében test scenario Egy alternatív tesztelési módszertan, a scenario testing esetében és csak ott hasonló szerepet tölt be, mint a test suite. test script Ezt a kifejezést helytelenül használják az automated test case helyett. A scripted testing ellentéte nem a manual testing, hanem az exlporatory. A test script a test case szinonímája. test case Egy elvárás egy adott részének működését ellenőrző dokumentum. Nagyon pontosan leírt feltételek és inputok mellett nagyon pontosan leírt funkcionalitást és outputot vár az ellenőrzött szoftvertől. test suite Egy adott funkcionalitást leíró test case-ek összessége a test suite. validation

7 verification fault failure defect bug Ellenőrzés: "you built the right product" tehát a specifikáció tényleg a megrendelő elvárásait tartalmazza Ellenőrzés: "you built the product right" tehát a programozó a specifikáció szerint írta meg a szoftvert Programozási hiba, mely funkcionális hibával nem jár. Programozási hiba, mely a funkcionalitásra hatással van. Tesztelő által észlelt failure, programozó által vissza nem igazolt Defect, mely a programozó szerint is az Források: