Sådan skriver du testcases med eksempler

Indholdsfortegnelse

Hvad er en testcase?

i forbindelse med programmelprøvning henviser en testsag til den rækkefølge af handlinger, der kræves for at verificere en bestemt funktion eller funktionalitet. I det væsentlige beskriver testsagen de trin, data, forudsætninger og postbetingelser, der er nødvendige for at verificere en funktion.

det vil opstille bestemte variabler, som kvalitetssikringssystemer skal sammenligne forventede og faktiske resultater for at konkludere, om funktionen fungerer som den skal. Test case-komponenter nævner input, udførelse og forventet output/respons. Grundlæggende fortæller det ingeniører, hvad de skal gøre, hvordan man gør det, og hvilke resultater der er acceptable.

Læs mere: Sådan oprettes testscenarier med eksempler

formålet med at skrive testcases

  • for at validere specifikke funktioner og funktioner i programmet.
  • at guide testere gennem deres daglige hands-on aktivitet.
  • for at registrere et katalog over trin, der er foretaget, som kan revideres i tilfælde af, at en fejl dukker op.
  • for at give en plan for fremtidige projekter og testere, så de ikke behøver at starte arbejdet fra bunden.
  • for at hjælpe med at opdage brugervenlighedsproblemer og designhuller tidligt.
  • for at hjælpe nye testere og udviklere med hurtigt at hente test, selvom de deltager midt i et igangværende projekt.

Standard Test Case Format

  • Test Case ID
  • Testscenarie
  • Testtrin
  • forudsætninger
  • testdata
  • forventede/tilsigtede resultater
  • faktiske resultater
  • teststatus – pass/fail

husk at medtage, mens du skriver testsager:

  • en rimelig beskrivelse af kravet
  • en beskrivelse af testprocessen
  • detaljer vedrørende testopsætning: version af programmet under test, datapunkter, OS, udstyr, sikkerhedsgodkendelse, dato, klokkeslæt, forudsætninger osv.
  • eventuelle relaterede dokumenter eller vedhæftede testere kræver
  • alternativ til forudsætninger, hvis de findes

fælles træk ved testsager

  • sandsynligvis revideret og opdateret regelmæssigt. Programmelkravene kan ændres afhængigt af ændringer i forretningsprioriteter eller kundepræferencer. Hvis kravene ændres, skal testcases ændres i overensstemmelse hermed. Påvisning af fejl og fejlfindingstrin kan også kræve, at testsager ændres.
  • sandsynligvis involverer klyngedannelse. Testsager i et enkelt testscenarie skal normalt køres i en bestemt rækkefølge eller i en gruppe. I dette tilfælde gælder særlige forudsætninger for en testsag for andre testsager i samme rækkefølge.
  • sandsynligvis være indbyrdes afhængige. Ofte kan testsager afhænge af hinanden. Dette gælder især for lagdelte applikationer med multi-tier forretningslogik.
  • sandsynligvis vil blive brugt af testere såvel som udviklere. Test cases er nyttige for udviklere såvel som testere. For eksempel, når devs løser fejl, kan testsager være ret nyttige til at replikere fejlen. I Test-Driven Development (TDD) opretter devs testcases for at udforme forretningslogik, dække flere testscenarier og begynde at skrive kode.

Test Case eksempel

lad os bygge et test case eksempel baseret på et bestemt scenario. Her er en prøve sag.

  • Test Case ID: #BST001
  • Test Scenario: at godkende en vellykket bruger login på Gmail.com
  • Testtrin:
    • brugeren navigerer til Gmail.com.
    • i feltet ‘E-mail’ indtaster brugeren en registreret e-mail-adresse.
    • brugeren klikker på knappen ‘Næste’.
    • brugeren indtaster den registrerede adgangskode.
    • brugeren klikker ‘Log ind.’
  • forudsætninger: et registreret Gmail-ID med et unikt brugernavn og adgangskode.
  • bro.ser: Chrome v 86. Enhed: Samsung Galakse Tab S7.
  • testdata: legitimt brugernavn og adgangskode.
  • Forventede / Tilsigtede Resultater: Når brugernavn og adgangskode er indtastet, omdirigerer hjemmesiden til brugerens indbakke, viser og fremhæver nye e-mails øverst.
  • faktiske resultater: som forventet
  • teststatus – Pass/Fail: Pass

