Hur man skriver testfall: Den ultimata guiden med exempel

how write test cases

I denna fördjupade praktiska handledning om hur man skriver testfall har jag täckt detaljerna i vad som är ett testfall, dess standarddefinition och testfallsteknik.

Vad är ett testfall?

Ett testfall har komponenter som beskriver inmatning, åtgärder och ett förväntat svar för att avgöra om en funktion i en applikation fungerar korrekt.

Ett testfall är en uppsättning instruktioner om ”HUR” för att validera ett visst testmål / mål, som när det följs kommer att berätta om systemets förväntade beteende är uppfyllt eller inte.

Lista med handledning som omfattas av denna testfallsserie:

Hur man skriver:

Handledning nr 1: Vad är ett testfall och hur man skriver testfall (denna handledning)
Handledning nr 2: Exempel på testfallsmall med exempel (Ladda ner) (måste läsas)
Handledning nr 3: Skriva testfall från SRS-dokument
Handledning nr 4: Hur man skriver testfall för ett givet scenario
Handledning nr 5: Hur du förbereder dig för testfallshantering
Självstudie nr 6: Hur man skriver negativa testfall

Exempel:

Självstudie 7: 180+ exempel på testfall för webb- och skrivbordsapplikationer
Handledning # 8: 100+ färdiga testscenarier (checklista)

Skrivtekniker:

Handledning nr 9: Orsak- och effektdiagram - Dynamisk testfallsteknik
Handledning nr 10: Testteknik för statlig övergång
Handledning nr 11: Orthogonal Array Testing Technique
Handledning nr 12: Fel gissningsteknik
Handledning nr 13: Fältvalideringstabell (FVT) Testdesignteknik

Testfall mot testscenarier:

Handledning nr 14: Testfall mot testscenarier
Handledning nr 15: Skillnaden mellan testplan, teststrategi och testfall

Automatisering:

Handledning nr 16: Hur man väljer rätt testfall för automatiseringstestning
Handledning nr 17: Hur man översätter manuella testfall till automatiseringsskript

Testhanteringsverktyg:

Handledning nr 18: Bästa testhanteringsverktygen
Handledning nr 19: TestLink för testfallshantering
Handledning nr 20: Skapa och hantera testfall med HP Quality Center
Handledning nr 21: Utföra testfall med ALM / QC

Domänspecifika fall:

Handledning # 22: Testfall för ERP-applikation
Handledning nr 23: JAVA-applikationstestfall
Handledning # 24: Gränsvärdesanalys och ekvivalenspartitionering

Låt oss fortsätta med den första guiden i denna serie.

Rekommenderade verktyg:

Innan du fortsätter till testfallsprocessen rekommenderar vi att du laddar ner detta verktyg för hantering av testfall. Detta underlättar skrivprocessen för testfall som nämns i denna handledning:

# 1) TestRail

=> Ladda ner TestRail Test Case Management Tool

# 2) TestMonitor

Testhantering på toppnivå online. Revolutionerande lätt.

TestMonitor är ett testhanteringsverktyg från början till slut för varje organisation. En enkel, intuitiv metod för testning. Oavsett om du implementerar företagsprogramvara, behöver QA, bygger en kvalitetsapp eller bara behöver en hjälpande hand i ditt testprojekt, har TestMonitor täckt dig.

=> Besök TestMonitors webbplats

Vad du kommer att lära dig:

• Vad är ett testfall och hur man skriver testfall?
  • Varför skriver vi tester?
  • Hur man skriver testfall?
  • Grundformat för testfallet
• Tips för att skriva tester
  • • # 1) Håll det enkelt men inte för enkelt; gör det komplicerat men inte alltför komplext:
    • # 2) Efter att ha dokumenterat testfallet, granska en gång som testare:
    • # 3) Bundet såväl som underlättar testarna:
    • # 4) Var en bidragsgivare:
    • # 5) Glöm aldrig slutanvändaren:
• Hur man uppnår excellens i testfallsdokumentation
  • Användbara tips och tricks
    • # 1) Är ditt testdokument i god form?
    • # 2) Glöm inte att täcka de negativa fallen
    • # 3) Ha steg med atomtest
    • # 4) Prioritera testerna
    • # 5) Sekvensfrågor
    • # 6) Lägg till tidsstämpel och testarens namn i kommentarerna
    • # 7) Inkludera webbläsarinformation
    • # 8) Förvara två separata ark - 'Bugs' och 'Summary' i dokumentet
• Hur man INTE ska skriva tester
  • De 3 vanligaste problemen i testfall
    • # 1) Sammansatta steg
    • # 2) Applikationsbeteende tas som förväntat beteende
    • # 3) Flera villkor i ett fall
• Hur man förbättrar testfallets effektivitet
  • Dokumentsamling för testskrivning
  • Verkligt exempel
  • Testfallsdokument
  • Insamling av testdata
• Vikten av att standardisera testfallet
  • Skäl att återanvända testfall
  • Vad är ett standardtest vid webbtestning?
  • Slutsats
  • Rekommenderad läsning

Vad är ett testfall och hur man skriver testfall?

