Use case en use case testen Volledige zelfstudie

use case use case testing complete tutorial

Laten we het eerst begrijpen ‘Wat is een use case?’ en later zullen we bespreken ‘Wat is use case-testen?’ ​

Een use case is een hulpmiddel om de vereiste gebruikersinteractie te definiëren. Als u een nieuwe applicatie probeert te maken of wijzigingen aan een bestaande applicatie wilt aanbrengen, worden er verschillende discussies gevoerd. Een van de kritische discussies die u moet voeren, is hoe u de vereiste voor de softwareoplossing zult vertegenwoordigen.

Bedrijfsexperts en ontwikkelaars moeten een wederzijds begrip hebben over de vereiste, aangezien deze erg moeilijk te bereiken is. Elke standaardmethode om de communicatie tussen hen te structureren, zal echt een zegen zijn. Het zal op zijn beurt de miscommunicaties verminderen en hier is de plek waar Use Case in beeld komt.

Deze tutorial geeft je een duidelijk beeld van het concept van use case en testen, waarbij de verschillende aspecten die ermee te maken hebben worden behandeld met praktische voorbeelden voor een goed begrip van iedereen die helemaal nieuw is met het concept.

Wat je leert:

• Use Case
• Wie gebruikt ‘Use Case'-documenten?
• Soorten use cases
  • # 1) Gebruiksgevallen op zonnige dagen
  • # 2) Gebruiksscenario's voor regenachtige dagen
• Elementen in use cases
• Vertegenwoordiging
• Hoe schrijf je een use case?
• Gebruik casusdiagram
• Gebruikersacties
• Wat is use case-testen?
  • Enkele feiten
  • Hoe maak je een testcase-sjabloon?
• Gevolgtrekking
• Aanbevolen literatuur

Use Case

Use case speelt een belangrijke rol in de verschillende fasen van de Software Development Life Cycle. Gebruiksscenario hangt af van ‘Gebruikersacties’ en ‘Reactie van het systeem’ op de gebruikersacties.

Het is de documentatie van de ‘Acties’ die worden uitgevoerd door de Actor / Gebruiker en het overeenkomstige ‘Gedrag’ van het Systeem met de ‘Acties’ van de Gebruiker. Gebruik cases kan al dan niet resulteren in het bereiken van een doel van de ‘Acteur / Gebruiker’ over interacties met het systeem.

In Use Case zullen we beschrijven ‘Hoe zal een systeem reageren op een bepaald scenario?’ ​Het is ‘gebruikersgericht’ niet ‘systeemgericht’.

Het is ‘gebruikersgericht’: We zullen specificeren ‘wat zijn de acties die de gebruiker doet?’ En ‘Wat zien de actoren in een systeem?’.

Het is niet ‘systeemgericht’: We zullen niet specificeren ‘Wat is de input die aan het systeem wordt gegeven?’ En ‘Wat is de output die door het systeem wordt geproduceerd?’.

Het ontwikkelteam moet de ‘Use Cases’ schrijven, aangezien de ontwikkelingsfase er sterk van afhangt.

Use case writer, teamleden en de klanten zullen bijdragen aan het creëren van deze cases. Om deze te maken, hebben we een ontwikkelteam nodig en het team moet zich goed bewust zijn van de projectconcepten.

Na implementatie van de case wordt het document getest en wordt het gedrag van het systeem dienovereenkomstig gecontroleerd. In een geval staat de hoofdletter ‘A’ voor ‘Acteur’, de letter ‘S’ voor ‘Systeem’.

Wie gebruikt ‘Use Case'-documenten?

Deze documentatie geeft een compleet overzicht van de verschillende manieren waarop de gebruiker met een systeem omgaat om het doel te bereiken. Betere documentatie kan helpen om de vereiste voor een softwaresysteem op een veel eenvoudigere manier te identificeren.

Deze documentatie kan worden gebruikt door softwareontwikkelaars, softwaretesters en belanghebbenden.

Gebruik van de documenten:

• Ontwikkelaars gebruiken de documenten om de code te implementeren en te ontwerpen.
• Testers gebruiken ze om het testgevallen ​
• Zakelijke belanghebbenden gebruiken het document om de softwarevereisten te begrijpen.

