Pulpit nawigacyjny jakości (Agile)

Można umożliwia uzyskanie przeglądu postępu występujących w badania, rozwój, pulpitu nawigacyjnego jakości i tworzenie obszarów odnoszą się do jakości oprogramowania w ramach rozwoju.Zespół można użyć pulpitu nawigacyjnego jakości i podejmowania decyzji, obsługujące cele zespołu wokół jakości produktu.

Za pomocą tego pulpitu nawigacyjnego, można przejrzeć postęp testu, tworzenie Państwa, postępu w rozwiązywaniu i zamykania błędów, stawka bug reactivations, procent kodu, które zostały przetestowane i tendencje zmian kodu.Każdy z tych wskaźników jest wykreślana w ostatnich czterech tygodni.

[!UWAGA]

Pulpity nawigacyjne dostęp za pośrednictwem portalu sieci zespołu projektu.Dostęp można uzyskać tylko jeżeli pulpitu nawigacyjnego jakości programu portal została włączona i jest przygotowana, aby użyć Microsoft Office SharePoint Server 2007.Aby uzyskać więcej informacji, zobacz Pulpity nawigacyjne (Agile) lub Dostęp do portalu projektu zespołowego lub do sterowania procesami.

W tym temacie Dane wyświetlane na pulpicie nawigacyjnym Działań wymaganych do śledzenia jakości Rozwiązywanie problemów z jakością Dostosowywanie pulpitu nawigacyjnego jakości

Można użyć tego pulpitu nawigacyjnego odpowiedzi na następujące pytania:: Jest nakładu badania na torze? Zespół jest testowanie odpowiednie funkcje? Są zespołu naprawianiem wysokiej jakości? Są testy starych? Czy zespół ma wystarczające badania? Wszelkie wąskich gardeł występuje?

Wymagane są uprawnienia

Aby wyświetlić pulpit nawigacyjny, musi być przypisane lub należeć do grupy, która została przypisana odczytu uprawnień w Produkty SharePoint dla zespołu projektu.Modyfikować, kopiować lub dostosować pulpit nawigacyjny, musi być przypisane lub należeć do grupy, która została przypisana członków uprawnień w Produkty SharePoint dla zespołu projektu.Aby uzyskać więcej informacji, zobacz Dodawanie użytkowników do zespołów projektów.

Aby zmodyfikować raport w Office Excel, musi być członkiem TfsWarehouseDataReaders rola zabezpieczeń w SQL Server Analysis Services i muszą być przypisane lub należeć do grupy, która została przypisana członków uprawnień w Produkty SharePoint zespołu projektu.Aby uzyskać więcej informacji, zobacz Udzielenie dostępu do bazy danych magazynu Visual Studio Informatykami.

Aby wyświetlić element pracy, musi być członkiem czytelników grupy lub Widok elementów pracy, w tym węźle należy ustawić uprawnienie Zezwalaj na.Aby utworzyć lub zmodyfikować element pracy, musi być członkiem Współautorzy grupy lub pracy edytowanie elementów w tym węźle należy ustawić uprawnienie Zezwalaj na.Aby uzyskać więcej informacji, zobacz Zarządzanie uprawnieniami.

Dane wyświetlane na pulpicie nawigacyjnym

Członkowie zespołu można użyć do określenia ogólnej jakości produktu, które rozwijają się jakości pulpitu nawigacyjnego.W idealnym przypadku stawek przebieg badania, błędy i kod pozyskiwane samego obrazu, ale często nie wszystkie pokaz.Po znalezieniu niezgodności, należy sprawdzić ściślej właściwe kompilacji i serii danych.Pulpit nawigacyjny jakości łączy wyniki badań, użycie kodu z badania, zajętość kodu i błędów, aby ułatwić zrozumienie perspektywy wiele jednocześnie.

W szczególności Panel wyświetla składniki Web Part, które na poniższej ilustracji pokazano i w poniższej tabeli opisano.

[!UWAGA]

Badanie postępów Plan raportu jest dostępna, tylko gdy zespół tworzy plany badań i uruchamia testy za pomocą Test Runner i Microsoft Test Manager.Informacje dotyczące określenia zestawy testów i badań, planów, zobacz Organizowanie przypadkach badania przy użyciu pakietów testowych.

