Testowy pulpit nawigacyjny (zwinny i CMMI)

Przy użyciu pulpitu nawigacyjnego testu, można monitorować działania testu, raport na temat postępu, Znajdź luk w testów i zidentyfikować obszary testów, które mogą wymagać dalszego badania. Ten pulpit nawigacyjny Wyświetla pięć raportów, które zapewniają informacje dotyczące testowania, który wystąpił w najnowszej czterech tygodni.

W tym temacie: Dane wyświetlane na pulpicie nawigacyjnym Wymagane działania monitorowania testów rozwój Postęp testu monitora Określenia luk w testowania Monitor testu błędów i strat

Tego pulpitu nawigacyjnego umożliwia odpowiedzieć na następujące pytania: Jest przypadek testowy przygotowania zgodnie z planem? Zespół zdefiniował przypadków testowych dla wszystkich wątków użytkownika lub wymagania? Co to są proporcje przypadków testowych, które są przechodzącą awarie i zablokowanych? Metryki błąd testu wskazują problemu, który wymaga dalszych poszukiwań? Co to jest stan ostatnich nocy kompilacji? Co to są najnowsze zaewidencjonowania?

Wymagania

• Testowanie postępu Plan, gotowości przypadek testowy, Stan testowanie Historia użytkownika, stanu testowanie wymagania, i Testowanie działania raporty są dostępne tylko, kiedy zespół tworzy planów testów i uruchamia testy zgodnie z opisem w Planowanie ręcznych testów za pomocą systemu Team Web Access.

• Realizuj, postępu, wykresy trendów i raporty za pośrednictwem nie są wyświetlane, gdy serwer, który jest hostem usługi Analysis Services dla projektu zespołowego jest niedostępny.

• Plus wymagań wymienionych w Pulpity nawigacyjne portalu projektu.

Dane wyświetlane na pulpicie nawigacyjnym

Pulpit nawigacyjny test umożliwia zrozumieć, jak również zespołu postępuje w testowaniu wątki użytkownika (Agile) lub wymagania (CMMI). Pulpit nawigacyjny testu, wyświetla następujące składniki web Part.

Wersja szablonu procesu elastyczne

Wersja szablonu procesu CMMI

Składnik Web Part	Dane wyświetlane	Tematy pokrewne
	Skumulowany wykres warstwowy wyników testów wszystkich przypadków testowych zgrupowane w ich najnowsze wyniki zarejestrowane w ciągu ostatnich czterech tygodni. Wyniki obejmują nigdy nie uruchamiaj, zablokowane, nie powiodło się, i Passed.	Postęp planu testów - Raport
	Wykres skumulowany warstwowy, który pokazuje, jak wiele przypadków testowych zostały w Projekt lub Gotowe stanu najnowsze czterech tygodni.	Gotowość przypadków testowych - Raport
	Wykres słupkowy poziomy, który informuje o liczbie wyniki testu dla każdej kombinacji przypadkami testowymi i testowania konfiguracji zdefiniowany dla każdego użytkownika wątku lub wymagań. Wykres grupuje wyniki testów zgodnie z ich najnowsze testu, jeżeli dostępne są następujące opcje Passed (zielony) nie powiodło się (czerwony), zablokowane (purpurowy) lub nie Uruchom (szary).	Raport programu Excel dotyczący stanu testu scenariuszy użycia (Agile) Status wymagań testu — Raport programu Excel (CMMI)
	Wykres liniowy, prezentujące łączna liczba wszystkie wyniki są uruchamiane dla wszystkich ręczne przypadki testowe podczas ostatniego czterech tygodni.	Test aktywności — Raport programu Excel
	Wykres skumulowany warstwowy prezentujące łączna liczba wszystkie wyniki wynik nie powiodło się dla przypadków testowych, sortowane według typu błędu podczas ostatniego tygodnia cztery. Typy awarii między innymi regresji, Nowy problem, i znany problem.	Analiza niepowodzenia - Raport w programie Excel
	Lista nadchodzących zdarzeń. Ta lista jest tworzony na podstawie składnika Web Part programu SharePoint.	Nie dotyczy
	Liczba aktywnych, rozpoznanych i zamkniętych elementów roboczych. Można otworzyć listę elementów roboczych, wybierając każdy numer. Ta lista jest tworzony na podstawie Team Web Access składników Web Part.	Nie dotyczy
	Lista ostatnich kompilacji oraz ich status. Więcej szczegółów można wyświetlić, wybierając konkretną kompilację. Ta lista jest tworzony na podstawie Team Web Access składników Web Part. Legendę: : Kompilacja nie została rozpoczęta : Kompilacja w toku : Kompilacja powiodła się : Kompilacja nie powiodła się : Kompilacja została zatrzymana : Kompilacja zakończona częściowym sukcesem	Uruchamiaj, monitoruj i zarządzaj kompilacjami
	Lista najnowszych zaewidencjonowań. Więcej szczegółów można wyświetlić, wybierając specyficzną operację ewidencjonowania. Ta lista jest tworzony na podstawie Team Web Access składników Web Part.	Pisanie kodu i zarządzanie oczekującymi zmianami

