Testy integracyjne mają na celu wykrycie błędów w interfejsach oraz interakcjach między poszczególnymi modułami bądź systemami. Czym jest i do czego konkretnie służy tego typu testowanie? Na czym polega? Jakie są jego rodzaje i czym różnią się testy integracyjne od systemowych? Po odpowiedzi na te i inne pytania zapraszamy do dalszej części artykułu.

Testy integracyjne — co to?

Testy integracyjne wykonuje się po to, aby wykryć defekty występujące w interfejsach i interakcjach między modułami lub systemami. Testowanie integracyjne jest rodzajem testowania, w którym moduły oprogramowania są logicznie zintegrowane i testowane jako grupa. 

Typowy projekt oprogramowania składa się z wielu modułów, kodowanych przez różnych programistów. Celem tego typu testowania jest odnalezienie błędów w interakcjach modułów, gdy są one zintegrowane. Testowanie integracyjne skupia się na sprawdzaniu komunikacji danych między tymi komponentami.

Poszczególne moduły najpierw testowane są oddzielnie (jednostkowo), a dopiero po tym integrowane są jeden po drugim, aż do całkowitej integracji wszystkich. Działanie to ma na celu sprawdzenie zachowania kombinacji oraz weryfikację, czy wymagania są zaimplementowane poprawnie, czy też nie. Warto tu zaznaczyć, że testowanie integracyjne odbywa się jeszcze w trakcie cyklu wytwarzania oprogramowania, a nie na sam koniec. Często więc zdarza się, że nie wszystkie moduły, dostępne są na tym etapie do testowania (dlatego czasami do testów musimy wykorzystać sterowniki lub zaślepki).

Testy integracyjne — dlaczego są potrzebne?

Pomimo iż każdy moduł oprogramowania testowany jest jednostkowo, z wielu różnych powodów, nadal mogą pojawiać się defekty. Dzieje się tak dlatego, że ogólnie rzecz biorąc moduły programowane są indywidualnie, przez różnych programistów, których logika, sposób myślenia i pracy w naturalny sposób różnią się od siebie. Testy integracyjne stają się więc konieczne, by sprawdzić, czy moduły oprogramowania działają poprawnie w jedności, tzn. czy po prostu ze sobą poprawnie współpracują.

Ponadto w trakcie tworzenia modułu, może nastąpić zmiana wymagań klienta. Z uwagi na to, że nowe wymagania mogą nie być testowane indywidualnie, konieczne jest testowanie integracji systemu. Oprócz tego błędy zawierać mogą także interfejsy modułów oprogramowania z bazą danych czy zewnętrzne interfejsy sprzętowe (jeśli istnieją). Nieodpowiednia obsługa wątków, również może powodować problemy i nieprawidłowości w działaniu całej aplikacji.

Testowanie integracyjne zapewnia prawidłowe działanie modułów i wykrywanie błędów związanych z interfejsem. Co więcej, testowanie integracyjne można rozpocząć już po udostępnieniu testowanych modułów. Przeprowadzenie testów nie wymaga bowiem uprzedniego zakończenia drugiego modułu, gdyż można w tym celu użyć zaślepek lub sterowników.

Rodzaje testów integracyjnych

Testy integracyjne różnią się od siebie ze względu na poziom podejścia — wyróżniamy podejście “wielkiego wybuchu” tzn. Big Bang oraz przyrostowe. Składają się na nie: podejścia Top-Down, Bottom – Up oraz ich połączenie. Poniżej podajemy rodzaje integracji testowych, wraz z ich najważniejszymi cechami.

• Podejście wielkiego wybuchu (Big Bang) — integruje wszystkie moduły jednocześnie, a nie jeden po drugim. Sprawdza, czy system działa zgodnie z oczekiwaniami. Jeśli jakiś defekt zostanie wykryty w całkowicie zintegrowanej aplikacji, trudno będzie ustalić, który moduł spowodował problem.

Podejście Big Bang sprawdza się dobrze, przy małych systemach. Jednakże przy pomocy tego podejścia trudno jest określić miejsce, w którym występuje defekt (czy jest to w komponencie, czy może w interfejsie?), wyzwaniem jest też nabrać pewności, czy wszystkie przypadki z poziomu testów integracyjnych, pokryte są testami. Ponadto błędy obecne w interfejsach komponentów wykrywane są, w bardzo późnej fazie testowej, istnieje tutaj też duże ryzyko niewykrycia błędów, które mogą się ujawnić dopiero w wersji produkcyjnej systemu

