Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Inżynieria Oprogramowania 9. Testowanie oprogramowania Leszek J Chmielewski Wydział Zastosowań Informatyki i Matematyki SGGW www.lchmiel.pl.

Podobne prezentacje


Prezentacja na temat: "Inżynieria Oprogramowania 9. Testowanie oprogramowania Leszek J Chmielewski Wydział Zastosowań Informatyki i Matematyki SGGW www.lchmiel.pl."— Zapis prezentacji:

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

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

3 Inżynieria oprogramowania 9. Testowanie oprogramowania 3/34 Plan Wstęp Testowanie defektów Testowanie integracyjne Testowanie obiektowe Warsztaty do testowania Podsumowanie

4 Inżynieria oprogramowania 9. Testowanie oprogramowania 4/34 Plan Wstęp Testowanie defektów Testowanie integracyjne Testowanie obiektowe Warsztaty do testowania Podsumowanie

5 Inżynieria oprogramowania 9. Testowanie oprogramowania 5/34 Metody nieformalne Specyfikacja wymagań Specyfikacja systemu Projekt systemu Projekt szczegółowy Test akceptacyjny Plan testów akceptacyjnych Plan testów integracji systemu Plan testów integracji podsystemu Testy modułów i jednostek Test integracji systemu Test integracji podsystemu Działanie Testowanie komponentów Testowanie integracyjne Twórca oprogramowania Zespół testujący integrację 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

6 Inżynieria oprogramowania 9. Testowanie oprogramowania 6/34 Plan Wstęp Testowanie defektów Testowanie integracyjne Testowanie obiektowe Warsztaty do testowania Podsumowanie

7 Inżynieria oprogramowania 9. Testowanie oprogramowania 7/34 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 Inżynieria oprogramowania 9. Testowanie oprogramowania 8/34 Model testowania defektów Dane testowe można generować automatyczne, przypadki testowe – nie Testować trzeba tylko podzbiór dopuszczalnych przypadków testowych Do wyboru tego podzbioru – strategia Opracuj przypadki testowe Przypadki testowe Przygotuj dane testowe Uruchom na nich program Porównaj wyniki z przypadkami testowymi Dane testowe Wyniki testów Raport z testów

9 Inżynieria oprogramowania 9. Testowanie oprogramowania 9/34 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 Inżynieria oprogramowania 9. Testowanie oprogramowania 10/34 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ę Testowe dane wejściowe Wej b Wyniki testów Wyj b Dane wejściowe powodujące anormalne zachowanie Dane wyjściowe umożliwiające wykrycie defektów System

11 Inżynieria oprogramowania 9. Testowanie oprogramowania 11/34 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 Inżynieria oprogramowania 9. Testowanie oprogramowania 12/34 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 Inżynieria oprogramowania 9. Testowanie oprogramowania 13/34 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 Inżynieria oprogramowania 9. Testowanie oprogramowania 14/34 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,

15 Inżynieria oprogramowania 9. Testowanie oprogramowania 15/34 Testowanie strukturalne: Testowanie ścieżek Liczba niezależnych ścieżek? O(n)? O(n 2 )? O(n 3 )? = złożoność cykliczna Grafu ZC(G) = L_krawędzi(G) – L_węzłów(G) =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

16 Inżynieria oprogramowania 9. Testowanie oprogramowania 16/34 Plan Wstęp Testowanie defektów Testowanie integracyjne Testowanie obiektowe Warsztaty do testowania Podsumowanie

17 Inżynieria oprogramowania 9. Testowanie oprogramowania 17/34 Specyfika testowania integracyjnego Zdecydowanie najłatwiej jest testować w procesie integrowania przyrostowego – zalecany ze względu na testy integracyjne Moduł M a, testy T a + Moduł M b, testy T a + T b + Moduł M c, testy T a + T b + T c... Interakcje między modułami zaburzają ten prosty schemat

18 Inżynieria oprogramowania 9. Testowanie oprogramowania 18/34 Testowanie wstępujące i zstępujące Wstę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 Inżynieria oprogramowania 9. Testowanie oprogramowania 19/34 Testowanie wstępujące i zstępujące Wstę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 Komponent poziomu N+1 Sterownik testowania Namiastka komponentu poziomu N+1

