Testowanie jest nierozerwalnym elementem powstawania systemów informatycz-nych. Pozwala zmierzyć jakość tworzonego oprogramowania wyrażoną przez liczbę znalezionych usterek zarówno dla funkcjonalnych, jak i niefunkcjonalnych wymagań i atrybutów oprogramowania. Jego celem jest wykonywanie kodu przy zadanych wejściowych i określonych stanach w celu wykrycia ewentualnych błędów. Ma na celu potwierdzenie wykonania określonego kodu zgodnie z założeniami projekto-wymi. Trzeba pamiętać o tym, że nie ma możliwości przetestowania wszystkich do-puszczalnych danych wejściowych lub wyjściowych programu. Liczba potencjalnych przypadków testowych może być ogromna i nie zawsze dałoby się ustalić wszystkie możliwe kombinacje.
Wyróżniane są dwie podstawowe techniki projektowania testów. Są to techniki białoskrzynkowe oraz czarnoskrzynkowe.
37 W testowaniu metodą czarnej skrzynki nie wykorzystuje się żadnych informacji
o wewnętrznej strukturze testowanego systemu. Test ten bada tylko aspekt funkcjo-nalny systemu. Najistotniejszym celem jest otrzymanie wyników na określone dane wejściowe, czyli wykrycie i zdefiniowanie warunków, w których wynik nie jest zgodny ze specyfikacją. Testy metodą czarnej skrzynki zazwyczaj obejmują [Glenford 2005, ss. 24–25, Pawlak 2014, ss. 131–135]:
• sprawdzanie poprawności interfejsu użytkownika, • sprawdzanie działania funkcji,
• sprawdzanie poprawności walidacji,
• sprawdzenie poprawności zakończenia programu.
W testowaniu białoskrzynkowym analizowany jest kod źródłowy aplikacji. Zapro-jektowanie przypadków testowych umożliwia znajomość struktury kodu, jak również danych wejściowych. Testowanie białoskrzynkowe zwane strukturalnym pozwala zoptymalizować kod programu oraz wychwycić miejsca, w których są błędy.
Testy białoskrzynkowe sprawdzają [Glenford 2005, ss. 26-28, Pawlak 2014, ss. 136-139]:
• wewnętrzną strukturę modułów, • wydajność poszczególnych modułów, • funkcjonalności poszczególnych modułów, • czas reakcji.
Metodologia testowania białą skrzynką nie zaleca uczestnictwa w procesie wy-twarzania oprogramowania osób zajmujących się testowaniem.
Proces testowania oprogramowania odbywa się na kilku poziomach. Z każdym poziomem jest związany określony typ testu:
• testy komponentów, • testy warstw, • testy wymagań,
• testy manualne i automatyczne pod względem metody ich realizacji. Testy komponentów, zwane jednostkowymi, odbywają się na najniższym pozio-mie – bezpośrednio na kodzie aplikacji [Patton 2002, s. 111]. Sprawdzają działanie pewnego niewielkiego obszaru funkcjonalności testowanego kodu z określonymi da-nymi wejściowymi w celu zwrócenia oczekiwanych danych wyjściowych. Testy tego typu najczęściej przeprowadzane są przez programistów używających do tego celu wcześniej przygotowanych danych testowych. Udowodniają, że kod działa zgodnie z założeniami programisty [Adam 2015, s. 73; Smiglin 2016, ss. 29–35].
38
Aplikacje poddawane testowaniu są zbudowane ze współpracujących ze sobą komponentów (zwanych modułami). Testy warstw zwane integracyjnymi są wykony-wane w celu wykrycia defektów we współdziałaniu pomiędzy modułami lub systema-mi. Testy te sprawdzają, czy dane pomiędzy modułami są przekazywane poprawnie. Wykorzystywane są do sprawdzania zgodności z projektem aplikacji oraz współpracy wszystkich modułów [Glenford 2005, ss. 117–150, Pawlak 2014, ss. 66].
Testy systemowe weryfikują działanie aplikacji jako całości. Sprawdzają, czy dane pomiędzy systemami są przekazywane poprawnie, czy wszystkie funkcje realizują swoje zadania. Testy te pozwalają określić poziom bezpieczeństwa systemu, współ-pracę z innymi systemami oraz jego wydajność i szybkość działania [Adam 2015, s. 78].
Testy wymagań oceniają stopień spełnienia wymogów wydajnościowych przez system lub moduł. Może to być [Adam 2015, ss. 533-537, Glenford 2005, s. 157]:
• badanie czasu odpowiedzi aplikacji,
• badanie procesów pod kątem wykonywanych czynności,
• porównywanie czasu odpowiedzi aplikacji przy różnym jej obciążeniu, • sprawdzanie reakcji systemu na utratę danych,
• sprawdzanie, w jakim czasie są wykonywane zapytania kierowane do bazy danych.
Testy wydajnościowe pozwalają przetestować aplikację, tak aby spełniała wyma-gania projektowe i dawała gwarancję odporności na przeciążenia [Adam 2015, s. 401]. Testowanie oprogramowania może się odbywać na dwa sposoby: manualnie i automatycznie [Pawlak 2014, ss. 183–186]. Z reguły testowanie ręczne dotyczy te-stów funkcjonalnych, natomiast testy automatyczne stosuje się w testowaniu struk-turalnym, testach regresyjnych (testach oprogramowania po wykonaniu zmian) i akceptacyjnych (potwierdzających wykonanie oprogramowania odpowiedniej ja-kości). Tester na podstawie stworzonych skryptów może weryfikować jakość opro-gramowania, wykorzystując wiedzę i logiczne myślenie. Postępując wg określonego scenariusza może jednak popełniać błędy, co wynika ze słabości „czynnika ludzkie-go”. Biorąc pod uwagę aspekt nieskończoności testowania i uzyskania większego pokrycia dzięki maszynom, lepszym rozwiązaniem jest wykorzystanie specjalnych narzędzi, które wykonają zadany test zgodnie z określonymi parametrami. Sprawą dyskusyjną jest więc wybór sposobu testowania. Zwykle decyzja, czy automatyzo-wać i w jakim stopniu, podejmowana jest jednak na poziomie menadżerów, a nie testerów oprogramowania.
39
Automatyzacja testów
Automatyzacja z definicji jest procesem, który pozwala na znaczne ograniczenie lub zastąpienie ludzkiej pracy fizycznej i umysłowej przez pracę maszyn działających na zasadzie samoregulacji i wykonujących określone czynności bez udziału człowieka. Proces testowania oprogramowania również można poddać automatyzacji. I to za-równo jeśli chodzi o testy funkcjonalne, dotyczące badania poprawności działania pewnych obszarów oprogramowania, jak i testy niefunkcjonalne, badające wydaj-ność i wiarygodwydaj-ność systemu. W wypadku testów niefunkcjonalnych jest to zazwy-czaj jedyna możliwość sprawdzenia. Jako przykład można przyjąć testy obciąże-niowe, których celem jest sprawdzenie, czy dany system wytrzyma równoczesne korzystanie przez tysiąc użytkowników. Wydaję się, że manualnie jest to niemożliwe, na pewno też koszt finansowy i czasowy takiej weryfikacji jest niezasadny. Wymaga-łoby to zebrania dużej liczby osób i poinstruowania ich co do wykonywania, najlepiej synchronicznie, konkretnych scenariuszy. Dobrze byłoby też uzupełnić taki zespół o osoby monitorujące i zbierające wyniki pracy systemu. Na koniec takie wyniki nale-żałoby w odpowiedni sposób zinterpretować. Te wszystkie działania można w mniej czasochłonny i bardziej ekonomiczny sposób zautomatyzować, a praca ponad tysiąca osób zostałaby zastąpiona pracą jednego testera automatyzującego [Automatyzacja testów systemowych 2016].
Należy wspomnieć też o tym, że testy automatyczne są bardzo dobrym uzupeł-nieniem testów manualnych. Często automatyzacja jest mylnie postrzegana jako sposób na całkowite zastąpienie testów manualnych. Pewne obszary testowanego oprogramowania powinny zostać testowane w sposób ręczny. Przyczyną jest fakt, że komputery mają trudności z przetwarzaniem i interpretacją pewnych informacji, któ-re są naturalne dla człowieka [Smiglin 2016, ss. 29–35].