Softwaretesttechnieken met voorbeelden van testcaseontwerpen

Wat is een softwaretesttechniek?

Softwaretesttechnieken helpen u bij het ontwerpen van betere testcases. Omdat grondig testen niet mogelijk is, helpen handmatige testtechnieken het aantal uit te voeren testcases te verminderen en tegelijkertijd de testdekking te vergroten. Ze helpen testcondities te identificeren die anders moeilijk te herkennen zijn. Softwaretesttechnieken kunnen worden onderverdeeld in de volgende typen:

• Grenswaardeanalyse
• Equivalentieklasse-partitionering
• Beslissingstabelgebaseerd testen
• Staatsovergang
• Fout bij raden

👉 Schrijf je gratis in voor een live softwaretestproject

De 7 principes van softwaretesttechnieken

Softwaretesttechnieken volgen een reeks principes om het testproces uit te voeren. Deze 7 principes helpen testers bij het effectief plannen, ontwerpen en uitvoeren van tests. Deze principes zorgen ervoor dat testen doelgericht, efficiënt en afgestemd op de projectdoelen blijft.

De 7 principes van softwaretesttechnieken zijn Testen toont de aanwezigheid van defecten aan, grondig testen is onmogelijk, vroegtijdig testen bespaart tijd en kosten, defecten Clustering, pesticideparadox, testen is contextafhankelijk en de afwezigheid-van-fouten-misvatting. U kunt op het volgende klikken link om meer te leren.

Hoe transformeert AI traditionele softwaretesttechnieken?

AI is revolutioniserende softwaretesten door introductie automatisering, voorspelling en aanpassingsvermogen. Het maakt mogelijk geautomatiseerde testcasegeneratie vanuit natuurlijke taal met behulp van LLM's, zelfherstellende scripts die zich aanpassen aan veranderingen in de gebruikersinterface, en voorspellende defectanalyse gebaseerd op historische gegevens. AI ondersteunt ook risicogebaseerde prioritering, visuele tests, en autonome testuitvoering binnen CI/CD-pijplijnen. Via natuurlijke taalinterfaces, Testers kunnen cases op een conversatiewijze creëren, waardoor workflows worden versneld. In essentie maakt AI testen mogelijk. slimmer, sneller en veerkrachtiger, Verminder de handmatige inspanning en verbeter tegelijkertijd de nauwkeurigheid en dekking in moderne, evoluerende toepassingen.

Software testtechnieken

Grenswaardeanalyse (BVA)

Randwaardeanalyse is gebaseerd op testen op de grenzen tussen partities. Het omvat maximum-, minimum-, binnen- of buitengrenzen, typische waarden en foutwaarden.

Empirisch bewijs toont aan dat veel defecten zich voordoen nabij grenswaarden in plaats van bij waarden in het middenbereik. Dit staat ook bekend als BVA en biedt een selectie van testcases die grenswaarden testen.

Deze black-box-testtechniek vormt een aanvulling op Equivalence Partitioning door zich te richten op de randgevallen van dezelfde invoerbereiken. Deze softwaretesttechniek is gebaseerd op het principe dat als een systeem correct werkt voor grenswaarden, het waarschijnlijk ook werkt voor alle waarden binnen dat bereik.

Richtlijnen voor grenswaardeanalyse

• Als een invoervoorwaarde beperkt is tussen de waarden x en y, dan moeten de testgevallen worden ontworpen met waarden x en y, en met waarden die boven en onder x en y liggen.
• Als een invoervoorwaarde een groot aantal waarden bevat, moet de testcase worden ontwikkeld om de minimum- en maximumwaarden te testen. Hierbij worden ook waarden boven en onder de minimum- en maximumwaarden getest.
• Pas richtlijnen 1 en 2 toe op de uitvoervoorwaarden. Dit levert een uitvoer op die de verwachte minimum- en maximumwaarden weerspiegelt. Het test ook de waarden onder of boven de waarden.

Voorbeeld:

Input condition is valid between 1 to 10