Soorten use cases

Er zijn 2 soorten.

Zij zijn:

• Zonnige dag
• Regenachtige dag

# 1) Gebruiksgevallen op zonnige dagen

Dit zijn de belangrijkste gevallen die het meest waarschijnlijk zullen gebeuren als alles goed gaat. Deze krijgen een hoge prioriteit dan de andere gevallen. Zodra we de cases hebben afgerond, geven we deze ter beoordeling aan het projectteam en zorgen we ervoor dat we alle vereiste cases hebben afgedekt.

converteer karakter naar string c ++

# 2) Gebruiksscenario's voor regenachtige dagen

Deze kunnen worden gedefinieerd als de lijst met randgevallen. De prioriteit van dergelijke gevallen komt na de ‘Sunny Use Cases’. We kunnen de hulp inroepen van belanghebbenden en productmanagers om de gevallen te prioriteren.

Elementen in use cases

Hieronder staan ​​de verschillende elementen:

1) Beknopt Omschrijving : Een korte beschrijving waarin de zaak wordt uitgelegd.

2) Acteur : Gebruikers die zijn betrokken bij acties voor use cases.

3) Voorwaarde : Voorwaarden waaraan moet worden voldaan voordat de zaak begint.

4) Basis Stromen : ‘Basisstroom’ of ‘Hoofdscenario’ is de normale workflow in het systeem. Het is de stroom van transacties die de actoren doen bij het bereiken van hun doelen. Wanneer de acteurs interactie hebben met het systeem, aangezien het de normale workflow is, zullen er geen fouten optreden en krijgen de acteurs de verwachte output.

5) Wissel af stromen : Naast de normale workflow kan een systeem ook een ‘Alternatieve workflow’ hebben. Dit is de minder gebruikelijke interactie van een gebruiker met het systeem.

6) Uitzondering stromen : De stroom die voorkomt dat een gebruiker het doel bereikt.

7) Post Voorwaarden : De voorwaarden die moeten worden gecontroleerd nadat de casus is voltooid.

Vertegenwoordiging

Een casus wordt vaak weergegeven in een platte tekst of een diagram. Vanwege de eenvoud van het use case-diagram wordt het door elke organisatie als optioneel beschouwd

Use Case Voorbeeld:

Hier zal ik de casus voor ‘Inloggen’ op een ‘Schoolmanagementsysteem’ uitleggen.

Punten om op te merken

• Veelgemaakte fouten die de deelnemers maken met Use Case is dat deze ofwel te veel details over een bepaalde case bevat, of helemaal niet genoeg details.
• Dit zijn tekstuele modellen, indien nodig kunnen we er al dan niet een visueel diagram aan toevoegen.
• Bepaal de toepasselijke randvoorwaarde.
• Schrijf de processtappen in de juiste volgorde.
• Specificeer de kwaliteitseis voor het proces.

Hoe schrijf je een use case?

De onderstaande punten zullen u helpen om deze te schrijven:

​ Wanneer we proberen een case te schrijven, is de eerste vraag die moet opwerpen ‘Wat is het primaire gebruik voor de klant?’. Deze vraag zal je ertoe aanzetten om je cases te schrijven vanuit het perspectief van de gebruiker.

​ We moeten hiervoor een sjabloon hebben verkregen.

​ Het moet productief, eenvoudig en sterk zijn. Een sterke use case kan indruk maken op het publiek, zelfs als ze kleine fouten hebben.

​ We zouden het moeten nummeren.

​ We moeten de processtap in de volgorde schrijven.

​ Geef de scenario's een juiste naam, de naamgeving moet worden gedaan in overeenstemming met het doel.

​ Dit is een iteratief proces, wat betekent dat wanneer u ze voor de eerste keer schrijft, het niet perfect zal zijn.

​ Identificeer de actoren in het systeem. Misschien vindt u een heleboel acteurs in het systeem.

Voorbeeld ​als u een e-commercesite als Amazon overweegt, kunnen we daar acteurs vinden zoals kopers, verkopers, groothandelaars, auditors, leveranciers, distributeurs, klantenservice enz.

