Use Case and Use Case Testing Complete Tutorial

use case use case testing complete tutorial

Til å begynne med, la oss forstå det ‘Hva er brukstilfelle?’ og senere vil vi diskutere ‘Hva er bruksteststesting?’ .

En brukstilfelle er et verktøy for å definere den nødvendige brukerinteraksjonen. Hvis du prøver å lage en ny applikasjon eller gjøre endringer i en eksisterende applikasjon, blir det gjort flere diskusjoner. En av de kritiske diskusjonene du må ta er hvordan du vil representere kravet til programvareløsningen.

Bedriftseksperter og utviklere må ha en gjensidig forståelse av kravet, da det er veldig vanskelig å oppnå. Enhver standardmetode for å strukturere kommunikasjonen mellom dem vil virkelig være en velsignelse. Det vil igjen redusere feilkommunikasjonen, og her er stedet hvor Use case kommer inn i bildet.

Denne opplæringen vil gi deg et klart bilde av begrepet Use case og testing, og dekker de forskjellige aspektene som er involvert i det med praktiske eksempler for enkel forståelse av alle som er helt nye i konseptet.

Hva du vil lære:

• Bruk sak
• Hvem bruker ‘Use Case’-dokumenter?
• Typer av brukstilfeller
  • # 1) Solskinnsbruk
  • # 2) Regnfull dag
• Elementer i brukstilfeller
• Representasjon
• Hvordan skriver jeg et brukstilfelle?
• Bruk sakdiagram
• Brukerhandlinger
• Hva er bruksteststesting?
  • Noen fakta
  • Hvordan lage en testsaksmal?
• Konklusjon
• Anbefalt lesing

Bruk sak

Use case spiller en viktig rolle i de forskjellige fasene av programvarens utviklingslivssyklus. Brukssaken avhenger av 'Brukerhandlinger' og 'Svar fra systemet' til brukerhandlingene.

Det er dokumentasjonen av 'Handlinger' utført av skuespilleren / brukeren og den korresponderende 'oppførselen' til systemet til brukerens 'handlinger'. Bruk tilfeller kan eller ikke kan resultere i å oppnå et mål fra 'Actor / User' om interaksjoner med systemet.

I brukstilfelle vil vi beskrive ‘Hvordan et system vil svare på et gitt scenario?’ . Det er 'brukerorientert' ikke 'systemorientert'.

Det er 'brukerorientert': Vi vil spesifisere ‘hva er handlingene som brukeren gjør?’ Og ‘Hva skuespillerne ser i et system?’.

Det er ikke 'systemorientert': Vi vil ikke spesifisere ‘Hva er inngangen gitt til systemet?’ Og ‘Hva er produksjonen produsert av systemet?’.

Utviklingsteamet må skrive ‘Use Cases’, ettersom utviklingsfasen er veldig avhengig av dem.

Bruk saksforfatter, teammedlemmer og kundene vil bidra til opprettelsen av disse sakene. For å lage disse må vi ha et utviklingsteam samlet, og teamet skal være veldig bevisst prosjektkonseptene.

Etter å ha implementert saken blir dokumentet testet, og systemets oppførsel blir sjekket deretter. I et tilfelle betegner store bokstaver 'A' 'Actor', bokstaven 'S' betegner 'System'.

Hvem bruker ‘Use Case’-dokumenter?

Denne dokumentasjonen gir en fullstendig oversikt over de forskjellige måtene brukeren samhandler med et system for å nå målet. Bedre dokumentasjon kan bidra til å identifisere kravet til et programvaresystem på en mye enklere måte.

Denne dokumentasjonen kan brukes av programvareutviklere, programvaretestere og interessenter.

Bruk av dokumentene:

• Utviklere bruker dokumentene for å implementere koden og designe den.
• Testere bruker dem til å lage test tilfeller .
• Virksomhetsinteressenter bruker dokumentet for å forstå programvarekravene.

Typer av brukstilfeller

Det er to typer.

De er:

• Solfylt dag
• Regnfull dag

# 1) Solskinnsbruk

Det er de viktigste tilfellene som mest sannsynlig vil skje når alt gjør det bra. Disse prioriteres høyt enn de andre sakene. Når vi har fullført sakene, gir vi den til prosjektgruppen for gjennomgang og sørger for at vi har dekket alle nødvendige saker.

hvordan du kopierer en array-java

# 2) Regnfull dag

Disse kan defineres som listen over kantsaker. Prioriteten til slike saker vil komme etter ‘Sunny Use Cases’. Vi kan søke hjelp fra interessenter og produktledere for å prioritere sakene.

Elementer i brukstilfeller

