Hur man klassificerar positiva och negativa testscenarier - En testares fuskark

how classify positive

Du kan göra något på det enkla eller svåra sättet - det viktiga är att du gör det. Det finns få enkla vardagliga saker, men utan självförtroende passar inte något åt ​​dem i våra sinnen och omfattningen av framgång är en hit eller miss.

Låt oss ta ett enkelt exempel idag och hitta genvägar som inte bara klargör begreppen utan också ser till att du alltid kommer att få rätt.

Positiv eller negativ klassificering av testscenarier / fall

Testdesignprocessen är trefaldig:

• Identifiera krav
• Skriv testscenarier (en rad tips om vad man ska testa)
• Designa detaljerade instruktioner om hur man testar (testfall)

När vi skriver testscenarier klassificerar vi dem i positiva och negativa förhållanden. (När du tänker på det, är det verkligen viktigt att göra denna klassificering? Om ja, vilket syfte tjänar det? Vi måste testa dem alla ändå, eller hur?) Det slår mig också för det mesta. Men jag tror att det är ett försök att skapa tillräcklig täckning och hjälper till att fastställa att vi testar både de glada och alternativa vägar som systemet ska hantera. Kommentera nedan om du känner till andra skäl till varför detta görs.

Nu ska vi titta på några krav, skriva testscenarier och utföra klassificeringen.

# 1) Logga in :En användare som anger korrekta referenser kommer in i systemet. Om uppgifterna är felaktiga nekas åtkomst och ett felmeddelande visas.

# 2) Visa produkter: Låt oss anta att det finns en online-katalog över alla produkter som är tillgängliga i systemet och den visar dem alla i en lista när du klickar på länken 'Visa produkter'.

# 3) Logga ut: När man klickar på den här länken loggas användaren ut.

Jag ska skriva några testscenarier för dessa krav.

Tabell A:Den rätta vägen

Ibland ser jag dock testscenariot skrivet så här.

Tabell B: Inlägg markeradeNettoär ogiltiga testscenarier.

För inloggningens framgångsrika ärende finns det ett lika och motsatt fall när det inte kommer att lyckas. Inte alla krav ska vara så och för dem finns det egentligen ingen tvång att skriva ett negativt scenario.

Slutsats: Inte alla krav borde ha negativa fall.

Vid denna punkt, om du tänker 'Hur vet jag' eller 'Jag är fortfarande inte säker', här är ett enkelt fuskark som hjälper.

vad är swf-fil hur man öppnar den

Om det finns en generalisering vi kan göra om applikationer är att de är dynamiska. Ingången (data, klick, etc.) som vi tillhandahåller kommer att orsaka att applikationen blir ett visst sätt och genererar en viss utdata.

En enkel korrelation mellan ingångs- och utgångsvariablerna gör det lätt att förstå.

Låt oss prova följande för inloggning:

Så du ser från ovanstående tabell kan vi säga att vi kategoriserar det primära flödet som positivt och det alternativa flödet (även det korrekta beteendet för applikationen) markeras som negativt.

De två sista fallen i rött är faktiskt buggar. Testning handlar om validering av krav och när de inte fungerar som avsett hittar vi buggar. Eftersom vi inte validerar för defekter är de två sista fallen ogiltiga.

Följ samma tankegång och tillämpa den för att logga ut och visa produkter, här är vad du får.

Som du kan se, för dessa krav finns det ingen möjlighet att tillhandahålla en felaktig ingång. Därför behöver det inte skrivas negativa testscenarier / fall.

Avslutande tankar:

Systemet kan utsättas för positiv eller negativ inmatning. Hur som helst bör systemet generera korrekt utdata. De fall som tenderar att hantera korrekt input är positiva. De som handlar om korrekt men negativ inmatning är negativa.

Några tips:

# 1) När en slutfall till slutfall är skrivna för UAT eller till och med systemtestning är det alltid de positiva testfall som gör det till flödet.

#två) Ibland är klassificeringen subjektiv.Till exempel, om jag tar bort något på en webbplats och jag får ett bekräftelsemeddelande som frågar mig 'Är du säker på att du vill radera den här posten?' med OK och Avbryt alternativ - enligt mig är det ett positivt fall att klicka på avbryt. Men vissa tycker att det är negativt eftersom den primära avsikten med alternativet 'Ta bort' är att ta bort och inte avbryta åtgärden. Så en testares bedömning spelar också en roll i klassificeringen.

# 3) För varje positivt fall finns det inte alltid ett lika och motsatt negativt fall.

Ovanstående metod garanterar alltid korrekt klassificering. Prova själv och berätta för mig, om det inte gör det. :) 'En genväg är ofta fel snitt.' - Men då kanske det inte är i det här fallet!

För en mer formell förklaring av negativ testning, se => Vad är negativtestning och hur man skriver negativa testfall?

Om författaren: Den här artikeln är skriven av STH-teammedlem Swati S. Gå med i hennes live QA-utbildning här: “ Den bästa träningsprogrammet för programvarutestning du någonsin kommer att få! '

Meddela oss gärna om du har gillat den här artikeln och vill se några sådana grundläggande begrepp lätt förklaras i de kommande artiklarna.

Dina kommentarer, frågor, feedback och läsekrets uppskattas och uppskattas här på STH. Lycklig testning!

Rekommenderad läsning

• Positiv testning: Betydelse och fördelar förklarade med verkliga testscenarier
• Hur man skriver testfall för en inloggningssida (provscenarier)
• Vad är negativtestning och hur man skriver negativa testfall?
• Hur man skriver testfall för ATM-maskin (exempel på scenarier)
• Effektiv skriptning av selen och felsökning av scenarier - Selen-handledning nr 27
• Typer av migreringstest: Med testscenarier för varje typ
• QTP-handledning # 24 - Använda virtuella objekt och återställningsscenarier i QTP-tester
• Testa hälso-och sjukvårdsprogram - Tips och viktiga testscenarier (del 2)