©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 1 Testowanie oprogramowania l Przedstawienie metod, które można wykorzystać przy testowaniu.

Prezentacja na temat: "©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 1 Testowanie oprogramowania l Przedstawienie metod, które można wykorzystać przy testowaniu."— Zapis prezentacji:

1 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 1 Testowanie oprogramowania l Przedstawienie metod, które można wykorzystać przy testowaniu programów w celu wykrycia usterek

2 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 2 Cele l Znać kilka metod testowania używanych w celu wykrywania usterek programów; l znać porady dotyczące testowania interfejsów komponentów; l znać specyficzne podejścia do testowania komponentów i testowania integracji systemów obiektowych; l znać zasady działania narzędzi CASE wspomagających testowanie.

3 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 3 Zawartość l Testowanie defektów l Testowanie integracyjne l Testowanie obiektowe l Warsztaty do testowania

4 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 4 Fazy testowania Testowanie komponentów Testowanie komponentów Testowanie integracyjne Testowanie integracyjne Twórca oprogramowania Zespół testujący integrację

5 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 5 Testowanie l W trakcie procesu planowania W i Z menedżerowie muszą podejmować decyzje o tym, kto jest odpowiedzialny za poszczególne fazy testowania. l W większości wypadków programiści odpowiadają za testowanie własnego kodu (modułów lub obiektów). l Po zakończeniu tych czynności do pracy przystępuje zespół integrujący, który łączy moduły różnych programistów, buduje oprogramowanie i testuje system jako całość. l Testowania systemów krytycznych każdy zespół niezależnie opracowuje testy systemu na podstawie szczegółowej specyfikacji każdego komponentu programowego. l Testowanie integracyjne musi być oparte na pisemnej specyfikacji systemu. l Za testowanie integracyjne zawsze odpowiada wydzielony zespół.

6 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 6 Testowanie defektów l Celem testowania defektów jest ujawnienie utajonych defektów w systemie oprogramowania przed dostarczeniem. l Odróżnia to takie testowanie od testowania zatwierdzającego, które ma wykazać, że system spełnia swoją specyfikację. l Testowanie zatwierdzające służy do sprawdzenia za pomocą testów akceptacyjnych, czy system działa poprawnie. l Pozytywny test defektu to test powodujący, że system działa niepoprawnie i w ten sposób ujawniający defekt. Z tego wynika podstawowa właściwość testowania. Testowanie wykazuje obecność, a nie brak defektów programu.

7 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 7 Proces testowania defektów Raport z testowania Raport z testowania Wyniki testów Wyniki testów Dane testowe Dane testowe Przypadki testowe Przypadki testowe Opracuj przypadki testowe Opracuj przypadki testowe Przygotuj dane testowe Przygotuj dane testowe Uruchom program na danych testowych Uruchom program na danych testowych Porównaj wyniki z przypadkami testowymi Porównaj wyniki z przypadkami testowymi

8 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 8 l Należy przetestować wszystkie funkcje systemu dostępne z menu. l Należy przetestować kombinacje funkcji (np. formatowanie tekstu) dostępnych z tego samego menu. l Należy przetestować wszystkie funkcje, w których użytkownik wprowadza dane, zarówno na poprawnych, jak i niepoprawnych danych wejściowych. Strategie testowania

9 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 9 l Testowanie funkcjonalne lub inaczej testowanie czarnej skrzynki to podejście do testowania, przy którym testy wprowadza się ze specyfikacji programu lub komponentu. l System jest „czarną skrzynką”, której zachowanie można ustalić jedynie na podstawie jego danych wejściowych związanych z nimi danych wyjściowych. l Inną nazwą tego podejścia jest testowanie funkcjonalne, ponieważ osoba testująca zajmuje się jedynie funkcjonalnością, a nie implementacją oprogramowania. Testowanie czarnej skrzynki

10 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 10 Testowanie czarnej skrzynki al t he presence of defects Wej b Testowe dane wejściowe Wyj b Wyniki wyjściowe testów System Dane wejściowe powodujące anormalne zachowanie Dane wyjściowe, które umożliwiają wykrycie defektów

