Hvad er en testsag?
ET TESTSAG er et sæt handlinger, der udføres for at bekræfte en bestemt funktion eller funktionalitet i din softwareapplikation. En testcase indeholder testtrin, testdata, forudsætning, postcondition udviklet til specifikt testscenarie for at verificere ethvert krav. Testcasen inkluderer specifikke variabler eller betingelser, hvor en testingeniør kan sammenligne forventede og faktiske resultater for at afgøre, om et softwareprodukt fungerer efter kundens krav.
Test Scenario Vs Test Case
Testscenarier er ret vage og dækker en lang række muligheder. Test handler om at være meget specifik.
For et testscenario: Kontroller loginfunktionalitet er der mange mulige testsager:
- Test sag 1: Kontroller resultaterne ved indtastning af gyldig bruger-id og adgangskode
- Test Case 2: Kontroller resultaterne ved indtastning af ugyldigt bruger-ID og adgangskode
- Test sag 3: Kontroller svaret, når et bruger-id er tomt og der trykkes på knappen Login og mange flere
Dette er intet andet end en testsag.
I denne vejledning lærer du at skrive testcases i manuel test med eksempel -
- Hvordan man skriver testtilfælde i manuel testning
- Formatet af standardtestsager
- Bedste praksis til skrivning af et godt testeksempeleksempel.
- Test sagsstyringsværktøjer
- Ressourcer
Klik her, hvis videoen ikke er tilgængelig
Hvordan man skriver testtilfælde i manuel testning
Lad os oprette en testcase til scenariet: Tjek loginfunktionalitet
Trin 1) En simpel testtilfælde til forklaring af scenariet ville være
| Test sag # | Test case beskrivelse |
|---|---|
| 1 | Kontroller svaret, når gyldig e-mail og adgangskode indtastes |
Trin 2) For at udføre testsagen skal du have testdata. Tilføjelse af det nedenfor
| Test sag # | Test case beskrivelse | Testdata |
|---|---|---|
| 1 | Kontroller svaret, når gyldig e-mail og adgangskode indtastes | E-mail: Denne e-mail-adresse er beskyttet mod spambots. Du skal aktivere JavaScript for at kunne se den. Adgangskode: lNf9 Oti7 2h |
Identifikation af testdata kan være tidskrævende og kan undertiden kræve oprettelse af testdata på ny. Årsagen til, at det skal dokumenteres.
Trin 3) For at udføre en testtilfælde skal en tester udføre et specifikt sæt handlinger på AUT. Dette er dokumenteret som nedenfor:
| Test sag # | Test case beskrivelse | Test trin | Testdata |
|---|---|---|---|
| 1 | Kontroller svaret, når gyldig e-mail og adgangskode indtastes |
1) Indtast e-mail-adresse 2) Indtast adgangskode 3) Klik på Log ind |
E-mail: Denne e-mail-adresse er beskyttet mod spambots. Du skal aktivere JavaScript for at kunne se den. Adgangskode: lNf9 Oti7 2h |
Mange gange er teststrinene ikke enkle som ovenfor, hvorfor de har brug for dokumentation. Desuden kan forfatteren af testsagen forlade organisationen eller tage på ferie eller er syg og fri eller har meget travlt med andre kritiske opgaver. En ansat for nylig kan blive bedt om at udføre testsagen. Dokumenterede trin vil hjælpe ham og også lette anmeldelser fra andre interessenter.
Trin 4) Målet med testtilfælde i softwaretest er at kontrollere AUT's opførsel for et forventet resultat. Dette skal dokumenteres som nedenfor
| Test sag # | Test case beskrivelse | Testdata | forventet resultat |
|---|---|---|---|
| 1 | Kontroller svaret, når gyldig e-mail og adgangskode indtastes | E-mail: Denne e-mail-adresse er beskyttet mod spambots. Du skal aktivere JavaScript for at kunne se den. Adgangskode: lNf9 Oti7 2h | Login skal være vellykket |
Under testudførelsestiden kontrollerer testeren forventede resultater mod faktiske resultater og tildeler en bestået eller ikke-godkendt status
| Test sag # | Test case beskrivelse | Testdata | forventet resultat | Faktisk resultat | Bestå ikke-bestå |
|---|---|---|---|---|---|
| 1 | Kontroller svaret, når gyldig e-mail og adgangskode indtastes | E-mail: Denne e-mail-adresse er beskyttet mod spambots. Du skal aktivere JavaScript for at kunne se den. Adgangskode: lNf9 Oti7 2h | Login skal være vellykket | Login var vellykket | Passere |
Trin 5) At din testtilfælde bortset fra kan have et felt som Pre-Condition, der specificerer ting, der skal på plads, før testen kan køre. For vores testsag er en forudsætning at have en browser installeret for at få adgang til det site, der testes. En testsag kan også omfatte postbetingelser, der specificerer alt, hvad der gælder, når testsagen er afsluttet. I vores testsag vil en posttilstand være tidspunktet og datoen for login gemmes i databasen
Formatet af standardtestsager
Nedenfor er et format på et standardeksempel på login-testsager.
| Test sags-ID | Testscenarie | Test trin | Testdata | Forventede resultater | Faktiske resultater | Bestå ikke-bestå |
|---|---|---|---|---|---|---|
| TU01 | Kontroller kundelogin med gyldige data |
| Userid = guru99 Adgangskode = pass99 | Brugeren skal logge ind på et program | Som forventet | Passere |
| TU02 | Kontroller kundelogin med ugyldige data |
| Userid = guru99 Adgangskode = glass99 | Brugeren skal ikke logge ind på et program | Som forventet | Passere |
Hele denne tabel kan oprettes i Word, Excel eller ethvert andet teststyringsværktøj. Det er alt for at teste sagsdesign
Under udarbejdelsen af en testsag, der skal omfatte følgende oplysninger
- Beskrivelsen af hvilket krav der testes
- Forklaringen på, hvordan systemet testes
- Testopsætningen som en version af en applikation under test, software, datafiler, operativsystem, hardware, sikkerhedsadgang, fysisk eller logisk dato, tidspunkt på dagen, forudsætninger såsom andre tests og enhver anden opsætningsinformation, der er relevant for de krav, der testes
- Input og output eller handlinger og forventede resultater
- Eventuelle bevis eller vedhæftede filer
- Brug aktivt sprog
- Test sag bør ikke være mere end 15 trin
- Et automatisk test script kommenteres med input, formål og forventede resultater
- Opsætningen tilbyder et alternativ til forudgående test
- Med andre tests skal det være en forkert rækkefølge for forretningsscenarier
Bedste praksis til skrivning af et godt testeksempeleksempel.
1. Testtilfælde skal være enkle og gennemsigtige:
Opret testsager, der er så enkle som muligt. De skal være klare og koncise, da forfatteren af testsagen muligvis ikke udfører dem.
Brug selvsikker sprog som at gå til hjemmesiden, indtaste data, klikke på dette og så videre. Dette gør det lettere at forstå testtrinene og tester udførelsen hurtigere.
2. Opret testcase med slutbruger i tankerne
Det ultimative mål for ethvert softwareprojekt er at skabe testcases, der opfylder kundernes krav og er nemme at bruge og betjene. En tester skal oprette testsager under hensyntagen til slutbrugerperspektivet
3. Undgå gentagelse af testcase.
Gentag ikke testtilfælde. Hvis der er behov for en testsag til udførelse af en anden testsag, skal du kalde testsagen ved hjælp af dens testsag-id i kolonnen forudgående tilstand
4. Antag ikke
Antag ikke funktionalitet og funktioner i din softwareapplikation, mens du forbereder testsagen. Hold dig til specifikationsdokumenterne.
5. Sørg for 100% dækning
Sørg for at skrive testcases for at kontrollere alle softwarekrav, der er nævnt i specifikationsdokumentet. Brug sporbarhedsmatrix for at sikre, at ingen funktioner / betingelser efterlades uprøvede.
6. Testtilfælde skal kunne identificeres.
Navngiv testcase-id'et således, at de let identificeres, mens der spores mangler eller identificeres et softwarekrav på et senere tidspunkt.
7. Implementere testteknikker
Det er ikke muligt at kontrollere alle mulige forhold i din softwareapplikation. Softwaretestteknikker hjælper dig med at vælge et par testtilfælde med den maksimale mulighed for at finde en defekt.
- Grænseværdi-analyse (BVA): Som navnet antyder, er det teknikken, der definerer testning af grænser for et specificeret interval af værdier.
- Ækvivalenspartition (EP): Denne teknik opdeler området i lige dele / grupper, der har tendens til at have samme adfærd.
- State Transition Technique : Denne metode bruges, når softwareadfærd ændres fra en tilstand til en anden efter en bestemt handling.
- Fejlgætteteknik: Dette gætter / forudser den fejl, der kan opstå under manuel test. Dette er ikke en formel metode og tager fordelene ved en testers erfaring med applikationen
8. Selvrensende
Den testcase, du opretter, skal sætte testmiljøet tilbage til præ-testtilstanden og bør ikke gøre testmiljøet ubrugeligt. Dette gælder især for konfigurationstest.
9. Gentagelig og selvstændig
Testcasen skal generere de samme resultater hver gang, uanset hvem der tester det
10. Peer review.
Efter at have oprettet testsager, skal du få dem gennemgået af dine kolleger. Dine jævnaldrende kan afdække mangler i dit test case design, som du let kan gå glip af.
Test sagsstyringsværktøjer
Teststyringsværktøjer er automatiseringsværktøjer, der hjælper med at administrere og vedligeholde testkasserne. Hovedfunktionerne i et test case management værktøj er
- Til dokumentation af testsager: Med værktøjer kan du fremskynde oprettelse af testsager ved hjælp af skabeloner
- Udfør testsagen, og registrer resultaterne: Testsagen kan udføres gennem de værktøjer, og de opnåede resultater kan let registreres.
- Automatiser defektsporing: Mislykkede tests linkes automatisk til bugsporeren, som igen kan tildeles udviklerne og kan spores ved e-mail-underretninger.
- Sporbarhed: Krav, testsager, udførelse af testsager er alle sammenkoblet gennem værktøjerne, og hver sag kan spores til hinanden for at kontrollere testdækningen.
- Beskyttelse af testtilfælde: Testtilfælde skal kunne genbruges og skal beskyttes mod at blive tabt eller ødelagt på grund af dårlig versionskontrol. Test Case Management Tools tilbyder funktioner som
- Konventioner om navngivning og nummerering
- Versionering
- Skrivebeskyttet opbevaring
- Kontrolleret adgang
- Off-site backup
Populære teststyringsværktøjer er: Quality Center og JIRA
Ressourcer
- Bemærk, at den anvendte skabelon vil variere fra projekt til projekt. Læs denne tutorial for at lære testskabeloner med forklaring på vigtige felter
Download ovenstående testcase-skabelon Excel (.xls)