Nedenfor er de forskjellige elementene:

1) Kort beskrivelse : En kort beskrivelse som forklarer saken.

2) Skuespiller : Brukere som er involvert i brukstilfelleshandlinger.

3) Forutsetning : Vilkår som skal tilfredsstilles før saken starter.

4) Grunnleggende Strømme : 'Basic Flow' eller 'Main Scenario' er den normale arbeidsflyten i systemet. Det er strømmen av transaksjoner som skuespillerne gjør for å nå målene sine. Når skuespillerne samhandler med systemet, da det er den vanlige arbeidsflyten, vil det ikke være noen feil, og skuespillerne får den forventede produksjonen.

5) Alternativ strømme : Bortsett fra den vanlige arbeidsflyten, kan et system også ha en ‘Alternativ arbeidsflyt’. Dette er den mindre vanlige interaksjonen som en bruker gjør med systemet.

6) Unntak strømme : Flyten som hindrer en bruker i å oppnå målet.

7) Innlegg Forhold : Vilkårene som må kontrolleres etter at saken er avsluttet.

Representasjon

En sak er ofte representert i ren tekst eller et diagram. På grunn av enkelheten i bruksdiagrammet, anses det for å være valgfritt av enhver organisasjon

Eksempel på brukstilfelle:

Her vil jeg forklare saken for ‘Login’ til et ‘School Management System’.

Poeng å merke seg

• Vanlige feil som deltakerne gjør med Use Case, er at den enten inneholder for mange detaljer om en bestemt sak eller ikke nok detaljer i det hele tatt.
• Dette er tekstmodeller om nødvendig, kan vi legge til et visuelt diagram eller ikke.
• Bestem gjeldende forutsetning.
• Skriv prosessstrinnene i riktig rekkefølge.
• Spesifiser kvalitetskrav for prosessen.

Hvordan skriver jeg et brukstilfelle?

Poengene som er oppsummert nedenfor, vil hjelpe deg med å skrive disse:

=> Når vi prøver å skrive en sak, er det første spørsmålet som burde reise, ‘Hva er den primære bruken for kunden?’ Dette spørsmålet får deg til å skrive sakene dine fra brukerens perspektiv.

=> Vi må ha skaffet oss en mal for disse.

=> Det må være produktivt, enkelt og sterkt. Et sterkt brukstilfelle kan imponere publikum selv om de har mindre feil.

=> Vi bør nummerere det.

=> Vi bør skrive prosesstrinnet i sin rekkefølge.

=> Gi eget navn til scenariene, navngivning må gjøres i henhold til formålet.

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

=> Identifiser aktørene i systemet. Du kan finne en rekke skuespillere i systemet.

Eksempel ,hvis du vurderer et e-handelssted som Amazon, der kan vi finne aktører som kjøpere, selgere, grossister, revisorer, leverandører, distributører, kundebehandling etc.

Først skal vi vurdere de første skuespillerne. Vi kan ha mer enn én skuespiller som har samme oppførsel.

For eksempel , både kjøper / selger kan ‘opprette en konto’. Likeledes kan både 'Kjøper og Selger' 'søke etter varen'. Så dette er duplisert atferd og de må elimineres. Bortsett fra å bruke dupliserte saker, må vi ha mer generelle saker. Derfor må vi generalisere sakene for å unngå duplisering.

=> Vi må bestemme den gjeldende forutsetningen.

Bruk sakdiagram

Use Case Diagram er en illustrasjon av brukerens handlinger i et system. Det gir et flott verktøy i denne sammenhengen, hvis diagrammet inneholder mange skuespillere, er det veldig lett å forstå. Hvis det er et høyt nivådiagram, vil det ikke dele mange detaljer. Det viser komplekse ideer på en ganske grunnleggende måte.

Fig nr: UC 01

Som vist i Fig nr: UC 01 det representerer et diagram der rektangel representerer et 'system', ovalt representerer et 'brukstilfelle', pil representerer et 'forhold' og mannen representerer en 'bruker / skuespiller'. Det viser et system / et program, så viser det organisasjonen / menneskene som samhandler med det og viser den grunnleggende flyt av ‘Hva systemet gjør?’

Fig nr: UC 02

Fig nr: UC 03 - Bruk saksdiagram for pålogging

Dette er Use case-diagrammet for ‘Login’ saken. Her har vi mer enn én aktør, de er alle plassert utenfor systemet. Studenter, lærere og foreldre regnes som primære aktører. Det er derfor de alle er plassert på venstre side av rektangelet.

