Test wcześnie i często

Jak najszybciej połowu wad jest najtańszą metodą zapewnienia jakości oprogramowania.Kent Beck i Cynthia Andres napisał "Oto dylemat podczas tworzenia oprogramowania: wady są drogie, ale wyeliminowanie wad jest drogie.Jednak większość wad kończy się więcej, niż byłoby koszt zapobiegające ich wyceny." (Programowanie ekstremalne wyjaśnione: radzenia sobie ze zmianami) Najważniejsze wskazówki i narzędzia może pomóc zespołowi, aby zminimalizować koszty zapobiegania i naprawy błędów przy zachowaniu wysokiej jakości projektu w trakcie całego okresu jego użytkowania.

Zespół dokładniej można ocenić jakość projektu w dowolnym momencie, jeśli znajdziesz wady, usunąć wady i sprawdź poprawki, jak iść.Testując często, zespołów i udziałowcom można posiadać zawsze aktualne informacje bieżącego stanu kodu i podejmować świadome decyzje w trakcie realizacji projektu.Ostatecznie, można odpowiedzieć na pytanie "Czy możemy zwolnić?" i zrozumienie jego dla ludzi, którzy korzystają z programów.

W tym temacie zaleca następujące wskazówki:

• Utwórz zestaw zautomatyzowane testy dla każdej klasy i dla wszystkich głównych części interfejsu API.Pisania testów jednostkowych powinny wziąć około 40% czasu członków zespołu.Aby uzyskać więcej informacji, zobacz Tworzenie testów automatycznych przy użyciu programu Microsoft Test Manager.

• Utwórz testy dla każdej historyjki użytkownika.Najlepiej te powinny być zautomatyzowane.Aby uzyskać więcej informacji, zobacz Tworzenie testów zaległych elementów, przypadków użycia lub wymagań produktu.

• Utwórz zasady ewidencjonowania, które przypominają członkom zespołu, aby uruchomić testy przed sprawdzeniem w kodzie.Aby uzyskać więcej informacji, zobacz Add Check-in Policies.

• Umożliwia ustawienie budowy ciągły lub w godzinach nocnych, który uruchamia pełny zestaw testów.

• Monitor zakresu badań, aby zapewnić, że cały kod jest badany.Należy dążyć do pokrycia co najmniej 70%.Aby uzyskać więcej informacji, zobacz Testowanie luk raport programu Excel (Agile).

• Uruchamianie ręcznych testów pod koniec każdego sprint.

Zespół można zarządzać i skalować te badania przeprowadzane we wczesnej fazie projektu przy użyciu integracji między Microsoft Test Manager, Visual Studio Application Lifecycle Management (ALM), i Visual Studio Team Foundation Server.Aby uzyskać więcej informacji, zobacz Testowanie aplikacji.

W tym temacie

• Strategia badania

• Planowanie badań

• Testowania odbiorczego

• Testowanie jednostek

• Sterowane testami i testujący wczesne

• Ręczne i automatyczne testowanie

• Sprawozdania z wyników testu

Strategia badania

Sukces drużyny testy, zależy od kilku czynników, które obejmują wielkości zespołu, drużyny metod i narzędzi do zarządzania drużyny.Można użyć metod agile do ciągłej poprawy wyników badań.Dzięki zastosowaniu tej metody, nie tylko można rozpocząć do testowania z bardzo ograniczonymi zasobami, ale również można dostosować swoje praktyki odpowiednio całym projekcie.

Co należy uwzględnić przy wprowadzaniu agile testowania

Przy wprowadzaniu agile testowania do istniejącej aplikacji, zespołu można zacząć od myślenia strategii badań, zarówno na poziomie sprint, jak i na poziomie projektu.Na poziomie sprint można dołączyć zestaw testów akceptacyjnych na pokrycie każdej historyjki użytkownika bieżącego sprintu.Na poziomie projektu może mieć testy, które obejmują całego projektu, takich jak testowanie to-end.Jest to przydatne, jeśli chcesz zweryfikować funkcje rozciągający się na dwóch lub więcej sprinty.Można utworzyć wszystkie rodzaje badań, podczas gdy zespół buduje kodu podczas sprintu.Badania te obejmują testy, testy akceptacyjne i niefunkcjonalne badań, takich jak testy wydajności, testów bezpieczeństwa i testy użyteczności.

Aby zastosować testowania metod agile, najpierw należy rozważyć historii aplikacji i system, że używane przez zespół.Agile metod badania można zastosować do nowych i istniejących aplikacji.Można użyć Microsoft Test Manager do tworzenia planu testowania całego projektu i planu testów dla każdego sprint w projekcie.Próby te plany pozwalają zespół organizacji przypadków testowych do testów, które pomagają ustalić priorytety uruchomionych testów i pomóc zrozumieć wyniki badań.Aby uzyskać więcej informacji, zobacz Tworzenie testów zaległych elementów, przypadków użycia lub wymagań produktu.Zespół można użyć Visual Studio ALM do grupy przypadków testowych do testów przez kilka metod:

• Tworzenie i zarządzanie grupą statyczne przypadków testowych.

