Test včas a často

Zachycení vady co nejdříve je nejlevnější způsob, jak zajistit kvalitu softwaru.Kent Beck a Cynthia Andresu napsali "zde při vývoji softwaru je dilemma: vady jsou nákladné, ale odstranění vady je také nákladné.Ale většina vady skončit ocenění více, než by být náklady jim zabránit." (Vysvětlit extrémní programování: Změna funkcí) Doporučené postupy a nástroje mohou pomoci týmu minimalizovat náklady na předcházení a odstraňování závad udržováním kvality projektu po celou dobu jeho životního cyklu.

Váš tým můžete přesněji odhadnout kvalitu projektu kdykoli Pokud vyhledání vady, opravit vady a ověřit opravy, které budou následovat.Otestováním často, můžete týmu a zúčastněné strany informován o aktuálním stavu kódu a rozhodování v celém projektu.Nakonec by měl být schopen odpovědět na otázku "Jsme uvolnit?" a pochopit důsledky pro uživatele, kteří používají software.

Toto téma se doporučuje následující postupy:

• Vytvořte sadu testů automatizované jednotky pro jednotlivé třídy a rozhraní API pro každý hlavní součásti.Psaní testů jednotky by měly přijmout asi 40 % času členy týmu.Další informace naleznete v tématu Vytváření automatizovaných testů pomocí nástroje Microsoft Test Manager.

• Vytvořte testy pro každého příběhu uživatele.Ty by měla pokud možno automatizován.Další informace naleznete v tématu Vytváření testů pro nevyřízené položky produktu, uživatelské scénáře nebo požadavky.

• Vytvoření zásad kontroly, které připomenout členům týmu, chcete-li spustit testy jednotky před kontrolou v kódu.Další informace naleznete v tématu Add Check-in Policies.

• Nastavte průběžné nebo noční sestavení, která se spouští úplnou sadu testů.

• Sledování pokrytí testu k zajištění, že váš kód je testován.Cílem pro pokrytí nejméně 70 %.Další informace naleznete v tématu Testování sestavu aplikace Excel mezery (agilní).

• Spuštění ručních testů téměř na konci každého období.

Váš tým může správu a rozšiřování těchto testování aktivit v rané fázi projektu pomocí integrace mezi Microsoft Test Manager, Visual Studio Application Lifecycle Management (ALM), a Visual Studio Team Foundation Server.Další informace naleznete v tématu Testování aplikace.

V tomto tématu

• Testovací strategie

• Plánování testu

• Testování přijetí

• Testování částí

• Test-Driven Development a brzy Test

• Ruční a automatické testování

• Vykazování výsledků testování

Testovací strategie

Úspěch vašeho týmu s testováním závisí na několika faktorech, které zahrnují velikost vašeho týmu, váš tým metod a nástrojů pro správu vašeho týmu.Agilní metody můžete nepřetržitě zlepšovat výsledky testů.Použitím této metody pouze můžete spustit test s velmi omezenými zdroji, ale také upravit své praxe podle potřeby v celém projektu.

Co je třeba vzít v úvahu při zavádění agilní testování

Při zavádění, agilní testování do existující aplikace, váš tým spustit přemýšlení testovací strategie na úrovni sprint i úrovni projektu.Na úrovni sprint může obsahovat sadu přejímacích zkoušek pro pokrytí každého příběhu uživatele z aktuálního období.Na úrovni projektu máte zkoušky, zahrnující celý projekt, jako je testování na začátku do konce.To je užitečné, pokud chcete ověřit fungování, zasahující do dvou nebo více obdobích.Zatímco tým vytvoří kód během sprint, můžete vytvořit všechny druhy zkoušek.Tyto zkoušky zahrnují testování částí přejímacích zkoušek a funkční testy, jako jsou testy výkonu, zabezpečení zkoušky a testy použitelnosti.

Chcete-li použít agilní metody zkoušení, nejprve zvažte historie aplikace a systém, který používá váš tým.Použijete-li agilní metody zkoušení nových i existujících aplikací.Můžete použít Microsoft Test Manager Chcete-li vytvořit plán testování pro celý projekt a plán testování pro každý sprint v projektu.Tyto zkoušky plány umožňují týmu uspořádání testových případů do sady testů, které pomáhají určit prioritu provozní zkoušky a porozumět výsledky testů.Další informace naleznete v tématu Vytváření testů pro nevyřízené položky produktu, uživatelské scénáře nebo požadavky.Váš tým může používat Visual Studio ALM do skupiny testových případů do testových sad prostřednictvím několika způsoby:

