Tworzenie przypadków testowych

Transkrypt

1 Tworzenie przypadków testowych Prowadząca: Katarzyna Pietrzyk Agenda 1. Wprowadzenie 2. Wymagania 3. Przypadek testowy Definicja Schemat Cechy dobrego przypadku testowego 4. Techniki projektowania Czarnej skrzynki Białej skrzynki Oparte na doświadczeniu 5. Test scenariusze 6. Metryki

2 To juŝ było Testowanie Poziomy testów Rodzaje testów Wymagania Definiowane przez uŝytkowników Przetwarzane przez analityka Analizowane/Weryfikowane przez testera Implementowane przez developera Testowane przez testera

3 Testowalność [1/2] The degree to which a system or component facilitates the establishment of test criteria and the performance of tests to determine whether those criteria have been met. [IEEE] Testowalność [2/2] Przegląd (ang.review) wymagań jest najbardziej efektywną drogą walidacji wymagań. Defekty, które nie będą znalezione podczas przeglądu wymagań będą wnoszone do kolejnych faz produkcji oprogramowania. Naprawienie defektów staje się coraz droŝsze. Cechy dobrze zdefiniowanych wymagań: jednoznaczność kompletność spójność modyfikowalność śledzalność uŝyteczność (wtórna) weryfikowalność

4 Przypadek testowy [1/2] (ang. Test case) Zbiór wejść, warunków początkowych oraz oczekiwanych wyników i warunków końcowych utworzony, aby wykonać określonąścieŝkę w programie albo aby zweryfikować zgodność z określonym wymaganiem. [IEEE 610] 1. Unikalny identyfikator, nazwa Przypadek testowy [2/2] 2. Opis, co sprawdza dany przypadek testowy (ang. Test case) 3. Warunki, jakie muszą zostać spełnione zanim przystąpimy do wykonywania przypadku testowego Id Opis Wykonywanej czynności Id: Nazwa Oczekiwane rezultaty Aktualny rezultat Status 4. Pojedyncza czynność, którą naleŝy wykonać 1 5. Spodziewane rezultaty wykonania czynności 2 6. Wynik poprawnego wykonania przypadku testowego

5 Cechy dobrego przypadku testowego Znajduje defekty (maksymalną ilość) Weryfikuje poprawność (działania) systemu/zgodność z wymaganiami Określa stabilność/wiarygodność systemu Minimalizuje koszty wsparcia (ang.support) i utrzymania (ang.maintenance) Szacuje/zapewnia jakość systemu Dopasowany do tego, co chcemy sprawdzić Techniki projektowania 1. Techniki czarnej szkrzynki (ang.black-box) 2. Techniki białej skrzynki (ang.white-box) 3. Techniki oparte na doświadczeniu (ang.experience based)

6 Techniki czarnej skrzynki (ang.black-box) Zakładana jest znajomość wymagań dla testowanej funkcjonalności. Wprowadzamy dane wejściowe i analizujemy wyniki otrzymywane na wyjściu. System jest traktowany jak czarna skrzynka, która działa w nieznany sposób. Dane wejściowe Czarna skrzynka Dane wyjściowe Klas równowaŝności (equivalence partitioning) Wartości granicznych (boundary value analysis) Technika oparta o przejścia stanów (state transition testing) Technika oparta o tabele decyzyjne (decision table testing) Technika oparta o przypadki uŝycia (use case testing) Technika klas równowaŝności Wszystkie moŝliwe wartości dzielone są na klasy (równowaŝności), takie Ŝe: Istnieje skończona ilość tych klas System zachowuje się analogicznie dla wartości z tej samej klasy Test dla jednego z kaŝdej klasy jest wystarczający Jeśli dla jednego przypadku wystąpi defekt, dla pozostałych przypadków równieŝ Zminimalizowanie liczby wykonywanych przypadków testowych Wybór właściwych przypadków testowych, aby pokryć wszystkie moŝliwe scenariusze Przykład: Parametr miesiąc w dacie niepoprawne wartości 1 poprawne wartości niepoprawne wartości 2

7 Technika wartości granicznych Badane jest zachowanie systemu dla wartości granicznych Technika ta jest często traktowana jako rozszerzenie poprzedniej techniki DuŜo większe prawdopodobieństwo niepoprawnego zachowania testowanej funkcjonalności na krańcach klas równowaŝności Krańce minimalne, maksymalne wartości Testujemy zarówno wartości poprawne jak i niepoprawne Przykład: W bazie rejestrowane są osoby w wieku 0-10 lat [-1,0,1,10,11] Technika oparta o przejście stanów [1/2] Przypadki testowe są projektowane tak, aby sprawdzić: kaŝde przejście pomiędzy stanami, sekwencję przejść, kaŝdy stan, typową sekwencję stanów.

8 Technika oparta o przejście stanów [2/2] Przykład: Maszyna pracuje zgodnie z prezentowanym diagramem stanów Stan wej. 1 0 S1 S1 S2 S1 S2 S2 S2 S1 Tabela przejścia stanów 0 Diagram stanów Technika oparta o tabelę decyzyjną Metoda ta moŝe być stosowana, gdy zachowanie systemu zaleŝy od decyzji logicznych Kolumna tabeli odnosi się do jednej reguły biznesowej Przykład: C1 A1 Reguły C2 A2 C1 C2 F T T T - F C3 negacja logiczne AND A3 C3 A1 A2 - - T T F F F T F A3 F F T Graf przyczynowo-skutkowy Tabela decyzyjna