• Zastosowanie kwerend do tworzenia i zarządzania nimi dynamiczne grupy przypadków testowych (to znaczy Znajdź przypadków testowych na podstawie priorytetu).

• Dodawanie historii użytkownika lub wymaganie do planu testów, w których łącze do wymogu przypadków testowych.

• Kopiowanie istniejącego pakietu testów z innego planu testów.

Aby uzyskać więcej informacji, zobacz Organizowanie przypadkach badania przy użyciu pakietów testowych.

Po drugie należy wziąć pod uwagę podatność kodu.Aby dowiedzieć się, należy rozumieć architektury i wzorców aplikacji.Jeśli używasz wzorców, takich jak Model View Controller (MVC), Model View Controller (MVVM) lub modelu widoku prezentera (MVP), można wyizolować określone funkcje i uruchomić badania funkcjonalności, bez negatywnego wpływu testów interfejsu użytkownika.Jednak to nie zawsze reprezentuje real sprawy.Na przykład nie mogą izolowaniu funkcjonalność refaktoryzacji części aplikacji, i ma dostęp niektórych obszarach kodu tylko przez użytkownika procedury obsługi zdarzeń interfejsu lub sieci.Jeśli chcesz znacznie poprawić jakość test, należy zwiększyć procent sprawdzalne kodu.Aby uzyskać więcej informacji na temat tych wzorów, zobacz ASP.NET Model View Controller (MVC).

Po trzecie należy rozważyć możliwości zespołu, przed przystąpieniem do implementacji testów agile.Niektórzy członkowie zespołu powinien mieć możliwość tworzenia testów jednostkowych, podczas implementacji funkcji.Niektórzy członkowie zespołu powinien być w stanie utworzyć i zdefiniować przypadki użycia ręcznego i testy przepływu pracy, jeśli pozna reguł biznesowych aplikacji.Dodatkowo inni członkowie zespołu powinny móc utworzyć zautomatyzowany i bardziej szczegółowe testy, które są oparte na tych testów ręcznych, jeżeli posiadają niezbędne kwalifikacje techniczne.

Jak zarządzać cyklu badania

Testowanie jest procesem iteracyjnym całym projekcie.Można znaleźć następujące czynności:

1. Zrobić jasne cele testowania i upewnij się, że całego zespołu akceptuje je.W oparciu o cele, określenie strategii badań.Na przykład strategii może być "testy zostaną przeprowadzone przed każdym ewidencjonowania, testy jednostkowe będą miały użycie kodu 70%, a wszystkie wątki, użytkownik będzie miał co najmniej jeden test zautomatyzowany."

2. Zdefiniuj planie testów na podstawie projektu historyjek użytkownika, założenia projektowe i niefunkcjonalne wymagania w bieżącym sprintu.

   1. Można dodać historyjek użytkownika do listy zaległości i przewidywać przyszłe Sprint.Należy dopasować każdy test mający na celu co najmniej jednego biegu i, powinna więc przypadków testowych dla wszystkich historyjek użytkownika w sprintu.

3. Definiowanie i tworzenie przypadków testowych, takich jak testy akceptacyjne, testy, badania funkcjonalności i testów wydajności.

4. Grupa przypadków testowych do testów.Można dopasować te przetestować suites do planów określonych w badaniach, które pomagają w dotarciu zakresu testów.

5. Uruchamianie testów i należą przypadków testowych wielokrotnie w całej sprintu.Start uruchomić testy we wczesnej fazie sprint, a nadal dodawać przypadków testowych do pakietów testowych.Jeśli chcesz zidentyfikować maw warunki i sytuacje, można zastosować, badania odkrywcze i konwersacje częste wewnątrz zespołu.

6. Zapewnić, iż wszystkie testy akceptacyjne dla historii użytkownika przeszły przed ustawieniem swój status, aby zakończyć.

Chociaż przepływu pracy może być znacznie bardziej zaangażować się w zależności od awarii oprogramowania, poprzedniej ilustracji oddaje istotę przepływu pracy wśród głównych składników.

• Kod generuje buduje.

• Kod jest pod wpływem określonego gniazda, planów testowania i jakości buduje.

• Plany przeprowadzania testów oraz przypadków testowych są pod wpływem cele planowanych i inne aspekty projektu, który nie jest wyświetlany na rysunku.

• Zmiany w kodzie może wpłynąć na przypadków testowych.

Naprawianie błędów

1. Jak najszybciej muszą radzić sobie z błędami.Poważny błąd oznacza, że historyjek użytkownika, do których ma wpływ nie zostały zakończone.

2. Tworzenie elementów pracy błąd pod kątem błędów, które znajdują się za pomocą testowania lub innych działań.Ustaw wskaźnik ważności błędu określają stopień, do którego wpływa na historyjek użytkownika.O wysokim znaczeniu, takie jak 0 lub 1, wskazuje, że ważny użytkownik historie nie zostały zaimplementowane lub że użytkownicy muszą wykonać znaczące obejścia, aby osiągnąć Historia.O niskim znaczeniu, takich jak 3, wskazuje, że użytkownicy nadal mogą osiągnąć ich główne cele bez dodatkowej pracy.

3. Pracę w Twoim zespole podjęcie decyzji w sprawie planu działania dla każdego błędu.