Att skriva effektiva fall är en färdighet. Och du kan lära dig det av erfarenhet och kunskap om applikationen som testas.

För grundläggande instruktioner om hur man skriver tester, se följande video:

Ovanstående resurser bör ge oss grunderna i testskrivningsprocessen.

Nivåer för testskrivningsprocessen:

• Nivå 1: På denna nivå skriver du grundläggande fall från den tillgängliga specifikationen och användardokumentation.
• Nivå 2: Det här är praktiska scenen där skrivfall beror på applikationens faktiska funktion och systemflöde.
• Nivå 3: Detta är det stadium där du kommer att gruppera några fall och skriv ett testförfarande . Testförfarandet är inget annat än en grupp små fall, kanske högst 10.
• Nivå 4: Automation av projektet. Detta kommer att minimera mänsklig interaktion med systemet och därmed kan QA fokusera på de för närvarande uppdaterade funktionerna för att testa snarare än att förbli upptagen med regressionstestning.

Varför skriver vi tester?

Det grundläggande målet med att skriva ärenden är för att validera testtäckningen för en ansökan.

Om du arbetar i någon CMMi-organisation följs teststandarderna närmare. Att skriva fall ger någon form av standardisering och minimerar ad hoc-metoden vid testning.

Hur man skriver testfall?

Fält:

• Testfall ID
• Enhet att testa: Vad ska verifieras?
• Antaganden
• Testdata: Variabler och deras värden
• Steg som ska utföras
• Förväntat resultat
• Faktiskt resultat
• Godkänd / misslyckad
• Kommentarer

Grundformat för testfallet

Kontrollera
Använder sig av (verktygsnamn, taggnamn, dialogruta, etc)
Med (betingelser)
Till (vad som returneras, visas, demonstreras)

Kontrollera: Används som testordets första ord.
Använder sig av: Att identifiera vad som testas. Du kan använda 'in' eller 'välja' här istället för att använda beroende på situationen.

För alla applikationer måste du täcka alla typer av tester som:

• Funktionella fall
• Negativa fall
• Gränsvärdesfall

När du skriver dessa alla dina TC ska vara enkla och lätta att förstå .

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

Tips för att skriva tester

En av de vanligaste och viktigaste aktiviteterna hos en Software Tester (SQA / SQC person) är att skriva testscenarier och fall.

Det finns några viktiga och kritiska faktorer som är relaterade till denna stora aktivitet. Låt oss först se en fågelperspektiv på dessa faktorer.

Viktiga faktorer som involverar skrivprocessen:

a) TC är benägna att regelbundet revideras och uppdateras:

Vi lever i en ständigt föränderlig värld och detsamma gäller även för programvara. Programvarukrav förändras direkt på fallen. När krav ändras måste TC uppdateras.

Ändå är det inte bara förändringen i kravet som kan orsaka revision och uppdatering av TC: er. Under utförandet av TC: er uppstår många idéer i sinnet och många underbetingelser för en enda TC kan identifieras. Allt detta orsakar en uppdatering av TC: er och ibland leder det till att nya TC: er läggs till.

Dessutom, under regressionstestning, kräver flera korrigeringar och / eller krusningar reviderade eller nya TC: er.

b) TC är benägna att distribuera bland testarna som kommer att utföra dessa:

Naturligtvis finns det knappast en sådan situation där en enda testare utför alla TC: er. Normalt finns det flera testare som testar olika moduler i en enda applikation. Så TC: erna är uppdelade mellan testarna enligt deras egna områden i applikationen som testas.

Vissa TC: er som är relaterade till integrationen av applikationen kan köras av flera testare medan de andra TC: erna endast kan köras av en enda testare.

c) TC är benägna att kluster och gruppering:

Det är normalt och vanligt att TC som tillhör ett enda testscenario vanligtvis kräver att de körs i någon specifik sekvens eller i form av en grupp. Det kan finnas vissa förutsättningar för en TC som kräver körning av andra TC innan de körs själv.

På samma sätt, enligt affärslogiken för AUT, kan en enda TC bidra till flera testvillkor och ett enda testvillkor kan bestå av flera TC.

d) TC har en tendens till interberoende:

Detta är också ett intressant och viktigt beteende hos TC: erna som anger att de kan vara beroende av varandra. Från medelstora till stora applikationer med komplex affärslogik är denna tendens mer synlig.

Det tydligaste området i alla applikationer där detta beteende definitivt kan observeras är interoperabiliteten mellan olika moduler av samma eller till och med olika applikationer. Enkelt talat, varhelst de olika modulerna en enskild applikation eller flera applikationer är beroende av varandra, återspeglas samma beteende också i TC: erna.

e) TC är benägna att distribueras bland utvecklarna (särskilt i testdriven utvecklingsmiljö):

Ett viktigt faktum om TC är att dessa inte bara ska användas av testarna. I det normala fallet, när en bugg fixas av utvecklarna, använder de indirekt TC för att åtgärda problemet. På samma sätt, om den testdrivna utvecklingen följs, används TC: er direkt av utvecklarna för att bygga sin logik och täcka alla scenarier i deras kod som adresseras av TC.

