Korzystne zarówno dla jakości, jak i skrócenia łącznego czasu wykonywania testów jest poprzedzenie testów dynamicznych, tj. takich, w których przypadki testowe są wykonywane na pracującym programie, tak zwanymi testami statycznymi, a więc przede wszystkim analizą kodu źródłowego.
Oprócz badania poprawności działania funkcji jawnych, warto prześledzić działanie programu "od środka", na niskim poziomie. Chodzi o wychwycenie ukrytych błędów w rodzaju "przecieków pamięci" albo niezauważalnego niszczenia danych czy nawet kodu programu, np. z powodu błędnie zaadresowanych wskaźników.
W czasie wykonywania testów nie należy zapominać o kontroli mniej formalnych atrybutów jakości, np. przepustowości, wydajności, ogólnej użyteczności - nawet jeżeli pominięto je w specyfikacji wymagań.
Nauka o testowaniu
W praktyce testowania wypracowano wiele interesujących metod formalnych, które pozwalają testerowi wyrobić sobie pogląd na różne możliwe podejścia do zagadnienia i towarzyszących im konstrukcji abstrakcyjnych. Oto pobieżny przegląd tego dorobku.
Domeny testowania Ponieważ nie da się przetestować wszystkiego, istotne jest, by nie dublować niepotrzebnie wysiłków. Wyobraźmy sobie, że testujemy program typu "kalkulator". Czy podczas testowania funkcji dodawania sensowne jest testowanie wszystkich możliwych kombinacji wartości? Czy prawdopodobna jest sytuacja, że program poprawnie wykona dodawanie 17+23, a niepoprawnie 18+32? Oczywiście nie, ponieważ te przykładowe wartości, jak wiele innych, należących do dziedziny danych wejściowych, należą do tej samej klasy czy też domeny równoważności i nie ma potrzeby testowania wszystkich czy choćby wielu. Niemniej dodatkowa uwaga należy się wartościom granicznym danej klasy.
Techniki oparte na szacowaniu poziomu pokrycia kodu Na podstawie wybranego modelu pokrycia kodu podczas wykonywania przypadków testowych wybieramy zadania tak, by wymagane pokrycie osiągnąć. W niektórych przypadkach, np. szczególnie ważnych algorytmów czy funkcji, pokrycie może sięgnąć nawet 100% instrukcji kodu. Podobnie będzie z testowaniem rozgałęzień przepływu sterowania (tam, gdzie w kodzie są instrukcje warunkowe typu if, case, switch, while...) tak, by zostały wykonane z wszelkimi możliwymi wynikami, np. zarówno PRAWDA i FAŁSZ dla instrukcji if.
Technik pomiaru poziomu pokrycia kodu jest wiele, a zastosowanie konkretnego wariantu zależy najczęściej od charakteru oprogramowania. Niestety przy opracowywaniu typowego oprogramowania biznesowego są one stosowane raczej rzadko z przyczyn kosztowych. Ale już np. przy konstruowaniu systemów krytycznych (sprzęt medyczny, oprogramowanie stosowane w samolotach czy kolejowe systemy sygnalizacyjne) osiągnięcie określonego poziomu pokrycia kodu jest zwykle bezwzględnym wymogiem zgodności ze standardami.
Testowanie oparte na modelu tranzycji stanów Technika ta polega na opisaniu działania systemu w formie modelu czy też diagramu obrazującego kolejne kroki jego wykonywania czy stanów, w jakich się znajduje. Przykładowo, opis działania kuchenki mikrofalowej jako pewnej liczby stanów mógłby mieć następującą postać: oczekiwanie, wybór czasu, gotowanie, przerwa w wyniku otwarcia drzwiczek itd. Stworzony model służy następnie do wygenerowania ciągu przypadków testowych umożliwiających łatwe przetestowanie wszystkich stanów. Model ten jest dość powszechnie stosowany w testach systemów wbudowanych.
Testowanie oparte na modelu składni Polega na tym, że jakąś część programu opisuje się jako język mający swoją składnię, a następnie generuje się zadania testowe w taki sposób, aby zweryfikować zgodność faktycznego działania programu z tą składnią. Metodę tę stosuje się m.in. przy testowaniu kompilatorów, protokołów komunikacyjnych, a także elementów interfejsu użytkownika.
Czy przedstawione metody da się zastosować w rzeczywistości, którą rządzą napięte harmonogramy oraz niejasne i zmienne wymagania? To, co zostało określone jako "sztuka" i "rzemiosło", bez wątpienia tak. Jeśli zaś chodzi o "naukę", na pierwszy rzut oka jest ona groźna i abstrakcyjna. Jednak poznawszy lepiej te techniki, łatwiej dostrzec, że niekoniecznie są one kosztownym luksusem. Wprost przeciwnie, zwykle pozwalają na znaczne uproszczenie procesu testowania i podniesienie jakości jego efektów - przy utrzymaniu łącznych kosztów na poziomie zbliżonym do stosowanych powszechnie w metodach "żywiołowych".
Bogdan Bereza-Jarociński jest niezależnym konsultantem pracującym m.in. dla szwedzkiej firmy Enea. Można się z nim kontaktować pod adresem: [email protected].
