Use Case and Use Case Testing Complete Tutorial

use case use case testing complete tutorial

Till att börja med, låt oss förstå 'Vad är användningsfall?' och senare kommer vi att diskutera ”Vad är test av användningsfall?” .

Ett användningsfall är ett verktyg för att definiera den nödvändiga användarinteraktionen. Om du försöker skapa en ny applikation eller göra ändringar i en befintlig applikation görs flera diskussioner. En av de kritiska diskussionerna du måste göra är hur du kommer att representera kravet på programvarulösningen.

Affärsexperter och utvecklare måste ha en ömsesidig förståelse för kravet, eftersom det är mycket svårt att uppnå. Varje standardmetod för att strukturera kommunikationen mellan dem kommer verkligen att vara en välsignelse. Det kommer i sin tur att minska misskommunikationen och här är platsen där Use case kommer in i bilden.

Denna handledning ger dig en tydlig bild om begreppet Use case och testning, och täcker därmed de olika aspekterna av det med praktiska exempel för enkel förståelse för alla som är helt nya i konceptet.

Vad du kommer att lära dig:

• Användningsfall
• Vem använder dokumenten ”Use Case”?
• Typer av användningsfall
  • # 1) Användningsfall för solig dag
  • # 2) Användningsfall för regnig dag
• Element i användningsfall
• Representation
• Hur skriver jag ett användningsfall?
• Använd falldiagram
• Användaråtgärder
• Vad är användningsfallstestning?
  • Några fakta
  • Hur skapar jag en testfallsmall?
• Slutsats
• Rekommenderad läsning

Användningsfall

Användningsfall spelar en viktig roll i de olika faserna i programvaruutvecklingens livscykel. Användningsfall beror på 'Användaråtgärder' och 'Systemets svar' på användaråtgärderna.

Det är dokumentationen av ”Åtgärder” som utförs av Skådespelaren / Användaren och motsvarande ”Uppförande” av Systemet till Användarens ”Åtgärder”. Använd fall kan eller inte kan leda till att uppnå ett mål av ”Skådespelaren / Användaren” om interaktioner med systemet.

I användningsfallet kommer vi att beskriva ”Hur kommer ett system att reagera på ett visst scenario?” . Det är ”användarorienterat” inte ”systemorienterat”.

Det är ”användarorienterat”: Vi kommer att specificera ”vilka åtgärder görs av användaren?” Och ”Vad skådespelarna ser i ett system?”.

Det är inte ”systemorienterat”: Vi kommer inte att specificera ”Vilken ingång ges till systemet?” Och ”Vilken produktion ger systemet?”.

Utvecklingsteamet måste skriva ”Use Cases”, eftersom utvecklingsfasen är mycket beroende av dem.

Använd ärendeskrivare, teammedlemmar och kunderna kommer att bidra till skapandet av dessa ärenden. För att skapa dessa måste vi ha ett utvecklingsgrupp monterat och teamet bör vara mycket medvetet om projektkoncepten.

Efter genomförandet av ärendet testas dokumentet och systemets beteende kontrolleras därefter. I ett fall betecknar stora bokstäver 'A' 'Skådespelare', bokstaven 'S' betecknar 'System'.

Vem använder dokumenten ”Use Case”?

Denna dokumentation ger en fullständig översikt över de distinkta sätt som användaren interagerar med ett system för att uppnå målet. Bättre dokumentation kan hjälpa till att identifiera kravet på ett mjukvarusystem på ett mycket enklare sätt.

Denna dokumentation kan användas av mjukvaruutvecklare, mjukvarutestare och intressenter.

Användning av dokumenten:

• Utvecklare använder dokumenten för att implementera koden och utforma den.
• Testare använder dem för att skapa testfall .
• Affärsintressenter använder dokumentet för att förstå programvarukraven.

Typer av användningsfall

Det finns två typer.

Dom är:

• Solig dag
• Regnig dag

# 1) Användningsfall för solig dag

De är de primära fallen som sannolikt kommer att hända när allt går bra. Dessa prioriteras högt än de andra fallen. När vi har avslutat ärendena ger vi det till projektgruppen för granskning och ser till att vi har täckt alla erforderliga ärenden.

test fallhanteringsverktyg öppen källkod

# 2) Användningsfall för regnig dag

Dessa kan definieras som en lista över kantfall. Prioriteten för sådana fall kommer efter ”Sunny Use Cases”. Vi kan söka hjälp från intressenter och produktchefer för att prioritera ärenden.

Element i användningsfall

Nedan följer de olika elementen:

1) Kortfattad beskrivning : En kort beskrivning som förklarar fallet.

2) Skådespelare : Användare som är involverade i användningsfallsåtgärder.

3) Förutsättning : Villkor som ska uppfyllas innan ärendet börjar.

4) Grundläggande Flöde : 'Basic Flow' eller 'Main Scenario' är det normala arbetsflödet i systemet. Det är flödet av transaktioner som skådespelarna gör för att uppnå sina mål. När aktörerna interagerar med systemet, eftersom det är det vanliga arbetsflödet, kommer det inte att bli något fel och skådespelarna får den förväntade produktionen.

5) Alternativ flöde : Förutom det normala arbetsflödet kan ett system också ha ett 'Alternativt arbetsflöde'. Detta är den mindre vanliga interaktionen som görs av en användare med systemet.

6) Undantag flöde : Flödet som hindrar en användare från att uppnå målet.

7) Inlägg Betingelser : Villkoren som måste kontrolleras efter att ärendet är avslutat.

Representation

Ett ärende representeras ofta i klartext eller ett diagram. På grund av enkelheten i use case-diagrammet anses det vara frivilligt av alla organisationer

Exempel på användningsfall:

Här kommer jag att förklara fallet för 'Login' till ett 'School Management System'.

Poäng att notera

• Vanliga misstag som deltagarna gör med Use Case är att det antingen innehåller för många detaljer om ett visst fall eller inte tillräckligt med detaljer alls.
• Det här är textmodeller om det behövs kan vi lägga till ett visuellt diagram eller inte.
• Bestäm tillämplig förutsättning.
• Skriv processstegen i rätt ordning.
• Ange kvalitetskrav för processen.

Hur skriver jag ett användningsfall?

Poängen som sammanfattas nedan hjälper dig att skriva dessa:

=> När vi försöker skriva ett ärende är den första frågan som borde väcka ”Vad är kundens primära användning?” Den här frågan får dig att skriva dina ärenden ur användarens perspektiv.

=> Vi måste ha fått en mall för dessa.

=> Det måste vara produktivt, enkelt och starkt. Ett starkt användningsfall kan imponera publiken även om de har mindre misstag.

=> Vi borde numrera det.

=> Vi borde skriva processsteget i sin ordning.

=> Ange scenariorna, namngivningen måste göras enligt syftet.

=> Detta är en iterativ process, vilket innebär att när du skriver dem för första gången kommer det inte att vara perfekt.

=> Identifiera aktörerna i systemet. Du kan hitta en massa skådespelare i systemet.

Exempel ,om du funderar på en e-handelswebbplats som Amazon, där kan vi hitta aktörer som köpare, säljare, grossister, revisorer, leverantörer, distributörer, kundvård etc.

Låt oss inledningsvis överväga de första skådespelarna. Vi kan ha mer än en skådespelare som har samma beteende.

Till exempel , både köpare och säljare kan ”skapa ett konto”. På samma sätt kan både 'Köpare och Säljare' 'Sök efter artikel'. Så detta är dubbla beteenden och de måste elimineras. Förutom att använda dubbletterna måste vi ha mer allmänna fall. Därför måste vi generalisera fallen för att undvika dubbelarbete.

=> Vi måste fastställa tillämplig förutsättning.

Använd falldiagram

Use Case Diagram är en bildrepresentation av en användares handlingar i ett system. Det ger ett utmärkt verktyg i detta sammanhang, om diagrammet innehåller många skådespelare är det väldigt lätt att förstå. Om det är ett diagram på hög nivå kommer det inte att dela mycket detaljer. Det visar komplexa idéer på ett ganska grundläggande sätt.

Fig nr: UC 01

Som visas i Fig nr: UC 01 det representerar ett diagram där rektangel representerar ett 'system', oval representerar ett 'användningsfall', pil representerar ett 'förhållande' och mannen representerar en 'användare / skådespelare'. Det visar ett system / applikation, sedan visar det organisationen / personerna som interagerar med det och visar det grundläggande flödet av ”Vad systemet gör?”

Fig nr: UC 02

Bild nr: UC 03 - Använd falldiagram för inloggning

Detta är Use case-diagrammet för 'Login' -fallet. Här har vi mer än en aktör, de är alla placerade utanför systemet. Studenter, lärare och föräldrar betraktas som primära aktörer. Det är därför de alla är placerade på vänster sida av rektangeln.

