Hva er test case?
Programvareterminologi kan ofte være ganske forvirrende. Testfallet, scenariet, planen; de høres alle ganske like ut, og det er lett å blande begrepene. I programvaretesting er det viktig å unngå betenkeligheter med den omkringliggende terminologien. Derfor, i denne artikkelen, vil vi se på hva det betyr.
Det er en gruppe forhold eller variabler som testeren verifiserer samsvar med kravene til programvaren som testes. Det brukes til å gi trinnvise instruksjoner til testerne. Det er et dokument som har testdata, forutsetninger, forventede resultater osv., Utviklet for et spesifikt scenario. Å utføre det fungerer som utgangspunkt, hvoretter vi bruker et sett med inndataverdier, og venter på et endelig resultat. Forløpet med å utvikle dem hjelper oss også med å finne komplikasjoner i applikasjonskravene.
Vanligvis skriver en tester fra QA-teamet dem. Dette inkluderer ikke testene som utviklingsteamet skriver, men testene som blir utført etter utvikling og enhetstesting er utført. Enda viktigere, en tester som forstår funksjonaliteten til applikasjonen og kan gi et testtilfelle av verdi, bør skrive det.
Mal
Det har vanligvis følgende felt. Imidlertid kan formatet på feltene variere fra selskap til selskap, avhengig av teststyringsverktøyet som brukes av dem.
| Test case-ID | ID-en blir gitt til prøvesaken. |
| Test Case Beskrivelse | Beskrivelsen av test saken. |
| Relatert krav | ID-en gis kravet som denne test saken kartlegger. |
| Forutsetninger | Eventuelle forutsetninger eller krav som skal oppfylles før du kjører testen. |
| Testtrinn | Trinnvise instruksjoner ble gitt for å kjøre testen. |
| Testdata | Data som brukes mens du utfører testen. |
| forventet resultat | Resultatet som forventes fra testen, loggført før du kjører testen. |
| Egentlige resultatet | Det faktiske resultatet oppnådd etter å ha kjørt testen |
| Status | Status oppnådd etter å ha kjørt testen. Det kan være bestått, mislykkes, ikke utført, blokkert. |
| kommentarer | Eventuelle merknader som skal gis for testen. |
| Miljøinformasjon | Inkluderer nettverk / maskinvare / programvareinformasjon som testen kjøres i. |
Hvordan skrive en prøvesak?
Nedenfor er trinnene som er gitt for å skrive en prøvesak.
Trinn 1: Tildel et nummer og en beskrivelse.
Trinn 2: For å kunne kjøre det, trenger vi testdata. Uten testdataene ville vi ikke ha riktig informasjon å teste, noe som gjør oppgaven arbeidskrevende.
Trinn 3: For å kjøre den, må vi ha et visst sett med instruksjoner for å utføre testen. Disse trinnene kalles testtrinn. Behovet for dette oppstår når forfatteren trekker seg fra prosjektet eller er på pause. Da vil noen andre fra prosjektet måtte ta opp testingen. Skriftlige trinn vil hjelpe dem.
Trinn 4: Målet med dem er å undersøke atferden til applikasjonen. For å utføre dette, må vi ha et forventet resultat. Etter utførelsen blir forventede resultater sammenlignet med det faktiske resultatet fra testen, og følgelig vil en status bli tilordnet den.
Trinn 5: Vi kan også ha et tilleggsfelt som forutsetningsfeltet, som forteller oss betingelsene som skal oppfylles før testkjøringen, et felt etter betingelser, som forteller oss betingelsene som skal oppfylles etter testkjøringen, etc.
Eksempel:
| Test case-ID | Test Case Beskrivelse | Testtrinn | Testdata | forventet resultat | Egentlige resultatet | Status |
| TC01 | Sjekk ansattes pålogging med gyldige data |
1. Gå til påloggingssiden. 2. Angi Userid 3.Tast inn passord 4. Klikk på Innlogging-knappen | Userid = admin
Passord = abc12345 | Bruker skal kunne logge inn | Som forventet | Sende |
| TC02 | Sjekk ansattes pålogging med ugyldige data | 1. Gå til påloggingssiden.
2. Angi Userid 3.Tast inn passord 4. Klikk på Innlogging-knappen | Userid = admin
Passord = 12345abc | Bruker skal ikke kunne logge inn | Som forventet | Sende |
Betydningen av prøvesak
De har et enormt inntrykk på testfasen. Å skrive dem er like viktig som selve testprosessen. Det hjelper oss å tenke gjennom detaljene og sikrer at vi takler dem fra så mange synspunkter som mulig.
Viktigheten av å ha det er at hvem som helst kan prøve på nytt ved å bruke dem. De er potente gjenstander som er nyttige for fremtidige lagkamerater, i tillegg til å gi dokumentasjon på hvordan en applikasjon presterer. For å oppsummere gir de følgende betydning:
- De sikrer god dekning av testen, og sørger for at hovedfunksjonaliteten ikke blir savnet under testen.
- Det lar dem tenke grundig på forskjellige måter å bekrefte funksjonene i applikasjonen.
- Negativer blir også skrevet, noe som gjør testingen til en grundig prosess, med lite oversett.
- De kan brukes på nytt, da alle kan henvise dem og kjøre testen.
Nyttige tips og triks
Husk følgende informasjon når du skriver dem:
- Det skal være enkelt og kortfattet, med ikke mer enn 15 trinn.
- Hver av dem skal gjøres gjenbrukbare.
- Unngå repetisjon.
- Ytterligere informasjon om testoppsett skal gis som programvare, maskinvare, operativsystem, versjon av applikasjonen som testes, forutsetninger for testen, etc.
- Det skal skrives på en måte som vi bare tester én ting om gangen, uten overlapp.
- Forsikre deg om at alle scenarier, positive og negative, blir dekket, noe som gir oss 100% dekning.
- De bør opprettes med sluttbruker i tankene.
Konklusjon
For å konkludere, kan de forbedre vår innsats i generell testing og kan forbedre programvarekvaliteten til store mål, samtidig som vi sparer tid og krefter på grunn av gjenbrukbarhet av testtilfeller.
Anbefalte artikler
Dette er en guide til What is Test Case. Her har vi diskutert mal, viktighet og nyttige tips og triks. Du kan også se på følgende artikler for å lære mer -
- Hva er programvareutvikling?
- Spørsmål om programvareteknikkintervju
- Karriere som programvareutviklere
- 14 beste programvareverktøy for å lage presentasjoner av god kvalitet