Brug Case og Use Case Testing Komplet vejledning

use case use case testing complete tutorial

Lad os forstå det til at begynde med 'Hvad er brugssag?' og senere vil vi diskutere 'Hvad er test af brugssager?' .

En brugssag er et værktøj til at definere den krævede brugerinteraktion. Hvis du prøver at oprette en ny applikation eller foretage ændringer i en eksisterende applikation, foretages der flere diskussioner. En af de kritiske diskussioner, du skal lave, er, hvordan du repræsenterer kravet til softwareløsningen.

Forretningseksperter og udviklere skal have en gensidig forståelse af kravet, da det er meget vanskeligt at nå. Enhver standardmetode til strukturering af kommunikationen mellem dem vil virkelig være en velsignelse. Det vil igen reducere fejlkommunikationen, og her er det sted, hvor Use case kommer ind i billedet.

Denne tutorial giver dig et klart billede af begrebet Use case og test, hvorved de dækker de forskellige aspekter, der er involveret i det, med praktiske eksempler for nem forståelse af alle, der er helt nye i konceptet.

Hvad du lærer:

• Brug sag
• Hvem bruger 'Use Case'-dokumenter?
• Typer af anvendelsestilfælde
  • # 1) Brugsdage på solskinsdag
  • # 2) Brugsdage til regnvejrsdag
• Elementer i brugssager
• Repræsentation
• Hvordan man skriver en brugssag?
• Brug sagsdiagram
• Brugerhandlinger
• Hvad er brugssagstestning?
  • Nogle fakta
  • Hvordan oprettes en testskabelon?
• Konklusion
• Anbefalet læsning

Brug sag

Brugssag spiller en væsentlig rolle i de forskellige faser af softwareudviklingens livscyklus. Brugssagen afhænger af 'Brugerhandlinger' og 'Svar fra systemet' til brugerhandlingerne.

Det er dokumentationen for 'Handlinger' udført af skuespilleren / brugeren og den tilsvarende 'adfærd' af systemet til brugerens 'handlinger'. Brug sager kan eller måske ikke resultere i at nå et mål fra 'skuespilleren / brugeren' om interaktioner med systemet.

I brugssagen vil vi beskrive 'Hvordan reagerer et system på et givet scenario?' . Det er 'brugerorienteret' ikke 'systemorienteret'.

Det er 'brugerorienteret': Vi specificerer 'hvad er handlingerne, der udføres af brugeren?' Og 'Hvad skuespillerne ser i et system?'.

Det er ikke 'systemorienteret': Vi specificerer ikke 'Hvad er input til systemet?' Og 'Hvad produceres output af systemet?'.

Udviklingsteamet skal skrive 'Use Cases', da udviklingsfasen i høj grad afhænger af dem.

Brug sagsforfatter, teammedlemmer, og kunderne bidrager til oprettelsen af ​​disse sager. For at skabe disse er vi nødt til at have et udviklingshold samlet, og teamet skal være meget opmærksom på projektkoncepterne.

Efter implementering af sagen testes dokumentet, og systemets opførsel kontrolleres i overensstemmelse hermed. I et tilfælde betegner store bogstaver 'A' 'skuespiller', bogstavet 'S' betegner 'system'.

Hvem bruger 'Use Case'-dokumenter?

Denne dokumentation giver et komplet overblik over de forskellige måder, hvorpå brugeren interagerer med et system for at nå målet. Bedre dokumentation kan hjælpe med at identificere kravet til et softwaresystem på en meget lettere måde.

Denne dokumentation kan bruges af softwareudviklere, softwaretestere såvel som interessenter.

Anvendelse af dokumenterne:

• Udviklere bruger dokumenterne til at implementere koden og designe den.
• Testere bruger dem til at oprette test tilfælde .
• Forretningsinteressenter bruger dokumentet til at forstå softwarekravene.

Typer af anvendelsestilfælde

Der er to typer.

De er:

• Solskinsdag
• Regnvejrsdag

# 1) Brugsdage på solskinsdag

Det er de primære tilfælde, der mest sandsynligt vil ske, når alt går godt. Disse prioriteres højt end de andre sager. Når vi har afsluttet sagerne, giver vi det til projektteamet til gennemgang og sikrer, at vi har dækket alle de krævede sager.

program til download af videoer fra websteder

# 2) Brugsdage til regnvejrsdag

Disse kan defineres som listen over kantsager. Prioriteten af ​​sådanne sager kommer efter 'Sunny Use Cases'. Vi kan søge hjælp fra interessenter og produktledere til at prioritere sagerne.

Elementer i brugssager

