Modelowanie testów. czyli po co testerowi znajomość UML

Transkrypt

1 Modelowanie testów czyli po co testerowi znajomość UML Paweł Dudzik październik 2015

2 Naturalny opis świata Powstaje pytanie, jak opisać ten świat, aby opis był jak najbardziej zbliżony do rzeczywistości, a jednocześnie dla wszystkich zrozumiały. Zadanie jest trudne, gdyż trzeba pogodzić ścisłą precyzję modelu oprogramowania z terminologią i nawykami odbiorców (w tym użytkowników) systemu. 2 WarszawQA

3 Opisywanie rzeczywistości 3 WarszawQA

4 Dwa spojrzenia na system Każdy system możemy postrzegać z dwóch perspektyw: zewnętrznej, kiedy widzimy, jakie funkcje system udostępnia obiektom zewnętrznym, wewnętrznej, kiedy widzimy, jak te funkcje są realizowane. 4 WarszawQA

5 Model systemu Model jest takim opisem fragmentu rzeczywistości, który uwypukla cechy istotne z punktu widzenia twórców modelu, zaś ukrywa cechy nieistotne. Definicja pojęcia «system» jest to pewna dziedzina złożona z części, które tworzą całość zgodnie z pewnym planem lub celem. Podejmując się budowy systemu informatycznego, najpierw należy dokładnie zdefiniować jego zadania. Aby to wykonać trzeba dokładnie poznać zasady rządzące funkcjonowaniem tego systemu (wypracowane przez firmę/organizację zamawiającą system). 5 WarszawQA

6 Model systemu Aby ułatwić rozumienie działania systemu, buduje się model, który pozwala skupić się na jego najistotniejszych elementach. Model jest abstrakcyjną reprezentacją wybranego fragmentu rzeczywistości. Model systemu pozwala na weryfikację poprawności rozumienia zasad funkcjonowania organizacji, stanowi płaszczyznę do dyskusji analityków i projektantów z ekspertami i przyszłymi użytkownikami systemu. Do stworzenia modelu należy użyć pewnej notacji. Notacja jest to ustalony sposób prezentacji pojęć, pozwalający na zrozumienie modelu (lub ogólnie przekazu). To samo można wyrazić za pomocą różnych notacji, jednak przystępując do budowy modelu, a potem do jego interpretacji należy wiedzieć, z jakiej notacji korzystamy. 6 WarszawQA

7 Składowe języka modelowania składnia określa, jakie oznaczenia wolno stosować i w jaki sposób je ze sobą łączyć semantyka określa, co należy rozumieć pod przyjętymi oznaczeniami pragmatyka określa, w jaki sposób i w jakich sytuacjach należy używać przyjętych oznaczeń 7 WarszawQA