bedste praksis til skrivning af testsager

  • Prioriter klarhed og gennemsigtighed. Vær klar, kortfattet og selvsikker i at beskrive, hvad testeren skal gøre, og hvilke resultater de ideelt set skal få.
  • fokus på slutbrugerens krav, når du skriver prøve test cases. Kort test cases til at afspejle alle aspekter af brugeren rejse. Brug dokumentet specifikationer og dokumentet krav til at gøre det.
  • undgå gentagelse. Hvis flere test kan udføres med samme testcase, skal du bruge testcase-ID ‘ et til at henvise til den krævede testcase.
  • hold Testtrin så minimale som muligt. Ideelt set skal du holde det til 10-15 trin, hvis det er muligt.
  • fokus på at opnå maksimal testdækning. Mens 100% testdækning sjældent er opnåelig, kan en høj procentdel opnås med de rigtige strategier.

    Læs mere: Hvordan sikrer du maksimal testdækning?

  • Opret selvrensende testsager. Det betyder, at testsager skal vende testmiljøet tilbage til en uberørt tilstand før test. Test bør ikke efterlade nogen rester af sig selv i miljøet, når de er afsluttet. Dette er et integreret element i konfigurationsstyring. For at forstå mere dybtgående: Hvad er konfigurationsstyring i DevOps?
  • form test cases for tests, der returnerer de samme resultater, uanset hvem der kører dem. Sørg for, at testene er selvstændige.

når testcases er blevet formet, skal tilsvarende test køres på ægte bro.Serere, enheder og operativsystemer. Husk, at enhedsfragmentering er en betydelig bekymring for enhver udvikler og tester. Hver hjemmeside har til at arbejde problemfrit på flere enhed-bro.ser-OS kombinationer. Med 9000 + forskellige enheder, der bruges til at få adgang til internettet globalt, skal alle programmer optimeres til forskellige konfigurationer, visningsport og skærmopløsninger.

prøv at teste på Real Device Cloud Gratis

i denne tilstand kan ingen emulator eller simulator replikere reelle brugerforhold. Programmel skal testes på rigtige enheder for at arbejde under virkelige omstændigheder som et lavt batteri, indgående opkald, svag netværksstyrke og så videre. Hvis et internt laboratorium ikke er tilgængeligt, skal du vælge en skybaseret testindstilling, der tilbyder rigtige enheder.

cloud Selenium grid tilbyder 2000 + rigtige enheder og bro.sere til automatiseret test. Det betyder, at brugere kan køre test på flere rigtige enheder og bro.sere ved blot at tilmelde sig, logge ind og vælge de nødvendige kombinationer. Testere kan også udføre Cypresstest på 30 + ægte bro.serversioner på tværs af vinduer og macOS. Registrer fejl, før brugerne gør det ved at teste programmer under reelle brugerforhold.

Bemærk: Undlad at frigive programmer uden test på rigtige enheder. Når brugerne besøger, vil de støde på fejl og fejl, der let kunne have været undgået, og forstyrrende brugeroplevelser vil resultere i tab af brugere.

oprettelse af velstrukturerede og resultatorienterede testcases er grundlæggende for at køre vellykkede tests. Derudover sikrer de omfattende testdækning og giver en klar plan for kvalitetssikringssystemer, der skal følges. Brug denne artikel til at lære de grundlæggende elementer i at skabe effektive testcases og begynde at udføre tests designet til at optimere og levere top-of-the-line brugeroplevelser.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret.