Sådan skriver du testtilfælde: Den ultimative guide med eksempler

how write test cases

I denne dybdegående praktiske vejledning om, hvordan man skriver testtilfælde, har jeg dækket detaljerne i, hvad der er en test sag, dens standard definition og test sag design teknikker.

Hvad er en testsag?

En test case har komponenter, der beskriver input, handling og et forventet svar for at afgøre, om en funktion i en applikation fungerer korrekt.

En testtilfælde er et sæt instruktioner om “HVORDAN” til validering af et bestemt testmål / mål, som når det følges, fortæller os, om systemets forventede opførsel er opfyldt eller ej.

Liste over vejledninger, der er dækket af denne test case-skriveserie:

Sådan skriver du:

Tutorial # 1: Hvad er en test sag, og hvordan man skriver test tilfælde (denne vejledning)
Tutorial # 2: Eksempel på testcase-skabelon med eksempler (Download) (skal læses)
Tutorial # 3: Skrivning af testcases fra SRS-dokument
Tutorial # 4: Hvordan man skriver testsager til et givet scenario
Tutorial # 5: Sådan forbereder du dig til test case skrivning
Tutorial # 6: Hvordan man skriver negative testtilfælde

Eksempler:

Tutorial # 7: 180+ prøveeksempler til web- og desktopapplikationer
Tutorial # 8: 100+ klar til at udføre testscenarier (tjekliste)

Skriveteknikker:

Tutorial # 9: Årsag og virkning Graf - Dynamisk test sagsskrivningsteknik
Tutorial # 10: Testteknik for statlig overgang
Tutorial # 11: Ortogonal Array Testing Technique
Tutorial # 12: Fejl ved gætteteknik
Vejledning nr. 13: Field Validation Table (FVT) Test Design Technique

Test case vs testscenarier:

Tutorial # 14: Test tilfælde mod testscenarier
Tutorial # 15: Forskellen mellem testplan, teststrategi og testcase

Automatisering:

Tutorial # 16: Sådan vælges korrekte testtilfælde til automatiseringstest
Tutorial # 17: Sådan oversættes manuelle testtilfælde til automatiseringsskripter

Teststyringsværktøjer:

Tutorial # 18: Bedste teststyringsværktøjer
Tutorial # 19: TestLink til test case management
Tutorial # 20: Oprettelse og styring af testtilfælde ved hjælp af HP Quality Center
Tutorial # 21: Udførelse af testtilfælde ved hjælp af ALM / QC

Domænespecifikke sager:

Tutorial # 22: Test tilfælde til ERP-applikation
Tutorial # 23: JAVA applikationstest tilfælde
Tutorial # 24: Grænseværdianalyse og ækvivalenspartitionering

Lad os fortsætte med den første tutorial i denne serie.

Anbefalede værktøjer:

Inden du fortsætter til testprocessens skriveproces, anbefaler vi at downloade dette værktøj til håndtering af testsager. Dette letter din testproces, der er beskrevet i denne vejledning:

# 1) TestRail

=> Download TestRail Test Case Management Tool

# 2) TestMonitor

Top test online teststyring. Revolutionerende let.

TestMonitor er et end-to-end teststyringsværktøj til enhver organisation. En enkel, intuitiv tilgang til test. Uanset om du implementerer virksomhedssoftware, har brug for QA, bygger en kvalitetsapp eller bare har brug for en hjælpende hånd i dit testprojekt, har TestMonitor dig dækket.

=> Besøg TestMonitor-webstedet

Hvad du lærer:

• Hvad er en testsag, og hvordan man skriver testsager?
  • Hvorfor skriver vi tests?
  • Hvordan man skriver testsager?
  • Grundlæggende format for testsagens erklæring
• Tips til skrivetests
  • • # 1) Hold det simpelt, men ikke for simpelt; gør det komplekst, men ikke for komplekst:
    • # 2) Efter at have dokumenteret testsagerne skal du gennemgå en gang som Tester:
    • # 3) Bundet såvel som lettere testere:
    • # 4) Vær en bidragyder:
    • # 5) Glem aldrig slutbrugeren:
• Sådan opnås ekspertise i dokumentation af testsager
  • Nyttige tip og tricks
    • # 1) Er dit testdokument i god form?
    • # 2) Glem ikke at dække de negative sager
    • # 3) Har trin til atomtest
    • # 4) Prioriter testene
    • # 5) Sekvens spørgsmål
    • # 6) Føj tidsstempel og testernavn til kommentarerne
    • # 7) Inkluder browseroplysninger
    • # 8) Opbevar to separate ark - 'Bugs' & 'Summary' i dokumentet
• Hvordan IKKE skal skrive tests
  • 3 mest almindelige problemer i testsager
    • # 1) Sammensatte trin
    • # 2) Applikationsadfærd tages som forventet adfærd
    • # 3) Flere betingelser i et tilfælde
• Sådan forbedres effektiviteten af ​​testkasser
  • Dokumentindsamling til testskrivning
  • Rigtigt eksempel
  • Test sagsdokument
  • Testdataindsamling
• Betydningen af ​​standardisering af testsagerne
  • Årsager til at genbruge testsager
  • Hvad er en standardtest i webtest?
  • Konklusion
  • Anbefalet læsning

Hvad er en testsag, og hvordan man skriver testsager?