11 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 11 Dzielenie na klasy równoważności l Dane wejściowe programu można zakwalifikować do kilku różnych klas. Te klasy określają wspólne właściwości, np. liczby dodatnie, liczby ujemne, napisy bez odstępów itd. l Programy działają zwykle w porównywalny sposób dla wszystkich elementów jednej klasy. l Ze względu na te równoważne zachowania, klasy te są czasem nazywane klasami równoważności lub dziedzinami. l Jedno z systematycznych podejść do testowania defektów polega na zidentyfikowaniu wszystkich klas równoważności, które muszą być obsłużone przez program. Przypadki testowe projektuje się tak, aby dane wejściowe i wyjściowe leżały wewnątrz tych klas.

12 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 12 Dzielenie na klasy równoważności System Niedopuszczalne dane wejściowe Dopuszczalne dane wejściowe Dane wyjściowe

13 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 13 Klasy równoważności Mniej niż 4Między 4 i 10Więcej niż 10 Mniej niż 10 000Między 10 000 i 99 999Więcej niż 99 999 3 7 4 10 11 Liczba wartości wejściowych 9999 100005000099999 100000 Wartości wejściowe

14 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 14 Specyfikacja podprogramu wyszukującego procedure Szukaj (Klucz : ELEM ; T: SEQ of ELEM ; Znaleziono : in out BOOLEAN; L: in out POZ.ELEM) ; Pre-condition -- ciąg ma co najmniej jeden element T’FIRST <= T’LAST Post-condition -- znaleziono element i wskazuje go L ( Znaleziono and T (L) = Klucz) or -- element nie występuje w ciągu ( not Znaleziono and not (exists i, T’FIRST >= i <= T’LAST, T (i) = Klucz ))

15 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 15 TablicaElement Jedna wartośćJest w ciągu Jedna watośćNie ma jej w ciągu Więcej niż 1 wartośćJest pierwszym elememtem w ciągu Więcej niż 1 wartośćJest ostatnim elementem w ciągu Więcej niż 1 wartośćJest środkowym elementem w ciągu Więcej niż 1 wartośćNie ma jej w ciągu Ciąg wejściowy (T)Klucz (Klucz)Wynik (Znaleziono, L) 1717true, 1 170false, ?? 17,29,21,2317true, 1 41,18,9,31,30,16,4523true, 7 17,18,21,23,29,41,3823true, 4 21,23,29,33,3825false, ?? Klasy równoważności dla podprogramu wyszukującego

16 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 16 Testowanie strukturalne l Testowanie strukturalne to podejście do testowania, przy którym testy opracowuje się na podstawie wiedzy o strukturze i implementacji oprogramowania. l To podejście jest czasem nazywane testowaniem “białej skrzynki”, “szklanej skrzynki” lub “przezroczystej skrzynki” w odróżnieniu od testowania czarnej skrzynki. l Testowanie strukturalne stosuje się zwykle do stosunkowo niewielkich jednostek programów, takich jak podprogramy i operacje związane z obiektem. l Jak wskazuje nazwa, osoba testująca może analizować kod i korzystać z wiedzy o strukturze komponentu przy opracowywaniu danych testowych.

17 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 17 Testowanie strukturalne Dane testowe Testowe dane wyjściowe Testowe dane wyjściowe Kod komponentu Jest podstawą oprogramowania Testuje

