1. Strona główna
  2. Sylabus poziomu podstawowego ISTQB 2018 (wersja 1.01)
  3. 2. Testowanie w cyklu życia oprogramowania
  4. 2.2. Poziomy testów
  5. 2.2.2. Testowanie integracyjne

2.2.2. Testowanie integracyjne

Cele testowania integracyjnego

Testowanie integracyjne skupia się na interakcjach między modułami lub systemami. Cele testowania integracyjnego to:

  • zmniejszanie ryzyka;
  • sprawdzanie zgodności zachowań funkcjonalnych i niefunkcjonalnych interfejsów z projektem i specyfikacjami;
  • budowanie zaufania do jakości interfejsów;
  • wykrywanie defektów (które mogą występować w samych interfejsach lub w modułach/systemach);
  • zapobieganie przedostawaniu się defektów na wyższe poziomy testowania.

Podobnie jak w przypadku testowania modułowego, istnieją sytuacje w których automatyczne integracyjne testy regresji pozwalają uzyskać pewność, że wprowadzone zmiany nie spowodowały nieprawidłowej pracy dotychczas działających interfejsów, modułów lub systemów.

W niniejszym sylabusie opisano dwa różne poziomy testowania integracyjnego, które mogą być wykonywane w odniesieniu do przedmiotów testów różnej wielkości:

  • Testowanie integracji modułów skupia się na interakcjach i interfejsach między integrowanymi modułami. Testy tego typu wykonuje się po zakończeniu testowania modułowego (zwykle są to testy automatyczne). W przypadku iteracyjnego i przyrostowego modelu wytwarzania oprogramowania testy integracji modułów są zwykle elementem procesu ciągłej integracji.
  • Testowanie integracji systemów skupia się na interakcjach i interfejsach między systemami, pakietami i mikrousługami. Testy tego typu mogą również obejmować interakcje z interfejsami dostarczanymi przez organizacje zewnętrzne (np. dostawców usług internetowych — ang. Web Services). W takim przypadku organizacja wytwarzająca oprogramowanie nie kontroluje interfejsów zewnętrznych, co może stwarzać wiele problemów w obszarze testowania (związanych np. z usuwaniem defektów w kodzie tworzonym przez organizację zewnętrzną, które blokują testowanie, bądź z przygotowywaniem środowisk testowych). Testowanie integracji systemów może odbywać się po zakończeniu testowania systemowego lub równolegle do trwającego testowania systemowego (dotyczy to zarówno sekwencyjnego, jak i przyrostowego wytwarzania oprogramowania).

Podstawa testów

Przykładowe produkty pracy, które mogą być wykorzystywane jako podstawa testów w ramach testowania integracyjnego, to między innymi:

  • projekt oprogramowania i systemu;
  • diagramy sekwencji;
  • specyfikacje interfejsów;
  • przypadki użycia;
  • architektura na poziomie modułów i systemu;
  • przepływy pracy;
  • definicje interfejsów zewnętrznych.

Przedmioty testów

Do typowych przedmiotów testów zalicza się:

  • podsystemy;
  • bazy danych;
  • infrastrukturę;
  • interfejsy;
  • interfejsy programowania aplikacji (ang. Application Programming InterfaceAPI);
  • mikrousługi.

Typowe defekty i awarie

Przykładami typowych defektów i awarii wykrywanych w ramach testowania integracji modułów są:

  • niepoprawne lub brakujące dane bądź niepoprawne kodowanie danych;
  • niepoprawne uszeregowanie lub niepoprawna synchronizacja wywołań interfejsów;
  • niezgodności interfejsów;
  • błędy komunikacji między modułami;
  • brak obsługi lub nieprawidłowa obsługa błędów komunikacji między modułami;
  • niepoprawne założenia dotyczące znaczenia, jednostek lub granic danych przesyłanych między modułami.

Przykładami typowych defektów i awarii wykrywanych w ramach testowania integracji systemów są:

  • niespójne struktury komunikatów przesyłanych między systemami;
  • niepoprawne lub brakujące dane bądź niepoprawne kodowanie danych;
  • niezgodność interfejsów;
  • błędy komunikacji między systemami;
  • brak obsługi lub nieprawidłowa obsługa błędów komunikacji między systemami;
  • niepoprawne założenia dotyczące znaczenia, jednostek lub granic danych przesyłanych między systemami;
  • nieprzestrzeganie rygorystycznych, obowiązujących przepisów dotyczących zabezpieczeń.

Konkretne podejścia i odpowiedzialności

Testowanie integracji modułów i testowanie integracji systemów powinno koncentrować się na samej integracji. Przykładem takiego podejścia jest integrowanie modułu A z modułem B, podczas którego testy powinny skupiać się na komunikacji między tymi modułami, a nie na funkcjonalności każdego z nich (funkcjonalność ta powinna być przedmiotem testowania modułowego). Analogicznie w przypadku integrowania systemu X z systemem Y testerzy powinni skupiać się na komunikacji między tymi systemami, a nie na funkcjonalności każdego z nich (funkcjonalność ta powinna być przedmiotem testowania systemowego). Na tym poziomie można przeprowadzać testy funkcjonalne, niefunkcjonalne i strukturalne.

Testowanie integracji modułów jest często obowiązkiem programistów, natomiast za testowanie integracji systemów zwykle odpowiadają testerzy. O ile jest to możliwe, testerzy wykonujący testowanie integracji systemów powinni znać architekturę systemu, a ich spostrzeżenia powinny być brane pod uwagę na etapie planowania integracji.

Zaplanowanie testów integracyjnych i strategii integracji przed zbudowaniem modułów lub systemów umożliwia wytworzenie tych modułów lub systemów w sposób zapewniający maksymalną efektywność testowania. Usystematyzowane strategie integracji mogą być oparte na architekturze systemu (np. strategie zstępujące lub wstępujące), zadaniach funkcjonalnych, sekwencjach przetwarzania transakcji bądź innych aspektach systemu lub modułów. Aby uprościć lokalizowanie defektów i umożliwić ich wczesne wykrywanie, integrację należy przeprowadzać metodą przyrostową (np. niewielka liczba jednocześnie dodawanych komponentów lub systemów). Nie zaleca się integracji metodą „wielkiego wybuchu”, polegającą na zintegrowaniu wszystkich modułów lub systemów naraz. W odpowiednim ukierunkowaniu testowania integracyjnego może również pomóc analiza ryzyka związanego z najbardziej złożonymi interfejsami.

Im szerszy jest zakres integracji, tym trudniej jest wskazać konkretny moduł lub system, w którym wystąpiły defekty, co może prowadzić do wzrostu ryzyka i wydłużenia czasu diagnozowania problemów. Jest to jeden z powodów, dla których powszechnie stosuje się metodę ciągłej integracji, polegającą na integrowaniu oprogramowania moduł po module (np. integracja funkcjonalna). Elementem ciągłej integracji jest często automatyczne testowanie regresji, które w miarę możliwości powinno odbywać się na wielu poziomach testów.