Regresní testování ( angl. regression testing ← lat. regressio „moving back, return, retreating“) je souhrnný název pro všechny typy testování softwaru zaměřené na odhalování chyb v již testovaných částech zdrojového kódu . Takové chyby – když po provedení změn v programu přestane fungovat něco, co mělo fungovat dál – se nazývají regresní chyby .
Regresní testování (pro některé[ co? ] zdroje) zahrnuje novou opravu chyby – kontrola opravy nově nalezené závady, starou opravu chyby – kontrola, zda se dříve opravená a ověřená závada znovu nereprodukuje v systému, a také vedlejší efekt – kontrola, zda dříve fungující funkčnost nebyla porušena, pokud by její kód mohl být ovlivněn opravou některých závad v jiné funkčnosti. Mezi běžně používané metody regresního testování patří opakování předchozích testů a také kontrola, zda se chyby regrese nedostaly do další verze v důsledku sloučení kódu.
Ze zkušeností s vývojem softwaru je známo, že opakovaný výskyt stejných chyb je poměrně častým případem. Někdy je to kvůli slabým technikám správy verzí nebo kvůli lidské chybě při správě verzí . Ale stejně často je řešení problému „krátké“: po další změně v programu řešení přestane fungovat. A nakonec, při přepisování jakékoli části kódu se často objevují stejné chyby, které byly v předchozí implementaci.
Proto se při opravě chyby považuje za dobrou praxi vytvořit pro ni test a pravidelně jej spouštět s následnými změnami v programu. Ačkoli lze regresní testování provádět ručně, nejčastěji se provádí pomocí specializovaných programů, které umožňují provádět všechny regresní testy automaticky . Některé projekty dokonce používají nástroje pro automatické spouštění regresních testů v daném časovém intervalu. To se obvykle provádí po každé úspěšné kompilaci (v malých projektech) buď každý večer nebo každý týden.
Regresní testování je nedílnou součástí extrémního programování . Tato metodika nahrazuje projektovou dokumentaci rozšiřitelným, opakovatelným a automatizovaným testováním celého softwarového balíku v každé fázi procesu vývoje softwaru .
Regresní testování lze použít nejen ke kontrole správnosti programu, často se používá také k hodnocení kvality výsledku. Při vývoji kompilátoru se tedy při spouštění regresních testů bere v úvahu velikost výsledného kódu, rychlost jeho provádění a doba kompilace každého z testovacích případů.
S. Yoo a M. Harman [1] ve svém článku poskytují následující klasifikaci regresního testování:
Test minimalizace sady se snaží zmenšit velikost sady testů odstraněním testovacích případů ze sady testů na základě daného kritéria. Existují tři přístupy, z nichž první využívá automatizované bezpečnostní testování k odhalování zranitelností zkoumáním chyb aplikací, které mohou detekovat známý malware, jako jsou viry nebo červi. Tento přístup považuje pouze neúspěšné testy z předchozí verze za opětovné spuštění v nové verzi systému po vyřešení problému.
Další přístup je navržen pro detekci a opravu zranitelností v menších verzích webových aplikací. Nastaví pevný odkaz se stránkami předchozí verze pomocí iterátorů, které jsou vybrány k prozkoumání webových stránek obsahujících zranitelnosti.
A konečně třetí přístup nabízí testování se samočinnou adaptací systému na již známé poruchy. Autoři se vyhýbají reprodukování již známých chyb tím, že berou v úvahu pouze ty testy, které mají být spuštěny a které odhalily známá selhání v předchozích verzích.
Problém testu stanovení priority spočívá ve správném řazení testů, což maximalizuje požadované vlastnosti, jako je včasná detekce chyb. Současné přístupy k upřednostňování také zohledňují pouze zranitelnosti.
Jedna metoda nabízí testy priority založené na chybách, které přímo využívají znalost jejich schopnosti detekovat chyby.
Druhý nabízí měnitelný systém přehrávání záznamů, který umožňuje přepsat nahranou, spuštěnou verzi aplikace do nové, upravené. Jejich provedení je upřednostněno kvůli určení optimálního upraveného přepisu na základě nákladové funkce a měření rozdílu mezi původním provedením a upraveným provedením při opakování.
Metoda výběru vám umožňuje vybrat podmnožinu nebo všechny testovací případy za účelem testování změněných částí softwaru. Následující přístupy testují jak bezpečnostní mechanismy, tak zranitelnosti.
Regresní testování se provádí, když jsou provedeny změny ve stávající funkčnosti softwaru nebo pokud je v softwaru opravena chyba. Regresní testování lze implementovat několika přístupy. Úspěšné absolvování všech testů upraveným programem poskytuje jistotu, že změny provedené v softwaru neovlivní stávající funkčnost, která by v každém případě měla zůstat nezměněna.
V agilním procesu řízení projektů, kde je životní cyklus vývoje softwaru velmi krátký, zdroje jsou vzácné a změny softwaru jsou prováděny velmi často. Regresní testování může přinést spoustu zbytečné režie.
Regresní testování se obvykle provádí pomocí automatizačních nástrojů, ale současná generace nástrojů pro regresní testování není navržena pro práci s databázovými aplikacemi. Z tohoto důvodu může při spouštění regresního testu na aplikacích, které používají databáze, vzniknout neplánované náklady, protože to vyžaduje hodně ruční práce.
Zásadním problémem při údržbě softwaru je, že oprava jedné chyby má vysokou pravděpodobnost (20-50 %), že způsobí, že se objeví nová. Proto se celý proces řídí zásadou „dva kroky vpřed, jeden krok zpět“.
Proč nemůžeme chyby opravovat přesněji? Za prvé, i skrytá vada se projeví poruchou na jednom místě. Ve skutečnosti má často důsledky v celém systému, které obvykle nejsou zřejmé. Jakýkoli pokus o opravu s minimálním úsilím opraví to, co je místní a zřejmé, ale pokud není struktura velmi jasná nebo dokumentace velmi dobrá, dlouhodobé účinky této opravy zůstanou bez povšimnutí. Za druhé, chyby obvykle neopravuje autor programu, ale často junior programátor nebo praktikant.
Kvůli zavedení nových chyb vyžaduje údržba programu mnohem více systémového ladění na příkaz než jakákoli jiná forma programování. Teoreticky je po každé opravě potřeba spustit celou sadu testovacích případů, proti kterým byl systém předtím kontrolován, abyste se ujistili, že nebyl nějakým nepochopitelným způsobem poškozen. V praxi by se takové backtracking (regresní) testování skutečně mělo tomuto teoretickému ideálu blížit a je velmi nákladné.
- F. Brooks Mýtický člověk-měsíc aneb jak vznikají softwarové systémy [2]