Typy testów

Z poprzedniego artykułu dowiedziałeś się, jakie poziomy testów spotykamy w codziennej pracy. Dzisiaj postaram się przybliżyć wam typy testów. Typy i poziomy testów są to dwa odrębne zagadnienia. Czytając ten artykuł powinieneś mieć z tyłu głowy, że dany typ testu zwykle może być wykonany na każdym poziomie testowania. Poziom testów jest skupiony na celu testów.

Zwykle najczęściej spotykamy 4 podstawowe typy testów:

• funkcjonalne

• niefunkcjonalne

• strukturalne

• testy związane ze zmianami

Testy funkcjonalne są to testy skupione na przetestowanie jakiejś konkretnej funkcji oprogramowania. Tego rodzaju testy mają na celu przetestowanie aplikacji pod kątem niefunkcjonalnej właściwości np. wydajności czy użyteczności. Testy struktury, których celem jest przetestowanie architektury, struktury systemu. Na koniec testy związane ze zmianami to te testy, które wykonujemy po zmianach, czyli na przykład sprawdzenie czy błąd nadal występuje, czy testy regresji.

Testy funkcjonalne

W dużym uproszczeniu można stwierdzić, że taki rodzaj testów skupia się na tym, „co” system robi. Jest to forma weryfikacji czy warunki funkcjonalne zostały spełnione. To jak aplikacja ma działać zwykle bierzemy wprost ze specyfikacji funkcjonalnej, specyfikacji wymagań czy z przypadków użycia

Jeśli mówmy i testach funkcjonalnych – od razu powinniśmy pomyśleć o testach czarnoskrzynkowych, o metodach takich jak podział na klasy równoważności, analiza wartości brzegowych, tablice decyzyjne itp. Takie testy są testami czarno skrzynkowymi. Dotyczą “widocznego” zachowania aplikacji.

Testy niefunkcjonalne

Testowanie niefunkcjonalne skupia się na tym “jak” system działa. Do oceny tego jak system działa bierzemy pod uwagę aspekty takie jak:

• niezawodność

• efektywność

• bezpieczeństwo

• pielęgnowalność

• przenaszalność

• użyteczność

Testowanie niefunkcjonalne odważę się powiedzieć, że są bardziej skomplikowane niż testy funkcjonalne. Z reguły są bardziej złożone, z doświadczenia wiem, że dokumentacja zwykle skupia się na aspektach funkcjonalnych a nie niefunkcjonalnych. Tester musi o tym jednak zawsze pamiętać, nawet, jeśli nie jest to jasno zdefiniowane w specyfikacji. Co z tego, że aplikacja będzie idealna pod względem tego, co ma robić, jak będzie działała wolno i będzie bardzo nieprzyjazna dla użytkownika.

Testy strukturalne (białoskrzynkowe)

Testy strukturalne oparte są na technikach białoskrzynkowych. Oznacza to, że testujemy oprogramowanie patrząc w kod, analizujemy wewnętrzną strukturę aplikacji czy systemu. Najczęściej taki typ testów stosowany jest w celu pomiaru, oceny dokładności testowania. Odpowiedzią na to jest parametr pokrycia, czyli stopień, w jakim element został przetestowany. Testy badają reakcje systemu na konkretne dane, najlepiej takie, które pokrywają wszystkie możliwe ścieżki programu wtedy możemy mówić o 100% pokryciu.

O pokryciu kodu możemy mówić w kontekście linii kodu, rozgałęzień w instrukcjach warunkowych, warunków logicznych itp. Zwykle tego rodzaju testy są zautomatyzowane

Istnieje teoria, że warto zaczynać od testów funkcjonalnych a następnie przejść do testów białoskrzynkowych, a nie odwrotnie. Co w przypadków testów TDD nie do końca jest realne, ponieważ to najpierw test strukturalny powstaje. Ponieważ należy mieć z tyłu głowy, że unit testy to nic innego jak testy białoskrzynkowe. Tak samo badanie złożoności kodu.

Tak naprawdę, jeszcze możemy wspomnieć w tym momencie o testach statycznych – które wykonywane są bez uruchamiania oprogramowania, czyli choćby klasyczne Code Review. Jednak też jest oparte na analizie kodu. Chociaż CR nie jest to zwykle uwzględniane, jako typowa technika białoskrzynkowa.

Testy związane ze zmianami

Ostatni typ testów, który dzisiaj omówimy to testy oparte na zmianach. Jest to jeden z ważniejszych rodzajów testów. Polega on na ponownym wykonaniu testu bądź testów, ponieważ wystąpiła jakaś zmiana np. kod (błąd w kodzie) został poprawiony i należy sprawdzić czy aby na pewno defekt nie występuje, nowa wersja oprogramowania została wydana czy też zaszły zmiany w komponencie (np. w bibliotece), który wykorzystuje nasza aplikacja.

Jak już pewnie pamiętacie z poprzednich artykułów do tego rodzaju testów możemy zaliczyć re-testy jak i testy regresji. Dla przypomnienia, re-testy wykonujemy w sytuacji, gdy na przykład programista naprawi błąd i naszym zadaniem jest zweryfikować czy usterka faktycznie została naprawiona oraz testy regresji polegające na przetestowaniu aplikacji pod kątem czy przypadkiem jakieś nowe błędy się nie wkradły w “działających wcześniej” modułach. Można też powiedzieć, że re-testy wykonujemy bazując na konkretnym błędzie, testy regresji bardziej weryfikują czy coś po drodze nie zostało zepsute, “przy okazji”.

Podsumowanie

W poprzednim artykule pisałam o poziomach testów, dzisiaj o typach testów. W obu tych przypadkach chodzi o to samo, ale są to dwa niezależne od siebie podziały. Jak już wspominałam, każdy typ testów może być stosowany na każdym poziomie testowania. W codziennym życiu jednak zwykle spotkamy się z połączeniami bardziej klasycznymi takimi jak testy niefunkcjonalne wykonywane na etapie testów systemowych, ale tak jak zawsze to podkreślam każdy projekt jest inny i czasem połączenia mogą nas zaskoczyć. Najważniejsze to znać te typy i poziomy testów tak by móc je ułożyć jak najefektywniejszy proces testowy.