Metryki testowania oprogramowania: co to jest, typy i przykłady
Tomasza Hamiltona
⚡ Inteligentne podsumowanie
Metryki testowania oprogramowania to ilościowe miary postępu, jakości i produktywności procesu testowania. W tym przewodniku omówiono trzy typy metryk, rozróżnienie bazowe i obliczeniowe, cykl życia metryk oraz słownik formuł, które można zastosować bezpośrednio.
Czym są metryki testowania oprogramowania?
Metryki testowania oprogramowania to miary ilościowe stosowane do szacowania postępu, jakości, produktywności i kondycji procesu testowania oprogramowania. Celem metryk testowania oprogramowania jest poprawa wydajności i efektywności procesu testowania oprogramowania oraz pomoc w podejmowaniu lepszych decyzji dotyczących dalszego procesu testowania poprzez dostarczenie wiarygodnych danych o procesie testowania.
Metryka wyraża, w ujęciu ilościowym, stopień, w jakim system, komponent lub proces posiada daną cechę. Prostą analogią jest porównanie rzeczywistego tygodniowego zużycia paliwa przez samochód z wartością podawaną przez producenta.
Metryki testowania oprogramowania — poprawia wydajność i skuteczność procesu testowania oprogramowania.
Metryki testowania oprogramowania lub pomiar testów oprogramowania to ilościowe wskazanie zakresu, wydajności, wymiaru, ilości lub rozmiaru jakiegoś atrybutu procesu lub produktu.
Przykład pomiaru testowego oprogramowania: Całkowita liczba defektów
Dlaczego wskaźniki testowe są ważne?
„Nie możemy ulepszyć tego, czego nie możemy zmierzyć”. Metryki testowe mają na celu umożliwienie pomiaru procesu testowania.
- Zdecyduj, jaki powinien być kolejny etap działań
- Przedstaw dowody na poparcie twierdzenia lub prognozy dotyczącej jakości
- Określ, jaki rodzaj poprawy jest wymagany
- Uzasadnij zmianę procesu lub technologii
Przeczytaj więcej na ten temat Znaczenie metryk testowych
Rodzaje metryk testowych
- Metryki procesu: Można go zastosować do poprawy wydajności procesu SDLC (Cykl życia rozwoju oprogramowania)
- Dane produktu: Zajmuje się jakością oprogramowania
-
Metryki projektu: Można go wykorzystać do pomiaru efektywności zespołu projektowego lub dowolnego innego narzędzia testowe wykorzystywane przez członków zespołu
Wybór odpowiednich wskaźników jest ważniejszy niż ich gromadzenie. Zanim zdecydujesz się na konkretny zestaw, rozważ następujące kwestie:
- Ustal grupę docelową przygotowania metryk
- Zdefiniuj cel dla metryk
- Wprowadź wszystkie istotne wskaźniki w oparciu o potrzeby projektu
- Zważ koszty i korzyści każdej metryki oraz fazę cyklu życia projektu, w której zapewnia ona największą wartość
Metryki testów ręcznych
In Inżynieria oprogramowaniaMetryki testów ręcznych dzielą się na dwie klasy
- Podstawowe dane
- Obliczone dane
Metryki podstawowe to surowe dane zebrane przez Analityka Testów podczas opracowywania i wykonywania przypadku testowego (Liczba wykonanych przypadków testowych, liczba przypadków testowych). Natomiast obliczone metryki pochodzą z danych zebranych w metrykach podstawowych. Menedżer testów zwykle korzysta z obliczonych metryk w celu raportowania testów (% ukończenia, % zasięgu testu).
W zależności od projektu lub modelu biznesowego, najważniejsze wskaźniki to zazwyczaj:
- Wskaźniki produktywności wykonania przypadków testowych
- Wskaźniki produktywności przygotowania przypadków testowych
- Metryki defektów
- Wady według priorytetu
- Wady według wagi
- Wadliwy współczynnik poślizgu
Metryki testów ręcznych i automatycznych
Opisane powyżej metryki zakładają ręcznie wykonywany pakiet. Pakiet zautomatyzowany jest mierzony inaczej, ponieważ nakład pracy związany z wykonaniem nie stanowi już ograniczenia.
| kryteria | Metryki testowania ręcznego | Metryki testów automatycznych |
|---|---|---|
| Głowny cel | Postęp wysiłku i wykonania | Zasięg, stabilność i czas działania |
| Typowy pomiar | Liczba przypadków testowych wykonanych dziennie | Procent pokrycia automatyzacji |
| Sygnał jakości | Liczba usterek znalezionych na godzinę testu | Niestabilna częstotliwość testów, udział niestabilnych testów |
| Miara kosztów | Godziny testera | Godziny konserwacji skryptu na wydanie |
| Miernik prędkości | Czas trwania cyklu w dniach | Czas wykonania pakietu w minutach |
Automation Coverage = (Test cases automated / Total test cases) x 100 Flaky Test Rate = (Tests with inconsistent results / Total automated tests) x 100
Na szczególną uwagę zasługuje niestabilna częstotliwość testów. Gdy przekroczy ona około 5%, zespoły zaczynają ignorować kompilacje „czerwone”, a w tym momencie pakiet przestaje dostarczać informacji, niezależnie od poziomu pokrycia.
Cykl życia metryk testowych w inżynierii oprogramowania
| Różne etapy cyklu życia metryk | Kroki na każdym etapie |
|---|---|
| Analiza |
|
| Komunikacja |
|
| Ocena |
|
| Zgłoś |
|
Jak obliczyć metrykę testową
| Pan# | Kroki testowania metryk | Przykład |
|---|---|---|
| 1 | Zidentyfikuj klucz Testowanie oprogramowania procesy, które należy zmierzyć | Postęp testowania trackrólewski proces |
| 2 | Na tym etapie tester wykorzystuje dane jako punkt odniesienia do zdefiniowania metryk | Liczba przypadków testowych planowanych do wykonania dziennie |
| 3 | Określenie informacji, które mają być przestrzegane, częstotliwość trackról i osoba odpowiedzialna | Rzeczywista liczba wykonanych testów w ciągu dnia zostanie zarejestrowana przez menedżera testów na koniec dnia |
| 4 | Efektywne obliczanie, zarządzanie i interpretacja zdefiniowanych wskaźników | Rzeczywista liczba przypadków testowych wykonanych dziennie |
| 5 | Zidentyfikuj obszary wymagające poprawy w zależności od interpretacji zdefiniowanych wskaźników | If walizka testowa wykonanie jest poniżej ustalonego celu, zbadaj przyczynę i zaproponuj środki naprawcze |
Przykład obliczenia metryki testowej
Weźmy za przykład procent wykonanych przypadków testowych. Aby wyrazić stan wykonania w procentach, użyj wzoru:
Percentage test cases executed= (No of test cases executed/ Total no of test cases written) X 100
Jeśli napisano 250 przypadków testowych i wykonano 175, wynik wynosi (175 / 250) x 100 = Wzrost o 70.
Ten sam schemat dotyczy każdego innego parametru wykonania: przypadków testowych niewykonanych, zaliczonych, nieudanych i zablokowanych. Każdy z nich to po prostu inny licznik w tym samym mianowniku.
Najważniejsze wskaźniki testowe Track
W słowniczku na końcu tego samouczka wymieniono wszystkie powszechnie używane formuły. W praktyce, w pakiecie raportowym rzadko potrzeba ich więcej niż osiem. To właśnie one konsekwentnie wpływają na podejmowanie decyzji.
| metryczny | Na co odpowiada | Uważaj na |
|---|---|---|
| Procent wykonania przypadku testowego | Na jakim etapie zaplanowanego biegu jesteśmy? | Nie mówi nic o jakości, tylko o postępie |
| Gęstość defektów | Defekty na jednostkę rozmiaru, więc który moduł jest najsłabszy? | Zależy od stałego pomiaru rozmiaru |
| Efektywność usuwania wad | Jaką część usterek wykryliśmy przed premierą? | Można sfinalizować dopiero po otrzymaniu danych produkcyjnych |
| Wyciek defektów | Ile usterek dotarło do klienta? | Najważniejszy pojedynczy sygnał jakości |
| Pokrycie testowe | W jakim stopniu wymagania są realizowane? | Wysoki poziom pokrycia przy słabych twierdzeniach niczego nie dowodzi |
| Wskaźnik ważności wady | Czy otwarte ubytki są poważne czy kosmetyczne? | Liczenie wad bez ważenia wprowadza w błąd |
| Średni czas naprawy | Jak szybko zespół jest w stanie naprawić usterkę? | Zniekształcony przez kilka długotrwałych wad |
| Produktywność wykonywania testów | Ile przypadków dziennie rozwiązuje tester? | Zachęca do płytkich testów, jeśli jest używany jako cel |
Warto dodać do słownika dwie formuły, ponieważ to właśnie o nie prosi kadra zarządzająca:
Defect Removal Efficiency = (Defects found before release / Total defects found) x 100
Defect Leakage = (Defects found in production / Defects found before release) x 100
Pułapka pomiaru. Każda metryka używana jako cel przestaje być dobrą miarą. Ustaw cel produktywności na 30 przypadków testowych dziennie, a testerzy napiszą 30 trywialnych przypadków. Raportuj metryki jako zbiór, nigdy w izolacji, i zestawiaj każdą wartość produktywności z wartością jakości.
Słownik wzorów metryk testowania oprogramowania
- Współczynnik wysiłku związanego z przeróbką = (Rzeczywisty wysiłek włożony w przeróbki w tej fazie/całkowity faktyczny wysiłek włożony w tę fazę) X 100
- Pełzanie wymagań = (Całkowita liczba dodanych wymagań/liczba wymagań początkowych)X100
- Odchylenie harmonogramu = (Rzeczywista data dostawy – planowana data dostawy)
- Koszt znalezienia wady podczas testowania = (Całkowity wysiłek włożony w testowanie/defekty wykryte podczas testowania)
- Przesunięcie harmonogramu = (Rzeczywista data zakończenia – szacowana data zakończenia) / (Planowana data zakończenia – planowana data rozpoczęcia) X 100
- Procent zaliczonych przypadków testowych = (Liczba zaliczonych testów/całkowita liczba wykonanych testów) X 100
- Procent nieudanych przypadków testowych = (Liczba nieudanych testów/całkowita liczba wykonanych testów) X 100
- Procent zablokowanych przypadków testowych = (Liczba zablokowanych testów/całkowita liczba wykonanych testów) X 100
- Naprawiono procent defektów = (Usterki naprawione/Zgłoszone wady) X 100
- Procent zaakceptowanych wad = (Wady uznane za ważne przez zespół programistów / Całkowita liczba zgłoszonych usterek) X 100
- Odroczony procent wad = (Wady odroczone do przyszłych wersji / Całkowita liczba zgłoszonych usterek) X 100
- Procent wad krytycznych = (Wady krytyczne / Całkowita liczba zgłoszonych usterek) X 100
- Średni czas naprawy defektów przez zespół programistów = (Całkowity czas potrzebny na poprawki błędów/liczba błędów)
- Liczba testów przeprowadzonych w danym okresie = Liczba przebiegów testów/całkowity czas
- Testuj efektywność projektowania = Liczba zaprojektowanych testów / Całkowity czas
- Skuteczność przeglądu testów = Liczba przejrzanych testów / Całkowity czas
- Współczynnik znajdowania błędówlub defektów na godzinę testu = Całkowita liczba defektów / Całkowita liczba godzin testu