At skrive effektive sager er en færdighed. Og du kan lære det af erfaring og viden om applikationen, der testes.

For grundlæggende instruktioner om, hvordan man skriver tests, bedes du kontrollere følgende video:

Ovennævnte ressourcer skal give os det grundlæggende i testskrivningsprocessen.

Niveauer af testskrivningsprocessen:

• Niveau 1: I dette niveau vil du skrive basissager fra den tilgængelige specifikation og brugerdokumentation.
• Niveau 2: Dette er praktisk stadium hvor skriftlige sager afhænger af applikationens faktiske funktion og systemflow.
• Niveau 3: Dette er det stadium, hvor du vil gruppere nogle sager og skriv en testprocedure . Testproceduren er intet andet end en gruppe små sager, måske maksimalt 10.
• Niveau 4: Automatisering af projektet. Dette vil minimere menneskelig interaktion med systemet, og dermed kan QA fokusere på de aktuelt opdaterede funktionaliteter til at teste i stedet for at forblive travlt med regressionstest.

Hvorfor skriver vi tests?

Det grundlæggende mål med at skrive sager er for at validere testdækningen af ​​en ansøgning.

Hvis du arbejder i en hvilken som helst CMMi-organisation, følges teststandarderne nærmere. Skrivning af sager bringer en form for standardisering og minimerer ad hoc-tilgangen i test.

Hvordan man skriver testsager?

Felter:

• Test sag id
• Enhed til test: Hvad skal bekræftes?
• Antagelser
• Testdata: Variabler og deres værdier
• Trin, der skal udføres
• forventet resultat
• Faktisk resultat
• Bestå ikke-bestå
• Kommentarer

Grundlæggende format for testsagens erklæring

Verificere
Ved brug af (værktøjsnavn, tagnavn, dialog osv.)
Med (betingelser)
Til (hvad der returneres, vist, demonstreret)

Verificere: Brugt som det første ord i testerklæringen.
Ved brug af: At identificere, hvad der testes. Du kan bruge 'indtastning' eller 'valg' her i stedet for at bruge afhængigt af situationen.

For enhver applikation skal du dække alle typer tests som:

• Funktionelle sager
• Negative tilfælde
• Grænseværditilfælde

Mens du skriver disse alle dine TC'er skal være enkle og lette at forstå .

hvordan man opretter en streng array

***********************************************

Tips til skrivetests

En af de hyppigste og største aktiviteter i en softwaretester (SQA / SQC-person) er at skrive testscenarier og sager.

Der er nogle vigtige og kritiske faktorer, der er relateret til denne store aktivitet. Lad os få et fugleperspektiv af disse faktorer først.

Vigtige faktorer involveret skriveproces:

a) TC'er er tilbøjelige til regelmæssig revision og opdatering:

Vi lever i en verden, der konstant ændrer sig, og det samme gælder også for software. Ændring af softwarekrav påvirker sagerne direkte. Når kravene ændres, skal TC'er opdateres.

Alligevel er det ikke kun ændringen i kravet, der kan forårsage revision og opdatering af TC'er. Under udførelsen af ​​TC'er opstår der mange ideer i sindet, og der kan identificeres mange underbetingelser for en enkelt TC. Alt dette medfører en opdatering af TC'er, og nogle gange fører det endda til tilføjelsen af ​​nye TC'er.

Desuden kræver flere rettelser og / eller krusninger under regressionstest reviderede eller nye TC'er.

b) TC'er er tilbøjelige til distribution blandt testere, der vil udføre disse:

Der er naturligvis næppe en sådan situation, hvor en enkelt tester udfører alle TC'erne. Normalt er der flere testere, der tester forskellige moduler i en enkelt applikation. Så TC'erne er opdelt mellem testere i henhold til deres ejede områder af den applikation, der testes.

Nogle TC'er, der er relateret til integrationen af ​​applikationen, kan udføres af flere testere, mens de andre TC'er kun kan udføres af en enkelt tester.

c) TC'er er tilbøjelige til gruppering og batching:

Det er normalt og almindeligt, at TC'er, der tilhører et enkelt testscenarie, normalt kræver deres udførelse i en bestemt rækkefølge eller i form af en gruppe. Der kan være visse forudsætninger for en TC, der kræver udførelse af andre TC'er, før de kører selv.

I overensstemmelse med AUT's forretningslogik kan en enkelt TC ligeledes bidrage til flere testbetingelser, og en enkelt testbetingelse kan bestå af flere TC'er.

d) TC'er har en tendens til indbyrdes afhængighed:

Dette er også en interessant og vigtig opførsel af TC'erne, der angiver, at de kan være indbyrdes afhængige af hinanden. Fra mellemstore til store applikationer med kompleks forretningslogik er denne tendens mere synlig.

Det klareste område i enhver applikation, hvor denne adfærd helt sikkert kan observeres, er interoperabiliteten mellem forskellige moduler i de samme eller endda forskellige applikationer. Kort sagt, uanset hvor de forskellige moduler en enkelt applikation eller flere applikationer er indbyrdes afhængige, afspejles den samme adfærd også i TC'erne.

e) TC'er er udsat for distribution blandt udviklerne (især i testdrevet udviklingsmiljø):

En vigtig kendsgerning ved TC'er er, at disse ikke kun skal bruges af testerne. I det normale tilfælde, når en fejl er under rettelse af udviklerne, bruger de indirekte TC til at løse problemet. Tilsvarende, hvis den testdrevne udvikling følges, bruges TC'er direkte af udviklerne til at opbygge deres logik og dække alle de scenarier i deres kode, der adresseres af TC'er.