Tips för att skriva effektiva tester:

Med tanke på ovanstående 5 faktorer, här är några tips för att skriva effektiva TC: er.

Låt oss börja!!!

# 1) Håll det enkelt men inte för enkelt; gör det komplicerat men inte alltför komplext:

Detta uttalande verkar vara en paradox. Men jag lovar att det inte är så. Håll alla steg i TC: erna atomära och exakta. Nämn stegen med rätt sekvens och korrekt mappning till förväntade resultat. Testfallet ska vara självförklarande och lätt att förstå. Detta är vad jag menar för att göra det enkelt.

Nu gör det till ett komplext sätt att göra det integrerat med testplanen och andra TC: er. Se de andra TC: erna, relevanta artefakter, GUI osv. Där och när det behövs. Men gör detta på ett balanserat sätt. Gör inte en testare för att flytta fram och tillbaka i dokumenthögen för att slutföra ett enda testscenario.

Å andra sidan, låt inte ens testaren dokumentera dessa TC: er på ett mycket kompakt sätt. När du skriver TC: er, kom alltid ihåg att du eller någon annan måste revidera och uppdatera dessa.

# 2) Efter att ha dokumenterat testfallet, granska en gång som testare:

Tänk aldrig att jobbet är gjort när du har skrivit den sista TC i testscenariot. Gå till början och granska alla TC: er en gång, men inte med tanke på en TC-författare eller testplanerare. Granska alla TC: er med testerna. Tänk rationellt och försök att torka dina TC: er.

Utvärdera alla steg och se om du har nämnt dessa tydligt på ett förståeligt sätt och de förväntade resultaten är i harmoni med dessa steg.

Se till att testdata specificerad i TC: er är möjlig inte bara för faktiska testare utan är också i enlighet med realtidsmiljön. Se till att det inte finns någon beroendekonflikt mellan TC: er och kontrollera att alla referenser till andra TC: er / artefakter / GUI är korrekta. Annars kan testarna ha stora problem.

# 3) Bundet såväl som underlättar testarna:

Lämna inte testdata på testare. Ge dem en rad ingångar, särskilt där beräkningar ska utföras eller applikationens beteende är beroende av ingångar. Du kan låta dem bestämma värdena för testdataobjektet men aldrig ge dem friheten att själva välja testdataobjekten.

Eftersom de medvetet eller oavsiktligt kan använda samma testdata igen och igen och vissa viktiga testdata kan ignoreras under körning av TC.

Håll testarna lugna genom att organisera TC: erna enligt testkategorierna och relaterade områden i en applikation. Instruera och nämna tydligt vilka TC: er som är beroende av varandra och / eller grupperade. Ange också uttryckligen vilka TC: er som är oberoende och isolerade så att testaren kan hantera sin totala aktivitet därefter.

Vid den här tiden kan du vara intresserad av att läsa om analys av gränsvärden, vilket är en testfallstrategidesignstrategi som används vid testning i svart ruta. Klick här att veta mer om det.

# 4) Var en bidragsgivare:

Acceptera aldrig FS eller designdokumentet som det är. Ditt jobb är inte bara att gå igenom FS och identifiera testscenarierna. Att vara en QA-resurs, tveka aldrig att bidra till affärer och ge förslag om du känner att något kan förbättras i applikationen.

Föreslå även utvecklare, särskilt i TC-driven utvecklingsmiljö. Föreslå listrutor, kalenderkontroller, urvalslista, gruppknappar, mer meningsfulla meddelanden, varningar, uppmaningar, förbättringar relaterade till användbarhet etc.

Att vara en QA, testa inte bara utan gör skillnad!

# 5) Glöm aldrig slutanvändaren:

Den viktigaste intressenten är ”Slutanvändaren” som äntligen kommer att använda applikationen. Så, glöm aldrig honom i något skede av TCs skrivning. I själva verket bör slutanvändaren inte ignoreras i något skede under SDLC. Ändå är min betoning hittills bara relaterad till mitt ämne.

Så, under identifieringen av testscenarier, ska du aldrig förbise de fall som mest används av användaren eller de fall som är affärskritiska även om de används mindre ofta. Håll dig i skorna för slutanvändaren och gå igenom alla TC: er och bedöma det praktiska värdet av att utföra alla dina dokumenterade TC: er.

hur öppnar man en jar-fil

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

Hur man uppnår excellens i testfallsdokumentation

Att vara programvarutestare kommer du säkert att hålla med mig om att det är verkligen en utmanande uppgift att komma med ett perfekt testdokument.

Vi lämnar alltid utrymme för förbättringar i våra Dokumentation av testfall . Ibland kan vi inte tillhandahålla 100% testtäckning via TC: erna, och ibland är testmallen inte i nivå, eller så saknar vi god läsbarhet och tydlighet i våra tester.

När du blir ombedd att skriva testdokumentation som testare bör du inte bara börja på ett ad hoc-sätt. Det är mycket viktigt att förstå syftet med att skriva testfall långt innan du arbetar med dokumentationsprocessen.

Testen ska alltid vara tydliga och tydliga. De bör skrivas på ett sätt som gör det lättare för testaren att genomföra den fullständiga testningen genom att följa stegen som definieras i vart och ett av testerna.