Nedenfor er de forskellige elementer:

1) Kort beskrivelse : En kort beskrivelse, der forklarer sagen.

2) Skuespiller : Brugere, der er involveret i Use Cases Actions.

3) Forudsætning : Betingelser, der skal opfyldes, før sagen begynder.

4) Grundlæggende Flyde : 'Basic Flow' eller 'Main Scenario' er den normale arbejdsgang i systemet. Det er strømmen af ​​transaktioner, som skuespillerne udfører for at nå deres mål. Når skuespillerne interagerer med systemet, da det er den normale arbejdsgang, er der ingen fejl, og skuespillerne får den forventede output.

5) Alternativ flyde : Bortset fra den normale arbejdsgang kan et system også have en 'Alternativ arbejdsgang'. Dette er den mindre almindelige interaktion, som en bruger udfører med systemet.

6) Undtagelse flyde : Strømmen, der forhindrer en bruger i at nå målet.

7) Post Betingelser : De betingelser, der skal kontrolleres, når sagen er afsluttet.

Repræsentation

En sag er ofte repræsenteret i en almindelig tekst eller et diagram. På grund af enkelheden i use case-diagrammet betragtes det som valgfrit af enhver organisation

Eksempel på brugssag:

Her vil jeg forklare sagen for 'Login' til et 'School Management System'.

Punkter, der skal bemærkes

• Almindelige fejl, som deltagerne laver med Use Case, er at det enten indeholder for mange detaljer om en bestemt sag eller slet ikke nok detaljer.
• Disse er teksmodeller, hvis det kræves, kan vi muligvis tilføje et visuelt diagram til det.
• Bestem den gældende forudsætning.
• Skriv procestrinene i den rigtige rækkefølge.
• Angiv kvalitetskrav til processen.

Hvordan man skriver en brugssag?

Nedenstående punkter hjælper dig med at skrive disse:

=> Når vi prøver at skrive en sag, er det første spørgsmål, der skal rejse, 'Hvad er den primære brug for kunden?' Dette spørgsmål får dig til at skrive dine sager fra brugerens perspektiv.

=> Vi skal have fået en skabelon til disse.

=> Det skal være produktivt, enkelt og stærkt. En stærk brugssag kan imponere publikum, selvom de har mindre fejl.

=> Vi skal nummerere det.

=> Vi skal skrive procestrin i sin rækkefølge.

=> Giv scenarierne eget navn, navngivning skal ske i henhold til formålet.

=> Dette er en iterativ proces, hvilket betyder, at når du skriver dem for første gang, vil den ikke være perfekt.

=> Identificer aktørerne i systemet. Du kan finde en masse skuespillere i systemet.

Eksempel ,hvis du overvejer et e-handelssted som Amazon, der kan vi finde aktører som købere, sælgere, grossister, revisorer, leverandører, distributører, kundebehandling osv.

Lad os indledningsvis overveje de første skuespillere. Vi kan have mere end én skuespiller, der har samme adfærd.

For eksempel , både køber / sælger kan 'oprette en konto'. Ligeledes kan både 'Køber og Sælger' 'Søg efter vare'. Så dette er dobbelt adfærd, og de skal fjernes. Bortset fra at bruge de dobbelte sager, skal vi have mere generelle sager. Derfor er vi nødt til at generalisere sagerne for at undgå dobbeltarbejde.

=> Vi skal bestemme den gældende forudsætning.

Brug sagsdiagram

Use Case Diagram er en billedlig gengivelse af en brugers handlinger i et system. Det giver et godt værktøj i denne sammenhæng, hvis diagrammet indeholder mange skuespillere, er det meget let at forstå. Hvis det er et diagram på højt niveau, deler det ikke mange detaljer. Det viser komplekse ideer på en ret grundlæggende måde.

Fig nr: UC 01

Som vist i Fig nr: UC 01 det repræsenterer et diagram, hvor rektangel repræsenterer et 'system', ovalt repræsenterer et 'brugssag', pil repræsenterer et 'forhold' og manden repræsenterer en 'bruger / skuespiller'. Det viser et system / applikation, så viser det organisationen / personer, der interagerer med det, og viser den grundlæggende strøm af 'Hvad systemet gør?'

Fig nr: UC 02

Fig nr: UC 03 - Brug sagsdiagram til login

Dette er Use case-diagrammet for 'Login' -sagen. Her har vi mere end en aktør, de er alle placeret uden for systemet. Studerende, lærere og forældre betragtes som primære aktører. Derfor er de alle placeret på venstre side af rektanglet.

