Hvad er regressionstest?

Hvad er regressionstest?

Regressionstest er defineret som en type softwaretest for at bekræfte, at en nylig program- eller kodeændring ikke har påvirket eksisterende funktioner negativt. Vi kan også sige, at det ikke er andet end et helt eller delvist udvalg af allerede udførte testcases, der genudføres for at sikre, at eksisterende funktionaliteter fungerer fint.

Denne type test udføres for at sikre, at nye kodeændringer ikke har nogen bivirkninger på de eksisterende funktionaliteter. Det sikrer, at den gamle kode stadig fungerer, når de seneste kodeændringer er udført.

👉 Tilmeld dig gratis live regressionstestprojekt

Hvorfor regressionstest?

Regressionstestprocessen er vigtig i testomfanget. Da det kan identificere, om kodeændringer eller -forbedringer introducerer nye defekter eller forstyrrer eksisterende funktionelle tests.

Uden en regressionstestproces kan selv mindre kodeændringer have en chance for at føre til dyre fejl. Det er derfor en systematisk praksis at hjælpe med at opretholde softwarekvaliteten. Denne metode hjælper med at forhindre gentagelse af kendte problemer og øger tilliden til softwaren.

Hvornår kan vi udføre regressionstest?

Her er scenarierne, når du kan anvende regressionstestprocessen.

Ny funktionalitet tilføjes til applikationen: Dette sker, når nye funktioner eller moduler oprettes i en app eller et websted. Regressionen udføres for at se, om de eksisterende funktioner fungerer som normalt med introduktionen af ​​den nye funktion.

Ved ændringskrav: Når der sker en væsentlig ændring i systemet, anvendes regressionstest. Denne test er udført for at kontrollere, om disse skift har påvirket funktioner, der var der.

Efter at en defekt er rettet: Udviklerne udfører regressionstest efter at have rettet en fejl i enhver funktionalitet. Dette gøres for at afgøre, om de ændringer, der blev foretaget, mens fejlen blev rettet, har påvirket andre relaterede eksisterende funktioner.

Når ydeevneproblemet er løst: Efter at have rettet eventuelle ydeevneproblemer, udløses regressionstestprocessen for at se, om den har påvirket andre eksisterende funktionelle tests.

Under integration med et nyt eksternt system: End-to-end regressionstestproces er påkrævet, når produktet integreres med et nyt eksternt system.

Sådan laver du regressionstest i softwaretest

Som vi diskuterede før, udløses regressionstest baseret på enhver ændring af softwaren. Det kan være en fejlrettelse, integration af nye funktioner og så videre. Når et sådant arbejde sker, udfører QA-teamet følgende aktiviteter, der er angivet nedenfor. Disse opgaver udføres, før de starter regressionstestens udførelsescyklus.

• Diskuter med udviklingsteamet om de specifikke moduler og biblioteker, der blev berørt under ændringen
• Diskuter med produktejeren om ændringen af ​​den nye funktion og lær, hvordan den flyder på tværs af eller påvirker anden funktionalitet.
• Identificer testene fra den eksisterende testpakke, som testerne skal udføre for at regressere de eksisterende funktioner.

Forskellige regressionstestteknikker kan udføres til effektiv kvalitetssikring af software:

Gentest alle

Dette er en af ​​metoderne til regressionstestning, der specifikt anvender en regressionstestpakke. I dette tilfælde skal alle testene i den eksisterende testspand eller -suite genudføres. Dette er en dyr metode, da den kræver meget tid og ressourcer.

Valg af regressionstest

Regression Test Selection er en teknik, hvor nogle udvalgte testcases fra en testsuite udføres. Det hjælper med at teste, om den ændrede kode påvirker softwareapplikationen eller ej. Her er testcases kategoriseret i to dele. De genanvendelige testcases kan bruges i yderligere regressionscyklusser, mens forældede testcases ikke kan bruges i efterfølgende cyklusser.

Prioritering af Test Cases