Dessutom bör testfallsdokumentet innehålla så många fall som krävs för att tillhandahålla fullständig testtäckning . Till exempel bör du försöka täcka testningen för alla möjliga scenarier som kan uppstå i din programvara.

Med tanke på ovanstående punkter, låt mig nu ta dig igenom en rundtur om hur man uppnår excellens i testdokumentation.

Användbara tips och tricks

Här ska jag ge dig några användbara riktlinjer som kan ge dig ett steg i testdokumentationen från de andra.

# 1) Är ditt testdokument i god form?

Det bästa och enkla sättet att organisera testdokumentet är att dela upp det i många enskilda användbara avsnitt. Dela upp hela testningen i flera testscenarier. Dela sedan varje scenario i flera tester. Slutligen delar upp varje fall i flera teststeg.

Om du använder excel ska du dokumentera varje testfall på ett separat ark i arbetsboken där varje testfall beskriver ett komplett testflöde.

# 2) Glöm inte att täcka de negativa fallen

Som programvarutestare måste du tänka utanför lådan och ta fram alla möjligheter som din applikation stöter på. Vi, som testare, måste verifiera att om ett oautentiskt försök att gå in i programvaran eller någon ogiltig data för att flöda över applikationen ska stoppas och rapporteras.

Således är ett negativt fall lika viktigt som ett positivt fall. Se till att för varje scenario du har två testfall - ett positivt och ett negativt . Den positiva bör täcka det avsedda eller normala flödet och den negativa bör täcka det oavsiktliga eller exceptionella flödet.

# 3) Ha steg med atomtest

Varje teststeg ska vara atomärt. Det bör inte finnas några ytterligare delsteg. Ju enklare och tydligare ett teststeg är, desto lättare skulle det vara att fortsätta med testningen.

# 4) Prioritera testerna

Vi har ofta strikta tidslinjer för att slutföra testningen av en applikation. I det här fallet kan vi missa att testa några av de viktiga funktionerna och aspekterna av programvaran. För att undvika detta bör du märka en prioritet vid varje test medan du dokumenterar det.

Du kan använda vilken kodning som helst för att definiera prioriteten för ett test. Det är i allmänhet bättre att använda någon av de tre nivåerna, hög, medium och låg , eller 1, 50 och 100. När du har en strikt tidslinje, bör du slutföra alla tester med hög prioritet och sedan gå till mellan- och lågprioritetstesterna.

Till exempel - För en shoppingwebbplats kan verifiering av åtkomstförnekande för ett ogiltigt försök att logga in i appen vara ett fall med hög prioritet, verifiering av visning av relevanta produkter på användarskärmen kan vara ett medelprioritetsfall och verifiera färgen på texten som visas skärmknapparna kan vara ett lågprioritetstest.

# 5) Sekvensfrågor

Bekräfta om steget i testet är helt korrekt. En fel sekvens av steg kan leda till förvirring. Företrädesvis bör stegen också definiera hela sekvensen från att komma in i appen till att lämna appen för ett visst scenario som testas.

# 6) Lägg till tidsstämpel och testarens namn i kommentarerna

Det kan finnas ett fall där du testar en applikation, någon gör ändringar parallellt med samma app eller någon kan uppdatera appen efter att din testning är klar. Detta leder till en situation där dina testresultat kan variera med tiden.

Så det är alltid bättre att lägga till en tidsstämpel med testarens namn i testkommentarerna så att ett testresultat (godkänt eller misslyckat) kan tillskrivas tillståndet för en applikation vid den aktuella tiden. Alternativt kan du få en Verkställd datum Kolumnen läggs till separat i testfallet som uttryckligen kommer att identifiera teststämplingen.

# 7) Inkludera webbläsarinformation

Som du vet kan testresultaten variera beroende på vilken webbläsare testet utförs om det är en webbapplikation. För att underlätta för andra testare, utvecklare eller den som granskar testdokumentet, bör du lägga till webbläsarens namn och version i ärendet så att felet enkelt kan replikeras.

# 8) Förvara två separata ark - 'Bugs' och 'Summary' i dokumentet

Om du dokumenterar i ett excel ska de två första arken i arbetsboken vara Sammanfattning och Bugg. Sammanfattningsbladet ska sammanfatta testscenariot och Bugs-arket bör lista alla problem som uppstod under testningen. Betydelsen av att lägga till dessa två ark är att det ger en tydlig förståelse av testningen för läsaren / användaren av dokumentet.

Så när tiden är begränsad kan dessa två ark visa sig vara mycket användbara för att ge en översikt över testningen.

Testdokumentet ska ge bästa möjliga testtäckning, utmärkt läsbarhet och bör följa ett standardformat hela tiden.

Vi kan uppnå enastående testdokumentation genom att bara hålla några viktiga tips i åtanke när vi organiserar testfallsdokument, prioriterar TC: erna, har allt i rätt ordning, inklusive alla obligatoriska detaljer för att utföra en TC, och tillhandahåller tydliga och klara teststeg, etc. såsom diskuterats ovan.

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

