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.1. Testowanie modułowe

2.2.1. Testowanie modułowe

Cele testowania modułowego

Testowanie modułowe (zwane także testowaniem jednostkowym, testowaniem komponentów lub testowaniem programu) skupia się na modułach, które można przetestować oddzielnie. Cele tego typu testowania to między innymi:

  • zmniejszanie ryzyka;
  • sprawdzanie zgodności zachowań funkcjonalnych i niefunkcjonalnych modułu z projektem i specyfikacjami;
  • budowanie zaufania do jakości modułu;
  • wykrywanie defektów w module;
  • zapobieganie przedostawaniu się defektów na wyższe poziomy testowania.

W niektórych przypadkach — zwłaszcza w przyrostowych i iteracyjnych modelach wytwarzania oprogramowania (np. modelu zwinnym), w których zmiany kodu mają charakter ciągły — automatyczne modułowe testy regresji są kluczowym elementem pozwalającym uzyskać pewność, że wprowadzone zmiany nie spowodowały nieprawidłowej pracy innych, istniejących i działających już modułów.

Testy modułowe są często wykonywane w izolacji od reszty systemu (zależnie od modelu cyklu życia oprogramowania i konkretnego systemu), przy czym w takiej sytuacji może być konieczne użycie atrap obiektów (ang. mock object), wirtualizacji usług, jarzm testowych, zaślepek bądź sterowników. Testowanie modułowe może obejmować funkcjonalność (np. poprawność obliczeń), parametry niefunkcjonalne (np. wycieki pamięci) oraz właściwości strukturalne (np. testowanie decyzji).

Podstawa testów

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

  • projekt szczegółowy;
  • kod;
  • model danych;
  • specyfikacje modułów.

Przedmioty testów

Do typowych przedmiotów testów dla testów modułowych zalicza się:

  • moduły, jednostki lub komponenty;
  • kod i struktury danych;
  • klasy;
  • moduły baz danych.

Typowe defekty i awarie

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

  • niepoprawna funkcjonalność (np. niezgodna ze specyfikacją projektu);
  • problemy z przepływem danych;
  • niepoprawny kod i logika.

Defekty są zwykle usuwane natychmiast po wykryciu, często bez formalnego procesu zarządzania nimi. Należy jednak zaznaczyć, że zgłaszając defekty, programiści dostarczają ważne informacje na potrzeby analizy przyczyny podstawowej i doskonalenia procesów.

Konkretne podejścia i odpowiedzialności

Testowanie modułowe jest zwykle wykonywane przez programistę będącym autorem kodu, a przynajmniej wymaga dostępu do testowanego kodu. W związku z tym programiści mogą naprzemiennie tworzyć moduły i wykrywać/usuwać defekty. Programiści często piszą i wykonują testy po napisaniu kodu danego modułu. Jednakże, w niektórych przypadkach — zwłaszcza w przypadku zwinnego wytwarzania oprogramowania — automatyczne przypadki testowe do testowania modułowego można również tworzyć przed napisaniem kodu aplikacji.

Warto w tym miejscu omówić przykład wytwarzania sterowanego testami (ang. Test Driven DevelopmentTDD). Model ten ma charakter wysoce iteracyjny i opiera się na cyklach obejmujących tworzenie automatycznych przypadków testowych, budowanie i integrowanie niewielkich fragmentów kodu, wykonywanie testów modułowych, rozwiązywanie ewentualnych problemów oraz refaktoryzację kodu. Proces ten jest powtarzany do momentu ukończenia modułu i zaliczenia wszystkich testów modułowych. Wytwarzanie sterowane testami jest przykładem podejścia typu „najpierw testuj”. Model ten był pierwotnie stosowany w ramach programowania ekstremalnego (ang. eXtreme ProgrammingXP), ale upowszechnił się również w innych modelach zwinnych oraz cyklach sekwencyjnych (patrz [ISTQB® AT]).