Pulpit nawigacyjny jakości (zwinny i CMMI)

Może być używany do uzyskiwania przeglądu postępu występujących w teście rozwoju, pulpit nawigacyjny jakości i tworzenia obszarach odnoszą się do jakości oprogramowania w opracowaniu. Zespół umożliwia pulpit nawigacyjny jakości Dowiedz się i podejmowania decyzji obsługujące celów zespołu wokół jakości produktu.

Przy użyciu tego pulpitu nawigacyjnego, możesz przejrzeć postęp testu, tworzyć stany, postęp w rozwiązaniu i zamykania usterki, współczynnik reactivations usterkę, procent kodu, który ma zostać przetestowana i trendów w zmiany kodu. Każdy z tych metryki jest wykreślić najnowsze czterech tygodni.

W tym temacie: Dane wyświetlane na pulpicie nawigacyjnym Wymagane działania do śledzenia jakości Rozwiązywanie problemów z jakością

Tego pulpitu nawigacyjnego umożliwia odpowiedzieć na następujące pytania: To działanie testu zgodnie z planem? Zespół testuje odpowiednie funkcje? Czy zespołu poprawki wysokiej jakości? Testy są stare? Zespół ma wystarczające testów? Czy występują wąskie gardła za wszelkie?

Wymagania

Te same wymagania zdefiniowane w Pulpity nawigacyjne portalu projektu.

Dane wyświetlane na pulpicie nawigacyjnym

Członkowie zespołu umożliwia określenie ogólnej jakości produktu, które są one tworzenie pulpitu nawigacyjnego jakości. W przypadku idealny stawek przebiegu testu, usterki i kod churn wszystkie program, który tego samego obrazu, ale często nie. Po znalezieniu różnic, należy sprawdzić ściślej odpowiednie kompilacji i serii danych. Pulpit nawigacyjny jakości łączy wyniki testów, pokrycie kodu z testowania, pochodząca kodu i usterki, aby lepiej zrozumieć wiele perspektyw w tym samym czasie.

Aby dowiedzieć się o składnikami Web Part, które są wyświetlane na pulpicie nawigacyjnym jakości, skorzystać z ilustracji i zgodne z tabeli.

Uwaga

Testowanie postępu Plan raportu jest dostępna tylko wtedy, gdy zespołu tworzy planów testów i uruchamianych testów.

Raporty postępu, kompilacji i wykresy kodu za pośrednictwem , nie są wyświetlane podczas magazynu danych na potrzeby projektu zespołowego jest niedostępny.

Aby dowiedzieć się więcej na temat sposobu interpretacji, aktualizowania lub dostosować wykresy, które są widoczne na pulpicie nawigacyjnym jakości, zobacz temat w poniższej tabeli.

Składnik Web Part	Dane wyświetlane	Tematy pokrewne
	Wykres skumulowany warstwowy wyników testów wszystkich przypadków testowych pogrupowane według najnowsze wyniki zarejestrowane - nigdy nie uruchamiaj, zablokowane, nie powiodło się, lub Passed — w ciągu ostatniego czterech tygodni.	Postęp planu testów - Raport
	Skumulowany kolumn, które pokazują, ile tworzy nie powiodło się lub powiodło się podczas ostatniego czterech tygodni.	Raport programu Excel dotyczący stanu kompilacji
	Wykres skumulowany warstwowy łączna liczba wszystkie błędy, przedstawić w rozbiciu na stan, podczas ostatniego tygodnia cztery.	Raport programu Excel dotyczący postępu usterek
	Wykres skumulowany warstwowy ile błędy zespołu reaktywował ze stanu rozwiązany i zamknięty podczas ostatniego czterech tygodni.	Reaktywacje usterek — Raport programu Excel
	Wykres liniowy, że przedstawia wartość procentową kodu przetestowane przez tworzenie testy weryfikacji (BVT) i innych testów w ciągu ostatniego czterech tygodni.	Pokrycie kodu — Raport w programie Excel
	Skumulowany obszaru wykresu, który zawiera liczbę wierszy kodu zespołu dodane, usunięte i zmienić zaewidencjonowania przed kompilacji w najnowszych czterech tygodni.	Przenoszenie kodu — 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 : Tworzenie częściowo powiodło się.	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 jakości