Hur man INTE ska skriva tester

Vi tillbringar större delen av vår tid med att skriva, granska, genomföra eller underhålla dessa. Det är ganska olyckligt att test också är de mest felbenägna. Skillnaderna i förståelse, organisationstest, brist på tid etc. är några av anledningarna till att vi ofta ser tester som lämnar mycket att önska.

Det finns många artiklar på vår webbplats om detta ämne, men här kommer vi att se Hur man INTE skriver testfall - några tips som kommer att vara avgörande för att skapa distinkta, kvalitativa och effektiva tester.

Låt oss läsa vidare och observera att dessa tips är till för både nya och erfarna testare.

De 3 vanligaste problemen i testfall

1. Sammansatta steg
2. Applikationsbeteende tas som förväntat beteende
3. Flera villkor i ett fall

Dessa tre måste vara på min topp 3-lista över vanliga problem i testskrivningsprocessen.

Det som är intressant är att dessa händer med både nya och erfarna testare och vi fortsätter att följa samma felaktiga processer utan att inse att några enkla åtgärder kan fixa saker enkelt.

Låt oss gå till det och diskutera var och en i detalj:

# 1) Sammansatta steg

Först och främst, vad är ett sammansatt steg?

Till exempel ger du anvisningar från punkt A till punkt B: om du säger att 'Gå till XYZ-plats och sedan till ABC' kommer det inte att vara mycket meningsfullt, för här tänker vi - 'Hur gör jag komma till XYZ i första hand ”- börja istället med” Sväng vänster härifrån och gå 1 mil, sväng sedan höger på Rd. nr 11 för att komma fram till XYZ ”kan uppnå bättre resultat.

Exakt samma regler gäller även för tester och dess steg.

Till exempel Jag skriver ett test för Amazon.com - gör en beställning för vilken produkt som helst.

Följande är mina teststeg (Obs! Jag skriver bara stegen och inte alla andra delar av testet som det förväntade resultatet etc.)

till . Starta Amazon.com
b . Sök efter en produkt genom att ange produktens nyckelord / namn i fältet 'Sök' högst upp på skärmen.
c . Välj det första från sökresultaten som visas.
d . Klicka på Lägg i varukorg på produktinformationssidan.
är . Kassa och betala.
f . Kontrollera sidan för orderbekräftelse.

Nu, kan du identifiera vilka av dessa som är ett sammansatt steg? Höger- steg (e)

Kom ihåg att tester handlar alltid om 'Hur' att testa, så det är viktigt att skriva de exakta stegen i 'Hur du checkar ut och betalar' i ditt test.

Därför är ovanstående fall mer effektiva när de skrivs enligt nedan:

till . Starta Amazon.com
b . Sök efter en produkt genom att ange produktens nyckelord / namn i fältet 'Sök' högst upp på skärmen.
c . Välj det första från sökresultaten som visas.
d . Klicka på Lägg i varukorg på produktinformationssidan.
är . Klicka på Kassan i varukorgssidan.
f . Ange CC-information, frakt och faktureringsinformation.
g . Klicka på Kassa.
h . Kontrollera sidan för orderbekräftelse.

Därför är ett sammansatt steg det som kan delas upp i flera individuella steg. Nästa gång vi skriver tester, låt oss alla vara uppmärksamma på den här delen och jag är säker på att du håller med mig om att vi gör det oftare än vi inser.

# 2) Applikationsbeteende tas som förväntat beteende

Fler och fler projekt måste hantera denna situation idag.

Brist på dokumentation, extrem programmering, snabba utvecklingscykler är några skäl som tvingar oss att lita på applikationen (en äldre version eller så) för att antingen skriva testerna eller att basera själva testningen på. Som alltid är detta en bevisad dålig praxis - inte alltid riktigt.

Det är ofarligt så länge du håller ett öppet sinne och behåller förväntningen att - “AUT kan vara felaktig”. Det är först när du inte tror att det är så, saker fungerar dåligt. Som alltid låter vi exemplen prata.

Om följande är den sida du skriver / utformar teststegen för:

Fall 1:

Om mitt testfall är som nedan:

1. Starta shoppingwebbplatsen.
2. Klicka på Frakt och retur - Förväntat resultat: Frakt- och retursidan visas med “Lägg din information här” och en “Fortsätt” -knapp.

Då är detta felaktigt.

Fall 2:

1. Starta shoppingwebbplatsen.
2. Klicka på Frakt och returnera.
3. I textrutan ”Ange beställningsnummer” som finns på denna skärm anger du beställningsnummer.
4. Klicka på Fortsätt - Förväntat resultat: Informationen om beställningen relaterad till frakt och returer visas.

Fall 2 är ett bättre testfall eftersom även om referensapplikationen beter sig fel tar vi det bara som en riktlinje, gör ytterligare undersökningar och skriver det förväntade beteendet enligt den förväntade korrekta funktionen.

Slutsats: Tillämpning som referens är en snabbgenväg men den har sina egna risker. Så länge vi är försiktiga och kritiska ger det fantastiska resultat.

# 3) Flera villkor i ett fall

Låt oss än en gång lära av Exempel .

