Hva er regresjonstesting? Definisjon, verktøy, metode og eksempel

what is regression testing

Hva er regresjonstesting?

Regresjonstesting er en type testing som gjøres for å verifisere at en kodeendring i programvaren ikke påvirker produktets eksisterende funksjonalitet. Dette er for å sikre at produktet fungerer bra med ny funksjonalitet, feilrettinger eller endringer i den eksisterende funksjonen. Tidligere utførte testsaker kjøres på nytt for å verifisere virkningen av endring.

=> Klikk her for fullstendig testplanopplæringsserie

Regresjonstesting er en programvaretestingstype der testtilfeller kjøres på nytt for å sjekke om den forrige funksjonaliteten til applikasjonen fungerer bra, og at de nye endringene ikke har introdusert noen nye feil.

Denne testen kan utføres på en ny versjon når det er en betydelig endring i den opprinnelige funksjonaliteten, også i en enkelt feilretting.

Regresjon betyr å teste de uendrede delene av applikasjonen.

Hva du vil lære:

• Veiledninger dekket i denne serien
• Oversikt over regresjonstest
• Når skal jeg utføre denne testen?
• Kan regresjonstesting utføres manuelt?
• Automatiserte verktøy for regresjonstesting
• Hvorfor regresjonstesten?
• Typer av regresjonstesting
  • # 1) Enhetsregresjon
  • # 2) Delvis regresjon
  • # 3) Fullstendig regresjon
• Hvor mye regresjon kreves?
• Hva gjør vi for regresjonskontroll?
• Regresjonstestteknikker
  • # 1) Test alle på nytt
  • # 2) Valg av regresjonstest
  • # 3) Testprioritering
  • # 4) Hybrid
• Hvordan velge en regresjonstestsuite?
• Hvordan utføre regresjonstesting?
• Regresjon i smidig
  • # 1) Regresjon på sprintnivå
  • # 2) End-to-End regresjon
• Fordeler
• Ulemper
• Regresjon av GUI-applikasjon
• Forskjellen mellom regresjon og omprøving
• Mal for regresjonstestplan (TOC)
  • # 1) Dokumenthistorikk
  • # 2) Referanser
  • # 3) Plan for regresjonstest
  • # 4) Godkjenning / aksept
• Konklusjon
• Anbefalt lesing

Veiledninger dekket i denne serien

Opplæring # 1: Hva er regresjonstesting (Denne opplæringen)
Opplæring nr. 2: Testverktøy for regresjon
Opplæring # 3: Test på nytt mot regresjonstesting
Opplæring # 4: Automatisert regresjonstesting i smidig

Oversikt over regresjonstest

Regresjonstest er som en verifiseringsmetode. Test tilfeller er vanligvis automatisert ettersom test tilfeller er nødvendig for å utføre igjen og igjen, og å kjøre de samme test sakene igjen og igjen manuelt er også tidkrevende og kjedelig.

For eksempel, Vurder et produkt X, der en av funksjonalitetene er å utløse bekreftelse, aksept og utsendt e-post når du klikker på Bekreft, Godta og forsendelse.

Noen problemer oppstår i bekreftelses-e-posten, og for å fikse det samme blir noen kodeendringer gjort. I dette tilfellet må ikke bare bekreftelses-e-postene testes, men godkjennelse og utsendt e-post må også testes for å sikre at endringen i koden ikke har påvirket dem.

Regresjonstesting er ikke avhengig av noe programmeringsspråk som Java, C ++, C #, etc. Det er en testmetode som brukes til å teste produktet for modifikasjoner eller for oppdateringer som gjøres. Den bekrefter at endringer i et produkt ikke påvirker de eksisterende modulene i produktet.

Bekreftelse av at feilene er løst, og at de nylig tilføyde funksjonene ikke har skapt noe problem i den forrige arbeidsversjonen av programvaren.

Testere utfører funksjonstesting når en ny versjon er tilgjengelig for verifisering. Hensikten med denne testen er å verifisere endringene som er gjort i den eksisterende funksjonaliteten og den nye funksjonaliteten også.