Prioritering af testcases afhænger af forretningspåvirkningen, kritikaliteten og hyppigt anvendte funktionstests. Desuden reducerer prioritering af testcases baseret på prioritet i høj grad indsatsen for at udføre regressionstests.

Valg af testcases til regressionstest

Det blev fundet ud fra branchedata, at en god del af de defekter, som kunderne rapporterede, skyldtes sidste øjebliks fejlrettelser. Dette resulterede i bivirkninger, og derfor valgte man Test Cases for regressionstest er ikke en nem opgave.

En effektiv regressionstestsuite kan bygges ved at vælge følgende typer testcases –

• Testcases fra funktionaliteter/moduler, der har hyppige defekter.
• Funktioner, der er mere synlige for brugerne
• Testcases, der verificerer produktets kerneegenskaber
• Testcases af funktionaliteter, der har gennemgået nyere ændringer.
• Alle integrationstesttilfælde
• Alle komplekse testcases
• Grænseværdi testcases
• Udvalgt glad vej og negative testcases

Værktøjer til regressionstest

Hvis din software gennemgår hyppige ændringer, vil omkostningerne til regressionstest eskalere. Da manuel udførelse af testcases øger testudførelsestiden såvel som omkostningerne. Automatisering af regressionstesttilfælde er det smarte valg i sådanne tilfælde. Omfanget af automatisering afhænger af antallet af testcases, der forbliver genanvendelige i successive regressionscyklusser.

Følgende er de vigtigste værktøjer, der bruges til både funktionel og regressionstestautomatisering i softwareudvikling:

1) testRigor

testRigor hjælper dig med direkte at udtrykke test som eksekverbare specifikationer på almindeligt engelsk. Brugere af alle tekniske evner kan bygge ende-til-ende-test af enhver kompleksitet, der dækker mobil-, web- og API-trin. Testtrin udtrykkes på slutbrugerniveau i stedet for at stole på detaljer om implementering som XPaths eller CSS Selectors.

Funktioner:

• Gratis for evigt offentlig version
• Testcases er på engelsk
• Ubegrænsede brugere og ubegrænsede tests
• Den nemmeste måde at lære automatisering på
• Optager til web-trin
• Integrationer med CI/CD og Test case management
• E-mail og SMS test
• Web + mobil + API-trin i én test

Besøg testRigor >>

Selenium: Selenium er det mest brugte open source-værktøj, der bruges til at automatisere webapplikationer. Selenium kan bruges til browserbaseret regressionstest. Den understøtter programmeringssprog som f.eks Java, Rubin, PythonOsv

Hurtig test professionel (QTP): HP Quick Test Professional er automatiseret software designet til at automatisere funktions- og regressionstestsager. Det bruger VB Script sprog til automatisering. Det er et datadrevet, søgeordsbaseret værktøj.

Rational Functional Tester (RFT): IBM's rationelle funktionstester er en Java værktøj, der bruges til at automatisere testcases af softwareapplikationer. Dette bruges primært til at automatisere regressionstestsager, og det integreres også med Rational Test Manager.

Typer af regressionstest

Her er de forskellige former for regressionstest:

1) Enhedsregressionstest (URT)

Dette er en meget fokuseret tilgang, hvor kun det modificerede afsnit går under regressionstesten i stedet for nedslagsområdet. På denne måde forbliver de andre dele af modulet upåvirkede.

Eksempel

Som en for eksempel i Build 1 blev et problem fundet og rapporteret til udvikleren.

Lad os sige, at det var en fejl i login-funktionaliteten. Så udvikleren retter det, tilføjer fejlrettelsen i Build 2 og sender den. Testteamet kontrollerer kun, om login-funktionen fungerer som forventet i stedet for at kontrollere andre funktioner.

2) Regional regressionstest (RRT)

Ved regional regressionstestning testes modifikations- og påvirkningsområderne. Dette område undersøges for at finde ud af, om nogen pålidelige moduler kan blive påvirket af ændringerne.

Eksempel: I dette eksempel, i den første build, sendes modulerne A, B, C og D til test af udvikleren. Testeren finder fejl i modul B, så applikationen returneres til udvikleren for at rette fejlene.

