A regressziós tesztelés ( angol. regression testing ← lat. regressio „visszatérés, visszatérés, visszavonulás”) egy gyűjtőnév minden olyan szoftverteszthez, amelynek célja a forráskód már tesztelt szakaszaiban lévő hibák észlelése . Az ilyen hibákat – amikor a program módosítása után valami, aminek tovább kellett volna működnie, az leáll – ezeket regressziós hibáknak nevezzük .
Regressziós tesztelés (egyeseknél[ mi? ] források) új hibajavítást tartalmaz - újonnan talált hiba javításának ellenőrzése, régi hibajavítás - annak ellenőrzése, hogy a korábban kijavított és ellenőrzött hiba nem reprodukálódik-e újra a rendszerben, valamint mellékhatás is - annak ellenőrzése, hogy a korábban működő hiba a funkcionalitás nem sérült meg, ha a kódját befolyásolhatja más funkciók hibáinak javítása. Az általánosan használt regressziós tesztelési módszerek közé tartozik a korábbi tesztek újrafuttatása, valamint annak ellenőrzése, hogy a kódegyesítés következtében regressziós hibák kerültek-e be a következő verzióba.
A szoftverfejlesztés tapasztalataiból ismert, hogy ugyanazon hibák ismétlődő megjelenése meglehetősen gyakori eset. Néha ez a gyenge verziókezelési technikáknak vagy a verziókezelésben elkövetett emberi hibáknak köszönhető . De ugyanilyen gyakran a probléma megoldása „rövid életű”: a következő programmódosítás után a megoldás leáll. És végül, a kód bármely részének átírásakor gyakran ugyanazok a hibák jelentkeznek, amelyek az előző megvalósításban voltak.
Ezért a hibajavítás során bevált gyakorlatnak tekinthető, hogy tesztet hozzon létre, és rendszeresen lefusson a program későbbi módosításaival. Bár a regressziós tesztelés kézzel is elvégezhető, leggyakrabban speciális programok segítségével végzik el, amelyek lehetővé teszik az összes regressziós teszt automatikus végrehajtását . Egyes projektek még eszközöket is használnak a regressziós tesztek adott időintervallumban történő automatikus futtatására. Ezt általában minden sikeres összeállítás után (kis projekteknél) minden este vagy hetente megteszik.
A regressziós tesztelés az Extreme Programming szerves része . Ez a módszer a tervdokumentációt a teljes szoftvercsomag bővíthető, megismételhető és automatizált tesztelésével váltja fel a szoftverfejlesztési folyamat minden szakaszában .
A regressziós tesztelés nem csak a program helyességének ellenőrzésére használható, hanem gyakran az eredmény minőségének értékelésére is . Tehát egy fordító fejlesztésekor a regressziós tesztek futtatásakor figyelembe veszik az eredményül kapott kód méretét, a végrehajtás sebességét és az egyes tesztesetek fordítási idejét.
S. Yoo és M. Harman [1] cikkében a regressziós tesztelés következő osztályozását adja meg:
A halmazminimalizálási teszt a teszthalmaz méretének csökkentésére törekszik úgy, hogy adott kritérium alapján a teszteseteket kizárja a tesztkészletből. Három megközelítés létezik, amelyek közül az első automatizált biztonsági tesztelést alkalmaz a sebezhetőségek felderítésére az olyan alkalmazáshibák vizsgálatával, amelyek képesek felismerni az ismert rosszindulatú programokat, például vírusokat vagy férgeket. Ez a megközelítés csak az előző verzió sikertelen tesztjeit veszi figyelembe a rendszer új verziójában történő újrafuttatásnak a probléma kijavítása után.
Egy másik megközelítés a webalkalmazások kisebb kiadásaiban lévő sebezhetőségek észlelésére és kijavítására szolgál. Szilárd hivatkozást hoz létre az előző verzió oldalaihoz olyan iterátorok segítségével, amelyek a sebezhetőséget tartalmazó weboldalak vizsgálatára vannak kiválasztva.
És végül a harmadik megközelítés a rendszer önadaptációjával végzett tesztelést kínál a már ismert hibákra. A szerzők elkerülik a már ismert hibák reprodukálását azzal, hogy csak azokat a teszteket veszik számításba, amelyek a korábbi verziók ismert hibáit tárták fel.
A prioritási teszt probléma a tesztek helyes elrendezésével kapcsolatos, ami maximalizálja a kívánt tulajdonságokat, például a hibák korai felismerését. Ezenkívül a jelenlegi prioritási megközelítések csak a sebezhetőségeket veszik figyelembe.
Az egyik módszer hibaalapú prioritásteszteket kínál, amelyek közvetlenül kihasználják a hibák észlelésére vonatkozó tudásukat.
A másik egy cserélhető felvétel-lejátszási rendszert kínál, amely lehetővé teszi az alkalmazás felvett, végrehajtott verziójának átírását egy új, módosított verzióra. Ezek végrehajtása prioritást élvez, mivel a költségfüggvény alapján meghatározzuk az optimális módosított átírást, és újrapróbálkozáskor mérjük az eredeti és a módosított végrehajtás közötti különbséget.
A kiválasztási módszer lehetővé teszi egy részhalmaz vagy az összes teszteset kiválasztását a szoftver megváltozott részeinek teszteléséhez. A következő megközelítések a biztonsági mechanizmusokat és a sebezhetőségeket egyaránt tesztelik.
A regressziós tesztet akkor hajtják végre, ha a szoftver meglévő funkcionalitását módosítják, vagy ha hibajavítás történik a szoftverben. A regressziós tesztelés többféle megközelítéssel is megvalósítható. Ha a módosított program minden tesztet sikeresen teljesít, akkor biztos lehet benne, hogy a szoftveren végrehajtott változtatások nem érintik a meglévő funkcionalitást, amely minden esetben változatlan marad.
Egy agilis projektmenedzsment folyamatban, ahol a szoftverfejlesztési életciklus nagyon rövid, az erőforrások szűkösek, és a szoftverek nagyon gyakran változnak. A regressziós tesztelés sok szükségtelen többletköltséget jelenthet.
A regressziótesztelés általában automatizálási eszközökkel történik, de a regressziótesztelő eszközök jelenlegi generációja nem alkalmas adatbázis-alkalmazások kezelésére. Emiatt az adatbázisokat használó alkalmazások regressziós tesztjének futtatása nem tervezett költségekkel járhat, mivel sok kézi munkát igényel.
A szoftverkarbantartás alapvető problémája, hogy egy hiba kijavítása nagy valószínűséggel (20-50%) újat okoz. Ezért az egész folyamat a „két lépés előre, egy lépés hátra” elvét követi.
Miért nem tudjuk pontosabban kijavítani a hibákat? Először is, még egy rejtett hiba is egy helyen meghibásodásként nyilvánul meg. A valóságban ennek gyakran az egész rendszerre kiterjedő következményei vannak, általában nem nyilvánvalóak. Bármilyen kísérlet arra, hogy minimális erőfeszítéssel kijavítsa, kijavítja azt, ami helyi és nyilvánvaló, de ha a szerkezet nem nagyon világos, vagy a dokumentáció nem nagyon jó, a javítás hosszú távú hatásai észrevétlenek maradnak. Másodszor, a hibákat általában nem a program szerzője javítja ki, hanem gyakran egy fiatal programozó vagy gyakornok.
Az új hibák bevezetése miatt a programkarbantartás utasításonként sokkal több rendszerhibakeresést igényel, mint bármely más programozási forma. Elméletileg minden javítás után le kell futtatni a teljes tesztesetet, amellyel szemben a rendszert korábban ellenőrizték, hogy megbizonyosodjon arról, hogy nem sérült-e meg valamilyen érthetetlen módon. A gyakorlatban az ilyen visszalépési (regressziós) tesztelésnek valóban meg kell közelítenie ezt az elméleti ideált, és ez nagyon költséges.
- F. Brooks A mitikus emberhónap vagy a szoftverrendszerek létrehozásának módja [2]