4. Rozwiązania błędów, tak szybko, jak je naprawić.Błąd powinni należeć do innej osoby do sprawdzenia.Sprawdź i możliwie jak najszybciej zamknąć błędów.

5. Służy do śledzenia stanu błędów.Retrospektywnego spotkania na końcu każdej iteracji, obejrzyj raport błędów trendów i omówienia przyczyn wszelkich przyrostów nietypowe.Aby uzyskać więcej informacji, zobacz Zgłoś trendów.

Planowanie badań

Planowanie test jest proces pomaga zespołowi zrozumieć duży obraz projektu i proces przygotowywania zespołu dla wszystkich rodzajów testowania.Testowanie Agile rozpoczyna się sprint poziomu.W każdym sprint zespół utworzy badań w celu sprawdzenia historyjek użytkownika, które powstały w tym sprint.Zespół uruchamia testy, które zostały utworzone głównie bieżący i poprzedni w.Za pośrednictwem trwania projektu dużej liczby testów są buduje się który obejmuje wszystkie funkcje.Ilustracja przedstawia szablon dla planów testowania w projekcie.

Tworzenie planu testów dla każdego sprint i dla projektu

Korzystając z funkcji testowania Visual Studio ALM, zespół może stopniowo plan, organizowania, należy wykonać i raport sprawdzania.Zespół można utworzyć szablon dla planów badań, a członkowie zespołu można wypełnić pakietów testowych.W planie testów zespołu można zidentyfikować, gdzie należy używać automatycznego lub ręcznego przypadków testowych.

Dla każdego sprint w projekcie można rozpocząć tworzenie planu testowania.Korzystając z tego planu, zespół może skupić się na sprawdzaniu funkcji w bieżącym sprintu.Mimo, że plan jest pusty po pierwsze, można go używać jako symbol zastępczy dla pakietów testowych.Dodatkowo można zorganizować przypadków testowych do testów.Aby uzyskać aktualne informacje zwrotne od stronom projektu, należy utworzyć tych przypadków testowych, początku i na całym sprintu.

Można również utworzyć planu testów, który obejmuje cały projekt.Plany badania projektu umożliwia zlewają badań od poprzedniego Sprint i organizowanie testów, które mają zastosowanie do całego projektu.Dlatego należy kontynuować uruchamianie regresji pakietów testowych, ponieważ ważne jest, aby utrzymać stabilności i przepływu, gdy zespół buduje większych projektów.Zwłaszcza, jeśli pracujesz z zespołami większe i rozproszone, że brak bliskości, testów regresji na aktualizowanym można wychwytywanie błędów, które są oparte na zmiany, które mają wpływ kaskadowych.Bez poprawnego środków błędy te są bardzo trudne do uchwycenia i łowione późno w cyklu lub po porodzie.

Niektóre zespoły może być zdefiniowanie planu testów, który obejmuje cały projekt.Tego rodzaju planów testowania może zweryfikować pokrewne funkcje w szeregu Sprint i zawierają zestawy testów, które są uruchamiane w trakcie realizacji projektu.Na przykład można przetestować funkcja, która obejmuje Sprint historyjek użytkownika tylko wtedy, gdy cała funkcja jest kompletny.

Zdefiniowanie testów akceptacyjnych przed sprint

Należy zdefiniować testów akceptacyjnych przed sprintu.Te testy akceptacyjne może pomóc określić, czy Historyjka użytkownika jest kompletny.Po utworzeniu pakietu testów, o nazwie testów akceptacyjnych w planie testów dla każdego sprint, można śledzić przypadków testowych akceptacji.Aby uzyskać więcej informacji, zobacz Testowania odbiorczego dalszej części tego tematu.

Budowę testów jednostkowych w ciągu sprint

Zespół jednostki typu testy należy budować podczas sprintu.Testy można sprawdzić kod wydajności, takie jak koszt czasu i zasobów, które są używane na wykonanie kodu.Inne rodzaje badań, takich jak testy niefunkcjonalne (to znaczy testy wydajności i testy zabezpieczeń) powinna być zbudowany i dodany do testów.Należy zorganizować te przetestować suites, tak aby można było łatwo zidentyfikować ich kosztów.

Fokus badań na obszarach stosowania wysoki

Zrozumienie, gdzie istnieje dużej zmienności w oprogramowaniu Określa, gdzie może być punkty aktywne.Wypełnionych przez użytkownika, środowiska naturalnego, który działa oprogramowanie, sieci i sprzęt są przykładami zmienne konfiguracji, umożliwiające zespołowi Odkryj punktów aktywnych w oprogramowaniu.Jeśli rzadko występuje warunek lub są zawiłe kilka warunków, które mogą wystąpić podczas testu, wartość badania zmniejsza się z tym, że potencjalny wpływ wadę jest bardzo duża.Ogólnie rzecz biorąc izolacja funkcjonalności jest pożądane, jeśli jest to możliwe.Badania sytuacji duży wpływ są równie ważne.Aby uzyskać więcej informacji dotyczących sposobu zarządzania konfiguracjami za pomocą Microsoft Test Manager, zobacz Konfiguracje testów — określanie platform testowych.

