Meny

Skrive testtilfeller fra SRS-dokument (LAST NED Live-prosjekteksempel på testtilfeller)

writing test cases from srs document

Prøv Instrumentet Vårt For Å Eliminere Problemer

Skrive testtilfeller fra SRS-dokument (Last ned live prosjekteksempel på testtilfeller) - Programvaretesting QA-opplæringsdag 4

Bare for å rehash det vi har gjort så langt - vi jobber oss gjennom Programvare Testing Training minikurs på et live-prosjekt OrangeHRM.

I denne gratis online QA-treningsserien så langt er vi ferdige med:

  1. SRS gjennomgang,
  2. Testscenario / Identifikasjon av testomfang og
  3. Dokumentert testplanen .

Skrive testtilfeller fra SRS-dokument

Nå har vi nådd den delen som er den virkelige avtalen,prøvesakene.

Som angitt i artikkelen før dette: Test tilfeller er dokumentert av QA teamet mens Code fase av SDLC pågår. Med andre ord, mens Dev-teamet bygger programvaresystemet, blir testteamet klart med testtilfellene som vil hjelpe oss med å teste systemet når det er klart, dvs. på slutten av kodefasen.

Så i dagens artikkel vil vi jobbe med å forstå hva testsaker er, hvordan lage dem og skrive noen få eksempler på testsaker for vårt live-prosjekt.

La oss komme til det med en gang.

Hva du vil lære:

Grunnleggende om skrivetestesaker

#1) Hvis testscenarier dreier seg om “Hva vi skal teste” på AUT - testsakene handler om “Hvordan vi skal teste et krav”.

For eksempel , hvis testscenariet er 'Validerer administratorinnloggingsfunksjonaliteten' - Dette vil gi i 3 testtilfeller (eller forhold) - Pålogging (vellykket), Pålogging mislyktes når feil brukernavn er angitt, Pålogging mislykket når feil passord er angitt . Hver testtilfelle vil i sin tur ha trinn for å løse hvordan vi kan kontrollere at en bestemt testtilstand er oppfylt eller ikke.

#to) Inndataene for å lage et test case-dokument er FRD, testscenarier opprettet i det tidligere trinnet og eventuelle andre referansedokumenter hvis de er til stede.

# 3) Testsaksdokumentasjonen er viktig å levere av QA-teamet og deles med BA, PM og andre team når de er ferdige for tilbakemelding.

# 4) Arbeidet er delt mellom teammedlemmene, og hvert medlem vil være ansvarlig for å lage testtilfeller for en bestemt modul eller en del av en bestemt modul.

# 5) Akkurat som med testscenariene, må vi avtale en felles mal før vi begynner med dokumentasjon på testsaken. Nesten alt kan brukes til å lage testsaker. De to mest brukte valgene er MS Excel og MS word.

# 6) De MS-ordmal ser slik ut:

Test tilfeller MS word mal

# 7) De Excel-mal kunne se slik ut:

qa treningstest tilfeller prøver xls

# 8) Fra de to ovennevnte malene kan det observeres at feltene (eller komponentene) som utgjør en testtilfelle er de samme, den eneste forskjellen er måten de er organisert på.

Så lenge det er et felt for hver type informasjon som skal inkluderes i en test, spiller ikke formatet på malen noen rolle. Imidlertid er min personlige favoritt tilfeldigvis excel-arket, fordi det er lett å utvide, kollapse, sortere osv. Men igjen, velg hvilket som helst format som fungerer best for deg.

Felt i prøvesaker

La oss ta et øyeblikk for å observere feltene som er en del av en testtilfelle.

Test case ID og Test case beskrivelse er de generiske.

De andre feltene kan forklares som følger:

  • Forutsetning: Tilstand for AUT (tilstanden AUT må være for at vi skal komme i gang).
  • Inngang: Trinn for datainnføring. For disse trinnene er det viktig å merke seg hva slags input-informasjon som kreves - Testdata.
  • Valideringspunkt / utløser / handling : Hva får valideringen til å skje? (Klikk på en knapp eller veksle eller tilgangen til lenken. Sørg for at det er minst ett valideringspunkt til en testtilfelle - ellers blir alt datainnføring uten noe å se etter. Også for å sikre at vi har nok modulering, prøv å ikke kombinere for mange valideringspunkter i en testtilfelle. 1 per testtilfelle er optimal.)
  • Produksjon: Forventet resultat.
  • Posttilstand: Dette er tilleggsinformasjon som gis til fordel for testeren, bare for å gjøre testsaken mer innsiktsfull og informativ. Dette inkluderer en forklaring på hva som skjer eller hva som kan forventes av AUT når alle testsakstrinnene er utført.