• Podejście przyrostowe (od góry do dołu)  — technika ta rozpoczyna się od najwyższego modułu i stopniowo postępuje ku niższym. Tylko górny moduł jest testowany w izolacji. Następnie dolne są integrowane jeden po drugim. Proces ten jest powtarzany, aż wszystkie zostaną zintegrowane i przetestowane. W celu testowania najwyższych modułów trzeba opracować zaślepki. Można je nazwać fragmentem kodu, który symuluje i akceptuje dane wejściowe/żądania z nadrzędnego modułu i zwraca wyniki/odpowiedź. W ten sposób pomimo braku modułów niższych jesteśmy w stanie przetestować ten górny.

Zarówno zaślepki, jak i sterowniki są fikcyjnym fragmentem kodu, który jest używany do testowania „nieistniejących” modułów. Uruchamiają funkcje/metodę i zwracają odpowiedź, która jest porównywana z oczekiwanym zachowaniem

W praktycznych scenariuszach zachowanie kodów pośredniczących nie jest takie proste, jak się wydaje. Tworzenie zaślepek bywa złożone i czasochłonne.

• Podejście przyrostowe (od dołu do góry) — rozpoczyna się od komponentów położonych najniżej i stopniowo przesuwa się w górę. Testowanie integracyjne trwa do momentu, aż wszystkie elementy staną się zintegrowane, a cała aplikacja zostanie przetestowana jako pojedyncza jednostka (testowanie systemowe). Sterowniki z ang. drivers to fikcyjne programy służące do wywoływania funkcji najniższego modułu, w przypadku, gdy funkcja wywołująca nie istnieje. Technika Bottom-Up wymaga, by sterownik modułu przekazywał dane wejściowe przypadku testowego do interfejsu testowanego modułu.

Przy podejściu Bottom — Up łatwo wykryć i wdrożyć działania naprawcze, przy usterkach występujących w najniższych jednostkach programu. Do wad tego sposobu testowania integracyjnego zaliczyć można to, że główny program faktycznie nie istnieje do momentu, aż ostatni moduł nie zostanie zintegrowany i przetestowany. Rezultatem tego, może być odkrycie potencjalnych wad projektowych wyższego poziomu, dopiero na samym końcu.

Zaślepki i Sterowniki w testach integracyjnych

Warto wiedzieć, że zaślepki i sterowniki to atrapy programów w testach integracyjnych. Służą one do ułatwienia działań związanych z testowaniem oprogramowania. Programy te działają jako substytuty brakujących modeli w testach. Nie implementują całej logiki programowania modułu oprogramowania, ale symulują komunikację danych z modułem wywołującym, podczas testowania. Zaślepka jest wywoływana przez testowany moduł, natomiast sterownik go wywołuje.

Jak wykonywać testy integracyjne?

Poniżej przedstawiamy prostą procedurę wykonywania testów integracyjnych, która sprawdzi się niezależnie od strategii testowania oprogramowania (które omówione zostały wcześniej):

1. Przygotowanie planu testów integracyjnych

2. Zaprojektowanie scenariuszy testowych, przypadków i skryptów.

3. Wykonywanie scenariuszy i  przypadków testowych, i  zgłaszanie usterek.

4. Śledzenie i ponowne testowanie, wykrytych wcześniej defektów.

Dwa ostatnie kroki należy powtarzać aż do pomyślnego zakończenia testów integracyjnych.

Różnice między testowaniem integracyjnym a systemowym

Testowanie integracyjne to proces, w którym moduły są testowane pod względem ich wzajemnej komunikacji, integracji. Weryfikacja tego typu jest przeprowadzana w celu sprawdzenia, czy zintegrowane moduły działają zgodnie z oczekiwaniami, czy też nie. Natomiast testowanie systemowe to proces, w którym testowany jest system jako całość — tzn. wszystkie moduły/komponenty są wtedy już ze sobą zintegrowane. Dzieje się tak, aby sprawdzić, czy system działa zgodnie z oczekiwaniami i czy nie występują żadne błędy ani problemy w całym systemie.

Testy integracyjne są ważną częścią cyklu testowania, ponieważ umożliwiają znajdowanie defektów, we współdziałaniu zaprogramowanych modułów oprogramowania . Pomaga to w odnalezieniu wad już na wczesnym etapie, co z kolei oszczędza wysiłku, kosztów i równocześnie upewnia nas w tym, że zintegrowane moduły działają zgodnie z oczekiwaniami.