Hva er regresjonstesting?

Hva er regresjonstesting?

Regresjonstesting er definert som en type programvaretesting for å bekrefte at et nylig program eller kodeendring ikke har påvirket eksisterende funksjoner negativt. Vi kan også si at det ikke er annet enn et helt eller delvis utvalg av allerede utførte testtilfeller som kjøres på nytt for å sikre at eksisterende funksjonalitet fungerer bra.

Denne typen testing gjøres for å sikre at nye kodeendringer ikke har noen bivirkninger på eksisterende funksjonalitet. Det sikrer at den gamle koden fortsatt fungerer når de siste kodeendringene er gjort.

👉 Meld deg på gratis live regresjonstestingsprosjekt

Hvorfor regresjonstesting?

Regresjonstesting er viktig i testomfanget. Siden den kan identifisere om kodeendringer eller forbedringer introduserer nye defekter eller forstyrrer eksisterende funksjonstester.

Uten en regresjonstestprosess kan selv mindre kodeendringer ha en sjanse til å føre til kostbare feil. Det er derfor en systematisk praksis for å opprettholde programvarekvaliteten. Denne metoden bidrar til å forhindre gjentakelse av kjente problemer og øker tilliten til programvaren.

Når kan vi utføre regresjonstesting?

Her er scenariene når du kan bruke regresjonstestprosessen.

Ny funksjonalitet er lagt til applikasjonen: Dette skjer når nye funksjoner eller moduler opprettes i en app eller et nettsted. Regresjonen utføres for å se om de eksisterende funksjonene fungerer som vanlig med introduksjonen av den nye funksjonen.

Ved endringskrav: Når det skjer en betydelig endring i systemet, brukes regresjonstesting. Denne testen er gjort for å sjekke om disse skiftene har påvirket funksjoner som var der.

Etter at en defekt er rettet: Utviklerne utfører regresjonstesting etter å ha fikset en feil i en hvilken som helst funksjonalitet. Dette gjøres for å finne ut om endringene som ble gjort mens du fikset feilen, har påvirket andre relaterte eksisterende funksjoner.

Når ytelsesproblemet er løst: Etter å ha fikset eventuelle ytelsesproblemer, utløses regresjonstestprosessen for å se om den har påvirket andre eksisterende funksjonstester.

Mens du integrerer med et nytt eksternt system: End-to-end regresjonstesting er nødvendig når produktet integreres med et nytt eksternt system.

Hvordan gjøre regresjonstesting i programvaretesting

Som vi diskuterte tidligere, utløses regresjonstesting basert på enhver endring som er gjort i programvaren. Det kan være en feilretting, integrering av nye funksjoner og så videre. Når slikt arbeid skjer, utfører QA-teamet følgende aktiviteter gitt nedenfor. Disse oppgavene utføres før de starter utførelsessyklusen for regresjonstesten.

• Diskuter med utviklingsteamet om de spesifikke modulene og bibliotekene som ble berørt under endringen
• Diskuter med produkteieren om endringen til den nye funksjonen og finn ut hvordan den flyter på tvers av eller påvirker annen funksjonalitet.
• Identifiser testene fra den eksisterende testpakken som testerne må utføre for å regressere de eksisterende funksjonene.

Ulike regresjonstestteknikker kan utføres for effektiv kvalitetssikring av programvare:

Test alle på nytt

Dette er en av metodene for regresjonstesting, spesielt ved å bruke en regresjonstestpakke. I dette tilfellet bør alle testene i den eksisterende testbøtten eller suiten utføres på nytt. Dette er en kostbar metode da den krever mye tid og ressurser.

Valg av regresjonstest

Regresjonstestutvelgelse er en teknikk der noen utvalgte testtilfeller fra en testpakke utføres. Det hjelper å teste om den endrede koden påvirker programvaren eller ikke. Her er testcaser kategorisert i to deler. De gjenbrukbare testtilfellene kan brukes i ytterligere regresjonssykluser, mens foreldede testtilfeller ikke kan brukes i påfølgende sykluser.

Prioritering av Test Cases

Prioritering av testtilfellene avhenger av forretningseffekten, kritikaliteten og ofte brukte funksjonstester. Dessuten reduserer prioritering av testtilfeller basert på prioritet innsatsen med å utføre regresjonstester.