• Vytváření a správa statická skupina testových případů.

• Použití dotazu k vytvoření a správě dynamické skupiny testových případů (to znamená najít testových případů na základě priority).

• Přidání do testového plánu, kde testových případů mají požadavek příběhu uživatele nebo požadavku.

• Kopírování existujícího testové sady z jiného testového plánu.

Další informace naleznete v tématu Uspořádání pomocí testování sad testovacích případů.

Za druhé je třeba zvážit Driven váš kód.Další informace, je třeba porozumět architektura a trendy aplikace.Používáte-li vzorky jako Model View Controller (MVC), Model zobrazení ViewModel (MVVM) nebo modelu zobrazení předvádějícího (MVP), můžete izolovat určité funkce a spusťte funkční testy bez negativní dopad testování pro uživatelské rozhraní.Ale to není vždy představují reálný případ.Například nelze izolovat funkcí refaktoringu částí aplikace a některé oblasti kód pouze prostřednictvím tohoto uživatele lze dosáhnout obslužné rutiny událostí rozhraní nebo sítě.Pokud chcete výrazně zlepšit kvalitu testu, musí zvýšit podíl lze kód.Další informace o těchto vzorků, viz ASP.NET Model View Controller (MVC).

Za třetí je nutné zvážit možnosti vašeho týmu před zavedením agilní testování.Někteří členové týmu by měla být schopen vytvořit jednotku zkoušky při provádění funkce.Někteří členové týmu měli být schopni vytvořit a definovat případy použití ruční a pracovní postup zkoušky, je-li se seznámit s obchodními pravidly aplikace.Ostatní členové týmu je navíc mohly vytvořit automatizované a podrobnější testy, které jsou založeny na těchto ručních testů, pokud mají potřebné odborné dovednosti.

Správa životního cyklu pro testování

Testování je iterativní proces v celém projektu.Odkažte na následující kroky:

1. Proveďte jasně vymezené cíle testování a ujistěte se, že celý tým souhlasí, že na ně.V závislosti na těchto cílů, určete strategii test.Strategie může být například "testy budou spuštěny před všech vrácení se změnami, testování částí bude mít Průchod kódem 70 % a každý příběh uživatele bude mít alespoň jeden automatického testování."

2. Definujte plán testování na základě projektu příběhy uživatelů, předpoklady návrhu a funkční požadavky v aktuálním období.

   1. Můžete přidat příběhy uživatelů nevyřízené položky a jejich plánování budoucích obdobích.By měl odpovídat každý plán testování pro alespoň jeden sprint a má proto testových případů pro všechny uživatele texty v období.

3. Definování a vytváření testových případů, jako je například přejímacích zkoušek, testování částí, funkčních zkoušek a testů výkonnosti.

4. Skupina testových případů do testových sad.Můžete přizpůsobit tyto testovací sady do definovaných zkušebních plánů, které pomohou nalézt testového úsilí.

5. Spustit testových sad a obsažené testových případů opakovaně po celou dobu sprint.Start spustit testy v rané fázi sprint a pokračujte v přidávání testových případů do sady testů.Pokud chcete určit důležité zkušebních podmínek a situací, můžete použít průzkumné testování a časté konverzovat uvnitř týmu.

6. Zajistěte, aby všechny testy použitelnosti pro příběh uživatele prošly před nastaví svůj stav na dokončení.

Ačkoli pracovní postup může být mnohem komplikovanější podle rozpisu software, na předchozím obrázku zachycuje podstatu mezi hlavní součásti pracovního postupu.

• Kód generuje sestavení.

• Kód je ovlivněno definované pracovní plány pro testování a kvality sestavení.

• Plány pro testování a testování sad testových případů jsou ovlivněny plánovaných cílů a další aspekty projektu, který není uveden na obrázku.

• Změny v kódu může ovlivnit testových případů.

Oprava chyb

1. Je třeba řešit chyby co nejdříve.Závažné chyby znamená, že příběhy uživatelů, které budou ovlivněny nebyly dokončeny.

2. Vytvořte pracovní položky chyb pro chyby nalezené pomocí testování nebo jiné činnosti.Nastavení závažnosti chyby označuje míru, do které ovlivňuje příběhy uživatelů.Vysoká závažnost, například 0 nebo 1, označuje, že nejsou implementována příběhy důležité uživatelů nebo že musí provést významné řešení k dosažení textu.Nízký stupeň závažnosti, například 3, označuje uživatele lze dosáhnout i jejich hlavní cíle bez práce navíc.

