Regressionstestning ( eng. regression testing ← lat. regressio “moving back, returning, retreating”) är ett samlingsnamn för alla typer av mjukvarutestning som syftar till att upptäcka fel i redan testade delar av källkoden . Sådana fel - när, efter att ha gjort ändringar i programmet, något som borde ha fortsatt att fungera slutar fungera - kallas de för regressionsbuggar .
Regressionstestning (för vissa[ vad? ] källor) inkluderar ny buggfix - kontroll av korrigeringen av en nyligen hittad defekt, gammal buggfix - kontroll av att en tidigare åtgärdad och verifierad defekt inte reproduceras i systemet igen, och även bieffekt - kontroll av att tidigare fungerande funktionaliteten har inte gått sönder, om dess kod skulle kunna påverkas av att åtgärda vissa defekter i annan funktionalitet. Vanligt använda metoder för regressionstestning inkluderar omkörningar av tidigare tester, samt att kontrollera om regressionsbuggar kom in i nästa version som ett resultat av kodsammanslagning.
Från erfarenhet av mjukvaruutveckling är det känt att det upprepade uppträdandet av samma fel är ett ganska vanligt fall. Ibland beror detta på svag versionskontrollteknik eller på mänskliga fel i versionskontrollen . Men lika ofta är lösningen på ett problem "kortlivad": efter nästa ändring i programmet slutar lösningen att fungera. Och slutligen, när du skriver om någon del av koden, dyker ofta samma fel upp som var i den tidigare implementeringen.
Därför anses det vara god praxis när du åtgärdar en bugg att skapa ett test för det och köra det regelbundet med efterföljande ändringar av programmet. Även om regressionstestning kan göras manuellt, görs det oftast med hjälp av specialiserade program som låter dig utföra alla regressionstester automatiskt . Vissa projekt använder till och med verktyg för att automatiskt köra regressionstester vid ett givet tidsintervall. Detta görs vanligtvis efter varje lyckad sammanställning (i små projekt) antingen varje kväll eller varje vecka.
Regressionstestning är en integrerad del av Extreme Programmering . Denna metodik ersätter designdokumentation med utbyggbar, repeterbar och automatiserad testning av hela mjukvarupaketet i varje steg av mjukvaruutvecklingsprocessen .
Regressionstestning kan användas inte bara för att kontrollera ett programs korrekthet, det används ofta även för att utvärdera kvaliteten på resultatet. Så när man utvecklar en kompilator , när man kör regressionstester, beaktas storleken på den resulterande koden, hastigheten på dess exekvering och kompileringstiden för vart och ett av testfallen.
I sin artikel tillhandahåller S. Yoo och M. Harman [1] följande klassificering av regressionstestning:
Uppsättningsminimeringstestet försöker minska storleken på testsetet genom att eliminera testfall från testsetet baserat på ett givet kriterium. Det finns tre tillvägagångssätt, varav den första använder automatisk säkerhetstestning för att upptäcka sårbarheter genom att undersöka applikationsfel som kan upptäcka känd skadlig programvara som virus eller maskar. Detta tillvägagångssätt betraktar endast misslyckade tester från den tidigare versionen som ska köras om i den nya versionen av systemet efter att problemet har åtgärdats.
Ett annat tillvägagångssätt är utformat för att upptäcka och åtgärda sårbarheter i mindre versioner av webbapplikationer. Den skapar en hård länk till sidorna i den tidigare versionen med iteratorer som är valda för att undersöka webbsidor som innehåller sårbarheter.
Och slutligen erbjuder den tredje metoden testning med självanpassning av systemet för redan kända fel. Författarna undviker att reproducera redan kända buggar genom att endast överväga de tester som ska köras som avslöjade kända fel i tidigare versioner.
Prioriteringstestproblemet handlar om att beställa testerna rätt, vilket maximerar önskade egenskaper, såsom tidig upptäckt av fel. Dessutom tar nuvarande prioriteringsstrategier endast hänsyn till sårbarheter.
En metod erbjuder felbaserade prioritetstester som direkt utnyttjar kunskapen om deras förmåga att upptäcka fel.
Den andra erbjuder ett utbytbart inspelningsuppspelningssystem som låter dig skriva om den inspelade, körda versionen av applikationen till en ny, modifierad. Deras exekvering prioriteras på grund av att man bestämmer den optimala modifierade omskrivningen baserat på kostnadsfunktionen och mäter skillnaden mellan den ursprungliga exekveringen och den modifierade vid ett nytt försök.
Urvalsmetoden låter dig välja en delmängd eller alla testfall för att testa de ändrade delarna av programvaran. Följande tillvägagångssätt testar både säkerhetsmekanismer och sårbarheter.
Regressionstestning utförs när ändringar görs i befintlig funktionalitet i programvaran eller om det finns en buggfix i programvaran. Regressionstestning kan implementeras genom flera tillvägagångssätt. Att klara alla tester framgångsrikt av det modifierade programmet ger förtroende för att de ändringar som görs i programvaran inte påverkar den befintliga funktionaliteten, som bör vara oförändrad i alla fall.
I en agil projektledningsprocess där mjukvaruutvecklingens livscykel är mycket kort, resurserna är knappa och mjukvaruförändringar görs mycket ofta. Regressionstestning kan leda till mycket onödiga omkostnader.
Vanligtvis görs regressionstestning med hjälp av automationsverktyg, men den nuvarande generationen av regressionstestverktyg är inte utformade för att hantera databasapplikationer. Av denna anledning, när man kör ett regressionstest på applikationer som använder databaser, kan det finnas en oplanerad kostnad eftersom det kräver mycket manuellt arbete.
Ett grundläggande problem i mjukvaruunderhåll är att det är hög sannolikhet (20-50%) att fixa en bugg att en ny dyker upp. Därför följer hela processen principen om "två steg framåt, ett steg tillbaka."
Varför kan vi inte åtgärda fel mer exakt? För det första visar sig även en dold defekt som ett misslyckande på ett ställe. I verkligheten har det ofta konsekvenser i hela systemet, vanligtvis inte uppenbart. Varje försök att fixa det med minimal ansträngning kommer att fixa det som är lokalt och uppenbart, men om inte strukturen är mycket tydlig eller dokumentationen är mycket bra, kommer de långsiktiga effekterna av denna fix att förbli obemärkta. För det andra åtgärdas fel vanligtvis inte av författaren till programmet, utan ofta av en junior programmerare eller praktikant.
På grund av introduktionen av nya buggar, kräver programunderhåll mycket mer systemfelsökning per programsats än någon annan form av programmering. Teoretiskt sett måste du efter varje fix köra hela uppsättningen testfall som systemet kontrollerades mot tidigare, för att säkerställa att det inte har skadats på något obegripligt sätt. I praktiken borde sådana bakåtspårningstestning (regression) verkligen närma sig detta teoretiska ideal, och det är mycket kostsamt.
- F. Brooks Den mytiska manmånaden eller hur mjukvarusystem skapas [2]