Raport dotyczący wskaźników jakości kompilacji

Raport Wskaźniki jakości kompilacji pokazuje pokrycie testu, postęp dokonany w kodzie oraz liczbę usterek dla określonej definicji kompilacji. Można użyć tego raportu aby określić, jak bliskie do jakości wydania są porcje kodu.

Idealnie, jeśli wyniki testu, usterki oraz postęp dokonany w kodzie przedstawiają ten sam obraz, jednak często się tak nie dzieje. Po znalezieniu rozbieżności, można użyć raportu Wskaźniki jakości usterek aby zbadać szczegóły określonej kompilacji i serii danych. Ponieważ ten raport łączy wyniki badań, pokrycie kodu z testów, postęp dokonany w kodzie oraz usterki, można przeglądać wiele perspektyw w tym samym czasie.

Aby uzyskać informacje o tym, jak uzyskać dostęp, odświeżać lub zarządzać raportami, zobacz Raporty (SQL Server Reporting Services ).

Uwaga

Ten raport wymaga, żeby kolekcja projektu zespołu zawierająca projekt Twojego zespołu została przygotowana z użyciem programu SQL Server Reporting Services.Ten raport nie jest dostępny, jeśli opcja Raporty nie pojawia się po otwarciu programu Team Explorer i rozwinięciu węzła projektu zespołu.

W tym temacie Dane w raporcie Zmienianie liczby kompilacji w raporcie Interpretowanie raportu Filtrowanie raportu

Możesz użyć tego raportu do udzielenia odpowiedzi na następujące pytania: Jaka jest jakość oprogramowania? Jak często testy kończą się pomyślnie i jaka część kodu jest testowana? W oparciu o kod i metryki testów, czy jest prawdopodobne, że zespół osiągnie zamierzony cel?

Wymagane są uprawnienia

Aby wyświetlić raport, użytkownik musi być przypisany lub należeć do grupy, która została ma przypisaną rolę przeglądarki w usługach Reporting Services. Aby uzyskać więcej informacji, zobacz Dodawanie użytkowników do zespołów i projektów.

Dane w raporcie

Dane wyświetlane w raporcie Wskaźniki jakości kompilacji są pochodne po hurtowni danych. Na osi X znajdują się określone kompilacje, które zawiera raport, na podstawie filtrów, które zostały ustawione dla platformy, konfiguracji oraz definicji kompilacji.

Każdy słupek pionowy reprezentuje zbiór danych, który jest pochodny po jednej lub więcej kompilacji. W wariancie raportu, dotyczącym rozmiaru kodu, wysokość słupka pionowego reprezentuje ilość zaewidencjonowanej bazy kodu. Słupki są skalowane, tak aby największy z nich pasował do wysokości wykresu. Testy ręczne mogą być uruchamiane w dowolnym czasie po kompilacji i są skojarzone z kompilacją. Testy, które nie zostały jeszcze uruchomione są liczone jako "niejednoznaczne."

Poniższa ilustracja pokazuje przykładowy raport Wskaźniki jakości kompilacji.

W poniższej tabeli opisano informacje, wyświetlane dla każdego wskaźnika jakości w raporcie:

Wskaźnik jakości	Opis
Aktywne usterki (liczba)	Wykres liniowy, przedstawiający liczbę usterek, które były aktywne w czasie kompilacji. Uwaga Błędy, które nie są jawnie skojarzone z kompilacjami.Niektóre liczone błędy mogą nie wpływać na kompilacje, które są wyświetlane na wykresie.Można użyć parametru Obszar aby filtrować usterki po obszarze produktu.Technika ta może pokazać usterki, które mają największą szansę wpłynąć na kompilacje w raporcie.
Postęp dokonany w kodzie (wiersze)	Wykres liniowy, który przedstawia liczbę wierszy kodu, które zespół dodał, usunął i zmienił w zaewidencjonowaniach przed kompilacją. Postęp dokonany w kodzie jest obliczany poprzez określenie liczby wierszy kodu, które zostały dodane, usunięte lub zmodyfikowane do kompilacji, podzieloną przez liczbę wszystkich wierszy w kompilacji.
Pokrycie kodu (procent)	Wykres liniowy, przedstawiający procent kodu, pokryty przez testy.
Niejednoznaczne testy	Szara część skumulowanego wykresu słupkowego, która wskazuje na liczbę testów, które się nie powiodły lub zostały zatrzymane. Jeśli kompilacja nie powiodła się, testy nie są liczone lub są liczone jako niejednoznaczne.
Testy zakończone niepomyślnie	Czerwona część skumulowanego wykresu słupkowego, która wskazuje na liczbę testów, których kompilacja zakończyła się niepowodzeniem.
Testy zakończone pomyślnie	Zielona część skumulowanego wykresu słupkowego, która wskazuje na liczbę testów, których kompilacja zakończyła się powodzeniem.

Uwaga

Aby uzyskać więcej informacji dotyczących znaczenia wyników testów kończących się niepowodzeniem lub powodzeniem, zobacz Postęp planu testów - Raport.

Możesz filtrować raport w następujący sposób:

• Zmień zakres osi X poprzez określenie liczby kompilacji oraz daty końcowej raportu. Data pierwszej pokazanej kompilacji będzie zależała od częstotliwości kompilacji.

• Filtruj zestaw kompilacji, które pokazuje raport, poprzez określenie platformy, konfiguracji oraz definicji kompilacji, które mają zostać zawarte w raporcie. Ustaw parametry w tej sekwencji, ponieważ zestaw dostępnych wartości dla definicji kompilacji zależy od platformy i konfiguracji.

• Filtruj błędy, które są zliczane w raporcie poprzez określenie zakresu produktu do dołączenia. Ten filtr nie wpływa na zestaw kompilacji, które pojawiają się na osi X dla postępu dokonanego w kodzie, pokrycia kodu lub wyników testu.

Aby uzyskać więcej informacji, zobacz Filtrowanie raportu w dalszej części tego tematu.

Wymagane aktywności testów i zarządzania kompilacją

Aby raport Wskaźniki jakości kompilacji był użyteczny i obrazował wszystkie wskaźniki jakości, które może wyświetlić, członkowie zespołu muszą wykonać następujące aktywności, aby zarządzać testami i kompilacjami:

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

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

• Utwórz definicje kompilacji. Możesz tworzyć wiele definicji kompilacji, które mogą być uruchamiane 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.

• Regularnie uruchamia kompilację. Możesz uruchamiać kompilacje w ustawionych 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.

Zmienianie liczby kompilacji w raporcie

Wyświetlanie raportu Wskaźniki jakości kompilacji będzie się różniło znacząco w zależności od liczby kompilacji, które zawiera raport oraz innych filtrów, które zostaną zastosowane w raporcie. Raport może zostać skoncentrowany na określonym zakresie kompilacji, poprzez zmianę liczby kompilacji, które mają się pojawiać w raporcie.

Aby ustawić liczbę kompilacji, które są reprezentowane w raporcie

1. W Liczba kompilacji, należy wpisać liczbę do zawarcia.

2. Należy kliknąć ikonę kalendarza obok Zakończenie (Data), a następnie wybrać datę, która odpowiada ostatniemu dniu, w którym uruchamiane były kompilacje, które mają zostać zawarte w raporcie.

3. Kliknij Wyświetl raport.

Interpretowanie raportu

Możesz przejrzeć raport, aby znaleźć odpowiedzi na następujące pytania, dotyczące dowolnej określonej definicji kompilacji:

• Jaka jest jakość oprogramowania?

• Czy zespół testuje wystarczającą ilość kodu?

• Czy testy są zaliczane?

• Czy prawdopodobne jest, że zespół zakończy prace w oparciu metryki kodu oraz testów?