Wymagane działania monitorowania testów rozwój

Do raportów na pulpicie nawigacyjnym test się przydatne i dokładne zespołu należy wykonać następujące czynności:

• Zdefiniować przypadki testowe i wątki użytkownika lub wymagania i Utwórz przetestowane przez łącza z przypadków testowych do wymagań dotyczących lub wątki użytkownika.

• Definiowanie planów testów i przypadków testowych przypisuj do przetestowania planów.

• Dla testów ręcznych oznaczyć wyniki każdego kroku weryfikacji w przypadku testowego jako przekazany lub nie powiodło się.

  Ważne

  Testerzy należy oznaczyć krok testu o stanie, jeśli jest krok testu weryfikacji.Wynik ogólny dla przypadek testowy odzwierciedla status wszystkich kroków testu oznaczone tester.W związku z tym przypadek testowy będzie mieć stan nie powiodło się, jeśli tester oznaczona każdy krok testu jako nie powiodło się lub nie zaznaczone.

  Testów automatycznych, każdy przypadek testowy, automatycznie jest oznaczona jako przekazany lub nie powiodło się.

• (Opcjonalnie) Umożliwia filtrowanie przypisać iteracji i obszaru ścieżki do każdy przypadek testowy.

Postęp testu monitora

Raporty pierwszych trzech na pulpicie nawigacyjnym testowanie umożliwia monitorowanie postępu testu i odpowiedzi na pytania w poniższej tabeli.

Report	Odpowiedzi na pytania	Uwagi
Gotowość przypadków testowych	Liczbę przypadków testowych zdefiniował zespołu testu? Liczbę przypadków testowych są gotowe do uruchomienia już dziś? Liczbę przypadków testowych musi zespołu nadal zapisu i przejrzyj? Ogólnej liczby przypadków testowych ma być wystarczającej liczby wątków użytkownika, które implementuje zespołu? Jaki procent przypadków testowych zespołu testu uruchomić już dziś? Zespół będzie mógł przygotować wszystkie przypadki testowe do końca iteracji?	Postęp w dobrej kondycji pokazuje stałym wzrostem liczby przypadków testowych, które projektowania i przechodzenia do stanu Gotowe zespołu. Zła postępu pokazuje, że nie lub kilka przypadków testowych są gotowe do uruchomienia. Kiedy wszystkie przypadki testowe pozostają w stanie projektu przez długi czas, problemu można zablokować postępu. Należy zbadać przyczyny zablokowaniu. Przerwę w testowania może rozwijać, jeżeli nie ma wystarczającą liczbę przypadków testowych. Liczba przypadków testowych, które są definiowane w projekcie powinna być równa lub większa niż liczba wątków użytkownika, które implementuje zespołu. Liczba przypadków testowych nie są wystarczające.
Test postępu planowania	Liczba przypadków testowych są przekazywania? Liczba przypadków testowych kończą się niepowodzeniem? Liczba przypadków testowych są blokowane? Nigdy nie uruchomiono liczbę przypadków testowych? Jaki procent przypadków testowych są przekazywania na wszystkie plany testowanie? Ile testowania zespół zakończeniu? Prawdopodobnie na zakończenie testowania na czas zespołu?	Jako rozwoju cyklu postępu, należy przekazać więcej przypadków testowych, a mniejszą liczbę przypadków testowych powinien w innych stanów. Zła postępu występuje, gdy zbyt wiele przypadków testowych nie powiodło się. W zależności od tego, gdzie jesteś w cyklu produktu może być sprawdzane, dlaczego tak wiele przypadków testowych kończą się niepowodzeniem. Liczba przypadków testowych, które nie powiodły się lub nigdy nie uruchamiaj jest prosty, można do sprawdzania, czy konkretne przyczyny, które mają wpływ na każdym obszarze.
Stan testu scenariuszy użycia Status wymagań testu	Dla każdego użytkownika wątku lub wymagań powoduje uruchamianie przypadków testowych? Jeśli przypadków testowych są zablokowane lub nie powoduje uruchamianie zespołu zrozumieć problemy uniemożliwiające i są one traktowane?	Postęp w dobrej kondycji pokazuje w większości przypadków testowych dla każdego użytkownika wątku lub przekazywania są wymagania. Zła postępu wskazane jest zbyt wiele testowanie przypadków dla określonego użytkownika wątku lub wymagań, które znajdują się w nigdy nie uruchamiaj, zablokowane, lub nie powiodło się stanu. Należy zbadać przyczyny, które pozwalają przypadków testowych, które są definiowane dla użytkownika wątku lub wymagania przed przesłaniem.

