Výukový program Use Case a Use Case Testing

use case use case testing complete tutorial

Za prvé, pochopme „Co je případ použití?“ a později budeme diskutovat „Co je Testování případů použití?“ .

Případ použití je nástroj pro definování požadované interakce uživatele. Pokud se pokoušíte vytvořit novou aplikaci nebo provést změny v existující aplikaci, proběhne několik diskusí. Jednou z kritických diskusí, kterou musíte udělat, je, jak budete reprezentovat požadavek na softwarové řešení.

Obchodní experti a vývojáři musí mít o požadavku vzájemné porozumění, protože je velmi obtížné ho dosáhnout. Jakákoli standardní metoda strukturování komunikace mezi nimi bude ve skutečnosti přínosem. To zase sníží nedorozumění a tady je místo, kde se do obrazu dostane případ Use.

Tento výukový program vám poskytne jasný obraz o konceptu Use case a testování, a tím pokryje jeho různé aspekty praktickými příklady pro snadné pochopení každého, kdo je v konceptu úplně nový.

Co se naučíte:

• Pouzdro
• Kdo používá dokumenty „Použít případ“?
• Druhy případů použití
  • # 1) Případy slunečného dne
  • # 2) Pouzdra na deštivý den
• Případy použití
• Zastoupení
• Jak napsat případ použití?
• Použijte případový diagram
• Akce uživatele
• Co je Testování případů použití?
  • Některá fakta
  • Jak vytvořit šablonu testovacího případu?
• Závěr
• Doporučené čtení

Pouzdro

V různých fázích životního cyklu vývoje softwaru hraje významnou roli případ použití. Případ použití závisí na „uživatelských akcích“ a „odezvě systému“ na uživatelské akce.

Jde o dokumentaci „akcí“ prováděných hercem / uživatelem a odpovídající „chování“ systému k „akcím“ uživatele. Případy užití může nebo nemusí vést k dosažení cíle „hercem / uživatelem“ v interakcích se systémem.

V případě použití popíšeme „Jak bude systém reagovat na daný scénář?“ . Není „orientovaný na uživatele“, nýbrž „na systém“.

Je „uživatelsky orientovaný“: Budeme specifikovat „jaké akce provede uživatel?“ A „Co vidí herci v systému?“.

Není „systémově orientovaný“: Nebudeme specifikovat „Jaký je vstup daný do systému?“ A „Jaký je výstup produkovaný systémem?“.

Vývojový tým musí napsat „Případy použití“, protože vývojová fáze na nich velmi závisí.

K vytvoření těchto případů přispějí spisovatelé případů, členové týmu a zákazníci. Abychom je mohli vytvořit, musíme mít sestavený vývojový tým a tým by si měl být velmi dobře vědom koncepcí projektu.

Po implementaci případu je dokument otestován a odpovídajícím způsobem zkontrolováno chování systému. V případě, že velké písmeno „A“ označuje „herce“, písmeno „S“ označuje „systém“.

Kdo používá dokumenty „Použít případ“?

Tato dokumentace poskytuje úplný přehled o odlišných způsobech interakce uživatele se systémem k dosažení cíle. Lepší dokumentace může pomoci identifikovat požadavek na softwarový systém mnohem snadněji.

Tuto dokumentaci mohou používat vývojáři softwaru, testeři softwaru i zúčastněné strany.

Použití dokumentů:

• Vývojáři používají dokumenty k implementaci kódu a jeho návrhu.
• Testeři je používají pro vytváření testovací případy .
• Zainteresované strany z podnikání používají dokument k pochopení softwarových požadavků.

Druhy případů použití

Existují 2 typy.

Oni jsou:

• Slunečný den
• Deštivý den

# 1) Případy slunečného dne

Jsou to primární případy, které se s největší pravděpodobností stanou, když se vše povede dobře. Těm je dána vysoká priorita než ostatním případům. Jakmile jsme případy dokončili, předáme je projektovému týmu ke kontrole a ujistíme se, že jsme pokryli všechny požadované případy.

implementace seznamu sousedství c ++

# 2) Pouzdra na deštivý den

Ty lze definovat jako seznam okrajových případů. Priorita takových případů bude následovat po „případech Sunny Use“. Můžeme požádat o pomoc zúčastněné strany a produktové manažery, aby upřednostnily případy.

Případy použití

Níže jsou uvedeny různé prvky:

1) Stručně popis : Stručný popis vysvětlující případ.

2) Herec : Uživatelé, kteří jsou zapojeni do akcí případů použití.