• Jak często testy kończą się pomyślnie i jaka część kodu jest testowana?

  Uwaga

  Stosunek segmentów kolorowych do szarych odzwierciedla ułamek kodu, pokryty testami, podczas kiedy proporcje pomiędzy kolorowymi segmentami tylko w przybliżeniu odzwierciedlają ułamki kodu, które zdają testy lub nie.Ta niejednoznaczność spowodowana jest faktem, że ułamek zielonych spośród kolorowych segmentów reprezentuje liczbę zdanych testów.Pojedynczy błąd w jednej części kodu może spowodować zakończenie niepowodzeniem wielu testów lub jeden niezdany test może reprezentować obszerny błąd w projekcie, który ma konsekwencje w całej bazie kodu.

Zdrowa wersja raportu

Zdrowy raport Wskaźniki jakości kompilacji będzie pokazywał następujące wskaźniki:

• Większość testów jest zdana (duże zielone obszary) i kilka testów jest niezdanych (małe ilości czerwonego).

• Procent czerwonego jest mniejszy niż 20-30 procent.

Jak pokazuje następująca ilustracja, pokrycie kodu i odsetek zdanych testów są wysokie i wzrastające w czasie. Postęp dokonany w kodzie, aktywne usterki, testy niezdane i nierozstrzygające są niskie i malejące.

Niezdrowa wersja raportu Wskaźniki jakości kompilacji

Niezdrowa wersja raportu Wskaźniki jakości kompilacji pokazuje jeden lub więcej następujących wskaźników. Można zbadać przyczynę zgodnie z następującymi wskazówkami.

• Mniej pokrycie kodu i większy postęp dokonany w kodzie. Na poniższej ilustracji przedstawiono spadek pokrycia kodu i wzrost postępu dokonanego w kodzie. Te dane są jasnym ostrzeżeniem, że nowy kod jest zaewidencjonowany bez odpowiadających pokrywających go testów jednostkowych.

  

• Nisk wskaźnik uruchamianych testów. Poniższa ilustracja pokazuje niski wskaźnik uruchamianych testów. Dane te mogą wskazywać, że zespół nie wykonuje wystarczającej liczby testów. Ta blokada może wskazywać na brak zasobów lub fakt, że testerzy robią coś innego, takiego jak pisanie automatyzacji testów zamiast testowania bieżących funkcji. W obu przypadkach bilansowanie zasobów może być uzasadnione.

  

• Wysoki postęp dokonany w kodzie, niski wskaźnik pokrycia kodu. Wysoki postęp dokonany w kodzie sugeruje, że powstaną usterki, jako efekt uboczny zmian. W projekcie doskonale refaktoryzowanym można zobaczyć wysoki postęp dokonany w kodzie przy braku zmian w pokryciu kodu ani wskaźniku zdanych testów. W przeciwnym razie wysoki postęp dokonany w kodzie może wskazywać na zmniejszone pokrycie oraz potrzebę ponownego napisania testów.

  Poniższa ilustracja pokazuje wysoki wskaźnik postępu dokonanego w kodzie oraz niski wskaźnik pokrycia kodu testami, pomimo że wskaźnik zdanych testów pozostaje wysoki. Te dane wskazują na to, że testy, które są uruchamiane nie testują nowego kodu.

  

• Wysoki wskaźnik niezdanych testów. Na poniższej ilustracji przedstawiono, że wiele testów jest uruchamianych przy rozsądnym pokryciu kodu, jednak testy nie są zdawane. Dane te mogą wskazywać na luźne praktyki rozwoju lub, we wczesnych iteracjach, testy mogą być zbyt trudne dla tego etapu produktu.

  

  Niezdawane testy powinny być adresowane tak szybko, jak to możliwe. Jeśli naprawa kodu nie jest praktyczna, niezdawane testy powinny zostać czasowy wyłączone i usterka powinna zostać zapisana. Chociaż czasami jest akceptowalne, żeby traktować błędy analizy kodu jako mniej ważne na początku projektu, nie powinno się pozwolić aby czerwone sekcje rosły zbyt duże.

