Jakość - pulpit nawigacyjny (CMMI)
W czasie gdy Twoje oprogramowanie jest opracowywane, pulpit nawigacyjny Jakość pozwala Ci dokonywać przeglądu postępu testów, stan kompilacji, postęp w rozwiązywaniu i zamykaniu błędów, wskaźnik reaktywacji błędów, procent kodu, który został przetestowany oraz trendy zmian kodu.Każdy z tych wskaźników jest wykreślany dla ostatnich czterech tygodni.Zespół może użyć pulpitu nawigacyjnego Jakość do podejmowania decyzji, które wspierają cele zespołu związane z jakością produktu.
[!UWAGA]
Masz dostęp do pulpitów nawigacyjnych za pośrednictwem portalu projektu zespołowego.Możesz uzyskać dostęp do pulpitu nawigacyjnego Jakość tylko wtedy, gdy ten portal został włączony i jest skonfigurowany do korzystania z programu SharePoint Server Enterprise Edition.Aby uzyskać więcej informacji, zobacz Pulpity nawigacyjne.
W tym temacie
|
Możesz użyć tego pulpitu nawigacyjnego do udzielenia odpowiedzi na następujące pytania:
|
Wymagane są uprawnienia
Aby wyświetlić pulpit nawigacyjny, użytkownik musi być przypisany lub należeć do grupy, która ma przypisane uprawnienia odczytu w Produkty SharePoint dla projektu zespołu.Aby zmodyfikować, skopiować lub dostosować pulpit nawigacyjny, użytkownik musi być przypisany lub należeć do grupy, która ma przypisane uprawnienia Członkowie w Produkty SharePoint dla projektu zespołu.Aby uzyskać więcej informacji, zobacz Dodawanie użytkowników do zespołów i projektów.
Aby zmodyfikować raport w Office Excel, musisz być członkiem roli zabezpieczeń TfsWarehouseDataReaders w Analysis Services SQL Server i musisz być przypisany lub należeć do grupy, która otrzymała uprawnienia Członkowie w Produkty SharePoint dla projektu zespołowego.Aby uzyskać więcej informacji, zobacz Udzielenie dostępu do bazy danych magazynu Visual Studio Informatykami.
Aby wyświetlić element roboczy, musisz być członkiem grupy Czytelnicy lub mieć uprawnienie do wyświetlania elementów roboczych w tym węźle z ustawieniem Zezwalaj.Aby utworzyć lub zmodyfikować element roboczy, musisz być członkiem grupy współautorów lub mieć uprawnienie do edytowania elementów pracy w tym węźle z ustawieniem Zezwalaj.
Dane, które są wyświetlane na pulpicie nawigacyjnym
Członkowie zespołu mogą korzystać z pulpitu nawigacyjnego Jakość, aby określać jakość produktu, który opracowują.W idealnym przypadku współczynnik testów kończonych sukcesem, błędy i postęp dokonany w kodzie pokazują ten sam obraz, ale często tak nie jest.Po znalezieniu niezgodności musisz dokładniej sprawdzić odpowiednią kompilację i serię danych.Pulpit nawigacyjny Jakość łączy wyniki testów i pokrycie kodu z testów, postęp dokonany w kodzie, oraz błędy, aby ułatwić zrozumienie wielu perspektyw jednocześnie.
Aby dowiedzieć się o częściach sieci Web, które są wyświetlane na pulpicie nawigacyjnym Jakość, zapoznaj się z rysunkiem i tabelą poniżej.
[!UWAGA]
Raport Postęp planu testu jest dostępny tylko wtedy, gdy zespół tworzy plany testów i przeprowadza testy przy użyciu Test Runner i Microsoft Test Manager.
Wykresy postępu, kompilacji i kodu oraz raporty od do nie są wyświetlane, gdy hurtownia danych dla projektu zespołowego nie jest dostępna.
Aby uzyskać więcej informacji dotyczących sposobu interpretowania, aktualizowania lub dostosowywania wykresów, które pojawiają się na pulpicie nawigacyjnym Jakość, zobacz tematy wymienione w poniższej tabeli.
Web Part |
Dane wyświetlane |
Tematy pokrewne |
---|---|---|
Skumulowany warstwowy wykres dla wyników testów wszystkich testów pogrupowanych według najnowszych wyników - Nigdy nie uruchamiane, Zablokowane, Zakończono niepowodzeniem, lub Zakończono powodzeniem - w ciągu ostatnich czterech tygodni. |
||
Skumulowane kolumny, które pokazują, jak wiele kompilacji zostało Zakończonych niepowodzeniem lub Zakończonych powodzeniem w ciągu ostatnich czterech tygodni. |
||
Skumulowany warstwowy wykres łącznej liczby wszystkich błędów, zgrupowanych według ich statusu w ciągu ostatnich czterech tygodni. |
||
Wykres skumulowany warstwowy pokazuje, jak wiele błędów zespołu zostało ponownie uaktywnionych ze stanu rozwiązane lub zamknięte w ciągu ostatnich czterech tygodni. |
||
Wykres liniowy, który przedstawia procent kodu, który został zbadany przez testy weryfikacji kompilacji (BVT) i inne testy w ciągu ostatnich czterech tygodni. |
||
Skumulowany warstwowy wykres określający ile wierszy kodu zespół dodał, usunął i zmienił w zaewidencjonowaniach przed kompilacją w ciągu ostatnich czterech tygodni. |
||
Lista nadchodzących zdarzeń.Lista pochodzi od 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 pochodzi ze składnika Web Part Team Web Access. |
Typy elementów szablonów roboczych procesu CMMI oraz przepływ pracy |
|
Lista ostatnich kompilacji oraz ich status.Więcej szczegółów można wyświetlić, wybierając na specyficzną kompilację.Ta lista pochodzi ze składnika Web Part Team Web Access. Legenda: : Kompilacja nie została rozpoczęta : Kompilacja w toku : Kompilacja powiodła się : Kompilacja zakończyła się niepowodzeniem : Kompilacja została zatrzymana : Kompilacja zakończona częściowym sukcesem |
||
Lista najnowszych zaewidencjonowań.Więcej szczegółów można wyświetlić, wybierając specyficzną operację ewidencjonowania.Ta lista pochodzi ze składnika Web Part Team Web Access. |
Wymagane działania związane z monitorowaniem jakości
Aby pulpit nawigacyjny jakości był przydatny i dokładny, zespół musi wykonać działania, które w tej sekcji opisano.
Wymagane działania związane ze śledzeniem postępu planu testu
Aby raport Postęp planowania testów był użyteczny i dokładny, zespół musi wykonać następujące działania:
Zdefiniuj przypadki testowe i wymagania, i utwórz łącza Przetestowane przez między wymaganiami a przypadkami testowymi.
Zdefiniuj plany testów i przypisz przypadki testowe do planów testów.
W przypadku ręcznych testów oznacz wyniki każdego kroku sprawdzania poprawności w przypadku testowym jako „powodzenie” lub „niepowodzenie”.
Ważne Testerzy muszą oznaczyć krok testu statusem, jeśli jest to krok testu sprawdzania poprawnościOgólny wynik przypadku testowego odpowiada statusowi wszystkich kroków testowych, które zostały oznaczone.Tym samym przypadek testowy będzie posiadał status niepowodzenia, jeżeli tester oznaczył którykolwiek z kroków jako niepowodzenie lub go nie oznaczył.
W przypadku testów zautomatyzowanych każdy przypadek testowy jest automatycznie oznaczony jako zakończony powodzeniem albo niepowodzeniem.
(Opcjonalnie) Aby obsługiwać filtrowanie, należy przypisać ścieżki Iteracja i Obszar do każdego przypadku testowego.
[!UWAGA]
Aby uzyskać informacje na temat definiowania ścieżek obszarów i iteracji, zobacz Dodawanie i modyfikowanie obszaru i ścieżek iteracji
Wymagane działania do śledzenia postępu błędów i reaktywacji błędów
Aby raporty o postępie usterek i reaktywacjach usterek były użyteczne i dokładne, zespół musi wykonać następujące działania:
Zdefiniuj błędy.
Aktualizuj Stan każdego Błędu, w miarę jak zespół rozwiązuje, weryfikuje, zamyka lub ponownie uaktywnia te błędy.
(Opcjonalnie) Określ ścieżki Iteracja i Obszar dla każdego błędu, jeśli chcesz filtrować według tych pól.
Działania wymagane dla śledzenia stanu kompilacji, pokrycia kodu i postępu dokonanego w kodzie
Aby raporty o stanie kompilacji, pokryciu kodu i postępie dokonanym w kodzie były użyteczne i dokładne, zespół musi wykonać następujące działania:
Skonfiguruj system kompilacji.Aby użyć Team Foundation Build, musisz skonfigurować system kompilacji.
Aby uzyskać więcej informacji, zobacz Configuring Your Build System.
Utwórz definicje kompilacji.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.
Definiuj testy, aby automatycznie uruchomić jako część kompilacji.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.
Skonfiguruj testy w celu zbierania danych 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 Konfiguracja pokrycia kodu przy użyciu ustawień testów jest przestarzała i How to: Gather Code-Coverage Data with Generic Tests.
Regularnie uruchamia kompilację.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łonek zespołu może ręcznie ocenić kompilację za pomocą Build Explorer, ta ocena nie jest odzwierciedlana w raporcie Wskaźniki jakości kompilacji.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ą
Poniższa tabela opisuje określone problemy w zakresie jakości, których monitorowanie ułatwia pulpit nawigacyjny Jakość i określa akcje, które może wykonywać zespół.
Problem |
Raporty do przejrzenia |
Uwagi dotyczące rozwiązywania problemów |
---|---|---|
Kompilacja zakończona niepowodzeniem |
Stan kompilacji |
Nocna kompilacja jest sercem projektów rozwoju 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 zakończone niepowodzeniem |
Postęp planu testu Postęp dokonany w kodzie |
Gdy wskaźniki ilości testów zakończonych niepowodzeniem i postępów dokonanych w kodzie są wysokie, zespół może zbadać, dlaczego oprogramowanie tak często ma awarie.Przyczyny mogą obejmować poszczególne praktyki opracowywania lub testów, które są zbyt rygorystyczne na początku cyklu iteracji. |
Testy zakończone powodzeniem, ale o wysokiej częstotliwości znajdowania błędów |
Postęp planu testu Postęp w zakresie błędu |
Jeśli w tym samym okresie powodzeniem kończy się wiele testów i znajdowanych jest wiele błędów, zespół może zbadać następujące możliwości:
|
Testy są przestarzałe |
Postęp planu testu Pokrycie kodu Postęp dokonany w kodzie |
W czasie, gdy wiele testów kończy się powodzeniem, znacząca ilość kodu zmienia się i spada pokrycie kodu, zespół może nie przeprowadzać testów, które korzystają z nowego kodu. Ponieważ testy nie są dopracowywane w takim samym tempie jak zmiany kodu, zakres testów może stać się mniej odpowiedni. |
Zespół nie testuje, nie zamyka ani nie uaktywnia rozwiązanych błędów |
Postęp w zakresie błędu |
Gdy w raporcie Postępu w zakresie błędu dla błędów rozwiązanych wystąpi wybrzuszenie, deweloperzy rozwiązują błędy, ale testerzy jeszcze ich nie zweryfikowali i nie zamknęli.Zespół powinien zbadać dlaczego ten wzorzec został opracowany. |
Zbyt mało testów |
Postęp planu testu Postęp dokonany w kodzie |
Gdy zespół wykonuje kilka testów, postęp dokonany w kodzie jest wysoki, a pokrycie kodu jest mniejsze niż oczekiwane, zespół może potrzebować przydzielić do testów większą ilość zasobów.Dodatkowo zespół powinny zapewnić, że testerzy koncentrują się na tych samych funkcjach jak reszta zespołu. |
Reaktywacje |
Reaktywacje błędu |
Gdy zespół reaktywuje Błędy w dużej lub rosnącej ilości, testerzy często odrzucają poprawki deweloperów.Zespół musi się zająć tymi problemami, aby uniknąć przyznawania znaczących zasobów na przerabianie odrzuconych poprawek.Potencjalne przyczyny: słabe raportowanie usterek, słabe zarządzanie laboratorium testowym lub zbyt agresywne klasyfikowanie. |
Niewystarczające testowanie jednostkowe |
Pokrycie kodu Postęp dokonany w kodzie |
Kiedy spadek w pokryciu kodu zbiega się ze wzrostem postępu dokonanego w kodzie, deweloperzy mogą ewidencjonować kod bez żadnych odpowiadających testów jednostkowych będących w stanie to pokryć. W większości przypadków pokrycie kodu powinno wynosić blisko 100%, jeśli zespół praktykuje rozwój oparty na testach lub podobne techniki.Jeśli testy jednostkowe są ponownie wykorzystywane jako testy BVT, pokrycie kodu powinno pojawić się w odpowiednich raportach. |
Dostosowywanie pulpitu nawigacyjnego Jakość
Możesz dostosować Pulpit nawigacyjny Jakość w następujący sposób:
Zmień filtry dla każdego raportu programu Excel, aby skoncentrować się na obszarach określonego produktu lub iteracji.
Dodaj zapytanie niestandardowego składnika Web part, który wyświetla listę elementów roboczych, które znajduje kwerenda.Na przykład można dodać zapytanie, które wyświetla listę wszystkich aktywnych błędów, które nie są połączone z przypadkiem testowym.To zapytanie pokaże ilość Błędów, które są zgłaszane, ale nie można ich odnaleźć poprzez testy i dlatego nie podlegają testowaniu metodą regresji.
Dodaj istniejące raporty programu Excel, takie jak Tendencje usterek i Analizy błędów do pulpitu nawigacyjnego.
Aby uzyskać więcej informacji na temat pracy z raportami programu Office Excel i ich dostosowywania, zobacz następujące strony w witrynie firmy Microsoft w sieci Web: