Testcase-mal (last ned eksempel på Excel)
Thomas Hamilton
Hva er mal for testtilfeller?
A Testcase-mal er et godt utformet dokument for å utvikle og bedre forståelse av testcasedata for et bestemt testcase-scenario. En god Testsak malen opprettholder testartefaktkonsistens for testteamet og gjør det enkelt for alle interessenter å forstå testsakene. Å skrive testcase i et standardformat reduserer testinnsatsen og feilraten. Testcaseformat er mer ønskelig i tilfelle hvis du vurderer testcase fra eksperter.Malen som er valgt for prosjektet ditt avhenger av testpolicyen din. Mange organisasjoner lager testcases i Microsoft Excel mens noen er inne Microsoft Word. Noen bruker til og med testadministrasjonsverktøy som HP ALM for å dokumentere testsakene sine.
Test case mal for Excel
Klikk nedenfor for å laste ned Test Case Excel-fil
Last ned testcasemalen ovenfor (.xls)
Testcase-mal for Word
Klikk nedenfor for å laste ned Test Case Word-fil
Last ned testcasemalen ovenfor (.docx)
Uavhengig av hvilken testcasedokumentasjonsmetode som er valgt, må en god testcase-mal ha følgende felt
| Testtilfellefelt | Tekniske beskrivelser |
|---|---|
| Testtilfelle-ID: | Hvert testtilfelle skal representeres av en unik ID. For å indikere testtyper, følg en konvensjon som "TC_UI_1" som indikerer "User Interface Test Case#1." |
| Testprioritet: |
Det er nyttig når du utfører testen.
|
| Navn på modulen: | Bestem navnet på hovedmodulen eller undermodulen som testes |
| Test Designet av: | Testerens navn |
| Dato for testdesign: | Dato da testen ble designet |
| Test Utført av: | Hvem utførte test-testeren |
| Dato for testutførelse: | Dato når testen må utføres |
| Navn eller testtittel: | Tittel på testsaken |
| Description/Sammendrag av test: | Bestem sammendraget eller testformålet i korte trekk |
| Pre-conditioning: | Eventuelle krav som må gjøres før utførelse av denne testsaken. For å utføre denne testsaken må du oppgi alle forutsetninger |
| avhengig: | Bestem eventuelle avhengigheter av testkrav eller andre testtilfeller |
| Teststrinn: | Nevn alle testtrinnene i detalj og skriv i den rekkefølgen den skal utføres. Mens du skriver testtrinn, sørg for at du gir så mange detaljer som mulig |
| Testdata: | Bruk av Testdata som innspill til testcasen. Lever forskjellige datasett med presise verdier som skal brukes som input |
| forventede resultater: | Nevn det forventede resultatet inkludert feil eller melding som skal vises på skjermen |
| Post-Condition: | Hva ville være tilstanden til systemet etter å ha kjørt testsaken? |
| Egentlige resultatet: | Etter testutførelse skal det faktiske testresultatet fylles ut |
| Status (Ikke bestått/Bestått): | Merk dette feltet som mislykket, hvis det faktiske resultatet ikke er i henhold til det estimerte resultatet |
| Merknader: | Hvis det er noen spesielle forhold som er igjen i feltet ovenfor |
Du kan eventuelt ha følgende felt avhengig av prosjektkravene
- Link / defekt ID: Inkluder lenken for Defekt eller bestemme defektnummeret hvis teststatusen er mislykket
- Nøkkelord / testtype: For å bestemme tester basert på testtyper kan dette feltet brukes. Eks: Brukervennlighet, funksjonell, forretningsregler, etc.
- Krav: Krav som denne testsaken skrives for
- Referanser / Vedlegg: Det er nyttig for kompliserte testscenarier, angi den faktiske banen til dokumentet eller diagrammet
- Automatisering (Ja/Nei): For å spore automatiseringsstatus når testtilfeller er automatiserte
- Egendefinerte felt: Felter som er spesifikt at prosjektet ditt testes på grunn av klient-/prosjektkrav.