3. Spolupracovat s ostatními ve vašem týmu rozhodnout o akčním plánu pro každou chybu.

4. Chyby vyřešte, jako je opravit.Chyb by měl být přiřazen k jiné osobě ověřit.Ověřte a chyby co nejdříve zavřít.

5. Sledovat stav chyby.Následného zasedání na konci každé iteraci prohlédnout sestavu trendů chyb a diskutovat o důvodech pro jakékoli neobvyklé zvýšení.Další informace naleznete v tématu Ohlášení trendů.

Plánování testu

Plánování testu je proces pomoci týmu pochopit velký obrázek vašeho projektu a procesu přípravy tým pro testování všech druhů.Agilní testování začíná období úrovně.V každém sprint tým vytvoří testy a ověřte příběhy uživatelů, které byly vytvořeny v tomto sprint.Tým spustí testy, které byly vytvořeny v aktuální a předchozí obdobích.Až v průběhu projektu velký počet zkoušek jsou sestaveny pokrývající všechny funkce.Následující ilustrace ukazuje šablonu pro plány pro testování v projektu.

Vytvořit plán testování pro každé období a pro projekt

Pomocí testování funkcí Visual Studio ALM, váš tým může postupně plánování, uspořádání, spustit a sestava testuje.Váš tým můžete vytvořit šablonu pro plány pro testování a členům týmu můžete vyplnit testových sad.V testovém plánu lze identifikovat váš tým, kde byste měli použít automatické nebo ruční testových případů.

Pro každý sprint v projektu může zahájit vytvořit plán testování.Pomocí tohoto plánu tým zaměřit na ověření funkčnosti v aktuálním období.Ačkoli plán je prázdný na začátku, můžete ho také jako zástupný symbol pro testování sad.Potom můžete uspořádat testových případů do příslušné testových sad.Pokud chcete získat včas zpětnou vazbu od zúčastněných stran projektu byste měli vytvořit tyto testových případů předčasného a po celou dobu sprint.

Můžete také vytvořit plán testování, které pokrývá celý projekt.Plány pro testování projektu můžete použít funkce coalesce testy z předchozích obdobích a uspořádání testových sad, které se vztahují k celému projektu.Měli byste nadále spustit regresní testování sad, protože je důležité zachovat stabilitu a toku, pokud váš tým vytvoří větší projekty.Zejména v případě, že pracujete s větší a distribuované týmy, které postrádají blízkost, může zachytit testových sad regresní chyby, které jsou založeny na změny, které mají dopady na CSS.Bez správné opatření na místě tyto chyby jsou velmi obtížné zachytit a může být zachycena pozdě v cyklu nebo po dodání.

Některé týmy mohou chtít definovat plán testování, která pokrývá celý projekt.Tyto druhy plány pro testování může ověřit související funkce v mnoha obdobích a obsahují testových sad, které běží v celém projektu.Například můžete otestovat funkci, která pokrývá příběhy uživatelů v rámci období nevyvážené pouze po dokončení celé funkce.

Definovat přejímacích zkoušek před sprint

Měli byste definovat přejímacích zkoušek před sprint.Tyto testy použitelnosti můžete určit, zda je celý příběh uživatele.Přijetí testových případů můžete sledovat, je-li vytvořit testové sadě s názvem přejímacích zkoušek v testovém plánu pro každé období.Další informace naleznete v tématu Testování přijetí dále v tomto tématu.

Vytvoření jednotky testy během sprint

Váš tým by měl sestavit testování částí během sprint.Testování částí můžete ověřit kód výkonu, například náklady na čas a prostředky, které slouží ke spuštění kódu.Jiných typů testů, jako je například funkční testy (to znamená, že testy výkonu a zabezpečení) by sestavena a přidán do příslušné testových sad.Uspořádejte tyto testovací sady, takže lze snadno identifikovat jejich nákladů.

Testování v oblastech vysoké použití fokus

Principy, kde existuje vysoké variability software Určuje, kde může být aktivní body.Uživatelský vstup, prostředí, které spustí software, sítě a hardware jsou proměnné konfigurace, které umožňují týmu pro zjišťování aktivních oblastí v softwaru.Pokud existuje convoluted několik podmínek, které mohou nastat při zkoušce podmínku dochází zřídka, nesnižuje hodnotu testu s tím rozdílem, že potenciální dopad vadu je velmi vysoká.Izolace funkce obecně je žádoucí, pokud je to možné.Důležité jsou také testování situacích velký ohlas.Další informace o správě konfigurací pomocí Microsoft Test Manager, viz Konfigurace testů – určení testovacích platforem.