Når udvikleren har rettet fejlene i den anden build i modul B, sendes den til testingeniøren igen. Testingeniøren erfarer, at fiksering af modul B har påvirket A og C.

Derfor kontrollerer testeren modul B's modifikationer i den anden udgivelse. Tester derefter påvirkningsområderne i A og C for at identificere, hvordan de er blevet påvirket.

Bemærk: Under regressionstestning er der et muligt problem, at dette problem nedenfor kan opstå.

problem:

• I build 1 beder kunderne normalt om ændringer, modifikationer og tilføjede funktioner.
• Denne anmodning sendes derefter til både udviklings- og testteamet.
• Udviklingsteamet foretager derefter ændringerne. Derefter sender testingeniøren en e-mail til klienten og informerer dem om de områder, ændringen vil påvirke.
• Testlederen samler derefter de berørte områders liste fra klienten, udviklerne og testafdelingen.
• Nedslagslisten sendes derefter til testingeniørerne, som starter regressionstestning.

Denne type testmetode skaber kommunikationshuller. Udviklerne og kunderne kan ikke altid vende tilbage til e-mails; der er derfor ikke et ordentligt overblik over påvirkningsområdet.

Opløsning: For at fjerne denne form for problemer kan testteamet arrangere et møde, når den nye build kommer efter fejlrettelser, nye funktioner og ændringer. Dette møde vil blive afholdt for at diskutere, om modulerne er berørt af ændringerne.

Der vil være en testrunde for at finde påvirkninger, så de kan lave en påvirkningsliste. Testledningen tilføjer det maksimale antal områder i påvirkningsområdet på denne liste.

Nedenfor kan du se, hvordan processen vil se ud:

• "Byg verifikationstest" for at kontrollere applikationens hovedfunktioner.
• Test af alle nye funktioner.
• Undersøgelse af ændrede eller modificerede funktioner.
• Gentest af fejl.
• Så, endelig, analyse af påvirkningsområde ved hjælp af regional regressionstest.

3) Fuld regressionstest (FRT):

Denne test dækker alle funktionerne i en applikation. Fuld regressionstest udføres normalt i senere udgivelser. Således kan du bruge FRT efter de første par udgivelser og som den sidste test før lancering.

I den anden eller tredje build kan kunden eller virksomhedsejeren bede om ændringer. De kan også kræve nye funktionaliteter og eller rapportere mangler. Testteamet udfører derefter konsekvensanalyse, foretager alle ændringerne og udfører en endelig komplet produkttest.

For eksempel er 4. build den endelige udgivelse før lanceringen. Så i denne build udfører testteamet en komplet test eller gentest af produktet i stedet for kun påvirkningsområdet eller en funktion. Dette gøres efter ændringerne og testene i build 1, 2 og 3.

For at udføre fuldstændig regressionstest skal du overveje disse omstændigheder:

• Ændringer udføres på applikationens kernekomponenter. For eksempel, hvis der er en ændring i en rodfil af en app eller kernemoduler, skal hele applikationen regresseres. Hvis der er foretaget mange ændringer.

4) Korrigerende regressionstest:

Denne test udføres, når der ikke foretages ændringer i funktionerne. Sådanne tests kan udføres med eksisterende tilfælde.

5) Gentest alle regressionstest:

I denne form for test bliver alle mindre til større ændringer foretaget i applikationen fra oprindelsen eller build 1 gentestet.

Denne test udføres, når alle andre regressionstest ikke kan identificere årsagen til problemerne.

6) Selektiv regressionstest:

Dette udføres for at kontrollere, hvordan koden reagerer, når en ny kode føjes til programmet. For at udføre denne test bruges et undersæt fra eksisterende cases for at gøre det effektivt og omkostningseffektivt. Kriterier for valg af et undersæt er baseret på de modificerede kodemoduler, afhængigheder, kritikaliteten af ​​den berørte funktionalitet og historiske defektdata.

7) Progressiv regressionstest:

Denne type regressionstest producerer vigtige output, når der foretages specifikke ændringer i programmet og nye testcases oprettes.