Administrator og ansatte betraktes som sekundære skuespillere, så vi plasserer dem på høyre side av rektangelet. Skuespillere kan logge på systemet, så vi kobler skuespillerne og påloggingssaken med en kontakt.

Andre funksjoner som finnes i systemet er Tilbakestill passord og Glemt passord. De er alle relatert til påloggingssaken, så vi kobler dem til kontakten.

Brukerhandlinger

Dette er handlingene som gjøres av brukeren i et system.

For eksempel: Søker på stedet, legger til et element i favoritter, prøver å kontakte osv.

Merk:

• Et system er ‘hva du utvikler’. Det kan være et nettsted, en app eller en hvilken som helst annen programvarekomponent. Det er vanligvis representert med et rektangel. Den inneholder brukstilfeller. Brukerne plasseres utenfor ‘rektangelet’.
• Bruk tilfeller er vanligvis representert av ovale former som spesifiserer handlingene i den.
• Skuespillere / brukere er menneskene som bruker systemet. Men noen ganger kan det være andre systemer, personer eller andre organisasjoner.

Hva er bruksteststesting?

Den kommer under funksjonell Black Box testteknikk. Ettersom det er en svart esketesting, vil det ikke være noen inspeksjon av kodene. Flere interessante fakta om dette er orientert i denne delen.

Det sikrer om banen som brukes av brukeren fungerer etter hensikten eller ikke. Det sørger for at brukeren kan utføre oppgaven vellykket.

Noen fakta

• Det er ikke testing som utføres for å bestemme kvaliteten på programvaren.
• Selv om det er en type slutt-til-slutt-testing, vil det ikke sikre hele dekning av brukerapplikasjonen.
• Basert på testresultatet kjent fra Use Case-testingen, kan vi ikke bestemme distribusjonen av produksjonsmiljøet.
• Det vil finne ut feilene i integrasjonstesting.

Eksempel på bruksteststest:

Tenk på et scenario der en bruker kjøper en vare fra et nettsted for online shopping. Brukeren vil først logge på systemet og begynne å utføre et søk. Brukeren vil velge ett eller flere elementer som vises i søkeresultatene, og han vil legge dem til i handlekurven.

Etter alt dette vil han sjekke ut. Så dette er et eksempel på en logisk koblet serie trinn som brukeren vil utføre i et system for å utføre oppgaven.

Flyten av transaksjoner i hele systemet fra ende til slutt blir testet i denne testingen. Brukstilfeller er vanligvis banen som brukerne mest sannsynlig vil bruke for å oppnå en spesifikk oppgave.

Dette gjør brukstilfeller lett å finne feilene, da det inkluderer banen som brukerne har større sannsynlighet for å komme over når brukeren bruker applikasjonen for første gang.

Trinn 1: Det første trinnet er gjennomgangen av Use Case-dokumenter.

Vi må gjennomgå og sørge for at funksjonskravene er fullstendige og korrekte.

Steg 2: Vi må sørge for at brukstilfeller er atomare.

For eksempel: Tenk på et 'Skolesystem som har mange funksjoner som' Innlogging ',' Vis studentdetaljer ',' Vis merker ',' Vis fremmøte ',' Kontaktpersonale ',' Send inn avgifter 'osv. For dette tilfellet prøver vi å klargjøre brukstilfellene for funksjonen for pålogging.

Vi må sørge for at ingen av de vanlige arbeidsflytbehovene trenger å blande seg med noen annen funksjonalitet. Det må bare være helt relatert til funksjonen ‘Logg på’.

Trinn 3: Vi må inspisere den normale arbeidsflyten i systemet.

Etter å ha inspisert arbeidsflyten, må vi sørge for at den er fullført. Basert på kunnskapen om systemet eller til og med domenet, kan vi finne ut de manglende trinnene i arbeidsflyten.

Trinn 4: Forsikre deg om at den alternative arbeidsflyten i systemet er fullført.

Trinn 5: Vi bør sørge for at hvert trinn i brukstilfellet kan testes.

Hvert trinn som er forklart i Use Case-testingen, kan testes.

For eksempel, noen kredittkorttransaksjoner i systemet kan ikke testes av sikkerhetsmessige årsaker.

Trinn 6: Når vi har gjenopplivet disse sakene, kan vi skrive prøvesakene.

Vi må skrive testtilfeller for hver normal flyt og alternativ flyt.

For eksempel , Vurder saken 'Show Student Marks', i et skoleledelsessystem.

Bruk saksnavn: Vis studentmerker

Skuespillere: Studenter, lærere, foreldre

Forutsetning:

1) Systemet må være koblet til nettverket.

2) Skuespillere må ha 'Student ID'.

Bruk sak for 'Vis studentmerker':