Laten we eerst eens kijken naar de eerste acteurs. We kunnen meer dan één acteur hebben die hetzelfde gedrag vertoont.

Bijvoorbeeld ​ zowel koper als verkoper kunnen ‘een account aanmaken’. Evenzo kunnen ‘Koper en Verkoper’ ‘Artikel zoeken’. Dit zijn dus dubbele gedragingen en ze moeten worden geëlimineerd. Afgezien van het gebruik van dubbele gevallen, moeten we meer algemene gevallen hebben. Daarom moeten we de gevallen generaliseren om dubbel werk te voorkomen.

​ We moeten de toepasselijke randvoorwaarde bepalen.

Gebruik casusdiagram

Use Case Diagram is een grafische weergave van de acties van een gebruiker (s) in een systeem. Het biedt in deze context een geweldig hulpmiddel, als het diagram veel actoren bevat, is het heel gemakkelijk te begrijpen. Als het een diagram op hoog niveau is, zal het niet veel details delen. Het toont complexe ideeën op een vrij eenvoudige manier.

Afb.Nr: UC 01

Zoals getoond in de Afb.Nr: UC 01 het vertegenwoordigt een diagram waarbij Rechthoek een ‘Systeem’ vertegenwoordigt, ovaal een ‘Gebruikscasus’ vertegenwoordigt, Pijl vertegenwoordigt een ‘Relatie’ en de Man een ‘Gebruiker / acteur’ vertegenwoordigt. Het toont een systeem / applicatie, vervolgens toont het de organisatie / mensen die ermee omgaan en toont het de basisstroom van ‘Wat doet het systeem?’

Afb.Nr: UC 02

Fig No: UC 03 - Use case diagram voor login

Dit is het use case-diagram van de ‘Login’ case. Hier hebben we meer dan één actor, ze zijn allemaal buiten het systeem geplaatst. Studenten, docenten en ouders worden als primaire actoren beschouwd. Daarom worden ze allemaal aan de linkerkant van de rechthoek geplaatst.

Admin en Staff worden beschouwd als secundaire actoren, dus plaatsen we ze aan de rechterkant van de rechthoek. Acteurs kunnen inloggen op het systeem, dus verbinden we de acteurs en inlogcase met een connector.

Andere functies die in het systeem worden aangetroffen, zijn Wachtwoord opnieuw instellen en Wachtwoord vergeten. Ze zijn allemaal gerelateerd aan login case, dus we verbinden ze met de connector.

Gebruikersacties

Dit zijn de acties die door de gebruiker in een systeem worden uitgevoerd.

Bijvoorbeeld: Zoeken op locatie, een item aan favorieten toevoegen, proberen contact op te nemen enz.

Notitie:

• Een systeem is ‘wat je ook aan het ontwikkelen bent’. Het kan een website, een app of een andere softwarecomponent zijn. Het wordt over het algemeen weergegeven door een rechthoek. Het bevat use cases. Gebruikers worden buiten de ‘rechthoek’ geplaatst.
• Gebruik cases worden doorgaans weergegeven door ovale vormen die de acties erin specificeren.
• Acteurs / gebruikers zijn de mensen die het systeem gebruiken. Maar soms kunnen het andere systemen, personen of een andere organisatie zijn.

Wat is use case-testen?

Het valt onder de testtechniek Functional Black Box. Omdat het een black box-test is, vindt er geen inspectie van de codes plaats. In deze sectie worden enkele interessante feiten hierover toegelicht.

Het zorgt ervoor dat het pad dat door de gebruiker wordt gebruikt, werkt zoals bedoeld of niet. Het zorgt ervoor dat de gebruiker de taak met succes kan voltooien.

Enkele feiten

• Er worden geen tests uitgevoerd om de kwaliteit van de software te bepalen.
• Zelfs als het een soort end-to-end-test is, zal het niet de volledige dekking van de gebruikerstoepassing garanderen.
• Op basis van het testresultaat dat bekend is uit de Use Case testing kunnen we niet beslissen over de inzet van de productieomgeving.
• Het zal de gebreken in integratietests ontdekken.