Det hjælper med at sikre, at ingen komponenter fra de ældre versioner er blevet påvirket i den seneste version.

8) Delvis regressionstest:

Delvis regressionstest bruges til at verificere, at nye kodeændringer eller -forbedringer ikke påvirker eksisterende funktionalitet negativt. Men i modsætning til en fuld regressionstest, som involverer gentest af hele applikationen, fokuserer vi i delvis regressionstest kun på specifikke dele af softwaren, der er påvirket af de seneste ændringer.

Derfor er det primære formål med delvis regressionstest at spare tid og ressourcer ved at undgå gentestning af uændrede dele af applikationen. Testcases til partiel regressionstestning er nøje udvalgt baseret på konsekvensanalysen af ​​kodeændringerne. Det er afgørende at identificere de korrekte testcases, der skal inkluderes i den delvise regressionstestsuite. Manglende kritiske testcases kan føre til oversete problemer.

Automatiseret regressionstest

Som tidligere nævnt er automatisering af regressionstest nødvendig, når der er flere udgivelser. Det er også nødvendigt for flere regressionscyklusser og adskillige gentagne aktiviteter. Da det er meget tidskrævende at udføre flere testcyklusser på tværs af udgivelser.

Med automatisering kan du dog teste flere gange. Dette kræver skrivning af automatiseringstestscripts til udførelse, som kræver relevant planlægning og design. I en sådan test kan teamet ikke direkte starte med automatisering. Derfor er vi nødt til at involvere både manuelle test- og automationstestteams for at dække dette omfang. Her er hvordan automatiseret regressionstest udføres:

Trin 1) Det manuelle testteam tjekker alle krav og identificerer påvirkningsområdet. Efter denne proces videresender de kravtestpakken til automationsteamet eller automationsingeniøren.

Trin 2) Det manuelle testteam begynder at teste de nye moduler, mens automationstestteamet skriver scriptet og automatiserer testcasen.

Trin 3) Før brug af denne metode til en regressionstest, identificerer automatiseringsteamet, hvilke cases der understøtter automatisering.

Trin 4) De konverterer disse regressionstests til scripts afhængigt af hvilke sager der kan automatiseres.

Trin 5) Under scripting-processen henviser automatiseringsteamet til regressionstestsagen. Det gør de, da de muligvis ikke besidder produktet eller værktøjet og app-viden.

Trin 6) Når testscripts er afsluttet, vil automatiseringsteamet udføre dem på den nye app.

Trin 7) Efter udførelsen informerer resultatet om testen var bestået eller ikke bestået.

Trin 8) Hvis testen mislykkes, kontrolleres den igen ved hjælp af den manuelle testmetode, og hvis problemet eksisterer, rapporteres det til den respektive udvikler.

Bemærk: Når fejlen er rettet, sendes problemet og nedslagsområdet til den manuelle tester til gentestning, og automatiseringsteamet genudfører scriptet.

Trin 9) Denne proces fortsætter, indtil alle de nyligt tilføjede regressionsfunktioner får en bestået status.

Her er fordelene ved automatiseret regressionstest:

• Genanvendelig: Dens testscripts kan genbruges på tværs af flere udgivelser.
• Nøjagtighed: Automatiseringsværktøjerne udfører opgaven redundant, hvilket reducerer risikoen for fejl.
• Sparer tid: Det er hurtigere end den manuelle funktionelle testproces og er tidseffektiv.
• Batchudførelse: Det er muligt at udføre alle scripts samtidigt og parallelt i automatiseret test.
• Ingen ressourceforøgelse nødvendig: Regressionstesten er forpligtet til at stige med hver ny udgivelse. Du behøver dog ikke tilføje nye ressourcer til automatisering.

Hvordan vælger man testcases til regressionstest?

Her er hvordan du kan vælge det rigtige tilfælde til regressionstest.