Określenia luk w testowania

Można użyć Stan testu Historia użytkownika lub Stan testu wymagań raport, aby sprawdzić, czy testów są obejmujące wszystkie kodu oraz odpowiedzieć na następujące pytania:

• Wątki użytkownika lub wymagania, które mają niski ogólnej liczby przypadków testowych?

• Wątki użytkownika lub wymagania, które mają wysoki ogólnej liczby przypadków testowych, które są zablokowane lub nigdy nie uruchamiaj?

• Pokrycie przypadek testowy dla każdego użytkownika wątku lub wymagań, spełnia oczekiwań?

• Wątki użytkownika lub wymagania, które mają wysoki współczynnik błędów testu?

• Co to jest średnią liczbę przypadków testowych, które są definiowane dla każdego użytkownika wątku lub wymagania?

Monitor testu błędów i strat

Monitoruj testu błędów, można zidentyfikować i rozwiązywania problemów z kodem wcześniej. Ostatnie dwa raporty na pulpicie nawigacyjnym testu umożliwia uzyskiwanie lepsze szczegółowych informacji dotyczących liczbę testy, które nie powiodły się.

Report	Odpowiedzi na pytania	Uwagi
Aktywność testów ręcznych	To liczba prób, które zespołu nigdy nie zostało uruchomione zmniejszenie? Jest zespołu minimalizację ogólnej liczby zablokowanych testów? Mniej testów nie powiodły się wraz z upływem czasu? Czy jeden test przekazywania? Działanie testu zawiera kołkami, których nie można uwzględnić?	Testowanie czynność ręczna raport wskazuje wyniki każdy przypadek testowy, dla każdej konfiguracji testów dla wszystkich planami testów oraz. Impulsy, które mogą wystąpić, może być wczesnym wskaźniki problemów w działanie testu lub jakość kodu, który sprawdza zespołu w. Należy sprawdzić metryki ostatnie kompilacji, stan usterek i pochodząca kodu w celu ustalenia, czy ich Pomocy opisano zmiany.
Analizy niepowodzeń testów	Ile testów są regresję? Zespół dba ogólnej liczby strat lub test awarii w oczekiwanym zakresów lub celami zespołu? Jest zespołu rozwiązania problemów, jak są identyfikowane i znane problemy w odpowiednim czasie?	Dobra raport analizy błąd testu pokazuje średnie liczby nowych problemów, znane problemy i strat. Jeśli wystąpi wszelkie kołkami w tych obszarach, zespół może być konieczne zbadać. Impulsy mogą wskazywać na problemy z działania testów lub jakość kodu, który sprawdza zespołu w. Ponadto można sprawdzić metryki ostatnie kompilacji, stan usterek i pochodząca kodu w celu ustalenia, czy ich Pomocy opisano zmiany.

Zobacz też

Koncepcje

Pulpity nawigacyjne portalu projektu