Gebruiksvoorbeeld Testvoorbeeld:

Overweeg een scenario waarin een gebruiker een artikel koopt van een online winkelwebsite. De gebruiker zal eerst inloggen op het systeem en beginnen met zoeken. De gebruiker selecteert een of meer items die in de zoekresultaten worden weergegeven en voegt ze toe aan de winkelwagen.

Na dit alles zal hij uitchecken. Dit is dus een voorbeeld van een logisch verbonden reeks stappen die de gebruiker in een systeem zal uitvoeren om de taak te volbrengen.

Hierbij wordt de stroom van transacties in het gehele systeem van begin tot eind getest. Use Cases zijn over het algemeen het pad dat gebruikers waarschijnlijk zullen gebruiken om een ​​specifieke taak uit te voeren.

Dit maakt Use Cases dus gemakkelijk om de defecten te vinden, aangezien het het pad bevat dat de gebruikers eerder zullen tegenkomen wanneer de gebruiker de applicatie voor de eerste keer gebruikt.

Stap 1: De eerste stap is het beoordelen van Use Case-documenten.

We moeten herzien en ervoor zorgen dat de functionele vereisten volledig en correct zijn.

Stap 2: We moeten ervoor zorgen dat use cases atomair zijn.

Bijvoorbeeld: Overweeg een 'Schoolmanagementsysteem met veel functionaliteiten zoals' Inloggen ',' Leerlinggegevens tonen ',' Markeringen tonen ',' Aanwezigheid tonen ',' Contact opnemen met personeel ',' Kosten indienen ', enz. Voor dit geval proberen we om bereid de Use Cases voor 'Login'-functionaliteit voor.

We moeten ervoor zorgen dat geen van de normale workflow-behoeften hoeft te worden verwisseld met andere functionaliteit. Het moet volledig gerelateerd zijn aan de ‘Inloggen’ functionaliteit.

Stap 3: We moeten de normale workflow in het systeem inspecteren.

Na inspectie van de workflow moeten we ervoor zorgen dat deze volledig is. Op basis van de kennis van het systeem of zelfs het domein kunnen we de ontbrekende stappen in de workflow achterhalen.

Stap 4: Zorg ervoor dat de alternatieve workflow in het systeem is voltooid.

Stap 5: We moeten ervoor zorgen dat elke stap in de use case testbaar is.

Elke stap die in de use case-test wordt uitgelegd, is testbaar.

Bijvoorbeeld​ sommige creditcardtransacties in het systeem kunnen om veiligheidsredenen niet worden getest.

Stap 6: Zodra we deze cases nieuw leven hebben ingeblazen, kunnen we de testcases schrijven.

We moeten testcases schrijven voor elke normale stroom en alternatieve stroom.

Bijvoorbeeld ​ Overweeg het geval 'Show Student Marks' in een schoolmanagementsysteem.

Gebruik case naam: Leerlingcijfers weergeven

Acteurs: Studenten, docenten, ouders

Pre-conditie:

1) Het systeem moet op het netwerk zijn aangesloten.

twee) Acteurs moeten een ‘Student-ID’ hebben.

Gebruiksvoorbeeld voor ‘Leerlingcijfers tonen’:

Overeenkomstige testcase voor 'Show Student Marks'-case:

Houd er rekening mee dat de hier getoonde Testcase-tabel alleen de basisinformatie bevat. ‘Hoe u een testcase-sjabloon maakt’ wordt hieronder in detail uitgelegd.

De tabel geeft de ‘Testcase’ weer die overeenkomt met de casus ‘Show Student Mark’, zoals hierboven weergegeven.

De beste manier om testcases te schrijven, is door eerst de testcases voor ‘het hoofdscenario’ te schrijven en ze vervolgens voor ‘Alternatieve stappen’ te schrijven. De ' Stappen' in testcases zijn afkomstig van use case-documenten. De allereerste ' Stap' van 'Show Student Mark' case, 'Enter Student Name' wordt de eerste Stap in de ‘Testcase’.

De gebruiker / acteur moet het kunnen invoeren. Dit wordt de verwacht resultaat ​

