how classify positive
Je kunt iets op de gemakkelijke of moeilijke manier doen - het belangrijkste is dat je het doet. Er zijn maar weinig simpele alledaagse dingen, maar zonder vertrouwen past er iets niet helemaal in ons hoofd en is de mate van succes een schot in de roos.
Laten we vandaag een eenvoudig voorbeeld nemen en snelkoppelingen vinden die niet alleen de concepten verduidelijken, maar er ook voor zorgen dat u het altijd goed doet.
Positieve of negatieve classificatie van testscenario's / cases
Het testontwerpproces is drievoudig:
- Identificeer vereisten
- Schrijf testscenario's (aanwijzingen in één regel van wat te testen)
- Ontwerp gedetailleerde instructies voor het testen (testcases)
Bij het schrijven van testscenario's classificeren we deze in positieve en negatieve omstandigheden. (Als je erover nadenkt, is het dan echt belangrijk om deze classificatie te maken? Zo ja, met welk doel dient het? We moeten ze toch allemaal testen, nietwaar?) Het verslaat mij ook grotendeels. Maar ik denk dat het een poging is om voldoende dekking vast te stellen en helpt om vast te stellen dat we zowel de gelukkige als de alternatieve paden testen die het systeem verondersteld wordt af te handelen. Geef hieronder uw commentaar als u andere redenen kent waarom dit wordt gedaan.
Laten we nu eens kijken naar enkele vereisten, testscenario's schrijven en de classificatie uitvoeren.
# 1) Inloggen Een gebruiker die de juiste inloggegevens invoert, komt in het systeem. Als de inloggegevens onjuist zijn, wordt de toegang geweigerd en wordt er een foutbericht weergegeven.
# 2) Bekijk producten: Laten we aannemen dat er een online catalogus is van alle producten die in het systeem beschikbaar zijn en dat deze allemaal in een lijst worden weergegeven wanneer op de link 'Bekijk producten' wordt geklikt.
# 3) Uitloggen: Wanneer op deze link wordt geklikt, wordt de gebruiker uitgelogd.
Ik ga enkele testscenario's schrijven voor deze vereisten.
Tabel A:De goede weg
Testscenario-ID | Beschrijving testscenario | Positief negatief |
---|---|---|
TS_login_01 | Controleer of de gebruiker zich heeft aangemeld als de ingevoerde gegevens correct zijn | Positief |
TS_login_02 | Valideer of de gebruiker geen toegang heeft als de ingevoerde inloggegevens onjuist zijn | Negatief |
TS_ViewProduct_01 | Valideer of alle items worden vermeld wanneer op de link Producten bekijken wordt geklikt | Positief |
TS_logout_01 | Controleer of de reeds aangemelde gebruiker is afgemeld bij het systeem wanneer op uitloggen wordt geklikt | Positief |
Soms zie ik het Testscenario echter zo geschreven.
Tabel B: Inzendingen gemarkeerdNettozijn ongeldige testscenario's.
Testscenario-ID | Beschrijving testscenario | Positief negatief |
---|---|---|
TS_login_01 | Controleer of de gebruiker zich heeft aangemeld als de ingevoerde gegevens correct zijn | Positief |
TS_login_02 | Valideer of de gebruiker geen toegang heeft als de ingevoerde inloggegevens onjuist zijn | Negatief |
TS_ViewProduct_01 | Valideer of alle items worden vermeld wanneer op de link Producten bekijken wordt geklikt | Positief |
TS_ViewProduct_02 | Valideer als alle items niet in de lijst staan wanneer op de link Bekijk producten wordt geklikt | Negatief |
TS_logout_01 | Controleer of de reeds aangemelde gebruiker is afgemeld bij het systeem wanneer op uitloggen wordt geklikt | Positief |
TS_logout_02 | Valideer als de gebruiker niet uitlogt wanneer op de uitloglink wordt geklikt | Negatief |
Voor een succesvol geval van inloggen is er een gelijk en tegenovergesteld geval wanneer het niet succesvol zal zijn. Niet alle vereisten zouden zo moeten zijn en voor hen is er echt geen dwang om een negatief scenario te schrijven.
Kort gezegd: niet elke vereiste zou negatieve gevallen moeten hebben.
Als u op dit punt denkt 'Hoe zal ik dat weten' of 'Ik weet het nog steeds niet zeker', is hier een eenvoudig spiekbriefje dat u zal helpen.
defecte levenscyclus bij het testen van software
Als er één generalisatie is die we over applicaties kunnen maken, is dat ze dynamisch zijn. De input (data, clicks, etc.) die we leveren zorgen ervoor dat de applicatie op een bepaalde manier werkt en een bepaalde output genereert.
Een eenvoudige correlatie tussen de input- en outputvariabelen maakt dit gemakkelijk te begrijpen.
Laten we het volgende proberen om in te loggen:
Invoer | Uitvoer | Positief negatief |
---|---|---|
Correct (correcte login-info) | Correct (gebruiker aangemeld) | Positief |
Onjuist (onjuiste inloggegevens) | Correct (een foutmelding) | Negatief |
Correct (correcte login-info) | Onjuist - Inloggen mislukt | Bug / defect |
Onjuist (onjuiste inloggegevens) | Onjuist (systeem logt ze in) - 'Oh, de horror!' | Bug / defect |
U kunt dus aan de bovenstaande tabel zien dat we kunnen zeggen dat we de primaire stroom als positief categoriseren en de alternatieve stroom (ook het juiste gedrag van de applicatie) als negatief wordt gemarkeerd.
De laatste twee gevallen in rood zijn in feite bugs. Testen gaat over het valideren van vereisten en als ze niet werken zoals bedoeld, vinden we bugs. Aangezien we niet valideren op defecten, zijn de laatste twee gevallen ongeldig.
Volg dezelfde gedachtegang en pas deze toe om uit te loggen en producten te bekijken, hier is wat u krijgt.
Invoer | Uitvoer | Positief negatief |
---|---|---|
Uitloggen (klik) | Correct - Logt uit | Positief |
Uitloggen (klik) | Onjuist - blijft aangemeld | Bug / defect |
Bekijk producten (klik) | Correct - Toont producten | Positief |
Bekijk producten (klik) | Onjuist (geen lijst of onjuiste lijstweergave) | Bug / defect |
Zoals u kunt zien, is er voor deze vereisten geen mogelijkheid om een onjuiste invoer op te geven. Daarom hoeven er geen negatieve testscenario's / cases geschreven te worden.
Afsluitende gedachten:
Het systeem kan worden blootgesteld aan positieve of negatieve input. Hoe dan ook, het systeem moet de juiste output genereren. De cases die de neiging hebben om met correcte input te gaan, zijn positief. Degenen die ongeveer correct zijn maar negatieve invoer zijn negatief.
Enkele tips:
# 1) Wanneer een end-to-end testgevallen zijn geschreven voor UAT of zelfs systeemtesten, het zijn altijd de positieve testgevallen die in de flow komen.
#twee) Soms is de classificatie subjectief.Bijvoorbeeld, als ik iets op een site verwijder en ik een bevestigingsbericht ontvang met de vraag 'Weet u zeker dat u dit item wilt verwijderen?' met de opties OK en Annuleren - volgens mij is klikken op annuleren een positief geval. Maar sommigen denken dat het negatief is, omdat de primaire bedoeling van de optie 'Verwijderen' is om de bewerking te verwijderen en niet te annuleren. Het oordeel van een tester speelt dus ook een rol bij de classificatie.
# 3) Voor elk positief geval is er niet altijd een gelijk en tegengesteld negatief geval.
De bovenstaande methode garandeert altijd een correcte classificatie. Probeer het zelf en vertel het me, als dat niet het geval is. :) 'Een shortcut is vaak een verkeerde cut.' - Maar in dit geval is het misschien niet zo!
Raadpleeg => voor een meer formele uitleg van negatieve testen Wat is negatief testen en hoe schrijf je negatieve testcases?
Over de auteur: Dit artikel is geschreven door STH-teamlid Swati S. Volg hier haar live QA-training: ' De beste softwaretesttraining die u ooit zult krijgen!
Laat het ons weten als je dit artikel leuk vond en dat je dergelijke basisconcepten gemakkelijk in de komende artikelen wilt zien.
Uw opmerkingen, vragen, feedback en lezerspubliek worden hier bij STH zeer gewaardeerd en gewaardeerd. Veel plezier met testen!
Aanbevolen literatuur
- Positieve tests: betekenis en verdiensten verklaard met echte testscenario's
- Testcases schrijven voor een inlogpagina (voorbeeldscenario's)
- Wat is negatief testen en hoe schrijf je negatieve testcases?
- Testcases schrijven voor geldautomaten (voorbeeldscenario's)
- Efficiënte Selenium-scripts en scenario's voor probleemoplossing - Selenium-zelfstudie # 27
- Typen migratietests: met testscenario's voor elk type
- QTP Tutorial # 24 - Virtuele objecten en herstelscenario's gebruiken in QTP-tests
- Gezondheidszorgtoepassingen testen - tips en belangrijke testscenario's (deel 2)