INŻYNIERIA OPROGRAMOWANIA TESTOWANIE INTEGRACYJNE

Transkrypt

1 INŻYNIERIA OPROGRAMOWANIA TESTOWANIE INTEGRACYJNE

2 Definicja ITQB Testowanie integracyjne (integration testing) wykonywane w celu wykrycia defektów w interfejsach i interakcjach pomiędzy modułami lub systemami Podstawą testowania jest projekt architektury systemu (dla dużych systemów także przypadku użycia)

3 testy integracyjne wykonywane są po testach jednostkowych (kiedy zbiór komponentów zostanie przetestowany, następnym krokiem jest upewnienie się, że interfejsy pomiędzy komponentami są zdefiniowane poprawnie i współdziałają ze sobą) mogą obejmować także testy wydajnościowe

4 NA CZASOCHŁONNOŚĆTESTOWANIA INTEGRACYJNEGO MA WPŁYW KOLEJNOŚĆ ŁĄCZENIA MODUŁÓW PODSTAWOWYM PROBLEMEM W TEJ FAZIE TESTÓW JEST LOKALIZACJA BŁĘDÓW

5 Podział testów (II) Modułowe(małej skali) umożliwia sprawdzenie czy dane pomiędzy modułami są przekazywane poprawnie (definicja ISTQB: Testy wykonywane w celu wykrycia usterek w interfejsach i interakcjach pomiędzy integrowanymi modułami) Systemowe (dużej skali) umożliwia sprawdzenie czy dane pomiędzy systemami są przekazywane poprawnie (definicja ISTQB: Testowanie integracji systemów i pakietów; testowanie interfejsów z organizacjami zewnętrznymi, (np. Elektroniczna Wymiana Danych przez Internet.)).

6 Podział testów (II) Interfejsów wykrywanie usterek w interfejsach między modułami Testowanie interfejsu programowania API odporność na błędy Sprzęt-oprogramowanie (hardware-software integration testing)

7 Podział testów (III) poziome (integracja to budowanie kolejnych warstw systemu, metodyka oparta o hierarchiczną dekompozycję, łatwiejsze zarządzanie za cenę pominięcia aspektów funkcjonalnych) wstępujące zstępujące kanapkowe hurtowe pionowe (integracja to konstruowanie kolejnych modułów funkcjonalnych systemu, jak najszybsza integracja i realizacja przypadków użycia)

8 Namiastki i sterowniki Sterownik (driver) symuluje zachowanie tej części systemu, która wykorzystuje testowany komponent poprzez przekazywanie mu danych wejściowych i obsługiwaniu (najczęściej wyświetlaniu) otrzymywanych wyników. Namiastka (stub) to symulacja komponentów, z których korzysta testowany komponent. Komponenty wchodzące w skład namiastki testowej muszą mieć (w dłuższej perspektywie) API identyczne z API ich oryginałów, (identyczne sygnatury wszystkich metod). Identyczność ta musi być zagwarantowana. Zmiana komponentu oznacza zmianę reprezentującej go namiastki.

9 Co trudniej symulować? NAMIASTKĘ

10 Dlaczego? Nie zawsze wystarcza atrapa ograniczająca swe działanie do wypisywania komunikatów, że właśnie wywołana została jej metoda (w większości sytuacji od namiastki testowej oczekuje się konkretów) Często stworzenie namiastki testowej jest tak trudne, że prościej użyć w tej roli oryginalnych komponentów (dla wielu komponentów dopiero po ich ukończeniu tworzone są sterowniki i namiastki testowe, a jeśli dany komponent implementowany jest w warunkach napiętego (lub przekroczonego) harmonogramu, nie są one tworzone wcale. Aby zapobiec tej niekorzystnej tendencji, wiele metodologii programistycznych wymusza wręcz tworzenie namiastek i sterowników równolegle z budowaniem komponentu oryginalnego; komponent może być testowany na bieżąco, w trakcie tworzenia, a wiele jego usterek może być wykrywanych)

11 Testowanie poziome: hurtowe ( big bang ) każdy komponent z założenia jest na swoim miejscu błędy występujące w interfejsach komponentów wykrywane są w bardzo późnej fazie procesu testowego trudno jest określić miejsce w którym występuje defekt, czy przyczyna błędu leży w komponencie czy w interfejsie w razie wystąpienia usterki wszystkie komponenty są traktowane jako podejrzane i potencjalnie wadliwe. istnieje wysokie możliwość niewykrycia krytycznych błędów, które mogą ujawnić się dopiero w wersji produkcyjnej systemu trudno upewnić się czy wszystkie przypadki z poziomu testów integracyjnych są pokryte testami. ZALETA (JEDYNA?): NAMIASTKI I STEROWNIKI SĄ ZBĘDNE