Valg av testtilfeller for regresjonstesting

Det ble funnet fra bransjedata at en god del av defektene som ble rapportert av kunder, skyldtes feilrettinger i siste liten. Dette resulterte i bivirkninger, og derfor valgte man test Cases for regresjonstesting er ikke en lett oppgave.

En effektiv regresjonstestpakke kan bygges ved å velge følgende typer testtilfeller –

• Testtilfeller fra funksjonaliteter/moduler som har hyppige feil.
• Funksjoner som er mer synlige for brukerne
• Testtilfeller som bekrefter kjernefunksjonene til produktet
• Testtilfeller av funksjoner som har gjennomgått nyere endringer.
• Alle integrasjonstesttilfeller
• Alle komplekse testsaker
• Grenseverditestsaker
• Valgt lykkelig vei og negative testtilfeller

Verktøy for regresjonstesting

Hvis programvaren din gjennomgår hyppige endringer, vil kostnadene for regresjonstesting eskalere. Ettersom manuell utførelse av testtilfeller øker testgjennomføringstiden så vel som kostnadene. Automatisering av regresjonstesttilfeller er det smarte valget i slike tilfeller. Omfanget av automatisering avhenger av antall testtilfeller som forblir gjenbrukbare for påfølgende regresjonssykluser.

Følgende er de viktigste verktøyene som brukes for både funksjonell og regresjonstestautomatisering i programvareteknikk:

1) testRigor

testRigor hjelper deg å uttrykke tester direkte som kjørbare spesifikasjoner på vanlig engelsk. Brukere med alle tekniske ferdigheter kan bygge ende-til-ende-tester av enhver kompleksitet som dekker mobil-, nett- og API-trinn. Testtrinn uttrykkes på sluttbrukernivå i stedet for å stole på detaljer om implementering som XPaths eller CSS Selectors.

Egenskaper:

• Gratis for alltid offentlig versjon
• Testtilfeller er på engelsk
• Ubegrenset antall brukere og ubegrensede tester
• Den enkleste måten å lære automatisering på
• Opptaker for webtrinn
• Integrasjoner med CI/CD og Test case management
• E-post og SMS testing
• Web + mobil + API-trinn i én test

Besøk testRigor >>

Selenium: Selenium er det mest brukte åpen kildekodeverktøyet som brukes til å automatisere webapplikasjoner. Selenium kan brukes til nettleserbasert regresjonstesting. Den støtter programmeringsspråk som f.eks JavaRubin, PythonOsv

Hurtigtest Profesjonell (QTP): HP Quick Test Professional er automatisert programvare utviklet for å automatisere funksjons- og regresjonstesttilfeller. Den bruker VB Script-språk for automatisering. Det er et datadrevet, nøkkelordbasert verktøy.

Rasjonell funksjonstester (RFT): IBMsin rasjonelle funksjonstester er en Java verktøy som brukes til å automatisere testtilfeller av programvareapplikasjoner. Dette brukes først og fremst for å automatisere regresjonstesttilfeller, og det integreres også med Rational Test Manager.

Typer regresjonstesting

Her er de forskjellige typene regresjonstesting:

1) Enhetsregresjonstesting (URT)

Dette er en veldig fokusert tilnærming der kun den modifiserte delen går under regresjonstesten i stedet for nedslagsregionen. På denne måten forblir de andre delene av modulen upåvirket.

Eksempel

Som en eksempel, i Build 1 ble et problem funnet og rapportert til utvikleren.

La oss si at det var en feil i påloggingsfunksjonen. Så utvikleren fikser det, legger til feilrettingen i Build 2 og sender den. Testteamet sjekker bare om påloggingsfunksjonen fungerer som forventet i stedet for å sjekke andre funksjoner.

2) Regional regresjonstesting (RRT)

I regional regresjonstesting testes modifikasjons- og påvirkningsområdene. Dette området undersøkes for å finne ut om noen pålitelige moduler kan bli påvirket av endringene.

Eksempel: I dette eksemplet, i den første bygningen, sendes modulene A, B, C og D for testing av utvikleren. Testeren finner feil i modul B, så applikasjonen returneres til utvikleren for å fikse feilene.