Tips til at skrive effektive tests:

Med de ovennævnte 5 faktorer i tankerne, her er et par tip til at skrive effektive TC'er.

Lad os begynde!!!

# 1) Hold det simpelt, men ikke for simpelt; gør det komplekst, men ikke for komplekst:

Denne erklæring synes et paradoks. Men jeg lover, at det ikke er sådan. Hold alle trin i TC'er atomare og præcise. Nævn trinnene med den korrekte rækkefølge og korrekt kortlægning til de forventede resultater. Test case skal være selvforklarende og let at forstå. Dette er hvad jeg mener for at gøre det enkelt.

Nu gør det til et komplekst middel at gøre det integreret med testplanen og andre TC'er. Se de andre TC'er, relevante artefakter, GUI'er osv., Hvor og når det er nødvendigt. Men gør dette på en afbalanceret måde. Lav ikke en tester til at bevæge sig frem og tilbage i dokumentbunken for at udfylde et enkelt testscenarie.

På den anden side skal du ikke engang lade testeren dokumentere disse TC'er på en meget kompakt måde. Mens du skriver TC'er, skal du altid huske, at du eller en anden bliver nødt til at revidere og opdatere disse.

# 2) Efter at have dokumenteret testsagerne skal du gennemgå en gang som Tester:

Tror aldrig, at jobbet er udført, når du har skrevet den sidste TC i testscenariet. Gå til starten og gennemgå alle TC'erne en gang, men ikke med tankegangen til en TC-forfatter eller testplanlægger. Gennemgå alle TC'er med en testers sind. Tænk rationelt, og prøv at tørre dine TC'er.

Evaluer at alle trin og se om du har nævnt disse tydeligt på en forståelig måde, og de forventede resultater er i harmoni med disse trin.

Sørg for, at testdata specificeret i TC'er er mulig ikke kun for faktiske testere, men er også i overensstemmelse med realtidsmiljøet. Sørg for, at der ikke er nogen afhængighedskonflikt mellem TC'er, og kontroller, at alle referencer til andre TC'er / artefakter / GUI'er er korrekte. Ellers kan testerne være i store problemer.

# 3) Bundet såvel som lettere testere:

Efterlad ikke testdataene på testere. Giv dem en række input, især hvor beregninger skal udføres, eller applikationsadfærd afhænger af input. Du kan lade dem bestemme værdierne for testdataelementet, men give dem aldrig friheden til selv at vælge testdataelementerne.

Fordi de bevidst eller utilsigtet bruger de samme testdata igen og igen, og nogle vigtige testdata kan ignoreres under udførelsen af ​​TC'er.

Hold testerne rolige ved at organisere TC'erne i henhold til testkategorierne og de relaterede områder i en applikation. Instruer og nævn klart hvilke TC'er der er indbyrdes afhængige og / eller batchede. Angiv ligeledes eksplicit hvilke TC'er der er uafhængige og isolerede, så testeren kan styre sin samlede aktivitet i overensstemmelse hermed.

På dette tidspunkt er du måske interesseret i at læse om analyse af grænseværdier, der er en test case design strategi, der bruges i sort boks test. Klik på her at vide mere om det.

# 4) Vær en bidragyder:

Accepter aldrig FS eller designdokumentet, som det er. Dit job er ikke kun at gå gennem FS og identificere testscenarierne. At være en QA-ressource, tøv aldrig med at bidrage til forretningen og komme med forslag, hvis du føler, at noget kan forbedres i applikationen.

Foreslå også udviklere, især i TC-drevet udviklingsmiljø. Foreslå rullelister, kalenderkontrol, valgliste, gruppe-radioknapper, mere meningsfulde meddelelser, advarsler, meddelelser, forbedringer relateret til brugervenlighed osv.

At være en QA, ikke bare teste, men gør en forskel!

# 5) Glem aldrig slutbrugeren:

Den vigtigste interessent er 'Slutbruger', som endelig vil bruge applikationen. Så glem ham aldrig på noget tidspunkt i skrivning af TC'er. Faktisk bør slutbrugeren ikke ignoreres på noget tidspunkt i hele SDLC. Alligevel er min vægt indtil videre kun relateret til mit emne.

Så under identifikationen af ​​testscenarier må du aldrig overse de sager, der mest bruges af brugeren eller de sager, der er forretningskritiske, selvom de bruges mindre hyppigt. Hold dig i slutbrugerens sko, og gå derefter gennem alle TC'erne og bedøm den praktiske værdi af at udføre alle dine dokumenterede TC'er.

***********************************************

Sådan opnås ekspertise i dokumentation af testsager

At være softwaretester, vil du helt sikkert være enig med mig i, at det virkelig er en udfordrende opgave at komme med et perfekt testdokument.

Vi giver altid mulighed for forbedringer i vores Test sagsdokumentation . Nogle gange er vi ikke i stand til at give 100% testdækning gennem TC'erne, og til tider er testskabelonen ikke på niveau, eller vi mangler god læsbarhed og klarhed til vores tests.

Når du tester, skal du ikke bare starte væk ad ad hoc når du bliver bedt om at skrive testdokumentation. Det er meget vigtigt at forstå formålet med at skrive testsager i god tid inden du arbejder på dokumentationsprocessen.

Testene skal altid være klare og klare. De skal skrives på en måde, der giver testeren lethed til at udføre den komplette test ved at følge de trin, der er defineret i hver af testene.

Derudover skal testcase-dokumentet indeholde så mange sager, som det kræves for at levere komplette test dækning . For eksempel , skal du prøve at dække testningen for alle mulige scenarier, der kan opstå i dit softwareprogram.

Med de ovennævnte punkter i tankerne, lad mig nu tage dig gennem en rundvisning om, hvordan du opnår fremragende kvalitet i testdokumentation.

Nyttige tip og tricks

Her vil jeg give dig nogle nyttige retningslinjer, der kan give dig et ben i din testdokumentation fra de andre.

# 1) Er dit testdokument i god form?

Den bedste og enkle måde at organisere dit testdokument på er ved at opdele det i mange nyttige sektioner. Opdel hele testen i flere testscenarier. Del derefter hvert scenarie i flere tests. Endelig opdel hver sag i flere testtrin.

Hvis du bruger excel, skal du dokumentere hver testcase på et separat ark i projektmappen, hvor hver testcase beskriver en komplet testflow.

# 2) Glem ikke at dække de negative sager

Som softwaretester skal du tænke uden for boksen og udarbejde alle de muligheder, som din applikation kommer på tværs af. Vi som testere er nødt til at kontrollere, at hvis et uautentisk forsøg på at komme ind i softwaren eller ugyldige data til at flyde over applikationen skal stoppes og rapporteres.

Således er en negativ sag lige så vigtig som en positiv sag. Sørg for, at for hvert scenarie, du har to testsager - en positiv og en negativ . Den positive skal dække den tilsigtede eller normale strøm, og den negative skal dække den utilsigtede eller usædvanlige strøm.

# 3) Har trin til atomtest

Hvert teststrin skal være et atomært trin. Der bør ikke være yderligere deltrin. Jo mere simpelt og klart et testtrin er, jo lettere ville det være at gå videre med testen.

# 4) Prioriter testene

Vi har ofte strenge tidslinjer til at afslutte testning af en applikation. I dette tilfælde kan vi gå glip af at teste nogle af de vigtige funktioner og aspekter ved softwaren. For at undgå dette skal du tagge en prioritet med hver test, mens du dokumenterer den.

Du kan bruge en hvilken som helst kodning til at definere prioriteten for en test. Det er generelt bedre at bruge et af de 3 niveauer, høj, medium og lav , eller 1, 50 og 100. Så når du har en streng tidslinje, skal du først gennemføre alle testene med høj prioritet og derefter gå til mellem- og lavprioritetstestene.

For eksempel - for et shoppingwebsted kan det være en sag med høj prioritet at verificere adgangsnægtelse for et ugyldigt forsøg på at logge ind i appen. Bekræftelse af visning af relevante produkter på brugerskærmen kan være et mellemprioriteret tilfælde og kontrol af farven på teksten, der vises skærmknapperne kan være en lavprioritetstest.

# 5) Sekvens spørgsmål

Bekræft, om rækkefølgen af ​​trin i testen er helt korrekt. En forkert rækkefølge af trin kan føre til forvirring. Trinene bør fortrinsvis også definere hele sekvensen fra at komme ind i appen, indtil den forlader appen for et bestemt scenario, der testes.

# 6) Føj tidsstempel og testernavn til kommentarerne

Der kan være et tilfælde, hvor du tester en applikation, nogen foretager ændringer parallelt med den samme app, eller nogen opdaterer muligvis appen, når din test er udført. Dette fører til en situation, hvor dine testresultater kan variere med tiden.

Så det er altid bedre at tilføje en tidsstempel med testers navn i testkommentarerne, så et testresultat (bestå eller ikke) kan tilskrives tilstanden for en applikation på det bestemte tidspunkt. Alternativt kan du få en Udført dato Kolonne tilføjet særskilt til testsagen, som eksplicit identificerer teststemplets tidsstempel.

# 7) Inkluder browseroplysninger

Som du ved, kan testresultaterne variere afhængigt af den browser, testen er udført på, hvis det er en webapplikation. For at gøre det lettere for andre testere, udviklere eller den, der gennemgår testdokumentet, skal du tilføje browserens navn og version til sagen, så fejlen let kan replikeres.

# 8) Opbevar to separate ark - 'Bugs' & 'Summary' i dokumentet

Hvis du dokumenterer i et excel, skal de første to ark i projektmappen være Resume og Bugs. Resuméarket skal opsummere testscenariet, og fejlarket skal angive alle de problemer, der opstår under testningen. Betydningen af ​​at tilføje disse to ark er, at det vil give en klar forståelse af testen til læseren / brugeren af ​​dokumentet.

Så når tiden er begrænset, kan disse to ark vise sig at være meget nyttige til at give et overblik over testningen.

Testdokumentet skal give den bedst mulige testdækning, fremragende læsbarhed og skal følge et standardformat hele vejen igennem.

Vi kan opnå ekspertise i testdokumentation ved blot at holde nogle få vigtige tip i tankerne, når vi organiserer testdokumenter, prioriterer TC'erne, har alt i korrekt rækkefølge, inklusive alle obligatoriske detaljer til at udføre en TC, og giver klare og klare testtrin, osv. som beskrevet ovenfor.

***********************************************

Hvordan IKKE skal skrive tests

Vi bruger det meste af vores tid på at skrive, gennemgå, udføre eller vedligeholde disse. Det er ret uheldigt, at tests også er de mest fejlbehæftede. Forskellene i forståelse, organisationstestpraksis, mangel på tid osv. Er nogle af grundene til, at vi ofte ser tests, der lader meget tilbage at ønske.

Der er mange artikler på vores side om dette emne, men her kan du se Hvordan man IKKE skal skrive testcases - et par tip, der vil være med til at skabe særprægede, kvalitet og effektive tests.

Lad os læse videre, og vær opmærksom på, at disse tip er til både nye og erfarne testere.

3 mest almindelige problemer i testsager

1. Sammensatte trin
2. Applikationsadfærd tages som forventet adfærd
3. Flere forhold i et tilfælde

Disse tre skal være på min top 3-liste over almindelige problemer i testskrivningsprocessen.

Hvad der er interessant er, at disse sker med både nye og erfarne testere, og vi følger bare de samme fejlbehæftede processer uden at indse, at et par enkle tiltag let kan løse ting.

Lad os komme til det og diskutere hver enkelt i detaljer:

# 1) Sammensatte trin

Først og fremmest, hvad er et sammensat trin?

For eksempel giver du anvisninger fra punkt A til punkt B: hvis du siger, at 'Gå til XYZ sted og derefter til ABC', vil dette ikke give meget mening, for her finder vi os selv tænker - 'Hvordan gør jeg komme i første omgang til XYZ ”- start i stedet med“ Drej til venstre herfra og gå 1 mil, og drej derefter til højre ad Rd. nr. 11 for at nå frem til XYZ ”kan opnå bedre resultater.

Præcis de samme regler gælder også for test og dets trin.

For eksempel Jeg skriver en test til Amazon.com - bestil et produkt.

Følgende er mine testtrin (Bemærk: Jeg skriver kun trinene og ikke alle de andre dele af testen som det forventede resultat osv.)

til . Start Amazon.com
b . Søg efter et produkt ved at indtaste produktets nøgleord / navn i feltet 'Søg' øverst på skærmen.
c . Vælg den første fra de viste søgeresultater.
d . Klik på Tilføj til indkøbskurv på siden med produktoplysninger.
er . Checkout og betale.
f . Tjek siden med ordrebekræftelse.

Nu, kan du identificere, hvilket af disse er et sammensat trin? Højre trin (e)

Husk, test handler altid om 'Hvordan' at teste, så det er vigtigt at skrive de nøjagtige trin i 'Sådan tjekker og betaler' i din test.

Derfor er ovenstående tilfælde mere effektive, når de skrives som nedenfor:

til . Start Amazon.com
b . Søg efter et produkt ved at indtaste produktets nøgleord / navn i feltet 'Søg' øverst på skærmen.
c . Vælg den første fra de viste søgeresultater.
d . Klik på Tilføj til indkøbskurv på siden med produktoplysninger.
er . Klik på Checkout på siden med indkøbskurven.
f . Indtast CC-oplysninger, forsendelse og faktureringsoplysninger.
g . Klik på Checkout.
h . Tjek siden med ordrebekræftelse.

Derfor er et sammensat trin det, der kan opdeles i flere individuelle trin. Lad os alle være opmærksomme på denne del, når vi skriver prøver, og jeg er sikker på, at du er enig med mig i, at vi gør dette oftere, end vi er klar over.

# 2) Applikationsadfærd tages som forventet adfærd

Flere og flere projekter skal håndtere denne situation i disse dage.

Mangel på dokumentation, Ekstrem programmering, hurtige udviklingscyklusser er få grunde, der tvinger os til at stole på applikationen (en ældre version eller deromkring) til enten at skrive testene eller at basere selve testen på. Som altid er dette en bevist dårlig praksis - ikke altid rigtig.

Det er harmløst, så længe du holder et åbent sind og holder forventningen om, at - “AUT kan være fejlbehæftet”. Det er kun når du ikke tror, ​​det er, tingene fungerer dårligt. Som altid vil vi lade eksemplerne tale.

Hvis det følgende er den side, du skriver / designer testtrinene til:

Sag 1:

Hvis mine test case trin er som nedenfor:

1. Start shoppingwebstedet.
2. Klik på Forsendelse og retur - Forventet resultat: Forsendelses- og returneringssiden vises med 'Sæt din info her' og en 'Fortsæt' -knap.

Så er dette forkert.

Sag 2:

1. Start shoppingwebstedet.
2. Klik på Forsendelse og returner.
3. I tekstfeltet 'Indtast ordrenummer' i dette skærmbillede skal du indtaste ordrenr.
4. Klik på Fortsæt - Forventet resultat: Detaljerne om ordren relateret til forsendelse og returnering vises.

Sag 2 er en bedre testsag, for selvom referenceansøgningen opfører sig forkert, tager vi kun den som en retningslinje, gør yderligere undersøgelser og skriver den forventede adfærd i henhold til den forventede korrekte funktionalitet.

Bundlinie: Anvendelse som reference er en hurtig genvej, men den kommer med sine egne farer. Så længe vi er forsigtige og kritiske, giver det fantastiske resultater.

# 3) Flere betingelser i et tilfælde

Lad os endnu en gang lære af Eksempel .

Se nedenstående testtrin: Følgende er testtrin inden for en test for en login-funktion.

en. Indtast gyldige detaljer, og klik på Send.
b. Efterlad feltet Brugernavn tomt. Klik på Send.
c. Lad adgangskodefeltet være tomt, og klik på Send.
d. Vælg et allerede logget brugernavn / adgangskode, og klik på Send.

Hvad der skulle være 4 forskellige sager, kombineres i en. Du tænker måske - hvad er der galt med det? Det sparer en masse dokumentation, og hvad jeg kan gøre i 4, jeg gør det i 1 - er ikke så godt? Nå, ikke helt. Grunde?

Læs videre:

• Hvad hvis en af ​​betingelserne mislykkes - vi skal markere hele testen som 'mislykket'. Hvis vi markerer hele sagen 'mislykket', betyder det, at alle 4 betingelser ikke fungerer, hvilket ikke rigtig er sandt.
• Test skal have et flow. Fra forudsætning til trin 1 og gennem trinene. Hvis jeg følger denne sag, i trin (a), hvis den lykkes, bliver jeg logget ind på siden, hvor 'login' -muligheden ikke længere er tilgængelig. Så når jeg kommer til trin (b) - hvor skal testeren indtaste brugernavnet? Ser du, strømmen er brudt.

Derfor skrive modulære tests . Det lyder som en masse arbejde, men alt hvad der kræves for dig, er at adskille ting og bruge vores bedste venner Ctrl + C og Ctrl + V til at arbejde for os. :)

***********************************************

Sådan forbedres effektiviteten af ​​testkasser

Softwaretestere bør skrive deres tests fra det tidligere stadium af softwareudviklings livscyklus, bedst i softwarekravsfasen.

Testadministratoren eller en QA-manager skal indsamle og forberede de maksimalt mulige dokumenter i henhold til nedenstående liste.

Dokumentindsamling til testskrivning

# 1) Dokument til brugerkrav

Det er et dokument, der viser forretningsprocessen, brugerprofiler, brugermiljø, interaktion med andre systemer, udskiftning af eksisterende systemer, funktionelle krav, ikke-funktionelle krav, licens- og installationskrav, ydelseskrav, sikkerhedskrav, brugbarhed og samtidige krav osv. .,

# 2) Dokument til forretningsbrug

Dette dokument beskriver brugssag scenarie med de funktionelle krav set fra forretningsperspektivet. Dette dokument dækker forretningsaktørerne (eller systemet), mål, forudsætninger, efterbetingelser, grundlæggende flow, alternativ strøm, optioner, undtagelser for hver eneste forretningsstrøm i systemet under krav.

# 3) Dokument om funktionelle krav

Dette dokument beskriver de funktionelle krav til hver funktion til systemet under krav.

Normalt fungerer funktionelle kravsdokument som et fælles lager for både udviklings- og testteamet såvel som for projektets interessenter inklusive kunderne for de forpligtede (undertiden frosne) krav, som skal behandles som det vigtigste dokument for enhver softwareudvikling.

# 4) Software-projektplan (valgfri)

Et dokument, der beskriver detaljerne i projektet, mål, prioriteter, milepæle, aktiviteter, organisationsstruktur, strategi, overvågning af fremskridt, risikoanalyse, antagelser, afhængigheder, begrænsninger, uddannelseskrav, klientansvar, projektplan mv.

# 5) QA / testplan

Dette dokument beskriver kvalitetsstyringssystemet, dokumentationsstandarder, ændringskontrolmekanisme, kritiske moduler og funktioner, konfigurationsstyringssystem, testplaner, mangelfølgning, acceptkriterier osv.

Det testplan dokument bruges til at identificere de funktioner, der skal testes, funktioner, der ikke skal testes, testteamsallokeringer og deres grænseflade, ressourcekrav, testplan, testskrivning, testdækning, testleverancer, forudsætning for testudførelse, bugrapportering og sporing mekanisme, testmålinger osv.,

Rigtigt eksempel

Lad os se, hvordan vi effektivt skriver testcases til en velkendt og enkel 'Login'-skærm i henhold til figuren nedenfor. Det tilgang til testning vil være næsten det samme, selv for komplekse skærme med mere information og kritiske funktioner.

# 1) Den første tilgang til enhver testsagsproces vil være at få en skærmprototype (eller wire-frames) som ovenfor, hvis tilgængelig. Dette er muligvis ikke tilgængeligt for nogle af funktionaliteterne og afhænger af kritikken ved designet af en prototype i de tidligere udviklingsstadier.

Men hvis en SRS (Specifikation af softwarekrav) er tilgængelig til projektet, de fleste af skærmprototyperne er udviklet af projektteamet. Denne form for skærm forenkler testers job og øger testens effektivitet.

#to) Dernæst specifikationer for funktionelle krav . Det afhænger af organisationsprocessen, det vil være tilgængeligt i en pakke med flere dokumenter.

Så vælg det bedste dokument til skrivning af sager, enten kan det være et brugerkravsdokument eller en funktionskravspecifikation (eller endda et SRS-dokument, hvis det kan forstås komfortabelt af testteamet), der giver en komplet funktionel strøm af det valgte funktion, der skal testes.

# 3) Når skærmprototypen og funktionelle specifikationer er på plads, skal testeren begynde at skrive sagerne med følgende tilgang og kriterier.

• UI-test :De kontroller / felter, der er synlige for brugeren. Der er statisk kontrol og dynamiske kontroller til rådighed for den funktion, der skal testes. For eksempel, i loginskærmbilledet ovenfor er 'Brugernavn & Adgangskode' teksterne statiske felter, der ikke kræver nogen brugerinteraktion, kun for kun at vise teksten.

• Funktionelle sager :På den anden side er login-knappen og hyperlinks (glemt adgangskode? & Registrering) dynamiske felter, der kræver brugerinteraktion ved at klikke på kontrolelementerne, som vil gøre noget bagefter.

• Database sager :Når brugeren først har indtastet brugernavnet og adgangskoden, kan testene skrives for at kontrollere den relaterede database for, om brugernavnet og adgangskoden er kontrolleret i den rigtige database og tabel, og brugeren har også tilladelse til at logge ind på applikationen under test.
  

• Behandle test :Dette er relateret til processen (ikke de handlinger, der er knyttet til de synlige kontroller, der er tilgængelige på skærmen), der er knyttet til funktionen og funktionaliteten. For eksempel, ved at klikke på Glemt adgangskode-linket i ovenstående eksempelskærm, sendes muligvis en e-mail til brugeren. Så måske skal en e-mail testes for den korrekte proces og bekræftelse.

4) Til sidst skal du holde “ BAOE mantra ', midler i) Basic Flow ii) Alternativ strømning iii) Valgmuligheder og iv) Undtagelser for fuldstændig dækning af det funktionelle flow og den funktion, der skal testes. Hvert koncept skal anvendes på positive og negative tests.

For eksempel, lad os se den enkle BAOE-tilgang til eksemplet på loginskærmen ovenfor.

• Grundlæggende flow: Indtast URL-stien til login i enhver browser, og indtast de krævede oplysninger, og log ind på applikationen.
• Alternativt flow: Installer applikationen på en mobilenhed, og indtast de nødvendige oplysninger, og log ind på applikationen.
• Muligheder: Hvilke muligheder er der for at komme til den samme loginskærm? For eksempel, efter login til applikationen kan klikke på 'Logout' muligvis medbringe den samme skærm, eller hvis sessionens timeout eller sessionen udløb, kan brugeren komme til login-skærmen.
• Undtagelser: Hvad er undtagelser, hvis mine tests er negative? For eksempel, hvis der er indtastet forkerte legitimationsoplysninger på loginskærmen, om brugeren får en fejlmeddelelse eller ingen tilknyttet handling.

Med al denne information i hånden, lad os begynde at skrive TC'erne til loginskærmen i et format med den komplette dækning og sporbarhed og med detaljerede oplysninger. Den logiske rækkefølge og nummerering af identifikation af ' Test sag-id ' vil være meget nyttigt til en hurtig identifikation af eksekveringshistorik i testsager.

Læs også=> 180+ prøve klar til brug test tilfælde til web og desktop applikationer.

Test sagsdokument

Bemærk : Testkolonnerne er ikke begrænset til nedenstående eksempler på testdokument, som kan opretholdes i et excel-ark for at have så mange kolonner, som det kræves for en komplet sporbarhedsmatrix, dvs. prioritet, testets formål, testtype, fejl screenshot-placering etc.,

Læs også=> Eksempel på test case skabelon med eksempler.

For at lette dette dokuments enkelhed og læsbarhed, lad os skrive trinene til at gengive, forventet og faktisk opførsel af testene til loginskærmen i detaljer nedenfor.

Bemærk : Tilføj kolonnen Faktisk adfærd i slutningen af ​​denne skabelon.

Testdataindsamling

Når testsagen skrives, er den vigtigste opgave for enhver tester at indsamle testdata. Denne aktivitet springes over og overses af mange testere med den antagelse, at testsagerne kan udføres med nogle eksempeldata eller dummy-data og kan fødes, når dataene virkelig kræves. Dette er en kritisk misforståelse, der fremfører prøvedata eller inputdata fra sindhukommelsen på tidspunktet for udførelse af testsager.

Hvis dataene ikke indsamles og opdateres i testdokumentet på tidspunktet for testens skrivning, bruger testeren unormalt mere tid på at indsamle dataene på tidspunktet for testudførelsen. Testdataene skal indsamles for både positive og negative tilfælde ud fra hele perspektivet af funktionens flow af funktionen. Dokumentet om forretningsbrug er meget nyttigt i denne situation.

Find et prøve testdokument til de test, der er skrevet ovenfor, hvilket igen vil være nyttigt for, hvor effektivt vi kan indsamle de data, der letter vores job på tidspunktet for testudførelsen.

***********************************************

Betydningen af ​​standardisering af testsagerne

I denne travle verden kan ingen gøre gentagne ting dag ud og dag ud med det samme niveau af interesse og energi. Især er jeg ikke lidenskabelig for at udføre den samme opgave igen og igen på arbejdspladsen. Jeg kan godt lide at styre ting og spare tid. Enhver i IT skal være sådan.

Alle it-virksomheder udfører forskellige typer projekter. Disse projekter kan enten være produktbaserede eller servicebaserede. Ud af disse projekter arbejder de fleste omkring websteder og test af websteder . Den gode nyhed om det er, at alle websteder har mange ligheder. Og hvis webstederne er for det samme domæne, har de også flere fælles funktioner.