18 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 18 Implementacja podprogramu wyszukującego binarnie w Javie Class WyszukiwanieBinarne { // Obudowywanie funkcji wyszukiwania binarnego, która pobiera uporządkowaną // tablicę obiektów oraz klucz i przekazuje obiekt z dwoma atrybutami, a dokładniej: // pozycja - numer pozycji w tablicy // znaleziono - wartość logiczna wskazująca, czy klucz znajduje się w tablicy, czy nie // Funkcja przekazuje obiekt, ponieważ w Javie nie ma możliwości przekazywania // do funkcji typów podstawowych przez odniesienie, a więc i przekazania // dwóch wartości // Przekazana pozycja ma wartość -1, jeśli elementu nie znaleziono public static void szukaj (int klucz, int [] tablica,Wynik w ) { int początek = 0 ; int koniec = tablica.length - 1 ; int środek ;

19 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 19 Implementacja podprogramu wyszukującego binarnie w Javie- c.d. w.znaleziono = false ; w.pozycja = -1 ; while ( początek <=koniec ) { środek = (koniec + początek ) / 2 ; if (tablica [środek] == klucz) { w.pozycja = środek ; w.znaleziono = true ; return ; } // gałąź if else { if (tablica [środek] < klucz) początek = środek - 1; } } // pętla while } // szukaj } // Wyszukiwanie Binarne

20 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 20 Klasy równoważności wyszukiwania binarnego Elementy Środek Granice klas równoważności Punkt środkowy

21 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 21 Ciąg wejściowyKlucz (Klucz)Wynik (Znaleziono, L) 1717true, 1 170false, ?? 17,21,23,2917true, 1 9,16,18,30,31,41,4545true, 7 17,18,21,23,29,38,4123true,4 17,18,21,23,29,33,3821true, 3 12,18,21,23,3223true, 4 21,23,29,33,3825false, ?? Przypadki testowe dla podprogramu wyszukującego

22 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 22 Testowanie ścieżek l Testowanie ścieżek to strategia testowania strukturalnego, której celem jest zbadanie każdej niezależnej ścieżki wykonania komponentu lub programu. l Jeśli wykonano każdą niezależną ścieżkę, to wszystkie instrukcje komponentu musiały być wykonane co najmniej raz. l Co więcej, każdą instrukcję strukturalną przetestowano wtedy zarówno dla przypadku prawdy, jak i fałszu. l W procesie tworzenia obiektowego testowanie ścieżek może służyć do testowania metod związanych z obiektami. l Liczba ścieżek w programie jest zwykle proporcjonalna do jego rozmiaru. l Testowanie ścieżek jest więc najczęściej stosowane w fazach testowania jednostkowego i testowania modułów.

23 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 23 l Przed przystąpieniem do testowania ścieżek należy opracować graf strumieni programu, który jest szkieletowym modelem wszystkich ścieżek w programie. l Graf strumieni składa się z węzłów reprezentujących decyzje i krawędzi odpowiadających przepływom sterowania. l Graf strumieni powstaje przez zastąpienie instrukcji sterujących programu równoważnymi diagramami. l Jeśli w programie nie ma instrukcji skoku, to utworzenie jego grafu strumieni jest łatwym procesem. l Budując graf strumieni, możemy pominą instrukcje sekwencyjne (przypisania, wywołania procedur i instrukcje wejścia-wyjścia). l Każda gałąź instrukcji warunkowej (if-then-else lub case) jest przedstawiona w postaci odrębnej ścieżki. l Pętle obrazuje się za pomocą strzałki wstecznie wskazującej węzeł warunku pętli. l Pętle i gałęzie warunkowe uwzględniono w przykładowym grafie strumieni podprogramu wyszukującego binarnie. Graf strumieni

24 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 24 Graf strumieni podprogramu wyszukującego binarnie 7 7 5 5 6 6 9 9 4 4 8 8 3 3 2 2 1 1 początek > koniec while początek <= koniec if (tablica [środek] = = klucz if (tablica [środek] < klucz

25 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 25 l Po odrębnym przetestowaniu komponentów programy należy je zintegrować w gotowy lub częściowo ukończony system. Ten proces integracji polega na zbudowaniu systemu i przetestowaniu otrzymanego systemu w poszukiwaniu problemów związanych z interakcjami komponentów. l Testy integracyjne należy opracować na podstawie specyfikacji systemu. Testowanie integracyjne należy rozpocząć natychmiast po powstaniu zdatnych do użycia wersji komponentów systemu. l Największą trudnością testowania integracyjnego jest lokalizowanie błędów wykrytych w trakcie tego procesu. l Między komponentami systemu zachodzą złożone interakcje. Znalezienie błędu, będącego przyczyną anomalii wykrytych w danych wyjściowych, może być trudne. l Aby ułatwić ową lokalizację błędu, zawsze należy stosować przyrostowe podejście do interakcji i testowania systemu. Na początku należy zintegrować pewną minimalną konfigurację systemu i przetestować otrzymany system. Następnie trzeba dodawać kolejne komponenty do tej minimalnej konfiguracji i testować po każdym dodanym przyroście. Testowanie integracyjne

26 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 26 Przyrostowe testowanie integracyjne T1 T2 T3 A B Zestaw testów nr 1Zestaw testów nr 2Zestaw testów nr 3

27 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 27 Testowanie zstępujące i wstępujące l Strategie testowania zstępująca i wstępująca odzwierciedlają różne podejścia do integracji systemu. l Przy integracji zstępującej integruje i testuje się komponenty systemu wysokiego poziomu przed ukończeniem ich projektu i implementacji. l Przy integracji wstępującej integruje i testuje się komponenty niskiego poziomu przed ukończeniem budowy komponentów wyższego poziomu.

28 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 28 Testowanie zstępujące l Jest integralną częścią zstępującego procesu budowania, który rozpoczyna się od komponentów wysokiego poziomu i polega na przejściu w dół hierarchii komponentów. l Program jest reprezentowany przez pojedynczy abstrakcyjny komponent z komponentami podrzędnymi w postaci namiastek. Namiastka ma taki sam interfejs jak komponent, ale jej funkcjonalność jest bardo ograniczona. l Po zaprogramowaniu i przetestowaniu komponentu najwyższego poziomu w ten sam sposób implementuje i testuje się jego komponenty podrzędne. l Ten proces jest kontynuowany do chwili zaimplementowania komponentów najniższego poziomu. Wówczas cały system jest już w pełni przetestowany.

29 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 29 Testowanie wstępujące l Polega natomiast na integrowaniu i testowaniu modułów niższego poziomu hierarchii, następnie przejściu w górę hierarchii modułów i przetestowaniu ostatecznego modułu. l Przy tym podejściu do rozpoczęcia prac nie jest konieczne ukończenie projektu architektonicznego systemu. l Do procesu testowania można więc przystąpić już we wczesnej fazie tworzenia. l To podejście może być zastosowane tam, gdzie w systemie ponownie wykorzystuje się i modyfikuje komponenty innych systemów.

30 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 30 Zstępujące testowanie integracyjne Poziom 2 Poziom 1 Kolejność testowania Namiastki poziomu 2 Namiastki poziomu 3...

31 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 31 Zstępujące testowanie integracyjne Poziom N-1 Poziom N Sterowniki testowania Sterowniki testowania Kolejność testowania

32 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 32 Testowanie interfejsu l Testowanie interfejsu jest wykonywane po zintegrowaniu modułów lub podsystemów w większe systemy. l Każdy moduł i podsystem ma zdefiniowany interfejs, który jest wywoływany przez inne komponenty programu. l Celem testowania interfejsu jest wykrycie usterek, które pojawiły się w systemie z powodu błędów w interfejsach lub nieprawdziwych założeniach o interfejsach.

33 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 33 Testowanie interfejsu Przypadki testowe Przypadki testowe A A C C B B

34 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 34 Rodzaje interfejsów l Interfejsy parametryczne. Są to interfejsy, w których dane lub niekiedy odwołania do funkcji są przekazywane od jednego komponentu do drugiego. l Interfejs w pamięci dzielonej. Są to interfejsy, w których blok pamięci jest dzielony między podsystemami. Dane są umieszczane w tym bloku przez jeden podsystem i pobierane stamtąd przez inny. l Interfejsy proceduralne. Są to interfejsy, w których jeden podsystem obudowuje zbiór procedur wywoływanych przez inne podsystemy. Interfejsy tego rodzaju mają obiekty i abstrakcyjne typy danych. l Interfejsy z przekazywaniem komunikatów. Są to interfejsy, w których jeden podsystem żąda usługi innego przez przesłanie mu komunikatu. Komunikat zwrotny zawiera wyniki wykonania usługi. Niektóre systemy obiektowe i systemy klient-serwer mają interfejsy tego rodzaju.

35 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 35 Testowanie obciążeniowe l Po całkowitej integracji systemu można badać pojawiające się właściwości systemu, takie jak efektywność i niezawodność. l Testy efektywności projektuje się tak, aby upewnić się, że system może działać przy założonym obciążeniu. l Zwykle polega to na zaplanowaniu szeregu testów, w których stopniowo zwiększa się obciążenie do chwili osiągnięcia akceptowalnej efektywności systemu.

36 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 36 Testowanie obiektowe l Obiekty jako oddzielne komponenty są zwykle większe niż poszczególne funkcje. l Obiekty integrowane w podsystemy są zwykle luźno powiązane i nie ma jasnego ‘wierzchołka’ systemu. l Jeśli obiekty użyto wielokrotnie, to osoby testujące mogą nie mieć dostępu do kodu źródłowego komponentu, a zatem nie mogą przeprowadzić jego analizy.

37 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 37 Poziomy testowania l Testowanie poszczególnych opcji związanych z obiektami Są to funkcje i procedury. Można wykorzystać podejścia zarówno czarnej, jak i białej skrzynki. l Testowanie poszczególnych klas obiektów Zasada testowania czarnej skrzynki pozostaje w mocy, ale pojęcie klas równoważności należy rozszerzyć tak, aby obejmowało ciągi powiązanych operacji. l Testowanie gron obiektów Ściśle zstępująca ani wstępująca integracja nie jest właściwa w wypadku grup powiązanych obiektów. Należy wykorzystać inne podejścia, takie jak testowanie scenariuszy. l Testowanie systemu obiektowego Przeprowadza się weryfikację i zatwierdzanie względem specyfikacji wymagań systemu w dokładnie ten sam sposób, jak w wypadku innych rodzajów systemów.

38 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 38 l Podejście do pokrywania testami polega na upewnieniu się, że wszystkie instrukcje i wszystkie ścieżki programu wykonano co najmniej jeden raz. l Przy testowaniu obiektów pełne pokrycie testami powinno obejmować: oddzielne testowanie wszystkich operacji związanych z obiektem ustalenie i odczytywanie wszystkich atrybutów związanych z obiektem badanie obiektu we wszystkich możliwych stanach, co oznacza, że należy zasymulować wszystkie zdarzenia powodujące zmianę stanu obiektu. Testowanie klas obiektów

39 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 39 Przykład stacji meteorologicznej l Zawiera on tylko jeden atrybut, który jest identyfikatorem stacji. Jest to stała ustalana w czasie instalowania stacji. l Trzeba więc jedynie sprawdzić, czy go nadano. Należy opracować przypadki testowe dla metod raportPogodowy, dostrój, testuj, uruchom i wyłącz. l Najlepiej testować te metody w izolacji, ale w niektórych wypadkach konieczne są pewne ciągi testów. Sprawdzanie metody wewnątrz wymaga na przykład wcześniejszego wykonania metody uruchom.

40 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 40 Interfejs stacji meteorologicznej StacjaMeteorologiczna identyfikator raportPogodowy () dostrój (przyrządy) testuj() uruchom (przyrządy) wyłącz (przyrządy) StacjaMeteorologiczna identyfikator raportPogodowy () dostrój (przyrządy) testuj() uruchom (przyrządy) wyłącz (przyrządy)

41 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 41 Integracja obiektów l Przy budowaniu systemów obiektowych poziomy integracji są słabej wyodrębnione. Oczywiście operacje i dane są integrowane w postaci obiektów i klas obiektów. l Testowanie tych klas obiektów odpowiada testowaniu jednostek. W systemach obiektowych nie ma bezpośredniego odpowiednika testowania modułów. l Murphy i inni (1994) sugerują jednak, że grupy klas, które łącznie oferują pewien zbiór usług, powinny być testowane razem. Nazwali to testowaniem gron.

42 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 42 Podejścia do testowania integracyjnego l Testowanie przypadków użycia lub scenariuszy. Przypadki użycia lub scenariusze są opisami jednego trybu użycia systemu. Podstawą testowania mogą być te opisy scenariuszy i grona obiektów utworzone w celu realizacji przypadków użycia związanych z tym trybem użycia. l Testowanie wątków. Polega na testowaniu reakcji systemu na konkretne zdarzenie wejściowe lub zbiór zdarzeń wejściowych. Systemy obiektowe często są sterowane zdarzeniami, a zatem jest to szczególnie dobry sposób testowania. l Testowanie interakcji obiektów. Podejście do testowania grup oddziałujących na siebie obiektów zaproponowali Jorgensen i Ericson(1994).

43 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 43 Testowanie scenariuszy l Często jest najskuteczniejszą z tych metod, ponieważ można je przeprowadzić tak, aby zacząć od najczęściej realizowanych scenariuszy, a niecodzienne i wyjątkowe scenariusze wziąć pod uwagę w późniejszej fazie procesu testowania. To czyni zadość podstawowej zasadzie testowania, która nakazuje poświęcenie największego wysiłku najczęściej używanym częściom systemu.

44 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 44 Diagram przebiegu gromadzenia danych meteorologicznych : Sterownik Komunikacji : Sterownik Komunikacji : Stacja Meteorologiczna : Stacja Meteorologiczna : Dane Meteorologiczne : Dane Meteorologiczne żądanie (raport) potwierdzenie () odpowiedź (raport) potwierdzenie () wyślij (raport) raportuj () podsumuj ()

45 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 45 Warsztaty do testowania l Testowanie to kosztowna i pracochłonna do testowania tworzenia oprogramowania. Narzędzia do testowania były więc pierwszymi narzędziami programowymi, które należało opracować. Te narzędzia zawierzają obecnie wiele udogodnień. Ich użycie znacząco obniża koszt procesu testowania. Różne narzędzia do testowania można zintegrować w ramach warsztatów do testowania.

46 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 46 Narzędzia warsztatów do testowania l Menedżer testów. l Generator danych testowych. l Wyrocznia. l Narzędzia do porównywania plików. l Generator raportów. l Analizator dynamiczny. l Symulator.

47 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 47 Warsztaty do testowania Kod źródłowy Kod źródłowy Raport z wykonania Raport z wykonania Testowany program Testowany program Dane testowe Dane testowe Spodziewane wyniki Spodziewane wyniki Wyniki testów Wyniki testów Raport z wynikami testów Raport z wynikami testów Specyfikacja Generator danych testowych Generator danych testowych Symulator Menedżer testów Menedżer testów Wyrocznia Narzędzia do porównywania plików Narzędzia do porównywania plików Generator raportów Generator raportów Analizator dynamiczny Analizator dynamiczny

48 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 48 Główne tezy l Przetestowanie często używanych części systemu jest ważniejsze niż testowanie tych części, które są rzadko stosowane. l Dzielenie na klasy równoważności jest sposobem opracowywania przypadków testowych. Polega na znajdowaniu podziału zestawów danych wejściowych i danych wyjściowych i zadawaniu programowi wartości z fragmentów tego podziału. Często wartością, która z największym prawdopodobieństwem da pozytywny wynik testu, jest wartość graniczna fragmentu podziału. l Testowanie czarnej skrzynki nie wymaga dostępu do kodu źródłowego. Przypadki testowe opracowuje się na podstawie specyfikacji programu. l Testowanie strukturalne polega na analizowaniu programu w celu odnalezienia jego ścieżek i wykorzystaniu wyników tej analizy przy wyborze wypadków przypadków testowych.

49 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 20 Slide 49 Główne tezy l Testowanie integracyjne powinno być poświęcone testowaniu interakcji między komponentami systemu i interfejsami komponentów. l Defekty interfejsów mogą powstawać w wyniku błędów przy odczytywaniu specyfikacji, w wyniku niewłaściwego zrozumienia specyfikacji lub nieprawdziwych założeń o synchronizacji. Celem testowania interfejsów jest wykrycie defektów w interfejsach obiektów lub modułów. l Testując klasy obiektów, należy opracować testy, które obejmują wykonanie wszystkich metod klasy, przypisanie i odczyt wartości wszystkich atrybutów i umożliwiają sprawdzenie obiektowe we wszystkich możliwych stanach. l Systemy obiektowe należy integrować wokół naturalnych gron obiektów, takich jak te związane z konkretnym przypadkiem użycia, zbiorem przypadków użycia lub wątkami obiektów.