Når denne testen er ferdig, bør testeren verifisere om den eksisterende funksjonaliteten fungerer som forventet, og de nye endringene har ikke innført noen feil i funksjonaliteten som fungerte før denne endringen.

Regresjonstest bør være en del av utgivelsessyklusen og må vurderes i testestimasjonen.

Når skal jeg utføre denne testen?

Regresjonstesting utføres vanligvis etter verifisering av endringer eller ny funksjonalitet. Men dette er ikke alltid tilfelle. For utgivelsen som det tar måneder å fullføre, må regresjonstester innlemmes i den daglige testsyklusen. For ukentlige utgivelser kan regresjonstester utføres når funksjonstesten er over for endringene.

Regresjonskontroll er en variant av retest (som ganske enkelt er å gjenta en test). Når du tester på nytt, kan årsaken være hva som helst. Si, du testet en bestemt funksjon, og det var på slutten av dagen - du kunne ikke fullføre testen og måtte stoppe prosessen uten å bestemme deg for om testen besto / mislyktes.

Neste dag når du kommer tilbake, utfører du testen igjen - det betyr at du gjentar en test du har utført før. Den enkle handlingen med å gjenta en test er en ny test.

Regresjonstest i kjernen er en slags ny test. Det er bare for den spesielle anledningen at noe i applikasjonen / koden har endret seg. Det kan være kode, design eller noe som helst som dikterer systemets overordnede rammer.

En omprøve som gjennomføres i denne situasjonen for å sikre at nevnte endring ikke har påvirket noe som allerede fungerte før, kalles regresjonstest. De vanligste årsakene til at dette kan gjennomføres er at nye versjoner av koden er opprettet (økning i omfang / krav) eller feil er løst.

Kan regresjonstesting utføres manuelt?

Jeg underviste akkurat en av disse dagene i klassen min, og et spørsmål kom til meg: 'Kan regresjon gjøres manuelt?'

Jeg svarte på spørsmålet og vi gikk videre i klassen. Alt virket OK, men på en eller annen måte niste dette spørsmålet meg en god stund senere.

Over de mange gruppene kommer dette spørsmålet flere ganger på forskjellige måter. Noen av dem er:

• For å utføre testutførelsen trenger vi et verktøy?
• Hvordan utføres regresjonstesting?
• Selv etter en hel testrunde - nykommere har vanskelig for å se hva som er regresjonstest?

Og selvfølgelig det originale spørsmålet:

• Kan denne testen utføres manuelt?

Til å begynne med, Testutførelse er en enkel handling å bruke testtilfellene dine og utføre disse trinnene på AUT, levere testdata og sammenligne resultatet oppnådd på AUT med forventet resultat nevnt i testsakene dine.

Avhengig av sammenligningsresultatet, setter vi status for testsaken bestått / ikke bestått. Testutførelse er så enkelt som det, det er ingen spesielle verktøy som er nødvendige for denne prosessen.

Automatiserte verktøy for regresjonstesting

Automated Regression Test er testområdet der vi kan automatisere det meste av testinnsatsen. Vi kjører alle tidligere utførte testsaker på en ny versjon.

Dette betyr at vi har et testsakssett tilgjengelig, og det er tidkrevende å kjøre disse testsakene manuelt. Vi vet de forventede resultatene, så det å automatisere disse testtilfellene er tidsbesparende og er en effektiv regresjonstestmetode. Omfanget av automatisering avhenger av antall testtilfeller som vil være gjeldende på overtid.

Hvis testtilfeller varierer fra tid til annen, øker applikasjonsomfanget, og da vil automatisering av regresjonsprosedyre være bortkastet tid.

De fleste av Regression-testverktøyene er opptaks- og avspillingstype. Du registrerer testtilfellene ved å navigere gjennom AUT (applikasjonen under test) og kontrollere om de forventede resultatene kommer eller ikke.

Verktøy

• Selen
• Catalog Studio
• AdventNet QEngine
• Regresjonstester
• vTest
• vann
• actiWate
• Rasjonell funksjonstester
• SilkTest
• TimeShiftX

