what is regression testing
Wat is regressietesten?
Regressietesten is een soort test die wordt uitgevoerd om te controleren of een codewijziging in de software geen invloed heeft op de bestaande functionaliteit van het product. Dit is om ervoor te zorgen dat het product goed werkt met nieuwe functionaliteit, bugfixes of enige wijziging in de bestaande functie. Eerder uitgevoerde testcases worden opnieuw uitgevoerd om de impact van verandering te verifiëren.
Klik hier voor een complete serie testplannen
Regressietesten is een softwaretesttype waarbij testgevallen opnieuw worden uitgevoerd om te controleren of de vorige functionaliteit van de applicatie goed werkt en de nieuwe wijzigingen geen nieuwe bugs hebben geïntroduceerd.
Deze test kan worden uitgevoerd op een nieuwe build wanneer er een significante verandering is in de oorspronkelijke functionaliteit, zelfs in een enkele bugfix.
Regressie betekent het opnieuw testen van de ongewijzigde delen van de applicatie.
Wat je leert:
- Tutorials die in deze serie worden behandeld
- Overzicht regressietest
- Wanneer moet u deze test uitvoeren?
- Kunnen regressietests handmatig worden uitgevoerd?
- Geautomatiseerde tools voor regressietesten
- Waarom de regressietest?
- Soorten regressietesten
- Hoeveel regressie is vereist?
- Wat doen we bij regressiecontrole?
- Regressietesttechnieken
- Hoe een regressietestsuite te selecteren?
- Hoe regressietests uitvoeren?
- Regressie in Agile
- Voordelen
- Nadelen
- Regressie van GUI-applicatie
- Verschil tussen regressie en opnieuw testen
- Regressietestplan-sjabloon (TOC)
- Gevolgtrekking
- Aanbevolen literatuur
Tutorials die in deze serie worden behandeld
Tutorial # 1: Wat is regressietesten (Deze tutorial)
Tutorial # 2: Regressietesthulpmiddelen
Tutorial # 3: Test opnieuw versus regressietesten
Tutorial # 4: Geautomatiseerde regressietesten in Agile
Overzicht regressietest
Regressietest is als een verificatiemethode. Testcases zijn over het algemeen geautomatiseerd, omdat testcases keer op keer moeten worden uitgevoerd en het handmatig uitvoeren van dezelfde testcases keer op keer tijdrovend en vervelend is.
Bijvoorbeeld, Overweeg een product X, waarin een van de functies is om bevestiging, acceptatie en verzonden e-mails te activeren wanneer op de knoppen Bevestigen, Accepteren en Verzenden wordt geklikt.
Er treedt een probleem op in de bevestigingsmail en om dit op te lossen, worden er enkele codewijzigingen aangebracht. In dit geval moeten niet alleen de bevestigingsmails worden getest, maar ook de acceptatie- en verzonden e-mails worden getest om er zeker van te zijn dat de wijziging in de code hen niet heeft beïnvloed.
Regressietesten zijn niet afhankelijk van een programmeertaal zoals Java, C ++, C #, enz. Het is een testmethode die wordt gebruikt om het product te testen op wijzigingen of updates die worden uitgevoerd. Het verifieert dat elke wijziging in een product geen invloed heeft op de bestaande modules van het product.
Controleren of de bugs zijn verholpen en dat de nieuw toegevoegde functies geen problemen hebben veroorzaakt in de vorige werkende versie van de software.
Testers voeren Functional Testing uit wanneer een nieuwe build beschikbaar is voor verificatie. De bedoeling van deze test is om de wijzigingen die zijn aangebracht in de bestaande functionaliteit en ook de nieuw toegevoegde functionaliteit te verifiëren.
Wanneer deze test is voltooid, moet de tester controleren of de bestaande functionaliteit werkt zoals verwacht en of de nieuwe wijzigingen geen defect in de functionaliteit hebben geïntroduceerd die vóór deze wijziging werkte.
Regressietest moet een onderdeel zijn van de afgiftecyclus en moet in de testschatting worden meegenomen.
Wanneer moet u deze test uitvoeren?
Regressietesten worden meestal uitgevoerd na verificatie van wijzigingen of nieuwe functionaliteit. Maar dit is niet altijd het geval. Voor de release die maanden in beslag neemt, moeten regressietests worden opgenomen in de dagelijkse testcyclus. Voor wekelijkse releases kunnen regressietests worden uitgevoerd wanneer de functionele tests voor de wijzigingen zijn voltooid.
Regressiecontrole is een variatie op een nieuwe test (dit is simpelweg het herhalen van een test). Bij het opnieuw testen kan de reden van alles zijn. Stel dat u een bepaalde functie aan het testen was en het was het einde van de dag - u kon het testen niet afmaken en moest het proces stoppen zonder te beslissen of de test geslaagd / mislukt was.
Wanneer u de volgende dag terugkomt, voert u de test opnieuw uit - dat betekent dat u een test herhaalt die u eerder hebt uitgevoerd. De simpele handeling van het herhalen van een test is een nieuwe test.
De kern van een regressietest is een soort hertest. Alleen voor de speciale gelegenheid is er iets in de applicatie / code veranderd. Het kan code, ontwerp of iets anders zijn dat het algemene raamwerk van het systeem dicteert.
Een hertest die in deze situatie wordt uitgevoerd om er zeker van te zijn dat de genoemde wijziging geen invloed heeft gehad op iets dat al werkte, wordt een regressietest genoemd. De meest voorkomende redenen waarom dit kan worden uitgevoerd, zijn omdat er nieuwe versies van de code zijn gemaakt (toename in scope / vereiste) of omdat bugs zijn verholpen.
Kunnen regressietests handmatig worden uitgevoerd?
Ik gaf net een dezer dagen les in mijn klas en er kwam een vraag bij me op: 'Kan regressie handmatig worden gedaan?'
Ik beantwoordde de vraag en we gingen verder in de klas. Alles leek in orde, maar op de een of andere manier bleef deze vraag me een tijdje later lastigvallen.
Over de vele batches heen komt deze vraag meerdere keren op verschillende manieren voor. Sommige ervan zijn:
- Hebben we een tool nodig om de testuitvoering uit te voeren?
- Hoe wordt regressietesten uitgevoerd?
- Zelfs na een hele testronde - vinden nieuwkomers het moeilijk om te onderscheiden wat precies regressietest is?
En natuurlijk de oorspronkelijke vraag:
- Kan deze test handmatig worden uitgevoerd?
Beginnen met, Test uitvoering is een simpele handeling door uw testcases te gebruiken en die stappen uit te voeren op de AUT, de testgegevens aan te leveren en het verkregen resultaat op de AUT te vergelijken met het verwachte resultaat dat in uw testcases wordt vermeld.
Afhankelijk van het vergelijkingsresultaat stellen we de status van de testcase geslaagd / mislukt in. Het uitvoeren van tests is zo simpel als dat, er zijn geen speciale tools nodig voor dit proces.
Geautomatiseerde tools voor regressietesten
Geautomatiseerde regressietest is het testgebied waar we de meeste testinspanningen kunnen automatiseren. We draaien alle eerder uitgevoerde testcases op een nieuwe build.
Dit betekent dat we een testcase-set beschikbaar hebben en het handmatig uitvoeren van deze testcases kost veel tijd. We kennen de verwachte resultaten, dus het automatiseren van deze testcases is tijdbesparend en een efficiënte regressietestmethode. De mate van automatisering is afhankelijk van het aantal testgevallen dat overuren van toepassing blijft.
Als testcases van tijd tot tijd variëren, wordt de toepassingsomvang steeds groter en zal automatisering van de regressieprocedure tijdverspilling zijn.
De meeste regressietesttools zijn van het opname- en afspeeltype. U neemt de testgevallen op door door de AUT (applicatie onder test) te navigeren en te controleren of de verwachte resultaten komen of niet.
Gereedschap
- Selenium
- Catalogus Studio
- AdventNet QEngine
- Regressietester
- vTest
- water
- actiWate
- Rationele functionele tester
- SilkTest
- TimeShiftX
De meeste hiervan zijn functionele en regressietesttools.
Aanbevolen literatuur => Kijk hier voor de lijst met beste regressietools
Het toevoegen en bijwerken van regressietestgevallen in een Automation-testsuite is een omslachtige taak. Bij het selecteren van een automatiseringstool voor regressietests, moet u controleren of u met deze tool de testgevallen gemakkelijk kunt toevoegen of bijwerken.
hoe kan ik xml-bestand openen
In de meeste gevallen moeten we geautomatiseerde regressietestgevallen regelmatig bijwerken vanwege frequente wijzigingen in het systeem.
BEKIJK DE VIDEO
Raadpleeg het volgende voor een meer gedetailleerde uitleg van de definitie met een voorbeeldRegressietestvideo
Waarom de regressietest?
Regressie wordt gestart wanneer een programmeur een bug repareert of een nieuwe code voor nieuwe functionaliteit aan het systeem toevoegt.
Er kunnen veel afhankelijkheden zijn in de nieuw toegevoegde en bestaande functionaliteit.
Het is een kwaliteitsmaatregel om te controleren of de nieuwe code overeenkomt met de oude code zodat de ongewijzigde code niet wordt aangetast. Meestal heeft het testteam de taak om de laatste minuut wijzigingen in het systeem te controleren.
In een dergelijke situatie is het testen van alleen het betreffende toepassingsgebied nodig om het testproces op tijd af te ronden door alle belangrijke systeemaspecten te behandelen.
Deze test is erg belangrijk wanneer er een continue verandering / verbetering wordt toegevoegd in de applicatie. De nieuwe functionaliteit mag de bestaande geteste code niet negatief beïnvloeden.
Regressie is vereist om de bugs te vinden die zijn opgetreden als gevolg van een wijziging in de code. Als deze tests niet worden uitgevoerd, kan het product kritieke problemen krijgen in de live-omgeving en dat kan de klant inderdaad in de problemen brengen.
Tijdens het testen van een online website meldt een tester een probleem dat de prijs van het product niet correct wordt weergegeven, d.w.z. dat de prijs lager is dan de werkelijke prijs van het product, en dit moet binnenkort worden opgelost.
Zodra de ontwikkelaar het probleem heeft opgelost, moet het opnieuw worden getest en is regressietest ook vereist, omdat het verifiëren van de prijs op de gerapporteerde pagina zou zijn gecorrigeerd, maar het kan een onjuiste prijs tonen op de overzichtspagina waar het totaal wordt weergegeven. met de andere kosten of de post die naar de klant wordt gestuurd, heeft nog steeds de verkeerde prijs.
Nu, in dit geval, zal de klant het verlies moeten dragen als deze test niet wordt uitgevoerd, aangezien de site de totale kosten berekent met de verkeerde prijs en dezelfde prijs per e-mail naar een klant gaat. Zodra de klant accepteert, wordt het product online tegen een lagere prijs verkocht, het is een verlies voor de klant.
Dit testen speelt dus een grote rol en is ook zeer vereist en belangrijk.
Soorten regressietesten
Hieronder staan de verschillende soorten regressie:
- Eenheidsregressie
- Gedeeltelijke regressie
- Volledige regressie
# 1) Regressie van eenheden
Eenheidsregressie wordt gedaan tijdens de Testen van een eenheid fase en code worden afzonderlijk getest, d.w.z. alle afhankelijkheden van de te testen eenheid worden geblokkeerd, zodat de eenheid afzonderlijk kan worden getest zonder enige discrepantie.
# 2) Gedeeltelijke regressie
Gedeeltelijke regressie wordt gedaan om te controleren of de code goed werkt, zelfs als de wijzigingen in de code zijn aangebracht en die eenheid is geïntegreerd met de ongewijzigde of reeds bestaande code.
# 3) Volledige regressie
Volledige regressie wordt gedaan wanneer een wijziging in de code wordt aangebracht op een aantal modules en ook als de impact van een wijziging in een andere module onzeker is. Het product als geheel wordt teruggedraaid om eventuele wijzigingen als gevolg van de gewijzigde code te controleren.
Hoeveel regressie is vereist?
Dit hangt af van de omvang van nieuw toegevoegde functies.
Als de reikwijdte van een fix of functie te groot is, is het toepassingsgebied dat wordt beïnvloed ook vrij groot en moeten de tests grondig worden uitgevoerd, inclusief alle testcases voor toepassingen. Maar dit kan effectief worden besloten wanneer de tester input krijgt van een ontwikkelaar over de reikwijdte, de aard en de hoeveelheid verandering.
Omdat dit repetitieve tests zijn, kunnen testcases worden geautomatiseerd, zodat alleen een reeks testcases eenvoudig kan worden uitgevoerd op een nieuwe build.
Regressietestgevallen moeten zeer zorgvuldig worden geselecteerd, zodat maximale functionaliteit wordt gedekt in een minimum aan testgevallen. Deze set testcases hebben continue verbeteringen nodig voor nieuw toegevoegde functionaliteit.
Het wordt erg moeilijk wanneer de toepassingsomvang erg groot is en er continue incrementen of patches voor het systeem zijn. In dergelijke gevallen moeten selectieve tests worden uitgevoerd om testkosten en tijd te besparen. Deze selectieve testcases worden gekozen op basis van de verbeteringen die aan het systeem zijn aangebracht en de onderdelen waar dit het meest van invloed kan zijn.
Wat doen we bij regressiecontrole?
- Herhaal de eerder uitgevoerde tests
- Vergelijk de huidige resultaten met eerder uitgevoerde testresultaten
Dit is een continu proces dat in verschillende stadia gedurende de levenscyclus van softwaretests wordt uitgevoerd.
Een best practice is om een regressietest uit te voeren na de Testen op gezond verstand of rook en aan het einde van Functioneel testen voor een korte release.
Om effectief te testen, moet de regressie Testplan moet worden gemaakt. Dit plan moet de regressieteststrategie en de exitcriteria schetsen. Prestatietests maken ook deel uit van deze test om ervoor te zorgen dat de systeemprestaties niet worden beïnvloed door de wijzigingen die zijn aangebracht in de systeemcomponenten.
Beste praktijken : Voer elke dag 's avonds geautomatiseerde testcases uit, zodat eventuele regressie-bijwerkingen de volgende dag kunnen worden verholpen. Op deze manier verkleint het het risico van afgifte door bijna alle regressiedefecten in een vroeg stadium af te dekken in plaats van deze aan het einde van de afgiftecyclus te vinden en op te lossen.
Regressietesttechnieken
Hieronder staan de verschillende technieken vermeld.
- Test alles opnieuw
- Selectie regressietest
- Testcase Prioritering
- Hybride
# 1) Test alles opnieuw
Zoals de naam al doet vermoeden, worden de volledige testgevallen in de testsuite opnieuw uitgevoerd om er zeker van te zijn dat er geen bugs zijn opgetreden vanwege een wijziging in de code. Dit is een dure methode omdat het meer tijd en middelen vereist in vergelijking met de andere technieken.
# 2) Selectie regressietest
Bij deze methode worden testgevallen uit de testsuite geselecteerd om opnieuw uit te voeren. Niet de hele suite wordt opnieuw uitgevoerd. De selectie van testcases gebeurt op basis van codewijziging in de module.
Testcases zijn onderverdeeld in twee categorieën, een is herbruikbare testcases en een andere is verouderde testcases. De herbruikbare testcases kunnen worden gebruikt in toekomstige regressiecycli, terwijl verouderde testcases niet worden gebruikt in de komende regressiecycli.
# 3) Prioritering van testgevallen
Testcases met hoge prioriteit worden eerst uitgevoerd dan degene met gemiddelde en lage prioriteit. De prioriteit van een testcase hangt af van de kriticiteit en de impact ervan op het product en ook van de functionaliteit van het product dat vaker wordt gebruikt.
# 4) Hybride
De hybride techniek is een combinatie van regressietestselectie en testcaseprioritering. In plaats van de hele testsuite te selecteren, selecteert u alleen de testcases die opnieuw worden uitgevoerd, afhankelijk van hun prioriteit.
Hoe een regressietestsuite te selecteren?
De meeste bugs die in de productieomgeving worden aangetroffen, treden op vanwege de aangebrachte wijzigingen of bugs die op het elfde uur zijn opgelost, d.w.z. de wijzigingen die in een later stadium zijn gedaan. De bugfix in de laatste fase kan andere problemen / bugs in het product veroorzaken. Daarom is regressiecontrole erg belangrijk voordat een product wordt uitgebracht.
Hieronder staat een lijst met testcases die kunnen worden gebruikt tijdens het uitvoeren van deze test:
- Functionaliteiten die veel worden gebruikt.
- Testcases die betrekking hebben op de module waarin de wijzigingen zijn aangebracht.
- Complexe testcases.
- Integratietestcases die alle belangrijke componenten bevatten.
- Testcases voor de kernfunctionaliteit of kenmerk van het product.
- Testcases met prioriteit 1 en prioriteit 2 moeten worden opgenomen.
- Testgevallen die vaak falen of recente testfouten werden in hetzelfde gevonden.
Hoe regressietests uitvoeren?
Nu we hebben vastgesteld wat regressie betekent, is het duidelijk dat het ook aan het testen is - simpelweg herhalen in een specifieke situatie om een specifieke reden. Daarom kunnen we veilig afleiden dat dezelfde methode die in de eerste plaats geldt voor testen ook hier kan worden toegepast.
Daarom, als het testen handmatig kan worden gedaan, kan regressietesten dat ook zijn. Het gebruik van een tool is niet nodig. Naarmate de tijd verstrijkt, worden applicaties echter opgestapeld met steeds meer functionaliteit, waardoor de reikwijdte van regressie blijft toenemen. Om het meeste uit de tijd te halen, is deze test meestal geautomatiseerd
Hieronder worden de verschillende stappen vermeld die nodig zijn om deze test uit te voeren
- Bereid een testsuite voor regressie voor rekening houdend met de punten die worden genoemd in 'Hoe regressietestsuite selecteren'?
- Automatiseer alle testcases van de testsuite.
- Werk de regressiesuite bij wanneer dat nodig is, bijvoorbeeld als er een nieuw defect wordt gevonden dat niet in de testcase wordt gedekt, en een testcase voor hetzelfde moet worden bijgewerkt in de testsuite, zodat het testen de volgende keer niet wordt gemist . De regressietestsuite moet correct worden beheerd door de testgevallen continu bij te werken.
- Voer de regressietestgevallen uit wanneer er een wijziging in de code is, de bug is opgelost, nieuwe functionaliteit is toegevoegd, een verbetering van de bestaande functionaliteit is uitgevoerd, enz.
- Maak een testuitvoeringsrapport met de Pass / Fails-status van de uitgevoerde testcases.
Bijvoorbeeld
Laat me dit uitleggen met een voorbeeld. Bekijk de onderstaande situatie:
Release 1 Statistieken | |
---|---|
Aantal testers | 3 |
Naam van de toepassing | XYZ |
Versie- / releasenummer | een |
Aantal vereisten (toepassingsgebied) | 10 |
Aantal testcases / tests | 100 |
Aantal dagen dat nodig is om te ontwikkelen | 5 |
Aantal dagen dat nodig is om te testen | 5 |
Release 2 Statistieken | |
---|---|
Aantal testers | 3 |
Naam van de toepassing | XYZ |
Versie- / releasenummer | twee |
Aantal vereisten (toepassingsgebied) | 10+ 5 nieuwe vereisten |
Aantal testcases / tests | 100+ 50 nieuw |
Aantal dagen dat nodig is om te ontwikkelen | 2.5 (aangezien dit de helft van de hoeveelheid werk is dan voorheen) |
Aantal dagen dat nodig is om te testen | 5 (voor de bestaande 100 TC's) + 2,5 (voor nieuwe vereisten) |
Release 3 Statistieken | |
---|---|
Aantal testers | 3 |
Naam van de toepassing | XYZ |
Versie- / releasenummer | 3 |
Aantal vereisten (toepassingsgebied) | 10+ 5 + 5 nieuwe vereisten |
Aantal testcases / tests | 100+ 50+ 50 nieuw |
Aantal dagen dat nodig is om te ontwikkelen | 2.5 (aangezien dit de helft van de hoeveelheid werk is dan voorheen) |
Aantal dagen dat nodig is om te testen | 7,5 (voor de bestaande 150 TC's) + 2,5 (voor nieuwe vereisten) |
Hieronder volgen de opmerkingen die we kunnen maken uit de bovenstaande situatie:
- Naarmate de releases groeien, groeit de functionaliteit.
- De ontwikkeltijd groeit niet noodzakelijkerwijs met releases, maar de testtijd wel
- Geen enkel bedrijf / zijn management zal bereid zijn om meer tijd te investeren in testen en minder in ontwikkeling
- We kunnen de tijd die nodig is om te testen niet eens verminderen door de grootte van het testteam te vergroten, want meer mensen betekent meer geld en nieuwe mensen betekent ook veel training en misschien ook een compromis in kwaliteit, omdat de nieuwe mensen misschien niet op één lijn liggen met de vereiste kennis niveaus onmiddellijk.
- Het andere alternatief is duidelijk om de mate van regressie te verminderen. Maar dat kan riskant zijn voor het softwareproduct.
Om al deze redenen is regressietesten een goede kandidaat voor automatiseringstesten, maar het hoeft niet alleen zo te gebeuren.
Basisstappen om regressietests uit te voeren
Elke keer dat de software een wijziging ondergaat en er een nieuwe versie / release komt, zijn de volgende stappen die u kunt nemen om dit type testen uit te voeren:
- Begrijp wat voor soort wijzigingen er in de software zijn aangebracht
- Analyseer en bepaal welke modules / delen van de software mogelijk worden beïnvloed - de ontwikkelingsteams en BA-teams kunnen behulpzaam zijn bij het verstrekken van deze informatie
- Bekijk uw testcases en bepaal of u een volledige, gedeeltelijke of unit-regressie moet doen. Identificeer degene die bij uw situatie passen
- Plan de tijd en test weg!
Regressie in Agile
Behendig is een adaptieve benadering die een iteratieve en incrementele methode volgt. Het product is ontwikkeld in korte iteraties genaamd sprint die 2-4 weken duurt. In agile zijn er een aantal iteraties, daarom speelt deze test een belangrijke rol als de nieuwe functionaliteit of codewijziging wordt uitgevoerd in de iteraties.
De regressietestsuite moet worden voorbereid vanaf de beginfase en moet bij elke sprint worden bijgewerkt.
In Agile valt regressiecheck onder twee categorieën:
- Regressie op sprintniveau
- Einde om regressie te beëindigen
# 1) Regressie op sprintniveau
Regressie op sprintniveau wordt voornamelijk gedaan voor de nieuwe functionaliteit of de verbetering die in de laatste sprint is aangebracht. Testcases uit de testsuite worden geselecteerd volgens de nieuw toegevoegde functionaliteit of de verbetering die is aangebracht.
# 2) End-to-end regressie
End-to-end regressie omvat alle testcases die opnieuw moeten worden uitgevoerd om het complete product end-to-end te testen door alle kernfunctionaliteiten van het product te bestrijken.
Omdat Agile korte sprints heeft en het maar doorgaat, is het hard nodig om de testsuite te automatiseren, worden de testcases opnieuw uitgevoerd en ook dat moet in korte tijd worden afgerond. Het automatiseren van de testcases vermindert de tijd van uitvoering en het wegglijden van defecten.
Voordelen
Hieronder staan de verschillende voordelen van regressietest vermeld
- Het verbetert de kwaliteit van het product.
- Het zorgt ervoor dat eventuele bugfixes of verbeteringen die worden aangebracht geen invloed hebben op de bestaande functionaliteit van het product.
- Voor deze tests kunnen automatiseringshulpmiddelen worden gebruikt.
- Het zorgt ervoor dat problemen die al zijn opgelost, niet opnieuw optreden.
Nadelen
Hoewel er verschillende voordelen zijn, zijn er ook enkele nadelen. Zij zijn:
- Het moet ook worden gedaan voor een kleine wijziging in de code, omdat zelfs een kleine wijziging in de code problemen kan veroorzaken in de bestaande functionaliteit.
- Als voor deze tests geen automatisering in het project wordt gebruikt, zal het een tijdrovende en vervelende taak zijn om de testcases steeds opnieuw uit te voeren.
Regressie van GUI-applicatie
Het is moeilijk om een GUI (Graphical User Interface) regressietest uit te voeren wanneer de GUI-structuur is gewijzigd. De testcases die in de oude GUI zijn geschreven, zijn verouderd of moeten worden aangepast.
Hergebruik van de regressietestcases betekent dat GUI-testcases worden aangepast aan de nieuwe GUI. Maar deze taak wordt omslachtig als u een groot aantal GUI-testcases heeft.
Verschil tussen regressie en opnieuw testen
Opnieuw testen wordt gedaan voor de testgevallen die mislukken tijdens de uitvoering en de bug die hiervoor is opgeworpen is verholpen, terwijl regressiecontrole niet beperkt is tot de bugfix, maar ook andere testgevallen omvat om ervoor te zorgen dat de bugfix niet enige andere functionaliteit van het product beïnvloed.
Regressietestplan-sjabloon (TOC)
1. Documentgeschiedenis
2. Referenties
3. Regressietestplan
3.1. Invoering
3.2. Doel
3.3. Teststrategie
3.4. Functie om te testen
3.5. Vereiste middelen
3.5.1. Hardwarevereisten
3.5.2. Softwarevereiste
3.6. Testschema
3.7. Verzoek wijzigen
3.8. In- / uitstapcriteria
3.8.1. Toegangscriteria voor deze toetsing
3.8.2. Exit Criteria voor deze test
3.9. Aanname / beperkingen
3.10. Testgevallen
3.11. Risico / veronderstellingen
3.12. Gereedschap
4. Goedkeuring / acceptatie
Laten we ze allemaal in detail bekijken.
# 1) Documentgeschiedenis
De documentgeschiedenis bestaat uit een record van het eerste concept en alle bijgewerkte versies in het onderstaande formaat.
Versie | Datum | Auteur | Commentaar |
---|---|---|---|
een | DD / MM / JJ | abc | Goedgekeurd |
twee | DD / MM / JJ | abc | Bijgewerkt voor de toegevoegde functie |
# 2) Referenties
De kolom Referenties houdt een overzicht van alle referentiedocumenten die voor het project zijn gebruikt of vereist tijdens het maken van een testplan.
Nee | Document | Plaats |
---|---|---|
een | SRS-document | Gedeelde rit |
# 3) Regressietestplan
3.1. Invoering
Dit document beschrijft de wijziging / update / verbetering van het te testen product en de aanpak die voor deze tests wordt gebruikt. Alle codewijzigingen, verbeteringen, updates en toegevoegde functies worden beschreven om te worden getest. Testcases die worden gebruikt voor Unit Testing en Integration Testing kunnen worden gebruikt om een testsuite voor regressie te maken.
3.2. Doel
Het doel van het regressietestplan is om te beschrijven wat precies en hoe het testen zou worden uitgevoerd om de resultaten te bereiken. Er wordt een regressiecontrole uitgevoerd om ervoor te zorgen dat geen enkele andere functionaliteit van het product wordt belemmerd door de codewijziging.
3.3. Teststrategie
Teststrategie beschrijft de aanpak die zal worden gebruikt om deze test uit te voeren en die omvat de techniek die zal worden gebruikt, wat de voltooiingscriteria zullen zijn, wie welke activiteit zal uitvoeren, wie de testscripts zal schrijven, welke regressietool zal worden gebruikt , stappen om de risico's af te dekken, zoals een tekort aan middelen, vertraging in de productie, enz.
3.4. Functies om te testen
Functie / componenten van het te testen product worden hier vermeld. Bij regressie worden alle testcases opnieuw uitgevoerd of worden degene die de bestaande functionaliteit beïnvloeden gekozen, afhankelijk van de uitgevoerde fix / update of verbetering.
3.5. Vereiste middelen
3.5.1. Hardwarevereiste:
Hardwarevereisten worden hier geïdentificeerd, zoals computers, laptop, modems, Macbook, smartphone, enz.
3.5.2. Softwarevereiste:
Softwarevereiste wordt geïdentificeerd, zoals welk besturingssysteem en browsers vereist zijn.
3.6. Testschema
Testschema definieert de geschatte tijd voor het uitvoeren van de testactiviteiten.
Bijvoorbeeld Hoeveel resources zullen een testactiviteit uitvoeren en ook dat in hoeveel tijd?
3.7. Verzoek wijzigen
CR-details worden vermeld waarvoor regressie zou worden uitgevoerd.
S.No | CR Beschrijving | Regressie Test Suite |
---|---|---|
een | ||
twee |
3.8. Criteria voor binnenkomst / vertrek
3.8.1. Toegangscriteria voor deze toetsing:
Er zijn toegangscriteria gedefinieerd voor het product om de regressiecontrole te starten.
Bijvoorbeeld:
- Coderingswijzigingen / verbetering / toevoeging van nieuwe functie moeten worden voltooid.
- Het regressietestplan moet worden goedgekeurd.
3.8.2. Exit Criteria voor deze test:
Hier worden de exitcriteria voor regressie gedefinieerd.
Bijvoorbeeld:
- Regressietests moeten worden voltooid.
- Alle nieuwe kritieke bugs die tijdens deze test worden gevonden, moeten worden afgesloten.
- Testrapport moet klaar zijn.
3.9. Testgevallen
Regressietestgevallen worden hier gedefinieerd.
3.10. Risico / veronderstellingen
Alle risico's en aannames worden geïdentificeerd en hiervoor wordt een noodplan opgesteld.
3.11. Gereedschap
Hulpmiddelen die in het project worden gebruikt, worden geïdentificeerd. Zoals:
- Automatiseringstool
- Bugrapportage tool
# 4) Goedkeuring / acceptatie
Namen en aanduidingen van de mensen worden hier vermeld:
Naam | Goedgekeurd / afgewezen | Handtekening | Datum |
---|---|---|---|
Gevolgtrekking
Regressietesten is een van de belangrijkste aspecten, omdat het helpt om een kwaliteitsproduct te leveren door ervoor te zorgen dat elke wijziging in de code, of deze nu klein of groot is, geen invloed heeft op de bestaande of oude functionaliteit.
Er zijn veel automatiseringstools beschikbaar voor het automatiseren van de regressietestgevallen, maar er moet een tool worden geselecteerd volgens de projectvereisten. Een tool moet de mogelijkheid hebben om de testsuite bij te werken, aangezien de regressietestsuite regelmatig moet worden bijgewerkt.
Daarmee sluiten we dit onderwerp af en hopen we dat er vanaf nu veel meer duidelijkheid over het onderwerp zal zijn.
Laat ons uw regressiegerelateerde vragen en opmerkingen weten. Hoe heeft u uw regressietesttaken aangepakt?
Bezoek hier voor een complete serie testplannen
Aanbevolen literatuur
- Beste softwaretesttools 2021 [QA Test Automation Tools]
- Top 10 meest populaire tools voor regressietesten in 2021
- Wat is betrouwbaarheidstesten: definitie, methode en hulpmiddelen
- 11 beste automatiseringstools voor het testen van Android-applicaties (Android App Testing Tools)
- Geautomatiseerde regressietests: uitdagingen, processen en stappen
- Primer eBook downloaden testen
- Verschil tussen hertesten en regressietesten met voorbeeld
- Top 10+ beste SAP-testtools (SAP Automation Tools)