Modelowanie testów czyli po co testerowi znajomość UML Paweł Dudzik październik 2015
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 27.10.2015
Opisywanie rzeczywistości 3 WarszawQA 27.10.2015
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 27.10.2015
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 27.10.2015
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 27.10.2015
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 27.10.2015
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 3... 8 WarszawQA 27.10.2015
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 27.10.2015
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 27.10.2015
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 27.10.2015
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 27.10.2015
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 27.10.2015
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 27.10.2015
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 27.10.2015
Przykład Analiza (złego) diagramu Use Case na potrzeby testów 16
17
18 kandydaci na kroki przypadku testowego
19 A jeśli niepoprawne logowanie?
20 A jeśli jest niepoprawny PESEL?
21 Jakie są warunki walidacji danych?
22 A jeśli dane na wydruku są niepoprawne?
23 Czy mamy określone wszystkie ścieżki (możliwości) przetwarzania?
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
Przykład Analiza danych na potrzeby testów 25
26
27 dane niezbędne do zalogowania
28 co jeśli klient nie ma PESEL? jaka jest pełna lista produktów bankowych?
29 pełen zakres danych do wniosku: co będzie jeśli ktoś mieszka w Portugalii?
30 Jakie to są oferty pełna lista
31 Jak poznajemy, że jest pozytywna decyzja? Co się stanie, jeżeli jest negatywna?
32 zakres danych dodatkowych
33 Jakie mogą być limity?
34 Jak sprawdzimy, czy dane na wydruku zgadzają się z danymi wprowadzonymi?
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
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
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
Przykład Tworzenie scenariusza testowego na podstawie diagramu Use Case 38
39 Tworzenie scenariusza testowego
Tworzenie scenariusza testowego start S 40
Tworzenie scenariusza testowego S niepoprawny login 41
Tworzenie scenariusza testowego S rozdzielnie operacji wprowadzenia numeru PESEL i wybrania produktu 42
Tworzenie scenariusza testowego S wprowadzenie niepoprawnych danych 43
Tworzenie scenariusza testowego S negatywna decyzja kredytowa 44
Tworzenie scenariusza testowego S wprowadzenie niepoprawnych danych 45
Tworzenie scenariusza testowego S brak możliwości wydruku 46
Tworzenie scenariusza testowego S poprawianie danych na wydruku 47
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
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
Przykład Analiza scenariuszy użycia na potrzeby testów 50
Typowy opis scenariusza działania 1 2 3 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 Scenariusz testowy diagram początkowy
Jednoznaczność opisu kroków id PT krok nazwa 317 317 317 317 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 Scenariusz testowy diagram
Definicja przypadków testowych PT liczba kroków krok 18 317 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 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
Zaawansowanie prac 56 id liczba kroków realizacja 18 317 0 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 PT01 17 23,53% K16 K18 K04 K22 K07 K24 K23 K08 K02 K01 K12 K19 K14 K10 K11 K20 K15 PT02 17 23,53% K16 K18 K04 K22 K07 K25 K23 K08 K02 K01 K12 K19 K14 K10 K11 K20 K15 PT03 18 22,22% K16 K18 K04 K22 K07 K26 K23 K08 K02 K01 K13 K12 K19 K14 K01 K11 K20 K15 PT04 18 22,22% K16 K18 K04 K22 K07 K27 K23 K08 K02 K01 K13 K12 K19 K14 K10 K11 K20 K15 PT05 18 22,22% K16 K18 K04 K22 K07 K17 K23 K08 K02 K01 K13 K12 K19 K14 K10 K11 K20 K15 PT06 18 22,22% K16 K18 K04 K22 K07 K28 K23 K08 K02 K01 K13 K12 K19 K14 K10 K11 K20 K15 PT07 17 29,41% K16 K18 K04 K22 K06 K29 K23 K08 K02 K09 K12 K19 K14 K10 K11 K20 K15 PT08 18 33,33% K16 K18 K04 K22 K06 K30 K23 K08 K02 K09 K40 K12 K19 K14 K10 K11 K20 K15 PT09 17 23,53% K16 K18 K04 K22 K07 K31 K23 K08 K02 K01 K12 K19 K14 K10 K11 K20 K15 PT10 17 29,41% K16 K18 K04 K22 K06 K32 K23 K08 K02 K09 K12 K19 K14 K10 K11 K20 K15 PT11 17 23,53% K16 K18 K04 K22 K07 K33 K23 K08 K02 K01 K12 K19 K14 K10 K11 K20 K15 PT12 17 23,53% K16 K18 K04 K22 K07 K34 K23 K08 K02 K01 K12 K19 K14 K10 K11 K20 K15 PT13 18 22,22% K16 K18 K04 K22 K07 K17 K23 K08 K02 K01 K13 K12 K19 K14 K10 K11 K20 K15 PT14 18 22,22% K16 K18 K04 K22 K07 K35 K23 K08 K02 K01 K13 K12 K19 K14 K10 K11 K20 K15 PT15 18 16,67% K16 K21 K05 K22 K07 K36 K03 K23 K08 K02 K09 K12 K21 K14 K10 K11 K21 K15 PT16 18 22,22% K16 K18 K04 K22 K07 K37 K23 K08 K02 K01 K13 K12 K19 K14 K10 K11 K20 K15 PT17 18 22,22% K16 K18 K04 K22 K07 K38 K23 K08 K02 K01 K13 K12 K19 K14 K10 K11 K20 K15 PT18 18 16,67% K16 K21 K05 K22 K07 K39 K03 K23 K08 K02 K09 K12 K21 K14 K10 K11 K21 K15 krok
Dziękuję za uwagę Infovide-Matrix S.A. ul. Gottlieba Daimlera 2 02-460 Warszawa pdudzik@ivmx.pl WarszawQA 27.10.2015