De fleste av disse er funksjonelle og regresjons-testverktøy.

Anbefalt lesing => Sjekk her for listen over de beste regresjonsverktøyene

Å legge til og oppdatere tilfeller med regresjonstest i en Automation-testpakke er en tungvint oppgave. Mens du velger et automatiseringsverktøy for regresjonstester, bør du sjekke om verktøyet lar deg enkelt legge til eller oppdatere testtilfellene.

kontinuerlig integrering og kontinuerlige leveringsverktøy

I de fleste tilfeller trenger vi å oppdatere automatiserte tilfeller med regresjonstest ofte på grunn av hyppige endringer i systemet.

SE VIDEOEN

For en mer detaljert forklaring av definisjonen med et eksempel, vennligst sjekk følgendeRegresjonstestvideo:

Hvorfor regresjonstesten?

Regresjon startes når en programmerer løser en feil eller legger til en ny kode for ny funksjonalitet i systemet.

Det kan være mange avhengigheter i den nylig lagt til og eksisterende funksjonalitet.

Det er et kvalitetsmål å sjekke om den nye koden samsvarer med den gamle koden, slik at den umodifiserte koden ikke blir berørt. Det meste av tiden har testteamet oppgaven med å sjekke siste øyeblikks endringene i systemet.

I en slik situasjon er det bare nødvendig å teste berørt applikasjonsområde for å fullføre testprosessen i tide ved å dekke alle de viktigste systemaspektene.

Denne testen er veldig viktig når det er lagt til en kontinuerlig endring / forbedring i applikasjonen. Den nye funksjonaliteten skal ikke påvirke den eksisterende testede koden negativt.

Regresjon er nødvendig for å finne feilene som oppstod på grunn av en endring i koden. Hvis denne testingen ikke er utført, kan produktet få kritiske problemer i det levende miljøet, og det kan faktisk føre kunden til problemer.

Når en tester et hvilket som helst nettsted, rapporterer en tester et problem med at prisen på produktet ikke vises riktig, det vil si at den viser en lavere pris enn den faktiske prisen på produktet, og at den må løses snart.

Når utvikleren har løst problemet, må det testes på nytt, og regresjonstesting er også påkrevd, ettersom bekreftelse av prisen på den rapporterte siden ville blitt korrigert, men det kan vise en feil pris på sammendragssiden der totalen vises sammen med de andre kostnadene, eller e-posten som sendes til kunden har fortsatt feil pris.

Nå, i dette tilfellet, må kunden bære tapet hvis denne testen ikke utføres ettersom nettstedet beregner den totale kostnaden med feil pris og samme pris går til en kunde via e-post. Når kunden godtar det, selges produktet online til en lavere pris, det vil være et tap for kunden.

Så denne testen spiller en stor rolle og er veldig nødvendig og viktig også.

Typer av regresjonstesting

Nedenfor er de forskjellige typer regresjon:

• Enhetsregresjon
• Delvis regresjon
• Fullstendig regresjon

# 1) Enhetsregresjon

Enhetsregresjon gjøres i løpet av Enhetstesting fase og kode testes isolert, dvs. eventuelle avhengigheter av enheten som skal testes, blokkeres slik at enheten kan testes individuelt uten avvik.

# 2) Delvis regresjon

Delvis regresjon gjøres for å verifisere at koden fungerer bra selv når endringene er gjort i koden, og at enheten er integrert med den uendrede eller allerede eksisterende koden.

# 3) Fullstendig regresjon

Fullstendig regresjon gjøres når en endring i koden gjøres på et antall moduler, og også hvis endringseffekten av en endring i en hvilken som helst annen modul er usikker. Produktet som helhet regres for å sjekke eventuelle endringer på grunn av den endrede koden.

Hvor mye regresjon kreves?

Dette avhenger av omfanget av nylig tilføyde funksjoner.

Hvis omfanget av en løsning eller funksjon er for stort, er applikasjonsområdet som blir berørt også ganske stort, og testingen bør utføres grundig, inkludert alle applikasjonstesttilfellene. Men dette kan effektivt avgjøres når testeren får innspill fra en utvikler om omfanget, naturen og mengden endring.