Når utvikleren fikser feilene i den andre bygningen i modul B, sendes den til testingeniøren igjen. Testingeniøren får vite at fikseringsmodul B har påvirket A og C.

Derfor sjekker testeren modul Bs modifikasjoner i den andre utgivelsen. Deretter tester du også innvirkningsområdene i A og C for å identifisere hvordan de har blitt påvirket.

OBS: Under regresjonstesting er det et mulig problem at dette problemet nedenfor kan oppstå.

problem:

• I bygg 1 ber kundene vanligvis om endringer, modifikasjoner og ekstra funksjoner.
• Denne forespørselen sendes så til både utviklings- og testteamet.
• Utviklingsteamet gjør deretter endringene. Deretter sender testingeniøren en e-post til klienten og informerer dem om områdene endringen vil påvirke.
• Testlederen samler deretter de berørte områdenes liste fra klienten, utviklerne og testavdelingen.
• Påvirkningslisten sendes deretter til testingeniørene, som starter regresjonstesting.

Denne typen testmetoder skaper kommunikasjonshull. Utviklerne og kundene kan ikke alltid gå tilbake til e-postene; derfor er det ingen ordentlig oversikt over nedslagsområdet.

Løsning: For å fjerne denne typen problemer, kan testteamet arrangere et møte når den nye konstruksjonen kommer etter feilrettinger, nye funksjoner og modifikasjoner. Dette møtet vil bli holdt for å diskutere om modulene er berørt på grunn av modifikasjonene.

Det blir en testrunde for å finne påvirkninger slik at de kan lage en påvirkningsliste. Testledningen legger til det maksimale antallet områder i innvirkningsområdet i denne listen.

Her er hvordan prosessen vil se ut:

• "Byggeverifiseringstest" for å sjekke hovedfunksjonene til applikasjonen.
• Testing av alle nye funksjoner.
• Undersøker endrede eller modifiserte funksjoner.
• Retesting av feil.
• Så, til slutt, konsekvensområdeanalyse ved hjelp av regional regresjonstesting.

3) Full regresjonstesting (FRT):

Denne testen dekker alle funksjonene til en applikasjon. Full regresjonstesting utføres vanligvis i senere utgivelser. Dermed kan du bruke FRT etter de første utgivelsene og som den siste testen før lansering.

I det andre eller tredje bygget kan kunden eller bedriftseieren be om endringer. De kan også kreve nye funksjoner og eller rapportere mangler. Testteamet gjennomfører deretter konsekvensanalyse, gjør alle modifikasjoner og utfører en siste komplett produkttest.

For eksempel er den fjerde versjonen den endelige utgivelsen før lanseringen. Så i denne konstruksjonen utfører testteamet en fullstendig test eller retest av produktet i stedet for bare nedslagsområdet eller en funksjon. Dette gjøres etter modifikasjonene og testene i bygg 4, 1 og 2.

For å utføre fullstendig regresjonstesting, må du vurdere disse omstendighetene:

• Endringer utføres på applikasjonens kjernekomponenter. For eksempel, hvis det er en endring i en rotfil til en app eller kjernemoduler, må hele applikasjonen regresseres. Hvis det er gjort mange endringer.

4) Korrigerende regresjonstesting:

Denne testen utføres når det ikke er gjort noen endringer i funksjonene. Slike tester kan utføres med eksisterende tilfeller.

5) Test all regresjonstesting på nytt:

I denne formen for testing testes alle mindre til større endringer som er gjort i applikasjonen fra opprinnelsen eller build 1.

Denne testen utføres når alle andre regresjonstester ikke klarer å identifisere årsaken til problemene.

6) Selektiv regresjonstesting:

Dette er utført for å sjekke hvordan koden reagerer når en ny kode legges til programmet. For å gjennomføre denne testen brukes et undersett fra eksisterende case for å gjøre det effektivt og kostnadseffektivt. Kriterier for å velge et delsett er basert på de modifiserte kodemodulene, avhengigheter, kritikaliteten til den berørte funksjonaliteten og historiske defektdata.

7) Progressiv regresjonstesting:

Denne typen regresjonstesting gir viktige resultater når det gjøres spesifikke endringer i programmet og nye testtilfeller opprettes.

