Menu

Testuitvoering bij softwaretests: exact proces en plan met voorbeeld

test execution software testing

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Exact proces en plan om testcases uit te voeren met echte voorbeelden.

Vandaag, in onze Minitrainingscursus Software Testen , gaan we door naar de laatste fase van de STLC, de Testuitvoering ​

U kunt de lijst met alle tutorials die in deze gratis QA-trainingsreeks zijn geplaatst, op deze pagina bekijken: End-to-end softwaretesttraining voor een live project.

Testuitvoering is zonder twijfel de belangrijkste en meest ‘gebeurt’ fase in de STLC en ook de volledige ontwikkelingscyclus. De reden is: de bijdrage en het werk van elk team / teamlid wordt hier gevalideerd:

Testuitvoering bij softwaretests

  • Heeft de Business Analist de vereisten correct geïnterpreteerd?
  • Heeft het ontwikkelteam de business requirements vertaald naar functionele requirements en uiteindelijk correct gecodeerd?
  • Heeft de data-architect en DBA's de juiste back-end systemen ontworpen?

Welnu, bij testuitvoering zouden alle antwoorden op deze vragen te vinden zijn. Dat maakt ons, QA's, de helden van het hele softwarebouwproces, nietwaar?​

Testuitvoering is ook het 'Test' -gedeelte van de SDLC.

wat is het beste gratis e-mailaccount

Zodra de testcases zijn geschreven, gedeeld met de BA's en het Dev-team, door hen zijn beoordeeld, worden wijzigingen gemeld aan het QA-team (indien aanwezig), het QA-team maakt de nodige wijzigingen. De testontwerpfase is voltooid. Het gereedmaken van de testcases betekent niet dat we de testrun kunnen starten. We moeten onder andere ook de applicatie gereed hebben.

Wat je leert:

Richtlijnen voor het uitvoeren van tests

Laten we nu een lijst maken van alle dingen die belangrijk zijn om de testuitvoeringfase te begrijpen:

# 1) De bouwen (de code die is geschreven door het ontwikkelteam is verpakt in wat wordt aangeduid als een build - dit is niets anders dan een installeerbaar stuk software (AUT), klaar om te worden geïmplementeerd in een QA-omgeving.) wordt geïmplementeerd (met andere woorden, geïnstalleerd en beschikbaar gesteld) aan de QA-omgeving is een van de belangrijkste aspecten die moeten gebeuren om de testuitvoering te starten.

#twee) Testuitvoering vindt plaats in het QA-omgeving ​Om er zeker van te zijn dat het werk van het ontwikkelteam aan de code niet op dezelfde plek plaatsvindt als waar het QA-team test, is het de algemene praktijk om een ​​speciale Dev- en QA-omgeving te hebben. (Er is ook een productieomgeving om de live-applicatie te hosten).

Dit is in feite om de integriteit van de applicatie in verschillende stadia van de SDLC-levenscyclus te behouden. Anders zijn idealiter alle 3 de omgevingen identiek van aard.

# 3) Grootte van het testteam is niet constant vanaf het begin van het project. Wanneer het testplan wordt gestart, heeft het team mogelijk gewoon een teamleider. Tijdens de testontwerpfase komen enkele testers aan boord. Testuitvoering is de fase waarin het team de maximale omvang heeft bereikt.

# 4) Testuitvoering gebeurt ook in minimaal 2 cycli (3 in sommige projecten). Typisch in elke cyclus worden alle testgevallen (de volledige testsuite) uitgevoerd. Het doel van de eerste cyclus is om blokkerende, kritische defecten en de meeste hoge defecten te identificeren.

Het doel van de tweede cyclus is om resterende hoge en gemiddelde defecten te identificeren, hiaten in de scripts te corrigeren en resultaten te verkrijgen.

# 5) Testuitvoering fase bestaat uit: Uitvoeren van de testscripts + Onderhoud van testscripts (corrigeren van hiaten in de scripts) + Rapportage (defecten, status, metrics, etc.) Daarom worden bij het plannen van deze fase en inspanningen moeten worden geschat rekening houdend met al deze aspecten en niet alleen met de uitvoering van het script.

# 6) Nadat het testscript is voltooid en de AUT is geïmplementeerd - en voordat de uitvoering van de test begint, is er een tussenstap. Dit heet de 'Test Readiness Review (TRR)' ​Dit is een soort overgangsstap die de testontwerpfase zal beëindigen en ons gemakkelijker in de testuitvoering zal brengen.

Raadpleeg deze link voor informatie over deze stap en een voorbeeld van een 'Testgereedheidscontrole-checklist': Checklist voor het testen van software

# 7) Naast de TRR zijn er nog enkele aanvullende controles voordat we ervoor zorgen dat we door kunnen gaan met het accepteren van de huidige build die in de QA-omgeving wordt geïmplementeerd voor testuitvoering.

Dat zijn de Rook- en gezond verstand testen ​Gedetailleerde informatie over wat deze zijn, is op: Wat is een rook- en gezondheidstest?

hoe string-array in java te retourneren

# 8) Na succesvolle afronding van TRR-, Smoke- en Sanity-tests, begint de testcyclus officieel.

# 9) Exploratory Testing zou worden uitgevoerd zodra de build klaar is om te testen. Het doel van deze test is om ervoor te zorgen dat kritieke defecten worden verwijderd voordat de volgende testniveaus kunnen beginnen. Deze verkennende toetsing wordt in de applicatie uitgevoerd zonder testscripts en documentatie. Het helpt ook om vertrouwd te raken met de AUT.

