Co to jest gęstość defektów? Wzór do obliczenia na przykładzie
Tomasza Hamiltona
⚡ Inteligentne podsumowanie
Gęstość defektów to miara liczby potwierdzonych defektów w module oprogramowania podzielona przez rozmiar tego modułu, zwykle wyrażana na tysiąc linii kodu, i sygnalizuje, czy kompilacja jest gotowa do wydania.
Co to jest gęstość defektów?
Gęstość defektów to liczba defektów potwierdzonych w oprogramowaniu lub module w określonym okresie eksploatacji lub rozwoju, podzielona przez rozmiar tego oprogramowania lub modułu. Pozwala zespołowi zdecydować, czy oprogramowanie jest gotowe do wydania.
Gęstość defektów jest liczona na tysiąc linii kodu, co jest znane również jako KLOC. Ponieważ liczba ta jest znormalizowana względem rozmiaru, duży moduł z wieloma defektami i mały moduł z niewielką liczbą defektów można porównać w tej samej skali, co nigdy nie jest możliwe przy samej liczbie błędów.
Metryka jest zazwyczaj raportowana na końcu cyklu testowego i tracwydanie nad wydaniem, więc jest ono umieszczone obok reszty proces zarządzania defektami cykl życia testowania oprogramowania.
Jak obliczyć gęstość defektów
Wzór na pomiar gęstości defektów:
Defect Density = Defect count/size of the release
Wielkość wydania można zmierzyć w odniesieniu do linii kodu (LOC).
O tym, czy otrzymana liczba ma jakiekolwiek znaczenie, decydują trzy szczegóły:
- Jednostka rozmiaru. LOC i KLOC to najpopularniejsze jednostki. Punkty funkcyjne są używane tam, gdzie zespoły chcą, aby miara rozmiaru nie zmieniała się w zależności od języka programowania, a niektóre zespoły zamiast tego normalizują ją według modułu lub komponentu.
- Co uznaje się za wadę. W liczniku uwzględniane są tylko potwierdzone defekty. Duplikaty, odrzucone raporty i prośby o ulepszenia muszą zostać wykluczone, w przeciwnym razie liczba ta wzrośnie bez wpływu na jakość kodu.
- Okienko pomiarowe. Wady wykryte podczas testów systemu, podczas testy regresji, a po wydaniu opisują różne rzeczy, więc okres musi być podany za pomocą liczby.
Przykład gęstości defektów
Załóżmy, że Twój produkt programowy składa się z 3 modułów. W każdym module wykryto następującą liczbę błędów:
- Moduł 1 = 10 błędów
- Moduł 2 = 20 błędów
- Moduł 3 = 10 błędów
Łączna liczba błędów = 10+20+10 = 40
Całkowita liczba wierszy kodu dla każdego modułu wynosi:
- Moduł 1 = 1000 LOC
- Moduł 2 = 1500 LOC
- Moduł 3 = 500 LOC
Całkowita linia Code = 1000+1500+500 = 3000
Gęstość defektów oblicza się jako:
Defect Density = 40/3000 = 0.013333 defects/loc = 13.333 defects/Kloc
Takie samo obliczenie zastosowane dla każdego modułu jest bardziej przydatne niż łączna liczba, jak pokazuje poniższy wykres: Moduł 2 zawiera 20 defektów w 1500 LOC, a Moduł 3 zawiera 10 defektów w zaledwie 500 LOC, więc Moduł 3 jest gęstszy i bardziej ryzykowny z tych dwóch, mimo że zgłosił mniej błędów.
Standard gęstości defektów
Nie ma ustalonego standardu gęstości defektów. Badania sugerują, że ulegnie awarii? na tysiąc linii kodu jest powszechnie uznawana za wskaźnik dobrej jakości projektu i jest to najczęściej cytowana w branży reguła.
Oczekiwania zmieniają się wraz z domeną. Oprogramowanie krytyczne dla bezpieczeństwa i podlegające regulacjom, takie jak awionika i urządzenia medyczne, jest utrzymywane na poziomie znacznie poniżej jednego defektu na KLOC, podczas gdy zwykłe aplikacje biznesowe rutynowo go przekraczają. Ponieważ zasady liczenia, jednostki wielkości i głębokość testów różnią się w zależności od organizacji, benchmark pochodzący z opublikowanego badania jest porównywalny tylko z projektem, który mierzy w ten sam sposób. Praktyczne zastosowanie tej metryki ma zatem charakter wewnętrzny: należy porównać wersję z poprzednią wersją tego samego produktu, zmierzoną identycznie.
Czynniki wpływające na gęstość defektów
Ta sama baza kodu może generować bardzo różne wskaźniki gęstości defektów w zależności od następujących czynników:
- Code złożoność. Głęboko zagnieżdżona logika i wysoka złożoność cyklomatyczna generują więcej błędów na linię niż prosty kod.
- Rodzaj branych pod uwagę wad. Zliczanie wyłącznie defektów funkcjonalnych lub uwzględnianie użyteczności, dokumentacji i niefunkcjonalny wyniki, zmieniają licznik w sposób istotny.
- Rozważany okres czasu. Wyniki uzyskane w dwutygodniowym cyklu testowym nie są porównywalne z wynikami uzyskanymi w ciągu sześciu miesięcy użytkowania produkcyjnego.
- Umiejętności programisty i testera. Doświadczeni programiści zgłaszają mniej błędów, a doświadczeni testerzy znajdują więcej istniejących, więc oba efekty zaniżają metrykę w przeciwnych kierunkach.
- Pokrycie testowe. Wady, których nigdy nie szukano, nigdy nie są brane pod uwagę, więc pokrycie testu po cichu ogranicza maksymalną możliwą gęstość.
Gęstość defektów a inne wskaźniki defektów
Gęstość Defektów odpowiada na jedno pytanie: jak skoncentrowane są znane defekty. Trzy towarzyszące metryki odpowiadają na pytania, na które nie potrafi odpowiedzieć, a większość zespołów raportuje je łącznie.
| metryczny | Co mierzy | Pytanie, na które odpowiada |
| Gęstość defektów | Potwierdzone defekty podzielone według rozmiaru (KLOC lub punkty funkcyjne) | Które moduły mają najwięcej defektów w stosunku do swojego rozmiaru? |
| Wyciek wady | Usterki wykryte po wydaniu jako udział wszystkich usterek | Ile z nich umknęło procesowi testowania i dotarło do użytkowników? |
| Efektywność usuwania wad | Wady usunięte przed wydaniem jako część wszystkich wad | Jak skuteczne było testowanie pod kątem wykrycia defektów na czas? |
| Wskaźnik ważności wady | Wady ważone według stopnia zaawansowania, a nie liczone równo | Jak poważne są wady, a nie tylko ile ich jest? |
Rozważane łącznie, te cztery elementy dają pełniejszy obraz: niska gęstość defektów i wysoka liczba wycieków defektów wskazują na płytkie testowanie, a nie na czysty kod, a to jest właśnie błędne odczytanie, przed którym ostrzega kolejna sekcja.
Zalety gęstości defektów
Oto zalety gęstości defektów:
- Pomaga mierzyć skuteczność testów.
- Pomaga rozróżnić koncentrację defektów pomiędzy komponentami i modułami oprogramowania.
- Jest ona przydatna do identyfikowania obszarów wymagających korekty lub udoskonalenia.
- Jest to przydatne przy wskazywaniu komponentów wysokiego ryzyka, które mają bezpośredni wpływ na testowanie oparte na ryzyku.
- Pomaga w określaniu potrzeb szkoleniowych różnych zasobów.
- Może to być pomocne przy szacowaniu nakładu pracy na testowanie i przeróbki spowodowane defektami.
- Potrafi oszacować pozostałe błędy w oprogramowaniu.
- Przed udostępnieniem produktu warto ocenić, czy dotychczasowe testy są wystarczające.
- Tworzy historyczną bazę odniesienia, względem której można porównywać późniejsze wydania.
Ograniczenia gęstości defektów
Metrykę łatwo obliczyć i łatwo ją błędnie zinterpretować. Poniższe ograniczenia decydują o tym, jaką wagę należy jej przypisać w decyzji o wydaniu:
- Niewykryte wady są niewidoczne. Licznik zawiera tylko błędy faktycznie wykryte podczas testów, więc słabo przetestowany moduł raportuje pochlebne wyniki.
- Powaga sytuacji jest ignorowana. Jedna wada, która psuje płatność i jeden problem z dopasowaniem kosmetycznym liczą się tak samo, dlatego też oprócz nich potrzebny jest widok ważony według ważności.
- Definicje wad są różne. Wyniki osiągane przez dwa zespoły, które liczą inaczej, są nieporównywalne, nawet w obrębie tej samej organizacji.
- Linie kodu są słabym wskaźnikiem rozmiaru. Kod rozbudowany zmniejsza gęstość, nie poprawiając niczego, a jednostka ta nie jest porównywalna w różnych językach programowania.
- Można manipulować tymi wskaźnikami. Odrzucenie raportów granicznych lub zawyżenie liczby wierszy poprawia wynik bez poprawy jakości produktu.
Nic z tego nie czyni wskaźnika Defect Density bezużytecznym. Sprawia on, że wskaźnik ten jest wskaźnikiem trendu dla jednego produktu, mierzonym w sposób spójny, a nie punktem odniesienia pozwalającym porównywać zespoły ze sobą.
Jak zmniejszyć gęstość defektów
Obniżenie gęstości defektów w praktyce, a nie tylko na papierze, oznacza wcześniejsze zapobieganie defektom i wykrywanie pozostałych przed udostępnieniem produktu. Poniższe praktyki powtarzają się w publikowanych wytycznych:
- Przenieś testowanie wcześniej. Zaangażowanie testerów na etapie wymagań i projektowania pozwala wychwycić niejednoznaczności zanim przekształcą się w kod, a to właśnie w tym etapie usuwanie błędów jest najtańsze.
- Revobejrzyj kod przed scaleniem. Recenzja ekspercka pozwala wykryć błędy logiczne, błędne odczytanie wymagań i wady projektowe, których nie można test jednostkowy zostało napisane, aby szukać.
- Zautomatyzuj zestaw narzędzi regresyjnych. Przeprowadzanie kontroli przy każdym zatwierdzeniu ciągła integracja zapobiega pojawianiu się starych defektów podczas pisania nowego kodu.
- Najpierw napisz testy. Rozwój oparty na testach wymusza określenie każdego zachowania przed jego wdrożeniem, oraz testowanie mutacji może następnie potwierdzić, że wyniki testów rzeczywiście coś wykazują.
- Zastosuj analizę statyczną. Automatyczne skanowanie kodu wykrywa odwołania do null, wycieki zasobów i obszary o dużej złożoności przed uruchomieniem jakiegokolwiek testu.
- Przebuduj gęste moduły. Po zidentyfikowaniu przez funkcję Defect Denity najgorszych komponentów, ich podział i uproszczenie zazwyczaj redukuje zarówno złożoność, jak i liczbę defektów.
- Wprowadź wady z powrotem do procesu. Analiza przyczyn źródłowych podczas retrospektyw pozwala przekształcić pojedyncze defekty w naprawy procesów, a nie jednorazowe poprawki.
Tracwydanie ponad wydaniem obok techniki testowania oprogramowania i danych o zasięgu, Defect Density staje się systemem wczesnego ostrzegania, a nie raportem.