Det bidrar til å sikre at ingen komponenter fra de eldre versjonene har blitt påvirket i den nyeste versjonen.

8) Delvis regresjonstesting:

Delvis regresjonstesting brukes til å bekrefte at nye kodeendringer eller forbedringer ikke påvirker eksisterende funksjonalitet negativt. I motsetning til en full regresjonstest, som innebærer å teste hele applikasjonen på nytt, fokuserer vi i delvis regresjonstesting kun på spesifikke deler av programvaren som er påvirket av de siste endringene.

Derfor er det primære formålet med delvis regresjonstesting å spare tid og ressurser ved å unngå retesting av uendrede deler av applikasjonen. Testtilfeller for delvis regresjonstesting er nøye utvalgt basert på konsekvensanalysen av kodeendringene. Det er avgjørende å identifisere de riktige testtilfellene som skal inkluderes i testpakken for delvis regresjon. Manglende kritiske testtilfeller kan føre til oversett problemer.

Automatisert regresjonstesting

Som nevnt tidligere, er det nødvendig å automatisere regresjonstester når det er flere utgivelser. Det er også nødvendig for flere regresjonssykluser og mange repeterende aktiviteter. Siden det er svært tidkrevende å utføre flere testsykluser på tvers av utgivelser.

Men med automatisering kan du teste flere ganger. Dette krever skriving av automatiseringstestskript for utførelse, som krever relevant planlegging og design. I slik testing kan ikke teamet starte direkte med automatisering. Derfor må vi involvere både manuell testing og automatiseringstestteam for å dekke dette omfanget. Her er hvordan automatisert regresjonstesting utføres:

Trinn 1) Det manuelle testteamet sjekker alle krav og identifiserer innvirkningsregionen. Etter denne prosessen videresender de kravtestbunten til automasjonsteamet eller automasjonsingeniøren.

Trinn 2) Det manuelle testteamet begynner å teste de nye modulene mens automasjonstestteamet skriver skriptet og automatiserer testsaken.

Trinn 3) Før du bruker denne metoden for en regresjonstest, identifiserer automasjonsteamet hvilke saker som vil støtte automatisering.

Trinn 4) De konverterer disse regresjonstestene til skript avhengig av hvilke saker som kan automatiseres.

Trinn 5) Under skriptprosessen refererer automasjonsteamet til regresjonstestsakene. De gjør det fordi de kanskje ikke har produktet eller kunnskapen om verktøyet og appen.

Trinn 6) Når testskriptene er fullført, vil automatiseringsteamet kjøre dem på den nye appen.

Trinn 7) Etter gjennomføringen informerer resultatet om testen var bestått eller ikke bestått.

Trinn 8) Hvis testen mislykkes, sjekkes den på nytt ved hjelp av den manuelle testmetoden, og hvis problemet eksisterer, rapporteres det til den respektive utvikleren.

OBS: Etter at feilen er fikset, sendes problemet og nedslagsområdet til den manuelle testeren for retesting, og automatiseringsteamet kjører skriptet på nytt.

Trinn 9) Denne prosessen fortsetter til alle de nylig lagt til regresjonsfunksjonene får en Pass-status.

Her er fordelene med automatisert regresjonstesting:

• Gjenbruk: Testskriptene kan gjenbrukes på tvers av flere utgivelser.
• Nøyaktighet: Automatiseringsverktøyene utfører oppgaven redundant, og reduserer sjansen for feil.
• Sparer tid: Det er raskere enn den manuelle funksjonelle testprosessen og er tidseffektiv.
• Batchutførelse: Det er mulig å kjøre alle skriptene samtidig og parallelt i automatisert testing.
• Ingen ressursøkning nødvendig: Regresjonstesten vil garantert øke med hver ny utgivelse. Du trenger imidlertid ikke legge til nye ressurser for automatisering.

Hvordan velge testtilfeller for regresjonstesting?

Her er hvordan du kan velge riktig tilfelle for regresjonstesting.