Existující projekty sledujte v oblastech, které mají nejvyšší počet závad a zjistit, proč existují vady.Také sledujte změny v kódu, protože tato oblast může přehlédnout základních předpokladů.Některé důvody pro kód vady patří potíže správy nejen státy (například sítě a uživatelské rozhraní), ale také kód.

Testování přijetí

Přejímacích zkoušek ověřit příběhy uživatelů.Tyto zkoušky nemohou zajistit pouze úspěšně vytvořit co vaši zákazníci potřebují po celou dobu životního cyklu projektu, ale také vytvořit vztah důvěryhodnosti se zákazníky a zobrazit přijaté zodpovědnosti.Další informace naleznete na následující webové stránce: Engineering Příručka pro přijetí Test.

Jak začít s testováním přijetí

Otevřít Microsoft Test Managera pak vytvořte testové sadě s názvem přejímacích zkoušek v plánu.Váš tým by měl mít alespoň jednu sadu test seskupující přejímacích zkoušek pro každé období. Další informace naleznete v tématu Definice testovacího plánu.

Migrace z ručních testů pro automatické testy

Ruční testy jsou nákladnější, ale jednodušší je definovat než automatických testů.Je proto vhodné strategie začínají ručních testů a postupně nahradit důležitější z nich s automatickými testy.

Nejprve spusťte vytvoření množiny ruční testových případů, které ověřují každý příběh uživatele, který byl definován pro období.Protože neexistuje žádný kód na začátku sprint, testového případu by měly obsahovat vysoké úrovně akce, které mapují částí příběhu uživatele.Krok v případě testu může být například "jako ověřený uživatel..." Počínaje ručního testového případu umožňuje týmu rychle definovat ideální přejímacích zkoušek, než začne sprint.

Za druhé revizi a aktualizaci přejímacích zkoušek tak, aby odrážely určitého uživatelského prostředí, pokud váš tým má kód, který implementuje příběhy uživatelů sprint.Však pokud váš tým nechce upravit existující sady přejímacích zkoušek, můžete importovat do nové testové sady testů a počáteční bod pro podrobnější testy.Krok v podrobnější testového případu může být například "Zadejte název do textového pole uživatelské jméno a klikněte na tlačítko přihlášení a přihlásit do bankovního účtu."

Za třetí založené na přejímacích zkoušek, vytvořte kódované uživatelské rozhraní (UI) zkoušky pomocí záznamu akce.Další informace naleznete v tématu Vygenerování programového testu uživatelského rozhraní ze stávajícího záznamu akcí.Kódované testy uživatelského rozhraní může generovat kód čištění, je-li vytvořit kroky, které izolovat funkce.Připojit kódované testovací uživatelské rozhraní pro ruční testových případů spuštění automatických testů z testovací plán (Další informace naleznete v tématu Jak: přidružit automatického testování testovacího případu.)

Ruční testy, které byly definovány na začátku sprint vám může pomoci vytvořit automatizované testy.Nejsou náklady na ruční i automatické testy, protože ruční testy musejí být spuštěny osobou a automatickými testy musejí být aktualizovány, pokud kód nebo uživatelské změny.Další informace naleznete v tématu Ruční vs automatického testování dále v tomto tématu.

Kdo spustí testových případů přijetí?

Přijetí testových případů lze spustit váš tým, vlastník vašeho produktu a zákazníky.Váš tým by měl spustit co nejvíce, jsou základem na sadu testů, které je třeba předat sprint.Vlastník produktu a zákazníka můžete také spustit testy použitelnosti a může vyžadovat ověření k úspěšnému dokončení období.

Váš tým může používat Microsoft Test Manager ke spuštění každý přijetí testového případu a zaznamenání digitalizace videa obrazovky s výsledky zkoušek.Tímto způsobem můžete získat vizuální záznam výsledků zkoušek a výsledky můžete také sdílet se svými zákazníky.To je užitečné v případě, že je obtížné vytvořit požadované konfigurace (například víceserverové konfigurace).

Definovat přijetí testových případů spolu s příběhy uživatelů

Po definování příběhy uživatelů, můžete definovat právo kritéria přijetí.Definováním přejímacích zkoušek může pomoci týmu pochopit kritéria přijatelnosti pro aktuální sprint od vlastníka výrobku a zákazníky.Protože zákazník musí souhlasit s přejímacích zkoušek, je vhodné vytvořit přijetí testových případů, než začne období.

