what is regression testing
Hvad er regressionstest?
Regressionstest er en type test, der udføres for at kontrollere, at en kodeskift i softwaren ikke påvirker produktets eksisterende funktionalitet. Dette er for at sikre, at produktet fungerer fint med ny funktionalitet, fejlrettelser eller enhver ændring i den eksisterende funktion. Tidligere udførte testsager genudføres for at kontrollere virkningen af ændringer.
=> Klik her for en komplet testplan-selvstudieserie
Regression Testing er en softwaretesttype, hvor testcases genudføres for at kontrollere, om applikationens tidligere funktionalitet fungerer fint, og at de nye ændringer ikke har introduceret nye fejl.
Denne test kan udføres på en ny build, når der er en væsentlig ændring i den oprindelige funktionalitet, også i en enkelt bug fix.
Regression betyder gentest af de uændrede dele af applikationen.
Hvad du vil lære:
- Vejledninger dækket af denne serie
- Oversigt over regressionstest
- Hvornår skal denne test udføres?
- Kan regressionstest udføres manuelt?
- Automatiske regressionstestværktøjer
- Hvorfor regressionstesten?
- Typer af regressionstest
- Hvor meget regression er påkrævet?
- Hvad gør vi ved regressionskontrol?
- Teknikker til regressionstest
- Hvordan vælges en regressionstest-suite?
- Hvordan udføres regressionstest?
- Regression I Agile
- Fordele
- Ulemper
- Regression af GUI-applikation
- Forskellen mellem regression og gentestning
- Regression Test Plan Template (TOC)
- Konklusion
- Anbefalet læsning
Vejledninger dækket af denne serie
Tutorial # 1: Hvad er regressionstest (Denne vejledning)
Tutorial # 2: Værktøjer til regressionstest
Tutorial # 3: Test igen mod regressionstest
Tutorial # 4: Automatiseret regressionstest i smidig
Oversigt over regressionstest
Regressionstest er som en verifikationsmetode. Testcases automatiseres normalt, da testcases kræves for at udføre igen og igen, og det er også tidskrævende og kedeligt at køre de samme testcases igen og igen manuelt.
For eksempel, Overvej et produkt X, hvor en af funktionaliteten er at udløse bekræftelse, accept og afsendte e-mails, når der klikkes på knapperne Bekræft, Acceptér og Forsendelse.
Nogle problemer opstår i bekræftelses-e-mailen, og for at rette det samme foretages nogle kodeændringer. I dette tilfælde skal ikke kun bekræftelses-e-mails testes, men accept og afsendt e-mail skal også testes for at sikre, at ændringen i koden ikke har påvirket dem.
Regressionstest er ikke afhængig af programmeringssprog som Java, C ++, C # osv. Det er en testmetode, der bruges til at teste produktet for ændringer eller for opdateringer, der udføres. Det bekræfter, at enhver ændring i et produkt ikke påvirker produktets eksisterende moduler.
Bekræftelse af, at fejlene er rettet, og at de nyligt tilføjede funktioner ikke har skabt noget problem i den tidligere arbejdsversion af softwaren.
Testere udfører funktionstestning, når en ny version er tilgængelig til verifikation. Formålet med denne test er at kontrollere de ændringer, der er foretaget i den eksisterende funktionalitet og den nyligt tilføjede funktionalitet.
Når denne test er udført, skal testeren kontrollere, om den eksisterende funktionalitet fungerer som forventet, og de nye ændringer har ikke introduceret nogen fejl i funktionalitet, der fungerede før denne ændring.
Regressionstest skal være en del af frigivelsescyklussen og skal overvejes i testestimationen.
Hvornår skal denne test udføres?
Regressionstest udføres normalt efter verifikation af ændringer eller ny funktionalitet. Men dette er ikke altid tilfældet. For frigivelsen, der tager måneder at gennemføre, skal regressionstest indarbejdes i den daglige testcyklus. Ved ugentlige frigivelser kan der udføres regressionstest, når funktionstesten er forbi for ændringerne.
Regressionskontrol er en variation af gentest (som simpelthen er at gentage en test). Ved gentest kan årsagen være alt. Sig, du testede en bestemt funktion, og det var slutningen af dagen - du kunne ikke afslutte testen og måtte stoppe processen uden at beslutte, om testen bestod / mislykkedes.
Den næste dag, når du kommer tilbage, udfører du testen igen - det betyder, at du gentager en test, du har udført før. Den enkle handling at gentage en test er en gentest.
Regressionstest i kernen er en slags gentest. Det er kun til den særlige lejlighed, at noget i applikationen / koden har ændret sig. Det kan være kode, design eller noget som helst, der dikterer systemets overordnede rammer.
En gentest, der udføres i denne situation for at sikre, at den nævnte ændring ikke har haft indflydelse på noget, der allerede fungerede før, kaldes Regression Test. De mest almindelige årsager til, at dette kan gennemføres, er, fordi der er oprettet nye versioner af koden (stigning i omfang / krav) eller bugs er rettet.
Kan regressionstest udføres manuelt?
Jeg underviste lige en af disse dage i min klasse, og et spørgsmål kom til mig: 'Kan regression ske manuelt?'
Jeg besvarede spørgsmålet, og vi gik videre i klassen. Alt virkede OK, men på en eller anden måde nagede dette spørgsmål mig et stykke tid senere.
Over de mange partier kommer dette spørgsmål flere gange på forskellige måder. Nogle af dem er:
- For at udføre testudførelsen har vi brug for et værktøj?
- Hvordan udføres regressionstest?
- Selv efter en hel testrunde - har nybegyndere svært ved at skelne, hvad præcis regressionstest er?
Og selvfølgelig det originale spørgsmål:
- Kan denne test udføres manuelt?
Til at starte med, Testudførelse er en simpel handling at bruge dine testsager og udføre disse trin på AUT, levere testdata og sammenligne det opnåede resultat på AUT med det forventede resultat, der er nævnt i dine testsager.
Afhængigt af sammenligningsresultatet indstiller vi status for test / case-bestået / ikke-godkendt. Testudførelse er så simpelt som det, der er ingen specielle værktøjer nødvendige til denne proces.
Automatiske regressionstestværktøjer
Automated Regression Test er testområdet, hvor vi kan automatisere det meste af testindsatsen. Vi kører alle de tidligere udførte testsager på en ny build.
Dette betyder, at vi har et testsagssæt til rådighed, og det er tidskrævende at køre disse testsager manuelt. Vi kender de forventede resultater, så det er tidsbesparende at automatisere disse testtilfælde og er en effektiv regressionstestmetode. Omfanget af automatisering afhænger af antallet af testsager, der fortsat gælder overarbejde.
Hvis testtilfælde varierer fra tid til anden, fortsætter applikationsomfanget og derefter automatiseres regressionsproceduren spild af tid.
De fleste af Regression-testværktøjerne er optage- og afspilningstype. Du registrerer testsagerne ved at navigere gennem AUT (applikation under test) og kontrollere, om de forventede resultater kommer eller ej.
Værktøjer
- Selen
- Catalog Studio
- AdventNet QEngine
- Regressionstester
- vTest
- vand
- actiWate
- Rationel funktionel tester
- Silketest
- TimeShiftX
De fleste af disse er funktionelle og regressions testværktøjer.
Anbefalet læsning => Tjek her for listen over de mest populære regressionsværktøjer
Tilføjelse og opdatering af regressionstestsager i en Automation-testpakke er en besværlig opgave. Mens du vælger et automatiseringsværktøj til regressionstest, skal du kontrollere, om værktøjet let giver dig mulighed for at tilføje eller opdatere testsagerne.
hvad er den bedste fjernelse af spyware-software
I de fleste tilfælde er vi nødt til at opdatere automatiske tilfælde af regressionstest ofte på grund af hyppige ændringer i systemet.
SE VIDEOEN
For en mere detaljeret forklaring af definitionen med et eksempel, se venligst følgendeVideo om regressionstest:
Hvorfor regressionstesten?
Regression startes, når en programmør løser en fejl eller tilføjer en ny kode til ny funktionalitet til systemet.
Der kan være mange afhængigheder i den nyligt tilføjede og eksisterende funktionalitet.
Det er et kvalitetsmål for at kontrollere, om den nye kode overholder den gamle kode, så den umodificerede kode ikke bliver påvirket. For det meste har testteamet til opgave at kontrollere ændringer i sidste øjeblik i systemet.
I en sådan situation er det kun nødvendigt at teste det berørte applikationsområde for at afslutte testprocessen til tiden ved at dække alle de store systemaspekter.
Denne test er meget vigtig, når der tilføjes en kontinuerlig ændring / forbedring i applikationen. Den nye funktionalitet bør ikke påvirke den eksisterende testede kode negativt.
Regression er påkrævet for at finde de fejl, der opstod på grund af en ændring i koden. Hvis denne test ikke er udført, kan produktet få kritiske problemer i det levende miljø, og det kan faktisk føre kunden til problemer.
Under test af ethvert online-websted rapporterer en tester et problem med, at prisen på produktet ikke vises korrekt, dvs. det viser en lavere pris end den faktiske pris på produktet, og det skal løses snart.
Når udvikleren har løst problemet, skal det testes igen, og regressionstest er også påkrævet, da bekræftelse af prisen på den rapporterede side ville være blevet rettet, men det viser muligvis en forkert pris på oversigtssiden, hvor det samlede antal vises sammen med de andre afgifter eller den mail, der sendes til kunden, har stadig den forkerte pris.
I dette tilfælde skal kunden bære tabet, hvis denne test ikke udføres, da webstedet beregner de samlede omkostninger med den forkerte pris, og den samme pris går til en kunde via e-mail. Når kunden accepterer, sælges produktet online til en lavere pris, det vil være et tab for kunden.
Så denne test spiller en stor rolle og er meget krævet og vigtig.
Typer af regressionstest
Nedenfor er de forskellige typer af regression:
- Enhedsregression
- Delvis regression
- Komplet regression
# 1) Enhedsregression
Enhedsregression sker i løbet af Enhedstest fase og kode testes isoleret, dvs. eventuelle afhængigheder af den enhed, der skal testes, blokeres, så enheden kan testes individuelt uden forskel.
# 2) Delvis regression
Delvis regression foretages for at kontrollere, at koden fungerer fint, selv når ændringerne er foretaget i koden, og at enheden er integreret med den uændrede eller allerede eksisterende kode.
# 3) Fuldstændig regression
Komplet regression udføres, når en ændring i koden udføres på et antal moduler, og også hvis ændringseffekten af en ændring i ethvert andet modul er usikker. Produktet som helhed regresseres for at kontrollere eventuelle ændringer på grund af den ændrede kode.
Hvor meget regression er påkrævet?
Dette afhænger af omfanget af nyligt tilføjede funktioner.
Hvis omfanget af en rettelse eller funktion er for stort, er applikationsområdet, der bliver berørt, også ret stort, og testen skal udføres grundigt inklusive alle applikationstesttilfælde. Men dette kan effektivt afgøres, når testeren får input fra en udvikler om omfanget, arten og mængden af ændring.
Da dette er gentagne tests, kan testcases automatiseres, så et sæt testcases alene let kan udføres på en ny build.
Regressionstestsager skal vælges meget omhyggeligt, så maksimal funktionalitet er dækket af et minimum af testsager. Disse sæt testsager har brug for løbende forbedringer for nyligt tilføjet funktionalitet.
Det bliver meget vanskeligt, når applikationsomfanget er meget stort, og der er kontinuerlige trin eller rettelser til systemet. I sådanne tilfælde skal der udføres selektive tests for at spare testomkostninger og tid. Disse selektive testtilfælde udvælges baseret på forbedringerne af systemet og de dele, hvor det kan påvirke mest.
Hvad gør vi ved regressionskontrol?
- Kør de tidligere udførte tests igen
- Sammenlign de aktuelle resultater med tidligere udførte testresultater
Dette er en kontinuerlig proces udført på forskellige stadier gennem softwaretestens livscyklus.
En bedste praksis er at gennemføre en regressionstest efter Tilregnelighed eller røgtest og i slutningen af funktionstest for en kort frigivelse.
For at udføre effektiv test, regressionen Testplan skal oprettes. Denne plan skal skitsere strategien for regressionstest og exitkriterierne. Ydelsestest er også en del af denne test for at sikre, at systemets ydelse ikke påvirkes på grund af de ændringer, der er foretaget i systemkomponenterne.
Bedste praksis : Kør automatiserede testsager hver dag om aftenen, så eventuelle regressionsbivirkninger kan løses i den næste dag. På denne måde reducerer det frigivelsesrisikoen ved at dække næsten alle regressionsfejl på et tidligt tidspunkt i stedet for at finde og rette dem i slutningen af frigivelsescyklussen.
Teknikker til regressionstest
Nedenfor er de forskellige teknikker.
- Test igen alle
- Valg af regressionstest
- Test case Prioritering
- Hybrid
# 1) Test alle igen
Som navnet selv antyder, udføres hele testcases i testpakken igen for at sikre, at der ikke er nogen fejl, der er opstået på grund af en ændring i koden. Dette er en dyr metode, da det kræver mere tid og ressourcer sammenlignet med de andre teknikker.
# 2) Valg af regressionstest
I denne metode vælges testcases fra testpakken, der skal genudføres. Ikke hele pakken genudføres. Udvælgelsen af testsager sker på baggrund af kodeændring i modulet.
Testtilfælde er opdelt i to kategorier, den ene er genanvendelige testtilfælde og den anden er forældede testsager. De genanvendelige testtilfælde kan bruges i fremtidige regressionscyklusser, mens forældede ikke bruges i de kommende regressionscyklusser.
# 3) Prioriteret testsag
Testsager med høj prioritet udføres først end dem med mellemlang og lav prioritet. Prioriteten af testcase afhænger af dets kritiske betydning og dens indvirkning på produktet og også af funktionaliteten af det produkt, der bruges oftere.
# 4) Hybrid
Hybridteknikken er en kombination af valg af regressionstest og prioritering af testtilfælde. I stedet for at vælge hele testpakken, skal du kun vælge de testsager, der genudføres, afhængigt af deres prioritet.
Hvordan vælges en regressionstest-suite?
De fleste af de fejl, der findes i produktionsmiljøet, opstår på grund af ændringer, der blev foretaget eller fejl, der blev rettet på den ellevte time, dvs. ændringer foretaget på et senere tidspunkt. Fejlrettelsen i sidste fase kan skabe andre problemer / fejl i produktet. Derfor er regressionskontrol meget vigtig, inden der frigives et produkt.
Nedenfor er en liste over testsager, der kan bruges, når du udfører denne test:
- Funktioner, der ofte bruges.
- Test sager, der dækker det modul, hvor ændringerne er foretaget.
- Komplekse testsager.
- Integrationstestsager, der inkluderer alle hovedkomponenterne.
- Test sager for produktets kernefunktionalitet eller funktion.
- Prioritet 1 og prioritet 2 testtilfælde skal medtages.
- Testtilfælde, der ofte fejler, eller nylige testfejl blev fundet i det samme.
Hvordan udføres regressionstest?
Nu hvor vi har fastslået, hvad regression betyder, er det tydeligt, at det også tester - blot gentagelse i en bestemt situation af en bestemt grund. Derfor kan vi sikkert udlede, at den samme metode gælder for test i første omgang, kan også anvendes til dette.
Derfor, hvis test kan udføres manuelt, kan regressionstest også være. Brug af et værktøj er ikke nødvendigt. Men efterhånden som applikationer bliver stablet med mere og mere funktionalitet, hvilket stadig øger omfanget af regression. For at få mest muligt ud af tiden er denne test oftest automatiseret .
Nedenfor er de forskellige trin involveret i udførelsen af denne test
- Forbered en testpakke til regression i betragtning af de punkter, der er nævnt i “Hvordan vælges Regression Test suite”?
- Automatiser alle testsagerne i testpakken.
- Opdater Regression-pakken, når det er påkrævet, som hvis der findes en ny defekt, som ikke er dækket af testsagen, og en testcase for det samme skal opdateres i testpakken, så testen ikke går glip af det næste gang . Regressionstestpakken skal styres korrekt ved løbende at opdatere testsagerne.
- Udfør regressionstestsagerne, når der er ændringer i koden, buggen er rettet, ny funktionalitet tilføjes, en forbedring af den eksisterende funktionalitet udføres osv.
- Opret en testudførelsesrapport, der inkluderer status Pass / Fails for de eksekverede testsager.
For eksempel:
Lad mig forklare dette med et eksempel. Undersøg nedenstående situation:
Slip 1 Statistik | |
---|---|
Antal testere | 3 |
Ansøgningens navn | XYZ |
Version / frigivelsesnummer | 1 |
Antal krav (anvendelsesområde) | 10 |
Antal testtilfælde / test | 100 |
Antal dage, det tager at udvikle sig | 5 |
Antal dage, det tager at teste | 5 |
Slip 2-statistik | |
---|---|
Antal testere | 3 |
Ansøgningens navn | XYZ |
Version / frigivelsesnummer | to |
Antal krav (anvendelsesområde) | 10+ 5 nye krav |
Antal testsager / test | 100+ 50 nye |
Antal dage, det tager at udvikle sig | 2,5 (siden denne halvdelen af arbejdet end tidligere) |
Antal dage, det tager at teste | 5 (for de eksisterende 100 TC'er) + 2.5 (for nye krav) |
Slip 3 Statistik | |
---|---|
Antal testere | 3 |
Ansøgningens navn | XYZ |
Version / frigivelsesnummer | 3 |
Antal krav (anvendelsesområde) | 10+ 5 + 5 nye krav |
Antal testsager / test | 100+ 50+ 50 nye |
Antal dage, det tager at udvikle sig | 2,5 (siden denne halvdelen af arbejdet end tidligere) |
Antal dage, det tager at teste | 7.5 (for de eksisterende 150 TC'er) + 2.5 (for nye krav) |
Følgende er de observationer, vi kan komme fra ovenstående situation:
- Efterhånden som udgivelserne vokser, vokser funktionaliteten.
- Udviklingstiden vokser ikke nødvendigvis med udgivelser, men testtiden gør det
- Ingen virksomhed / dets ledelse vil være klar til at investere mere tid i test og mindre til udvikling
- Vi kan ikke engang reducere den tid det tager at teste ved at øge testteamets størrelse, fordi flere mennesker betyder flere penge og nye mennesker betyder også masser af træning og måske også et kompromis i kvalitet, da de nye mennesker måske ikke er på niveau med den krævede viden niveauer straks.
- Det andet alternativ er helt klart at reducere mængden af regression. Men det kan være risikabelt for softwareproduktet.
Af alle disse grunde er Regression Testing en god kandidat til Automation Testing, men det behøver ikke kun gøres på den måde.
Grundlæggende trin til at udføre regressionstest
Hver gang softwaren gennemgår en ændring, og en ny version / frigivelse kommer op, er følgende de trin, du kan tage for at udføre denne type test:
- Forstå, hvilken type ændringer der er foretaget i softwaren
- Analyser og bestem hvilke moduler / dele af softwaren der kan blive påvirket - udviklings- og BA-holdene kan være med til at levere denne information
- Se på dine testsager, og find ud af, om du bliver nødt til at foretage en fuldstændig, delvis eller enhedsregression. Identificer dem, der passer til din situation
- Planlæg tiden og test væk!
Regression I Agile
Adræt er en adaptiv tilgang, der følger en iterativ og inkrementel metode. Produktet er udviklet i korte iterationer kaldet sprint, som varer i 2-4 uger. I agile er der et antal iterationer, derfor spiller denne test en vigtig rolle, da den nye funktionalitet eller kodeændring sker i iterationerne.
Regressionstestpakken skal forberedes fra den indledende fase og skal opdateres med hver sprint.
I Agile er regressionskontrol dækket af to kategorier:
- Sprint niveau regression
- End til slut regression
# 1) Regression af sprintniveau
Sprint Level Regression udføres hovedsageligt for den nye funktionalitet eller forbedring, der udføres i den seneste sprint. Testcases fra testpakken vælges i henhold til den nyligt tilføjede funktionalitet eller den forbedring, der udføres.
# 2) End-to-End regression
End-to-End-regression inkluderer alle de testtilfælde, der skal genudføres for at teste det komplette produkt fra ende til anden ved at dække alle produktets kernefunktioner.
Da Agile har korte sprints, og det fortsætter, er det meget nødvendigt at automatisere testpakken, testsagerne udføres igen, og det skal også afsluttes på kort tid. Automatisering af testsager reducerer udførelsestiden og mangler ved mangler.
Fordele
Nedenfor er de forskellige fordele ved regressionstest
- Det forbedrer produktets kvalitet.
- Det sikrer, at enhver fejlrettelse eller forbedring, der udføres, ikke påvirker produktets eksisterende funktionalitet.
- Automatiseringsværktøjer kan bruges til denne test.
- Det sørger for, at problemer, der allerede er løst, ikke opstår igen.
Ulemper
Selvom der er flere fordele, er der også nogle ulemper. De er:
- Det skal også gøres for en lille ændring i koden, fordi selv en lille ændring i koden kan skabe problemer i den eksisterende funktionalitet.
- Hvis i tilfælde af automatisering ikke bruges i projektet til denne test, vil det være en tidskrævende og kedelig opgave at udføre testsagerne igen og igen.
Regression af GUI-applikation
Det er vanskeligt at udføre en GUI-regressionstest (grafisk brugergrænseflade), når GUI-strukturen er ændret. Testcases skrevet på gammel GUI bliver enten forældede eller skal ændres.
Genbrug af regressionstesttilfælde betyder, at GUI-testtilfælde ændres i henhold til den nye GUI. Men denne opgave bliver besværlig, hvis du har et stort sæt GUI-testsager.
Forskellen mellem regression og gentestning
Gentest udføres for testsagerne, der mislykkes under udførelsen, og fejlen, der er rejst for det samme, er rettet, mens regressionskontrol ikke er begrænset til fejlrettelsen, da den også dækker andre testsager for at sikre, at fejlrettelsen ikke er påvirket enhver anden funktionalitet af produktet.
Regression Test Plan Template (TOC)
1. Dokumenthistorik
2. Referencer
3. Plan for regressionstest
3.1. Introduktion
3.2. Formål
3.3. Teststrategi
3.4. Funktion, der skal testes
3.5. Ressource krav
3.5.1. Hardwarekrav
3.5.2. Softwarekrav
3.6. Testplan
3.7. Ændringsanmodning
3.8. Indgangs- / udgangskriterier
3.8.1. Indgangskriterier for denne test
3.8.2. Udgangskriterier for denne test
3.9. Antagelse / begrænsninger
3.10. Test tilfælde
3.11. Risiko / antagelser
3.12. Værktøjer
4. Godkendelse / accept
Lad os se nærmere på hver af dem.
# 1) Dokumenthistorik
Dokumenthistorik består af en registrering af det første kladde og alle de opdaterede i nedenstående format.
Version | Dato | Forfatter | Kommentar |
---|---|---|---|
1 | DD / MM / ÅÅ | ABC | godkendt |
to | DD / MM / ÅÅ | ABC | Opdateret til den tilføjede funktion |
# 2) Referencer
Referencekolonnen holder styr på alle de anvendte eller krævede referencedokumenter til projektet, mens du opretter en testplan.
Lade være med | Dokument | Beliggenhed |
---|---|---|
1 | SRS-dokument | Delt drev |
# 3) Plan for regressionstest
3.1. Introduktion
Dette dokument beskriver ændring / opdatering / forbedring af det produkt, der skal testes, og den metode, der anvendes til denne test. Alle kodeændringer, forbedringer, opdateringer, tilføjede funktioner er beskrevet for at blive testet. Testcases anvendt til Unit Testing og Integration Testing kan bruges til at oprette en testpakke til regression.
3.2. Formål
Formålet med regressionstestplanen er at beskrive, hvad der præcist og hvordan testning vil blive udført for at opnå resultaterne. Regressionskontrol udføres for at sikre, at ingen anden funktionalitet af produktet hæmmes på grund af kodeændringen.
3.3. Teststrategi
Teststrategi beskriver den tilgang, der vil blive brugt til at udføre denne test, og som inkluderer den teknik, der vil blive brugt, hvad vil være færdiggørelseskriterierne, hvem der udfører hvilken aktivitet, hvem der skriver testskripterne, hvilket regressionsværktøj der vil blive brugt , trin til at dække risici som ressourceknus, forsinkelse i produktionen osv.
3.4. Funktioner, der skal testes
Funktion / komponenter i det produkt, der skal testes, er angivet her. Under regression udføres alle testsagerne igen, eller de der påvirker den eksisterende funktionalitet vælges afhængigt af den udførte rettelse / opdatering eller forbedring.
3.5. Ressource krav
3.5.1. Hardwarekrav:
Hardwarekrav er identificeret her som computere, bærbar computer, modemer, Mac-bog, smartphone osv.
3.5.2. Softwarekrav:
Softwarekrav identificeres som hvilket operativsystem og browsere der kræves.
3.6. Testplan
Testplan definerer den anslåede tid til testaktiviteterne.
For eksempel Hvor mange ressourcer udfører en testaktivitet, og det også på hvor lang tid?
3.7. Ændringsanmodning
CR-detaljer nævnes, for hvilke regression ville blive udført.
S. nr | CR Beskrivelse | Regression Test Suite |
---|---|---|
1 | ||
to |
3.8. Indgangs- / udgangskriterier
3.8.1. Indgangskriterier for denne test:
Indgangskriterier for produktets start af regressionskontrol er defineret.
For eksempel:
- Kodningsændringer / forbedring / tilføjelse af ny funktion skal afsluttes.
- Plan for regressionstest skal godkendes.
3.8.2. Udgangskriterier for denne test:
Her defineres udgangskriterierne for regression.
For eksempel:
- Regressionstest skal være afsluttet.
- Nye kritiske fejl fundet under denne test skal lukkes.
- Testrapport skal være klar.
3.9. Test tilfælde
Sager om regressionstest er defineret her.
3.10. Risiko / antagelser
Eventuelle risici og antagelser identificeres, og der udarbejdes en beredskabsplan for det samme.
3.11. Værktøjer
Værktøjer, der skal bruges i projektet, identificeres. Såsom:
- Automatiseringsværktøj
- Fejlrapporteringsværktøj
# 4) Godkendelse / accept
Navn og betegnelse på folket er anført her:
Navn | Godkendt / afvist | Underskrift | Dato |
---|---|---|---|
Konklusion
Regressionstest er et af de vigtige aspekter, da det hjælper med at levere et kvalitetsprodukt ved at sikre, at enhver ændring i koden, uanset om den er lille eller stor, ikke påvirker den eksisterende eller gamle funktionalitet.
Der findes mange automatiseringsværktøjer til automatisering af regressionstesttilfælde, men et værktøj skal vælges i henhold til projektkravet. Et værktøj skal have mulighed for at opdatere testpakken, da Regression-testpakken skal opdateres ofte.
Med det pakker vi dette emne op og håber, at der vil være meget bedre klarhed om emnet fra nu af.
Fortæl os venligst dine regressionsrelaterede spørgsmål og kommentarer. Hvordan tacklede du dine regressionstestopgaver?
=> Besøg her for en komplet testplan-tutorial-serie
Anbefalet læsning
- Bedste softwaretestværktøjer 2021 (QA Test Automation Tools)
- Top 10 mest populære regressionstestværktøjer i 2021
- Hvad er pålidelighedstest: definition, metode og værktøjer
- 11 bedste automatiseringsværktøjer til test af Android-applikationer (Android App-testværktøjer)
- Automatiseret regressionstest: udfordringer, proces og trin
- Test af Primer eBook Download
- Forskellen mellem gentestning og regressionstest med eksempel
- Top 10+ bedste SAP testværktøjer (SAP Automation Tools)