• Forstå omfanget av endringene og finn ut hvilke deler av programmet som har blitt endret, lagt til eller fikset. Du kan deretter fokusere på disse områdene for regresjonstesting.
• Ha en suite som dekker den kritiske funksjonaliteten og opprettholder denne som baseline for regresjonstesting. Som diskutert tidligere, anbefales det sterkt å ha disse testene automatisert.
• Prioriter tester basert på hvor kritisk funksjonaliteten er, innvirkning på sluttbrukeren og historiske defektdata.

Beste praksis for regresjonstesting

Nedenfor er noen viktige praksiser du bør følge når du opprettholder regresjonstester.

Automatiser der det er mulig

Automatisert regresjonstesting reduserer testinnsatsen og muliggjør rask utførelse av et stort antall testtilfeller.

Kontinuerlig integrasjon

Innlemming av regresjonstesting i CI/CD-rørledningene sikrer at tester kjøres automatisk hver gang endringer er forpliktet til kodebasen.

Valg av testtilfelle

Identifiser og vedlikehold et undersett av testtilfeller som representerer kjernefunksjonalitet og høyrisikoområder. Du kan også velge de som er direkte relatert til endringene som gjøres fordi det kan være upraktisk å kjøre alle tidligere testtilfeller.

Regelmessig utførelse

Utfør regresjonstester regelmessig, spesielt etter hver kodeendring. Dette hjelper til med å identifisere problemer tidlig i utviklingsprosessen.

Test Data Management

Sørg for at testdata som brukes til regresjonstester er konsistente og håndterbare fordi datarelaterte problemer kan påvirke testresultatene.

Miljøledelse

Oppretthold konsistente og reproduserbare testmiljøer. Dette inkluderer bruk av de samme operativsystemene, nettleserne og enhetskonfigurasjonene som brukes i produksjonen.

Ta opp og Track Defekter

Eventuelle feil som oppdages under regresjonstesting bør loggføres, tracbehandlet og håndtert. Prioriter løsningen basert på alvorlighetsgrad.

Reus Evne

Lag gjenbrukbare testskript og testdata for å redusere duplisering og forbedre vedlikeholdsevnen.

Regresjonstesting og konfigurasjonsadministrasjon

Konfigurasjonsadministrasjon under regresjonstesting blir avgjørende i smidige miljøer der en kode kontinuerlig endres. For å sikre effektive regresjonstester, observer følgende:

• Code Regresjonstesting bør gjøres via et konfigurasjonsstyringsverktøy.
• Ingen endringer må tillates å kode under regresjonstestfasen. Regresjonstestkoden må holdes immun mot utviklerendringer.
• Databasen som brukes til regresjonstesting må være isolert. Ingen databaseendringer må tillates

Forskjellen mellom retesting og regresjonstesting

Retesting betyr funksjonstesting av feilen eller buggen på nytt for å sikre at koden er fikset. Hvis den ikke er fikset, må feilen åpnes på nytt. Hvis den er fikset, defekten er stengt.

Regresjonstesting betyr å teste programvareapplikasjonen din når den gjennomgår en kodeendring. Det gjøres for å sikre at den nye koden ikke har påvirket andre deler av programvaren.

Her nedenfor er de primære forskjellene mellom disse to testene:

retesting	Regresjonstesting
Den er bygget spesielt for feilrettinger.	Regresjonstesting utføres hovedsakelig for å verifisere om kodeendringer har påvirket andre funksjoner.
Retesting sjekker ikke de andre versjonene og verifiserer bare om de ødelagte funksjonene er gjenopprettet.	Fokuserer på tidligere versjoner, og den tester om de tidligere funksjonene fortsatt fungerer som forventet.
Hver test er spesifikk	Regresjon er en generisk test.
Denne testen er for mislykkede testtilfeller.	Det er for beståtte testtilfeller.
Den sjekker spesifikke defekter, så den kan ikke automatiseres.	Kan automatiseres. Også sterkt anbefalt å være automatisert som vi diskuterte tidligere.
Retesting er ikke alltid en del av en testsyklus, da det bare er nødvendig når feil blir funnet.	Regresjon er alltid en del av testing, da hver gang en kode endres, må denne testen utføres for å forstå om produktfunksjonaliteten er stabil.
Det er høyprioritert testing da det fokuserer på kjente problemer.	Dette er lavprioritet testing, da det er totaltesting av mulige feil.
Denne testingen er ikke tidkrevende siden den fungerer på en spesifikk defekt.	Siden det involverer et stort område av programvaren, er det derfor tidkrevende.
Den bestemmer feil med samme data og miljø med en annen inngang og en ny versjon.	Denne testingen kan hente saker fra brukermanualer, feilrapporter og funksjonsspesifikasjoner.
Retesting kan ikke utføres uten den første testingen.	Det gjøres når endringer og modifikasjoner er obligatoriske i eksisterende prosjekt.