3) Předpoklad : Podmínky, které je třeba uspokojit před zahájením případu.

4) Základní Tok : „Základní tok“ nebo „Hlavní scénář“ je normální pracovní postup v systému. Je to tok transakcí prováděných Aktéry při dosahování jejich cílů. Když herci interagují se systémem, protože je to normální pracovní postup, nedojde k žádné chybě a herci získají očekávaný výstup.

5) Alternativní tok : Kromě běžného pracovního postupu může mít systém také „alternativní pracovní postup“. Toto je méně častá interakce prováděná uživatelem se systémem.

6) Výjimka tok : Tok, který brání uživateli v dosažení cíle.

7) Příspěvek Podmínky : Podmínky, které je třeba zkontrolovat po dokončení případu.

Zastoupení

Případ je často znázorněn jako prostý text nebo diagram. Kvůli jednoduchosti diagramu případů použití je považována jakoukoli organizací za volitelnou

Příklad použití případu:

Zde vysvětlím důvod pro „přihlášení“ k „systému řízení školy“.

Body, které je třeba poznamenat

• Časté chyby, které účastníci v případě použití dělají, spočívají v tom, že buď obsahuje příliš mnoho podrobností o konkrétním případu, nebo vůbec žádné podrobnosti.
• Jedná se o textové modely, pokud je to požadováno, můžeme nebo nemusíme k nim přidat vizuální diagram.
• Určete použitelný předpoklad.
• Postupujte podle pokynů ve správném pořadí.
• Uveďte požadavek na kvalitu procesu.

Jak napsat případ použití?

Níže shrnuté body vám pomohou tyto body napsat:

=> Když se snažíme napsat případ, první otázka, která by měla vyvstat, je „Jaké je primární použití pro zákazníka?“ Tato otázka vás přiměje psát vaše případy z pohledu uživatele.

=> Musíme pro ně získat šablonu.

=> Musí to být produktivní, jednoduché a silné. Silný případ použití může zapůsobit na publikum, i když má drobné chyby.

=> Měli bychom to očíslovat.

=> Procesní krok bychom měli napsat do jeho objednávky.

=> Dejte scénářům správný název, pojmenování musí být provedeno podle účelu.

=> Toto je iterační proces, což znamená, že když je napíšete poprvé, nebude to perfektní.

=> Identifikujte aktéry v systému. V systému můžete najít spoustu herců.

Příklad ,pokud vezmete v úvahu web elektronického obchodování, jako je Amazon, najdeme zde herce jako kupující, prodávající, velkoobchodní prodejci, auditoři, dodavatelé, distributoři, péče o zákazníky atd.

Zpočátku uvažujme o prvních aktérech. Můžeme mít více než jednoho herce se stejným chováním.

Například , Kupující / Prodávající mohou „vytvořit účet“. Obdobně „Kupující i Prodávající“ mohou „Vyhledat položku“. Jedná se tedy o duplicitní chování a je třeba je eliminovat. Kromě použití duplicitních případů musíme mít obecnější případy. Proto musíme případy zobecnit, abychom zabránili duplicitě.

=> Musíme určit použitelnou podmínku.

Použijte případový diagram

Diagram případů použití je obrazové znázornění akcí uživatelů v systému. Poskytuje v této souvislosti skvělý nástroj, pokud diagram obsahuje mnoho aktérů, pak je velmi snadné jej pochopit. Pokud se jedná o diagram na vysoké úrovni, nebude sdílet mnoho podrobností. Ukazuje složité myšlenky poměrně základním způsobem.

Obr.: UC 01

Jak je uvedeno v Obr.: UC 01 představuje diagram, kde Obdélník představuje „Systém“, ovál představuje „Případ použití“, Šipka představuje „Vztah“ a Muž představuje „Uživatel / Herec“. Ukazuje systém / aplikaci, poté ukazuje organizaci / lidi, kteří s ní interagují, a ukazuje základní tok „Co systém dělá?“

Obr.: UC 02

Obr.: UC 03 - Pro přihlášení použijte diagram případů

Toto je diagram případů použití případu „Přihlášení“. Tady máme více než jednoho herce, všichni jsou umístěni mimo systém. Za primární aktéry jsou považováni studenti, učitelé a rodiče. Proto jsou všechny umístěny na levé straně obdélníku.

Správce a štáb jsou považováni za sekundární herce, takže je umístíme na pravou stranu obdélníku. Herci se mohou přihlásit do systému, takže propojíme herce a případ přihlášení pomocí konektoru.