12 Testowanie poziome: wstępujące (bottom-up) Najniżej położone komponenty testowane są jako pierwsze Sterowniki symulują komponenty położone wyżej w hierarchii (jeszcze nieprzetestowane) Testowane moduły używane są do testowania wyżej położonych komponentów Proces testowy jest kontynuowany do momentu przetestowania komponentów znajdujących się na najwyższym poziomie ZALETA: łatwość identyfikacji miejsca (źródła) usterki: programista zna zasadę działania wszystkich niższych warstw ZALETA: namiastki są niepotrzebne WADA: interfejsy jako najwyższa warstwa organizacji są testowane bardzo późno, co może być kosztowne

13 Testowanie poziome: wstępujące (bottom-up)

14 Testowanie poziome: zstępujące (top-down) Moduły znajdujące się na najwyższym poziomie są testowane jako pierwsze Moduły znajdujące się w hierarchii poniżej, zastępowane/symulowane są przez namiastki (inaczej zaślepki, stubs) Testowane moduły używane są do testowania niżej położonych komponentów Proces testowy jest kontynuowany do momentu przetestowania komponentów znajdujących się na najniższym poziomie ZALETA: sterowniki są niepotrzebne WADA: potrzeba za to dużej liczby namiastek testowych, zwłaszcza w przypadku dużej funkcjonalności systemu (duża liczba metod implementowana z poziomu komponentów niskiego szczebla)

15 Testowanie poziome: zstępujące (top-down)

16 Testowanie poziome: kanapkowe dekompozycja na 3 warstwy (3 grupy warstw): górną ( kromka chleba, integracja zstępująca z warstwą środkową, sterownik dla warstwy środkowej) środkową, docelową ( szynka, pełni rolę namiastki dla warstwy górnej i sterownika dla warstwy dolnej ) dolną ( kromka chleba, integracja wstępująca z warstwą środkową, namiastka dla warstwy środkowej) ZALETA: eliminuje potrzebę tworzenia sterowników i namiastek dla obu skrajnych warstw ZALETA: możliwość zrównoleglenia testów ZALETA: wcześniejsze testowanie komponentów interfesju niż w przypadku testowania wstępującego WADA: deprecjonuje warstwę środkową pod kątem dokładnego przetestowania jej komponentów (brak testów jednostkowych dla warstwy środkowej)

17 Testowanie poziome: kanapkowe (zmodyfikowane) testowanie jednostkowe wszystkich komponentów przed jakąkolwiek integracją warstw Etapy wstępne testowanie warstwy górnej przy użyciu namiastek symulujących warstwę środkową, testowanie warstwy środkowej przy użyciu sterowników i namiastek zastępujących warstwy (odpowiednio) górną i dolną, testowanie warstwy dolnej, przy użyciu sterowników symulujących warstwę środkową 2 testy integracyjne: testowanie warstwy górnej we współpracy z warstwą środkową; można tu ponownie użyć testów dla warstwy środkowej, wykorzystywanych w środkowym etapie fazy wstępnej, testowanie warstwy dolnej we współpracy z warstwą środkową; tu także można ponownie użyć testów dla warstwy środkowej, wykorzystywanych w środkowym etapie fazy wstępnej.

18 Testowanie poziome: kanapkowe (zmodyfikowane) Podobne zrównoleglenia jak dla podstawowej metody kanapkowej ZALETA: testy integracyjne warstw górnej i dolnej (z udziałem namiastek i sterowników zastępujących warstwę środkową) mogą być zrównoleglone z testami jednostkowymi komponentów warstwy środkowej. ZALETA: skrócenie czasu testowania w porównaniu z integrowanie wstępującym i zstępującym WADA: konieczność stworzenia sterowników i namiastek dla komponentów warstwy środkowej, gdy te uczestniczą w testach jednostkowych

19 INTEGRACJA PIONOWA Dla danego przypadku użycia budowany jest sukcesywnie komplet jego funkcjonalności (stopniowe integrowanie komponentów składających się na interfejs użytkownika, logikę biznesową, oprogramowanie pośrednie, magazynowanie danych itp.. integrowanie pionowe jest czymś innym niż budowanie prototypu pionowego przy testowaniu użyteczności prototyp nigdy nie jest namiastką gotowego systemu i nigdy nie stanowi kandydatury do emisji. przyrostowe ewoluowanie projektu systemu, wiążące się z częstym rewidowaniem podjętych wcześniej decyzji projektowych.

20 Zadanie Otrzymałeś kod źródłowy aplikacji która w trakcie pracy przestaje działać. Uruchomiłeś ją 10-krotnie w debuggerze i stwierdziłeś że nigdy nie kończy pracy w tym samym miejscu. Aplikacja jest jednowątkowa i używa tylko biblioteki standardowej języka C. Jakie błędy programistyczne mogą powodować problem? Jak przetestujesz każdy z nich?