• Wysoki wskaźnik zdanych testów oraz wysoki wskaźnik aktywnych usterek. Na poniższej ilustracji przedstawiono wysoki wskaźnik zdanych testów, jednak nadal wysoki wskaźnik przychodzących usterek. Taka sytuacja może wystąpić z kilku powodów. Testy mogą nie być dostatecznie surowe dla tego etapu produktu.

  

  W wczesnych iteracjach proste testy są dobre, jednak w miarę dojrzewania produktu, testy powinny wykonywać szersze scenariusze oraz integracje. Testy mogą być przestarzałe, lub testowana może być niewłaściwa funkcjonalność. Może to być czas na zmianę technik testowania.

• Wzrastające wskaźniki zdanych testów i brak wzrostu w pokryciu kodu. Zwykle, jeśli uruchamiane jest więcej testów, więcej kodu powinno być pokryte. Z drugiej strony, jeśli wskaźniki wykonywanych oraz zdanych testów wzrastają bez odpowiadającej zmiany w pokryciu kodu, testy inkrementacyjne mogą być zbędne.

• Wzrasta liczba aktywnych usterek, ale liczba niezdanych testów nie wzrasta. Jeśli wzrasta liczba aktywnych usterek, ale testy nie pokazują odpowiadających porażek, najprawdopodobniej nie testują one tej samej funkcjonalności, która jest raportowana przez błędy.

• Zmniejsza się liczba aktywnych usterek, jednak nie wzrasta liczba zdanych testów. Jeżeli zmniejsza się liczba aktywnych usterek, jednak nie wzrastają wskaźniki zdanych testów, występuje ryzyko wzrastającego wskaźnika reaktywacji.

• Duże szare obszary. Szare segmenty oznaczają kod, który nie został skompilowany lub przetestowany w ramach podanej kompilacji. Te dane pojawiają się tylko w raporcie okresowym, gdzie jedna lub więcej określonych kompilacji nie pojawiła się w okresie.

Filtrowanie raportu

Można zastosować filtr raportu Wskaźniki jakości kompilacji na następujące sposoby:

• Zmieniaj przedział czasowy poprzez określenie liczby kompilacji oraz określenie końcowej daty dla raportu.

• Filtruj zestaw kompilacji, które są reprezentowane w raporcie, poprzez określenie platformy, konfiguracji oraz definicji kompilacji, które mają zostać zawarte w raporcie.

  Uwaga

  Można skonfigurować definicje kompilacji aby nie uruchamiały żadnych testów, uruchamiały niektóre testy lub wszystkie testy.Raport będzie się znacznie różnił w zależności od konfiguracji definicji kompilacji.

• Filtruj błędy, które są zliczane w raporcie poprzez określenie zakresu produktu do dołączenia.

Poniższa ilustracja przedstawia dostępne filtry:

Zastosuj filtry w sekwencji, którą określa następująca procedura. Opcje, które są dostępne w przypadku, gdy niektóre filtry zależą od wcześniej ustawionych filtrów.

Aby filtrować kompilacje, które pojawiają się w raporcie

1. W Liczba kompilacji, należy wpisać liczbę do zawarcia.

2. Należy kliknąć ikonę kalendarza obok Data zakończenia, a następnie wybrać ostatnią datę dla kompilacji do zawarcia.

3. Na liście Platforma zaznacz pole wyboru każdej platformy, którą chcesz uwzględnić.

4. Na liście Konfiguracja zaznacz pole wyboru każdej konfiguracji, którą chcesz uwzględnić.

5. Na liście Definicja kompilacji, zaznacz pole wyboru każdej definicji kompilacji, która ma zostać uwzględniona.

6. Kliknij Wyświetl raport.

Aby filtrować liczniki usterek, które są wyświetlane w raporcie

1. Na liście Obszar zaznacz pole wyboru każdego wyniku testu, który chcesz uwzględnić.

   W tym kroku raporty są filtrowane na podstawie hierarchii wyników testów.

2. Kliknij Wyświetl raport.

Zobacz też

Inne zasoby

Raporty (SQL Server Reporting Services )