Testanalyse en basisprincipes van testen
Thomas Hamilton
⚡ Slimme samenvatting
Testanalyse, ook wel testbasis genoemd, is de gestructureerde beoordeling van eisen, ontwerpdocumenten en andere artefacten die worden gebruikt om testbare voorwaarden af te leiden. Dit artikel beschrijft de bronnen, de stapsgewijze workflow en de plaatsing van testanalyse in het V-model.
Testanalyse — ook wel testbasis genoemd — staat helemaal aan het begin van de testlevenscyclus. Elke testconditie en elk testgeval wordt uiteindelijk geanalyseerd. tracLaten we er weer op terugkomen. De onderstaande secties definiëren de term, leggen de bronnen ervan uit, beschrijven de analyseworkflow en plaatsen deze in het V-model.
Wat is testanalyse?
Testanalyse In softwaretesten is het het proces van het beoordelen van de input die gebruikt wordt om testcondities en testgevallen af te leiden. Deze input – specificaties, vereisten, ontwerpdocumenten, gebruikersverhalen en vergelijkbare deliverables – worden gezamenlijk genoemd testartefactenHet doel van testanalyse is om te onderzoekentracDe testdoelstellingen zijn duidelijk genoeg dat elk ervan kan worden omgezet in een ondubbelzinnige testconditie. Omdat het geanalyseerde materiaal de basis vormt voor alle tests, wordt het ook wel de Testbasis.
Typische bronnen waaruit testers testinformatie halen, zijn onder andere:
- SRS — Softwarevereistenspecificatie
- BRS — Bedrijfsvereistenspecificatie
- Functionele ontwerpdocumenten
- Gebruikersverhalen, acceptatiecriteria en wireframes
Testers kunnen ook testomstandigheden genereren door de te testen applicatie direct te verkennen of door gebruik te maken van eerdere ervaringen, maar de meeste testers doen dat op een andere manier. testgevallen worden afgeleid van testartefacten om te onderhouden traceability.
👉 Schrijf je gratis in voor een live softwaretestproject
Waarom is Test Basis belangrijk?
De testbasis is de belangrijkste factor die bepaalt of een testsuite daadwerkelijke defecten opspoort of alleen maar spookdefecten. Het als optioneel beschouwen van de testbasis is de meest voorkomende oorzaak dat onopgemerkte bugs in productie terechtkomen. Een gedegen testanalyse levert vier concrete voordelen op:
- Tracgeschiktheid: Elke testcase kan worden gekoppeld aan een specifieke vereiste, waardoor impactanalyses van wijzigingen snel verlopen en auditbeoordelingen probleemloos verlopen.
- Duidelijkheid van de berichtgeving: RevHet in kaart brengen van de hiaten in de basisstructuur — ongespecificeerde fouttoestanden, ontbrekende randgevallen, ongedefinieerde niet-functionele drempelwaarden — voordat ze zich voordoen bij productieproblemen.
- Uitlijning van belanghebbenden: Wanneer het testteam de testomstandigheden afleidt uit dezelfde documenten als het ontwikkelteam, hanteren beide partijen een gedeelde definitie van "klaar".
- Vroegtijdige detectie van defecten: Veel eisenfouten (dubbelzinnigheden, tegenstrijdigheden, ontbrekende acceptatiecriteria) worden al tijdens de testanalyse ontdekt, ruim voordat er code wordt geschreven – verreweg de goedkoopste manier om ze te verhelpen.
Veelvoorkomende bronnen van testbasis
Verschillende artefacten leveren input voor verschillende testniveaus. Gebruik de onderstaande tabel als snel naslagwerk om te bepalen welk document u moet raadplegen bij het schrijven van testgevallen.
| Bronartefact | Best geschikt voor | Wat je Extract |
|---|---|---|
| Specificatie bedrijfsvereisten (BRS) | Acceptatie- en systeemtesten | Bedrijfsregels van begin tot eind, wettelijke beperkingen, succescriteria |
| Specificatie softwarevereisten (SRS) | Systeem testen | Functionele en niet-functionele eisen met meetbare drempelwaarden |
| Functionele/technische ontwerpdocumenten | Integratietesten | Module-interfaces, gegevensstroom, specificaties voor foutafhandeling |
| Gebruikersverhalen en acceptatiecriteria | Agile sprinttesten | Gedragsverwachtingen in de vorm "Gegeven-Wanneer-Dan" |
| Wireframes en UI-mockups | UI-/gebruiksvriendelijkheidstesten | Lay-out, navigatie, regels voor invoervalidatie |
| Applicatie in testfase (verkennend) | Verkennende en regressietests | Niet-gedocumenteerd gedrag, werkprocessen in de praktijk, uitzonderlijke gevallen |
Stapsgewijze handleiding voor het uitvoeren van testanalyses
Effectieve testanalyse volgt een herhaalbaar vijfstappenplan, ongeacht de omvang van het project of de gebruikte methodologie.
- Verzamel en inventariseer de testbasis. Verzamel alle documenten die het beoogde gedrag beschrijven: SRS, BRS, ontwerpdocumenten, user stories, mockups. Noteer welk document bij elke vereiste hoort. tracDe levensvatbaarheid blijft intact.
- Revbeoordeling voor testbaarheid. Lees elk document met drie vragen in gedachten: Is deze bewering meetbaar? Is deze ondubbelzinnig? Is deze volledig? Markeer elke eis die niet aan een van deze criteria voldoet en stuur deze terug naar de auteur voordat je er tests voor schrijft.
- Bepaal de testomstandigheden. Geef voor elke testbare bewering een lijst van de voorwaarden die geverifieerd moeten worden (positieve paden, negatieve paden, grenswaarden, foutafhandeling, beveiliging, prestaties). Een testvoorwaarde is de absolute waarde.tract “wat” — bijvoorbeeld, “Het systeem weigert bestellingen met een hoeveelheid van nul.” — iets wat verschilt van het concrete "hoe" van een testgeval.
- Prioriteer en groepeer de aandoeningen. Classificeer elke conditie op basis van risico en gebruiksfrequentie. Condities met een hoog risico en een hoge frequentie krijgen een gedetailleerde beschrijving; condities met een laag risico kunnen worden gecombineerd of steekproefsgewijs worden geanalyseerd. Hier bepaalt u ook welke condities geschikt zijn voor automatisering.
- Zet voorwaarden om in testgevallen. Elke prioriteitsconditie wordt een of meer testgevallen met randvoorwaarden, stappen, testgegevens en verwachte resultaten. Houd een eisenlijst bij. tracEen geschiktheidsmatrix die elk testgeval koppelt aan de oorspronkelijke vereiste.
Door deze volgorde te volgen, worden de meest voorkomende fouten bij testanalyse vermeden: het schrijven van testgevallen zonder duidelijke basis, het missen van negatieve scenario's en het produceren van tests die tijdens de defectanalyse niet aan een vereiste kunnen worden gekoppeld.
Testanalyse in het V-model
Het V-model koppelt elke ontwikkelactiviteit aan een corresponderende testactiviteit. Testanalyse vindt op elk niveau plaats met behulp van het document dat op dat moment in de levenscyclus beschikbaar is.
Figuur 1: Testanalyse over de fasen van de V-model.
Casestudy: Testgevallen afleiden uit een klantvereiste
Stel je een scenario voor waarin de klant de volgende eis van één regel verstuurt.
Client requirement: Add search functionality to an eCommerce Store
Hoewel de applicatie nog niet gebouwd is, kan een tester al verschillende testcondities afleiden door te analyseren wat de vereisten inhouden – zowel het gewenste resultaat als de mogelijke fouten die de klant niet expliciet heeft vermeld. Enkele voorbeelden zijn:
- Controleer het zoekresultaat wanneer er geen zoekwoord is ingevoerd.
- Controleer het zoekresultaat als er geen overeenkomend product is voor het ingevoerde zoekwoord.
- Controleer het zoekresultaat wanneer er meerdere overeenkomende producten voor het zoekwoord bestaan.
- Controleer het gedrag met speciale tekens, spaties aan het begin en einde van een invoer en zeer lange invoer.
- Controleer de hoofdlettergevoeligheid en het gedrag bij gedeeltelijke overeenkomsten.
- Controleer de zoekresponstijd onder de verwachte gebruikersbelasting.
De tester neemt de klantvereiste (de testbasis), analyseert deze en zet deze om in testcondities. Dit patroon herhaalt zich in elke fase van het V-model: testplannen en testgevallen worden gemaakt op basis van het document dat op dat moment in de levenscyclus beschikbaar is.
Video: Testanalyse uitgelegd
Als de video niet laadt, bekijk hem dan direct op YouTube.