9 Testowanie oparte o przypadki uŝycia Testy są tworzone na bazie przypadków uŝycia albo reguł biznesowych Przypadki uŝycia opisują interakcje pomiędzy aktorami (system, uŝytkownicy) Przypadki testowe stworzone na bazie przypadków uŝycia są najbardziej przydatne dla sprawdzenia błędów mogących pojawić się w codziennej pracy uŝytkowników (badają przepływy) Warunki początkowe Warunki końcowe Przydatne do tworzenia testów akceptacyjnych Zalety i wady Zalety testowania metodą czarnej skrzynki: testy są powtarzalne testowane jest środowisko, w którym przeprowadzane są testy zainwestowany wysiłek moŝe być uŝyty wielokrotnie Wady testowania metodą czarnej skrzynki: wyniki testów mogą być szacowane nazbyt optymistycznie nie wszystkie właściwości systemu mogą zostać przetestowane przyczyna błędu nie jest znana

10 Techniki białej skrzynki (ang. White-box) Testy białej (ang. white box), które zakładają znajomość sposobu implementacji testowanych funkcji i są opracowywane na podstawie sprawdzania kody źródłowego. Dane wejściowe Biała skrzynka If (a = 1) print a is 1 else print a is not 1 Dane wyjściowe pokrycie instrukcji kodu pokrycie decyzji/rozgałęzień Pokrycie instrukcji kodu (ang. Statement coverage) Przypadki testowe są przygotowywane w taki sposób, aby pokryć instrukcje. Przykład: (1) (2) (3) (4) (5) (6) (7) (8) TC if (a = 3) else End if (b = 7) End print a is 3 print a is not 3 print b is 7 Wejście a = 3; b = 7 a = 7; b = 7 Pokrycie instrukcji: 100% TC1: a=3; b=7 TC2: a=7; b=7 Instrukcja (1) (2) (5) (6) (7) (8) (1) (3) (4) (5) (7) (8) Wyjście a is 3 b is 7 a is not 3 b is 7

11 Pokrycie rozgałęzień (ang. Branch coverage) Przypadki testowe są przygotowywane w taki sposób, aby pokryć pętle. Przykład: (1) (2) (3) (4) (5) (6) (7) (8) if (a = 3) else End if (b = 7) End print a is 3 print a is not 3 print b is 7 TC1: a=3; b=7 TC2: a=7; b=7 TC Wejście Id decyzji 1. a = 3; b = 7 (1)True (6)True 2. a = 7; b = 7 (1) False(6) True Pokrycie rozgałęzień: 75% Wyjście a is 3 b is 7 a is not 3 b is 7 Zalety i wady Zalety testowania metodą białej skrzynki: poniewaŝ wymagana jest znajomość struktury kodu, łatwo jest określić jaki typ danych wejściowych/wyjściowych jest potrzebny, aby efektywnie przetestować aplikację oprócz głównego zastosowania testów pomaga zoptymalizować kod aplikacji pozwala dokładnie określić przyczynę i miejsce w którym znajduje się błąd. Wady testowania metodą białej skrzynki: poniewaŝ wymagana jest znajomość struktury kodu, do przeprowadzenia testów potrzebny jest tester ze znajomością programowania co podnosi koszty. prawie niemoŝliwym jest przejrzenie kaŝdej linii kodu w poszukiwaniu ukrytych błędów, co moŝe powodować błędy po fazie testów.

12 Techniki oparte na doświadczeniu (ang. experience based) Zgadywanie błędów przypadki testowe są tworzone na bazie intuicji testera oraz jej/jego doświadczenia z podobnych sytuacji. Testowanie eksploracyjne przypadki testowe są tworzone równolegle z wykonywaniem testów. Przydatne w przypadku braku dokumentacji w projekcie oraz w przypadku presji czasowej. Scenariusz testowy Scenariusz testowy określa: sekwencję wykonywanych czynności ustawia przypadki testowe w określonym porządku (kolejności) w celu sprawdzenia konkretnej części systemu TC3:nazwa3 TC11: nazwa11 TC16: nazwa16

13 Metryki Postęp tworzenia przypadków testowych Efektywność tworzenia przypadków testowych Jakość przypadku testowego Stopień pokrycia wymagań Narzędzia TestLink QA Track Mercury Test Director IBM Rational ClearQuest IBM Rational Test Manager

14 Podsumowanie Brak jednej prostej recepty/najbardziej właściwej metody na wygenerowanie dobrego przypadku testowego Czynniki decydujące o wyborze metody: Cel testów Wymagania na system/dostępność dokumentacji Typ testów Poziom i typ ryzyka Czas i budŝet Metoda prowadzenia projektu IT Następne spotkanie UŜyteczność- testowanie i nie tylko

15 ? Dziękuję Zadanie 1. Zbadać testowalność przypadku uŝycia 2. Przeprowadzić analizę testową przypadku uŝycia 3. Wybrać technikę przygotowania przypadków testowych 4. Na podstawie przypadku uŝyciu przygotować przypadki testowe.