Sådan skriver du testcases med eksempler

Hvad er en testcase?

A test sag er et sæt af handlinger, input og forventede resultater der hjælper testere med at verificere, om en specifik funktion eller funktionalitet i software fungerer som tilsigtet. Det fungerer som en trin-for-trin guide der definerer, hvad der skal testes, hvordan det skal testes, og hvilket resultat man kan forvente.

Tænk på en testcase som en opskrift på validering — den fortæller dig de nøjagtige ingredienser (testdata), processen (trin der skal udføres), og hvordan en perfekt ret (forventet resultat) skal se ud.

En velskrevet testcase er med til at sikre:

• Softwaren opfylder forretnings- og brugerkrav.
• Fejl eller uventet adfærd er fanget tidligt.
• Testning kan være gentaget og gennemgået af enhver QA-professionel.
• Hold kan spore hvilket krav hver test verificerer.

👉 Tilmeld dig et gratis live softwaretestprojekt

Trin til at oprette testcases i manuel test

Lad os oprette en testcase for scenariet: Tjek login-funktionalitet

Trin 1) En simpel testcase til at forklare scenariet ville være

Test sag #	Test sag Description
1	Tjek svar, når gyldig e-mail og adgangskode er indtastet

Trin 2) Test dataene.
For at udføre testsagen skal du bruge Testdata. Tilføjer det nedenfor

Test sag #	Test sag Description	Testdata
1	Tjek svar, når gyldig e-mail og adgangskode er indtastet	E-mail: guru99@email.com Adgangskode: lNf9^Oti7^2h

Identifikation af testdata kan være tidskrævende og kan nogle gange kræve at der oprettes testdata på ny. Årsagen til det skal dokumenteres.

Trin 3) Udfør handlinger.
For at udføre en testsag skal en tester udføre et specifikt sæt handlinger på AUT. Dette er dokumenteret som nedenfor:

Test sag #	Test sag Description	Test trin	Testdata
1	Tjek svar, når gyldig e-mail og adgangskode er indtastet	1) Indtast e-mailadresse 2) Indtast adgangskode 3) Klik på Log ind	E-mail: guru99@email.com Adgangskode: lNf9^Oti7^2h

Mange gange er testtrinnene ikke så enkle som ovenfor, og derfor kræver de dokumentation. Derudover kan forfatteren af ​​testcasen forlade organisationen, tage på ferie, være syg og have fri eller være meget travlt optaget med andre kritiske opgaver. En nyligt ansat kan blive bedt om at udføre testcasen. Dokumenterede trin vil hjælpe vedkommende og også lette gennemgange af andre interessenter.

Trin 4) Kontroller AUT'ens opførsel.
Målet med testcases i softwaretestning er at kontrollere AUT'ens opførsel for at opnå et forventet resultat. Dette skal dokumenteres som vist nedenfor.

Test sag #	Test sag Description	Testdata	forventet resultat
1	Tjek svar, når gyldig e-mail og adgangskode er indtastet	E-mail: guru99@email.com Adgangskode: lNf9^Oti7^2h	Login skal være vellykket

Under testudførelsestiden vil testeren kontrollere forventede resultater i forhold til faktiske resultater og tildele en bestået eller ikke-bestået status

Test sag #	Test sag Description	Testdata	forventet resultat	Faktisk resultat	Bestå ikke-bestå
1	Tjek svar, når gyldig e-mail og adgangskode er indtastet	E-mail: guru99@email.com Adgangskode: lNf9^Oti7^2h	Login skal være vellykket	Login lykkedes	Pass

Trin 5) At ud over din testcase - kan have et felt som,
en forudsætning, der specificerer ting, der skal være på plads, før testen kan køre. For vores testcase ville en forudsætning være at have en browser installeret for at få adgang til det websted, der testes. En testcase kan også indeholde efterbetingelser, der specificerer alt, hvad der gælder, efter at testcasen er afsluttet. For vores testcase ville en efterbetingelse være, at tidspunkt og dato for login gemmes i databasen.