Dla pulpitu nawigacyjnego jakości być przydatne i dokładne zespół, należy wykonać czynności, które w tej sekcji opisano.

Wymagane działania do śledzenia postępu planu testu

W raporcie postępu Plan testu być przydatne i dokładne zespołu należy wykonać następujące czynności:

• Definiowanie przypadków testowych i historie użytkowników i Utwórz przetestowane przez łącza między przypadków testowych i wątki użytkownika.

• Definiowanie planów testów, i przypisać je do planów testó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.

  Uwaga

  Aby uzyskać informacje na temat definiowania ścieżek obszaru i iterację, zobacz Dodawanie i modyfikowanie obszaru i ścieżek iteracji.

Wymagane działania do śledzenia postępu usterek i reactivations usterek

Dla raportów postęp usterek i usterek Reactivations być przydatne i dokładne zespołu należy wykonać następujące czynności:

• Zdefiniuj usterki.

• Aktualizacja stanu z każdej usterkę jako poprawki zespołu weryfikuje, zamyka lub spowoduje ponowne uaktywnienie go.

• (Opcjonalnie) Określ iteracji i obszaru ścieżki każdego usterki, aby filtrować według tych pól.

Wymagane działania śledzenia tworzyć stanu, pokrycie kodu i pochodząca kodu

Stan tworzenia, pokrycie kodu i raporty Churn kod się przydatne i dokładne członków zespołu należy wykonać następujące czynności:

• Konfiguracji systemu kompilacji. Aby użyć Team Foundation Build, należy skonfigurować system kompilacji.

  Aby uzyskać więcej informacji, zobacz Konfigurowanie systemu kompilacji oraz zarządzanie nim.

• Utwórz tworzenia definicji. Możesz tworzyć wiele definicji kompilacji, a następnie uruchamiać je, aby tworzyć kod dla innej platformy. Ponadto można uruchomić każdą kompilację dla różnych konfiguracji.

  Aby uzyskać więcej informacji, zobacz Zdefiniuj proces kompilacji.

• Testów do uruchomienia automatycznie w ramach kompilacji definiowanie. Jako część definicji kompilacji, możesz zdefiniować testy do przeprowadzenia jako część kompilacji lub zakończenia niepowodzeniem w przypadku testów kończących się niepowodzeniem.

  Aby uzyskać więcej informacji, zobacz Użycie szablonów domyślnych w procesie kompilacji.

• Skonfigurować testy, aby gromadzić dane pokrycia kodu. Aby dane pokrycia kodu pojawiły się w raporcie, członkowie zespołu muszą instrumentować testy w celu zbierania tych danych.

  Aby uzyskać więcej informacji, zobacz Uruchamianie testów w procesie kompilacji.

• Uruchom tworzy regularnie. Możesz uruchamiać kompilacje w regularnych odstępach czasu lub po każdym zaewidencjonowaniu. Możesz tworzyć kompilacje regularne, korzystając z wyzwalacza harmonogramu.

  Aby uzyskać więcej informacji, zobacz Tworzenie lub edycja definicji kompilacji i Uruchamiaj, monitoruj i zarządzaj kompilacjami.

  Uwaga

  Chociaż członka zespołu ręcznie nadać kompilację przy użyciu Build Explorer, ta klasyfikacja nie zostaną uwzględnione w raporcie tworzyć wskaźników jakości.Ocena kompilacji pojawia się w raporcie Podsumowanie kompilacji.Aby uzyskać więcej informacji, zobacz Ocenianie jakości zakończonej kompilacji i Raporty dotyczący podsumowania kompilacji.

Rozwiązywanie problemów z jakością

W poniższej tabeli opisano problemy określonej jakości, które na pulpicie nawigacyjnym jakości pomaga monitorować i identyfikacji działania, które można wykonać zespołu.