Další funkce v systému jsou Resetovat heslo a Zapomněli jste heslo. Všechny souvisí s případem přihlášení, takže je připojíme ke konektoru.

Akce uživatele

Jedná se o akce, které provádí uživatel v systému.

Například: Hledání na místě, přidání položky k oblíbeným, pokus o kontakt atd.

Poznámka:

• Systém je „vše, co vyvíjíte“. Může to být web, aplikace nebo jakákoli jiná softwarová součást. Obecně je reprezentován obdélníkem. Obsahuje případy použití. Uživatelé jsou umístěni mimo „obdélník“.
• Případy užití jsou obecně reprezentovány oválnými tvary určujícími akce uvnitř.
• Herci / Uživatelé jsou lidé, kteří používají systém. Někdy to však mohou být jiné systémy, osoba nebo jakákoli jiná organizace.

Co je Testování případů použití?

Spadá pod testovací techniku ​​Functional Black Box. Jelikož se jedná o testování černé skříňky, nebude zde žádná kontrola kódů. V této části je uvedeno několik zajímavých faktů.

Zajišťuje, zda cesta používaná uživatelem funguje tak, jak má, nebo ne. Zajišťuje, že uživatel může úkol úspěšně dokončit.

Některá fakta

• O kvalitě softwaru se neprovádí testování.
• I když se jedná o typ testování typu end-to-end, nezajistí celé pokrytí uživatelské aplikace.
• Na základě výsledku testu známého z Use Case testování nemůžeme rozhodnout o nasazení produkčního prostředí.
• Zjistí nedostatky v testování integrace.

Příklad testování případu použití:

Zvažte scénář, kdy uživatel kupuje položku z webu online nakupování. Uživatel se nejprve přihlásí do systému a zahájí vyhledávání. Uživatel vybere jednu nebo více položek zobrazených ve výsledcích hledání a přidá je do košíku.

Po tom všem se odhlásí. Toto je příklad logicky propojené řady kroků, které uživatel provede v systému, aby splnil úkol.

Při tomto testování je testován tok transakcí v celém systému od začátku do konce. Pouzdra použití jsou obecně cestou, kterou uživatelé s největší pravděpodobností použijí, aby dosáhli konkrétního úkolu.

Díky tomu je v případech použití snadné najít vady, protože zahrnuje cestu, na kterou uživatelé pravděpodobně narazí, když uživatel aplikaci používá poprvé.

Krok 1: Prvním krokem je kontrola dokumentů Use Case.

Musíme zkontrolovat a ujistit se, že funkční požadavky jsou úplné a správné.

Krok 2: Musíme se ujistit, že případy použití jsou atomové.

Například: Zvažte „Systém řízení školy s mnoha funkcemi, jako je„ Přihlášení “,„ Zobrazit podrobnosti studenta “,„ Zobrazit známky “,„ Zobrazit účast “,„ Kontaktovat zaměstnance “,„ Odeslat poplatky “atd. V tomto případě se snažíme připravit funkci Pouzdra pro funkci „Přihlášení“.

Musíme se ujistit, že se žádný z běžných pracovních postupů nemusí míchat s žádnou jinou funkcí. Musí to zcela souviset pouze s funkcí „Přihlásit se“.

Krok 3: Musíme zkontrolovat normální pracovní postup v systému.

Po kontrole pracovního postupu se musíme ujistit, že je kompletní. Na základě znalostí systému nebo dokonce domény můžeme zjistit chybějící kroky v pracovním postupu.

Krok 4: Zajistěte, aby byl alternativní pracovní postup v systému dokončen.

Krok 5: Měli bychom zajistit, aby každý krok v případu použití byl testovatelný.

Každý krok vysvětlený v testování případů použití je testovatelný.

Například, některé transakce kreditní kartou v systému nejsou z bezpečnostních důvodů testovatelné.

Krok 6: Jakmile tyto případy oživíme, můžeme psát testovací případy.

Musíme napsat testovací případy pro každý normální tok a alternativní tok.

Například , Zvažte případ „Zobrazit známky studenta“ v systému řízení školy.

Název případu použití: Ukažte studentské známky

Herci: Studenti, učitelé, rodiče

Předpoklad:

1) Systém musí být připojen k síti.

dva) Herci musí mít „studentské ID“.

Pouzdro pro „Zobrazit známky studenta“:

Odpovídající testovací případ pro případ „Zobrazit známky studenta“:

Upozorňujeme, že zde uvedená tabulka testovacích případů obsahuje pouze základní informace. „Jak vytvořit šablonu testovacího případu“ je podrobně vysvětleno níže.