Admin och personal betraktas som sekundära aktörer, så vi placerar dem på höger sida av rektangeln. Skådespelare kan logga in på systemet, så vi ansluter skådespelarna och inloggningsfallet med en kontakt.

Andra funktioner som finns i systemet är Återställ lösenord och Glömt lösenord. De är alla relaterade till inloggningsfallet, så vi ansluter dem till kontakten.

Användaråtgärder

Det här är de åtgärder som görs av användaren i ett system.

Till exempel: Söker på plats, lägger till ett objekt till favoriter, försöker kontakta etc.

Notera:

• Ett system är ”vad du än utvecklar”. Det kan vara en webbplats, en app eller någon annan programvarukomponent. Det representeras vanligtvis av en rektangel. Den innehåller användningsfall. Användare placeras utanför ”rektangeln”.
• Använd fall representeras vanligtvis av ovala former som anger åtgärderna i den.
• Skådespelare / användare är de människor som använder systemet. Men ibland kan det vara andra system, person eller någon annan organisation.

Vad är användningsfallstestning?

Den omfattas av testtekniken för funktionell Black Box. Eftersom det är en svart låda testas ingen kod av koderna. Flera intressanta fakta om detta beskrivs i detta avsnitt.

Det säkerställer om sökvägen som används av användaren fungerar som avsett eller inte. Det ser till att användaren kan utföra uppgiften framgångsrikt.

Några fakta

• Det är inte test som utförs för att bestämma kvaliteten på programvaran.
• Även om det är en typ av slut-till-slut-testning garanterar det inte hela användarapplikationens täckning.
• Baserat på testresultatet som är känt från Use Case-testningen kan vi inte bestämma distributionen av produktionsmiljön.
• Det kommer att ta reda på bristerna i integrationstestningen.

Exempel på användningsfallstest:

Tänk på ett scenario där en användare köper ett objekt från en online shoppingwebbplats. Användaren loggar först in i systemet och börjar utföra en sökning. Användaren väljer ett eller flera objekt som visas i sökresultaten och lägger till dem i kundvagnen.

Efter allt detta kommer han att kolla in. Så detta är ett exempel på logiskt anslutna serie steg som användaren kommer att utföra i ett system för att utföra uppgiften.

Flödet av transaktioner i hela systemet från slut till slut testas i denna testning. Användningsfall är i allmänhet den väg som användarna mest sannolikt använder för att uppnå en specifik uppgift.

Så det gör Use Cases enkelt att hitta defekterna eftersom det inkluderar den väg som användarna är mer benägna att stöta på när användaren använder applikationen för första gången.

Steg 1: Det första steget är granskningen av Use Case-dokument.

Vi måste granska och se till att funktionskraven är fullständiga och korrekta.

Steg 2: Vi måste se till att användningsfall är atomära.

Till exempel: Tänk på ett 'Skolhanteringssystem med många funktioner som' Inloggning ',' Visa studentinformation ',' Visa märken ',' Visa närvaro ',' Kontaktpersonal ',' Skicka in avgifter 'etc. För det här fallet försöker vi förbered användningsfall för inloggningsfunktionalitet.

Vi måste se till att inget av det normala arbetsflödesbehovet behöver blandas med någon annan funktion. Det måste vara helt relaterat till 'Logga in' -funktionaliteten.

Steg 3: Vi måste inspektera det normala arbetsflödet i systemet.

Efter att ha inspekterat arbetsflödet måste vi se till att det är komplett. Baserat på kunskapen om systemet eller till och med domänen kan vi ta reda på de saknade stegen i arbetsflödet.

Steg 4: Se till om det alternativa arbetsflödet i systemet är komplett.

Steg 5: Vi bör se till att varje steg i användningsfallet kan testas.

Varje steg som förklaras i Use Case-testningen är testbart.

Till exempel, vissa kreditkortstransaktioner i systemet kan inte testas av säkerhetsskäl.

Steg 6: När vi väl har återupplivat dessa fall kan vi skriva testfallet.

Vi måste skriva testfall för varje normalt flöde och alternativt flöde.

Till exempel , Tänk på 'Visa studentmärken' i ett skolhanteringssystem.

Använd fallets namn: Visa studentmärken

Skådespelare: Studenter, lärare, föräldrar

Förutsättning:

1) Systemet måste vara anslutet till nätverket.

2) Skådespelare måste ha ett 'student-ID'.

Användningsfall för 'Visa studentmärken':

Motsvarande testfall för 'Visa studentmärken' fall:

Observera att tabellen med testfall som visas här endast innehåller grundinformation. ”Hur man skapar testfallsmall” förklaras i detalj nedan.

Tabellen visar 'Testfall' som motsvarar fallet 'Visa studentmärke' som visas ovan.

Det bästa sättet att skriva testfall är att först skriva testfall för 'huvudscenariot' och sedan skriva dem för 'alternativa steg'. ” Steg' i testfall erhålls från Use Case-dokument. Den allra första ' Steg' i fallet 'Visa studentmärke' blir 'Ange studentnamn' det första Steg i ”Testfallet”.

Användaren / skådespelaren måste kunna skriva in den. Detta blir Förväntat resultat .

Vi kan söka hjälp av testdesignteknik som ” gränsvärdesanalys ” , ”Ekvivalenspartitionering” medan vi förbereder testfallet. Testdesigntekniken hjälper till att minska antalet testfall och därmed minska tiden det tar att testa.

Hur skapar jag en testfallsmall?

När vi förbereder testfallet måste vi tänka och agera som slutanvändaren, dvs sätt dig i en slutanvändares skor.

Det finns flera verktyg som finns tillgängliga på marknaden för att hjälpa till i detta sammanhang. '' TestLodge är en av dem, men det är inte ett gratis verktyg. Vi måste köpa den.

Vi behöver en mall för att dokumentera testfallet. Låt oss överväga ett vanligt scenario, 'FLIPKART-inloggning' som vi alla känner till. Googles kalkylark kan användas för att skapa testfallstabellen och dela den med teammedlemmarna. För tillfället använder jag ett Excel-dokument.

Här är ett exempel

=> LADDA NER denna testfallsmall här

Frist of all, namnge testfallet med ett lämpligt namn. Vi skriver testfall för en viss modul i ett projekt. Så vi måste lägga till 'Projektnamn' och den ”Projektmodul Kolumner i testfallstabellen. Dokumentet måste innehålla namnet på skaparen av testfallet.

Lägg därför till 'Skapad av' och 'Skapat Datum' kolumner. Dokumentet måste granskas av någon (teamledare, projektledare etc), så lägg till 'Granskats av' kolumn och 'Recenserat datum' .

Nästa kolumn är 'Testscenario' , här har vi tillhandahållit exempel på testscenariot 'Verifiera Facebook-inloggning' . Lägg till kolumnerna ”Test Scenario ID” och 'Beskrivning av testfall' .

För varje testscenario kommer vi att skriva 'Testfall ”. Så lägg till kolumnerna 'Testfall-ID' och ”Beskrivning av testfall ”. För varje testscenario kommer det att finnas 'Postvillkor' och 'Förvillkor' . Lägg till kolumnerna 'Post-Condition' och 'Pre-Condition'.

En annan viktig kolumn är 'Testdata' . Den innehåller de data som vi använder för testning. Ett testscenario måste anta ett förväntat resultat och det faktiska resultatet. Lägg till kolumnen 'Förväntat resultat' och ”Verkligt resultat”. 'Status' visar resultatet av testscenariot. Det kan vara antingen pass / misslyckas.

Testare kommer att utföra testfallet. Vi måste inkludera det som 'Avrättad av' och ”Exekverat datum” . Vi lägger till ”Kommandon” om det finns någon.

Slutsats

Jag hoppas att du skulle ha fått en klar uppfattning om användningsfall och test av användningsfall.

Att skriva dessa fall är en iterativ process. Du behöver bara lite övning och god kunskap om ett system för att skriva dessa fall.

I ett nötskal kan vi använda ”Use Case testing” i en applikation för att hitta de saknade länkarna, ofullständiga krav etc. Att hitta dem och ändra systemet kommer att uppnå effektivitet och noggrannhet för systemet.

Har du tidigare erfarenheter av användningsfall och testning? Dela gärna med oss ​​i kommentarfältet nedan.

Rekommenderad läsning

• Funktionell testning mot icke-funktionell testning
• Fördjupade förklaringar om förmörkelser för nybörjare
• Alpha Testing och Beta Testing (En komplett guide)
• DevOps Testing Tutorial: Hur DevOps kommer att påverka QA-testning?
• Bästa verktyg för testning av programvara 2021 (QA Test Automation Tools)
• Handledning för testning av användbarhet: En komplett guide för att komma igång
• GUI Testing Tutorial: A Complete User Interface (UI) Testing Guide
• Handledning med destruktiv testning och icke-destruktiv testning