We kunnen de hulp inroepen van testontwerptechnieken zoals ‘ grenswaardeanalyse ’ , ‘Equivalentiepartitie’ terwijl we de testcases voorbereiden. De testontwerptechniek zal helpen om het aantal testgevallen te verminderen en daarmee de testtijd te verkorten.

Hoe maak je een testcase-sjabloon?

Bij het voorbereiden van de testcases moeten we denken en handelen als de eindgebruiker, d.w.z. jezelf in de schoenen van een eindgebruiker plaatsen.

Er zijn verschillende tools die in de markt beschikbaar zijn om in deze context te helpen. ​ TestLodge ’is er een van, maar het is geen gratis tool. We moeten het kopen.

We hebben een sjabloon nodig om de testcase te documenteren. Laten we eens kijken naar een veelvoorkomend scenario, ‘FLIPKART-login’ waarmee we allemaal bekend zijn. Google-spreadsheet kan worden gebruikt om de testcase-tabel te maken en deze te delen met de teamleden. Ik gebruik voorlopig een Excel-document.

Hier is een voorbeeld

​ DOWNLOAD hier deze testcase-tabelsjabloon

Geef allereerst een naam voor het testcaseblad. We schrijven testcases voor een bepaalde module in een project. Dus we moeten de 'Naam van het project' en de ‘Projectmodule ’Kolommen in de testcasetabel. Het document moet de naam van de maker van de testcases bevatten.

Voeg daarom toe 'Gemaakt door' en ‘Aanmaakdatum’ kolommen. Het document moet worden beoordeeld door iemand (teamleider, projectmanager enz.), Dus voeg toe 'Beoordeeld door' kolom en ‘Beoordeeld Datum’ ​

Volgende kolom is ‘Testscenario’ , hier hebben we het voorbeeldtestscenario gegeven ‘Facebook-login verifiëren’ ​Voeg de kolommen toe ‘Testscenario-ID’ en ‘Beschrijving testcase’ ​

Voor elk testscenario zullen we schrijven ‘Testgevallen ​Dus voeg de kolommen toe ‘Testcase-ID’ en ‘Beschrijving testcase ​Voor elk testscenario zal er zijn ‘Postconditie’ en ‘Pre-Condition’ ​Voeg de kolommen ‘Post-Condition’ en ‘Pre-Condition’ toe.

Een andere belangrijke column is 'Testgegevens' ​Het bevat de gegevens die we gebruiken om te testen. Een testscenario moet uitgaan van een verwacht resultaat en het daadwerkelijke resultaat. Voeg de kolom toe 'Verwacht resultaat' en ‘Werkelijk resultaat’. 'Toestand' toont het resultaat van de uitvoering van het testscenario. Het kan slagen / mislukken zijn.

Testers zullen de testcases uitvoeren. We moeten het opnemen als 'Uitgevoerd door' en ‘Uitvoerdatum’ ​We zullen ’Commando's’ toevoegen als die er zijn.

Gevolgtrekking

Ik hoop dat je een duidelijk idee had gekregen van use cases en use case testen.

Het schrijven van deze cases is een iteratief proces. Je hebt maar weinig oefening en een goede kennis van een systeem nodig om deze cases te schrijven.

Kortom, we kunnen ‘Use Case testing’ in een applicatie gebruiken om de ontbrekende schakels, onvolledige vereisten, enz. Te vinden. Door ze te vinden en het systeem aan te passen, wordt het systeem efficiënter en accurater.

Heeft u eerdere ervaringen met use cases en testen? Deel het gerust met ons in de comments hieronder.

Aanbevolen literatuur

• Functioneel testen versus niet-functioneel testen
• Diepgaande Eclipse-zelfstudies voor beginners
• Alfatesten en bètatesten (een complete gids)
• Tutorial over DevOps-testen: welke invloed heeft DevOps op QA-testen?
• Beste softwaretesttools 2021 (QA Test Automation Tools)
• Tutorial over bruikbaarheidstesten: een complete handleiding om aan de slag te gaan
• GUI-testhandleiding: een complete gebruikersinterface (UI) testhandleiding
• Tutorial over destructief testen en niet-destructief testen