Dla istniejących projektów monitorować obszary, które mają największą liczbę wad i ustalić, dlaczego występują braki.Należy również monitorować rezygnacji kodu, ponieważ w tej dziedzinie, może przeoczyć zasadniczych założeń.Jest kilka wad kodu przyczyn trudności zarządzania nie tylko Państwa (na przykład, sieci i interfejs użytkownika), ale również kod.

Testowania odbiorczego

Badania odbiorcze Sprawdź historyjek użytkownika.Badania te nie zapewnia tylko pomyślnie stworzenie co klientów trzeba w całym cyklu życia projektu, ale także budowania zaufania z klientami i pokazuje swoje obowiązki akceptowane.Aby uzyskać więcej informacji, zobacz następującą stronę sieci Web: Akceptacji testu Engineering przewodnik.

Jak rozpocząć pracę z testowania odbiorczego

Otwórz Microsoft Test Manager, a następnie utwórz zestaw testów, o nazwie testów akceptacyjnych w planie testów.Zespół powinien mieć co najmniej jeden zestaw testów, grupujący testy akceptacyjne dla każdego sprintu. Aby uzyskać więcej informacji, zobacz Definiowanie planu testów.

Migracja z testów ręcznych do zautomatyzowanych testów

Ręcznych testów są łatwiejsze do zdefiniowania niż zautomatyzowane testy, ale bardziej kosztowna, aby uruchomić.Jest zatem dobrą strategią zacząć testów ręcznych i stopniowej wymiany tych ważniejszych z zautomatyzowane testy.

Po pierwsze Rozpocznij tworzenie zestawu ręczne przypadków testowych, które pozwalają sprawdzić każdej historyjki użytkownika, który został zdefiniowany dla sprint.Ponieważ nie ma żadnego kodu na początku sprint, przypadku testowego takie powinny określać wysokiego poziomu akcje, które są mapowane na częściach Historyjka użytkownika.Na przykład, można to krok w przypadku testowego "jako użytkownikowi uwierzytelnionemu, wykonaj..." Począwszy od ręcznego przypadku testowego umożliwia zespołowi szybko zdefiniować testów akceptacyjnych idealne, zanim rozpocznie się sprint.

Po drugie skorygować i zaktualizować testów akceptacyjnych, aby odzwierciedlić doświadczenia określonego użytkownika, gdy członkowie zespołu mają kod, który implementuje historyjek użytkownika w sprintu.Jednakże jeśli zespół nie chce zmodyfikować istniejący zestaw testów akceptacyjnych, możesz można zaimportować testów do nowego pakietu testów i punkt wyjścia do bardziej szczegółowych badań.Na przykład krok w przypadku bardziej szczegółowe badanie może być "Wpisz nazwę w polu tekstowym Nazwa użytkownika i wybierz przycisk logowania się zalogować na konto bankowe."

Po trzecie uzyskane w trakcie testów akceptacji, tworzyć testy interfejsu użytkownika zakodowanych przy użyciu nagrywania akcji.Aby uzyskać więcej informacji, zobacz Generowanie kodowanego testu interfejsu użytkownika na podstawie dotychczasowego rejestrowania akcji.Kodowane jako testy interfejsu użytkownika może wygenerować kod bardziej przejrzysty, jeśli utworzysz kroki, które izolują funkcjonalność.Po dołączeniu kodowane jako test interfejsu użytkownika do ręcznego przypadków testowych, można uruchomić testy automatyczne z planie testów (Aby uzyskać więcej informacji, zobacz Jak: skojarzyć testu automatycznego, w przypadku badania.)

Ręczne testów, które zostały zdefiniowane na początku sprint może ułatwić tworzenie zautomatyzowanych testów.Jest koszt badaniom zarówno ręcznych i automatycznych, ponieważ ręcznych testów muszą być przesłane przez osobę i zautomatyzowane testy muszą zostać zaktualizowane, jeśli zmiany kodu lub użytkownika.Aby uzyskać więcej informacji, zobacz vs ręczne, automatyczne testowanie dalszej części tego tematu.

Kto prowadzi przypadków testowych akceptacji?

Zespół, właściciela produktu i klientów można uruchomić przypadków testowych akceptacji.Zespół powinien uruchomić je tak często, jak to możliwe zapewnienie planu bazowego na zestaw testów, które należy przekazać w sprintu.Właściciel produktu i klienta można również uruchomić testy akceptacyjne i zażądać weryfikacji, aby pomyślnie zakończyć sprintu.

Zespół można użyć Microsoft Test Manager uruchomienie każdego przypadku testowego akceptacji i rejestrowanie wideo zrzut wyniki testu.W ten sposób można uzyskać graficzny zapis wyników badań, a także można podzielić się wyniki z klientami.Jest to pomocne, gdy jest trudne do tworzenia konfiguracji wymagane (na przykład, konfiguracje wieloserwerowe).

Definiowanie przypadków testowych akceptacji wraz z historyjek użytkownika

Po zdefiniowaniu historyjek użytkownika można zdefiniować kryteria akceptacji po prawej stronie.Definiując testów akceptacyjnych, może pomóc zespołowi zrozumieć kryteria przyjęcia dla bieżącego sprint od właściciela produktu i klientów.Klient musi wyrazić zgodę na testy akceptacyjne, dlatego warto utworzyć przypadków testowych akceptacji, zanim rozpocznie się sprint.

