how classify positive
Du kan gøre noget på den nemme eller hårde måde - det vigtige er, at du gør det. Der er få enkle hverdagsting, men uden tillid passer noget ved dem ikke helt i vores sind, og omfanget af succes er et hit eller miss.
Lad os tage et simpelt eksempel i dag og finde genveje, der ikke kun afklarer begreberne, men også sørger for at du altid får det rigtigt.
Positiv eller negativ klassificering af testscenarier / tilfælde
Testdesignprocessen er 3 gange:
- Identificer krav
- Skriv testscenarier (en linjemarkør for, hvad man skal teste)
- Design detaljerede instruktioner om, hvordan man tester (testcases)
Når vi skriver testscenarier, klassificerer vi dem i positive og negative forhold. (Når du tænker over det, er det virkelig vigtigt at foretage denne klassificering? Hvis ja, hvilket formål tjener den? Vi er nødt til at teste dem alligevel, er det ikke?) Det slår mig også for det meste. Men jeg tror, det er et forsøg på at skabe tilstrækkelig dækning og hjælper med at fastslå, at vi tester både de glade og alternative veje, som systemet skal håndtere. Kommenter venligst nedenfor, hvis du kender andre grunde til, at dette gøres.
Lad os nu se på nogle få krav, skrive testscenarier og udføre klassificeringen.
# 1) Login :En bruger, der indtaster korrekte legitimationsoplysninger, kommer ind i systemet. Hvis legitimationsoplysningerne er forkerte, nægtes adgang, og der vises en fejlmeddelelse.
# 2) Se produkter: Lad os antage, at der er et online katalog over alle produkter tilgængelige i systemet, og det viser dem alle på en liste, når der klikkes på linket 'Vis produkter'.
# 3) Log af: Når der klikkes på dette link, logges brugeren ud.
Jeg skal skrive få testscenarier for disse krav.
Tabel A:Den rigtige måde
Test scenario-id | Test scenarie beskrivelse | Positiv / negativ |
---|---|---|
TS_login_01 | Valider, hvis brugeren logger ind, hvis de indtastede legitimationsoplysninger er korrekte | Positiv |
TS_login_02 | Valider, hvis brugeren ikke har adgang, når de indtastede legitimationsoplysninger er forkerte | Negativ |
TS_ViewProduct_01 | Valider, hvis alle varerne er angivet, når der klikkes på linket Vis produkter | Positiv |
TS_logout_01 | Valider, hvis den allerede loggede bruger er logget ud af systemet, når der klikkes på logout | Positiv |
Imidlertid kan jeg sommetider se testscenariet skrevet sådan.
Tabel B: Indlæg markeretNeter ugyldige testscenarier.
Test scenario-id | Test scenarie beskrivelse | Positiv / negativ |
---|---|---|
TS_login_01 | Valider, hvis brugeren logger ind, hvis de indtastede legitimationsoplysninger er korrekte | Positiv |
TS_login_02 | Valider, hvis brugeren ikke har adgang, når de indtastede legitimationsoplysninger er forkerte | Negativ |
TS_ViewProduct_01 | Valider, hvis alle varerne er angivet, når der klikkes på linket Vis produkter | Positiv |
TS_ViewProduct_02 | Bekræft, hvis alle varerne ikke er angivet, når der klikkes på linket Vis produkter | Negativ |
TS_logout_01 | Valider, hvis den allerede loggede bruger er logget ud af systemet, når der klikkes på logout | Positiv |
TS_logout_02 | Bekræft, hvis brugeren ikke logger ud, når der klikkes på logoutlink | Negativ |
For login's vellykkede sag er der en lige og modsat sag, når den ikke lykkes. Ikke alle krav skal være sådan, og for dem er der virkelig ingen tvang til at skrive et negativt scenario.
Bundlinjen: Ikke alle krav skal have negative tilfælde.
På dette tidspunkt, hvis du tænker 'Hvordan ved jeg det' eller 'Jeg er stadig ikke sikker', her er et simpelt snydeark, der kan hjælpe.
enkel sorteringsalgoritme c ++
Hvis der er en generalisering, vi kan lave om applikationer, er, at de er dynamiske. Det input (data, klik osv.), Som vi leverer, får applikationen til at være en bestemt måde og generere en bestemt output.
En simpel sammenhæng mellem input- og outputvariablerne gør det let at forstå.
Lad os prøve følgende til login:
Indgang | Produktion | Positiv / negativ |
---|---|---|
Korrekt (korrekt logininfo) | Korrekt (bruger logget ind) | Positiv |
Forkert (forkert logininformation) | Korrekt (En fejlmeddelelse) | Negativ |
Korrekt (korrekt logininfo) | Forkert - Login mislykkes | Fejl / fejl |
Forkert (forkert logininformation) | Forkert (systemet logger dem ind) - 'Åh, rædslen!' :) | Fejl / fejl |
Så du kan se fra ovenstående tabel, vi kan sige, at vi kategoriserer den primære strømning som positiv, og den alternative strømning (også den korrekte opførsel af applikationen) er markeret som negativ.
De sidste to sager i rødt er faktisk bugs. Test handler om validering af krav, og når de ikke fungerer efter hensigten, finder vi fejl. Da vi ikke validerer for mangler, er de to sidste sager ugyldige.
Følg den samme tankegang og anvende den til at logge ud og se produkter, her er hvad du får.
Indgang | Produktion | Positiv / negativ |
---|---|---|
Log af (klik) | Korrekt - Log ud | Positiv |
Log af (klik) | Forkert - Bliver logget ind | Fejl / fejl |
Se produkter (klik) | Korrekt - Viser produkter | Positiv |
Se produkter (klik) | Forkert (ikke liste eller forkert listevisning) | Fejl / fejl |
Som du kan se, for disse krav er der ikke en mulighed for at levere et forkert input. Derfor behøver der ikke være negative testscenarier / sager skrevet.
Afsluttende tanker:
Systemet kan blive udsat for positive eller negative input. Uanset hvad skal systemet generere korrekt output. De sager, der har tendens til at håndtere korrekt input, er positive. Dem, der handler om korrekte, men negative input, er negative.
Et par pointer:
# 1) Når en ende til slut test tilfælde er skrevet til UAT eller endda systemtest, er det altid de positive testtilfælde, der får det til at strømme.
#to) Nogle gange er klassificeringen subjektiv.For eksempel, hvis jeg sletter noget på et websted, og jeg modtager en bekræftelsesmeddelelse, der spørger mig 'Er du sikker på, at du vil slette denne post?' med valgmulighederne OK og Annuller - ifølge mig er det en positiv sag at klikke på Annuller. Men nogle tror, det er negativt, da den primære hensigt med 'Slet' er at slette og ikke annullere handlingen. Så en testers vurdering spiller også en rolle i klassificeringen.
# 3) For hver positiv sag er der ikke altid en lige og modsat negativ sag.
Ovenstående metode garanterer altid korrekt klassificering. Prøv det selv og fortæl mig, hvis det ikke gør det. :) “En genvej er ofte en forkert snit.” - Men så er det måske ikke i dette tilfælde!
For en mere formel forklaring af negativ test, bedes du kontrollere => Hvad er negativ test og hvordan man skriver negative testtilfælde?
Om forfatteren: Denne artikel er skrevet af STH-teammedlem Swati S. Deltag i hendes live QA-kursus her: “ Den bedste software test træning, du nogensinde vil få! '
Fortæl os, hvis du kan lide denne artikel og ønsker at se sådanne grundlæggende begreber let forklaret i de kommende artikler.
Dine kommentarer, spørgsmål, feedback og læserskare er meget værdsat og værdsat her på STH. God test!
Anbefalet læsning
- Positiv testning: Betydning og fordele forklaret med virkelige testscenarier
- Sådan skriver du testtilfælde til en login-side (eksempler på scenarier)
- Hvad er negativ test og hvordan man skriver negative testtilfælde?
- Sådan skriver du testtilfælde til pengeautomat (eksempelscenarier)
- Effektiv Selen Scripting og fejlfinding af scenarier - Selen Tutorial # 27
- Typer af migreringstest: Med testscenarier for hver type
- QTP-tutorial # 24 - Brug af virtuelle objekter og gendannelsesscenarier i QTP-tests
- Test af sundhedsapplikationer - tip og vigtige testscenarier (del 2)