Raporty postępu, kompilacji i wykresy kodu przez , nie są wyświetlane, gdy magazyn danych dla zespołu projektu nie jest dostępne.

Aby dowiedzieć się więcej na temat interpretować, aktualizacji lub dostosowanie wykresów, które pojawiają się na pulpicie nawigacyjnym jakości, zobacz Tematy w poniższej tabeli.

Składnik Web part	Dane wyświetlane	Temat pokrewny
	Wykres skumulowany warstwowy wyników badań wszystkich przypadkach badania pogrupowane według ostatnich wyników zarejestrowane - Nigdy nie uruchamiać, zablokowane, nie powiodło się, lub przekazanego - w ciągu ostatnich czterech tygodni.	Sprawozdanie z postępu planu badań
	Stos kolumn, pokazujące, jak wiele buduje nie powiodło się lub udało się podczas ostatnich czterech tygodni.	Utworzyć raport o stanie programu Excel
	Wykres skumulowany warstwowy Skumulowana liczba wszystkich błędów, które są zgrupowane przez Państwo, w ciągu ostatnich czterech tygodni.	Zgłoś postępu programu Excel
	Wykres skumulowany warstwowy liczbę błędów zespołu został reaktywowany ze stanu rozwiązany lub zamknięty podczas ostatnich czterech tygodni.	Zgłoś Excel Reactivations
	Wykres liniowy, że pokazuje procent kod przetestowane przez tworzenie testów weryfikacyjnych (BVT) i innych badań w ciągu ostatnich czterech tygodni.	Kod zapotrzebowania Excel raportu
	Skumulowany wykres pokazujący ile linii kodu zespołu dodawane, usuwane i zmieniony w zarejestrowań przed budowanie podczas ostatnich czterech tygodni.	Kod zajętość Excel raportu
	Lista wydarzenia.Ta lista jest pochodną część sieci Web programu SharePoint.	Nie dotyczy
	Liczba aktywnych rozwiązany i zamknięty elementów pracy.Lista elementów roboczych można otworzyć, klikając każdy numer.Ta lista jest pochodną Team Web Access Web part.	Elementy pracy i przepływu pracy (Agile)
	Lista ostatnich kompilacje i ich stan.Więcej szczegółów można wyświetlić, klikając szczególnych kompilacji.Ta lista jest pochodną Team Web Access Web part. Legenda: : Tworzenie w toku : Kompilacja Nieuruchomiony : Powiodła się kompilacja : Nie powiodła się kompilacja : Zatrzymane kompilacji : Częściowo powiodła się kompilacja	Managing and Reporting on Builds
	Lista wyboru najnowsze dodatki plug-in.Więcej szczegółów można wyświetlić, klikając szczególnych ewidencjonowania.Ta lista jest pochodną Team Web Access Web part.	Opracowanie kodu i zarządzać oczekujące zmiany

Wymagane czynności monitorowania jakości

Pulpitu nawigacyjnego jakości za przydatne i dokładne zespołu musi wykonać działania, które opisano w tej sekcji.

Czynności wymagane do śledzenia postępu planu badań

Dla raportu postęp planu badań za przydatne i dokładne zespół, należy wykonać następujące działania:

• Określenie przypadków testów i historie użytkownika i utworzyć Badane przez łącza między przypadków testów i historie użytkownika.

• Określenie planów badań i przypisać plany badań przypadków testów.Aby uzyskać więcej informacji, zobacz Definiowanie planu testów.

• Dla badań ręczne oznaczyć wyniki każdego kroku sprawdzania poprawności w przypadku badania przekazany lub nie powiodło się.

  Ważne
  Testerzy musi oznaczyć kroku badania o stanie Jeśli krok testu poprawności.Ogólny wynik w przypadku badania odzwierciedla stan wszystkich etapów badania, które oznaczone tester.W przypadku badania będzie więc stan Niepowodzenie tester oznaczone podporządkować badania nie powiodło się lub nie zaznaczone.

  Dla zautomatyzowanych testów każdego przypadku badanie jest automatycznie oznaczona jako przekazany lub nie powiodło się.

