Vývoj testů z modelu
K uspořádání testů systému a jeho součástí můžete použít požadavky a modely architektury. Tento postup pomáhá zajistit, abyste otestování požadavků, které jsou pro uživatele a další zúčastněné strany důležité, a pomůže vám rychle aktualizovat testy, když se požadavky změní. Pokud používáte Microsoft Test Manager, můžete také udržovat propojení mezi modely a testy.
Informace o tom, které verze sady Visual Studio tyto funkce podporují, najdete v tématu Podpora verzí pro nástroje pro architekturu a modelování.
Testování systému a subsystému
Systémové testování, označované také jako akceptační testování, znamená testování, jestli jsou splněny potřeby uživatelů. Takové testy jsou znepokojeny externě viditelným chováním systému místo vnitřního návrhu.
Systémové testy jsou velmi cenné při rozšiřování nebo změně návrhu systému. Pomáhají vám vyhnout se vkládání chyb při změně kódu.
Při plánování jakékoli změny nebo rozšíření systému je užitečné začít se sadou systémových testů, které běží na existujícím systému. Pak můžete testy rozšířit nebo upravit, abyste otestování nových požadavků, udělali změny kódu a znovu spusťte kompletní sadu testů.
Při vývoji nového systému můžete začít vytvářet testy hned, jak začne vývoj. Definováním testů před vývojem jednotlivých funkcí můžete zachytit diskuze o požadavcích velmi konkrétním způsobem.
Testování subsystému používá stejné principy pro hlavní komponenty systému. Každá komponenta se testuje odděleně od ostatních komponent. Testy subsystému se zaměřují na chování viditelné v uživatelských rozhraních komponenty nebo rozhraní API.
Odvození systémových testů z modelu požadavků
Můžete vytvořit a udržovat vztah mezi systémovými testy a modelem požadavků. Pokud chcete vytvořit tuto relaci, napíšete testy, které odpovídají hlavním prvkům modelu požadavků. Visual Studio vám pomůže zachovat tento vztah tím, že umožňuje vytvářet propojení mezi testy a částmi modelu. Další informace o modelech požadavků najdete v tématu Požadavky na uživatele modelu.
Zápis testů pro každý případ použití
Pokud používáte Microsoft Test Manager, můžete vytvořit skupinu testů pro každý případ použití, který jste definovali v modelu požadavků. Pokud máte například případ použití Order a Meal,který zahrnuje Create Order and Add Item to Order, you can create tests for the overall and the more detailed of these use case.
Tyto pokyny můžou být užitečné:
Každý případ použití by měl mít několik testů pro hlavní cesty a výjimečné výsledky.
Když popisujete případ použití v modelu požadavků, je důležitější definovat jeho postcondition, tj. cíl, který se dosahuje, než podrobně popsat postupy, které uživatel následuje za účelem dosažení cíle. Například postcondition objednávky jídlo může být, že restaurace připravuje jídlo pro zákazníka a že zákazník zaplatil. Postcondition je kritérium, které by testy měly ověřit.
Založte samostatné testy na samostatných klauzulích postcondition. Můžete například vytvořit samostatné testy pro upozorňování restaurace na objednávku a pro převzetí platby od zákazníka. Toto oddělení má tyto výhody:
Změny v různých aspektech požadavků často probíhají nezávisle. Oddělením testů do různých aspektů tímto způsobem usnadníte aktualizaci testů při změně požadavků.
Pokud plán vývoje implementuje jeden aspekt případu použití před jiným, můžete testy povolit samostatně při vývoji.
Při návrhu testů oddělte výběr testovacích dat od kódu nebo skriptu, který určuje, zda bylo dosaženo postcondition. Například test jednoduché aritmetické funkce může být: Input 4; ověřte, že výstup je 2. Místo toho navrhujte skript jako: Zvolte vstup; vynásobte výstup samotným a ověřte, že je výsledkem původní vstup. Tento styl umožňuje měnit vstupy testů beze změny hlavního textu testu.
Propojení testů s případy použití
Pokud k návrhu a spuštění testů používáte Správce testů, můžete testy uspořádat podle požadavků, případů použití nebo pracovních položek uživatelského scénáře. Tyto pracovní položky můžete propojit s případy použití v modelu. Díky tomu můžete rychle sledovat změny požadavků na testy a sledovat průběh jednotlivých případů použití.
Propojení testů s případem použití
Ve Správci testů vytvořte požadavek a založte na ní sadu testů.
Požadavek, který vytvoříte, je pracovní položka na Team Foundation Serveru. V závislosti na šabloně procesu, kterou váš projekt používá se službou Team Foundation, může se jednat o pracovní položku uživatelského scénáře, požadavku nebo případu použití. Další informace naleznete v tématu O agilních nástrojích a agilním řízení projektů.
Propojte pracovní položku požadavku s jedním nebo více případy použití v modelu.
V diagramu případů použití klikněte pravým tlačítkem myši na případ použití a potom klikněte na odkaz na pracovní položku.
Přidejte do testovací sady testovací případy, které ověřují případy použití.
Každý uživatelský scénář nebo pracovní položka požadavku obvykle propojí s několika případy použití v modelu a každý případ použití bude odkazovat na několik uživatelských scénářů nebo požadavků. Důvodem je to, že každý uživatelský scénář nebo požadavek pokrývá sadu úloh, které vyvíjejí několik případů použití. Například v počáteční iteraci projektu můžete vyvinout základní uživatelský příběh, ve kterém si zákazník může vybrat položky z katalogu a nechat je doručovat. V pozdější iteraci může být, že uživatel platí při dokončení objednávky a dodavatel obdrží peníze po odeslání zboží. Každý text přidá klauzuli do postcondition případu použití Zboží objednávky.
Můžete vytvořit samostatné odkazy od požadavků na klauzule postcondition napsáním těchto klauzulí v samostatných komentářích k diagramu případu použití. Každý komentář můžete propojit s požadovanou pracovní položkou a propojit komentář s případem použití v diagramu.
Základní testy na typech požadavků
Typy, tj. třídy, rozhraní a výčty, modelu požadavků popisují koncepty a vztahy z hlediska toho, jak si uživatelé myslí a komunikují o jejich podnikání. Vylučuje typy, které se týkají pouze vnitřního návrhu systému.
Navrhněte testy z hlediska těchto typů požadavků. Tento postup vám pomůže zajistit, aby se změny požadavků probíraly, je snadné spojit změny s potřebnými změnami v testech. Umožňuje diskutovat o testech a jejich zamýšlených výsledcích přímo s koncovými uživateli a dalšími účastníky. To znamená, že potřeby uživatelů je možné udržovat mimo proces vývoje a vyhnout se neúmyslnému návrhu testů v oblasti možných chyb v návrhu.
V případě ručních testů se tento postup týká dodržování slovníku modelu požadavků v testovacích skriptech. Pro automatizované testy tento postup zahrnuje použití diagramů tříd požadavků jako základ pro testovací kód a vytvoření funkcí přístupového objektu a aktualizátoru pro propojení modelu požadavků s kódem.
Model požadavků může například obsahovat typy Nabídky, Položka nabídky, Pořadí a přidružení. Tento model představuje informace, které jsou uloženy a řešeny systémem objednávání jídla, ale nepředstavuje složitost jeho implementace. V pracovním systému může existovat několik různých realizace jednotlivých typů v databázích, v uživatelských rozhraních a v rozhraních API. V distribuovaném systému může najednou existovat několik variant jednotlivých instancí uložených v různých částech systému.
K otestování případu použití, jako je přidání položky do objednávky, může testovací metoda obsahovat kód podobný tomuto:
Order order = ... ; // set up an order
// Store prior state:
int countBefore = order.MenuItems.Count;
// Perform use case:
MenuItem chosenItem = ...; // choose an item
AddItemToOrder (chosenItem, order);
// Verify part of postcondition:
int countAfter = order.MenuItems.Count;
Assert (countAfter == countBefore = 1);
Všimněte si, že tato testovací metoda používá třídy modelu požadavků. Přidružení a atributy jsou realizovány jako vlastnosti .NET.
Aby to fungovalo, musí být vlastnosti tříd definovány jako funkce nebo přístupové objekty jen pro čtení, které přistupují k systému a načítají informace o svém aktuálním stavu. Metody, které simulují případy použití, jako je AddItemToOrder, musí systém řídit prostřednictvím jeho rozhraní API nebo prostřednictvím vrstvy pod jeho uživatelským rozhraním. Konstruktory testovacích objektů, jako je Order a MenuItem, musí také řídit systém, aby se vytvořily odpovídající položky uvnitř systému.
Řada přístupových objektů a aktualizátorů už bude dostupná prostřednictvím normálního rozhraní API aplikace. Aby bylo možné testy povolit, může být nutné napsat některé další funkce. Tyto další přístupové objekty a aktualizátory se někdy označují jako "instrumentace testů". Vzhledem k tomu, že závisí na interním návrhu systému, je zodpovědností vývojářů systému, aby je poskytli, zatímco testeři zapisují kód testů z hlediska modelu požadavků.
Při psaní automatizovaných testů můžete pomocí obecných testů zabalit přístupové objekty a aktualizátory.
Testy obchodních pravidel
Některé požadavky přímo nesouvisí s žádným případem použití. Například firma DinnerNow umožňuje zákazníkům vybírat z mnoha nabídek, ale vyžaduje, aby v každé objednávce byly všechny vybrané položky z jediné nabídky. Toto obchodní pravidlo lze vyjádřit jako neutrální o přidružení mezi objednávkami, nabídkami a položkami v modelu tříd požadavků.
Invariantní pravidlo tohoto typu řídí nejen všechny případy použití, které jsou aktuálně definovány, ale také všechny ostatní případy použití, které budou definovány později. Proto je užitečné ji napsat odděleně od případu použití a otestovat ji odděleně od případů použití.
Odvození testů subsystému z modelů
Při návrhu velkého systému na vysoké úrovni můžete identifikovat komponenty nebo subsystémy. Představují části, které mohou být navrženy samostatně nebo jsou umístěny v různých počítačích, nebo jsou opakovaně použitelné moduly, které lze rekombinovat mnoha způsoby.
Pro každou hlavní komponentu můžete použít stejné principy jako pro celý systém. Ve velkém projektu můžou mít každá komponenta svůj vlastní model požadavků. V menších projektech je možné vytvořit model architektury nebo návrh vysoké úrovně, aby se zobrazily hlavní komponenty a jejich interakce. Další informace najdete v tématu Modelování architektury vaší aplikace.
V obou případech můžete vytvořit vztah mezi prvky modelu a testy subsystému stejným způsobem jako mezi modelem požadavků a systémovými testy.
Izolace komponent pomocí poskytovaných a požadovaných rozhraní
Je užitečné identifikovat všechny závislosti, které má komponenta na jiných částech systému nebo externích služeb, a znázorňovat je jako povinná rozhraní. Toto cvičení obvykle vede k určitému návrhu, který komponentu výrazně oddělí a snadno oddělí od zbytku návrhu.
Výhodou tohoto oddělení je, že komponentu lze spustit pro testování nahrazením napodobením objektů, které služby obvykle používá. Jedná se o komponenty, které jsou nastavené pro účely testování. Napodobená komponenta poskytuje rozhraní, které vaše komponenta vyžaduje, a odpovídá na dotazy se simulovanými daty. Součásti napodobení tvoří součást kompletního testovacího svazku, který můžete připojit ke všem rozhraním komponenty.
Výhodou testování napodobení je, že můžete vyvíjet komponentu, zatímco ostatní komponenty, jejichž služby budou nadále používat, jsou stále ve vývoji.
Udržování vztahů mezi testy a modelem
V typickém projektu, který provádí iteraci každých několik týdnů, se kontrola požadavků koná na začátku každé iterace. Schůzka popisuje funkce, které se mají doručit v další iteraci. Model požadavků se dá použít k diskuzi o konceptech, scénářích a sekvencích akcí, které se budou vyvíjet. Obchodní účastníci nastavují priority, vývojáři odhadují a testeři zajišťují správné zachycení očekávaného chování jednotlivých funkcí.
Psaní testů je nejúčinnější způsob, jak definovat požadavek, a je to také efektivní způsob, jak zajistit, aby osoba jasně porozuměla tomu, co je potřeba. Zatímco psaní testů trvá příliš dlouho během workshopu specifikace, vytváření modelů lze provádět mnohem rychleji.
Z hlediska testování lze model požadavků považovat za zkratku pro testy. Proto je důležité zachovat vztah mezi testy a modelem v celém projektu.
Připojení testovacích případů k elementům modelu
Pokud váš projekt používá Správce testů, můžete propojit testy s prvky v modelu. Díky tomu můžete rychle najít testy ovlivněné změnou požadavků a sledovat rozsah, ve kterém byl požadavek dosažen.
Testy můžete propojit se všemi druhy prvků. Několik příkladů:
Propojte případ použití s testy, které ho prověří.
Napište klauzule postcondition nebo cíle případu použití do komentářů, které jsou propojené s případem použití, a pak propojte testy s každým komentářem.
Napište invariantní pravidla v komentářích k diagramům tříd nebo diagramům aktivit a propojte je s testy.
Propojte testy s diagramem aktivit nebo s jednotlivými aktivitami.
Propojte sadu testů s komponentou nebo subsystémem, který testuje.
Propojení testů s prvkem modelu nebo relací
Ve Správci testů vytvořte požadavek a založte na ní sadu testů.
Požadavek, který vytvoříte, je pracovní položka na Team Foundation Serveru. V závislosti na šabloně procesu, kterou váš projekt používá se službou Team Foundation, může se jednat o pracovní položku uživatelského scénáře, požadavku nebo případu použití. Další informace naleznete v tématu O agilních nástrojích a agilním řízení projektů.
Propojte pracovní položku požadavku s jedním nebo více prvky v modelu.
V diagramu modelování klikněte pravým tlačítkem myši na prvek, komentář nebo relaci a potom klikněte na odkaz na pracovní položku.
Přidejte do testovací sady testovací případy, které ověřují požadavek vyjádřený v prvku modelu.