Problem	Raporty o przegląd	Informacje dotyczące rozwiązywania problemów
Tworzenie błędów	Stan kompilacji	Godzinach nocnych kompilacji jest pulsu projektach wytwarzania oprogramowania. Jeśli kompilacje nie kończą się pomyślnie lub nie przechodzą testów weryfikacyjnych (BVT), zespół musi niezwłocznie rozwiązać problem.
Testy się niepowodzeniem	Test postępu planowania Postęp dokonany w kodzie	W przypadku wysokiej szybkości nieudanych prób i pochodząca kod zespołu Sprawdź dlaczego oprogramowania nie działa prawidłowo tak często. Przyczyny mogą obejmować luźne wytwarzania oprogramowania lub testy, które są zbyt rygorystycznej wczesnym cyklu iteracji.
Sprawdzenie, przekazując, ale z wysokiego stopnia znajdowania usterek	Test postępu planowania Postęp usterek	Po wielu testów przekazywania w tym samym okresie, ponieważ nie znaleziono wiele usterek, zespół może zbadać następujące możliwości: Testy nie jest wystarczająco rygorystycznej dla bieżącego etapu produktu. W iteracji wczesnym prostych testów są dobre. Jednak testy zachowywali bogatszej scenariuszy i integracji zgodnie z korzystania z produktu. Testy może być nieaktualny i testowanie niewłaściwy funkcjonalności. Technik stosowanych w różnych testu może oferować lepsze wyniki. Usterki są zgłaszane, ale nie podlegają testowania. Gdy usterki zgłoszone i nie są połączone z przypadek testowy, nie podlegają testowanie metodą regresji.
Testy są stare	Test postępu planowania Pokrycie kodu Postęp dokonany w kodzie	Podczas przekazywania wielu testów, zmienia znacząca ilość kodu i zmniejsza się pokrycie kodu, zespół może nie być uruchomiony testy, które wykonują nowy kod. Ponieważ nie opracowane testy na tym samym poziomie jak zmiany kodu, testów mogą stać się mniej i mniej odpowiednie.
Zespół nie jest testowania, zamykania lub ponownego uaktywnienia rozwiązanych usterek	Postęp usterek	W przypadku wystąpienia uwypuklenie w raporcie usterkę postęp dla rozwiązania usterki deweloperów rozwiązuje usterki, ale testerów nie zweryfikowano i zamknąć je. Zespół należy zbadać Dlaczego opracowała tego wzorca.
Za mało testowania	Test postępu planowania Postęp dokonany w kodzie	Podczas zespołu kilka testów, pochodząca z kodu jest wysoka i pokrycie kodu jest mniejsza niż oczekiwana, zespół może być konieczne Przydziel więcej zasobów do testowania. Ponadto zespołu powinien upewnij się, że testerów są skupiając się na te same funkcje jako pozostałych członków zespołu.
Ponowne aktywacje	Reaktywacje usterek	Gdy zespół spowoduje ponowne uaktywnienie usterki szybkością wysoki lub zwiększa, testerzy są często odrzuca programistów poprawki. Zespołu musi rozwiązać te problemy, aby uniknąć przydzielania zasobów znaczących kierunku konieczności wprowadzania zmian odrzucone poprawki. Potencjalne przyczyny raportowania usterek niska wydajność, zarządzanie laboratorium niska testów lub nadmiernie skuteczną segregowanie.
Niewystarczające testowania jednostek	Pokrycie kodu Postęp dokonany w kodzie	Po spadku pokrycie kodu pokrywa się ze wzrostem pochodząca kodu, deweloperzy mogą sprawdzanie w kodzie, bez żadnych odpowiednie testy jednostek do objęcia go. W większości przypadków pokrycie kodu powinna wynosić 100%, jeśli zespół rozwiązań Programowanie oparte na testach lub podobnych technik. Jeśli testy jednostek są używane ponownie jako BVTs, pokrycie kodu mają pojawiać się w odpowiedni raport.

Zobacz też

Koncepcje

Pulpity nawigacyjne portalu projektu