20 Inżynieria oprogramowania 9. Testowanie oprogramowania 20/34 Testowanie wstępujące i zstępujące Wstę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 Komponent poziomu N+1 Sterownik testowania Namiastka komponentu poziomu N+1 Namiastka Korek

21 Inżynieria oprogramowania 9. Testowanie oprogramowania 21/34 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 Inżynieria oprogramowania 9. Testowanie oprogramowania 22/34 Testowanie interfejsów Sterowniki testów nie symulują całego systemu, a namiastka – gotowego modułu Interfejsy: 1. Parametryczne 2. W pamięci dzielonej 3. Proceduralne – podsystem obudowuje zbiór procedur, dostarczając interfejsu do nich 4. Z przekazywaniem komunikatów

23 Inżynieria oprogramowania 9. Testowanie oprogramowania 23/34 Klasy błędów Niewłaściwe użycie interfejsu najczęściej interfejsy parametryczne Niezrozumienie interfejsu źle zrozumiana specyfikacja, fałszywe założenia Błędy synchronizacji w systemach czasu rzeczywistego, odbiorca dostaje nieaktualne dane pamięć dzielona, przekazywanie komunikatów Uwaga: Nie każdy błąd powstaje w jednym miejscu np. interakcja usterek kilku modułów

24 Inżynieria oprogramowania 9. Testowanie oprogramowania 24/34 Kilka zasad Jawnie wypisz wywołania zewnętrznych komponentów; w testach uwzględnij parametry leżące na granicach zakresów Testuj zerowe wartości wskaźników W interfejsie proceduralnym: niech test wywoła awarię komponentu – wykryjesz nieporozumienia co do specyfikacji W interfejsie z komunikatami: spowoduj przeciążenie W interfejsie wielu komponentów z pamięcią dzieloną: wypróbuj różne kolejności wywoływania komponentów – sprawdzisz niejawne założenia

25 Inżynieria oprogramowania 9. Testowanie oprogramowania 25/34 Plan Wstęp Testowanie defektów Testowanie integracyjne Testowanie obiektowe Warsztaty do testowania Podsumowanie

26 Inżynieria oprogramowania 9. Testowanie oprogramowania 26/34 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

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

28 Inżynieria oprogramowania 9. Testowanie oprogramowania 28/34 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

29 Inżynieria oprogramowania 9. Testowanie oprogramowania 29/34 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.

30 Inżynieria oprogramowania 9. Testowanie oprogramowania 30/34 Plan Wstęp Testowanie defektów Testowanie integracyjne Testowanie obiektowe Warsztaty do testowania Podsumowanie

31 Inżynieria oprogramowania 9. Testowanie oprogramowania 31/34 Warsztaty do testowania Przykład struktury Specyfikacja Generator danych testowych Dane testowe Wyrocznia Oracle Wyniki testów Spodziewane wyniki Narzędzie do porównywania plików Generator raportów Raport z wynikami testów Menedżer testów Testowany program Symulator środowiska Analizator dynamiczny Raport z wykonania programu Kod źródłowy

32 Inżynieria oprogramowania 9. Testowanie oprogramowania 32/34 Warsztaty do testowania Przykład struktury Specyfikacja Generator danych testowych Dane testowe Wyrocznia Oracle Wyniki testów Spodziewane wyniki Narzędzie do porównywania plików Generator raportów Raport z wynikami testów Menedżer testów Testowany program Symulator środowiska Analizator dynamiczny Raport z wykonania programu Kod źródłowy

33 Inżynieria oprogramowania 9. Testowanie oprogramowania 33/34 Plan Wstęp Testowanie defektów Testowanie integracyjne Testowanie obiektowe Warsztaty do testowania Podsumowanie

34 Inżynieria oprogramowania 9. Testowanie oprogramowania 34/34 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


Pobierz ppt "Inżynieria Oprogramowania 9. Testowanie oprogramowania Leszek J Chmielewski Wydział Zastosowań Informatyki i Matematyki SGGW www.lchmiel.pl."

Podobne prezentacje


Reklamy Google