Vývoj testů z modelu
V Microsoft Visual Studio Ultimate, architektonické modely a požadavky můžete uspořádat zkoušky systému a jeho součástí.Tato praxe pomáhá zajistit, aby zkušební požadavky, které jsou důležité pro uživatele a další zúčastněné strany a pomáhá při změně požadavky rychle aktualizovat zkoušky.Používáte-li Microsoft Test Manager, můžete také zachovat propojení mezi modely a zkoušky.
Systém a testování subsystému
Testování systému také známé jako testování přijetí, prostředky, testování, zda splnění potřeb uživatelů.Tyto zkoušky jsou obavy o externě viditelné chování systému namísto vnitřní návrhu.
Zkoušky systému jsou velmi cenné při prodloužení nebo přetváří systému.Pomáhají vyhnout se zavádění chyby při změně kódu.
Při plánování jakékoli změny nebo rozšíření systému, je vhodné začít sadu systému testů, které stávající systém.Potom můžete rozšířit nebo upravit zkoušky testovat nové požadavky, měnit kód a znovu spusťte úplnou sadu testů.
Při vývoji nového systému můžete začít vytvářet testy, jakmile začne rozvoje.Definováním testy před vyvinout jednotlivé funkce můžete zachytit požadavky diskuse velmi specifickým způsobem.
Testování subsystému platí stejné zásady pro hlavní součásti systému.Jednotlivé komponenty je testován odděleně od jiných komponent.Podsystém testy fokus na viditelné chování komponenty uživatelského rozhraní nebo rozhraní API.
Další informace o spuštění testů naleznete Testování aplikace.
Vyplývající z modelu požadavky zkoušky systému
Můžete vytvořit a udržovat vztah mezi systému zkoušky a požadavky na model.Chcete-li vytvořit tento vztah zapisovat do hlavní prvky modelu požadavky zkoušky, které odpovídají.Visual Studio Ultimatepomáhá udržovat umožňuje vytvořit propojení mezi testy a součásti modelu tím vztah.Další informace o modelech požadavky, viz Modelování požadavků uživatelů.
.gif "Dd409381.collapse_all(cs-cz,VS.110).gif")
Zápis zkoušky pro každý případ použití
Používáte-li Microsoft Test Manager, můžete vytvořit skupinu testů pro každý případ použití definována v modelu požadavky.Například pokud máte případ použití moučka, která zahrnuje vytvoření objednávky a přidat položku objednávky, objednávky můžete vytvořit testy pro obě celkové a podrobnější těchto případů použití.Další informace o případech použití viz Diagramy případu použití UML: pokyny.
Tyto pokyny mohou být užitečné:
Každý případ použití by měl mít několik testů, hlavní cesty a výjimečných výsledků.
Popíše požadavky modelu případu použití je důležité definovat jeho koncová podmínka, cíle, které je dosaženo než podrobně popisující postupy se řídí uživatel k dosažení cíle.Například může být koncová podmínka objednávky pokrmu, který restaurace připravuje pokrmu pro zákazníka a zákazník zaplatil.Koncová podmínka je kritérium, které by měl ověřit testy.
Základní samostatné zkoušky na zvláštní doložky koncová podmínka.Můžete například vytvořte samostatné zkoušky pro oznamování restaurace objednávky a pro přijímání plateb od zákazníka.Toto oddělení má tyto výhody:
Změny v různých aspektů požadavky dochází často nezávisle.Oddělením zkoušky do různých aspektů tímto způsobem usnadníte aktualizaci zkoušky při změně požadavky.
Pokud plán rozvoje implementuje jeden aspekt případu použití před jiný, můžete povolit zkoušky odděleně v průběhu vývoje.
Při návrhu testy samostatné volby zkušební data z kód nebo skript, který určuje, zda bylo dosaženo koncová podmínka.Test jednoduché aritmetické funkce může být například: vstup 4; Ověřte, zda je výstup 2.Místo toho návrhu skript jako: Zvolte vstup; výstup vynásobte sám a ověřte, zda je výsledek původní vstup.Tento styl umožňuje měnit vstupy test bez změny hlavní zkoušky.
Testy k případům použití propojení
Pokud používáte Test Manager návrhu a spustit testy, můžete uspořádat testy podle požadavku, případ použití nebo uživatel story pracovní položky.Můžete propojit tyto pracovní položky případy použití v modelu.To umožňuje rychle změny trasování požadavky na zkoušky a pomáhá sledovat průběh každého případu použití.
Propojení zkoušky případu použití
V Test Manager, vytvořit požadavek a založit test suite.Další informace naleznete v tématu Vytváření testů pro nevyřízené položky produktu, uživatelské scénáře nebo požadavky.
Je požadavek, který vytvoříte pracovní položky v Team Foundation Server.Může být práce uživatele Story, požadavek nebo případ použití položky v závislosti na šabloně proces používající projektu s Team Foundation.Další informace naleznete v tématu Plánování a sledování projektů.
Požadavek na položku propojte jeden nebo více případů použití v modelu.
V diagramu případu použití, klepněte pravým tlačítkem na případu použití a klepněte na tlačítko odkaz na položku pracovní.Další informace naleznete v tématu Propojení prvků modelu a pracovních položek.
Přidáte test suite, testovacích případů, které ověřují případy použití.
Obvykle bude každý uživatel článek nebo požadavek pracovní položku propojit několik případů použití v modelu a každý případ použití spojí několik článků uživatele nebo požadavky.Je to proto, že každý uživatel článek nebo požadavek zahrnuje sadu úkolů, které rozvíjí několik případů použití.V rané opakování projektu, můžete například vyvinout základní uživatelské textu, v němž zákazník výběr položek z katalogu a bylo dodáno.Článek v pozdější opakování může být, že uživatel zaplatí při dokončení objednávky a dodavatel přijímá peníze po odešle zboží.Každý článek přidá klauzuli koncová podmínka případu použití zboží na objednávce.
Můžete vytvořit samostatné odkazy z požadavků doložek koncová podmínka zápisem těchto doložek v samostatné poznámky v diagramu případu použití.Pracovní položky požadavku propojit jednotlivé komentáře a komentáře propojení v diagramu případu použití.
Základní typy požadavky na zkoušky
Typy, které je, třídy, rozhraní a vyčíslení požadavky modelu popisují koncepty a vztahy z hlediska přemýšlet a o jejich obchodní komunikaci uživatelů.Vylučuje typy týká pouze interní návrhu systému.
Navrhněte testy z hlediska těchto typů požadavků.Tato praxe pomáhá zajistit, že když jsou popsány požadavky na změny, je snadné nezbytné změny v zkoušky se týkají změny.Ji umožňuje diskutovat zkoušek a jejich výsledky určené přímo s koncovým uživatelům a dalšími zúčastněnými stranami.To znamená, že uživatelů potřebuje lze udržovat mimo proces vývoje a zabraňuje neúmyslnému návrh zkoušky kolem možné chyby v návrhu.
Ruční zkoušky pro tato praxe zahrnuje ulpívající na slovník požadavky modelu v testovací skripty.U automatických testů zahrnuje tato praxe pomocí diagramy třídy požadavky jako základ pro testovací kód a vytváření přístupový objekt a updater funkce propojení modelu požadavek kód.
Požadavky, které model může obsahovat například typy nabídky položku nabídky, objednávky a přidružení mezi nimi.Tento model představuje informace, které jsou uloženy a zabývat moučka objednáním systému, ale nepředstavuje složitosti jeho provádění.V systému práce může být několik různých realizations každého typu databáze uživatelských rozhraní a rozhraní API.V distribuovaném systému může být několik variant každé instance uložené v různých částech systému současně.
Otestujete případu použití, například přidat položku objednávky zkušební metody mohou zahrnovat kód podobná této:
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 metoda používá třídy modelu požadavky.Atributy a přidružení jsou realizovány jako.NET vlastnosti.
Chcete-li tuto práci, musí být vlastnosti tříd definována jako funkce jen pro čtení nebo přístupové objekty, jejichž přístup k systému načíst informace o aktuálním stavu.Metody, které simulují případů použití, jako je například AddItemToOrder, musí jednotka systému prostřednictvím jeho API nebo vrstvu pod jeho uživatelské rozhraní.Konstruktory test objektů, například pořadí a MenuItem musí také jednotky systému vytvořit odpovídající položky uvnitř systému.
Mnoho přístupových objektů a aktualizační programy a instalátory budou již k dispozici prostřednictvím rozhraní API normální aplikace.Ale některé další funkce může být zapsáno do zkoušky.Tyto další přístupové objekty a aktualizační programy a instalátory jsou někdy označovány jako "instrumentation test".Protože jsou závislé na vnitřní návrhu systému, je odpovědný, poskytnout vývojářům v systému vzhledem k tomu, že testerům napsat kód zkoušek z hlediska požadavků modelu.
Při zápisu automatických testů můžete obtékat přístupové objekty a aktualizační programy a instalátory obecné testy.Další informace naleznete v tématu Vytvoření automatického testování, která spustí spustitelný soubor pomocí obecné testy.
Zkoušky pro obchodní pravidla
Některé požadavky nesouvisejí přímo s jakékoli jednoho případu použití.Například obchodní DinnerNow umožňuje zákazníkům vybrat z mnoha nabídek, ale vyžaduje, aby v každé objednávce všechny zvolené položky musí být z jedné nabídky.Tato obchodní pravidlo lze vyjádřit invariant o přidružení mezi objednávkami, nabídkami a položek v modelu požadavky třídy.
Výchozí pravidlo tohoto druhu se řídí pouze všechny případy použití, které jsou aktuálně definované, ale také jiné použití případy, které budou stanoveny později.Proto je vhodné zapsat odděleně od jakékoli případu použití a testovat odděleně od případy použití.
Výchozí podnikové můžete zapsat jako komentář v diagramu třídy.Další informace naleznete v tématu Diagramy tříd jazyka UML: pokyny.
Testy můžete propojit obchodní pravidlo propojením komentář požadavku uživatele nebo článku práce položce, které lze propojit test suite v Test Manager.Další informace naleznete v tématu připojení testovacích případů prvky modelu.
Výkon a další jakostní požadavky služby můžete poznamenat poznámky k případu použití činnosti a sekvenční diagramy.Můžete propojit také na požadavky pracovních položek a jejich testování sad.
Sekvence a diagramy činnosti pro zkoušky
Pokud požadavky nebo modely architektury sekvence nebo diagramy činnosti, můžete psát testy, které následují diagramy přímo.
Někdy je užitečné k návrhu testů, které dynamicky zvolit různé cesty prostřednictvím poboček a smyčky v diagramu.
Zkuste ověřit stav systému po každé zprávy nebo akce.To může vyžadovat další služby WMI.
Zkoušky subsystému vyplývající z modelů
Vysoké úrovni návrhu velké systému můžete identifikovat prvků nebo podsystémů.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 rekombinované mnoha způsoby.Další informace naleznete v tématu Diagramy komponent UML: pokyny.
Můžete aplikovat na každou hlavní součást stejné zásady jako kompletní systém.Ve velkém projektu může mít každá součást vlastní požadavky na model.Menší projekty vytvořením Architektonický model nebo podrobný návrh aplikace zobrazit hlavní součásti a jejich interakce.Další informace naleznete v tématu Architektura systému Software pro modelování.
V obou případech lze vytvořit vztah mezi prvky modelu a zkoušky subsystému stejným způsobem stejně jako mezi modelu požadavky a zkoušky systému.
Izolovat součásti poskytované a požadované rozhraní
Je užitečné pro identifikaci všech závislostí, které má součást na jiných částech systému nebo externí služby a představují jako požadované rozhraní.Toto cvičení je obvykle vede k některé vzhled, který opustí mnohem více oddělenému a snadno oddělitelné součásti ze zbývající části návrhu.
Výhodou tohoto oddělení je, že komponenty mohou být provedeny pro testování nahrazením mock objekty služby, které obvykle používá.Jsou komponenty, které jsou nastaveny pro účely testování.Mock součást poskytuje rozhraní, které komponenta vyžaduje reagovat na dotazy simulované daty.Mock součásti součástí kompletní testovací vodiče, se můžete připojit k rozhraní komponenty.
Výhodou mock testování je vytvoření komponenta a komponenty, jejichž služby bude používat jsou stále ve vývoji.
Udržovat vztahy mezi testy a Model
V typickém projektu, který provádí iteraci každých několik týdnů je držena přezkoumání požadavků na začátku každé iteraci.Schůzky popisuje funkce, které mají být dodány v další opakování.Požadavky modelu lze pomoci diskutovat, koncepty, scénáře a sekvence akcí, které budou vypracovány.Zúčastněné strany obchodní nastavit priority, vývojáři provést odhady a testerům zajistit že správně digitalizováno očekávané chování jednotlivé funkce.
Psaní testů je nejúčinnějším způsobem definovat požadavek a je také účinný způsob, jak zajistit, aby osoba jasně chápali, co je potřeba.Ale vzhledem k tomu, že písemné zkoušky trvá příliš dlouho provést během dílny specifikace, vytváření modelů lze provést rychleji.
Z testování pohledu požadavky modelu lze vnímat jako zkratky pro zkoušky.Proto je důležité zachovat vztah mezi testy a model v celém projektu.
Testování připojení k prvky modelu
Pokud projekt používá Test Manager, zkoušky na prvky lze propojit v modelu.Umožňuje rychle najít zkoušky ovlivněny změnou v požadavcích a usnadňuje sledování míry, do které byl proveden požadavek.
Testy můžete propojit všechny druhy prvek.Zde jsou některé příklady:
Zkoušky, které ji vykonávají propojte případu použití.
Zápis doložky koncová podmínka případu použití, nebo cíl na poznámky, které jsou propojeny k případu použití a zkoušky propojit jednotlivé komentáře.
Výchozí pravidla psát komentáře třídy diagramy nebo diagramy činnosti a propojit je s testy.
Diagram činnosti nebo činnosti jednotlivých propojení zkoušky.
Součást nebo podsystém, který testuje propojte testovací sady.
Propojení zkoušky prvek modelu nebo vztah
V Test Manager, vytvořit požadavek a založit test suite.Další informace naleznete v tématu Vytváření testů pro nevyřízené položky produktu, uživatelské scénáře nebo požadavky.
Je požadavek, který vytvoříte pracovní položky v Team Foundation Server.Může být práce uživatele Story, požadavek nebo případ použití položky v závislosti na šabloně proces používající projektu s Team Foundation.Další informace naleznete v tématu Plánování a sledování projektů.
Požadavek na položku propojte jeden nebo více prvků v modelu.
V diagramu modelu prvku, komentáře nebo relace klepněte pravým tlačítkem myši a klepněte na tlačítko odkaz na položku pracovní.Další informace naleznete v tématu Propojení prvků modelu a pracovních položek.
Přidáte test suite, testovacích případů, které ověřují požadavky vyjádřené v prvku modelu.
Viz také
Koncepty
Vývoj modelů pro návrh softwaru
Modelování požadavků uživatelů