Jednym z wariantów testów jednostkowych jest analiza ścieżek, która polega na
A. określeniu punktu początkowego i końcowego oraz badaniu możliwych dróg pomiędzy tymi punktami.
B. utworzeniu kilku zbiorów danych o podobnym sposobie przetwarzania i użyciu ich do przeprowadzenia testu.
C. testowaniu obiektów pod względem inicjacji i zwolnienia zarezerwowanej pamięci.
D. testowaniu wartości brzegowych zbioru danych.
Pytanie z egzaminu CKE, czerwiec 2020 (arkusz EE.09-SG-20.06).
Analiza ścieżek w testach jednostkowych polega właśnie na wyznaczeniu punktu startowego i końcowego w kodzie, a potem sprawdzaniu możliwych dróg wykonania programu między tymi miejscami. To jest typowe podejście z grupy testów strukturalnych, czyli white-box testing, gdzie tester albo programista zna kod źródłowy i patrzy na jego logikę od środka. W praktyce bierze się np. funkcję z instrukcjami if, pętlami i wyjątkami, tworzy się graf przepływu sterowania, a następnie dobiera dane testowe tak, żeby przejść przez różne gałęzie programu. Moim zdaniem to jedna z sensowniejszych technik przy testowaniu bardziej złożonych metod, bo szybko pokazuje miejsca, których zwykłe testy mogłyby nie dotknąć. Dobre praktyki, znane też z podejścia ISTQB i ogólnych zasad inżynierii oprogramowania, zalecają mierzenie pokrycia kodu, np. pokrycia instrukcji, decyzji albo gałęzi. Dzięki analizie ścieżek można wykryć martwy kod, błędne warunki logiczne, nieobsłużone przypadki wyjątkowe i sytuacje, w których program zachowuje się poprawnie tylko dla najprostszego scenariusza. Przykład: jeśli funkcja logowania inaczej działa dla poprawnego hasła, zablokowanego konta i pustego formularza, to analiza ścieżek pomaga zaplanować testy dla każdej z tych dróg, a nie tylko dla jednego szczęśliwego przebiegu.
W tym pytaniu łatwo pomylić kilka różnych technik testowania, bo wszystkie występują w praktyce programistycznej i każda z nich może być używana przy testach jednostkowych. Testowanie wartości brzegowych dotyczy przede wszystkim danych wejściowych i sprawdzania zachowania programu na granicach dopuszczalnych zakresów, na przykład dla wieku 17, 18 i 19 lat albo dla pola o maksymalnej długości 255 znaków. To bardzo użyteczna technika, ale nie opisuje analizy ścieżek, bo nie skupia się na przebiegu sterowania w kodzie, tylko na dobraniu szczególnie ryzykownych wartości danych.
Sprawdzanie inicjacji obiektów i zwalniania pamięci odnosi się raczej do poprawnego zarządzania zasobami, szczególnie w językach takich jak C, C++ albo w systemach, gdzie wycieki pamięci są realnym problemem. W testach jednostkowych można oczywiście badać, czy obiekt został poprawnie utworzony, czy zamknięto plik, połączenie sieciowe albo uchwyt do bazy danych. Jednak to nadal nie jest analiza ścieżek, tylko kontrola cyklu życia obiektów i zasobów.
Tworzenie kilku zbiorów danych o podobnym sposobie przetwarzania przypomina bardziej podział na klasy równoważności. Chodzi tam o to, że skoro wiele danych powinno być obsługiwanych tak samo, to wybiera się reprezentatywne przykłady zamiast testować wszystko po kolei. Typowy błąd myślowy polega na tym, że każdą technikę doboru danych testowych traktuje się jako analizę ścieżek. A tu sedno jest inne: trzeba patrzeć na strukturę kodu, warunki, pętle, instrukcje wyboru i możliwe drogi od wejścia do wyjścia funkcji. Z mojego doświadczenia wynika, że gdy narysuje się prosty graf przepływu programu, różnica robi się od razu bardziej oczywista.
Sprawdzanie inicjacji obiektów i zwalniania pamięci odnosi się raczej do poprawnego zarządzania zasobami, szczególnie w językach takich jak C, C++ albo w systemach, gdzie wycieki pamięci są realnym problemem. W testach jednostkowych można oczywiście badać, czy obiekt został poprawnie utworzony, czy zamknięto plik, połączenie sieciowe albo uchwyt do bazy danych. Jednak to nadal nie jest analiza ścieżek, tylko kontrola cyklu życia obiektów i zasobów.
Tworzenie kilku zbiorów danych o podobnym sposobie przetwarzania przypomina bardziej podział na klasy równoważności. Chodzi tam o to, że skoro wiele danych powinno być obsługiwanych tak samo, to wybiera się reprezentatywne przykłady zamiast testować wszystko po kolei. Typowy błąd myślowy polega na tym, że każdą technikę doboru danych testowych traktuje się jako analizę ścieżek. A tu sedno jest inne: trzeba patrzeć na strukturę kodu, warunki, pętle, instrukcje wyboru i możliwe drogi od wejścia do wyjścia funkcji. Z mojego doświadczenia wynika, że gdy narysuje się prosty graf przepływu programu, różnica robi się od razu bardziej oczywista.