Ettersom dette er repeterende tester, kan testtilfeller automatiseres slik at et sett med testsaker enkelt kan utføres på en ny versjon.

Regresjonstest tilfeller må velges nøye slik at maksimal funksjonalitet blir dekket i et minimum sett med testtilfeller. Dette settet med testtilfeller trenger kontinuerlige forbedringer for nylig lagt til funksjonalitet.

Det blir veldig vanskelig når applikasjonsomfanget er veldig stort og det er kontinuerlige trinn eller oppdateringer til systemet. I slike tilfeller må det utføres selektive tester for å spare testkostnader og tid. Disse selektive testtilfellene er valgt ut fra forbedringene som er gjort med systemet og delene der det kan påvirke mest.

Hva gjør vi for regresjonskontroll?

• Kjør de tidligere utførte testene på nytt
• Sammenlign gjeldende resultater med tidligere utførte testresultater

Dette er en kontinuerlig prosess utført på forskjellige stadier gjennom programvaretestets livssyklus.

En god praksis er å gjennomføre en regresjonstest etter Sanity eller Smoke Testing og på slutten av funksjonstesting for en kort utgivelse.

For å gjennomføre effektiv testing, regresjonen Testplan skal opprettes. Denne planen skal skissere strategien for regresjonstesting og utgangskriteriene. Ytelsestesting er også en del av denne testen for å sikre at systemytelsen ikke påvirkes på grunn av endringene som er gjort i systemkomponentene.

Beste praksis : Kjør automatiserte testtilfeller hver dag på kvelden, slik at eventuelle regresjonsbivirkninger kan løses i neste dag. På denne måten reduserer det frigjøringsrisikoen ved å dekke nesten alle regresjonsfeil på et tidlig stadium i stedet for å finne og fikse dem på slutten av frigjøringssyklusen.

Regresjonstestteknikker

Nedenfor er de forskjellige teknikkene.

• Test på nytt alle
• Valg av regresjonstest
• Prøvesak Prioritering
• Hybrid

# 1) Test alle på nytt

Som navnet selv antyder, blir hele testtilfellene i testpakken kjørt på nytt for å sikre at det ikke er noen feil som har skjedd på grunn av en endring i koden. Dette er en kostbar metode da det krever mer tid og ressurser sammenlignet med de andre teknikkene.

# 2) Valg av regresjonstest

I denne metoden velges testtilfeller fra testpakken som skal kjøres på nytt. Ikke hele suiten blir kjørt på nytt. Valg av testtilfeller gjøres på grunnlag av kodeendring i modulen.

Test tilfeller er delt inn i to kategorier, en er gjenbrukbare test tilfeller og en annen er foreldet test tilfeller. De gjenbrukbare testtilfellene kan brukes i fremtidige regresjonssykluser, mens foreldede ikke brukes i de kommende regresjonssyklusene.

# 3) Testprioritering

Testsaker med høy prioritet utføres først enn de med middels og lav prioritet. Prioritering av testtilfelle avhenger av kritikk og innvirkning på produktet og også av funksjonaliteten til produktet som brukes oftere.

# 4) Hybrid

Hybridteknikken er en kombinasjon av valg av regresjonstest og prioritering av testtilfelle. I stedet for å velge hele testpakken, velg bare testtilfellene som kjøres på nytt avhengig av deres prioritet.

Hvordan velge en regresjonstestsuite?

De fleste feilene som finnes i produksjonsmiljøet, oppstår på grunn av endringene som ble gjort eller feilene ble løst på den ellevte timen, dvs. endringene som ble gjort på et senere tidspunkt. Feilrettingen på siste trinn kan skape andre problemer / feil i produktet. Derfor er regresjonskontroll veldig viktig før du slipper et produkt.

Nedenfor er en liste over testsaker som kan brukes mens du utfører denne testen:

• Funksjoner som ofte brukes.
• Test tilfeller som dekker modulen der endringene er gjort.
• Komplekse testsaker.
• Integrasjonstesttilfeller som inkluderer alle hovedkomponentene.
• Test saker for kjernefunksjonaliteten eller funksjonen til produktet.
• Prioritering 1 og Prioritet 2 testtilfeller bør inkluderes.
• Test tilfeller som ofte mislykkes, eller nylige testfeil ble funnet i det samme.

Hvordan utføre regresjonstesting?

Nå som vi har funnet ut hva regresjon betyr, er det tydelig at den også tester - bare å gjenta i en bestemt situasjon av en bestemt grunn. Derfor kan vi trygt utlede at den samme metoden gjelder for testing i utgangspunktet kan brukes på dette også.

Derfor, hvis testing kan gjøres manuelt, kan regresjonstesting også være det. Bruk av verktøy er ikke nødvendig. Imidlertid, etter hvert som applikasjoner blir stablet med mer og mer funksjonalitet som stadig øker omfanget av regresjon. For å få mest mulig ut av tiden er denne testen oftest automatisert .

Nedenfor er de forskjellige trinnene involvert i å utføre denne testen

• Forbered en testpakke for regresjon med tanke på punktene nevnt i “Hvordan velge Regression Test suite”?
• Automatiser alle testsaker i testpakken.
• Oppdater Regression-pakken når det er nødvendig, som om det blir funnet en ny defekt som ikke blir dekket i testsaken, og en testtilfelle for det samme bør oppdateres i testpakken, slik at testingen ikke blir savnet for neste gang . Regresjonstestpakken bør administreres riktig ved kontinuerlig oppdatering av testtilfellene.
• Utfør regresjonstesttilfellene når det er noen endring i koden, feilen er løst, ny funksjonalitet er lagt til, en forbedring av eksisterende funksjonalitet er utført osv.
• Lag en testutførelsesrapport som inkluderer statusen Bestått / Ikke bestått for de utførte testsakene.

For eksempel:

La meg forklare dette med et eksempel. Undersøk situasjonen nedenfor:

Følgende er observasjonene vi kan gjøre fra situasjonen ovenfor:

• Etter hvert som utgivelsene vokser, vokser funksjonaliteten.
• Utviklingstiden vokser ikke nødvendigvis med utgivelser, men testtiden gjør det
• Ingen selskaper / dets ledelse vil være klare til å investere mer tid i testing og mindre til utvikling
• Vi kan ikke engang redusere tiden det tar å teste ved å øke testlagets størrelse fordi flere betyr mer penger og nye mennesker betyr også mye trening og kanskje også et kompromiss i kvalitet, ettersom de nye menneskene kanskje ikke er på nivå med den nødvendige kunnskapen. nivåer umiddelbart.
• Det andre alternativet er klart å redusere mengden regresjon. Men det kan være risikabelt for programvareproduktet.

Av alle disse grunnene er regresjonstesting en god kandidat for automatiseringstesting, men det trenger ikke bare gjøres på den måten.

Grunnleggende trinn for å utføre regresjonstester

Hver gang programvaren gjennomgår en endring og en ny versjon / utgivelse kommer opp, er følgende trinn du kan ta for å utføre denne typen testing:

• Forstå hva slags endringer som er gjort i programvaren
• Analyser og avgjør hvilke moduler / deler av programvaren som kan bli påvirket - utviklings- og BA-team kan være med å gi denne informasjonen
• Ta en titt på testtilfellene dine og finn ut om du må gjøre en full, delvis eller enhetsregresjon. Identifiser de som passer til din situasjon
• Planlegg tiden og test bort!

Regresjon i smidig

Agile er en adaptiv tilnærming som følger en iterativ og inkrementell metode. Produktet er utviklet i korte iterasjoner kalt sprint som varer i 2-4 uker. I smidig er det en rekke iterasjoner, derfor spiller denne testen en viktig rolle ettersom den nye funksjonaliteten eller kodeendringen gjøres i iterasjonene.

Regresjonstestpakken bør utarbeides fra den innledende fasen og bør oppdateres med hver sprint.

I Agile dekkes regresjonssjekk i to kategorier:

• Sprintnivå regresjon
• End til slutt regresjon

# 1) Regresjon på sprintnivå

Sprint Level Regression gjøres hovedsakelig for den nye funksjonaliteten eller forbedringen som gjøres i den siste sprinten. Testtilfeller fra testpakken velges i henhold til den nylig lagt til funksjonaliteten eller forbedringen som er gjort.

# 2) End-to-End regresjon

End-to-End regresjon inkluderer alle testtilfellene som skal utføres på nytt for å teste hele produktet fra ende til annen ved å dekke alle kjernefunksjonalitetene til produktet.

Ettersom Agile har korte sprinter, og det fortsetter, er det veldig nødvendig å automatisere testpakken, testkassene blir utført på nytt og det må også fullføres på kort tid. Automatisering av testtilfellene reduserer tiden for utførelse og mangler.

Fordeler

Nedenfor er de forskjellige fordelene med regresjonstest

• Det forbedrer kvaliteten på produktet.
• Det sikrer at feilretting eller forbedring som gjøres ikke påvirker produktets eksisterende funksjonalitet.
• Automatiseringsverktøy kan brukes til denne testingen.
• Det sørger for at problemer som allerede er løst, ikke oppstår igjen.

Ulemper

Selv om det er flere fordeler, er det også noen ulemper. De er:

• Det må gjøres for en liten endring i koden også, fordi selv en liten endring i koden kan skape problemer i den eksisterende funksjonaliteten.
• Hvis det ikke blir brukt automatisering i prosjektet for denne testen, vil det være en tidkrevende og kjedelig oppgave å utføre testsakene igjen og igjen.

Regresjon av GUI-applikasjon

Det er vanskelig å utføre en GUI (grafisk brukergrensesnitt) regresjonstest når GUI-strukturen er modifisert. Testtilfellene skrevet på gammel GUI blir enten foreldet eller må endres.

Å bruke regresjonstesttilfellene på nytt betyr at GUI-testtilfeller blir modifisert i henhold til den nye GUI. Men denne oppgaven blir tungvint hvis du har et stort sett med GUI-testtilfeller.

Forskjellen mellom regresjon og omprøving

Gjennomprøving gjøres for testsakene som mislykkes under utførelsen, og feilen som er reist for det samme er løst, mens regresjonskontroll ikke er begrenset til feilrettingen, da den også dekker andre testtilfeller for å sikre at feilrettingen ikke har blitt påvirket annen funksjonalitet i produktet.

Mal for regresjonstestplan (TOC)

1. Dokumenthistorikk

2. Referanser

3. Regresjonstestplan

3.1. Introduksjon

3.2. Hensikt

3.3. Teststrategi

3.4. Funksjon som skal testes

3.5. Ressurskrav

3.5.1. Maskinvarekrav

3.5.2. Programvarekrav

3.6. Testplan

3.7. Forespørsel om endring

3.8. Inngangs- / utgangskriterier

3.8.1. Oppføringskriterier for denne testen

3.8.2. Utgangskriterier for denne testen

3.9. Antakelse / begrensninger

3.10. Test tilfeller

3.11. Risiko / forutsetninger

3.12. Verktøy

4. Godkjenning / aksept

La oss se nærmere på hver av dem.

# 1) Dokumenthistorikk

Dokumenthistorikk består av en oversikt over førsteutkastet og alle de oppdaterte i nedenstående format.

# 2) Referanser

Referansekolonne holder oversikt over alle referansedokumentene som brukes eller kreves for prosjektet mens du lager en testplan.

# 3) Plan for regresjonstest

3.1. Introduksjon

Dette dokumentet beskriver endring / oppdatering / forbedring av produktet som skal testes, og tilnærmingen som brukes til denne testingen. Alle kodeendringer, forbedringer, oppdateringer, tilleggsfunksjoner er beskrevet for å bli testet. Testtilfeller som brukes til enhetstesting og integrasjonstesting kan brukes til å lage en testpakke for regresjon.

3.2. Hensikt

