Redakcja
W sylabusie ISTQB® CT-AI możemy znaleźć takie oto stwierdzenie:
„It should be noted, however, that despite statement and decision coverage having been used for over 50 years, there is also little objective evidence of their relative effectiveness, even though they have been mandated for measuring coverage of software in safety-related applications, such as medical devices and avionics systems.”
Co w wolnym tłumaczeniu mogłoby brzmieć: „Należy zauważyć, że pomimo stosowania pomiarów pokrycia instrukcji i decyzji od ponad 50 lat, istnieje niewiele obiektywnych dowodów na ich względną skuteczność, mimo że są one obowiązkowe w przypadku pomiaru pokrycia oprogramowania w aplikacjach krytycznych pod względem bezpieczeństwa, takich jak urządzenia medyczne i systemy awioniczne”.
Tak. Testowanie białoskrzynkowe ma swoje ograniczenia, o których ciągle musimy pamiętać.
Przykładowo pokrycie instrukcji zapewnia jedynie, że każdy wiersz kodu zostanie wykonany co najmniej raz, ale nie gwarantuje, że wszystkie możliwe ścieżki wykonania lub gałęzie zostaną przetestowane. Oznacza to, że niektóre warunki logiczne mogą pozostać nieprzetestowane, szczególnie w punktach decyzyjnych, takich jak struktury if-else, co potencjalnie może prowadzić do pominięcia błędów w nieprzetestowanych gałęziach.
Pokrycie decyzji wymaga przetestowania zarówno wyników true, jak i false dla każdego punktu decyzyjnego, ale nadal nie obejmuje wszystkich możliwych kombinacji warunków w ramach złożonych decyzji (co jest rozwiązywane przez bardziej zaawansowane kryteria, takie jak pokrycie wielu warunków lub pokrycie zmodyfikowanego warunku/decyzji).
Osiągnięcie wysokiego procentowego pokrycia nie gwarantuje, że oprogramowanie jest wolne od defektów; przypadki skrajne lub określone scenariusze wejściowe mogą nie zostać wyzwolone przez testy, nawet jeśli metryki pokrycia wyglądają dobrze.
Pokrycie instrukcji ignoruje logikę podejmowania decyzji, co może prowadzić do fałszywego zaufania, ponieważ wszystkie wiersze kodu są uruchamiane, ale nie wszystkie wyniki decyzji są rygorystycznie testowane.
Te kryteria pokrycia nie uwzględniają kontekstu ani jakości danych wejściowych, dlatego nie są w stanie wykryć, czy pewne wartości wejściowe prowadzące do defektów zostały przetestowane. Co więcej techniki białoskrzynkowe jedynie w niewielkim zakresie używają danych testowych. To może znaczyć, że np. nie wychwycimy dzielenia przez zero.
Choć ISTQB® zaczyna negować techniki białoskrzynkowe to należy pamiętać również o ich zaletach, jak np. że każda linia kodu jest wykonywana co najmniej raz podczas testowania, pomagając zidentyfikować martwe obszary kodu. Pozwala to na lepszą jakość kodu poprzez ujawnienie kodu redundantnego lub niedostępnego. Oba typy pokrycia pomagają zoptymalizować przypadki testowe i łatwość utrzymania, wskazując kod wymagający skupienia na testowaniu, co umożliwia efektywną alokację zasobów testowych.
Nie rezygnujmy z nich!