Sjekk også ut den komplette listen over forskjeller over her..

Fordeler og ulemper med regresjonstesting

Fordeler

• Regresjonstesting forbedrer kvaliteten på produktene.
• Med denne testen sikrer du at modifikasjonene og feilrettingene ikke har endret eksisterende funksjoner og funksjoner.
• Siden regresjonssenger kjøres på eksisterende funksjoner, kan vi garantere at eldre defekter også dekkes.
• Det legger til rette for effektiv produktutvikling.
• Du kan oppnå høy brukertilfredshet med denne testingen på plass.
• Totalt sett opprettholder det stabiliteten til programvaren.

Ulemper

• Det bør utføres hver gang en liten endring gjøres, da den minste endringen kan føre til problemer i eksisterende moduler.
• Denne testen kan være tidkrevende når den utføres manuelt, og krever gjentatt testing.

Utfordringer i regresjonstesting

Følgende er de viktigste testproblemene for å utføre regresjonstesting:

• Med påfølgende regresjonskjøringer blir testseriene ganske store. På grunn av tids- og budsjettbegrensninger kan ikke hele regresjonstestpakken kjøres
• Å minimere testpakken mens du oppnår maksimalt er fortsatt en utfordring
• Det er en utfordring å bestemme frekvensen av regresjonstester, dvs. etter hver modifikasjon eller hver byggeoppdatering eller etter en haug med feilrettinger.

Praktisk anvendelse av eksempel på regresjonstesting med en video

Klikk her. hvis videoen ikke er tilgjengelig

Eksempel på regresjonstesting – Amazon

Tenk på e-handelsgiganten Amazon, som er en virksomhet på flere milliarder dollar som er avhengig av nettstedet for inntektsgenerering. For å opprettholde funksjonaliteten, påliteligheten og ytelsen, spiller regresjonstesting en avgjørende rolle.

La oss ta et scenario med å legge til en ny produktkategori.

Tenk deg at Amazon bestemmer seg for å utvide produkttilbudet sitt ved å introdusere en ny kategori kalt "Smart Home Devices" sammen med eksisterende kategorier som "Elektronikk" og "Klær."

Mulige regresjonstilfeller vil være:

Hjemmesidefunksjonalitet: Bekreft at hjemmesiden viser den nye kategorien «Smart hjemmeenheter» sammen med eksisterende enheter uten visningsproblemer.

Kategorinavigasjon: Sørg for at brukerne enkelt kan navigere til kategorisiden «Smarte hjemmeenheter» og returnere til hjemmesiden uten problemer.

Søkefunksjonalitet: Sørg for at søkefeltet returnerer nøyaktige resultater for smarthjemenheter når brukere søker etter dem, og ikke blander dem med andre produkter.

Brukerkontoer: Bekreft at brukerkontoer kan opprettes, oppdateres og brukes til kjøp av smarthjem-enheter og andre produkter.

Betalings prosessering: Test betalingsportaler spesifikke for kjøp og garanter sikre og feilfrie transaksjoner.

Mobil respons: Sjekk at nettstedet er mobilvennlig, slik at brukerne kan få tilgang til og kjøpe smarthjem-enheter på ulike enheter.

Hvis noen av disse regresjonstesttilfellene mislykkes, indikerer det et problem med nettstedets eksisterende funksjonalitet på grunn av tillegget av den nye produktkategorien. Dette problemet bør dokumenteres og løses umiddelbart. I tillegg, som Amazon fortsetter å utvide tilbudet sitt og gjøre endringer på nettstedet sitt, bør disse regresjonstestene utføres for å opprettholde en pålitelig nettbutikkping erfaring. Automatiserte testverktøy kan effektivisere denne prosessen.

Spørsmål og svar