Se også => Eksempel på mal for prøvesaker

Live-prosjekteksempel på testtilfeller (Last ned)

Nå som vi har nok bakgrunnsinformasjon til å komme i gang med prosessen med å lage testsaker, la oss komme i gang og lage få testsaker for vårt Live Project.

Basert på prosessen nevnt ovenfor har vi laget noen eksempler på testtilfeller for OrangeHRM-kontomodulen. Disse skal gi deg et eksakt format og en ide om hvordan du skal nærme deg å skrive testsaker.

=> Last ned eksempeldokument for testtilfeller for vårt Live Project her .

Merk: Det er få bilder som er henvist til eksempler på XLS-dokument. Hvis du ser på den på den eldre MS Office-versjonen, kan du møte kompatibilitetsproblemer.

Vi har listet opp bildene nedenfor i henhold til navnene deres i XLS-filene:

Se bilde 1
Se bilde 2
Se bilde 3

Der, alt gjort og alt bra.

Test Cases Skriving / Optimaliseringsmetoder

Tenk deg nå en situasjon der en bestemt side har noen 10-talls felt på seg eller har en kompleks forretningslogikk som er implementert der inne. For å sikre at vi optimaliserer prosessen med å lage testsaker i slike situasjoner, har vi testere visse test case-optimaliseringsmetoder.

Oppført nedenfor er lenkene som er gitt for mer informasjon om disse metodene.

innsettingssorteringsalgoritme c ++

Ved å bruke de ovennevnte teknikkene og følge den generelle prosessen for oppretting av testsaker, oppretter vi et sett med testsaker som effektivt vil teste applikasjonen.

Få viktige punkter å merke seg

  • Testtilfellene vi lager er ikke bare referansepunktet for QA-fasen, men også til UAT.
  • Internt test tilfeller er Fagfellevurdert i teamet .
  • Når en bestemt situasjon ikke blir adressert av en testtilfelle - tommelfingerregelen er, den kommer ikke til å bli testet. Så dette er et bra sted å sjekke om testpakken vi opprettet oppnår 100% testdekningsmål eller ikke. For å gjøre det kan det opprettes en sporbarhetsmatrise. Sjekk ut alt det er å vite om Sporbarhetsmatrise her .
  • Verktøy - Testhåndteringsverktøy som QC , qTest hjelpe oss med å lage testsaken. For et eksempel på hvordan testsaker kan håndteres ved hjelp av Quality Center, sjekk ut dette Kvalitetssenteropplæring .
  • Automatiseringsverktøy kan brukes til å lage testtilfeller - i så fall blir de referert til som testskripter.
Pro Tips :Vennligst utfør en stave- og grammatikkontroll på hvert eneste dokument vi oppretter. Vi er kvalitetsrepresentanter for IT-prosjekter - og det reflekterer ikke positivt over oss om våre leveranser selv er av dårligere kvalitet.

Det bringer oss til slutten av et annet interessant segment.

Konklusjon

Avslutningen av testopprettingsprosessen / testdesignfasen (STLC) og slutten av kodefasen (SDLC) vil generelt markere slutten på testforberedelsesfasen og begynnelsen av testutførelsesfasen.

Neste opplæring i dette programvaretestkurset - I den kommende artikkelen vil vi snakke om hva Test Execution er, hva det inkluderer og hva er forventningene fra QA-teamet i denne fasen.

=> QA-treningsdag 5: Testutførelse

Vi håper dere alle jobber sammen med denne serien. For enkelhets skyld er det bare opprettet noen få testtilfeller. De beste resultatene kan imidlertid sees når du jobber med å teste mye, noe som betyr å skrive flere og flere testsaker. Så ikke begrens arbeidet ditt og gjør så mye du kan.

Gi oss beskjed om dine spørsmål og kommentarer nedenfor. Glad test!

PREV Opplæring | NESTE veiledning

Anbefalt lesing

^