V tabulce je uveden „Testovací případ“ odpovídající případu „Zobrazit známku studenta“, jak je uvedeno výše.

Nejlepším způsobem, jak napsat testovací případy, je nejprve napsat testovací případy pro „hlavní scénář“ a poté je napsat pro „alternativní kroky“. „ Kroky v testovacích případech jsou získány z dokumentů Use Case. Úplně první „ Krok' z případu „Zobrazit studentskou známku“ se stane první „Zadejte studentské jméno“ Krok v „testovacím případě“.

Uživatel / herec musí být schopen vstoupit. Toto se stává Očekávaný výsledek .

Můžeme vyhledat pomoc s technikou návrhu testů jako analýza hraniční hodnoty “ , „Rozdělení ekvivalence“ při přípravě testovacích případů. Technika návrhu testu pomůže snížit počet testovacích případů a tím zkrátit čas potřebný k testování.

Jak vytvořit šablonu testovacího případu?

Při přípravě testovacích případů musíme myslet a chovat se jako koncový uživatel, tj. Postavit se do kůže koncového uživatele.

Na trhu je k dispozici několik nástrojů, které vám v této souvislosti pomohou. '' TestLodge “je jedním z nich, ale není to bezplatný nástroj. Musíme si to koupit.

Potřebujeme šablonu pro dokumentaci testovacího případu. Uvažujme o společném scénáři, přihlašování FLIPKART, který všichni známe. Tabulku Google lze použít k vytvoření tabulky testovacích případů a její sdílení se členy týmu. Prozatím používám dokument aplikace Excel.

Zde je příklad

=> STÁHNOUT tuto šablonu tabulky testovacích případů zde

Na první pohled pojmenujte list případu vhodným jménem. Píšeme testovací případy pro konkrétní modul v projektu. Musíme tedy přidat 'Název projektu' a „Modul projektu „Sloupce v tabulce testovacích případů. Dokument musí obsahovat jméno tvůrce testovacích případů.

Proto přidejte 'Vytvořil' a 'Datum vytvoření' sloupce. Dokument musí někdo zkontrolovat (vedoucí týmu, vedoucí projektu atd.), Tak přidejte „Zkontrolováno“ sloupec a „Datum revize“ .

Další sloupec je „Scénář testu“ , zde jsme poskytli příklad zkušebního scénáře „Ověřit přihlášení na Facebooku“ . Přidejte sloupce „ID testovacího scénáře“ a „Popis testovacího případu“ .

Pro každý scénář testu napíšeme „Testovací případy “. Přidejte tedy sloupce „ID testovacího případu“ a „Popis testovacího případu “. Pro každý testovací scénář bude „Post Condition“ a 'Předpoklad' . Přidejte sloupce „Post-Condition“ a „Pre-Condition“.

Dalším důležitým sloupcem je 'Testovací data' . Bude obsahovat údaje, které používáme pro testování. Scénář testu musí předpokládat očekávaný výsledek a skutečný výsledek. Přidejte sloupec 'Očekávaný výsledek' a „Skutečný výsledek“. 'Postavení' ukazuje výsledek provedení testovacího scénáře. Může to být buď vyhovět / selhat.

Testeři provedou testovací případy. Musíme to zahrnout jako „Provedeno“ a „Datum provedení“ . Přidáme „Příkazy“, pokud nějaké existují.

Závěr

Doufám, že byste měli jasnou představu o případech použití a testování případů použití.

Psaní těchto případů je iterační proces. K psaní těchto případů potřebujete jen málo praxe a dobrou znalost systému.

Stručně řečeno, můžeme použít „Použít testování případu“ v aplikaci k vyhledání chybějících odkazů, neúplných požadavků atd. Jejich vyhledáním a úpravou systému dosáhnete účinnosti a přesnosti systému.

Máte předchozí zkušenosti s případy použití a testováním? Neváhejte se s námi podělit v sekci komentářů níže.

Doporučené čtení

• Funkční testování vs. nefunkční testování
• Výukové programy pro zatmění do hloubky pro začátečníky
• Alfa testování a beta testování (kompletní průvodce)
• Výukový program pro testování DevOps: Jak DevOps ovlivní testování kvality?
• Nejlepší nástroje pro testování softwaru 2021 (QA Test Automation Tools)
• Výukový program pro testování použitelnosti: Kompletní příručka Začínáme
• Výukový program pro testování grafického uživatelského rozhraní: Kompletní příručka pro testování uživatelského rozhraní (UI)
• Výukový program pro destruktivní testování a nedestruktivní testování