A regressziós tesztelés (ritkábban nem-regressziós tesztelés ) funkcionális és nem funkcionális tesztek újbóli lefuttatása annak biztosítására, hogy a korábban kifejlesztett és tesztelt szoftver egy változtatás után is a várakozásoknak megfelelően működjön. Ha nem így van, akkor azt regressziónak nevezzük.
A regressziós tesztelést igénylő változtatások közé tartoznak a hibajavítások, szoftverfejlesztések, konfigurációs változtatások, sőt az elektronikus alkatrészek ( hardver ) cseréje is. Mivel a regressziós tesztkészletek minden feltárt hibával együtt bővülnek, gyakran alkalmazzák a tesztautomatizálást. Esetenként változáshatás-elemzést végeznek a tesztek megfelelő részhalmazának meghatározására ( nem-regressziós analízis ).
Háttér A szoftverek frissítése, módosítása vagy egy átalakított célrendszeren való újrafelhasználása során gyakran előfordul, hogy új hibák lépnek fel, illetve a régi hibák újra megjelennek.
Előfordul, hogy a hiba újbóli felmerülése azért történik, mert egy javítás elveszik a nem megfelelő verziókövetési gyakorlatok (vagy a verziókövetésben előforduló egyszerű emberi hiba ) miatt. Gyakran előfordul, hogy egy probléma javítása „ törékeny ”, abban az értelemben, hogy a problémát csak abban a szűk esetekben oldja meg, amikor azt először észlelték, de nem az általánosabb esetekben, amelyek a szoftver élettartama alatt felmerülhetnek. Gyakran előfordul, hogy egy adott területen a probléma javítása véletlenül szoftverhibát okoz egy másik területen.
Előfordulhat, hogy egy funkció újratervezésekor az eredeti megvalósítás során elkövetett hibák némelyike az újratervezés során is előfordul. A legtöbb szoftverfejlesztési helyzetben jó kódolási gyakorlatnak számít, hogy ha egy hibát megtalálnak és kijavítanak, akkor rögzítsenek egy olyan tesztet, amely a hibát feltárja, és ezt a tesztet a program későbbi módosításai után rendszeresen futtassák újra.
Bár ez manuális tesztelési eljárásokkal, programozási technikák használatával is elvégezhető, gyakran automatizált tesztelőeszközöket használnak. Egy ilyen tesztkészlet olyan szoftvereszközöket tartalmaz, amelyek lehetővé teszik a tesztelési környezet számára, hogy automatikusan végrehajtsa az összes regressziós tesztesetet ; számos projekt rendelkezik automatizált folyamatos integrációs rendszerrel amely meghatározott időközönként újra futtatja az összes regressziós tesztet, és jelentést készít az esetleges hibákról (amelyek regresszióra vagy elavult tesztre utalhatnak).
Gyakori stratégiák, hogy egy ilyen rendszert minden sikeres fordítás után (kis projektek esetén), minden este vagy hetente egyszer futtatnak. Ezeket a stratégiákat egy külső eszköz automatizálhatja.
A regressziós tesztelés az extrém programozási szoftverfejlesztési módszer szerves része. Ebben a módszerben a tervdokumentumok helyébe a teljes szoftvercsomag átfogó, megismételhető és automatizált tesztelése léphet fel a szoftverfejlesztési folyamat minden szakaszában. A regressziós tesztelést a funkcionális tesztelés befejezése után végzik el annak érdekében, hogy a többi funkció is megfelelően működik-e.
A vállalati világban a regressziós tesztelést hagyományosan egy szoftverminőség-biztosító csapat végzi, miután a fejlesztőcsapat befejezte a munkát. Az ebben a szakaszban talált hibák javítása azonban a legköltségesebb. Ezt a problémát az egységtesztelés térnyerése próbálja orvosolni. Bár a fejlesztők mindig is írtak teszteseteket a fejlesztési ciklus részeként, ezek a tesztesetek általában funkcionális tesztek vagy egységtesztek voltak, amelyek csak a kívánt eredményeket ellenőrizték. A fejlesztői tesztelés arra kényszeríti a fejlesztőt, hogy az egységtesztelésre összpontosítson, és pozitív és negatív teszteseteket is beépítsen.
technikák A különböző regressziós tesztelési technikák a következők:
Mindent újratesztelni Ez a módszer az aktuális program összes tesztesetét lefuttatja annak integritásának ellenőrzése érdekében. Bár ez költséges, mivel az összes tesztesetet újra le kell futtatni, így biztosítja, hogy a módosított kód miatt ne legyenek hibák.
Regressziós teszt kiválasztása A „mind újratesztelése” módszerrel ellentétben ez a technika a tesztkészlet egy részét futtatja le (a „mind újratesztelése” költségei miatt), ha a tesztkészlet egy részének kiválasztásának költsége kisebb, mint a „mind újratesztelése” módszerrel.
Tesztesetek priorizálása A teszteseteket rangsorolja úgy, hogy javuljon a tesztcsomag hibajelentési aránya. A tesztesetek rangsorolásának módszerei úgy osztják be a teszteseteket, hogy a magasabb prioritásúakat az alacsonyabb prioritásúak előtt hajtsák végre.
A tesztesetek priorizálásának típusai
Általános prioritásrendezés – Azok a tesztesetek kapjanak elsőbbséget, amelyek a későbbi verziókban is hasznosak lesznek Verzióspecifikus prioritásrendezés – A tesztesetek prioritását a szoftver egy adott verziójához igazítsuk.
Hibrid Ez a módszer a regressziós tesztek kiválasztásának és a tesztesetek fontossági sorrendbe állításának ötvözete.
Előnyök és hátrányok Regressziós tesztelést akkor végeznek, ha a szoftver meglévő funkcióiban változtatások történnek, vagy ha a szoftverben hibajavításra kerül sor. A regressziós tesztelés többféle módszerrel is elvégezhető; ha az „minden tesztelés” megközelítést alkalmazzák, az biztosítékot nyújt arra, hogy a szoftverben végrehajtott változtatások nem érintették a meglévő, változatlan funkciókat.
Az agilis szoftverfejlesztésben – ahol a szoftverfejlesztési életciklusok nagyon rövidek, az erőforrások szűkösek, és a szoftveren nagyon gyakran végeznek változtatásokat – a regressziós tesztelés sok felesleges többletterhelést okozhat.
Egy olyan szoftverfejlesztési környezetben, amely hajlamos harmadik féltől származó fekete doboz komponenseket használni, a regressziós tesztelés végrehajtása bonyolult lehet, mivel a harmadik féltől származó komponens bármilyen változása zavarhatja a rendszer többi részét (és a regressziós tesztelés végrehajtása egy harmadik féltől származó komponensen nehéz, mivel az egy ismeretlen entitás).
Felhasználás A regressziós tesztelés nemcsak egy program helyességének tesztelésére használható, hanem gyakran a kimenet minőségének nyomon követésére is. Például egy fordítóprogram tervezésekor a regressziós tesztelés nyomon követheti a kód méretét és a tesztkészlet-esetek fordításához és végrehajtásához szükséges időt.
Az új hibák megjelenésének következtében a program karbantartása az írt utasítások számához viszonyítva sokkal több rendszeres tesztelést igényel, mint bármely más programozási feladat. Elméletileg minden javítás után le kell futtatni a rendszerrel korábban végrehajtott összes tesztesetet, hogy megbizonyosodjunk arról, nem sérült-e meg a rendszer valamilyen rejtett módon. A gyakorlatban az ilyen „regressziós tesztelésnek” valóban meg kell közelítenie ezt az elméleti elképzelést, és ez rendkívül költséges. Regressziós tesztek bármilyen szinten elvégezhetők, az egységtől a rendszerintegrációig . A funkcionális tesztek a teljes programot különféle bemenetekkel tesztelik. Ezek a tesztek gyakran automatizáltak az ismétlés szükségessége miatt, és olyan teszteszközökkel is elvégezhetők, amelyek nem részei a fordítóprogram-készletnek. A nem funkcionális tesztek olyan szempontokat mérnek fel, mint a teljesítmény, a biztonság vagy a megbízhatóság. A nem funkcionális regressziós tesztek elvégzése további kihívásokat jelent. Például a teljesítményváltozások észlelése gyakran statisztikailag összetett, míg a biztonsági problémák jellemzően a szoftver ökoszisztéma sebezhetőségeiből, nem pedig az egyes kódváltozásokból erednek.
Referenciák
Kategória:Extrém programozás Kategória:Szoftvertesztelés