Analiza niepowodzenia - Raport w programie Excel

Możesz użyć raportu Analiza błędów, aby pomóc monitorować ilość regresji znajdowanych przez zespół testowy.Regresje są błędami w oprogramowaniu, które testujesz, a które nie pojawiły się w poprzednich wersjach.Zespół, który wykonuje testowanie regresji, w szczególności koncentruje się na wyszukiwaniu błędów, które pojawiły się tylko w nowej wersji oprogramowania.Raport Analizy błędów pokazuje, ile różnych konfiguracji dla każdego Przypadku testowego wcześniej zakończonych powodzeniem teraz kończy się niepomyślnie, w ciągu ostatnich czterech tygodni.

Ten raport jest dostępny tylko jeśli zespół utworzy plany testów i uruchomi je przy użyciu Microsoft Test Manager.Aby uzyskać informacje dotyczące sposobu określania zestawów testów i planów testów, zobacz Planowanie ręcznych testów za pomocą systemu Team Web Access.Aby uzyskać więcej informacji na temat dostępu do tego raportu, zobacz Excel — raporty.

[!UWAGA]

Możesz wyświetlić raport Analizy awarii z pulpitu nawigacyjnego Test.Możesz uzyskać dostęp do tego pulpitu nawigacyjnego tylko wtedy, gdy Twój portal projektu zespołowego został włączony i jest skonfigurowany do korzystania z programu SharePoint Server Enterprise Edition.

Wymagane są uprawnienia

Aby wyświetlić raport, 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ć lub dostosować raport, musisz być członkiem roli zabezpieczeń TfsWarehouseDataReaders w Analysis Services SQL Server.Użytkownik musi być przypisany lub należeć do grupy, która ma przypisane uprawnienia Członkowie dla projektu zespołu w Produkty SharePoint.Aby uzyskać więcej informacji, zobacz Udzielenie dostępu do bazy danych magazynu Visual Studio Informatykami.

Dane w raporcie

Raport Analizy błędów zapewnia skumulowany warstwowy wykres, który pokazuje skumulowaną liczbę wyników dla wszystkich zakończonych niepowodzeniem przypadków testowych, dla wszystkich konfiguracji, w ciągu ostatnich czterech tygodni.Typy błędów to Nowy problem, Znany problem lub Regresja.

Ten raport jest oparty na raporcie wykresu przestawnego, który pokazuje wyniki testów z ostatnich czterech tygodni, przechowywane w magazynie danych.

System sprawdza każdą konfigurację, dla której przeprowadzony został Przypadek testowy i próbuje zidentyfikować wynik poprzednika dla tej samej konfiguracji dla Przypadku testowego.Typ awarii, przypisany do Przypadku testowego/konfiguracji jest określany na podstawie następujących kryteriów:

• Regresja: Kiedy wynik bezpośredniego poprzednika był wynikiem Zakończony powodzeniem.

• Nowy problem: kiedy nie można znaleźć żadnego wyniku będącego bezpośrednim poprzednikiem.

• Znany problem: Kiedy wynik bezpośredniego poprzednika był wynikiem Zakończony niepowodzeniem.

Wymagane działania związane z monitorowaniem regresji

Aby raporty z analizą niepowodzeń były użyteczne i dokładne, zespół musi wykonać następujące działania:

• Zdefiniuj przypadki testowe i 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.

Interpretowanie raportu

Powinieneś się spodziewać, że Raport analizy awarii będzie się różnić w zależności od tego, gdzie jesteś w cyklu rozwoju produktu.Wczesne iteracje powinny wykazywać niewielkie działanie regresywne, jeśli w ogóle.W dalszej części cyklu projektowania należy się spodziewać kilku regresji.Powinieneś przejrzeć raport, aby znaleźć odpowiedzi na następujące pytania:

• Ile testów ogólnie się cofa?

• Czy zespół utrzymuje ogólną liczbę regresji lub awarii testów w ramach oczekiwanych zakresów lub celi zespołu?

• Czy zespół zajmuje się problemami na bieżąco po ich zidentyfikowaniu?Czy znane problemy są rozwiązywane w sposób terminowy?

Właściwy raport analizy awarii pokaże umiarkowaną liczbę nowych problemów, znanych problemów i regresji.Jeśli występują skoki w jednym lub więcej z tych obszarów, zespół może być zmuszony do dalszego badania.Wartości graniczne mogą wskazywać problemy w działaniu testów lub jakości kodu, który zespół ewidencjonuje.

Ponadto można sprawdzić status najnowszych wersji, status błędu i zmian kodu, aby ustalić, czy metryki dla każdego z tych wskaźników mogą pomóc w wyjaśnieniu zmian w wierszach testu aktywności.

Aktualizowanie i dostosowywanie raportów

Możesz aktualizować raport Analiza błędów, otwierając go w Office Excel i zmieniając opcje filtra dla raportu tabeli przestawnej.Możesz dostosować ten raport, aby obsługiwał inne widoki, zgodnie z opisem w poniższej tabeli.

Aby uzyskać więcej informacji na temat pracy z raportami PivotTables i PivotChart oraz ich dostosowywania, zobacz następujące strony w witrynie sieci Web firmy Microsoft:

• Sposoby dostosowywania raportów tabeli przestawnej

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

• Opublikuj skoroszyt w Excel Services

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

Zobacz też

Inne zasoby

Excel — raporty