Admin og personale betragtes som sekundære aktører, så vi placerer dem på højre side af rektanglet. Skuespillere kan logge ind på systemet, så vi forbinder skuespillerne og login-sagen med et stik.

Andre funktioner, der findes i systemet, er Nulstil adgangskode og Glemt adgangskode. De er alle relateret til login sag, så vi forbinder dem til stikket.

Brugerhandlinger

Dette er de handlinger, der udføres af brugeren i et system.

For eksempel: Søgning på stedet, Tilføjelse af et element til favoritter, forsøg på at kontakte osv.

Bemærk:

• Et system er 'hvad du end udvikler'. Det kan være et websted, en app eller en hvilken som helst anden softwarekomponent. Det er generelt repræsenteret af et rektangel. Den indeholder brugskasser. Brugere placeres uden for 'rektanglet'.
• Brug sager er generelt repræsenteret af ovale former, der angiver handlingerne inde i den.
• Skuespillere / brugere er de mennesker, der bruger systemet. Men nogle gange kan det være andre systemer, personer eller andre organisationer.

Hvad er brugssagstestning?

Det kommer under funktionel Black Box testteknik. Da det er en sort boks-test, vil der ikke være nogen inspektion af koderne. Flere interessante fakta om dette er beskrevet i dette afsnit.

Det sikrer, om den sti, som brugeren bruger, fungerer efter hensigten eller ej. Det sørger for, at brugeren kan udføre opgaven med succes.

Nogle fakta

• Det er ikke test, der udføres for at bestemme kvaliteten af ​​softwaren.
• Selvom det er en type slut-til-slut-test, vil det ikke sikre hele dækningen af ​​brugerapplikationen.
• Baseret på det testresultat, der er kendt fra Use Case-testen, kan vi ikke beslutte implementeringen af ​​produktionsmiljøet.
• Det vil finde ud af manglerne ved integrationstest.

Eksempel på brugssagstest:

Overvej et scenarie, hvor en bruger køber en vare fra et online shoppingsted. Brugeren logger først på systemet og begynder at udføre en søgning. Brugeren vælger et eller flere emner, der vises i søgeresultaterne, og han tilføjer dem til kurven.

Efter alt dette vil han tjekke ud. Så dette er et eksempel på logisk forbundet række trin, som brugeren vil udføre i et system for at udføre opgaven.

Strømmen af ​​transaktioner i hele systemet fra ende til slut testes i denne test. Brugstilfælde er generelt den sti, som brugerne sandsynligvis bruger, for at opnå en bestemt opgave.

Så det gør Use Cases let at finde defekterne, da det inkluderer den sti, som brugerne er mere tilbøjelige til at støde på, når brugeren bruger applikationen for første gang.

Trin 1: Det første trin er gennemgangen af ​​Use Case-dokumenter.

Vi er nødt til at gennemgå og sørge for, at funktionskravene er komplette og korrekte.

Trin 2: Vi er nødt til at sikre, at brugssager er atomare.

For eksempel: Overvej et 'Skolestyringssystem med mange funktioner som' Login ',' Vis elevoplysninger ',' Vis karakterer ',' Vis deltagelse ',' Kontaktpersonale ',' Indsend gebyrer 'osv. I denne instans forsøger vi at forberede Use Cases til 'Login' funktionalitet.

Vi er nødt til at sikre os, at ingen af ​​de normale workflowbehov behøver at blande sig med nogen anden funktionalitet. Det skal kun være fuldstændigt relateret til 'Log på' funktionalitet.

Trin 3: Vi er nødt til at inspicere den normale arbejdsgang i systemet.

Efter inspektion af arbejdsgangen skal vi sikre os, at den er komplet. Baseret på kendskabet til systemet eller endda domænet kan vi finde ud af de manglende trin i workflowet.

Trin 4: Sørg for, om den alternative arbejdsgang i systemet er komplet.

Trin 5: Vi skal sørge for, at hvert trin i brugssagen kan testes.

Hvert trin, der er forklaret i Use Case-testen, kan testes.

For eksempel, nogle kreditkorttransaktioner i systemet kan ikke testes af sikkerhedsmæssige årsager.

Trin 6: Når vi har genoplivet disse sager, kan vi skrive testsagerne.

Vi skal skrive testcases for hver normal flow og alternativ flow.

For eksempel , Overvej 'Show Student Marks' -sagen i et skolestyringssystem.

Brug sagsnavn: Vis studentermærker

Aktører: Studerende, lærere, forældre

Forudsætning:

1) Systemet skal være tilsluttet netværket.

to) Skuespillere skal have et 'studenter-id'.

Brug sag til 'Vis studentermærker':

