Inżynieria Oprogramowania 9. Testowanie oprogramowania

Prezentacja na temat: "Inżynieria Oprogramowania 9. Testowanie oprogramowania"— Zapis prezentacji:

1 Inżynieria Oprogramowania 9. Testowanie oprogramowania
26/03/2017 Inżynieria Oprogramowania 9. Testowanie oprogramowania Leszek J Chmielewski Wydział Zastosowań Informatyki i Matematyki SGGW

2 Źródła Materiały dra Waldemara Karwowskiego, wykładowcy w poprzednich semestrach Ian Sommerville, Inżynieria Oprogramowania, WNT, Warszawa 2003

3 Plan Wstęp Testowanie defektów Testowanie integracyjne
Testowanie obiektowe Warsztaty do testowania Podsumowanie

4 Plan Wstęp Testowanie defektów Testowanie integracyjne
Testowanie obiektowe Warsztaty do testowania Podsumowanie

5 Metody nieformalne Metody formalne: do systemów krytycznych
Specyfikacja wymagań Specyfikacja systemu Projekt systemu Projekt szczegółowy Testowanie komponentów Testowanie integracyjne Twórca oprogramowania Zespół testujący integrację Plan testów akceptacyjnych Plan testów integracji systemu Plan testów integracji podsystemu Testy modułów i jednostek Metody formalne: do systemów krytycznych Zwyczajne przypadki: testowanie na podstawie ogólnego opisu funkcji elementów Jednak integracja musi być przetestowana na podstawie pisemnej specyfikacji systemu Robi się to różnie w systemach funkcyjnych i obiektowych Działanie Test akceptacyjny Test integracji systemu Test integracji podsystemu

6 Plan Wstęp Testowanie defektów Testowanie integracyjne
Testowanie obiektowe Warsztaty do testowania Podsumowanie

7 Specyfika testowania defektów
Nie w celu zatwierdzenia – stwierdzenia realizacji funkcjonalności, ale w celu ujawnienia defektów Pozytywnym wynikiem testu jest znalezienie defektu

8 Model testowania defektów
Przypadki testowe Dane testowe Wyniki testów Raport z testów Opracuj przypadki testowe Przygotuj dane testowe Uruchom na nich program Porównaj wyniki z przypadkami testowymi Dane testowe można generować automatyczne, przypadki testowe – nie Testować trzeba tylko podzbiór dopuszczalnych przypadków testowych Do wyboru tego podzbioru – strategia

9 Strategia wyboru przypadków testowych
Przykład: Przetestować wszystkie funkcje dostępne z menu Przetestować wszystkie kombinacje funkcji dostępnych z tego samego menu (wyobraźmy sobie edytor tekstu) Przetestować wszystkie funkcje, w których użytkownik wprowadza dane dane poprawne dane niepoprawne (Świadomie pominęliśmy tu rzadkie kombinacje funkcjonalności)

10 Testowanie czarnej skrzynki
Testy wyprowadza się ze specyfikacji, nie biorąc pod uwagę struktury programu Inaczej: testowanie funkcjonalne – bierze się pod uwagę tylko funkcjonalność, a nie implementację Dane wejściowe powodujące anormalne zachowanie Wejb Testowe dane wejściowe Dane wyjściowe umożliwiające wykrycie defektów System Wyjb Wyniki testów

11 Czarna skrzynka: Dzielenie na klasy równoważności
Jak dobrać dane, aby ujawnić defekty? Wykrywamy w danych strukturę: klasy równoważności Testujemy centra i granice klas Przykład: konto telefonu komórkowego z rachunkiem Klasy równoważności: konto rozmów, usługa „darmowe wieczory”, usługa Internet z limitem, „pakiet rodzinny”, ... „środki” klas: stany typowe granice klas: rachunek nie opłacony, rozmowa rozpoczęta na granicy czasu „wieczory”, przekraczamy granicę transferu w pakiecie Internet, dokupujemy dodatkowy pakiet, telefon w pakiecie staje się nieaktywny, ...

12 Testowanie strukturalne
Zwane biała skrzynka, szklana, przezroczysta skrzynka – widać, co jest w środku Widać strukturę oprogramowania Można rozszerzyć wiedzę o klasach równoważności widać warunki, nie tylko dane

13 Testowanie strukturalne: Testowanie ścieżek
Praktyczne dla jednostek mniejszych wzrost złożoności Nie testujemy wszystkich możliwych ścieżek Tylko tak, aby każde rozgałęzienie wykonano dla wszystkich możliwych wyjść każda instrukcja była wykonana co najmniej raz

14 Testowanie strukturalne: Testowanie ścieżek
1, 2, 3, 8, 9 1, 2, 3, 4, 6, 7, 2 1, 2, 3, 4, 5, 7, 2 1, 2, 3, 4, 6, 7, 2, 8, 9 Nie: 1, 2, 8, 9 1 2 3 4 8 5 6 9 7

15 Testowanie strukturalne: Testowanie ścieżek
Liczba niezależnych ścieżek? O(n)? O(n2)? O(n3)? = złożoność cykliczna Grafu ZC(G) = L_krawędzi(G) – L_węzłów(G) + 2 11-9+2=4 Jeśli nie ma skoków w Programie: ZC(P) = L_warunków(P) + 1 Przypadki testowe dla każdej ścieżki Dynamiczny analizator programu - Profiler 1 2 3 4 8 5 6 9 7