Testování částí

Testování částí jsou automatizované testy, které ověřují funkce na úrovni komponenty, třída, metoda nebo vlastnost.Testování částí jsou základem automatizované a regresní testování, který poskytuje dlouhodobé stability a budoucí udržovatelnost projektu.

Jak jednotky testy pomáhají vyvíjet návrhové aplikaci?

Proces vytvoření jednotky testy při budování testované kód pomáhá definovat tvar kódu.Můžete vytvořit kód, který je lze pomocí testování částí.Potíže při vytváření testování částí kódu je znak, že kód by měl být refactored.

Jak uspořádat Moje testování částí

Každý člen týmu, který zapíše kód vytvořit testování částí pro komponenty, že sestavení a kontrola jednotky testování kódu do verze ovládacího prvku uvnitř Visual Studio projektu.Pracovní položky testového případu souborů do testové sady ověřování sestavení, která se spustí při každém sestavení prostřednictvím nepřetržité integrace a také v testové sadě, která ověří odpovídající příběhu uživatele.

Jak spravovat odchylka testování částí bez nutnosti změny kódu test?

Odchylka v testovací vstupy definuje podobnosti a rozdíly mezi zkouškami ověřuje funkce v kódu projektu.Při testování komponenty přihlašovací webovou aplikaci, je zadat několik typů hesel, chcete-li vytvořit uživatelský účet.Systém může mít pravidla pro kombinaci typů znaků, které se používají a objednávky.

Testovací aplikace Visual Studio Professional poskytuje funkce pro zápis zkoušky jednotky řízené daty a kódované testy uživatelského rozhraní.Další informace naleznete v tématu Jak: vytvoření test jednotky řízené daty a Jak: vytvoření Test řízené daty kódované uživatelského rozhraní.

Test-Driven vývoje a testování brzy

Test-driven development (TDD) je disciplína návrhu a programování, kde každý řádek kódu je zapsán v reakci na test, který programátor píše těsně před kódování.Myšlenka stává spotřebitele kód, který chcete implementovat velmi výkonné a realistická očekávání, jak by kód použit a určen.

V TDD vývojář pracuje mnoho malých úsecích.Vývoj každý malý přírůstek trvá několik minut až několik hodin.Mnoho těchto krocích obvykle tvoří příběh uživatele.Vývojář změnami zkoušek a kód při příběhu uživatele funguje.Vývojář pracuje v následujícím cyklu:

1. Zápis automatizovaný test, který by měl předat při zápisu přírůstek.

2. Ověřte, že nový test nezdaří směřujících k zajištění, že test funguje.

3. Napište kód, který provede test předat.

4. Spusťte test Chcete-li ověřit, že uspěje.

5. Také můžete spusťte všechny testy v téže oblasti, ujistěte se, že byly zavedeny žádné chyby.

6. Refaktorovat kódu, v případě potřeby zvýšit její strukturu bez přidání chování.Spusťte testy, abyste se ujistili, že kód stále funguje.

7. Všechny tyto kroky opakujte, dokud příběhu uživatele úplnou novinkou.Jako předchozí přírůstky jsou integrovány do úplný text, přidáte testy, které ověřují celý článek.

8. Provádění kódu a jednotky testy se změnami.

Pokud vás zajímají výhody včasné zkušební metody, můžete spustit tak, že vytvoříte ručně (nebo ruční akceptaci) zkoušky.Tyto ruční testy lze automatizovat vytvořením kódované test uživatelského rozhraní.(Další informace naleznete v tématu Jak: nahrávání aplikací zkoušené vygenerovat Test kódované uživatelského rozhraní.) Zkoušky integrace, které používají jednotky testování rámec v Visual Studio ALM je také možné vytvořit ověřte funkčnost, která je prováděna.Skupiny testových případů, které jsou vytvořeny v rané fázi iterace jsou spuštěny v rané fázi opakování při pokusu najít chyby ověřte funkčnost i.Tyto série zkoušek a testových případů lze průběžně spustit jako regresní testy v průběhu projektu.Pokračuje spustit tyto testy, pomůžete zajistit, že chyby, které nebyly nalezeny a funkce, která byla ověřena v rané fázi iterace nejsou ovlivněny změny v projektu.

Testování částí použití pro nepřetržité integrace

Testování částí, které jsou vytvořeny při použití předčasného zkušební praxe by uspořádány v testové sadě pro aktuální text sprint a uživatele.Tyto testy jednotky lze povýšen na plán testování celého projektu a pravidelné spouštění týmem a uvnitř cyklu Nepřetržitá integrace.Testování částí může také sloužit jako základ pro integraci, zatížení a testování výkonu.

