Tworzenie przypadków testowych

Prowadzący:
Katarzyna Pietrzyk
Paweł Morawski

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. Scenariusze testowe
6. Metryki
 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 programistę

Testowane przez testera

…
 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 90]

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.
Im późniejsza faza tworzenia oprogramowania,
tym naprawienie defektów staje się coraz droŜsze.
Cechy dobrze zdefiniowanych wymagań:

jednoznaczność

kompletność

spójność

modyfikowalność

śledzalność

uŜyteczność (wtórna)

weryfikowalność
 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]

Przypadek testowy [2/2]

(ang. Test case)
1. Unikalny identyfikator, nazwa

2. Opis, co sprawdza dany przypadek testowy

3. Warunki, jakie muszą zostać spełnione zanim

Nazwa
przystąpimy do wykonywania przypadku Opis
Oczekiwane Aktualny
Wykonywanej Status
rezultaty rezultat
testowego czynności

1
4. Pojedyncza czynność, którą naleŜy wykonać

5. Spodziewane rezultaty wykonania czynności 2

6. Wynik wykonania przypadku testowego

7. Stan systemu po poprawnym wykonaniu

przypadku testowego
 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)

 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.
... -2 -1 0 1 ...................... 12 13 14 15 .....
--------------------|-------------------------|---------------------
niepoprawne wartości 1 poprawne wartości niepoprawne wartości 2
 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,9,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.

Technika oparta o przejście stanów [2/2]

Przykład:
Maszyna pracuje zgodnie z prezentowanym diagramem stanów

0
1 1
Stan
wej. 1 0

S1 S1 S2 S1 S2

S2 S2 S1

0
Tabela przejścia stanów 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:

Reguły
C1 ∧ A1
1 2 3

C1 F T T
C2 A2
C2 T - F

- -
∧ C3 T
C3 A3

A1 T F F

negacja
A2 F T F
∧ logiczne AND
A3 F F T

Graf przyczynowo-skutkowy Tabela

decyzyjna
 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

 Techniki białej skrzynki
(ang. White-box)

Testy białej skrzynki (ang. white box), które zakładają znajomość sposobu
implementacji testowanych funkcji i są opracowywane na podstawie
sprawdzania kody źródłowego.
Biała skrzynka
If (a = 1)
Dane wejściowe print „a is 1” Dane wyjściowe
else
print „a is not 1”

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) if (a = 3)
(2) print “a is 3”
TC1: a=3; b=7
(3) else TC2: a=7; b=7
(4) print “a is not 3”
(5) End
(6) if (b = 7)
(7) print “b is 7”
(8) End

TC Wejście Instrukcja Wyjście

1. a = 3; b = 7 (1) (2) (5) (6) (7) (8) “a is 3” “b is 7”
2. a = 7; b = 7 (1) (3) (4) (5) (6) (7) (8) “a is not 3” “b is 7”
Pokrycie instrukcji: 100%
 Pokrycie rozgałęzień
(ang. Branch coverage)
Przypadki testowe są przygotowywane w taki sposób, aby pokryć rozgałęzienia.
Przykład:
(1) if (a = 3)
(2) print “a is 3”
TC1: a=3; b=7
(3) else TC2: a=7; b=7
(4) print “a is not 3”
(5) End
(6) if (b = 7)
(7) print “b is 7”
(8) End

TC Wejście Id decyzji Wyjście

1. a = 3; b = 7 (1)True (6)True “a is 3” “b is 7”
2. a = 7; b = 7 (1) False(6) True “a is not 3” “b is 7”

Pokrycie rozgałęzień: 75%

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.
 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

 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
 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…

Zarządzanie testowaniem oprogramowania.

 ?

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.
 Testowalność
Testowalność

• jednoznaczność

• kompletność

• spójność

• modyfikowalność

• śledzalność

• uŜyteczność (wtórna)

• weryfikowalność

Techniki projektowania

• 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)

• pokrycie instrukcji kodu

• pokrycie decyzji/rozgałęzień

• zgadywanie błędów

• testowanie eksploracyjne