• Forstå omfanget af ændringerne, og find ud af, hvilke dele af programmet, der er blevet ændret, tilføjet eller rettet. Du kan derefter fokusere på disse områder til regressionstestning.
• Har en suite, der dækker den kritiske funktionalitet og fastholder denne som baseline for regressionstest. Som diskuteret tidligere, anbefales det stærkt at få disse tests automatiseret.
• Prioriter test baseret på funktionalitetens kritikalitet, indvirkning på slutbrugeren og historiske defektdata.

Regression Testing Bedste Practices

Nedenfor er et par nøglepraksis, som du bør følge, når du vedligeholder regressionstest.

Automatiser hvor det er muligt

Automatiseret regressionstest reducerer testindsatsen og giver mulighed for hurtig eksekvering af et stort antal testcases.

Kontinuerlig integration

Inkorporering af regressionstestning i CI/CD-pipelines sikrer, at tests automatisk køres, hver gang ændringer er forpligtet til kodebasen.

Valg af testtilfælde

Identificer og vedligehold en undergruppe af testcases, der repræsenterer kernefunktionalitet og højrisikoområder. Du kan også vælge dem, der er direkte relateret til de ændringer, der foretages, fordi det kan være upraktisk at køre alle tidligere testcases.

Regelmæssig udførelse

Udfør regressionstests regelmæssigt, især efter hver kodeændring. Dette hjælper med at identificere problemer tidligt i udviklingsprocessen.

Test Data Management

Sørg for, at testdata, der bruges til regressionstest, er konsistente og håndterbare, fordi datarelaterede problemer kan påvirke testresultater.

Miljøledelse

Oprethold konsistente og reproducerbare testmiljøer. Dette inkluderer brug af de samme operativsystemer, browsere og enhedskonfigurationer, der bruges i produktionen.

Optag og Track Defekter

Eventuelle fejl, der opdages under regressionstest, skal registreres. tracbehandlet og håndteret. Prioritér deres løsning baseret på sværhedsgrad.

Reus Evne

Opret genbrugelige testscripts og testdata for at reducere dobbeltarbejde og forbedre vedligeholdelsesmulighederne.

Regressionstest og konfigurationsstyring

Konfigurationsstyring under regressionstest bliver bydende nødvendigt i agile miljøer, hvor en kode løbende ændres. For at sikre effektive regressionstest skal du observere følgende:

• Code Regressionstestning bør foregå under et konfigurationsstyringsværktøj.
• Ingen ændringer må tillades at kode under regressionstestfasen. Regressionstestkoden skal holdes immun over for udviklerændringer.
• Den database, der bruges til regressionstest, skal være isoleret. Ingen databaseændringer må tillades

Forskellen mellem gentest og regressionstest

Gentestning betyder funktionel testning af defekten eller fejlen igen for at sikre, at koden er rettet. Hvis den ikke er rettet, skal defekten genåbnes. Hvis den er rettet, defekten er lukket.

Regressionstest betyder at teste din softwareapplikation, når den gennemgår en kodeændring. Det gøres for at sikre, at den nye kode ikke har påvirket andre dele af softwaren.

Her nedenfor er de primære forskelle mellem disse to tests:

efterprøvning	Regressionstest
Den er bygget specielt til fejlrettelser.	Regressionstest udføres hovedsageligt for at verificere, om kodeændringer har påvirket andre funktionaliteter.
Gentestning kontrollerer ikke de andre versioner og verificerer kun, om de ødelagte funktioner er gendannet.	Fokuserer på tidligere versioner, og den tester, om de tidligere funktioner stadig fungerer som forventet.
Hver test er specifik	Regression er en generisk test.
Denne test er for mislykkede testcases.	Det er for beståede testsager.
Den kontrollerer specifikke defekter, så den kan ikke automatiseres.	Kan automatiseres. Det anbefales også stærkt at blive automatiseret, som vi diskuterede tidligere.
Gentestning er ikke altid en del af en testcyklus, da det kun er nødvendigt, når der findes fejl.	Regression er altid en del af testning, da hver gang en kode ændres, skal denne test udføres for at forstå, om produktets funktionalitet er stabil.
Det er højt prioriteret test, da det fokuserer på kendte problemer.	Dette er test med lav prioritet, da det er overordnet test af mulige defekter.
Denne test er ikke tidskrævende, da den virker på en specifik defekt.	Da det involverer et stort område af softwaren, er det derfor tidskrævende.
Det bestemmer defekter med samme data og miljø med et andet input og en ny version.	Denne test kan hente sager fra brugermanualer, fejlrapporter og funktionelle specifikationer.
Gentestning kan ikke udføres uden den første test.	Det sker, når ændringer og modifikationer er obligatoriske i det eksisterende projekt.

