Tworzenie przypadków testowych

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
Wykonywanej
czynności
testowego
4.
Pojedyncza czynność, którą naleŜy wykonać
1
5.
Spodziewane rezultaty wykonania czynności
2
6.
Wynik wykonania przypadku testowego
7.
Stan systemu po poprawnym wykonaniu
przypadku testowego
Oczekiwane
rezultaty
Aktualny
rezultat
Status
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
Stan
wej.
1
1
0
S1
S1
S2
S2
S2
S1
S1
S2
0
Diagram stanów
Tabela przejścia 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
3
C1
T
C2
T
-
F
-
-
T
A1
T
F
F
A2
F
T
F
A3
F
F
T
T
A2
C2
∧
C3
C3
A3
negacja
∧
2
F
logiczne AND
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)
print „a is 1”
else
print „a is not 1”
Dane wejściowe
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)
if (a = 3)
(2)
(3)
print “a is 3”
(4)
print “a is not 3”
(5)
End
(6)
if (b = 7)
(7)
(8)
TC
TC1: a=3; b=7
TC2: a=7; b=7
else
print “b is 7”
End
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”
(3)
TC1: a=3; b=7
TC2: a=7; b=7
else
(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.
2.
3.
4.
Zbadać testowalność przypadku uŜycia
Przeprowadzić „analizę testową” przypadku uŜycia
Wybrać technikę przygotowania przypadków testowych
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