8 Zależności między modelami Przedstawienie samej notacji modelu nie wystarcza. Potrzebne jest stworzenie metodyki opisującej sposoby tworzenia modeli i zasady przechodzenia między modelami oraz przedstawienie całego procesu wytwórczego. Rejestracja DaneWłaściciela Wydruk listy pojazdów OknoRejestracji DanePojazdu void Rejestracja::Rejestruj() { okno.wprowadzdane(); danew.podajdane(); //... } Rejestrator Rejestracja pojazdu : OknoRejestracji : Rejestracja : DaneWłaściciela : DanePojazdu : Rejestrator Wymaganie 1 Wymaganie 2 Wymaganie WarszawQA

9 Testowanie oparte na modelach wymagania specyfikacja wspólny model kryteria wyboru testu scenariusze i przypadki testowe oczekiwane wyniki wykonanie testów kod rzeczywiste wyniki porównanie 9 WarszawQA

10 Testowanie oparte na modelach wymagania specyfikacja kryteria wyboru testu scenariusze i przypadki testowe oczekiwane wyniki wykonanie testów kod rzeczywiste wyniki porównanie 10 WarszawQA

11 Testowanie oparte na modelach wymagania specyfikacja kryteria wyboru testu scenariusze i przypadki testowe oczekiwane wyniki wykonanie testów kod rzeczywiste wyniki porównanie 11 WarszawQA

12 Modelowanie scenariuszy testowych Wprowadzenie modelowania pozwala na: niezależną weryfikację modeli i dokumentacji projektowej, możliwość elastycznego planowania zakresu wykonywanych testów (liczby przypadków testowych), zastosowanie generatora przypadków testowych, przyjęcie jednolitej strategii określania przypadków testowych dla scenariuszy (tzw. racjonalnego pokrycia) pozwalającego na systematyczne pokrycie testami ścieżek, racjonalizację przygotowywania i wykonywania testów (na poziomie jednego scenariusza): sprawdzenie wyjątkowo czułych lub wrażliwych elementów scenariusza, ustalenie kolejności przypadków testowych tak, aby wykryć podstawowe błędy, zanim zacznie się wykonywanie zasadniczej części przypadków testowych (szczególnie ważne w testach automatycznych), poddanie nowych elementów scenariusza ujednoliconej procedurze wytwarzania i sprawdzania poprawności definicji. 12 WarszawQA

13 Modelowanie scenariuszy testowych Przy modelowaniu scenariuszy testowych należy wziąć pod uwagę następujące czynniki: źródło modelu w szczególności, czy jest on współdzielony z innymi zespołami projektowymi, czy też wykonywany wyłącznie na potrzeby testów, sposoby modelowania, w tym: użytą notację najlepiej opartą na powszechnie znanym standardzie (np. UML, BPMN), re używalność i wersjonowanie elementów modelu, możliwość skojarzenia (określenia powiązań) elementów modelu ze sobą i innymi artefaktami projektowymi szczególnie z wymaganiami, możliwość elastycznego dodawania do elementów modelu komentarzy, opisów, plików graficznych, np.: w celu dołączenia do generowanego raportu i do dokumentacji, możliwość wsparcia narzędziowego wybranego sposobu modelowania scenariuszy testowych. 13 WarszawQA

14 Planowanie testów Analiza dokumentacji projektowej pod kątem możliwości jej wykorzystania przy tworzeniu scenariuszy testowych i oszacowanie stopnia złożoności testów. Określenie warunków niezbędnych do realizacji testów oraz ryzyka związanego z przygotowaniem i przeprowadzaniem testów. Inwentaryzacja elementów interfejsów przewidzianych do użycia w trakcie testów i wybór narzędzi do automatyzacji testów. Określenie rekomendacji co do sposobu realizacji testów: możliwości pokrycia testami automatycznymi elementów interfejsu lub realizacja jako testów ręcznych, możliwości pokrycia testami funkcjonalności systemu, przy założeniu wykorzystywania poszczególnych rodzajów narzędzi testowych lub testów ręcznych, oszacowanie kosztów przygotowania rodzajów testów dla poszczególnych typów narzędzi testowych lub testów ręcznych. 14 WarszawQA

15 Rekomendacje sposobu realizacji testów Rekomendacje służą do opracowania: zakresu testów i sposobu ich realizacji, listy scenariuszy testowych wraz z opisem ich zakresu oraz sposobem wykonania, koncepcji przygotowania i przeprowadzenia testów, listy elementów interfejsu podlegających testowaniu automatycznemu, sposobu przygotowania środowiska testowego, zasad przygotowywania (w tym generowania) danych testowych, planu i harmonogramu przygotowywania i przeprowadzania testów, rejestru ryzyka związanego z przygotowywaniem i przeprowadzaniem testów. 15 WarszawQA

16 Przykład Analiza (złego) diagramu Use Case na potrzeby testów 16

17 17

18 18 kandydaci na kroki przypadku testowego

19 19 A jeśli niepoprawne logowanie?

20 20 A jeśli jest niepoprawny PESEL?

21 21 Jakie są warunki walidacji danych?

22 22 A jeśli dane na wydruku są niepoprawne?

23 23 Czy mamy określone wszystkie ścieżki (możliwości) przetwarzania?

24 Analiza danych Use Case Dane testowe jako podmioty procesu biznesowego: jak są opisywane w dokumentacji, czy opis jest zgodny z naszą wiedzą o rzeczywistości, czy odnosimy się do zewnętrznych standardów, czy przewidywany w dokumentacji zakres danych pozwala na opisanie wszystkich możliwych przypadków. Analogicznie postępujemy dla: opisów wykonywanych operacji jaki zakres danych niezbędny jest do ich wykonania, warunków niezbędnych do przejścia do kolejnego kroku procesu (niezbędny opis tekstowy). Dodatkowe pytania: czy nie potrzebujemy dodatkowych danych, szczególnie do przejścia do następnego kroku procesu, czy wielokrotnie używane elementy procesów mają na pewno ten sam zakres danych, w jaki sposób będziemy weryfikować poprawne wprowadzenie danych. 24

25 Przykład Analiza danych na potrzeby testów 25

26 26

27 27 dane niezbędne do zalogowania

28 28 co jeśli klient nie ma PESEL? jaka jest pełna lista produktów bankowych?

29 29 pełen zakres danych do wniosku: co będzie jeśli ktoś mieszka w Portugalii?

30 30 Jakie to są oferty pełna lista

31 31 Jak poznajemy, że jest pozytywna decyzja? Co się stanie, jeżeli jest negatywna?

32 32 zakres danych dodatkowych

33 33 Jakie mogą być limity?

34 34 Jak sprawdzimy, czy dane na wydruku zgadzają się z danymi wprowadzonymi?

35 Podsumowanie Opisy procesów i przypadków testowych są odpowiednie dla testów ręcznych, lecz nie zawierają zwykle: specyfikacji zakresu dopuszczalnych danych, listy atrybutów w opisie posługujemy się zwykle nazwami agregatów danych, zakresów dopuszczalnych danych, informacji o niepoprawnych danych, danych oczekiwanych, sposobu weryfikacji poprawności danych rzeczywistych poprzez zestawienie ich z wartościami oczekiwanymi. 35

36 Analiza przypadków testowych Dla każdego kroku sprawdzamy: zakres danych wprowadzanych, informacje niezbędne do przeprowadzenia danego kroku, elementy interfejsu występujące w opisie, sposób weryfikacji poprawności wprowadzanych danych, determinizm opisywanego procesu. 36

37 Model stanów systemu Modelując system przy pomocy diagramów stanów, można przyjąć następujące założenia: modelujemy tylko te stany systemu, które są istotne z punktu widzenia przeprowadzanych testów, stany diagramu odpowiadają stanom systemu (niekoniecznie pożądanym), przejścia są przypisane do akcji systemu z odpowiednimi danymi wejściowymi, stan systemu najlepiej jest kontrolować poprzez badanie danych wyjściowych. 37

38 Przykład Tworzenie scenariusza testowego na podstawie diagramu Use Case 38

39 39 Tworzenie scenariusza testowego

40 Tworzenie scenariusza testowego start S 40

41 Tworzenie scenariusza testowego S niepoprawny login 41

42 Tworzenie scenariusza testowego S rozdzielnie operacji wprowadzenia numeru PESEL i wybrania produktu 42

43 Tworzenie scenariusza testowego S wprowadzenie niepoprawnych danych 43

44 Tworzenie scenariusza testowego S negatywna decyzja kredytowa 44

45 Tworzenie scenariusza testowego S wprowadzenie niepoprawnych danych 45

46 Tworzenie scenariusza testowego S brak możliwości wydruku 46

47 Tworzenie scenariusza testowego S poprawianie danych na wydruku 47

48 Szacowanie złożoności testów Przy szacowaniu złożoności testów należy wziąć pod uwagę: złożoność diagramu stanu (liczba stanów, przejść oraz danych sterujących tymi przejściami), wielkość dziedzin poszczególnych danych wejściowych. Ponieważ przetestowanie wszystkich możliwych przejść jest zwykle nierealne, należy określić: organicznie co do liczby przejść w diagramie stanu, rozsądny poziom gęstości testów danych wejściowych, strategię wyboru przypadków testowych. 48

49 Scenariusze testowe Scenariusze testowe tworzymy na podstawie diagramu stanów: stanom przypisujemy kroki testowe, scenariusz definiujemy jako sekwencję przejść ze stanu do stanu (poczynając od stanu początkowego), określamy dane niezbędne do wykonania każdego z kroków testowych. Ponieważ mamy określony diagram stanów, można stosunkowo łatwo zbudować generator scenariuszy testowych. 49

50 Przykład Analiza scenariuszy użycia na potrzeby testów 50

51 Typowy opis scenariusza działania Uruchamiamy środowisko testowe w przeglądarce internetowej Wybieramy jednostkę 995 i profil Doradca Dyspozycje Wybieramy zakładkę szukaj klienta i wyszukujemy klienta indywidualnego dla którego będzie realizowana dyspozycja środowisko poprawnie zostaje uruchomione, dostępne są jednostki i profile Na ekranie będzie prezentowana lista zadań Klient zostaje wyszukany w systemie i pojawia się w kontekście klienta Platin 4 Wybieramy link Dyspozycja Otwiera się okno BPM katalog procesów 5 Z kategorii dyspozycji wybrać należy Kredytowa Uaktywnia się pole typ dyspozycji 6 7 W polu Typ dyspozycji wybieramy wartość Dostarczenie Polisy i wybieramy przycisk Start procesu Wybieramy priorytet sprawy, typ odpowiedzi, TAK jako odpowiedź na pytanie: Czy podpis jest zgodny z Kartą Wzorów Podpisów i przechodzimy do zakładki Checklista dokumentów Pojawia się okno BPM z danymi podstawowymi Pojawia się na liście dokument 8 Zaczynamy skan dokumentu Skan dyspozycji 9 Wybieramy przycisk Przekaż do BOD Status dokumentu zmieny na Dołączono 51

52 52 Scenariusz testowy diagram początkowy

53 Jednoznaczność opisu kroków id PT krok nazwa K01 PT01 10 K01 PT02 10 K01 PT03 15 K01 PT17 10 Dokonujemy zmiany jednostki na ZR25 i profilu na DP - WKGOI, wyszukujemy sprawę i klikamy przycisk Pobierz Dokonujemy zmiany jednostki na ZR25 i profilu na DP - WKGO, wyszukujemy sprawę klikamy przycisk Pobierz Dokonujemy zmiany jednostki na ZR25 i profilu na DP - WKGOI, wyszukujemy sprawe i klikamy przycisk Pobierz Dokonujemy zmiany jednostki na ZR25 i profilu na DP - WKGO, wyszukujemy sprawę i klikamy przycisk Pobierz K02 PT01 09 Wybieramy przycisk Przekaż do B0D K02 PT02 09 Wybieramy przycisk Przekaż do BOD K02 PT03 09 Wybieramy przycisk Wylij do BOD K02 PT15 10 Wybieramy przycisk Przekaż do BOD K02 PT16 09 Wybieramy przycisk Wyslij do BOD K02 PT17 09 Wybieramy przycisk Przeka do BOD K02 PT18 10 Wybieramy przycisk Przekaż do BOD K03 PT15 07 Wybieramy rachunek w polu rachunek kredytowy i wybieramy przycisk Start Procesu K03 PT18 07 Wybieramy rachunek w polu rachunek kredytowy i wybieramy przycisk Start procesu K04 PT01 03 K04 PT06 03 K04 PT07 03 Wybieramy zakadkę Szukaj klienta i wyszukujemy klienta indywidualnego dla którego bedzie realizowana dyspozycja Wybieramy zakładkę szukaj klienta i wyszukujemy klienta indywidualnego dla którego będzie realizowana dyspozycja Wybieramy zakładkę Szukajklienta i wyszukujemy klienta indywidualnego dla którego będzie realizowana dyspozycja 53

54 54 Scenariusz testowy diagram

55 Definicja przypadków testowych PT liczba kroków krok PT01 17 K16 K18 K04 K22 K07 K24 K23 K08 K02 K01 K12 K19 K14 K10 K11 K20 K15 PT02 17 K16 K18 K04 K22 K07 K25 K23 K08 K02 K01 K12 K19 K14 K10 K11 K20 K15 PT03 18 K16 K18 K04 K22 K07 K26 K23 K08 K02 K01 K13 K12 K19 K14 K01 K11 K20 K15 PT04 18 K16 K18 K04 K22 K07 K27 K23 K08 K02 K01 K13 K12 K19 K14 K10 K11 K20 K15 PT05 18 K16 K18 K04 K22 K07 K17 K23 K08 K02 K01 K13 K12 K19 K14 K10 K11 K20 K15 PT06 18 K16 K18 K04 K22 K07 K28 K23 K08 K02 K01 K13 K12 K19 K14 K10 K11 K20 K15 PT07 17 K16 K18 K04 K22 K06 K29 K23 K08 K02 K09 K12 K19 K14 K10 K11 K20 K15 PT08 18 K16 K18 K04 K22 K06 K30 K23 K08 K02 K09 K40 K12 K19 K14 K10 K11 K20 K15 PT09 17 K16 K18 K04 K22 K07 K31 K23 K08 K02 K01 K12 K19 K14 K10 K11 K20 K15 PT10 17 K16 K18 K04 K22 K06 K32 K23 K08 K02 K09 K12 K19 K14 K10 K11 K20 K15 PT11 17 K16 K18 K04 K22 K07 K33 K23 K08 K02 K01 K12 K19 K14 K10 K11 K20 K15 PT12 17 K16 K18 K04 K22 K07 K34 K23 K08 K02 K01 K12 K19 K14 K10 K11 K20 K15 PT13 18 K16 K18 K04 K22 K07 K17 K23 K08 K02 K01 K13 K12 K19 K14 K10 K11 K20 K15 PT14 18 K16 K18 K04 K22 K07 K35 K23 K08 K02 K01 K13 K12 K19 K14 K10 K11 K20 K15 PT15 18 K16 K21 K05 K22 K07 K36 K03 K23 K08 K02 K09 K12 K21 K14 K10 K11 K21 K15 PT16 18 K16 K18 K04 K22 K07 K37 K23 K08 K02 K01 K13 K12 K19 K14 K10 K11 K20 K15 PT17 18 K16 K18 K04 K22 K07 K38 K23 K08 K02 K01 K13 K12 K19 K14 K10 K11 K20 K15 PT18 18 K16 K21 K05 K22 K07 K39 K03 K23 K08 K02 K09 K12 K21 K14 K10 K11 K21 K15 55

56 Zaawansowanie prac 56 id liczba kroków realizacja PT ,53% K16 K18 K04 K22 K07 K24 K23 K08 K02 K01 K12 K19 K14 K10 K11 K20 K15 PT ,53% K16 K18 K04 K22 K07 K25 K23 K08 K02 K01 K12 K19 K14 K10 K11 K20 K15 PT ,22% K16 K18 K04 K22 K07 K26 K23 K08 K02 K01 K13 K12 K19 K14 K01 K11 K20 K15 PT ,22% K16 K18 K04 K22 K07 K27 K23 K08 K02 K01 K13 K12 K19 K14 K10 K11 K20 K15 PT ,22% K16 K18 K04 K22 K07 K17 K23 K08 K02 K01 K13 K12 K19 K14 K10 K11 K20 K15 PT ,22% K16 K18 K04 K22 K07 K28 K23 K08 K02 K01 K13 K12 K19 K14 K10 K11 K20 K15 PT ,41% K16 K18 K04 K22 K06 K29 K23 K08 K02 K09 K12 K19 K14 K10 K11 K20 K15 PT ,33% K16 K18 K04 K22 K06 K30 K23 K08 K02 K09 K40 K12 K19 K14 K10 K11 K20 K15 PT ,53% K16 K18 K04 K22 K07 K31 K23 K08 K02 K01 K12 K19 K14 K10 K11 K20 K15 PT ,41% K16 K18 K04 K22 K06 K32 K23 K08 K02 K09 K12 K19 K14 K10 K11 K20 K15 PT ,53% K16 K18 K04 K22 K07 K33 K23 K08 K02 K01 K12 K19 K14 K10 K11 K20 K15 PT ,53% K16 K18 K04 K22 K07 K34 K23 K08 K02 K01 K12 K19 K14 K10 K11 K20 K15 PT ,22% K16 K18 K04 K22 K07 K17 K23 K08 K02 K01 K13 K12 K19 K14 K10 K11 K20 K15 PT ,22% K16 K18 K04 K22 K07 K35 K23 K08 K02 K01 K13 K12 K19 K14 K10 K11 K20 K15 PT ,67% K16 K21 K05 K22 K07 K36 K03 K23 K08 K02 K09 K12 K21 K14 K10 K11 K21 K15 PT ,22% K16 K18 K04 K22 K07 K37 K23 K08 K02 K01 K13 K12 K19 K14 K10 K11 K20 K15 PT ,22% K16 K18 K04 K22 K07 K38 K23 K08 K02 K01 K13 K12 K19 K14 K10 K11 K20 K15 PT ,67% K16 K21 K05 K22 K07 K39 K03 K23 K08 K02 K09 K12 K21 K14 K10 K11 K21 K15 krok

57 Dziękuję za uwagę Infovide-Matrix S.A. ul. Gottlieba Daimlera Warszawa pdudzik@ivmx.pl WarszawQA