Boundary values 0,1,2 and 9,10,11

Equivalentieklasse-partitionering

Equivalence Class Partitioning verdeelt de set invoervoorwaarden in groepen waarvan verwacht wordt dat ze vergelijkbaar gedrag opleveren. Deze softwaretestmethode verdeelt het invoerdomein van een programma in gegevensklassen waaruit testcases moeten worden ontworpen.

Het concept achter deze testcase-ontwerptechniek is dat een testcase van een representatieve waarde van elke klasse gelijk is aan een test van een andere waarde van dezelfde klasse. Hiermee kunt u zowel geldige als ongeldige equivalentieklassen identificeren.

Voorbeeld:

Invoervoorwaarden zijn geldig tussen

 1 to 10 and 20 to 30

Er zijn dus vijf equivalentieklassen

--- to 0 (invalid)
1 to 10 (valid)
11 to 19 (invalid)
20 to 30 (valid)
31 to --- (invalid)

U selecteert waarden uit elke klasse, dat wil zeggen:

-2, 3, 15, 25, 45

Lees ook meer over – Grenswaardeanalyse en gelijkwaardigheidspartitioneringstesten

Beslissingstabelgebaseerd testen

Een beslissingstabel wordt ook wel een oorzaak-gevolgtabel genoemd. Deze softwaretesttechniek wordt gebruikt voor functies die reageren op een combinatie van invoer of gebeurtenissen. In een formuliervalidatiescenario wordt de knop 'Verzenden' bijvoorbeeld pas geactiveerd nadat alle verplichte velden zijn ingevuld.

De eerste taak is het identificeren van functionaliteiten waarbij de uitvoer afhankelijk is van een combinatie van invoer. Als er een grote invoerset met combinaties is, verdeel deze dan in kleinere subsets. Dit is handig voor het beheren van een beslissingstabel.

Voor elke functie moet u een tabel maken en alle soorten combinaties van invoer en de bijbehorende uitvoer vermelden. Dit helpt bij het identificeren van een situatie die de tester over het hoofd ziet.

Hieronder volgen de stappen voor het maken van een beslissingstabel:

• Zet de invoer in rijen in
• Voer alle regels in de kolom in
• Vul de tabel met de verschillende combinaties van invoer
• Noteer in de laatste rij de uitvoer ten opzichte van de invoercombinatie.

Voorbeeld:Een verzendknop in een contactformulier wordt alleen ingeschakeld als alle gegevens door de eindgebruiker zijn ingevoerd.

Staatsovergang

Bij de State Transition-techniek veranderen wijzigingen in invoervoorwaarden de status van de Application Under Test (AUT). Met deze testtechniek kan de tester het gedrag van een AUT testen. De tester kan deze actie uitvoeren door verschillende invoervoorwaarden achter elkaar in te voeren. Bij de State Transition-techniek levert het testteam zowel positieve als negatieve invoerwaarden om het systeemgedrag te evalueren.

Richtlijn voor staatstransitie:

• Statusovergang moet worden gebruikt wanneer een testteam de applicatie test op een beperkte set invoerwaarden.
• De Test Case Design-techniek moet worden gebruikt wanneer het testteam een ​​reeks gebeurtenissen wil testen die plaatsvinden in de te testen toepassing.

Voorbeeld:

In het volgende voorbeeld kan de gebruiker succesvol inloggen door binnen drie pogingen een geldig wachtwoord in te voeren. Als de gebruiker bij de eerste of tweede poging een ongeldig wachtwoord invoert, wordt de gebruiker gevraagd het wachtwoord opnieuw in te voeren. Wanneer de gebruiker het wachtwoord onjuist invoert,^rd Zodra dit is gebeurd, wordt de actie ondernomen en wordt het account geblokkeerd.

Staatsovergangsdiagram

In dit diagram wordt de gebruiker, wanneer hij of zij de juiste pincode invoert, doorgestuurd naar de status 'Toegang verleend'. De volgende tabel is gebaseerd op het bovenstaande diagram:

Staatsovergangstabel

	Correcte pincode	Onjuiste pincode
S1) Begin	S5	S2
S2) 1st poging	S5	S3
S3) 2nd poging	S5	S4
S4) 3rd poging	S5	S6
S5) Toegang verleend	-	-
S6) Account geblokkeerd	-	-

In de bovenstaande tabel verandert de status naar Toegang verleend wanneer de gebruiker de juiste pincode invoert. Voert de gebruiker een onjuist wachtwoord in, dan gaat hij of zij naar de volgende status. Doet hij of zij hetzelfde, dan gaat de status naar 3.^rd keer zal hij de geblokkeerde status van het account bereiken.

Fout bij raden

Fout bij raden is een softwaretesttechniek waarbij testers ervaring en intuïtie gebruiken om waarschijnlijke fouten in de code te voorspellen. De techniek is sterk gebaseerd op ervaring, waarbij testanalisten hun ervaring gebruiken om het problematische deel van de testapplicatie te raden. Testanalisten moeten daarom bekwaam en ervaren zijn om fouten beter te kunnen raden.

De techniek telt een lijst met mogelijke fouten of foutgevoelige situaties. Vervolgens schrijft de tester een testcase om die fouten bloot te leggen. Om testcases te ontwerpen op basis van deze softwaretesttechniek, kan de analist eerdere ervaringen gebruiken om de voorwaarden te identificeren.

Richtlijnen voor het raden van fouten:

• Bij de test moet gebruik worden gemaakt van de eerdere ervaring met het testen van soortgelijke toepassingen
• Inzicht in het geteste systeem
• Kennis van typische implementatiefouten
• Denk aan eerder probleemgebieden
• Evalueer historische gegevens en testresultaten

Voordelen en beperkingen van testtechnieken

Voordelen:

• Verbetert de testdekking en zorgt voor een bredere validatie van softwarefunctionaliteit.
• Verbetert de detectie van defecten door te focussen op gebieden met een hoog risico of die gevoelig zijn voor fouten.
• Promosystematisch testontwerp, waardoor redundantie en overlapping worden verminderd.
• Helpt problemen vroegtijdig in de SDLC te identificeren, waardoor de totale projectkosten worden verlaagd.
• Vereenvoudigt complexe tests met methoden zoals BVA en Equivalence Partitioning.
• Verhoogt de betrouwbaarheid van software en het vertrouwen van belanghebbenden in de productkwaliteit.

Beperkingen:

• Er bestaat geen enkele techniek die volledige defectdetectie garandeert.
• Bij sommige technieken is de ervaring en het oordeel van de tester erg afhankelijk.
• Integratie-, bruikbaarheids- of echte prestatieproblemen kunnen over het hoofd worden gezien.
• Beperkingen in tijd en middelen kunnen een grondige toepassing beperken.
• Bepaalde methoden bieden beperkte ondersteuning voor automatisering, waardoor de schaalbaarheid wordt beperkt.

Hoe kiest u de juiste testtechnieken?

Het kiezen van de juiste softwaretesttechnieken vereist dat deze worden afgestemd op de projectspecificaties om efficiëntie en dekking te garanderen. Factoren zoals het ontwikkelmodel, risico's en resources bepalen het selectieproces. Als ervaren softwaretester raad ik altijd aan om meerdere technieken te combineren voor optimale resultaten. Dit voorkomt de kans op overmatige afhankelijkheid van één methode.

• Afstemmen op doelstellingen: Stem technieken af ​​op doelen zoals functionaliteit, prestaties of beveiligingsbehoeften.
• Beoordeel risico's: Geef prioriteit aan gebieden met een hoog risico met behulp van risicogebaseerde methoden voor gerichte validatie.
• Architectuur en model aanpassen: Kies voor agile-vriendelijke benaderingen in iteratieve of meerlaagse systemen.
• Balansbeperkingen: Houd rekening met tijd, budget, vaardigheden en hulpmiddelen voor een haalbare uitvoering.

Veelgestelde vragen