Se også den komplette liste over forskelle link..

Fordele og ulemper ved regressionstest

Fordele

• Regressionstest forbedrer kvaliteten af ​​produkterne.
• Med denne test sikrer du, at ændringerne og fejlrettelserne ikke har ændret de eksisterende funktionaliteter og funktioner.
• Da regressionssenge køres på eksisterende funktioner, kan vi garantere, at ældre defekter også er dækket.
• Det letter effektiv produktudvikling.
• Du kan opnå høj brugertilfredshed med denne test på plads.
• Samlet set bevarer det softwarens stabilitet.

Ulemper

• Det bør udføres hver gang der foretages en lille ændring, da den mindste ændring kan give problemer i eksisterende moduler.
• Denne test kan være tidskrævende, når den udføres manuelt, hvilket kræver gentagne tests.

Udfordringer i regressionstest

Følgende er de største testproblemer for at udføre regressionstest:

• Med successive regressionskørsler bliver testsuiter ret store. På grund af tids- og budgetbegrænsninger kan hele regressionstestpakken ikke udføres
• Det er fortsat en udfordring at minimere testpakken og samtidig opnå maksimalt
• Det er en udfordring at bestemme hyppigheden af ​​regressionstests, dvs. efter hver ændring eller hver build-opdatering eller efter en masse fejlrettelser.

Praktisk anvendelse af eksempel på regressionstest med en video

Klik link. hvis videoen ikke er tilgængelig

Eksempel på regressionstest – Amazon

Overvej e-handelsgiganten Amazon, som er en multi-milliard-dollar virksomhed, der er afhængig af sin hjemmeside for at generere indtægter. For at opretholde dens funktionalitet, pålidelighed og ydeevne spiller regressionstest en afgørende rolle.

Lad os tage et scenario med tilføjelse af en ny produktkategori.

Imagine That Amazon beslutter at udvide sit produktudbud ved at introducere en ny kategori kaldet "Smart Home Devices" sammen med eksisterende kategorier som "Elektronik" og "Tøj."

Mulige regressionstilfælde ville være:

Hjemmesidefunktionalitet: Bekræft, at hjemmesiden viser den nye kategori "Smart Home Devices" sammen med eksisterende enheder uden visningsproblemer.

Kategorinavigation: Sørg for, at brugerne problemfrit kan navigere til kategorisiden "Smart Home Devices" og vende tilbage til hjemmesiden uden problemer.

Søgefunktioner: Sørg for, at søgefeltet returnerer nøjagtige resultater for smart home-enheder, når brugerne søger efter dem, og ikke blandes med andre produkter.

Brugerkonti: Bekræft, at brugerkonti kan oprettes, opdateres og bruges til køb af smart home-enheder og andre produkter.

Betalingsbehandling: Test betalingsgateways specifikke for køb og garanter sikre og fejlfri transaktioner.

Mobil reaktionsevne: Sørg for, at hjemmesiden forbliver mobilvenlig, så brugerne kan få adgang til og købe smart home-enheder på forskellige enheder.

Hvis nogen af ​​disse regressionstestsager mislykkes, indikerer det et problem med hjemmesidens eksisterende funktionalitet på grund af tilføjelsen af ​​den nye produktkategori. Dette problem bør dokumenteres og løses med det samme. Derudover, som Amazon fortsætter med at udvide sine tilbud og foretage ændringer på sin hjemmeside, bør disse regressionstests udføres for at opretholde en pålidelig onlinebutikping erfaring. Automatiserede testværktøjer kan strømline denne proces.

Ofte Stillede Spørgsmål