Spørgsmålet, der altid forvirrer mig, er at: “Hvis de fleste applikationer f.eks. Er ens: f.eks. Detailwebsteder, der er blevet testet tusind gange før,” Hvorfor skal vi skrive testcases til endnu et detailwebsted fra bunden? ” Vil det ikke spare masser af tid ved at trække de eksisterende testskripter, der blev brugt til at teste et tidligere detailsted, ud?

Sikker på, at der muligvis er nogle små justeringer, som vi muligvis skal gøre, men generelt er det også lettere, effektivt, tid og penge at spare og hjælper dermed altid med at holde testernes interesse højt. Hvem kan lide at skrive, gennemgå og vedligeholde de samme testsager gentagne gange, ikke? Genbrug af de eksisterende tests kan løse dette i vid udstrækning, og dine kunder finder det også smart og logisk.

Så logisk begyndte jeg at trække de eksisterende scripts fra lignende webbaserede projekter, foretog ændringer og foretog en hurtig gennemgang af dem. Jeg brugte også farvekodning til at vise de ændringer, der blev foretaget, så korrekturlæseren kun kan fokusere på den del, der er blevet ændret.

Årsager til at genbruge testsager

# 1) De fleste funktionelle områder på et websted er næsten - login, registrering, tilføj til indkøbskurv, ønskeliste, checkout, forsendelsesmuligheder, betalingsmuligheder, produktsideindhold, nyligt set, relevante produkter, kampagnekode faciliteter osv.

#to) De fleste af projekterne er kun forbedringer eller ændringer af den eksisterende funktionalitet.

# 3) Indholdsstyringssystemer, der definerer slots til billeduploads på statiske og dynamiske måder, er også almindeligt for alle websteder.

# 4) Detailwebsteder har CSR (Kundeservice) system også.

# 5) Backend-system og lagerapplikation ved hjælp af JDA bruges også af alle websteder.

# 6) Begrebet cookies, timeout og sikkerhed er også almindeligt.

# 7) Webbaserede projekter er ofte tilbøjelige til kravændringer.

# 8) Det typer af test behov er almindelige som browser kompatibilitetstest , test af ydeevne , sikkerhedstest

Ser du, der er masser, der er almindelige og lignende.

Når det er sagt, er genanvendelighed den rigtige vej, nogle gange kan ændringerne i sig selv tage mere eller mindre tid. Nogle gange kan man føle, at det er bedre at starte fra bunden end at ændre så meget.

Dette kan let håndteres ved at oprette et sæt standardtestsager for hver af de fælles funktionaliteter.

Hvad er en standardtest i webtest?

• Opret testtilfælde, der er komplette - trin, data, variabel osv. Dette vil sikre, at de ikke-lignende data / variabler simpelthen kan udskiftes, når en lignende testtilfælde er påkrævet.
• Indgangs- og udgangskriterierne skal defineres korrekt.
• De modificerbare trin eller udsagnet i trinene skal fremhæves i en anden farve for hurtigt at finde og udskifte.
• Det sprog, der bruges til oprettelse af en testtest, skal være generisk.
• Alle funktionerne på hvert websted skal dækkes i testsagerne.
• Navnet på testsagerne skal være navnet på funktionaliteten eller den funktion, som testsagen dækker. Dette vil gøre det lettere at finde testsagen fra sættet.
• Hvis der er nogen grundlæggende eller standardeksempel eller GUI-fil eller skærmbillede af funktionen, skal den vedhæftes med de relevante trin.

Ved at bruge ovenstående tip kan man oprette et sæt standardskripts og bruge dem med ringe eller krævede ændringer til forskellige websteder.

Disse standardtestsager kan også automatiseres, men igen er det altid et plus at fokusere på genanvendelighed. Også hvis automatisering er baseret på en GUI, er genbrug af scripts på tværs af flere webadresser eller websteder noget, jeg personligt aldrig har fundet effektivt.

Brug af et standardsæt med manuelle testtilfælde til forskellige websteder med mindre ændringer er den bedste måde at gennemføre en websitetest på. Alt, hvad vi har brug for, er at oprette og vedligeholde testsagerne med de rette standarder og brug.

Konklusion

Forbedring af testcaseeffektivitet er ikke et enkelt defineret udtryk, men det er en øvelse og kan opnås gennem en modnet proces og regelmæssig praksis.

Testteamet bør ikke være træt af at blive involveret i forbedring af sådanne opgaver, da det er det bedste værktøj til større præstationer i kvalitetsverdenen, dette er bevist i mange af testorganisationerne verden over på missionskritiske projekter og komplekse applikationer.

Håber du ville have fået enorm viden om begrebet Test Cases. Se vores serie af tutorials for at vide mere om testsager, og du er velkommen til at udtrykke dine tanker i kommentarfeltet nedenfor!

Næste tutorial

Anbefalet læsning

• Funktionel testning mod ikke-funktionel testning
• Vejledning til bærbarhedstestning med praktiske eksempler
• Typer af softwaretest: Forskellige testtyper med detaljer
• Bedste softwaretestværktøjer 2021 (QA Test Automation Tools)
• Alpha-test og betatestning (En komplet guide)
• Hvad er systemtest - En ultimativ begyndervejledning
• ISTQB-testcertificeringseksempler på spørgsmålspapirer med svar
• Sådan skriver du softwaretest ugentlig statusrapport