how classify positive
Du kan gjøre noe på den enkle eller harde måten - det viktigste er at du gjør det. Det er få enkle hverdagslige ting, men uten selvtillit passer ikke noe om dem helt i våre sinn, og omfanget av suksess er en hit eller miss.
La oss ta ett enkelt eksempel i dag og finne snarveier som ikke bare vil avklare konseptene, men også sørge for at du alltid vil få det riktig.
Positiv eller negativ klassifisering av testscenarier / tilfeller
Testdesignprosessen er tredoblet:
- Identifiser krav
- Skriv testscenarier (en linjepekere om hva du skal teste)
- Utform detaljerte instruksjoner om hvordan du tester (testtilfeller)
Når vi skriver testscenarier, klassifiserer vi dem i positive og negative forhold. (Når du tenker på det, er det veldig viktig å lage denne klassifiseringen? Hvis ja, hvilket formål tjener den? Vi må teste dem alle uansett, er det ikke?) Det slår meg også, for det meste. Men jeg tror det er et forsøk på å etablere tilstrekkelig dekning og bidrar til å fastslå at vi tester både de glade og alternative banene systemet skal håndtere. Vennligst kommenter nedenfor hvis du vet om andre grunner til at dette gjøres.
La oss nå se på noen få krav, skrive testscenarier og utføre klassifiseringen.
# 1) Logg inn :En bruker som angir riktig legitimasjon, kommer inn i systemet. Hvis legitimasjonen er feil, nektes tilgang og en feilmelding vises.
# 2) Vis produkter: La oss anta at det er en online katalog med alle produktene som er tilgjengelige i systemet, og den viser dem alle i en liste når du klikker på linken 'Vis produkter'.
# 3) Logg ut: Når man klikker på denne lenken, logges brukeren av.
Jeg skal skrive noen testscenarier for disse kravene.
Tabell A:Den riktige måten
| Test scenario-ID | Test scenario beskrivelse | Positiv negativ |
|---|---|---|
| TS_login_01 | Bekreft om brukeren logger inn hvis legitimasjonen du har oppgitt er riktig | Positivt |
| TS_login_02 | Valider hvis brukeren ikke får tilgang når legitimasjonen er oppgitt er feil | Negativ |
| TS_ViewProduct_01 | Valider hvis alle varene er oppført når det vises klikk på linken Vis produkter | Positivt |
| TS_logout_01 | Valider hvis den allerede påloggede brukeren er logget ut av systemet når du klikker på avlogging | Positivt |
Noen ganger ser jeg imidlertid testscenariet skrevet slik.
Tabell B: Innlegg merketNetter ugyldige testscenarier.
| Test scenario-ID | Test scenario beskrivelse | Positiv negativ |
|---|---|---|
| TS_login_01 | Bekreft om brukeren logger inn hvis legitimasjonen du har oppgitt er riktig | Positivt |
| TS_login_02 | Valider hvis brukeren ikke får tilgang når legitimasjonen er oppgitt er feil | Negativ |
| TS_ViewProduct_01 | Valider hvis alle varene er oppført når det vises klikk på linken Vis produkter | Positivt |
| TS_ViewProduct_02 | Valider hvis alle elementene ikke er oppført når det klikkes på linken for visning av produkter | Negativ |
| TS_logout_01 | Valider hvis den allerede påloggede brukeren er logget ut av systemet når du klikker på avlogging | Positivt |
| TS_logout_02 | Valider hvis brukeren ikke logger ut når man klikker på koblingen for avlogging | Negativ |
For vellykket innlogging er det en lik og motsatt sak når den ikke lykkes. Ikke alle kravene skal være slik, og for dem er det egentlig ingen tvang til å skrive et negativt scenario.
Poenget: Ikke alle krav skal ha negative tilfeller.
På dette punktet, hvis du tenker 'Hvordan vet jeg' eller 'Jeg er fortsatt ikke sikker', er det et enkelt jukseark som vil hjelpe.
hvor mange brukbare verter er tilgjengelige gitt en klasse c ip-adresse med standard nettverksmaske?
Hvis det er en generalisering vi kan gjøre om applikasjoner, er at de er dynamiske. Inndataene (data, klikk osv.) Som vi gir, vil føre til at applikasjonen blir en bestemt måte og genererer en viss utgang.
En enkel sammenheng mellom inngangs- og utgangsvariablene vil gjøre dette lett å forstå.
La oss prøve følgende for pålogging:
| Inngang | Produksjon | Positiv negativ |
|---|---|---|
| Riktig (riktig påloggingsinformasjon) | Riktig (bruker logget inn) | Positivt |
| Feil (feil innloggingsinformasjon) | Riktig (En feilmelding) | Negativ |
| Riktig (riktig påloggingsinformasjon) | Feil - Innlogging mislykkes | Feil / feil |
| Feil (feil innloggingsinformasjon) | Feil (systemet logger dem på) - 'Å, skrekken!' :) | Feil / feil |
Så, ser du fra tabellen ovenfor, vi kan si at vi kategoriserer primærflyten som positiv, og den alternative strømmen (også riktig oppførsel for applikasjonen) er merket som negativ.
De to siste tilfellene i rødt er faktisk feil. Testing handler om validering av krav, og når de ikke fungerer som de skal, finner vi feil. Siden vi ikke validerer for mangler, er de to siste sakene ugyldige.
Etter samme tankegang og bruke den til å logge ut og vise produkter, her er hva du får.
| Inngang | Produksjon | Positiv negativ |
|---|---|---|
| Logg ut (klikk) | Riktig - Logger av | Positivt |
| Logg ut (klikk) | Feil - Oppholder seg pålogget | Feil / feil |
| Vis produkter (klikk) | Correct - Viser produkter | Positivt |
| Vis produkter (klikk) | Feil (ikke liste eller feil listevisning) | Feil / feil |
Som du ser, for disse kravene, er det ikke en mulighet for å levere feil inngang. Derfor trenger det ikke være negative testscenarier / saker skrevet.
Avsluttende tanker:
Systemet kan bli utsatt for positive eller negative innganger. Uansett bør systemet generere riktig produksjon. Sakene som har en tendens til å håndtere riktig innspill er positive. De som handler om riktig, men negativ innspill, er negative.
Noen tips:
#1) Når en slutt til slutt test tilfeller er skrevet for UAT eller til og med systemtesting, er det alltid positive testtilfeller som gjør det til flyten.
#to) Noen ganger er klassifiseringen subjektiv.For eksempel, hvis jeg sletter noe på et nettsted og jeg mottar en bekreftelsesmelding som spør meg 'Er du sikker på at du vil slette denne oppføringen?' med alternativene OK og Avbryt - ifølge meg er å klikke på avbryt et positivt tilfelle. Men noen tror at det er negativt, da den primære hensikten med alternativet 'Slett' er å slette og ikke avbryte operasjonen. Så, en testers dom spiller også en rolle i klassifiseringen.
# 3) For hvert positivt tilfelle er det ikke alltid et likeverdig og motsatt negativt tilfelle.
Ovennevnte metode garanterer alltid riktig klassifisering. Prøv det selv og fortell meg, hvis det ikke gjør det. :) “En snarvei er ofte en feil kutt.” - Men det er kanskje ikke i dette tilfellet!
For en mer formell forklaring på negativ testing, vennligst sjekk => Hva er negativ testing og hvordan skriver jeg negative testtilfeller?
Om forfatteren: Denne artikkelen er skrevet av STH-teammedlem Swati S. Bli med på hennes live QA-kurs her: “ Den beste programvaretestopplæringen du noen gang vil få! '
Gi oss beskjed hvis du har likt denne artikkelen og vil se slike grunnleggende konsepter lett forklart i de kommende artiklene.
Dine kommentarer, spørsmål, tilbakemeldinger og lesertall er høyt verdsatt og verdsatt her på STH. Glad test!
Anbefalt lesing
- Positiv testing: Betydning og fortjenester forklart med virkelige testscenarier
- Hvordan skrive testsaker for en påloggingsside (eksempelscenarier)
- Hva er negativ testing og hvordan skriver jeg negative testtilfeller?
- Slik skriver du testtilfeller for minibank (eksempelscenarier)
- Effektiv Selen Scripting og feilsøking av scenarier - Selenium Tutorial # 27
- Typer av migrasjonstesting: Med testscenarier for hver type
- QTP Opplæring # 24 - Bruk av virtuelle objekter og gjenopprettingsscenarier i QTP-tester
- Testing av helseprogrammer - Tips og viktige testscenarier (del 2)