Hva er en testsak?
ET TESTSAK er et sett med handlinger utført for å bekrefte en bestemt funksjon eller funksjonalitet i programvaren. En testsak inneholder testtrinn, testdata, forutsetning, ettertilstand utviklet for spesifikt testscenario for å verifisere ethvert krav. Testtilfellet inkluderer spesifikke variabler eller forhold, der en testingeniør kan sammenligne forventede og faktiske resultater for å avgjøre om et programvareprodukt fungerer i henhold til kundens krav.
Test Scenario Vs Test Case
Testscenarier er ganske vage og dekker et bredt spekter av muligheter. Testing handler om å være veldig spesifikk.
For et testscenario: Sjekk innloggingsfunksjonalitet er det mange mulige testsaker:
- Testtilfelle 1: Kontroller resultatene ved å angi gyldig bruker-ID og passord
- Testtilfelle 2: Kontroller resultatene ved å angi ugyldig bruker-ID og passord
- Testtilfelle 3: Sjekk respons når en bruker-ID er tom og påloggingsknappen trykkes, og mange flere
Dette er ingenting annet enn en testsak.
I denne opplæringen lærer du hvordan du skriver testsaker i manuell testing med eksempel -
- Hvordan skrive testtilfeller i manuell testing
- Formatet for standard testtilfeller
- Beste praksis for å skrive gode eksempler på testtilfeller.
- Test saksbehandlingsverktøy
- Ressurser
Klikk her hvis videoen ikke er tilgjengelig
Hvordan skrive testtilfeller i manuell testing
La oss lage en testsak for scenariet: Sjekk påloggingsfunksjonalitet
Trinn 1) En enkel testtilfelle for å forklare scenariet ville være
| Testforsøk # | Test Case Beskrivelse |
|---|---|
| 1 | Sjekk svar når gyldig e-postadresse og passord er angitt |
Trinn 2) For å kunne utføre testsaken, trenger du testdata. Legge til det nedenfor
| Testforsøk # | Test Case Beskrivelse | Testdata |
|---|---|---|
| 1 | Sjekk svar når gyldig e-postadresse og passord er angitt | E-post: Denne e-postadressen er beskyttet mot programmer som samler e-postadresser. Du må aktivere JavaScript for å kunne se den. Passord: lNf9 Oti7 2h |
Å identifisere testdata kan være tidkrevende og kan noen ganger kreve at du oppretter testdata på nytt. Årsaken til at det må dokumenteres.
Trinn 3) For å utføre en testtilfelle, må en tester utføre et bestemt sett med handlinger på AUT. Dette er dokumentert som nedenfor:
| Testforsøk # | Test Case Beskrivelse | Teststrinn | Testdata |
|---|---|---|---|
| 1 | Sjekk svar når gyldig e-postadresse og passord er angitt |
1) Skriv inn e-postadresse 2) Skriv inn passord 3) Klikk på Logg inn |
E-post: Denne e-postadressen er beskyttet mot programmer som samler e-postadresser. Du må aktivere JavaScript for å kunne se den. Passord: lNf9 Oti7 2h |
Mange ganger er ikke trinnene enkle som ovenfor, og derfor trenger de dokumentasjon. Dessuten kan forfatteren av testsaken forlate organisasjonen eller reise på ferie eller er syk og ikke i tjeneste eller er veldig opptatt med andre kritiske oppgaver. En nylig ansatt kan bli bedt om å gjennomføre testsaken. Dokumenterte trinn vil hjelpe ham og også lette gjennomgang fra andre interessenter.
Trinn 4) Målet med testtilfeller i programvaretesting er å kontrollere oppførselen til AUT for et forventet resultat. Dette må dokumenteres som nedenfor
| Testforsøk # | Test Case Beskrivelse | Testdata | forventet resultat |
|---|---|---|---|
| 1 | Sjekk svar når gyldig e-postadresse og passord er angitt | E-post: Denne e-postadressen er beskyttet mot programmer som samler e-postadresser. Du må aktivere JavaScript for å kunne se den. Passord: lNf9 Oti7 2h | Pålogging skal være vellykket |
I løpet av testutførelsen vil testeren kontrollere forventede resultater mot faktiske resultater og tildele en bestått eller ikke-godkjent status
| Testforsøk # | Test Case Beskrivelse | Testdata | forventet resultat | Egentlige resultatet | Bestått / ikke bestått |
|---|---|---|---|---|---|
| 1 | Sjekk svar når gyldig e-postadresse og passord er angitt | E-post: Denne e-postadressen er beskyttet mot programmer som samler e-postadresser. Du må aktivere JavaScript for å kunne se den. Passord: lNf9 Oti7 2h | Pålogging skal være vellykket | Pålogging var vellykket | Sende |
Trinn 5) At bortsett fra testtilfellet ditt - kan ha et felt som Pre-Condition som spesifiserer ting som må på plass før testen kan kjøres. For vår testsak vil en forutsetning være å ha en nettleser installert for å få tilgang til nettstedet som testes. En testsak kan også omfatte Post - conditions som spesifiserer alt som gjelder etter at testsaken er fullført. For vår testtilfelle vil en postcondition være tidspunkt og dato for pålogging er lagret i databasen
Formatet for standard testtilfeller
Nedenfor er et format på et standard eksempel på eksempler på påloggingsprøver.
| Test saks-ID | Test Scenario | Teststrinn | Testdata | forventede resultater | Faktiske resultater | Bestått / ikke bestått |
|---|---|---|---|---|---|---|
| TU01 | Sjekk kundeinnlogging med gyldige data |
| Userid = guru99 Passord = pass99 | Bruker skal logge på et program | Som forventet | Sende |
| TU02 | Sjekk kundeinnlogging med ugyldige data |
| Userid = guru99 Passord = glass99 | Brukeren skal ikke logge på et program | Som forventet | Sende |
Hele denne tabellen kan opprettes i Word, Excel eller et hvilket som helst annet testadministrasjonsverktøy. Det er alt for å teste saksdesign
Mens du utarbeider en testsak for å inkludere følgende informasjon
- Beskrivelsen av hvilket krav som testes
- Forklaringen på hvordan systemet skal testes
- Testoppsettet som en versjon av et program under test, programvare, datafiler, operativsystem, maskinvare, sikkerhetstilgang, fysisk eller logisk dato, tid på dagen, forutsetninger som andre tester og annen oppsettinformasjon som er relevant for kravene som testes
- Innganger og utganger eller handlinger og forventede resultater
- Eventuelle bevis eller vedlegg
- Bruk aktivt sakspråk
- Test saken bør ikke være mer enn 15 trinn
- Et automatisert testskript kommenteres med innspill, formål og forventede resultater
- Oppsettet tilbyr et alternativ til nødvendige tester
- Med andre tester, bør det være en feil rekkefølge for forretningsscenarier
Beste praksis for å skrive gode eksempler på testtilfeller.
1. Testtilfeller må være enkle og gjennomsiktige:
Lag testsaker som er så enkle som mulig. De må være tydelige og konsise, ettersom forfatteren av testsaken ikke kan utføre dem.
Bruk påståelig språk som å gå til hjemmesiden, skriv inn data, klikk på dette og så videre. Dette gjør forståelsen av teststrinnene enkel og tester utførelsen raskere.
2. Opprett testsak med tanke på sluttbruker
Det endelige målet med ethvert programvareprosjekt er å lage testtilfeller som oppfyller kundens krav og er enkle å bruke og betjene. En tester må lage testsaker med tanke på sluttbrukerperspektivet
3. Unngå repetisjon av prøvesaker.
Ikke gjenta testsaker. Hvis det er behov for en testtilfelle for å utføre en annen testtilfelle, kan du ringe testsaken med sin test-saks-ID i kolonnen fortilstand.
4. Ikke anta
Ikke anta funksjonalitet og funksjoner i programvaren mens du forbereder testtilfelle. Hold deg til spesifikasjonsdokumentene.
5. Sørg for 100% dekning
Forsikre deg om at du skriver testtilfeller for å sjekke alle programvarekravene som er nevnt i spesifikasjonsdokumentet. Bruk sporbarhetsmatrise for å sikre at ingen funksjoner / forhold blir testet.
6. Testtilfeller må kunne identifiseres.
Navn på test-saks-ID slik at de lett kan identifiseres mens du sporer feil eller identifiserer et programvarekrav på et senere tidspunkt.
7. Implementere testteknikker
Det er ikke mulig å sjekke alle mulige forhold i programvaren. Testingsteknikker for programvare hjelper deg å velge noen få testtilfeller med maksimal mulighet for å finne en feil.
- Grenseverdianalyse (BVA): Som navnet antyder, er det teknikken som definerer testing av grenser for et spesifisert verdiområde.
- Equivalence Partition (EP): Denne teknikken deler området inn i like deler / grupper som har en tendens til å ha samme oppførsel.
- State Transition Technique : Denne metoden brukes når programvareoppførsel endres fra en tilstand til en annen etter en bestemt handling.
- Feil gjetningsteknikk : Dette er å gjette / forutse feilen som kan oppstå under manuell testing. Dette er ikke en formell metode og tar fordeler av en testers erfaring med applikasjonen
8. Selvrens
Testtilfellet du oppretter, må sette testmiljøet tilbake til tilstanden før test, og det skal ikke gjøre testmiljøet ubrukelig. Dette gjelder spesielt for konfigurasjonstesting.
9. Gjentatt og selvstendig
Testsaken skal generere de samme resultatene hver gang, uansett hvem som tester den
10. Peer-review.
Etter å ha opprettet testsaker, få dem gjennomgått av kollegene dine. Kollegene dine kan avdekke feil i testkassedesignet ditt, som du lett kan savne.
Test saksbehandlingsverktøy
Testhåndteringsverktøy er automatiseringsverktøyene som hjelper til med å administrere og vedlikeholde testkassene. Hovedfunksjonene i et testsaksbehandlingsverktøy er
- For å dokumentere testtilfeller: Med verktøy kan du fremskynde opprettelse av testsaker med bruk av maler
- Utfør testsaken og registrer resultatene: Testsaken kan utføres gjennom verktøyene og resultatene som oppnås, kan enkelt registreres.
- Automatiser feilsporing : Mislykkede tester blir automatisk koblet til feilsporeren, som igjen kan tildeles utviklerne og kan spores via e-postvarsler.
- Sporbarhet: Krav, testsaker, gjennomføring av testsaker henger sammen gjennom verktøyene, og hver sak kan spores til hverandre for å kontrollere testdekning.
- Beskytte testtilfeller : Testtilfeller bør være gjenbrukbare og bør beskyttes mot å gå tapt eller bli ødelagt på grunn av dårlig versjonskontroll. Test Case Management Tools tilbyr funksjoner som
- Navn- og nummereringskonvensjoner
- Versjonering
- Skrivebeskyttet lagring
- Kontrollert tilgang
- Sikkerhetskopiering utenfor stedet
Populære verktøy for testadministrasjon er: Quality Center og JIRA
Ressurser
- Vær oppmerksom på at malen som brukes vil variere fra prosjekt til prosjekt. Les denne veiledningen for å lære testsaksmal med forklaring på viktige felt
Last ned ovennevnte testsaksmal Excel (.xls)
