TESTOWANIE
Proces testowania systemów informatycznych najczęściej określany jest jako: uruchomienie programu z zamiarem znalezienia w nim błędów. Określenie błąd w odniesieniu do programu komputerowego może mieć wiele znaczeń. Na poniższej liście przedstawiono kilka przykładów błędów możliwych do wykrycia za pomocą testów przeprowadzonych w systemie:
błędy w kodzie źródłowym aplikacji,
brak implementacji wszystkich wymagań,
niepoprawna implementacja wymagań,
niewystarczająca wydajność systemu,
niestabilność aplikacji.
W celu wykrycia poszczególnych typów błędów stosowane są różne rodzaje testów, przeprowadzanych na każdym z etapów rozwoju aplikacji - od wczesnych wersji po końcowe fazy przejmowania systemu przez użytkowników. Każdy z testów koncentruje się na sprawdzeniu innej części aplikacji i ma inne cele. Jednak przyglądając się strategii ich wykonywania wyróżnić można dwie metody: białej i czarnej skrzynki.
Testowanie metodą białej skrzynki
Metoda białej skrzynki jest sposobem tworzenia i wykonywania testów z perspektywy osoby znającej wewnętrzną strukturę i sposób działania testowanej aplikacji. Testy takie skoncentrowane są na weryfikacji poprawności działania poszczególnych ścieżek przebiegu sterowania w systemie, a także jakości implementacji poszczególnych jednostek systemu. Z tą metoda mocno związane jest pojęcie pokrycia kodu źródłowego[1], które jest miarą tego, do jakiego stopnia tworzone oprogramowanie zostało przetestowane. W celu wyznaczenie wskaźnika pokrycia kodu następujące kryteria są brane pod uwagę:
pokrycie funkcji - określające procent przetestowanych funkcji,
pokrycie instrukcji - określające procent przetestowanych linii kodu źródłowego,
pokrycie gałęzi - określające procent instrukcji warunkowych przetestowanych zarówno z warunkiem prawda jak i fałsz,
pokrycie ścieżek - określające procent przetestowanych ścieżek logicznych wiodących przez program.
Całościowe przetestowanie aplikacji metodą białej skrzynki powinno dążyć do stuprocentowego pokrycia kodu systemu, a więc takiego, w którym każda jego linijka została wykonana przynajmniej raz. Niestety, często nawet w przypadku bardzo prostych programów jest ono niewykonalne. Może to wynikać zarówno z zakresu danych wejściowych poszczególnych komponentów, jak i z liczby ścieżek możliwych do przejścia w trakcie wykonania danej funkcji. Z tego powodu ta strategia wybierana jest do przetestowania wyłącznie najbardziej kluczowych sekcje programu. Niestety praktyka wybierania kodu do testów, może prowadzić do pomijania elementów, które programistom wydają się być oczywiste i w rezultacie do pominięcia ukrytych w nich błędów.
Testy metodą białej skrzynki są najbardziej pomocne we wczesnych fazach rozwoju systemu i ich wyniki pomagają programistom aplikacji w usunięciu błędów w tworzonych komponentach.
Testowanie metodą czarnej skrzynki
W testach wykonywanych metodą czarnej skrzynki[1] testowany komponent lub system traktowany jest jako całość, bez dostępu do wewnętrznej struktury kodu programu i szczegółów jego implementacji. Testy te, ze względu na sposób ich przeprowadzania, są też określane jako sterowane danymi. Polegają one na przygotowaniu danych wejściowych i wyjściowych. Dane wyjściowe wprowadzane są do systemu, a odpowiadające im dane wyjściowe, przyrównywane są do tych, które zwróci aplikacja. Oczywiście, w zależności od rodzaju testu, dane wejściowe i wyjściowe przyjmują różne postaci. I tak dla testów funkcjonalnych są to dane wprowadzane do programu za pomocą interfejsu użytkownika, zaś dla testów wydajnościowych będą to czasy odpowiedzi systemu lub liczba obsłużonych transakcji. Testy metodą czarnej skrzynki stosowane są na różnych etapach rozwoju systemu. Jednak im system staje się większy (rośnie skrzynka), tym stają się one bardziej powszechne. Wykonaniem tych testów, w przeciwieństwie do metody białej skrzynki, mogą zajmować się osoby nie związane z implementacją systemu. Atutem wybierania testerów spośród osób nie posiadających wiedzy o programie jest to, że żadna kombinacja danych wejściowych nie jest dla nich oczywista i są one skłonni przetestować te scenariusze, które zostały pominięte przez programistów. Punktem wyjścia do tworzenia testów metodą czarnej skrzynki jest specyfikacja wymagań stawianych aplikacji. Jej szczegółowa znajomość jest wymagana w celu opracowania testów pokrywających wszystkie funkcje, które program powinien realizować. W związku z tym testy takie określane są jako funkcjonalne lub behawioralne. Duża część istniejących testów systemów informatycznych zaliczana jest do strategii czarnej skrzynki.
Najczęściej spotykane pośród nich to testy funkcjonalne, testy wydajnościowe, testy obciążeniowe oraz testy systemowe. Należy jeszcze podkreślić, że zrealizowanie testów niefunkcjonalnych (np. wydajnościowych) możliwe jest jedynie przy zastosowaniu strategii czarnej skrzynki.
Typy testów
W poprzedniej sekcji opisane zostały dwie strategie tworzenia testów systemów informatycznych. W oparciu o nie możliwy jest do zrealizowania szereg testów, które można pogrupować w cztery poniższe typy:
testy jednostkowe,
testy integracyjne,
testy funkcjonalne,
testy niefunkcjonalne.
Niestety nie wszystkie z powyższych testów mogą być zautomatyzowane. Na przykład do realizacji integracyjnych testów systemowych konieczna jest współpraca kilku systemów, za które odpowiedzialne mogą być odrębne organizacje. W kontekście niniejszej pracy ważne jest aby w sposób automatyczny sprawdzać funkcjonalności dodawane do realizowanego systemu i wykrywać powstałe przy tym błędy. Do tego celu najczęściej stosuje się automatyzację testów opisanych w kolejnych podrozdziałach.
Testy jednostkowe
Testy jednostkowe (ang. unit tests) są realizacją strategii testowania metodą białej skrzynki. Są one tworzone w pierwszej kolejności i stanowią zazwyczaj największą pod względem liczebności, część testów budowanego oprogramowania. Oprócz wykrywania błędów, testy jednostkowe spełniają jeszcze dwie dodatkowe funkcje pozwalające zwiększyć jakość budowanego systemu oraz ułatwiające dalszy jego rozwój sprawdzając czy nie złamano wymagań. Testy takie dostarczają też swoistej dokumentacji i przykładów użycia poszczególnych jednostek kodu. Testy jednostkowe stosowane są we wszystkich istniejących językach programowania.
Wykrywanie błędów
Jak sama nazwa mówi testy jednostkowe skoncentrowane są na weryfikacji poprawnego działania poszczególnych jednostek kodu programu. Jako jednostkę rozumiemy tu najmniejszą testowalną[3] część aplikacji. W programowaniu proceduralnym jest to procedura lub funkcja, natomiast w językach obiektowych - metoda klasy. Zgodnie z najlepszymi praktykami tworzenia testów jednostkowych dobry test to taki, który wykazuje następujące cechy:
posiada wysokie prawdopodobieństwo wykrycia błędu,
jego wykonanie jest szybkie,
koncentruje się on jedynie na testowanej jednostce,
elementy nie należące do danej jednostki są odizolowane.
Właśnie w kontekście izolacji z testami jednostkowymi nierozerwalnie związane jest pojęcie obiektów zastępczych (ang. mock objects[3]). Izolacja komponentów do testów jednostkowych jest trudna do osiągnięcia, ponieważ poszczególne jednostki kodu programu ze sobą współpracują. Często zdarza się, iż klasy współpracujące z testowaną istotnie wpływają na pewne elementy środowiska systemu. W takim wypadku autorzy testów rozszerzają kod testu również na zależności testowanej klasy, co powoduje że test z jednostkowego zamienia się w integracyjny lub funkcjonalny . Przykładem takiej sytuacji może być testowanie komponentu realizującego komunikację z bazą danych. Programista tworzący test zawiera w nim również komendy języka SQL wprowadzające dane do tabel w bazie, co w rzeczywistości stanowi testowanie interakcji z systemem zewnętrznym. W programowaniu obiektowym, realizację odseparowania klas na potrzeby testów umożliwia programowanie przez interfejsy oraz użycie obiektów zastępczych. Obiekty te imitują klasy wykorzystywane przez testowany komponent. Udostępniając identyczny interfejs, którego implementacja jest zazwyczaj pusta.
Łamanie wymagań
Dzięki testom jednostkowym w szybki sposób można określić czy wprowadzona w kodzie zmiana nie łamie wymagań stawianych poszczególnym komponentom. Jeżeli dla danego komponentu istnieje zestaw testów jednostkowych, mających za zadanie sprawdzenie czy spełnia on stawiane wymagania, to po wprowadzeniu do programu zmian łamiących te wymagania testy te przestaną się poprawnie wykonywać. W przypadku gdy testy wykonywały się poprawnie, a po wprowadzeniu zmian sygnalizują błędy, stanowią
wtedy sposób wykrywania regresji w kodzie źródłowym i to ta właściwość jest najcenniejsza podczas automatycznego wykonywania testów w celach ciągłej integracji. Jednak uzyskanie takiego efektu wymaga odpowiednio dużego pokrycia testami kodu źródłowego aplikacji.
Dokumentacja
Testy jednostkowe poszczególnych komponentów stanowią doskonałą dokumentację. Programiści, na podstawie testu jednostkowego danej klasy są w stanie uzyskać wiedzę na temat jej funkcjonalności. Często też zdarza się, że zmiany w kolejnych wersjach systemu nie są uwzględniane w formalnej dokumentacji. Z kolei testy jednostkowe same wymuszają konieczność aktualizacji, ponieważ w innym wypadku zgłaszają błędy.
Testy integracyjne
Testy jednostkowe pozwalają zweryfikować zachowanie pojedynczych komponentów systemu. Jednak nawet jeżeli pracują one poprawnie w odosobnieniu, nie daje to pewności, że będą się poprawnie zachowywać współpracując ze sobą. Dzieje się tak dlatego, że do wykonywania stawianych im zadań, poszczególne moduły systemu wykorzystują funkcjonalności dostarczane im przez inne moduły. Dlatego wymagane jest również wykonanie testów integracyjnych dla współpracujących ze sobą komponentów.
Testy integracyjne są naturalnym rozszerzeniem testów jednostkowych i zazwyczaj wykonywane są przy użyciu tych samych narzędzi i bibliotek. Tym, co odróżnia je od testów jednostkowych jest zupełnie odmienne podejście do testowanych komponentów. Podczas testów integracyjnych najważniejsze jest zweryfikowanie czy współpraca pomiędzy poszczególnymi klasami i systemami zewnętrznymi przebiega w sposób pożądany. Testy integracyjne są realizacją strategii testowania metodą czarnej skrzynki. Testy integracyjne mogą być realizowane na wiele sposobów, jednak najczęściej wykorzystywane są opisane poniżej trzy modele[1]: z góry na dół, z dołu do góry i hybrydowy
Model z góry na dół
W podejściu z góry na dół najpierw integrowane są moduły najwyższego poziomu a później wykorzystywane przez nie moduły zależne. Pozwala to w pierwszej kolejności testować logikę procesów aplikacji biznesowych oraz przepływ danych pomiędzy nimi. Niestety taki model wymaga intensywnego wykorzystania obiektów zastępczych, ponieważ niektóre komponenty mogą nie być w danym momencie zaimplementowane. Występuje tu też ryzyko związane z relatywnie późnym integrowaniem elementów niskiego poziomu. Mimo, iż proces biznesowy wydaje się być obsługiwany poprawnie to zastąpienie obiektu zaślepki jednego z modułów niskiego poziomu może stać się niemożliwe do zaimplementowania, co z kolei wymusza zmianę w już utworzonych modułach. Zobrazować to można przykładem aplikacji korzystającej z bazy danych. Po zaimplementowaniu modułów wprowadzania danych może się okazać, iż niemożliwe jest zrealizowanie zapytań SQL w sposób jaki zakładano i koniecznym jest wprowadzania
zmian w już zaimplementowanych modułach. Gdy opisana sytuacja zaistnieje pod koniec projektu zasoby potrzebne do realizacji zmian mogą już nie być dostępne.
Model z dołu do góry
Podejście z dołu do góry wymusza testowanie i integrowanie elementów najniższego poziomu, to jest klas i ich metod, a następnie grupowanie przetestowanych elementów w moduły coraz to wyższego poziomu. Dzięki temu, podczas testów integracyjnych, zależności komponentów są już zaimplementowane i konieczność wykorzystywania obiektów zastępczych jest niewielka. Niestety, analogicznie do podejścia z góry na dół, pojawia się tu ryzyko związane z późnym testowaniem procesów wysokiego poziomu. Na
przykład po dojściu do najwyższego poziomu może się okazać, iż współpraca poszczególnych modułów nie może przebiegać w sposób jaki zakładano i wymagane jest ponowne zaimplementowanie kilku z nich. Jeżeli taka sytuacja wystąpi w końcowych fazach projektu, może już nie być czasu na zmiany.
Model hybrydowy
Model hybrydowy stara się wykorzystać zalety obu powyższych podejść i zminimalizować ich wady. Najpierw integrowane są moduły stanowiące interfejsy poszczególnych funkcjonalności przy użyciu modelu z góry na dół, a następnie funkcje wyjściowe tych modułów integrowane są w sposób z dołu do góry. W przykładowym systemie informatycznym mogłoby to odbywać się tak, iż najpierw zintegrowane zostałyby
moduły odpowiedzialne za obsługę interfejsu użytkownika dla danej funkcjonalności, a następnie niskopoziomowe moduły realizujące komunikację z bazami danych i systemami zewnętrznymi.
Testy funkcjonalne
Zestawy testów funkcjonalnych są odzwierciedleniem wymagań funkcjonalnych stawianych systemowi i tworzone są przy współpracy klientów biznesowych, analityków systemu, testerów i programistów. Język testów funkcjonalnych odzwierciedla domenę systemu. Operuje się w nim pojęciami takimi, jak na przykład konto w systemie bankowym czy przesyłka w systemie kurierskim, które powinny być definiowane przez
przedstawicieli klienta, nazywanych potocznie ekspertami domeny. Eksperci domeny posiadają niezbędną wiedzę na temat procesów biznesowych, które system ma realizować. Testy funkcjonalne to testy metodą czarnej skrzynki sterowane takimi danymi, które byłyby wprowadzane przez użytkowników końcowych aplikacji przez dedykowane im interfejsy. Stanowią narzędzie pozwalające przeprowadzać walidację tworzonego oprogramowania czyli sprawdzać:
Czy budowany jest ten system co trzeba.
Czy zrealizowane zostały wszystkie wymagania klienta.
Czy system spełnia oczekiwania klienta.
Tym samym, stanowią doskonały sposób na stwierdzenie kiedy dany przypadek użycia, a nawet cały system został w pełni oprogramowany - wtedy kiedy wszystkie zdefiniowane dla niego testy funkcjonalne dają wynik pozytywny.
Poprawne przejście zestawu testów funkcjonalnych stanowi zazwyczaj kryterium akceptacji odbioru systemu przez zamawiającego, dlatego testy takie często nazywane są testami akceptacyjnymi. Testy te wykonywane są w środowisku odzwierciedlającym docelowe środowisko systemu z uwzględnieniem wszystkich wymagań aplikacji, takich jak dostępność zasobów softwarowych (np. zainstalowana przeglądarka internetowa) lub też sprzętowych (karta dźwiękowa, połączenie internetowe). Testy takie przeznaczone są do wykonywania przez testerów i ich realizacja w sposób umożliwiający automatyczne wykonywanie w procesie ciągłej integracji nie może być pominięta. Jednak dzięki zastosowaniu dostępnych narzędzi możliwe jest wykonanie testów funkcjonalnych w sposób automatyczny.
Test niefunkcjonalne
Istnieje szereg oczekiwań stawianych przez klienta w stosunku do tworzonego oprogramowania, których nie da się w sposób jednoznaczny powiązać z dostarczaną funkcjonalnością. Przykładem takiego wymagania jest zachowywanie odpowiednich czasów przetwarzania danych wprowadzonych przez użytkowników i czasów odpowiedzi na poszczególne zapytania co możemy nazwać wydajnością systemu.
Przetestowanie wymagań niefunkcjonalnych jest możliwe jedynie poprzez zastosowanie strategii czarnej skrzynki.
Wydajność
Testy wydajnościowe pozwalają na wykrycie tych spośród komponentów systemu, które nie zachowują odpowiednich metryk wydajnościowych i wymagają optymalizacji. Służą również do identyfikacji potencjalnych wąskich gardeł, które obniżają sprawność systemu w przypadku zwiększonego obciążenia (np. komunikacja z systemami zewnętrznymi lub nadmierne zużycie pamięci).
Obciążenie
Testowanie obciążeniowe pozwala zweryfikować, czy nałożone wymagania wydajnościowe są spełniane w przypadku, gdy system używany jest równolegle przez zdefiniowaną liczbę użytkowników.
Wytrzymałość
Testy wytrzymałościowe, powszechnie stosowane do wyznaczenia maksymalnej liczby użytkowników, których system jest w stanie jednocześnie obsłużyć. Jeżeli liczba ta jest mniejsza od określonej w wymaganiach, zachowanie systemu uznawane jest za błędne. W kryterium wytrzymałości zawiera się też weryfikacja spełnienia wymagań wydajnościowych w przypadku chwilowego, znacznie zwiększonego obciążenia systemu. Jest to szczególnie istotne podczas testowania systemów dostępnych publicznie, np. portali internetowych w których obciążenie może wzrosnąć drastycznie po opublikowaniu jakiejś
wiadomości.