Ta en titt på teststegen nedan: Följande är teststegen inom ett test för en inloggningsfunktion.

a. Ange giltiga uppgifter och klicka på Skicka.
b. Lämna användarnamnfältet tomt. Klicka på Skicka.
c. Lämna lösenordsfältet tomt och klicka på Skicka.
d. Välj ett redan inloggat användarnamn / lösenord och klicka på Skicka.

Vad som måste vara fyra olika fall kombineras i ett. Du kanske tänker - Vad är fel med det? Det sparar mycket dokumentation och vad jag kan göra i 4, jag gör det i 1 är inte så bra? Tja, inte riktigt. Anledningar?

Läs vidare:

• Vad händer om ett av villkoren misslyckas - vi måste markera hela testet som 'misslyckat'. Om vi ​​markerar att hela ärendet 'misslyckades' betyder det att alla fyra villkoren inte fungerar, vilket inte är sant.
• Tester måste ha ett flöde. Från förutsättning till steg 1 och hela stegen. Om jag följer detta fall, i steg (a), om det lyckas, kommer jag att loggas in på sidan, där alternativet 'inloggning' inte längre är tillgängligt. Så när jag kommer till steg (b) - var ska testaren ange användarnamnet? Ser du, flödet är trasigt.

Därmed, skriva modulära tester . Det låter som mycket arbete men allt som krävs för dig är att separera saker och använda våra bästa vänner Ctrl + C och Ctrl + V för att arbeta för oss. :)

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

Hur man förbättrar testfallets effektivitet

Programvarutestarna bör skriva sina tester från det tidigare skedet av programvaruutvecklingens livscykel, bäst under programvarukravsfasen.

Testchefen eller en QA-chef ska samla in och förbereda maximalt möjliga dokument enligt listan nedan.

Dokumentsamling för testskrivning

# 1) Dokument om användarkrav

Det är ett dokument som listar affärsprocessen, användarprofiler, användarmiljö, interaktion med andra system, ersättning av befintliga system, funktionella krav, icke-funktionella krav, licensiering och installationskrav, prestandakrav, säkerhetskrav, användbarhet och samtidiga krav etc. .,

# 2) Affärsdokument

Detta dokument beskriver användningsfall scenario för funktionskraven ur affärsperspektivet. Detta dokument täcker affärsaktörerna (eller systemet), mål, förutsättningar, efterförhållanden, grundflöde, alternativt flöde, alternativ, undantag för varje affärsflöde i systemet under krav.

# 3) Dokument om funktionskrav

Detta dokument beskriver funktionskraven för varje funktion för systemet under krav.

Normalt fungerar funktionella kravdokument som ett gemensamt arkiv för både utvecklings- och testteamet och för projektets intressenter inklusive kunderna för de engagerade (ibland frysta) kraven, som bör behandlas som det viktigaste dokumentet för all mjukvaruutveckling.

# 4) Projektplan för programvara (valfritt)

Ett dokument som beskriver detaljerna i projektet, mål, prioriteringar, milstolpar, aktiviteter, organisationsstruktur, strategi, övervakning av framsteg, riskanalys, antaganden, beroenden, begränsningar, utbildningskrav, kundansvar, projektplan etc.

# 5) QA / testplan

Detta dokument beskriver kvalitetshanteringssystemet, dokumentationsstandarder, ändringsstyrmekanism, kritiska moduler och funktioner, konfigurationshanteringssystem, testplaner, spårning av fel, acceptanskriterier etc.

De testplan dokumentet används för att identifiera de funktioner som ska testas, funktioner som inte ska testas, testa teamallokeringar och deras gränssnitt, resurskrav, testschema, testskrivning, testtäckning, testleveranser, förutsättning för testutförande, felrapportering och spårning mekanism, testmått etc.,

Verkligt exempel

Låt oss se hur man effektivt skriver testfall för en bekant och enkel 'Login' skärm enligt figuren nedan. De metod för testning kommer att vara nästan samma även för komplexa skärmar med mer information och kritiska funktioner.

# 1) Det första tillvägagångssättet för alla testfallsprocesser är att få en skärmprototyp (eller trådramar) enligt ovan, om tillgänglig. Detta kanske inte är tillgängligt för vissa av funktionerna och beror på kritiken för att utforma en prototyp i de tidigare utvecklingsstadierna.

Men om en SRS (Specifikation av programvarukrav) är tillgängligt för projektet, de flesta av skärmprototyperna är utvecklade av projektteamet. Denna typ av skärm förenklar testarens jobb och ökar effektiviteten i testerna.

#två) Nästa, den specifikationer för funktionskrav . Det beror på organisationsprocessen, det kommer att finnas i en serie med flera dokument.

Så besluta det bästa dokumentet för att skriva ärenden, antingen kan det vara ett användarkravsdokument eller en funktionskravspecifikation (eller till och med ett SRS-dokument om det kan förstås bekvämt av testteamet) som ger ett fullständigt funktionellt flöde av det valda funktion som ska testas.

# 3) När skärmprototypen och funktionsspecifikationerna är på plats bör testaren börja skriva ärenden med följande tillvägagångssätt och kriterier.

