A szoftvertesztelés egy kutatási folyamat, egy szoftvertermék tesztelése , amelynek célja a program tényleges viselkedése és a várható viselkedése közötti megfelelés ellenőrzése egy bizonyos módon kiválasztott végső tesztsorozaton ( ISO / IEC TR 19759:2005) . 1] .
Különféle definíciókat adtak a tesztelésre különböző időpontokban és különböző forrásokból, többek között:
Az első szoftverrendszereket tudományos kutatási programok részeként, illetve a honvédelmi osztályok igényeire fejlesztették ki. Az ilyen termékek tesztelését szigorúan formalizált módon, minden vizsgálati eljárás, vizsgálati adat és a kapott eredmények feljegyzése mellett végezték. A tesztelést külön folyamatra különítették el, amely a kódolás befejezése után kezdődött, de általában ugyanaz a személyzet végezte.
Az 1960-as években nagy hangsúlyt fektettek a "kimerítő" tesztelésre, amelyet a kódban található összes útvonal vagy az összes lehetséges bemenet felhasználásával kellett elvégezni. Megjegyezték, hogy ilyen feltételek mellett a teljes szoftvertesztelés nem lehetséges, mert egyrészt nagyon nagy a lehetséges bemenetek száma, másrészt sok az út, harmadrészt pedig nehéz problémákat találni az architektúrában és a specifikációkban. Ezen okok miatt a „kimerítő” tesztelést elutasították, és elméletileg lehetetlennek ítélték.
Az 1970-es évek elején a szoftvertesztet "a termék helyességének bizonyításának folyamataként" vagy "a szoftver megfelelő működését ellenőrző tevékenységként" emlegették. A születőben lévő szoftverfejlesztésben a szoftverellenőrzést „a helyesség igazolásának” nevezték. Míg a koncepció elméletileg ígéretes volt, a gyakorlatban időigényes és nem elég átfogó. Úgy döntöttek, hogy a helyesség bizonyítása nem hatékony módszer a szoftverek tesztelésére. Néhány esetben azonban ma is alkalmazzák a helyes működés demonstrálását, például átvételi teszteket. Az 1970-es évek második felében a tesztelést egy program futtatásának tekintették azzal a szándékkal, hogy hibákat keressenek, nem pedig annak bizonyítását, hogy a program működik. A sikeres teszt olyan teszt, amely korábban ismeretlen problémákat fedez fel. Ez a megközelítés közvetlenül ellentétes az előzővel. Ez a két definíció a „tesztelési paradoxont” képviseli, amely két ellentétes állításon alapul: egyrészt a teszteléssel megbizonyosodhatunk arról, hogy a termék jól működik-e, másrészt feltárja a programok hibáit, megmutatva, hogy a termék nem működik. A tesztelés második célja a minőségjavítás szempontjából produktívabb, mivel nem teszi lehetővé a szoftverhibák figyelmen kívül hagyását.
Az 1980-as években a tesztelés kiterjedt a hibamegelőzésre is. A teszttervezés a leghatékonyabb ismert hibamegelőzési technika. Ezzel párhuzamosan elkezdődtek olyan gondolatok is megfogalmazódni, hogy szükség van egy tesztelési módszertanra, különös tekintettel arra, hogy a tesztelésnek tartalmaznia kell a teljes fejlesztési ciklus ellenőrzését, és ez egy kontrollált folyamat. A tesztelés során nem csak az összeállított programot, hanem a követelményeket, a kódot, az architektúrát és magukat a teszteket is ellenőrizni kell. Az 1980-as évek elejéig létező "hagyományos" tesztelés csak a lefordított, kész rendszerre vonatkozott (ma általában rendszertesztelésnek nevezik), de azóta a tesztelők a fejlesztési életciklus minden aspektusába bekapcsolódtak. Ez lehetővé tette, hogy a követelményekben és az architektúrában korábban megtalálják a problémákat, csökkentve ezzel a fejlesztési időt és költségvetést. Az 1980-as évek közepén jelentek meg az első automatizált tesztelési eszközök. A számítógépnek több tesztet kellett volna elvégeznie, mint egy ember, és ezt megbízhatóbban. Eleinte ezek az eszközök rendkívül egyszerűek voltak, és nem tudták szkripteket írni szkriptnyelveken.
Az 1990-es évek elején a "tesztelés" fogalmába kezdett beletartozni a tesztek és tesztkörnyezetek tervezése, tervezése, létrehozása, karbantartása és végrehajtása, és ez a tesztelésről a minőségbiztosításra való átmenetet jelentette, lefedve a teljes szoftverfejlesztési ciklust. Ekkoriban kezdtek megjelenni különféle szoftvereszközök a tesztelési folyamat támogatására: fejlettebb automatizálási környezetek szkriptek létrehozására és jelentések generálására, tesztmenedzsment rendszerek és terheléstesztelő szoftverek. Az 1990-es évek közepén, az internet fejlődésével és nagyszámú webes alkalmazás kifejlesztésével az „agilis tesztelés” (hasonlóan az agilis programozási módszertanokhoz) kezdett különösen népszerűvé válni.
Számos kritérium alapján szokás osztályozni a tesztelés típusait. Általában a következők vannak:
A tesztelés tárgyának megfelelőenAz ingyenes és nyílt forráskódú szoftverek esetében gyakran az alfatesztelési szakasz jellemzi a kód funkcionális tartalmát, a béta tesztelés pedig a hibajavítási szakaszt. Ugyanakkor általában a fejlesztés minden szakaszában a munka közbenső eredményei állnak a végfelhasználók rendelkezésére.
Az alábbiakban ismertetett technikák - fehér dobozos tesztelés és fekete doboz tesztelés - feltételezik, hogy a kód fut, és a különbség csak a tesztelő által birtokolt információkban van. Mindkét esetben dinamikus tesztelésről van szó .
A statikus tesztelés során a programkód nem fut le - a program elemzése a forráskód alapján történik, amelyet manuálisan olvasnak be, vagy speciális eszközökkel elemzik. Egyes esetekben nem a forráskódot elemezzük, hanem a közbenső kódot (például bájtkódot vagy MSIL -kódot ).
A statikus tesztelés magában foglalja a tesztelési követelményeket , specifikációkat és dokumentációt is .
A program következő verziójának módosításait követően a regressziós tesztek megerősítik, hogy a végrehajtott változtatások nem befolyásolták az alkalmazás többi funkciójának teljesítményét. A regressziós tesztelés manuálisan és tesztautomatizálási eszközökkel is elvégezhető .
A tesztelők különböző szinteken használnak tesztforgatókönyveket: mind a komponens tesztelése, mind az integráció és a rendszer tesztelése során. A tesztszkripteket általában olyan összetevők tesztelésére írják, amelyek valószínűleg meghibásodnak, vagy egy hiba, amelyet nem találnak időben, költséges lehet.
Attól függően, hogy a tesztfejlesztő hozzáfér-e a tesztelt program forráskódjához, különbséget tesznek a " fehér doboz tesztelése (stratégia szerint) " és a "fekete doboz tesztelése (stratégia szerint) " között.
A fehérdobozos tesztelés során (más néven átlátszó dobozos tesztelés ) a tesztfejlesztő hozzáfér a programok forráskódjához, és olyan kódot írhat, amely a tesztelt szoftver könyvtáraira hivatkozik. Ez jellemző az alkatrészek tesztelésére, ahol csak a rendszer egyes részeit tesztelik. Biztosítja, hogy a szerkezeti elemek bizonyos mértékig működőképesek és stabilak legyenek. A fehérdobozos tesztelés kódlefedettségi mérőszámokat vagy mutációtesztet használ .
A feketedobozos tesztelés során a tesztelő csak ugyanazokon az interfészeken keresztül férhet hozzá a programhoz, mint az ügyfél vagy a felhasználó, vagy olyan külső interfészeken keresztül, amelyek lehetővé teszik, hogy egy másik számítógép vagy más folyamat csatlakozzon a rendszerhez tesztelés céljából. Például egy tesztelő komponens virtuálisan megnyomhatja a tesztelt program billentyűit vagy egérgombjait a folyamatkommunikációs mechanizmus segítségével, és biztos lehet benne, hogy minden jól megy, és ezek az események ugyanazt a reakciót váltják ki, mint a valódi billentyűleütések és egérgombok. A feketedobozos tesztelést általában specifikációk vagy egyéb, a rendszer követelményeit leíró dokumentumok alapján végzik. Az ilyen típusú tesztelésnél a lefedettség kritériuma általában a bemeneti adatstruktúra lefedettségének, a követelmények lefedettségének és a modelllefedettségnek az összege (modell alapú tesztelés esetén ).
A szürke dobozos tesztelés során a tesztfejlesztő hozzáfér a forráskódhoz, de a tesztek közvetlen futtatásakor általában nincs szükség a kódhoz való hozzáférésre.
Míg az "alfa" és a "béta tesztelés" a termék megjelenése előtti szakaszokra utal (és implicit módon a tesztelő közösség méretére és a tesztelési módszerek korlátaira is), addig a fehér dobozos és fekete dobozos tesztelés arra utal, hogy a tesztelő eléri a célt.
A béta tesztelése általában a fekete doboz technikákra korlátozódik (bár a tesztelők egy része általában a béta teszteléssel párhuzamosan folytatja a fehér doboz tesztelését). Így a "béta tesztelés" kifejezés jelezheti a program állapotát (közelebb a kiadáshoz, mint az "alfa"), vagy jelezheti a tesztelők egy bizonyos csoportját és az e csoport által végrehajtott folyamatot. Vagyis a tesztelő folytathatja a fehérdobozos tesztelést annak ellenére, hogy a program már "béta", de ebben az esetben nem része a "béta tesztelésnek".
A kódlefedettség a program forráskódjának a tesztelés során végrehajtott ("lefedett") százalékát mutatja. A mérési módszerek szerint kezelői lefedettség, állapotlefedettség, útlefedettség, funkciólefedettség stb.
| Szoftverfejlesztés | |
|---|---|
| Folyamat | |
| Magas szintű koncepciók | |
| Útvonalak |
|
Fejlesztési módszertanok | |
| Modellek |
|
| Figyelemre méltó alakok |
|