Testování částí, které jsou vytvořeny při zahájení lze použít jako součást Nepřetržitá integrace.Další informace o tom, jak spustit testy během sestavení naleznete v tématu TestToolsTask Task.

Virtualizace slouží ke správě testových konfigurací

Chcete-li spustit testy jednotky, můžete vytvořit sadu prostředí, které jsou spravované technologií Hyper-V obrázky v Microsoft Test Manager. Další informace o způsobu spuštění automatických testů z testovací plán pomocí Microsoft Test Manager, viz Jak: automatické spuštění testů v laboratorním prostředí pomocí Správce Microsoft Test.

Ruční a automatické testování

Automatické a ruční testových případů vzájemně doplňují.Agilní týmy se snažit máte více automatizované testových případů, protože mohou podporovat časté nebo kontinuální testu.Nepřetržitě spustit testy, se musí provést rychle a často, což je obtížné dosáhnout s ruční testování.

Existují různé přístupy, které by měly být při rozhodování o rozdělení ruční a automatické testových případů.

Jak ovlivnit dovednosti ve vaší organizaci vaší distribuce typy testů?

Vlastník produktu pomáhá definovat příběhy uživatelů pro projekt a by měl také přispívat k vytváření přejímacích zkoušek.Vlastník produktu nebude pravděpodobně vyrábějící kódované testy, ale bude mít významné poznatky o obchodní domény.Testových případů, které jsou definovány vlastníkem produktu, proto budou na úrovni obchodní slovník a obchodní pravidla.Vlastník produktu v námořní společnosti bude například určit různé způsoby přepravy, které jsou podporovány v zaměstnání (například nákladní automobil, vlak, vzduchu, moře nebo kombinace).Vlastník produktu pak můžete definovat několik testových případů, které vykonávají různé možnosti.Tyto ruční testy je důležité určit minimální počet zkoušek, které vykonávají různé možnosti (v tomto případě znamená lodní dopravy).

Členové týmu, kteří vyrábějí kódu můžete sestavit kódované testy uživatelského rozhraní, které mohou být podle ručních testů nebo nezávislé na jakýkoli jiný test.Další informace naleznete v tématu How to: Generate a Coded UI Test by Recording the Application Under Test.Členové týmu, kteří mají schopnost spravovat a rozvíjet kód projektu musí podporovat kódované testy uživatelského rozhraní.

Při měla převést ruční testy automatických testů nebo vytvořit automatických testů od začátku?

Když budete chtít spustit testy opakovaně k udržení stability vašeho kódu, můžete vytvořit automatizované testy.Je důležité vzít v úvahu úsilí o vytváření automatických testů, protože investiční automatizace ovlivňuje zdroje týmu.Vytváření automatických testů, pokud kód má málo konve výsledky ve vyšší návratnost investic (ROI), protože je méně konve test.Při vytváření automatizace brzy, protože vám pomůže zjistit problémy v logice a návrhu je však hodnota.V obou případech musí považovat za prostředky, které jsou požadovány pro podporu automatického testování kódu.

Jakmile se rozhodnete, že musí být automatizován sadu testů, přesunete co nejdříve dokončit automatizace, protože výhody automatizace zahrnují správu stability kód.Úsilí, které je vyžadováno k dokončení automatizace ovlivní stabilitu a počet závad, které se nacházejí, jak je napsána automatizace.Nakonec rovnováhu mezi Ruční a automatické testy je o stanovení priority druhy zkoušek, které jsou nutné k vytvoření a spuštění během životnosti projektu.

Jaké typy testů jsou automatizovaná?

Testování částí

Testování částí ověřte funkčnost v kódu nebo prostřednictvím procesu, jako je například TDD.Testování částí jsou důležité, protože pomáhají udržovat stabilitu a závislosti do kódu.TDD také tendenci vyrábět lepší konstrukce se závislostí a definice funkční vrstvy, protože usnadňuje pochopení návrhu z hlediska spotřebitele kódu.

Zatížení zkoušky

Můžete vytvořit zatížení testy, které jsou založeny na existujících automatizovaných testových případů nebo můžete vytvořit testy, které generují určité typy zatížení aplikací nebo služeb.Další informace o tom, jak používat test agent řadiče a testování agenti pro generování simulované testování zatížení, viz Postup: Spusťte Test pomocí řadiče zkouška a zkouška agenti.

