Menu

Skrivning af testsager fra SRS-dokument (DOWNLOAD Live Project-prøveeksempler)

writing test cases from srs document

Prøv Vores Instrument Til At Fjerne Problemer

Skrivning af testtilfælde fra SRS-dokument (Download live projekteksempler på testtilfælde) - Softwaretest QA-træningsdag 4

Bare for at genopvaske det, vi har gjort indtil videre - vi arbejder os igennem Software Testing Training mini-kursus på et live-projekt OrangeHRM.

I denne gratis online QA-træningsserie hidtil er vi færdige med:

  1. SRS anmeldelse,
  2. Testscenarie / Identifikation af testomfang og
  3. Dokumenteret testplanen .

Skrivning af sager fra SRS-dokument

Nu er vi nået til den del, der er den virkelige aftale,testsagerne.

Som angivet i artiklen før dette: Testcases er dokumenteret af QA-teamet, mens SDLC-kodefasen foregår. Med andre ord, mens Dev-teamet bygger softwaresystemet, bliver testteamet klar med testcases, der vil hjælpe os med at teste systemet, når det er klar, dvs. i slutningen af ​​kodefasen.

Så i dagens artikel vil vi arbejde på at forstå, hvad testcases er, hvordan man opretter dem og skrive et par eksempler på testcases til vores live-projekt.

Lad os komme til det med det samme.

Hvad du lærer:

Grundlæggende om skrivetestsager

# 1) Hvis testscenarier drejer sig om, 'Hvad vi skal teste' på AUT - testsagerne handler om “Hvordan vi skal teste et krav”.

For eksempel , hvis testscenariet er “Valider Admin-loginfunktionaliteten” - Dette ville give i 3 testtilfælde (eller betingelser) - Login (vellykket), Login-mislykket, når det forkerte brugernavn er indtastet, Login-mislykket, når den forkerte adgangskode er indtastet . Hver testsag ville til gengæld have skridt til at løse, hvordan vi kan kontrollere, at en bestemt testtilstand er opfyldt eller ej.

#to) Input til oprettelse af et test case-dokument er FRD, testscenarier oprettet i det tidligere trin og eventuelle andre referencedokumenter, hvis de er til stede.

# 3) Testcase-dokumentationen er en vigtig leverance af QA-teamet og deles med BA, PM og andre hold, når de er færdige med henblik på deres feedback.

# 4) Arbejdet er fordelt på teammedlemmerne, og hvert medlem vil være ansvarlig for at skabe testcases for et bestemt modul eller en del af et bestemt modul.

# 5) Ligesom med testscenarierne skal der, før vi begynder dokumentation til testsag, aftales en fælles skabelon. Næsten alt kan bruges til at oprette testsager. De 2 mest anvendte valg er MS Excel og MS word.

# 6) Det MS-ordskabelon ser sådan ud:

Test cases MS word-skabelon

# 7) Det Excel-skabelon kunne se ud som følgende:

qa træningstestcases prøver xls

# 8) Fra ovenstående to skabeloner kan det observeres, at felterne (eller komponenterne), der udgør en testtilfælde, er de samme, den eneste forskel er den måde, de er organiseret på.

Så længe der er et felt for hver af de typer information, der skal medtages i en test, betyder formatet på skabelonen ikke noget. Min personlige favorit er dog tilfældigvis excel-arket, fordi det er let at udvide, skjule, sortere osv. Men igen, vælg ethvert format, der fungerer bedst for dig.

Felter i testtilfælde

Lad os tage et øjeblik for at observere de felter, der er en del af en test sag.

Test case ID og Test case beskrivelse er de generiske.

De andre felter kan forklares som følger:

  • Forudsætning: Status for AUT (den tilstand, hvor AUT skal være, for at vi kan komme i gang).
  • Indgang: Trin for indtastning af data. For disse trin er det vigtigt at bemærke, hvilken type inputinfo der kræves - Testdata.
  • Valideringspunkt / trigger / handling : Hvad får valideringen til at ske? (Klik på en knap eller skift eller linkadgangen. Sørg for, at der er mindst et valideringspunkt til en testtilfælde - ellers bliver det hele dataindtastning uden noget at se efter. Også for at sikre, at vi har tilstrækkelig modularitet, prøv ikke at kombinere for mange valideringspunkter i en test case. 1 per test case er optimal.)
  • Produktion: Forventet resultat.
  • Posttilstand: Dette er yderligere information, der leveres til fordel for testeren, bare for at gøre testsagen mere indsigtsfuld og informativ. Dette inkluderer en forklaring på, hvad der sker, eller hvad der kan forventes af AUT, når alle testsagstrin er udført.