Nøgleelementer i en testcase

En standard testcase omfatter typisk:

1. Test Case ID – Unik identifikator (f.eks. TC001)
2. Titel eller Description – Hvad testen bekræfter
3. forudsætninger – Hvad skal være til stede, før testen starter
4. Test trin – De præcise handlinger, der skal udføres
5. Testdata – Indtastningsværdier eller parametre
6. forventet resultat – Resultatet du skal se
7. Faktisk resultat – Hvad der egentlig skete
8. Status – Bestået, Ikke bestået eller Blokeret

Test Case vs Test Scenario

A testscenarie beskriver, hvad der skal testes — den brede funktionalitet eller brugerrejsen.

A testtilfælde, på den anden side forklarer, hvordan denne funktionalitet vil blive verificeret — de nøjagtige trin, data og forventede resultater.

Enkelt sagt:

• Testscenarie = Idé af hvad der skal testes.
• Testcase = Implementering hvordan man tester den idé.

Tænk på det sådan her –

"Hvis et testscenarie er en kapiteltitel, er hver testcase et afsnit, der forklarer kapitlet i detaljer."

Eksempelillustration:

Lad os tage et eksempel for at gøre det tydeligere:

Testscenarie:

"Tjek hjemmesidens loginfunktionalitet."

Relaterede testcases:

1. Bekræft login med gyldigt brugernavn og adgangskode.
2. Bekræft fejlmeddelelsen med ugyldig adgangskode.
3. Bekræft login med tomme felter.
4. Feltet "Bekræft adgangskode" skjuler indtastningstekst.

Her er scenariet et enkelt funktionelt mål, mens testcases opdeler det i specifikke, testbare betingelser.

Læs for mere information om Forskellen mellem testcase og testscenarie

Fordele ved at skrive testcases af høj kvalitet

• Testcases af høj kvalitet sikrer grundig testdækning, konsistens og sporbarhed på tværs af hele QA-processen.
• De hjælper testere med at fange tidlige fejl, vedligeholde regressionsstabilitetog garantere, at alle funktioner er i overensstemmelse med forretningskravene.
• Velskrevne testcases er klar, genanvendelig og repeterbar, så enhver tester eller automatiseringsværktøj kan udføre dem pålideligt.
• De fungerer også som en kommunikationsbro mellem udviklere, testere og interessenter — hvilket reducerer tvetydighed og sparer tid.
• Ved at dokumentere testmål, trin og resultater kan teams måle fremskridt, overholde standarder, og administrere opdateringer effektivt.
• Vigtigst af alt, gode testcases reducere vedligeholdelsesomkostninger, fremskynde automatisering og tilbyde tillid til softwarekvalitet.
• De fungerer som levende dokumentation for onboarding af nye testere og som struktureret input til AI og værktøjer til teststyring.

Almindelige fejl, der skal undgås, når du skriver testcases

Selv erfarne testere laver små fejl, der forringer testkvaliteten.

At undgå disse fejl kan forbedre det markant nøjagtighed, klarhed og vedligeholdelsesvenlighed af din testsuite.

1. Skrivning af vage trin: Tvetydige instruktioner som "tjek login-siden" forvirrer testere. Brug klare, handlingsbaserede trin.
2. Spring negative scenarier over: Medtag altid ugyldige input eller grænsetests for at sikre fuld dækning.
3. Genbrug af uklare testdata: Umærkede eller inkonsistente data gør testresultaterne upålidelige. Vedligehold et fælles testdatablad.
4. Overkomplicerende testcases: Lange sager med flere trin er svære at vedligeholde. Hold hver sag fokuseret og atomar.
5. Ignorerer opdateringer efter produktændringer: Forældede testcases skaber falske resultater. Revse og revidere regelmæssigt.
6. Manglende sporbarhed: Forbind altid testcases med krav for at spore dækning og overholdelse af regler.
7. Springer over fagfællebedømmelser: Friske øjne opfanger uklare eller overflødige trin tidligt.

Ofte Stillede Spørgsmål