Tilsvarende prøvesak for saken 'Show Student Marks':

Vær oppmerksom på at Test Case-tabellen vist her bare inneholder grunnleggende informasjon. ‘Hvordan lage Test Case-mal’ forklares i detalj nedenfor.

Tabellen viser 'Test Case' som tilsvarer 'Show Student Mark' -saken som vist ovenfor.

Den beste måten å skrive testsaker på er å skrive testsaker for ‘Hovedscenariet’ først, og deretter skrive dem for ‘Alternate Steps’. Den ‘ Steps ’ i testsaker er hentet fra Use Case-dokumenter. Den aller første ‘ Steg' i saken 'Show Student Mark', blir 'Enter Student Name' den første Steg i ‘Test Case’.

Brukeren / skuespilleren må kunne legge inn den. Dette blir den forventet resultat .

Vi kan søke hjelp av testdesignteknikk som ‘ grenseverdianalyse ’ , ‘Ekvivalenspartisjonering’ mens vi forbereder testsakene. Testdesignteknikken vil bidra til å redusere antall testtilfeller og dermed redusere tiden det tar å teste.

Hvordan lage en testsaksmal?

Når vi forbereder testsakene, må vi tenke og oppføre oss som sluttbruker, dvs. sette deg i skoene til en sluttbruker.

Det er flere verktøy som er tilgjengelige i markedet for å hjelpe i denne sammenhengen. ' TestLodge ’er en av dem, men det er ikke et gratis verktøy. Vi må kjøpe den.

Vi trenger en mal for å dokumentere testsaken. La oss vurdere et vanlig scenario, 'FLIPKART login' som vi alle er kjent med. Googles regneark kan brukes til å lage test case-tabellen og dele den med teammedlemmene. Foreløpig bruker jeg et Excel-dokument.

Her er et eksempel

=> LAST NED denne testtabellmalen her

Frist av alle, navngi testarket med et passende navn. Vi skriver prøvesaker for en bestemt modul i et prosjekt. Så vi må legge til 'Prosjektnavn' og ‘Prosjektmodul ’Kolonner i test case-tabellen. Dokumentet må inneholde navnet til skaperen av testsakene.

Legg derfor til 'Laget av' og 'Opprettet dato' kolonner. Dokumentet må gjennomgås av noen (teamleder, prosjektleder osv.), Så legg til 'Anmeldt av' kolonne og ‘Anmeldt dato’ .

Neste kolonne er 'Test Scenario' , her har vi gitt eksemplets testscenario ‘Verify Facebook Login’ . Legg til kolonnene ‘Test Scenario ID’ og 'Test Case Description' .

For hvert testscenario vil vi skrive ‘Test tilfeller '. Så legg til kolonnene ‘Test Case ID’ og ‘Test Case Description '. For hvert testscenario vil det være ‘Posttilstand’ og 'Forutsetning' . Legg til kolonnene ‘Post-Condition’ og ‘Pre-Condition’.

En annen viktig kolonne er 'Testdata' . Den inneholder dataene vi bruker til testing. Et testscenario må anta et forventet resultat og det faktiske resultatet. Legg til kolonnen 'Forventet resultat' og ‘Faktisk resultat’. 'Status' viser resultatet av testscenarioutførelsen. Det kan enten være bestått / ikke bestått.

Testere vil utføre testsakene. Vi må inkludere det som ‘Henrettet av’ og ‘Utført dato’ . Vi vil legge til kommandoer hvis det er noen.

Konklusjon

Jeg håper du ville ha fått en klar ide om brukstilfeller og brukstesten.

Å skrive disse sakene er en iterativ prosess. Du trenger bare lite trening og god kunnskap om et system for å skrive disse sakene.

I et nøtteskall kan vi bruke ‘Use Case testing’ i en applikasjon for å finne manglende lenker, ufullstendige krav osv. Å finne dem og endre systemet vil oppnå effektivitet og nøyaktighet i systemet.

Har du tidligere erfaringer med brukstilfeller og testing? Del gjerne med oss ​​i kommentarfeltet nedenfor.

Anbefalt lesing

• Funksjonstesting mot ikke-funksjonell testing
• In-Depth Eclipse Tutorials For Beginners
• Alpha Testing og Beta Testing (En komplett guide)
• DevOps Testing Tutorial: Hvordan DevOps vil påvirke QA-testing?
• Beste verktøy for testing av programvare 2021 (QA Test Automation Tools)
• Veiledning for brukervennlighetstesting: En komplett guide
• GUI Testing Tutorial: A Complete User Interface (UI) Testing Guide
• Destruktiv testing og ikke-destruktiv testing