Se også => Eksempel på testsagskabelon

Live-projekteksempler på testtilfælde (Download)

Nu hvor vi har nok baggrundsinformation til at komme i gang med processen til oprettelse af testsager, så lad os komme i gang og oprette få testsager til vores Live Project.

Baseret på ovennævnte proces har vi oprettet nogle eksempler på testtilfælde til OrangeHRM-kontomodulet. Disse skal give dig et nøjagtigt testcase-format og en idé om, hvordan du nærmer dig at skrive testsager.

=> Download eksempler på testcases-dokument til vores Live-projekt her .

Bemærk: Der er få billeder henvist til eksempler på testtilfælde XLS-dokument. Hvis du ser dette på den ældre MS Office-version, kan du blive udsat for kompatibilitetsproblemer.

Vi har listet disse billeder nedenfor efter deres navne i XLS-filerne:

Se billede 1
Se billede 2
Se billede 3

Der, alt gjort og alt godt.

Test Cases Skrivning / Optimeringsmetoder

Forestil dig nu en situation, hvor en bestemt side har et par 10 felter på sig eller har en kompleks forretningslogik, der er implementeret derinde. For at sikre, at vi optimerer testoprettelsesprocessen i sådanne situationer, har vi testere bestemte testcase-optimeringsmetoder.

Nedenfor vises de links, der findes for at få mere information om disse metoder.

youtube til mp3 converter ingen virus

Ved hjælp af ovenstående teknikker og efter den generelle proces til oprettelse af testsager opretter vi et sæt testsager, der effektivt vil teste applikationen ved hånden.

Få vigtige punkter, der skal bemærkes

  • De testsager, vi opretter, er ikke kun referencepunktet for QA-fasen, men også til UAT.
  • Internt test tilfælde er Peer-reviewed i teamet .
  • Når en bestemt situation ikke behandles af en testtilfælde - tommelfingerreglen er, at den ikke bliver testet. Så dette er et godt sted at kontrollere, om den testpakke, vi oprettede, opnår målet om 100% testdækning eller ej. For at gøre dette kan der oprettes en sporbarhedsmatrix. Tjek alt, hvad der er at vide om Sporbarhedsmatrix her .
  • Værktøjer - Teststyringsværktøjer som QC , qTest hjælpe os med oprettelsen af ​​testsagen. For et eksempel på, hvordan testsager kan håndteres ved hjælp af Quality Center, skal du tjekke dette Kvalitetscenter tutorial .
  • Automatiseringsværktøjer kan bruges til at oprette testsager - i hvilket tilfælde de kaldes testskripter.
Pro Tip :Udfør en stave- og grammatikkontrol på hvert eneste dokument, vi opretter. Vi er kvalitetsrepræsentanter for it-projekter - og det afspejler os ikke positivt, hvis vores leverancer selv er af ringere kvalitet.

Det bringer os til slutningen af ​​et andet interessant segment.

Konklusion

Afslutningen af ​​testoprettelsesprocessen / testdesignfasen (STLC) og afslutningen af ​​kodefasen (SDLC) markerer generelt afslutningen på testforberedelsesfasen og begyndelsen af ​​testudførelsesfasen.

Næste tutorial i dette softwaretestkursus - I den kommende artikel vil vi tale om, hvad testudførelse er, hvad den inkluderer, og hvad er forventningerne fra QA-teamet i denne fase.

=> QA-træningsdag 5: Testudførelse

Vi håber, at I alle sammen arbejder sammen med denne serie. Af hensyn til enkelheden er der kun oprettet et par testsager. De bedste resultater kan dog ses, når du arbejder med at teste i vid udstrækning, hvilket betyder at du skriver flere og flere testsager. Så du må ikke begrænse dit arbejde og gøre så meget som muligt.

Fortæl os venligst dine spørgsmål og kommentarer nedenfor. God test!

PREV-vejledning | NÆSTE vejledning

Anbefalet læsning

^