• UI-tester :Kontrollerna / fälten som är synliga för användaren. Det finns statisk kontroll och dynamiska kontroller tillgängliga för funktionen som ska testas. Till exempel, i inloggningsskärmen ovan är texten ”Användarnamn & lösenord” stata fält som inte kräver någon användarinteraktion, bara för att endast visa texten.

• Funktionella fodral :Å andra sidan är inloggningsknappen och hyperlänkar (glömt lösenord? & Registrering) dynamiska fält som kräver användarinteraktion genom att klicka på kontrollerna, som kommer att göra några åtgärder efteråt.

• Databasfall :När användaren har angett användarnamnet och lösenordet kan testerna skrivas för att kontrollera den relaterade databasen, oavsett om användarnamnet och lösenordet är kontrollerat i rätt databas och rätt tabell och användaren har också behörighet att logga in på applikationen som testas.
  

• Processprov :Detta är relaterat till processen (inte de åtgärder som är associerade med de synliga kontrollerna som är tillgängliga på skärmen) associerade med funktionen och funktionaliteten. Till exempel, klicka på Glömt lösenordslänken i ovanstående exempelskärm kan skicka ett e-postmeddelande till användaren. Så kanske ett e-postmeddelande måste testas för korrekt process och bekräftelse.

4) Håll slutligen ” BAOE mantra ', betyder att i) Grundflöde ii) Alternativt flöde iii) Alternativ och iv) Undantag för fullständig täckning av det funktionella flödet och funktionen som ska testas. Varje koncept ska tillämpas på positiva och negativa tester.

Till exempel, låt oss se det enkla BAOE-tillvägagångssättet för exempel på inloggningsskärmen ovan.

• Grundflöde: Ange webbadressen till inloggningen i vilken webbläsare som helst och ange den information som krävs och logga in på applikationen.
• Alternativt flöde: Installera applikationen på en mobil enhet och ange den information som krävs och logga in på applikationen.
• Alternativ: Vilka är tillgängliga alternativ för att komma till samma inloggningsskärm? Till exempel, efter inloggning till applikationen, klickar du på ”Logga ut” kan samma skärm visas eller om sessionens timeout eller session upphörde kan användaren komma till inloggningsskärmen.
• Undantag: Vad är undantag om mina tester är negativa? Till exempel, om fel inloggning anges i inloggningsskärmen, om användaren får ett felmeddelande eller ingen åtgärd associerad.

Med all denna information i handen, låt oss börja skriva TC: erna för inloggningsskärmen, i ett format med fullständig täckning och spårbarhet och med detaljerad information. Den logiska sekvensen och numreringen för att identifiera Testfall ID ' kommer att vara mycket användbart för en snabb identifieringsutförande av testfall.

Läs också=> 180+ prov färdigt att använda testfall för webb- och skrivbordsapplikationer.

Testfallsdokument

Notera : Testkolumnerna är inte begränsade till nedanstående provtestdokument, som kan upprätthållas i ett excel-ark för att ha så många kolumner som krävs för en fullständig spårbarhetsmatris, prioritet, syfte med testning, typ av testning, fel skärmdump plats etc.,

Läs också=> Exempel på testfallsmall med exempel.

För att underlätta det här dokumentets enkelhet och läsbarhet, låt oss skriva stegen för att återge, förväntat och faktiskt beteende för testerna för inloggningsskärmen i detalj nedan.

Notera : Lägg till faktiskt beteendekolumn i slutet av den här mallen.

Insamling av testdata

När testfallet skrivs är den viktigaste uppgiften för alla testare att samla in testdata. Denna aktivitet hoppas över och förbises av många testare med antagandet att testfallet kan utföras med en del provdata eller dummydata och kan matas när data verkligen krävs. Detta är en kritisk missuppfattning att mata samplingsdata eller mata in data från minnet vid tidpunkten för utförandet av testfall.

Om uppgifterna inte samlas in och uppdateras i testdokumentet när testet skrivs, skulle testaren spendera onormalt mer tid på att samla in data vid tidpunkten för testkörningen. Testdata bör samlas in för både positiva och negativa fall ur funktionens funktionalitet. Dokumentet om affärsanvändningsfall är mycket användbart i denna situation.

Hitta ett provtestdokument för de tester som skrivits ovan, vilket i sin tur kommer att vara till hjälp för hur effektivt vi kan samla in data som underlättar vårt jobb vid testutförandet.

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

Vikten av att standardisera testfallet

I denna hektiska värld kan ingen göra repetitiva saker dag in och dag ut med samma intresse och energi. Särskilt brinner jag inte för att göra samma uppgift om och om igen på jobbet. Jag gillar att hantera saker och spara tid. Alla i IT borde vara så.

Alla IT-företag genomför olika typer av projekt. Dessa projekt kan antingen vara produktbaserade eller tjänstebaserade. Av dessa projekt arbetar de flesta med webbplatser och webbplats testning . Den goda nyheten om det är att alla webbplatser har många likheter. Och om webbplatserna är för samma domän har de också flera gemensamma funktioner.