Testowanie jednostek

Testy są zautomatyzowane testy, które pozwalają sprawdzić funkcjonalność na poziomie składnika, klasy, metody lub właściwości.Testy są podstawą zautomatyzowane i regresji testowania, który zapewnia Długoterminowa stabilność i przyszłych łatwość konserwacji projektu.

Jak jednostki badania pomóc rozwijać projektu mojej aplikacji?

Proces tworzenia jednostki badań, podczas gdy kod testowane budynku pomaga zdefiniować kształt kodu.Można utworzyć kod, który jest sprawdzalne przy użyciu testów jednostkowych.Trudności w tworzeniu testy dla kodu jest to znak, że kod powinien być refactored.

Jak zorganizować Moje testy?

Każdy członek zespołu, który pisze kod należy utworzyć testów jednostkowych dla części budowy i sprawdzić jednostki przetestować kod do kontroli wersji wewnątrz Visual Studio projektu.Plik elementów pracy przypadków testowych do pakietu testów weryfikacji kompilacji, który będzie uruchamiany podczas każdego kompilacji dzięki ciągłej integracji, a także wewnątrz pakietu testów, które sprawdza odpowiednich historii użytkownika.

Jak zarządzać Odchylenie jednostki badań bez konieczności zmiany kodu testu?

Odchylenie w pobranej test definiuje podobieństwa lub różnice między badaniami, jak sprawdza, czy funkcje w kodzie projektu.Na przykład jeżeli składnik logowania aplikacji sieci Web, można podać kilka typów haseł, aby utworzyć konto użytkownika.System może mieć zasady zamówienia i kombinacji typów znaków, które są używane.

Program Visual Studio Professional Test zapewnia dla pisania testów opartych na danych jednostkowych i kodowane testy interfejsu użytkownika.Aby uzyskać więcej informacji, zobacz Porady: tworzenie testu jednostkowego opartego na danych i Jak: tworzenie Test opartych na danych zakodowanych interfejsu użytkownika.

Sterowane testami rozwoju i badań we wczesnym

Projektowanie sterowane testami (TDD) jest dyscypliny projektowania i programowania, gdzie każdy wiersz kodu został napisany w odpowiedzi na test, który programista pisze się tuż przed kodowania.Pomysł zostania konsumenta kodu, który zamierza zastosować jest bardzo zaawansowanym i obsługuje realnym jak kod powinien używane i skonstruowany.

W TDD autora działa wiele małymi dawkami.Rozwój każdego małą wielkość trwa od kilku minut do kilku godzin.Zazwyczaj wiele takich przyrostach składają się na historię użytkownika.Podczas pracy historii użytkownika, autora ewidencjonowanie testy i kodu.Deweloper współpracuje w następującego cyklu:

1. Napisz automatycznie test, który może przekazać, gdy jest zapisywana wartość przyrostu.

2. Zweryfikuj, że nowy test nie pomaga, upewnij się, że test działa.

3. Napisanie kodu, który spowoduje, że badania przekazać.

4. Uruchom test, aby zweryfikować, że to się uda.

5. Również uruchomić wszystkie inne testy na tym samym obszarze, aby upewnić się, że nie ma błędów zostały wprowadzone.

6. Refaktoringu kodu, jeśli to konieczne, w celu poprawy jego struktury bez dodawania zachowań.Należy ponownie uruchomić testy, aby upewnić się, że kod wciąż działa.

7. Powtarzaj wszystkie te kroki, aż pełny identyfikator wątku jest zaimplementowana.Zgodnie z poprzednim skoki są zintegrowane z całej historii, dodać testów weryfikujących cały artykuł.

8. Sprawdź w badaniach kodu i jednostkę implementacji.

Jeśli są Państwo zainteresowani z zalet metod na początku badania, można rozpocząć od utworzenia Podręcznik (lub indywidualne przyjęcie) testów.Badania te ręczne można zautomatyzować tworząc kodowane jako test interfejsu użytkownika.Aby uzyskać więcej informacji, zobacz Jak: generowanie Test zakodowanej interfejsu użytkownika poprzez rejestrowanie wniosku w ramach badania. Integracja z testów, które jednostka jest używana przetestować RAM w Visual Studio ALM można także tworzyć Aby zweryfikować funkcje, który jest realizowany.Grupy przypadków testowych, które są tworzone na początku iteracji są uruchamiane na początku iteracji, aby spróbować zarówno zweryfikować funkcje, jak i wszystkie błędy.Te zestawy testów i przypadków testowych można stale wykorzystywane jako testów regresji przez całe życie projektu.Kontynuując do prowadzenia tych badań, pomaga zapewnić, że błędy, które zostały znalezione i funkcje, które zostały zweryfikowane na początku iteracji nie dotyczy zmian w dalszej części projektu.

Użyj testy dla ciągłej integracji

Testy jednostkowe, które są tworzone podczas korzystania z praktyki na początku badania powinno zostać zorganizowane wewnątrz pakietu testów dla bieżącego wątku sprint i użytkownika.Badania te jednostki może być podwyższony do planu badań całego projektu i uruchamiana okresowo przez zespół, a wewnątrz cyklu ciągłej integracji.Testy może również służyć jako podstawa do integracji, obciążenia i testowanie wydajności.