• (Opcjonalnie) Obsługuje filtrowanie, należy przypisać iteracji i obszaru ścieżki w każdym przypadku badanie.

  [!UWAGA]

  Informacji na temat definiowania ścieżki obszaru i iteracji, zobacz Tworzenie i modyfikowanie obszarów i iteracje.

Działań wymaganych do śledzenia postępu błędów i błędów Reactivations

Bug postępu i Bug Reactivations raportów za przydatne i dokładne zespołu, należy wykonać następujące działania:

• Definiowanie błędów.

• Aktualizacja Państwo każdego Bug jako poprawki zespołu weryfikuje, zamyka lub ponownie uaktywnia go.

• (Opcjonalnie) Określ iteracji i obszaru ścieżki każdy błąd, jeśli chcesz filtrować według tych pól.

Czynności wymagane do śledzenia stanu kompilacji, użycie kodu i kodu zajętość

Budowanie stanu, Code Coverage i kod pozyskiwane raportów za przydatne i dokładne członkowie zespołu, należy wykonać następujące działania:

• Skonfiguruj build system.Aby użyć Team Foundation Build, należy skonfigurować system kompilacji.

  Aby uzyskać więcej informacji, zobacz Configuring Your Build System.

• Tworzenie definicji build.Można utworzyć kilka definicji kompilacji, a następnie uruchomić każdy z nich kod dla różnych platform.Ponadto można uruchomić każdej kompilacji dla różnych konfiguracji.

  Aby uzyskać więcej informacji, zobacz Zdefiniowanie procesu kompilacji.

• Definiowanie testy uruchamiane automatycznie jako część kompilacja.Jako część definicji kompilacji można zdefiniować testy, aby uruchomić jako część budowanie lub jeśli testy nie.

  Aby uzyskać więcej informacji, zobacz Zdefiniowanie procesu tworzenia, oparty na szablonie domyślne.

• Konfigurowanie testów w celu zbierania danych pokrycia kodu.Kod zapotrzebowania dane w raporcie członkowie zespołu muszą instrument prawny testów w celu zbierania danych.

  Aby uzyskać więcej informacji, zobacz Konfiguracja pokrycia kodu przy użyciu ustawień testów jest przestarzała i How to: Gather Code-Coverage Data with Generic Tests.

• Uruchom regularnie tworzy.Kompilacje można uruchomić w regularnych odstępach czasu lub po każdym wyboru.Kompilacje regularnych można utworzyć użycia wyzwalacza harmonogramu.

  Aby uzyskać więcej informacji, zobacz Utwórz definicję kompilacji i Uruchamianie, monitorowania i zarządzania kompilacje.

  [!UWAGA]

  Chociaż członek zespołu może ocenić kompilacji ręcznie za pomocą Build Explorer, to klasyfikacja nie jest odzwierciedlone w raporcie tworzenie wskaźników jakości.Klasyfikacja kompilacji pojawia się w raporcie Podsumowanie zbudować.Aby uzyskać więcej informacji, zobacz Oceń jakość wypełnione kompilacji i Tworzenie raportu podsumowującego.

Rozwiązywanie problemów z jakością

W poniższej tabeli opisano zagadnienia określonej jakości, pomagające jakości pulpitu nawigacyjnego można monitorować i określić akcje, które można wykonać zespół.

Problem	Przeglądanie raportów	Rozwiązywanie problemów z notatek
Budowanie awarii	Tworzy stanu	Dansk kompilacji jest pulsu projektów rozwoju oprogramowania.Kompilacje nie są pomyślnie Kończenie albo są nie przekazywanie kompilacji testów weryfikacyjnych (BVT), zespół musi niezwłocznie rozwiązać problem.
Testy braku	Postęp planu badań Zajętość kodu	W przypadku wysokiej stawki nieudanych prób i zajętość kod zespołu badać przyczyny awarii oprogramowania w tak często.Przyczyny mogą obejmować luzem rozwoju praktyk lub testów, które są zbyt rygorystyczne na początku cyklu iteracji.
Badania passing jednak wysoki stopień znajdowanie błędów	Postęp planu badań Bug postępu	Gdy wiele testów przekazywania w tym samym okresie jak stwierdzono wiele błędów, zespół może zbadać następujące możliwości: Badania może nie być dostatecznie surowe dla bieżącego etapu produktu.W wczesnych iteracji prostych testów są dobre.Testy powinny jednakże wykonywać szerszej scenariuszach i integracji jako dojrzewa produktu. Badania może być przestarzałych lub badania funkcjonalności niewłaściwy. Badania różnych technik może oferować lepsze wyniki. Błędy są raportowany, ale nie podlegające badaniom.Błędy są zgłaszane i nie są połączone w przypadku badania, nie podlegają one testowanie regresji.
Testy są przestarzałe	Postęp planu badań Użycie kodu Zajętość kodu	Podczas przekazywania wielu testów, zmienia znaczną ilość kodu i kodu spadek zapotrzebowania, zespół może nie być uruchomiona testów, które wykonuje nowy kod. Ponieważ testy nie są opracowywane z szybkością taką jak zmiany kodu, badanie zapotrzebowania mogą stać się coraz mniej odpowiednie.
Zespół nie jest badanie, zamknięcia lub ponownego uaktywniania rozpoznać błędy	Bug postępu	Uwypuklenie występuje w sprawozdaniu z postępu błędów dla błędów rozwiązane, idevelopers są Rozwiązywanie błędów, ale nie zweryfikowane i ich zamknięcia testerów.Zespół powinien zbadać Dlaczego ten rozwinął.
Zbyt mało testowania	Postęp planu badań Zajętość kodu	Gdy zespół działa kilka testów, jest wysoka zajętość kod i kod zapotrzebowania jest mniejsza niż oczekiwana, zespołu trzeba przydzielić więcej zasobów do testowania.Ponadto zespół powinny zapewnić, że testerów są koncentrując się na takie same funkcje jak reszta zespołu.
Reactivations	Błąd Reactivations	Gdy zespół ponownie uaktywnia błędów wysoki lub rosnącą szybkością, testerzy są często odrzuca poprawki deweloperów.Zespół musi rozwiązania tych problemów w celu uniknięcia podziału zasobów znaczące kierunku siłownię poprawki odrzucone.Potencjalne przyczyny: Raportowanie błędów ubogich, test słabe zarządzanie lab lub nadmiernie agresywne klasyfikacji.
Nieadekwatne testowania	Użycie kodu Zajętość kodu	Po spadku code coverage zbiega się z wzrost zajętość kodu, deweloperzy mogą sprawdzanie kodu bez odpowiedniego badania jednostki pokryć. W większości przypadków code coverage powinna wynosić 100%, jeśli zespół praktyk lets lub podobnych technik.Jeśli testy są ponownie wykorzystywane jako BVTs, code coverage powinny być wyświetlane w odpowiednich raportów.

Dostosowywanie pulpitu nawigacyjnego jakości

Jakość pulpitu nawigacyjnego można dostosowywać w następujący sposób:

• Zmienić filtry każdego raport programu Excel, aby skoncentrować się na obszarach określonego produktu lub iteracji.

• Dodawanie składnika Web part Wyświetla listę elementów pracy, które znajdzie kwerendę niestandardową kwerendę.Na przykład można dodać kwerendę, która zawiera listę wszystkich aktywnych błędów, które nie są połączone w przypadku badania.Ta kwerenda wyświetli wolumin błędów, że zgłoszono, ale nie można odnaleźć poprzez badania i dlatego nie podlegają Regresja.

• Dodawanie istniejących raportów programu Excel, takich jak Trendów Bug i Analizy awarii, do pulpitu nawigacyjnego.

Aby uzyskać więcej informacji dotyczących pracy z i dostosowywanie raportów w Office Excel, zobacz następujące strony w witrynie firmy Microsoft w sieci Web:

• Sposoby dostosowywania raportów tabeli przestawnej

• Edytuj lub usuń skoroszyt z usług programu Excel

• Publikowania skoroszytu w usługach programu Excel

• Zapisywanie pliku w bibliotece programu SharePoint lub innej lokalizacji w sieci Web

Zobacz też

Koncepcje

Pulpity nawigacyjne (Agile)

Artefakty (Agile)

Inne zasoby

Scrum