Tilsvarende testsag for 'Show Student Marks' -sagen:

Vær opmærksom på, at testcase-tabellen vist her kun indeholder de grundlæggende oplysninger. 'Sådan oprettes testskabelon' forklares detaljeret nedenfor.

Tabellen viser 'Test Case' svarende til 'Show Student Mark' -sagen som vist ovenfor.

Den bedste måde at skrive testcases på er først at skrive testcases til 'hovedscenariet' og derefter skrive dem til 'Alternate Steps'. Det ' Trin ' i testsager er hentet fra Use Case-dokumenter. Den allerførste ' Trin' i 'Show Student Mark' -sagen bliver 'Enter Student Name' den første Trin i 'Test Case'.

Brugeren / skuespilleren skal kunne indtaste den. Dette bliver forventet resultat .

Vi kan søge hjælp til testdesignteknik som ' grænseværdi-analyse ' , 'Ækvivalenspartitionering', mens vi forbereder testsagerne. Testdesignteknikken hjælper med at reducere antallet af testsager og derved reducere den tid, det tager at teste.

Hvordan oprettes en testskabelon?

Når vi forbereder testsagerne, skal vi tænke og handle som slutbrugeren, dvs. sætte dig selv i slutbrugerens sko.

Der er flere værktøjer, der er tilgængelige på markedet for at hjælpe i denne sammenhæng. '' TestLodge ’er en blandt dem, men det er ikke et gratis værktøj. Vi er nødt til at købe det.

Vi har brug for en skabelon til dokumentation af testsagen. Lad os overveje et almindeligt scenario, 'FLIPKART login', som vi alle er fortrolige med. Google-regneark kan bruges til at oprette test case-tabellen og dele den med teammedlemmerne. Indtil videre bruger jeg et Excel-dokument.

Her er et eksempel

=> DOWNLOAD denne skabelon til testtabel her

Frist af alt, navngiv testarket med et passende navn. Vi skriver testcases for et bestemt modul i et projekt. Så vi er nødt til at tilføje 'Projekt navn' og 'Projektmodul Kolonner i test case-tabellen. Dokumentet skal indeholde navnet på skaberen af ​​testsagerne.

Tilføj derfor 'Lavet af' og 'Oprettet dato' kolonner. Dokumentet skal gennemgås af nogen (teamleder, projektleder osv.), Så tilføj 'Anmeldt af' kolonne og 'Bedømt dato' .

Næste kolonne er 'Testscenarie' , her har vi leveret eksemplets testscenarie 'Bekræft Facebook-login' . Tilføj kolonnerne 'Test Scenario-id' og 'Test Case Description' .

For hvert testscenario skriver vi ‘Test tilfælde '. Så tilføj kolonnerne 'Test Case ID' og ‘Beskrivelse af testsag '. For hver testscenarie vil der være 'Posttilstand' og 'Forudsætning' . Tilføj kolonnerne 'Post-Condition' og 'Pre-Condition'.

En anden vigtig kolonne er 'Testdata' . Den indeholder de data, som vi bruger til testning. Et testscenarie skal antage et forventet resultat og det faktiske resultat. Tilføj kolonnen 'Forventet resultat' og 'Faktisk resultat'. 'Status' viser resultatet af eksekveringen af ​​testscenariet. Det kan enten være bestået / ikke bestået.

Testere udfører testsagerne. Vi er nødt til at medtage det som 'Henrettet af' og 'Udført dato' . Vi tilføjer 'kommandoer', hvis der er nogen.

Konklusion

Jeg håber, du ville have fået en klar idé om brugssager og test af brugssager.

At skrive disse sager er en iterativ proces. Du har bare brug for lidt øvelse og et godt kendskab til et system til at skrive disse sager.

I en nøddeskal kan vi bruge 'Use Case testing' i en applikation til at finde de manglende links, ufuldstændige krav osv. At finde dem og ændre systemet vil opnå effektivitet og nøjagtighed i systemet.

Har du tidligere erfaringer med brugssager og test? Del gerne med os i kommentarfeltet nedenfor.

Anbefalet læsning

• Funktionel testning mod ikke-funktionel testning
• Dybdegående formørkelsesvejledninger til begyndere
• Alpha-test og betatestning (En komplet guide)
• DevOps Testing Tutorial: Hvordan DevOps vil påvirke QA-test?
• Bedste softwaretestværktøjer 2021 (QA Test Automation Tools)
• Usability Testing Tutorial: En komplet startvejledning
• GUI Testing Tutorial: A Complete User Interface (UI) Testing Guide
• Destruktiv test og ikke-destruktiv testvejledning