Testy jednostkowe, które są tworzone od początku może służyć jako część ciągłej integracji.Aby uzyskać więcej informacji na temat uruchamiania testów podczas kompilacji, zobacz TestToolsTask Task.

Umożliwia zarządzanie konfiguracji testów wirtualizacji

Aby uruchomić testy, można utworzyć zestaw środowiska są zarządzane obrazów funkcji Hyper-V w Microsoft Test Manager. Aby uzyskać więcej informacji o sposobach uruchomić testy automatyczne planu testów za pomocą Microsoft Test Manager, zobacz Jak: Uruchom zautomatyzowane testy w środowisku laboratoryjnym przy użyciu Menedżera badania firmy Microsoft.

Ręczne i automatyczne testowanie

Automatyczne i ręczne przypadków testowych uzupełniają się.Zespoły Agile dążyć do mają bardziej zautomatyzowane przypadków testowych, ponieważ promują częste lub ciągłe testy zadziałały.Aby stale uruchomić testy, muszą one wykonać szybko i często, która jest trudna do osiągnięcia z testami.

Istnieje kilka uwag, które należy utworzyć przy podejmowaniu decyzji o rozkładzie ręcznych i automatycznych przypadków testowych.

Jak umiejętności w organizacji wpływają swojej dystrybucji typy testu?

Właściciel produktu pomaga ustalić, historyjek użytkownika dla projektu i powinien również przyczynić się do utworzenia testów akceptacyjnych.Właściciela produktu będzie prawdopodobnie nie zrobienie zakodowanej testów, ale będą miały znaczący wiedzy na temat domeny business.Przypadków testowych, które są zdefiniowane przez właściciela produktu w związku z tym, będzie na poziomie słownictwa biznesowych i reguł biznesowych.Na przykład właściciel produktu w przedsiębiorstwo żeglugowe określą różnych środków transportu, obsługiwanych przez biznesowych (na przykład ciężarówka, pociąg, lotniczą, morską lub kombinacji).Właściciel produktu można zdefiniować kilka przypadków testowych, które korzystają z różnych możliwości.Podczas ręcznego przeprowadzania tych badań jest ważne, aby określić minimalną liczbę testów, które korzystają z różnych opcji (w tym przypadku środki transportu morskiego).

Członkowie zespołu, którzy produkują kodu można zbudować zakodowanej testy interfejsu użytkownika, które mogą być oparte na testach ręczne lub niezależne od innych testów.Aby uzyskać więcej informacji, zobacz How to: Generate a Coded UI Test by Recording the Application Under Test.Kodowane jako testy interfejsu użytkownika musi być obsługiwane przez członków zespołu, którzy mają możliwość stosować i rozwijać kod projektu.

Kiedy powinien możesz przekonwertować testów ręcznych zautomatyzowane testy lub utworzyć automatyczne testy od początku?

Można skonstruować zautomatyzowane testy, jeśli oczekujesz uruchomić testy wielokrotnie w celu utrzymania stabilności kodu.Warto wziąć pod uwagę wysiłek tworzenie zautomatyzowanych testów, ponieważ inwestycja automatyzacji ma wpływ na zasoby zespołu.Tworzenie zautomatyzowanych testów, gdy kod ma mały rezygnacji wyniki w wyższy zwrot z inwestycji (ROI), ponieważ nie ma mniej rezygnacji test.Jednakże ma wartości tworzenia automatyzacji wcześnie, ponieważ to pomoże, problemy w logikę i projektowania.W obu przypadkach zasoby, które są wymagane do obsługi kodu automatycznych testów należy zwrócić uwagę.

Po podjęciu decyzji, że zestaw testów muszą być zautomatyzowane, Przenieś zakończenie automatyzacji najszybciej jak to możliwe, ponieważ korzyści automatyzacji obejmują zarządzanie stabilność kodu.Stabilność i liczby usterek, które znajdują się, jak napisano automatyzacji wpłynie na nakład pracy wymagany do ukończenia automatyzacji.Ostatecznie równowagi między ręcznym porównaniu zautomatyzowane testy jest o priorytetach rodzajów testów, które muszą być zbudowane i podczas trwania projektu.

Jakiego rodzaju badania są automatyczne?

Testy jednostkowe

Testy jednostkowe zweryfikować funkcje w kodzie lub przez proces, takich jak TDD.Testy są ważne, ponieważ pomagają utrzymać stabilności i zależności wewnątrz kodu.TDD także dąży do uzyskania lepszego projektowania z zależności i dobra jej definicji, ponieważ ułatwia zrozumienie konstrukcji z perspektywy konsumentów kodu.

Badania obciążenia

Można utworzyć testów obciążenia, które są oparte na istniejących zautomatyzowane przypadków testowych, lub można utworzyć testów, które generują określonych rodzajów ładunków w aplikacji lub usług.Aby uzyskać więcej informacji na temat testu agenta kontrolerów i zbadania agentów do generowania symulowane obciążenia testowania, zobacz Jak: Uruchom Test za pomocą testu kontrolerów i badania czynników.