Formålet med regresjonstestplanen er å beskrive hva nøyaktig og hvordan testing vil bli utført for å oppnå resultatene. Regresjonskontroll utføres for å sikre at ingen annen funksjonalitet av produktet hindres på grunn av kodeendringen.

3.3. Teststrategi

Teststrategi beskriver tilnærmingen som skal brukes til å utføre denne testen, og som inkluderer teknikken som skal brukes, hva som vil være fullføringskriteriene, hvem som skal utføre hvilken aktivitet, hvem som skal skrive testmanusene, hvilket regresjonsverktøy som skal brukes , trinn for å dekke risikoen som ressursknusing, forsinkelse i produksjonen osv.

3.4. Funksjoner som skal testes

Funksjonen / komponentene til produktet som skal testes, er oppført her. I regresjon kjøres alle testtilfellene på nytt, eller de som påvirker den eksisterende funksjonaliteten, velges avhengig av reparasjonen / oppdateringen eller forbedringen som er gjort.

3.5. Ressurskrav

3.5.1. Maskinvarekrav:

Maskinvarekrav er identifisert her som datamaskiner, bærbar datamaskin, modemer, Mac-bok, smarttelefon, etc.

3.5.2. Programvarekrav:

Programvarekrav identifiseres som hvilket operativsystem og nettlesere som kreves.

3.6. Testplan

Testplan definerer estimert tid for utførelse av testaktivitetene.

For eksempel Hvor mange ressurser vil utføre en testaktivitet, og det også på hvor lang tid?

3.7. Forespørsel om endring

CR-detaljer er nevnt som regresjon vil bli utført for.

3.8. Inngangs- / utgangskriterier

3.8.1. Oppføringskriterier for denne testen:

Oppføringskriterier for at produktet skal starte regresjonskontroll er definert.

For eksempel:

• Kodingsendringer / forbedring / tillegg av ny funksjon bør fullføres.
• Plan for regresjonstest bør godkjennes.

3.8.2. Utgangskriterier for denne testen:

Her er utgangskriteriene for regresjon definert.

For eksempel:

• Regresjonstesting bør være fullført.
• Eventuelle nye kritiske feil som ble funnet under denne testingen, bør lukkes.
• Testrapporten skal være klar.

3.9. Test tilfeller

Regresjonstesttilfeller er definert her.

3.10. Risiko / forutsetninger

Eventuelle risikoer og forutsetninger identifiseres, og det utarbeides en beredskapsplan for det samme.

3.11. Verktøy

Verktøy som skal brukes i prosjektet er identifisert. Som for eksempel:

• Automatiseringsverktøy
• Feilrapporteringsverktøy

# 4) Godkjenning / aksept

Navn og betegnelse på folket er oppført her:

Konklusjon

Regresjonstesting er en av de viktigste aspektene, da det hjelper å levere et kvalitetsprodukt ved å sørge for at endringer i koden, enten den er liten eller stor, ikke påvirker eksisterende eller gammel funksjonalitet.

Mange automatiseringsverktøy er tilgjengelige for automatisering av regresjonstesttilfellene, men et verktøy bør velges i henhold til prosjektkravet. Et verktøy skal ha muligheten til å oppdatere testpakken ettersom Regression-testpakken må oppdateres ofte.

Med det pakker vi inn dette emnet og håper det vil være mye bedre klarhet om emnet fra nå av.

Gi oss beskjed om dine spørsmål og kommentarer om regresjon. Hvordan taklet du oppgavene for regresjonstesting?

=> Besøk her for komplett testplanopplæringsserie

Anbefalt lesing

• Beste verktøy for testing av programvare 2021 (QA Test Automation Tools)
• Topp 10 mest populære regresjonstestverktøy i 2021
• Hva er pålitelighetstesting: definisjon, metode og verktøy
• 11 beste automatiseringsverktøy for testing av Android-applikasjoner (Android-app-testverktøy)
• Automatisert regresjonstesting: utfordringer, prosesser og trinn
• Testing Primer eBook Download
• Forskjellen mellom omprøving og regresjonstesting med eksempel
• Topp 10+ beste SAP-testverktøy (SAP-automatiseringsverktøy)