# 10) Net als in de andere fasen van de STLC wordt het werk ook in de Test Execution-fase verdeeld onder teamleden. De indeling kan gebaseerd zijn op module-wijs of testcase-telling of iets anders dat zinvol kan zijn.

#elf) Het primaire resultaat van de testuitvoeringsfase is in de vorm van rapporten, voornamelijk d.w.z. Defectrapport en Testuitvoeringsstatusrapport. Het gedetailleerde proces voor rapportage is te vinden op Testuitvoeringsrapporten.

Nieuwe kolommen in testcases-document

Het Test Case-document wordt nu uitgebreid met de volgende twee kolommen - Status en feitelijk resultaat ​

​ Notitie : Voor live projecttestuitvoering hebben we deze kolommen met testuitvoeringsresultaten toegevoegd en bijgewerkt in de testcases-spreadsheet die hieronder wordt gedownload)

# 1) Statuskolom

Testuitvoering is niets anders dan het gebruik van de teststappen op de AUT, het aanleveren van de testgegevens (zoals geïdentificeerd in het testcase-document) en het observeren van het gedrag van de AUT om te zien of het voldoet aan het verwachte resultaat of niet.

Als het verwachte resultaat niet wordt behaald, kan dit als een defect worden beschouwd. En de status van de testcase wordt 'Mislukt' en als aan het verwachte resultaat wordt voldaan, is de status 'Pass'. Als de testcase om welke reden dan ook niet kan worden uitgevoerd (een bestaand defect of een omgeving die niet ondersteunt), zou de status 'Geblokkeerd' zijn.

De status van een testcase die nog moet worden uitgevoerd, kan worden ingesteld op Geen run / niet uitgevoerd of kan leeg worden gelaten.

  • Als voor een testcase met meerdere stappen het verwachte resultaat van een bepaalde stap (in het midden van de testcase-stappen) niet wordt gehaald, kan de testcase-status daar worden ingesteld op 'Fail' en hoeven de volgende stappen niet te worden uitgevoerd.
  • De status 'Mislukt' kan in rode kleur worden aangegeven, als u er direct de aandacht op wilt vestigen.

# 2) Werkelijke resultaatkolom

Dit is een ruimte waar wij testers kunnen registreren wat de afwijking in het verwachte resultaat is. Als aan het verwachte resultaat is voldaan (of een testcase waarvan de status 'Pass' is), kan dit veld leeg worden gelaten. Omdat, als aan het verwachte resultaat wordt voldaan, dit betekent dat het werkelijke resultaat = verwacht resultaat, wat betekent dat het herschrijven in de werkelijke resultaatkolom een ​​herhaling en redundantie zal zijn.

Een screenshot van de afwijking kan aan deze kolom worden toegevoegd voor meer duidelijkheid over wat het probleem is.

Testuitvoeringsresultaten voor OrangeHRM Live-project

Laten we nu OrangeHRM aanschaffen en de testuitvoering uitvoeren op basis van de bovenstaande richtlijnen.

Hier zijn een paar punten om op te merken:

  • De uitgebreide testcase-sjabloon.
  • Verkennend testen zoals aangegeven dient te worden uitgevoerd zonder testscripts. Dus voel je vrij om de applicatie parallel te testen zoals je wilt.
  • Vanwege de beperkingen die we hebben bij het presenteren van het live-project in de vorm van leesbare inhoud, wordt slechts een beperkt aantal testcases / functionaliteit van de OrangeHRM-applicatie weergegeven in het voorbeeldtemplate voor testuitvoering. Nogmaals, voel je om aan meer te werken voor de meest praktische ervaring.
  • De Sanity- en Smoke-testsuites zijn ook aan het document toegevoegd, om u een idee te geven van wat voor soort testcases in aanmerking komen voor deze fasen.
  • Defecten worden nog niet gelogd, ook al staat de status van sommige testgevallen op 'Fail'. Dit komt omdat het loggen van de defecten de volgende belangrijkste / meest gebruikte factor is in een aspect van ons leven als testers. Dus we willen er in het volgende artikel in detail op ingaan.

Testcases met uitvoeringsresultaten:

samenvoegen sorteer c ++ code

​ Klik hier om het Test Case Execution-document te downloaden.

Het bevat - Uitvoeringsresultaat testcases, rooktesten, gezondheidstesten, verkennende test - spreadsheets

Ten slotte, als een testbeheertool is gebruikt voor het maken en onderhouden van de testcase, kan deze ook worden gebruikt voor het uitvoeren van tests. Het gebruik van een tool maakt het rapporteren eenvoudiger, maar verder is het proces van het uitvoeren van de testgevallen hetzelfde. Bekijk dit artikel om een ​​idee te krijgen van hoe u HP ALM gebruikt voor het uitvoeren van testcases ​

(Klik op de afbeelding voor een vergrote weergave)

ALM voor het resultaat van de testuitvoering

Hiermee komen we aan het einde van een ander interessant onderdeel van het testproces. In het volgende en laatste artikel hiervan gratis online Software Testing QA-training mini-cursus , we zullen in detail kijken naar defecten; afronden van onderwerpen als 'wanneer stoppen met testen', metrics en QA sign-off.

=> QA-training dag 6: Bugtracking, teststatistieken en testafmelden

Laat ons weten hoe het met ons gaat en blijf op de hoogte voor het volgende artikel.

Aanbevolen literatuur

^