Aby uzyskać więcej informacji na temat testowania obciążenia z Visual Studio ALM, zobacz następującą stronę w witrynie firmy Microsoft w sieci Web: Opis załadować testów.

Ciągłe badania integracji

Można użyć ciągłej integracji z Visual Studio ALM aby zapewnić, że w każdym przypadku, gdy kod jest opracowany i zaewidencjonowany, działa poprawnie z istniejącym kodem.Ciągłej integracji są ważne, jak zespołu i kodzie rośnie.Można zdefiniować typ kompilacji, zawierający testowania parametrów i określić, które testy, aby uruchomić po zakończeniu kompilacji.Aby uzyskać więcej informacji na temat definiowania budowy, który uruchamia testy, zobacz Zdefiniowanie procesu tworzenia, oparty na szablonie domyślne.

Rodzaje badań, które można zautomatyzowany?

Testowanie konfiguracji

Badania na wielu zainstalowanych środowisk może być bardzo pracochłonne zadanie.Microsoft Test Managerzapewnia możliwości prowadzenia testów na różne konfiguracje za pomocą maszyny wirtualne lub fizyczne maszyny.Aby uzyskać więcej informacji na temat uruchomić testy i zbierania danych w środowiskach wielu, zobacz Konfigurowanie maszyny testowej do wykonywania badań lub zbieranie danych.

Testy interfejsu użytkownika

Visual Studio ALMma możliwości tworzenia zautomatyzowane testy bezpośrednio dla interfejsu użytkownika.Aby uzyskać więcej informacji o tworzeniu testy interfejsu użytkownika kodowane, zobacz Jak: tworzenie testu zakodowanej interfejsu użytkownika.

Testy instalacji

Można skorzystać z możliwości laboratorium z Microsoft Test Manager grupę konfiguracji, które można użyć w celu sprawdzenia, czy programy instalacyjne dla aplikacji działać zgodnie z oczekiwaniami.

Jakie są bariery automatyzacji?

Możliwości zespołu

Tworzenie automatyzacji wymaga podzbiór zespół test, aby dowiedzieć się, jak napisać kod.Plan do ponoszenia krzywej uczenia się tworzenia automatyzacji i projektowania kodu testu.Podobny do kodu produkcji, projektowania kodu automatyzacji dla swojej pożądanych celów, takich jak łatwość konserwacji, łatwość składu i długowieczności.

Aby uzyskać więcej informacji na temat tworzenia zautomatyzowane testy za pomocą Visual Studio Test Professional, zobacz Tworzenie testów automatycznych przy użyciu programu Microsoft Test Manager.

Kod rezygnacji

Kod, który zmienia się często wdrożyliśmy i wywrze wpływ kaskadowych do kodu automatyzacji test, ponieważ będzie musiała zostać zmieniony.Tworzenie kodu automatyzacji test dla składników i interfejsów, które są mniej prawdopodobne zmienić, aby uniknąć tych efektów kaskadowych.

Kod projekt

Struktury kodu, takie jak ASP.NET MVC i MVVM przewodnik członkowie zespołu mogli napisać kod, który ma izolacji, które jest wymagane w celu sprawdzenia różnych części kodu.Kod, który jest ściśle związana z interfejsu użytkownika jest trudny do testowania, ponieważ może wymagać użytkownikowi interakcję ze formantów interfejsu użytkownika.

Jakie są zalety ręczne przypadków testowych?

Ręczne przypadków testowych oferują następujące korzyści:

• Podręcznik testy pomagają zespołowi wyszukiwania błędów w procesie poszukiwania.

• Ręczne przypadków testowych są łatwe do definiowania, ponieważ można zdefiniować zestaw kroków w dowolnym abstrakcji i zdefiniować sukcesów i niepowodzeń w żadnych warunkach, które chcesz.

• To bardzo proste rozpocząć pisanie ręczne przypadków testowych we wczesnej fazie projektu, zanim kodu został napisany.Jest to ważne podczas procesu definiowania testów akceptacyjnych.

• Jeśli używasz programu Visual Studio Professional przetestować przypadków testowych może składać się z etapów udostępnionych, które pomagają zaoszczędzić czas podczas definiowania podobne badania i pozostawić zespołem, aby ponownie użyć pojedynczej wersji podzbiór badania.Za pomocą etapów udostępnionych pomaga przy zmianie przypadków testowych, ponieważ zmiana etapów udostępnionych automatycznie zmienia wszystkich przypadków testowych, które używają etapów udostępnionych.Aby uzyskać więcej informacji dotyczących sposobu tworzenia i używania etapów udostępnionych ZobaczHow to: Share Common Test Case Steps Using Shared Steps

• Ręczne przypadków testowych może służyć jako środek początku komunikacji w projekcie lub sprint.

• Ręczne przypadków testowych może służyć jako środek dokumentowania zautomatyzowane przypadku testowego bez każda osoba przeglądająca kod.

• Klienci korzystający z Visual Studio ALM, wykonywanie testów ręczne można zebrać kod zapotrzebowania metryki.

Co to są deficyty ręczne przypadków testowych?

Ręczne przypadków testowych wykonywania poniższych braków:

• Zdefiniowanie kryteriów sukcesu może być skomplikowane, ponieważ zależy od punktu widzenia i język, który jest używany w definicji badania.Niektóre języka mogą być interpretowane inaczej, i który może opuścić miejsca na błędy.

• Uruchamianie testów, które zawierają ręczne przypadków testowych wymaga osobę, która ma fizycznie należy wykonać kroki testu i wyniki raportu.Ten proces może zużywać o wiele czasu i w związku z tym, mogą wymagać większej liczby członków zespołu do wykonywania testów albo zwiększenie długości czasu uruchamiania pakietu testów.Za pomocą Visual Studio Professional przetestować, zespół można użyć "do przodu ręczne testowanie", w jakie działania są rejestrowane podczas badania, które następnie mogą być uruchamiane w przyszłości przebiegu badania.

• W zależności od stabilność kod czas i wysiłek, który jest wymagany do uruchamiania testów zależy od.W efekcie uruchomione ręczne testów może wpłynąć na przepływu w zespole.

• Największy deficyt jest, że ręcznych testów są podatne na błąd człowieka w błąd.Testerzy mogą Zobacz błąd ich oczach i rozpoznaje go.

Jakie są zalety zautomatyzowanych przypadków testowych?

Zautomatyzowane przypadków testowych oferują następujące korzyści:

• Zautomatyzowane testy pomoc utrzymania stabilności i pomocy w znalezieniu regresji, które mogą wystąpić z powodu zmiany w kodzie.

• Testy automatyczne można uruchomić instalacji nienadzorowanej.

• Zautomatyzowane testy oprogramowania są i może być zaprojektowany i składa się z innym kodem wielokrotnego użytku.Dzięki temu zautomatyzowane testy, elastyczne i utrzymaniu.

• Automatyzacji można uruchamiać na wielu konfiguracji za pomocą Microsoft Test Manager.

• Może być gromadzony metryki pokrycia kodu, gdy testy automatyczne są uruchamiane.

Co to są deficyty zautomatyzowane przypadków testowych?

Zautomatyzowane przypadków testowych wykonywania poniższych braków:

• Specjalne warunki muszą być określone i wdrożone za pomocą kodu.Jak tworzony jest automatyzacja i wykonywania, dodatkowe warunki, które zostaną zrealizowane jako ich wykryciu.

• Gdy kod jest zmieniony lub refactored, może to być efekty kaskadowe, które wymagają odpowiednich starań, aby zmienić dotkniętych zautomatyzowane testy.

• Mogą istnieć psychologiczne w Twoim zespole podczas zmiany kodu spowodować wiele testów nie powiedzie się.Jeśli testy te są wykorzystywane jako flagi, zespół może zrezygnować z podniesienia wszelkie flagi.

• Mogą istnieć fałszywego poczucia bezpieczeństwa, kiedy przechodzi wszystkie testy, jeśli odpowiednie warunki nie są badania przypadków testowych.Jest ważne, aby utrzymać pakietów testowych i upewnij się, że sprawdzają one odpowiednie warunki i wyniki.

Sprawozdania z wyników testu

Z perspektywy agile, raportowanie i podczas badania Team Foundation Server dla bieżącego stanu jakości, na podstawie błędów lub agregacji miar, jest częścią sprzężenia zwrotnego, który pozwala zespołowi iteracyjne i wprowadzić zmiany w kodzie, plan projektu i planem badania.Aby uzyskać więcej informacji, zobacz Sprawozdanie z postępu planu badań.

Można również monitorować postęp w planie testów przy użyciu funkcji wyniki planu badań w Microsoft Test Manager.Wyniki planu badań włączy wykresy i statystyki numeryczny przeszedł testy nie powiodło się i aktywne.Ponadto wyniki planu badań obejmują szczegółowe wykresami typów awarii i rozdzielczość danych.Aby dołączyć lub wykluczyć zestawy testów określonych w planie testów można filtrować wyniki planu badań.Wyniki dla poszczególnych testerów można też wyświetlać, w zespole test.Aby uzyskać więcej informacji, zobacz Jak: Plan badań widok wyników w Microsoft Test Manager.

Jakie poziomy badań powinny być zgłaszane do zespołu?

Za pomocą Visual Studio Test Professional i Team Foundation Server, zespołowi zrozumieć stan Planowanie i wykonywanie testów.Team Foundation Serverprzechowuje swoje plany badań, pakietów testowych, przypadków testów, wyniki badań i wszystkie inne skojarzone dane, który jest generowany przez cały procesu testowania.Można wyświetlać wizualizację proces testowania i kontroli jakości, jeśli połączenie Microsoft Test Manager z raportowaniem i pozycji roboczych kwerend Team Foundation Server. Można użyć Microsoft Test Manager do kwerendy pod kątem błędów w szerokim zakresie różnych Państw.Błędy, które są oznaczone jako określonym przez innych członków zespołu powinna być w stanie rozpoznać.Aby sprawdzić poprawione błędy, można użyć kolejnych operacji budowania.Aby uzyskać informacje na temat weryfikowania, czy błąd został rozwiązany, zobacz Jak: Sprawdź, czy błąd jest stałe za pomocą Microsoft Test Manager.