Další informace o testování zatížení s Visual Studio ALM, naleznete na následující stránce na webu společnosti Microsoft: Principy testů pro načtení.

Zkoušky nepřetržité integrace

Nepřetržitá integrace s použitím Visual Studio ALM Chcete-li zajistit, že vždy, když kód je rozvíjet a změnami, pracuje správně s existujícím kódem.Nepřetržitá integrace je důležité jako váš tým a zvětšuje se základním kódu.Můžete definovat typ sestavení, která zahrnuje testování parametrů a určit, který testuje spustit po dokončení sestavení.Další informace o způsobu definování sestavení, který spustí testy, viz Definovat proces vytváření, který je založen na výchozí šabloně.

Typy testů, které je možné automatické?

Testování konfigurace

Testování v prostředí s více nainstalovaných může být velice pracný úkol.Microsoft Test Managerposkytuje možnosti spuštění testových sad na různé konfigurace virtuálních počítačů nebo fyzických počítačů.Další informace o tom, jak spustit testy a shromažďování dat v prostředí s více, viz Nastavení stroje Test spustit testy nebo shromažďovat Data.

Testy uživatelského rozhraní

Visual Studio ALMmá funkce vytváření automatických testů přímo pro uživatelské rozhraní.Další informace o tom, jak vytvořit testy kódované uživatelské rozhraní, viz Jak: vytvoření Test kódované uživatelského rozhraní.

Instalace zkoušky

Můžete využít možnosti laboratoře Microsoft Test Manager Chcete-li nastavit skupinu konfigurace, které lze použít k ověření, zda instalační programy pro vaše aplikace fungovat očekávaným způsobem.

Jaké jsou překážky automatizace?

Schopnosti týmu

Vytvoření automatizace vyžaduje podmnožinu test team-li se naučit psát kód.Plán zmocněna Křivka osvojování znalostí tvorby automatizace a návrh zkušebního předpisu.Podobně jako kód výroby, návrh automatizace kód požadovaného cíle, jako je například udržovatelnost, snadné složení a dlouhověkosti.

Další informace o tom, jak pomocí aplikace Visual Studio Test Professional vytvořit automatizované testy naleznete v tématu Vytváření automatizovaných testů pomocí nástroje Microsoft Test Manager.

Změny v kódu

Kód, který se často mění je přesunutí cílové a budou mít kaskádové efekty do kódu test automatizace, protože bude také nutné změnit.Vyhněte se tyto efekty CSS vytvořením test automatizace kód pro komponenty a rozhraní, které jsou méně pravděpodobné, že změna.

Kód návrhu

Kód rámců, jako je například technologie ASP.NET MVC a MVVM pomohou členové týmu mohli psát kód, který má izolace, která je povinna ověřit různé části kódu.Kód, který je pevně vázán na uživatelské rozhraní je obtížné testovat, protože může vyžadovat uživatel interaktivně pracovat s uživatelskými ovládacími prvky rozhraní.

Jaké jsou výhody ruční testových případů?

Ruční testových případů nabízejí následující výhody:

• Ruční testy pomohou váš tým najít chyby v procesu průzkum.

• Ruční testových případů lze snadno definovat, protože můžete definovat sadu kroků na jakékoliv abstrakce a v jakýchkoli podmínek, které chcete definovat úspěch a neúspěch.

• Je velmi snadné začít psát ruční testových případů v rané fázi projektu před napsal jakýkoli kód.To je důležité při definování přejímacích zkoušek.

• Pokud používáte Visual Studio Professional otestovat, testových případů může být tvořen sdílených kroků, které pomáhají šetřit čas při definování podobné testy a umožňují týmu znovu použít jednu verzi dílčí zkoušky.Použití sdílených kroků také pomáhá při změně testových případů, protože změna sdílených kroků se automaticky změní všechny testových případů, které používají sdílených kroků.Další informace o vytvoření a použití sdílených kroků v tématuHow to: Share Common Test Case Steps Using Shared Steps

• Ruční testových případů může sloužit jako prostředek pro včasné komunikace v projektu nebo sprint.

• Ruční testových případů může sloužit jako prostředek k dokumentování automatizované testového případu bez kdokoli, kdo kód.

• Použijete-li Visual Studio ALM, spuštění ručních testů můžete získat kód disponibility metriky.

Co jsou schodků veřejných financí ruční testových případů?

Ruční testových případů provést následující schodků veřejných financí:

• Definování kritéria úspěchu může být složité, protože je závislý na perspektivy a jazyk, který je použit v definici zkoušky.Některých jazyků lze interpretovat odlišně a který nesmí opustit prostor pro chyby.

• Spuštění sady testů, které zahrnují ruční testových případů vyžaduje osoby fyzicky sledovat kroky testu a výsledky sestavy.Tento proces může spotřebovat s velkým množstvím času a proto mohou vyžadovat zvýšený počet členů týmu k provedení zkoušek nebo zvýšené časový úsek pro spuštění testové sady.Pomocí Visual Studio Professional testování týmu můžete použít "fast forward ruční testování," v akce, které jsou zaznamenány během testování, které lze poté spustit v budoucnu zkušební jízdy.

• V závislosti na stabilitu kód se budou lišit čas a námahu, který je vyžadován pro spuštění testů.Spuštění ručních testů v důsledku toho může ovlivnit tok v týmu.

• Největší schodek je, že ruční testy jsou náchylné k lidské chyby při zjištění chyby.Testeři mohou zobrazit chyby před jejich oči a nelze rozpoznat.

Jaké jsou výhody automatizované testových případů?

Automatizované testových případů nabízejí následující výhody:

• Automatizované testy pomáhají udržovat stabilitu a vám pomohou najít nevýhody, se kterými může dojít z důvodu změn kódů.

• Automatické testy můžete spustit bezobslužnou instalaci.

• Automatických testů jsou software a lze navržen a je složený z jiných opakovaně použitelný kód.Díky automatické testy, flexibilní a údržba.

• Automatizace lze spustit na více konfigurací pomocí Microsoft Test Manager.

• Při spuštění automatických testů je možné sbírat kód disponibility metriky.

Co jsou schodků veřejných financí automatizované testových případů?

Automatizované testových případů provést následující schodků veřejných financí:

• Zvláštní podmínky musí být zváženy a implementovány pomocí kódu.Automatizace je vytvořen a běhu, další podmínky budou implementovány jako jsou zjištěny.

• V případě, že kód je změněn nebo refactored, může být kaskádové efekty, které vyžaduje odpovídající úsilí, chcete-li změnit ohrožený automatických testů.

• Může být psychologický dopad na váš tým při změny kódu způsobit mnoho testy selhání.Je-li tyto testy se používají jako příznaky, týmu nebudete chtít vyvolat žádné příznaky.

• Může být falešný pocit jistoty v případě, že všechny testy úspěšné, pokud nejsou správné podmínky zkoušení testových případů.Je důležité udržovat testových sad a zajistit, že jejich ověřit správné podmínky a výsledky.

Vykazování výsledků testování

Z agilní perspektivy, sestav a zadávání dotazů Team Foundation Server pro aktuální stav kvality na základě chyby nebo agregační metriky je část smyčky zpětné vazby, která umožňuje týmu iterovat a upravte kód, plán projektu a plán testování.Další informace naleznete v tématu Plán průběhu zkoušce.

Průběhu testového plánu můžete sledovat také pomocí testovací plán výsledky funkce v aplikaci Microsoft Test Manager.Výsledky zkoušek plánu zahrnují grafy a číselné statistiky na předán testy se nezdařily a aktivní.Navíc výsledky testů plánu zahrnout podrobné grafy zobrazující typů selhání a rozlišení dat.Výsledky zkoušek plánu mohou být filtrovány zahrnout nebo vyloučit určité testových sad v plánu.Můžete také zobrazit výsledky jednotlivých testeři v test team.Další informace naleznete v tématu Jak: plán testování zobrazení výsledků ve Microsoft Test Manager.

Úrovně testů, které je třeba hlášeny týmu?

Pomocí aplikace Visual Studio Test Professional a Team Foundation Server, váš tým můžete pochopit stav plánování a provádění zkoušek.Team Foundation Serverukládá plány pro testování, testování sad testových případů, výsledky zkoušek a všechny ostatní související data, která je generována v celém procesu testování.Můžete vizualizovat proces testování a kontrolu jakosti, pokud zkombinujete Microsoft Test Manager sestavy a dotazy pracovní položky Team Foundation Server. Můžete použít Microsoft Test Manager zjišťovat chyby v mnoha různých státech.Chyby, které jsou označeny jako pevná ostatní členové týmu by měla být vyřešen stavu.Následná sestavení můžete ověřit opravených.Chcete-li zobrazit informace o tom, jak ověřit, zda byly opraveny chyby naleznete v tématu Jak: Ověřte Bug je pevné pomocí Správce Microsoft Test.