Frågan som alltid förvirrar mig är att: 'Om de flesta applikationer är likartade, till exempel: till exempel detaljhandelssajter, som har testats tusen gånger tidigare,' Varför behöver vi skriva testfall för ännu en detaljhandeln från grunden? ” Kommer det inte att spara massor av tid genom att dra ut befintliga testskript som användes för att testa en tidigare detaljhandelssida?

Visst, det kan finnas några små justeringar som vi kan behöva göra, men totalt sett är det också lättare, effektivt, tids- och pengarbesparande och därmed alltid hjälper till att hålla testarnas intressen höga. Vem gillar att skriva, granska och underhålla samma testfall upprepade gånger, eller hur? Återanvändning av befintliga tester kan lösa detta i stor utsträckning och dina kunder kommer att tycka att det är smart och logiskt också.

Så logiskt började jag dra befintliga skript från liknande webbaserade projekt, gjorde ändringar och gjorde en snabb genomgång av dem. Jag använde också färgkodning för att visa de ändringar som gjordes, så att granskaren bara kan fokusera på den del som har ändrats.

Skäl att återanvända testfall

# 1) De flesta funktionella områden på en webbplats är nästan - inloggning, registrering, lägg i kundvagn, önskelista, kassa, leveransalternativ, betalningsalternativ, innehåll på produktsidan, nyligen visade, relevanta produkter, kampanjkod etc.

#två) De flesta av projekten är bara förbättringar eller ändringar av den befintliga funktionaliteten.

# 3) Innehållshanteringssystem som definierar platserna för bilduppladdningar på statiska och dynamiska sätt är också vanligt för alla webbplatser.

# 4) Detaljhandelswebbplatser har CSR (Kundtjänst) -system också.

# 5) Backend-system och lagerapplikation med JDA används också av alla webbplatser.

# 6) Begreppet cookies, timeout och säkerhet är också vanligt.

# 7) Webbaserade projekt är ofta utsatta för kravförändringar.

# 8) De typer av tester behövs är vanliga som webbläsare kompatibilitetstest , prestandatester , säkerhetstestning

Du förstår, det finns mycket som är vanligt och liknande.

Med detta sagt är återanvändbarhet vägen att gå, ibland kan ändringarna själva eller inte ta mer eller mindre tid. Ibland kan man känna att det är bättre att börja från grunden än att ändra så mycket.

Detta kan enkelt hanteras genom att skapa en uppsättning standardtestfall för var och en av de vanliga funktionerna.

Vad är ett standardtest vid webbtestning?

• Skapa testfall som är kompletta - steg, data, variabel etc. Detta kommer att säkerställa att data som inte är liknande / variabel helt enkelt kan ersättas när ett liknande testfall krävs.
• In- och utgångskriterierna bör definieras korrekt.
• De modifierbara stegen eller uttalandet i stegen bör markeras i en annan färg för att snabbt hitta och ersätta.
• Språket som används för att skapa standardtestfallet ska vara generiskt.
• Alla funktioner på varje webbplats bör täckas i testfallet.
• Testfallets namn bör vara namnet på funktionaliteten eller den funktion som testfallet täcker. Detta gör det lättare att hitta testfallet från uppsättningen.
• Om det finns något grundläggande eller standardprov eller GUI-fil eller skärmdump av funktionen, ska den bifogas med relevanta steg.

Genom att använda ovanstående tips kan man skapa en uppsättning standardskript och använda dem med små eller nödvändiga ändringar för olika webbplatser.

Dessa standardtestfall kan också automatiseras, men återigen är det alltid ett plus att fokusera på återanvändbarhet. Även om automatisering bygger på ett GUI, att återanvända skript över flera webbadresser eller webbplatser är något jag personligen aldrig tyckte var effektivt.

Att använda en standarduppsättning av manuella testfall för olika webbplatser med mindre ändringar är det bästa sättet att göra en webbplatstestning. Allt vi behöver är att skapa och underhålla testfallet med rätt standard och användning.

Slutsats

Förbättring av effektiviteten i testfallet är inte ett enkelt definierat begrepp, men det är en övning och kan uppnås genom en mognad process och regelbunden övning.

Testteamet borde inte vara trött på att engagera sig i förbättringen av sådana uppgifter eftersom det är det bästa verktyget för större prestationer i kvalitetsvärlden, detta bevisas i många av testorganisationerna över hela världen på uppdragskritiska projekt och komplexa applikationer.

Hoppas att du skulle ha fått enorm kunskap om begreppet testfall. Se vår serie handledning för att lära dig mer om testfall och uttryck gärna dina tankar i kommentarfältet nedan!

Nästa handledning

Rekommenderad läsning

• Funktionell testning mot icke-funktionell testning
• Handbok för testbarhet med praktiska exempel
• Typer av programvarutestning: Olika testtyper med detaljer
• Bästa verktyg för testning av programvara 2021 (QA Test Automation Tools)
• Alpha Testing och Beta Testing (En komplett guide)
• Vad är systemtestning - En ultimat nybörjarguide
• ISTQB-testcertifieringsprovfrågeställningar med svar
• Hur man skriver Software Testing Weekly Status Report