16 Plan Wstęp Testowanie defektów Testowanie integracyjne
Testowanie obiektowe Warsztaty do testowania Podsumowanie

17 Specyfika testowania integracyjnego
Zdecydowanie najłatwiej jest testować w procesie integrowania przyrostowego – zalecany ze względu na testy integracyjne Moduł Ma, testy Ta + Moduł Mb, testy Ta + Tb + Moduł Mc, testy Ta + Tb + Tc ... Interakcje między modułami zaburzają ten prosty schemat 

18 Testowanie wstępujące i zstępujące
najpierw moduły niskiego poziomu N potem wyższego N-1 ... Zstępujące: system jako całość – struktura, poziom 0 potem moduły poziomu niższego N+1 Wydawałoby się, że testowanie wstępujące jest jedyną rozsądną możliwością ...

19 Testowanie wstępujące i zstępujące
moduły niskiego poziomu N potem wyższy N-1 Zstępujące: struktura systemu, poziom 0 potem niższy N+1 Komponent poziomu N Namiastka komponentu poziomu N+1 Sterownik testowania Namiastka komponentu poziomu N+1 Namiastka komponentu poziomu N+1 Komponent poziomu N+1 Komponent poziomu N+1 Komponent poziomu N+1

20 Testowanie wstępujące i zstępujące
moduły niskiego poziomu N potem wyższy N-1 Zstępujące: struktura systemu, poziom 0 potem niższy N+1 Komponent poziomu N Namiastka  Korek Namiastka komponentu poziomu N+1 Sterownik testowania Namiastka komponentu poziomu N+1 Namiastka komponentu poziomu N+1 Komponent poziomu N+1 Komponent poziomu N+1 Komponent poziomu N+1

21 Testowanie wstępujące i zstępujące
Porównania: Zstępujące: łatwiej zatwierdzić architekturę można zaprezentować koncepcję ALE trudno obserwować testy, bo nie są produkowane prawdziwe wyniki Wstępujące: powstają prawdziwe wyniki ALE trzeba wytwarzać sterowniki testowania

22 Testowanie interfejsów
Podczas laboratorium

23 Plan Wstęp Testowanie defektów Testowanie integracyjne
Testowanie obiektowe Warsztaty do testowania Podsumowanie

24 Specyfika programów obiektowych
Obiekty są zwykle większe, niż funkcje Są luźno powiązane, struktura nie jest ścisła, brak oczywistego „wierzchołka” systemu W programowaniu z użyciem wielokrotnym może nie być dostępu do kodu źródłowego Skutki: Testy białej skrzynki mogą dotyczyć większych jednostek Testowanie integracyjne jest inne

25 Cztery poziomy testowania obiektowego
Testowanie operacji związanych z obiektami testowanie czarnej i białej skrzynki Testowanie klas obiektów rozszerzone podejście do klas równoważności Testowanie gron obiektów testowanie wstępujące/zstępujące  scenariusze Testowanie całego systemu użytkownika nie interesuje obiektowość – zwykłe testy względem specyfikacji wymagań

26 Testowanie klas obiektów
W testowaniu systemów funkcyjnych badano wszystkie instrukcje i wszystkie ścieżki Teraz trzeba również oddzielnie testować wszystkie operacje związane z obiektami – metody zapisywać i odczytywać wszystkie atrybuty obiektów badać obiekty we wszystkich możliwych stanach  symulować wszystkie zdarzenia wywołujące zmianę stanu

27 Integracja obiektów Nie ma ścisłej hierarchii, ale
Zbiór obiektów, które razem oferują określony zbiór usług, nazwiemy gronem Podejścia: Testowanie przypadków użycia, scenariuszy dla gron używamy diagramów przebiegu (sekwencji) Testowanie wątków: reakcji na zdarzenia Testowanie interakcji: ścieżki {zdarzenie wejściowe, ciąg ścieżek metoda-komunikat, zdarzenie wyjściowe} Należy zwrócić uwagę na wyjątki i ich obsługę przez obiekty.

28 Plan Wstęp Testowanie defektów Testowanie integracyjne
Testowanie obiektowe Warsztaty do testowania Podsumowanie

29 Warsztaty do testowania
Podczas laboratorium

30 Plan Wstęp Testowanie defektów Testowanie integracyjne
Testowanie obiektowe Warsztaty do testowania Podsumowanie

31 Podsumowanie Testy często używanych części systemu są najważniejsze
Dziel dane na klasy równoważności; testuj na wartościach centralnych i granicznych Systemy funkcyjne można testować wstępująco i zstępująco Testy czarnej skrzynki – bez znajomości kodu, na podstawie specyfikacji Testy białej skrzynki – strukturalne – na podstawie kodu; warunki i ścieżki Testowanie integracyjne – sprawdza interakcję i interfejsy Defekty interfejsów: często w wyniku błędów rozumienia specyfikacji, fałszywych założeń Testy klas – metody, atrybuty, stany Testy systemów obiektowych trzeba organizować wokół gron obiektów związanych z przypadkami użycia lub wątkami