Inżynieria oprogramowania
Projektowanie systemów informatycznych
Dr inż. Lucjan Miękina
upel.agh.edu.pl/wimir/login/
Katedra Robotyki i Mechatroniki
May 12, 2014
1/1
Testowanie
Metody testowania
Metody strukturalne
Metody strukturalne (white-box, glass-box) są stosowane, gdy kod programu jest
dostępny. Przypadki testowe mogą być generowane na podstawie algorytmu lub kodu,
następnie wykonuje się analizę pokrycia kodu (module coverage), która ujawnia, czy
wszystkie linie kodu są wykonywane (i w jakich warunkach) lub czy wszystkie warunki
(if-else lub switch) są spełniane. Wykonuje się również analizę niezależnych ścieżek
programu (path analysis), co pozwala sprawdzić poprawność logiki programu i
zlokalizować niepotrzebny kod.
Zakres testowania
Biorąc pod uwagę zakres testowania, wyróżnia się testy:
jednostek (unit testing),
scalania (integration testing)
systemów użytkowych.
2/1
Testowanie
Testy jednostek
Testy jednostek dotyczą pojedynczych klas i pozwalają na ujawnienie błędów w ich
implementacji. Ponieważ z założenia klasy w docelowym systemie nie funkcjonują
niezależnie, należy skonstruować odpowiednie środowisko do testowania, zwane
pilotem testu (test driver), symulujące funkcje otoczenia klasy. Pilot testu dostarcza
danych wejściowych testu, kontroluje i śledzi wykonanie i protokołuje wyniki. Testy
jednostek mogą poza tym wynikać z analizy diagramu maszyny stanowej stanowiącego
opis funkcjonalności danej jednostki.
Ponieważ ten typ testów jest wykonywany bardzo często, w wielu środowiskach typu
IDE istnieją wspierające go narzędzia. Na przykład NetBeans zawiera wtyczki JUnit i
CUnit, które generują szkielet testów dla wybranych klas zgodnie z podejściem
właściwym dla tych technologii. Szkielet ten odwzorowuje strukturę testowanej klasy 
każdej metodzie odpowiada metoda ją testująca, która jest wygenerowana przez
NetBeans i musi być rozbudowana przez projektanta klasy, tak by wykonywała
wszystkie przypadki testowe. Kod testujący jest umieszczony w odrębnej gałęzi
projektu (Test Packages) i nie wchodzi w skład finalnej dystrybucji.
3/1
Testowanie
Model V
W teorii i praktyce występuje wiele różnych odmian procesu inżynierii
oprogramowania. Przykładami są modele software life cycle, kaskadowy (waterfall
model), spiralny (spiral model), zunifikowany (unified process), model V (V-model) i
model W (W-model).
We wszystkich, oprogramowanie wytwarza się etapami. W większości procesów
występują podobne etapy, a różnice dotyczą warunków i możliwości przejścia do
następnego etapu lub powrotu do poprzedniego.
Cechą szczególną modeli
V i W jest ścisłe połącze-
nie między etapami kon-
strukcji oprogramowania
4/1
i jego testowania.
Testowanie
Model W
Lewa gałąz
modelu W składa się etapów konstrukcji oprogramowania, podzielonych
na dwa zadania: (1) konstrukcji (2) i przygotowanie odpowiednich testów. Strzałki
między zadaniami konstrukcji i przygotowania testów oznaczają powtórzenia
stosowane w celu dopracowania postaci wyników.
5/1
Testowanie
Model W
Prawa gałąz
modelu W reprezentuje testowanie i debugowanie. Strzałki między
zadaniami testowania, debugowania i implementacji oznaczają iteracyjne usuwanie
błędów. Jeśli test ujawnia błąd, konieczne jest debugowanie w celu lokalizacji błędu, a
po usunięciu błędu, czyli zmianie implementacji, należy wykonać ponowne testowanie
w celu potwierdzenia.
5/1
Testowanie
Tworzenie testów w oparciu o model
Tworzenie testów w oparciu o model wymaga systematycznego podejścia i niekiedy
pozwala na automatyczne generowanie testów z modelu. UML jako język pozwala
specyfikować model testu, używając profilu UTP (UML Testing Profile) do opisu
testów.
Z punktu widzenia testowania, modele UML mogą być postrzegane jako programy
wykonywalne. Dlatego znane metody generowania testów mogą być zastosowane do
modelowania testów w języku UML. W szczególności dotyczy to użycia metod
black-box i white-box.
Testowanie metodą czarnej skrzynki (black-box)
Testowanie metodą czarnej skrzynki, nazywane też testowaniem funkcjonalnym,
traktuje obiekt testu (SUT - System Under Test) jako element o nieznanym wnętrzu,
więc zupełnie nie bierze sie pod uwagę informacji o jego strukturze lub funkcjach. W
zamian uwzględnia się relację między wejściem i wyjściem. Zwykle definiuje się zbiór
przypadków testowych dla każdej metody testowanego obiektu, uwzględniając
wszystkie kombinacje danych wejściowych.
Typowe podejścia w systematycznym tworzeniu testów czarnej skrzynki wykorzystują
klay równoważności i analizę wartości brzegowych.
6/1
Testowanie
Tworzenie testów w oparciu o model
Testowanie metodą białej skrzynki (white-box)
Testowanie metodą białej skrzynki, nazywane też testowaniem metodą szklanej
skrzynki, wykorzystuje dostępność modelu lub kodu obiektu. Przypadki testowe są
przygotowywane na podstawie pokrycia kodu. Typowe aspekty to pokrycie instrukcji,
pokrycie gałęzi i pokrycie ścieżek. Dodatkowo analizuje się użycie zmiennych i
warunków logicznych w rozgałęzieniach i pętlach.
Kryteria pokrycia mogą też służyć do definiowania przypadków testowych z modeli
UML. Na przykład, można analizować pokrycie stanów i przejść w diagramie stanu
klasy. Podobnie można wykorzystać diagramy sekwencji, czynności i interakcji.
7/1
References
8/1