1
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów
Bła
ż
ej Pietrzak
Blazej.Pietrzak@cs.put.poznan.pl
Testowanie wymaga du
ż
ego wysiłku ze strony zespołu testuj
ą
cego.
Mimo to przetestowany system nadal zawiera bł
ę
dy. Rzadko kiedy starcza
zasobów i czasu na jego adekwatne sprawdzenie. Czy istniej
ą
zatem techniki
umo
ż
liwiaj
ą
ce dokładniejsze testowanie? Jedn
ą
z nich jest technika b
ę
d
ą
ca w
tytule tego wykładu – automatyzacja wykonywania testów. Zapraszam Pa
ń
stwa
na wykład.
2
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (2)
Plan wykładów
Zasady skutecznego działania
Specyfikacja wymagań (przypadki użycia)
Przeglądy artefaktów (inspekcje Fagana)
Język UML, cz. I
Język UML, cz. II
Metody formalne (sieci Petriego)
Wzorce projektowe
Zarządzanie konfiguracją (CVS)
Wprowadzenie do testowania
Automatyzacja wykonywania testów
Programowanie Ekstremalne
Ewolucja oprogramowania i refaktoryzacja
Omówiony tutaj materiał b
ę
dzie punktem odniesienia dla
pozostałych wykładów dotycz
ą
cych programowania ekstremalnego i
refaktoryzacji, gdzie testowanie odgrywa kluczow
ą
rol
ę
podczas
weryfikacji poprawno
ś
ci przekształce
ń
refaktoryzacyjnych.
3
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (3)
Plan wykładu
• Automatyzacja testowania – wady i zalety
• Automatyzacja poszczególnych
czynno
ś
ci w ramach testowania
• JUnit jako przykład narz
ę
dzia
do automatyzacji testów
• JUnit - dobre praktyki
programistyczne
Plan wykładu wygl
ą
da nast
ę
puj
ą
co. Na pocz
ą
tku spojrzymy ogólnie
na testowanie i na proces jego automatyzacji. Okre
ś
limy co oznacza dobrej
jako
ś
ci wariant testu w przypadku r
ę
cznego testowania, oraz w jaki sposób
opisana jest jako
ść
dla testów automatycznych. Nast
ę
pnie omówione zostan
ą
czynno
ś
ci w ramach testowania. Dla ka
ż
dej z nich podane zostan
ą
sposoby jej
automatyzacji. Wytłumaczone zostanie dlaczego wykonywanie i porównywanie
wyników testów jest bardziej adekwatne do automatyzacji ni
ż
ich projektowanie.
Podane zostan
ą
korzy
ś
ci, problemy i ograniczenia płyn
ą
ce z automatyzacji
testowania. Wreszcie jako przykład narz
ę
dzia do automatyzacji wykonywania
testów przedstawiona zostanie biblioteka JUnit. Na koniec podane zostan
ą
dobre
praktyki programistyczne zwi
ą
zane z jej wykorzystaniem.
4
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (4)
Potrzeba szybkich rozwi
ą
za
ń
• Testowanie oprogramowania powinno by
ć
:
– Efektywne
– Wydajne
• Testowanie to ~ 30% - 40% (dla systemów
krytycznych ~80%) całkowitej pracochłonno
ś
ci
• Przetestowane programy zawieraj
ą
bł
ę
dy
Oprogramowanie powinno by
ć
przetestowane by uzyska
ć
pewno
ść
,
ż
e b
ę
dzie działa
ć
prawidłowo w
ś
rodowisku docelowym. Od testowania wymaga
si
ę
by było ono efektywne i wydajne. Przez efektywne rozumie si
ę
skuteczne w
znajdywaniu bł
ę
dów. Wydajne natomiast oznacza wykonanie testów w sposób
jak najszybszy i jak najta
ń
szy.
Czas potrzebny na testowanie dla typowych projektów
informatycznych waha si
ę
od 30% do 40% całkowitej pracochłonno
ś
ci. W
przypadku systemów krytycznych wynosi nawet do 80%. Mimo to przetestowane
programy zawieraj
ą
bł
ę
dy. Niestety nieprawidłowe działanie programu sporo
kosztuje szczególnie gdy usterki znalezione zostan
ą
dopiero po wdro
ż
eniu
systemu, podczas normalnego u
ż
ytkowania. Powodów wyst
ę
powania bł
ę
dów
mo
ż
e by
ć
wiele jednak oznacza to,
ż
e nie przetestowano dokładnie systemu.
5
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (5)
Obietnice automatyzacji testowania
• Zwi
ę
kszenie testowania
(przypadki testowe uruchamiane w minutach)
• Zmniejszenie kosztu testowania a
ż
do 80%
wysiłku r
ę
cznego testowania
• Lepszej jako
ś
ci oprogramowanie
wyprodukowane szybciej
Jednym z rozwi
ą
za
ń
mo
ż
e by
ć
zwi
ę
kszenie czasu potrzebnego na
testowanie. Jednak w praktyce jest to cz
ę
sto nieopłacalne. Innym rozwi
ą
zaniem
jest poprawa sposobu w jaki testowane jest oprogramowanie. Mo
ż
na przeszkoli
ć
testerów, by tworzyli skuteczniejsze przypadki testowe. R
ę
czne wykonywanie
testów zajmuje sporo czasu, szczególnie je
ś
li raz zaprojektowane warianty
testów wykonywane s
ą
wiele razy. Automatyzuj
ą
c testowanie mo
ż
na znacznie
zmniejszy
ć
koszt zwi
ą
zany z dokładnym testowaniem. W tym samym czasie
mo
ż
na wykona
ć
wi
ę
ksz
ą
liczb
ę
przypadków testowych, czyli mo
ż
na dokładniej
sprawdzi
ć
system. Wykonanie wariantów testu mo
ż
e trwa
ć
kilka minut, a nie jak
w przypadku r
ę
cznych testów godziny. Znane s
ą
przypadki gdzie automatyzacja
testowania zmniejszyła koszt testowania do 80% wysiłku potrzebnego na jego
r
ę
czne przeprowadzenie. W ten sposób zaoszcz
ę
dzone pieni
ą
dze mo
ż
na było
przeznaczy
ć
na dokładniejsze testowanie i wyprodukowa
ć
lepszej jako
ś
ci
oprogramowanie w krótszym czasie.
6
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (6)
Ocena jako
ś
ci wariantu testu
Ekonomia
Łatwość zmian
Przykładność
Efektywność
Testowanie to umiej
ę
tno
ść
wyboru, które warianty testów powinny
by
ć
zaprojektowane i wykonane. Dla ka
ż
dego systemu wyst
ę
puje astronomiczna
liczba przypadków testowych. W praktyce jednak jest czas na wykonanie tylko
niewielkiej cz
ęś
ci z nich. Mimo tego od wybranych wariantów, które maj
ą
by
ć
wykonane oczekuje si
ę
,
ż
e znajd
ą
wi
ę
kszo
ść
bł
ę
dów wyst
ę
puj
ą
cych w
programie.
Wybór przypadków testowych do wykonania jest wi
ę
c bardzo
wa
ż
nym zadaniem. Badania pokazały,
ż
e selekcja wariantów w sposób losowy
nie jest efektywnym podej
ś
ciem do testowania. Najlepszym podej
ś
ciem jest
wybranie „najlepszych przypadków testowych” do wykonania. Jak wi
ę
c mo
ż
na
okre
ś
li
ć
, które warianty testów s
ą
najlepsze?
W kontek
ś
cie automatyzacji testowania przypadki testowe mo
ż
na
ocenia
ć
na podstawie czterech atrybutów:
efektywno
ś
ci (ang. effective), łatwo
ś
ci zmian (ang. evolvable), przykładno
ś
ci
(ang. exemplary), i ekonomiczno
ś
ci (ang. economic).
7
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (7)
Ocena jako
ś
ci wariantu testu
Ekonomia
Łatwość zmian
Przykładność
Efektywność
Zdolność testu do
znajdywania błędów
Najwa
ż
niejszym z atrybutów opisuj
ą
cych jako
ść
przypadku
testowego jest efektywno
ść
(ang. effective). Jest to zdolno
ś
ci testu do
znajdywania bł
ę
dów. Im wi
ę
ksza jest jego warto
ść
tym wi
ę
ksze jest
prawdopodobie
ń
stwo na znalezienie bł
ę
du przez test.
8
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (8)
Ocena jako
ś
ci wariantu testu
Ekonomia
Łatwość zmian
Przykładność
Efektywność
Zdolność testu do
sprawdzania więcej niż
jednej rzeczy
Dobry wariant testu powinien tak
ż
e posiada
ć
zdolno
ść
do
testowania wi
ę
cej ni
ż
jednej rzeczy w ramach przypadku testowego. W ten
sposób zmniejsza to całkowit
ą
liczb
ę
przypadków testowych wymaganych do
sprawdzenia systemu. Cech
ę
t
ą
opisuje atrybut przykładno
ść
(ang. exemplary).
Im wi
ę
ksza warto
ść
tego atrybutu tym wi
ę
cej potrafi przetestowa
ć
dany
przypadek testowy.
9
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (9)
Ocena jako
ś
ci wariantu testu
Ekonomia
Łatwość zmian
Przykładność
Efektywność
Koszt modyfikacji przypadku
testowego
Pozostałe dwa atrybuty bior
ą
pod uwag
ę
koszt zwi
ą
zany z
przypadkiem testowym. Pierwszy z nich, łatwo
ść
zmian (ang. evolvable) okre
ś
la
ile kosztuje modyfikacja wariantu testu, w przypadku gdy testowany system uległ
zmianie. Na ogół wraz z modyfikacjami w systemie konieczne jest te
ż
zmodyfikowanie przypadków testowych. Je
ś
li zmieniono zachowanie istniej
ą
cej
funkcji (nie polegaj
ą
ce oczywi
ś
cie na poprawieniu wykrytego bł
ę
du) to konieczna
b
ę
dzie aktualizacja przypadków testowych j
ą
sprawdzaj
ą
cych. Im wi
ę
ksza
warto
ść
tego atrybutu tym łatwiej jest wprowadzi
ć
zmian
ę
w danym wariancie
testu za ka
ż
dym razem gdy testowany system ulega zmianie.
10
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (10)
Ocena jako
ś
ci wariantu testu
Ekonomia
Łatwość zmian
Przykładność
Efektywność
Koszt wykonania, analizy i
debugowania wariantu testu
Ostatni z atrybutów ekonomiczno
ść
(ang. Economic) okre
ś
la koszt
wykonania, analizy i debugowania przypadku testowego. Im wi
ę
ksza jego
warto
ść
tym taniej jest dany wariant wykona
ć
i analizowa
ć
.
W praktyce trzeba cz
ę
sto równowa
ż
y
ć
wpływ tych czterech
czynników na siebie. Przykładowo wariant testu, który testuje wiele rzeczy b
ę
dzie
najcz
ęś
ciej kosztował sporo na etapie wykonania, analizy i ewentualnego
debugowania tego testu. B
ę
dzie tak
ż
e najprawdopodobniej wymagał sporego
nakładu pracy na jego piel
ę
gnacj
ę
w przypadku, gdy testowany system ulegnie
zmianie. Niestety wysoka warto
ść
dla atrybutu przykładno
ś
ci powoduje obni
ż
enie
na skali ekonomiczno
ś
ci i łatwo
ś
ci zmian.
Mo
ż
na wi
ę
c powiedzie
ć
,
ż
e testowanie to nie tylko zapewnienie,
ż
e
warianty testu znajd
ą
wi
ę
kszo
ść
bł
ę
dów, ale tak
ż
e zapewnienie,
ż
e te przypadki
testowe s
ą
dobrze zaprojektowane i nie kosztuj
ą
sporo.
11
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (11)
Ocena jako
ś
ci automatyzacji
Ekonomia
Łatwość zmian
Przykładność
Efektywność
Automatyzacja testów znacznie ró
ż
ni si
ę
od testowania. Bywa
bardzo kosztowna, dro
ż
sza nawet od r
ę
cznego wykonania testów. Bardzo wa
ż
n
ą
rol
ę
odgrywa tutaj wybór wariantów testów, które maj
ą
by
ć
zautomatyzowane.
Decyzja ta wpływa na to czy zyskuje si
ę
na automatyzacji testów czy te
ż
traci.
Jako
ść
automatyzacji nie okre
ś
la si
ę
tak samo jak jako
ść
wariantów testów.
To czy dany przypadek testowy jest zautomatyzowany czy
wykonywany r
ę
cznie nie wpływa na jego zdolno
ść
znajdywania bł
ę
dów -
efektywno
ść
(ang. effective), ani na przykładno
ść
(ang. exemplary). Nie ma
znaczenia jak dobrze zostanie zautomatyzowany wariant testu, który nie wykrywa
ż
adnego bł
ę
du. Po automatyzacji nadal nie wykryje bł
ę
du! B
ę
dzie za to
wykonywany szybciej.
Automatyzacja testów wpływa na dwa atrybuty: ekonomiczno
ść
(ang. economic), oraz łatwo
ść
zmian (ang. evolvable). Po zaimplementowaniu
zautomatyzowany przypadek testowy jest na ogół bardziej ekonomiczny,
poniewa
ż
koszt zwi
ą
zany z jego wykonaniem tego testu jest znacznie mniejszy
od przeprowadzenia go r
ę
cznie. Niestety zautomatyzowane testy kosztuj
ą
wi
ę
cej
je
ś
li chodzi o ich stworzenie i utrzymanie. Im lepsze podej
ś
cie do automatyzacji
testów, tym ta
ń
sze b
ę
dzie ich tworzenie w dłu
ż
szej perspektywie czasu. Je
ś
li w
trakcie automatyzacji nie bierze si
ę
pod uwag
ę
konieczno
ś
ci przyszłej piel
ę
gnacji
testów, ich pó
ź
niejsza aktualizacja mo
ż
e kosztowa
ć
co najmniej tyle samo (je
ś
li
nie wi
ę
cej) co wykonanie tych testów r
ę
cznie.
12
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (12)
Ocena jako
ś
ci wariantu testu
Ekonomia
Łatwość zmian
Przykładność
Efektywność
Ręczne
testowanie
Wpływ automatyzacji na atrybuty opisuj
ą
ce jako
ść
wariantu testu
zobrazowane zostan
ą
na poni
ż
szym diagramie. Załó
ż
my,
ż
e dla wariantu testu
wykonanego r
ę
cznie warto
ś
ci atrybutów przyjmuj
ą
warto
ś
ci pokazane na
diagramie przy pomocy linii ci
ą
głej.
13
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (13)
Ocena jako
ś
ci wariantu testu
Ekonomia
Łatwość zmian
Przykładność
Efektywność
Ręczne
testowanie
Zautomatyzowane
pierwsze przejście
Po automatyzacji, przypadek testowy traci na łatwo
ś
ci zmian,
poniewa
ż
wi
ę
cej pracy trzeba po
ś
wi
ę
ci
ć
na jego dostosowanie ni
ż
w przypadku
jego „r
ę
cznego” odpowiednika. Traci równie
ż
na ekonomiczno
ś
ci, poniewa
ż
zautomatyzowanie go kosztuje wi
ę
cej pracy ni
ż
wykonanie tego wariantu
„r
ę
cznie”.
14
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (14)
Ocena jako
ś
ci wariantu testu
Ekonomia
Łatwość zmian
Przykładność
Efektywność
Ręczne
testowanie
Zautomatyzowane
pierwsze przejście
Zautomatyzowane
po wielu
przejściach
Dopiero gdy zautomatyzowany przypadek testowy wykonany
zostanie wiele razy stanie si
ę
bardziej ekonomiczny od tego samego wariantu
testu wykonanego r
ę
cznie.
By uzyska
ć
efektywny i wydajny zbiór zautomatyzowanych testów
trzeba zbudowa
ć
zbiór dobrych przypadków testowych, czyli takich które
maksymalizuj
ą
cztery omówione wcze
ś
niej kryteria oceny. Z tych wariantów
nast
ę
pnie wybiera si
ę
te, które powinny by
ć
poddane automatyzacji.
15
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (15)
Kto automatyzuje?
Test automator:
–Tester
–Programista
Osob
ą
, która tworzy i piel
ę
gnuje artefakty zwi
ą
zane ze
zautomatyzowanymi testami jest test automator. Zadaniem testera natomiast jest
przygotowanie „dobrych” wariantów testów, które nast
ę
pnie oceniane s
ą
pod
k
ą
tem automatyzacji. Test automatorem bywa cz
ę
sto sam tester, cho
ć
mo
ż
e by
ć
nim tak
ż
e osoba spoza zespołu odpowiedzialnego za testowanie. Przykładowo
je
ś
li w skład zespołu testerów wchodz
ą
osoby, które s
ą
u
ż
ytkownikami systemu
to posiadaj
ą
oni nieocenion
ą
wiedz
ę
biznesow
ą
, ale nie maj
ą
umiej
ę
tno
ś
ci
technicznych potrzebnych do automatyzacji tych testów. Do tego celu mo
ż
na
wykorzysta
ć
programistów, by wspomogli te osoby w procesie implementacji i
piel
ę
gnacji zautomatyzowanych testów. W takim przypadku programista jest test
automatorem.
Podobnie jak mo
ż
liwe jest uzyskanie dobrych lub słabych
jako
ś
ciowo przypadków testowych, mo
ż
liwe jest uzyskanie ró
ż
nej jako
ś
ci
zautomatyzowanych wariantów testu. To od umiej
ę
tno
ś
ci test automatora zale
ż
y
jak łatwo b
ę
dzie doda
ć
lub poprawi
ć
istniej
ą
ce zautomatyzowane warianty
testów, oraz jakie korzy
ś
ci b
ę
d
ą
płyn
ąć
z automatyzacji.
16
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (16)
Zalety
• Testy regresyjne
• Wi
ę
cej testów cz
ęś
ciej
• Wykonanie testów trudnych do wykonania r
ę
cznie
• Lepsze u
ż
ycie zasobów
• Spójno
ść
i powtarzalno
ść
testów
• Reu
ż
ywalno
ść
testów
• Szybciej na rynek
• Zwi
ę
kszona pewno
ść
• Testowanie mo
ż
e odbywa
ć
si
ę
w nocy
Automatyzacja testowania umo
ż
liwia wykonanie wielu czynno
ś
ci znacznie
wydajniej ni
ż
w przypadku gdyby były przeprowadzane r
ę
cznie. Najbardziej oczywist
ą
korzy
ś
ci
ą
płyn
ą
c
ą
z automatycznego testowania jest wykonanie testów regresyjnych dla nowej wersji
programu. Wysiłek konieczny na ten typ testowania jest minimalny, pod warunkiem,
ż
e testy
zostały zautomatyzowane dla wcze
ś
niejszej wersji aplikacji. W zaledwie kilka minut mo
ż
na wtedy
wybra
ć
odpowiednie warianty testów i je wykona
ć
.
Jako zalet
ę
mo
ż
na zaliczy
ć
tak
ż
e uruchamianie wi
ę
cej testów cz
ęś
ciej. Dzi
ę
ki
temu,
ż
e testy wykonuj
ą
si
ę
szybciej mo
ż
na je wykonywa
ć
cz
ęś
ciej. To prowadzi do wi
ę
kszej
pewno
ś
ci,
ż
e tworzony system działa zgodnie z oczekiwaniami klienta.
Niektóre testy bardzo trudno wykona
ć
r
ę
cznie lub jest to wr
ę
cz niemo
ż
liwe. Do
tego typu testów nale
żą
m.in. testy wydajno
ś
ciowe. Próba wykonania testu, w którym 500 osób
próbuje w tym samym czasie wstawi
ć
pewn
ą
informacj
ę
do bazy mo
ż
e by
ć
do
ść
kosztowna i
trudna do zsynchronizowana w przypadku gdyby miała by
ć
przeprowadzona przez testerów.
Odci
ąż
aj
ą
c testerów od konieczno
ś
ci wykonywania testów i porównywania
uzyskanego wyj
ś
cia z oczekiwanym, które s
ą
do
ść
nudnymi zaj
ę
ciami umo
ż
liwia im skupienie si
ę
na projektowaniu lepszych testów.
Na automatyzacji zyskuj
ą
tak
ż
e same testy. Poprawia si
ę
ich spójno
ść
i
powtarzalno
ść
. Testy, które s
ą
powtarzane automatycznie b
ę
d
ą
powtarzane dokładnie tak samo
(przynajmniej wej
ś
cie, gdy
ż
wyj
ś
cie mo
ż
e si
ę
ró
ż
ni
ć
w zale
ż
no
ś
ci od np. czasu). To daje poziom
regularno
ś
ci, który jest trudno uzyska
ć
przez testowanie r
ę
czne. Te same testy mog
ą
by
ć
wykonywane w ró
ż
nych konfiguracjach sprz
ę
towych, na ró
ż
nych systemach operacyjnych z
wykorzystaniem ró
ż
nych baz danych. To daje spójno
ść
pomi
ę
dzy platformami dla produktów
wieloplatformowych, która jest niemo
ż
liwa do osi
ą
gni
ę
cia w przypadku r
ę
cznego testowania.
Narzucenie dobrego re
ż
imu automatyzacji testów mo
ż
e zapewni
ć
spójne standardy zarówno dla
testowania jak i programowania. Przykładowo narz
ę
dzie mo
ż
e sprawdzi
ć
,
ż
e ten sam typ cechy
został zaimplementowany w ten sam sposób we wszystkich aplikacjach.
17
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (17)
Zalety
• Testy regresyjne
• Wi
ę
cej testów cz
ęś
ciej
• Wykonanie testów trudnych do wykonania r
ę
cznie
• Lepsze u
ż
ycie zasobów
• Spójno
ść
i powtarzalno
ść
testów
• Reu
ż
ywalno
ść
testów
• Szybciej na rynek
• Zwi
ę
kszona pewno
ść
• Testowanie mo
ż
e odbywa
ć
si
ę
w nocy
Dzi
ę
ki temu,
ż
e automatyczne testy mo
ż
na wykonywa
ć
szybciej czas potrzebny
na testowanie mo
ż
e zosta
ć
skrócony, co oznacza,
ż
e produkt mo
ż
e zosta
ć
szybciej wypuszczony
na rynek.
Testowanie mo
ż
e tak
ż
e odbywa
ć
si
ę
w nocy. Testy uruchamiane s
ą
gdy testerzy ko
ń
cz
ą
prac
ę
. Nie trzeba czeka
ć
na wyniki. B
ę
d
ą
dost
ę
pne
nast
ę
pnego dnia rano.
18
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (18)
Ograniczenia automatyzacji
• „Zautomatyzowane testy znajduj
ą
tylko 15% bł
ę
dów.
R
ę
czne testowanie znajduje 85%.”
Bach, 1997
• Automatyzacja testów nie poprawia ich efektywno
ś
ci
„Automatyzacja chaosu daje tylko szybszy chaos”
• Automatyzacja testów mo
ż
e ograniczy
ć
wytwarzanie
oprogramowania (wzgl
ę
dy ekonomiczne)
• Du
ż
y koszt wytworzenia automatycznego testu
~2 – 10x (max 30x) wysiłek zwi
ą
zany z r
ę
cznym
wykonywaniem testów
• Automatyczne testy nie maj
ą
wyobra
ź
ni
Z automatyzacj
ą
testowania wi
ąż
e si
ę
wiele problemów i
ogranicze
ń
. James Bach na podstawie swojego wieloletniego do
ś
wiadczenia
podaje,
ż
e wi
ę
kszo
ść
bł
ę
dów wykrywana jest podczas r
ę
cznego wykonywania
testowania, bo a
ż
85% z nich. Tylko 15% bł
ę
dów znajdywanych jest przez
automatyczne przypadki testowe. By móc zautomatyzowa
ć
dany wariantu testu
trzeba najpierw upewni
ć
si
ę
,
ż
e jest prawidłowy. Nie ma sensu tworzy
ć
automatu
dla niepoprawnych przypadków testowych. Testowanie wariantu testu polega
najcz
ęś
ciej na wykonaniu go najpierw r
ę
cznie, a nast
ę
pnie przeanalizowaniu
uzyskanych wyników. Dopiero tak sprawdzony wariant jest automatyzowany.
Najwi
ę
ksza szansa na znalezienie bł
ę
du jest podczas pierwszego wykonania
testu. Raz wykryty i poprawiony bł
ą
d na ogół nie powtarza si
ę
, za wyj
ą
tkiem
sytuacji, w których testowany fragment programu podlega modyfikacjom. Wtedy
istnieje szansa na wprowadzenie bł
ę
du podczas zmian w kodzie aplikacji.
Testy poddawane automatyzacji musz
ą
by
ć
dobrej jako
ś
ci.
Narz
ę
dzie wykonuj
ą
ce testy mo
ż
e tylko okre
ś
li
ć
czy oczekiwane wyj
ś
cie pasuje
do faktycznie zaobserwowanego. Nie poda czy wariant testu jest prawidłowy.
Je
ś
li przypadek testowy jest mało efektywny to prawdopodobie
ń
stwo znalezienia
bł
ę
du dla takiego wariantu po jego automatyzacji b
ę
dzie równie
ż
niewielkie.
Automat mo
ż
e najwy
ż
ej zwi
ę
kszy
ć
wydajno
ść
takiego testu tzn. zmniejszy
ć
koszt
i czas potrzebny do wykonania wariantu testu.
19
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (19)
Ograniczenia automatyzacji
• „Zautomatyzowane testy znajduj
ą
tylko 15% bł
ę
dów.
R
ę
czne testowanie znajduje 85%.”
Bach, 1997
• Automatyzacja testów nie poprawia ich efektywno
ś
ci
„Automatyzacja chaosu daje tylko szybszy chaos”
• Automatyzacja testów mo
ż
e ograniczy
ć
wytwarzanie
oprogramowania (wzgl
ę
dy ekonomiczne)
• Du
ż
y koszt wytworzenia automatycznego testu
~2 – 10x (max 30x) wysiłek zwi
ą
zany z r
ę
cznym
wykonywaniem testów
• Automatyczne testy nie maj
ą
wyobra
ź
ni
Zautomatyzowane testy s
ą
mniej podatne na zmiany ni
ż
testy
wykonywane r
ę
cznie. Wymagaj
ą
wi
ę
cej wysiłku na etapie wytworzenia oraz w ich
pó
ź
niejszej piel
ę
gnacji. Modyfikacje programu wymagaj
ą
tak
ż
e dostosowania
zautomatyzowanych testów. Mog
ą
one nie by
ć
wprowadzone ze wzgl
ę
dów
ekonomicznych. Mo
ż
e okaza
ć
si
ę
,
ż
e zmiana wariantów testów jest nieopłacalna
je
ś
li nie pomy
ś
lano o ich piel
ę
gnacji podczas ich automatyzacji.
Koszt wytworzenia automatycznych testów te
ż
nie jest bez
znaczenia.
Ś
rednio wynosi on 2 do 10 razy wysiłku zwi
ą
zanego z r
ę
cznym
wykonywaniem testów. W niektórych przypadkach koszt ten nawet wzrastał do
30 razy. W zwi
ą
zku z tym wa
ż
ne jest by automatyzowa
ć
tylko te testy, dla których
ma to ekonomiczny sens, czyli takie, które b
ę
d
ą
wiele razy uruchamiane. Dzi
ę
ki
temu koszt zwi
ą
zany z ich wytworzeniem si
ę
zwróci.
Automatyczne testy to tylko program posłusznie wykonuj
ą
cy
instrukcje. Niestety tylko tester jest w stanie stwierdzi
ć
, czy wykonywany
przypadek testowy zawiera bł
ą
d. Tak
ż
e tylko on jest w stanie poprawi
ć
wariant
testu by sprawdzał dodatkowe rzeczy je
ś
li uzna,
ż
e ów wariant nie jest
dostatecznie szczegółowy.
20
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (20)
Kiedy testowa
ć
r
ę
cznie?
• Testy s
ą
wykonywane rzadko
• Testowany program cz
ę
sto ulega zmianom
• Wyniki s
ą
łatwe do sprawdzenia przez człowieka
i trudne do zautomatyzowania (np. audio,
schemat kolorów, układ kontrolek na formatce)
• Test wymaga fizycznej interakcji ze strony
u
ż
ytkownika
Nie jest mo
ż
liwe ani tak
ż
e oczekiwane by automatyzowa
ć
wszystkie
czynno
ś
ci zwi
ą
zane z testowaniem jak równie
ż
same testy. Zawsze znajd
ą
si
ę
takie przypadki, które łatwiej b
ę
dzie wykona
ć
r
ę
cznie lub te
ż
takie, których
automatyzacja jest nieekonomiczna. Testy których najcz
ęś
ciej nie warto
automatyzowa
ć
to testy wykonywane rzadko. Je
ś
li test jest wykonywany tylko
kilka razy to koszt zwi
ą
zany z jego automatyzacj
ą
mo
ż
e nie zwróci
ć
si
ę
. To
wła
ś
nie wielokrotne uruchamianie takiego testu amortyzuje koszt zwi
ą
zany z jego
automatyzacj
ą
.
W przypadku gdy testowany program cz
ę
sto ulega zmianie mo
ż
e
okaza
ć
si
ę
,
ż
e nie warto automatyzowa
ć
testów sprawdzaj
ą
cych te jego
fragmenty, które cz
ę
sto podlegaj
ą
modyfikacji. Wraz ze zmianami w programie
wi
ąż
e si
ę
potrzeba dostosowywania testów co zwi
ę
ksza koszt zwi
ą
zany z ich
utrzymaniem i mo
ż
e okaza
ć
si
ę
nieopłacalne.
Równie
ż
nie warto automatyzowa
ć
testów, które łatwe s
ą
do
zweryfikowania przez człowieka, ale trudne lub niemo
ż
liwe dla automatu.
Przykładowo sprawdzenie schematu kolorów, czy te
ż
układu (ang. layout)
kontrolek w interfejsie u
ż
ytkownika, albo okre
ś
lenie czy prawidłowy d
ź
wi
ę
k
wydobywa si
ę
w momencie wywołania okre
ś
lonego zdarzenia w systemie s
ą
do
ść
trudne do sprawdzenia przez program, a nie sprawiaj
ą
wi
ę
kszych
problemów testerowi.
Je
ś
li testy wymagaj
ą
fizycznej interakcji ze strony u
ż
ytkownika
systemu to tak
ż
e powinny by
ć
wykonywane r
ę
cznie. Przykładem takiego testu,
jest sytuacja kiedy by wykona
ć
test nale
ż
y przeci
ą
gn
ąć
kart
ę
przez czytnik kart.
21
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (21)
Czynno
ś
ci w ramach testowania
1. Identyfikacja warunków testu
2. Zaprojektowanie przypadków testowych
3. Zbudowanie przypadków testowych
4. Uruchomienie przypadków testowych
5. Porównanie uzyskanych wyników
z oczekiwanymi
Na tym slajdzie przedstawiono czynno
ś
ci wykonywane w ramach
testowania. To s
ą
czynno
ś
ci, dla których chciałbym omówi
ć
mo
ż
liwo
ść
przeprowadzenia automatyzacji.
22
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (22)
Czynno
ś
ci w ramach testowania
1. Identyfikacja warunków testu
element lub zdarzenie, które mo
ż
e
by
ć
zweryfikowane przez testy
Warunek 1: przelew < 0
Warunek 2: u
ż
ytkownik posiada konto
Pierwsz
ą
czynno
ś
ci
ą
jak
ą
nale
ż
y wykona
ć
to okre
ś
lenie co b
ę
dzie
testowane. Przez warunek testu rozumie si
ę
element lub zdarzenie, które mo
ż
e
by
ć
zweryfikowane przez testy. Jest wiele ró
ż
nych warunków testu dla systemu,
jak równie
ż
dla ró
ż
nych rodzajów testowania, takich jak testowanie
wydajno
ś
ciowe, czy te
ż
testy bezpiecze
ń
stwa itd.
Warunki testu to opisy okoliczno
ś
ci, które mo
ż
na by sprawdzi
ć
.
Przykładowo: sprawdzenie zachowania si
ę
systemu gdy wykonywany b
ę
dzie
przelew na konto o warto
ś
ci ujemnej.
Istnieje wiele ró
ż
nych technik testowania, które ułatwiaj
ą
testerom
identyfikacj
ę
warunków testu w sposób usystematyzowany (przykładowo analiza
warto
ś
ci granicznych).
23
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (23)
Czynno
ś
ci w ramach testowania
1.
Identyfikacja warunków testu
2.
Zaprojektowanie przypadków testowych
Stan systemu:
•Zalogowany do systemu
•Baza danych posiada dane testowe
Komunikat pytaj
ą
cy o
potwierdzenie
Informacja o bł
ę
dnych
danych
Oczekiwane wyj
ś
cie
Wprowad
ź
dane przelewu
Potwierd
ź
Wej
ś
cie
kwota = -1
nr konta = xxx
kwota = -1
nr konta = xxx
1
2
Warunki testu
Krok
Zaprojektowanie przypadków testowych okre
ś
la w jaki sposób
warunki testu b
ę
d
ą
sprawdzane. Wariant testu składa si
ę
z szeregu testów
przeprowadzanych w sekwencji i powi
ą
zanych z przedmiotem testu, czyli
powodem/celem testu. Wynikiem projektowania testu jest zbiór testów
składaj
ą
cych si
ę
z warto
ś
ci wej
ś
ciowych, oczekiwanego wyj
ś
cia oraz stanu
systemu koniecznego do przeprowadzenia testu. Oczekiwane wyj
ś
cie zawiera
informacje, na temat tego co powinno by
ć
utworzone, czego nie powinno by
ć
w
wyniku wykonania testu itd. Zbiór oczekiwanego wyj
ś
cia mo
ż
e by
ć
całkiem spory.
24
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (24)
Czynno
ś
ci w ramach testowania
1. Identyfikacja warunków testu
2. Zaprojektowanie przypadków testowych
3. Zbudowanie przypadków testowych
–
Przygotowanie procedur testowych
Procedura testowa dla testu wprowadzenia ujemnej warto
ś
ci kwoty przelewu:
1. Wci
ś
nij przycisk Tab.
2. Wprowad
ź
-1.
3. Wci
ś
nij przycisk Tab.
4. Wprowad
ź
nr konta = xxx
5. Wci
ś
nij Tab.
6. Po pod
ś
wietleniu si
ę
przycisku Submit wci
ś
nij ENTER.
Zbudowanie przypadków testowych polega na utworzeniu procedur
testowych, które opisuj
ą
elementarne kroki konieczne do wykonania
pojedynczego testu w ramach przypadku testowego. Przykładowo dla testu
zwi
ą
zanego z wprowadzeniem ujemnej warto
ś
ci kwoty przelewu procedura
testowa wygl
ą
da nast
ę
puj
ą
co:
1. Wci
ś
nij przycisk Tab.
2. Wprowad
ź
-1.
3. Wci
ś
nij przycisk Tab.
4. Wprowad
ź
nr konta = xxx
5. Wci
ś
nij Tab.
6. Po pod
ś
wietleniu si
ę
przycisku Submit wci
ś
nij ENTER.
Je
ś
li kroki te wykonywane s
ą
automatycznie to mówi si
ę
o skryptach testowych.
25
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (25)
Czynno
ś
ci w ramach testowania
1. Identyfikacja warunków testu
2. Zaprojektowanie przypadków testowych
3. Zbudowanie przypadków testowych
–
Przygotowanie procedur testowych
–
Przygotowanie danych wej
ś
ciowych
–
Przygotowanie oczekiwanego wyj
ś
cia
4. Uruchomienie przypadków testowych
5. Porównanie uzyskanych wyników
z oczekiwanymi
Dane wej
ś
ciowe musz
ą
tak
ż
e zosta
ć
zbudowane by móc wykona
ć
testy. Je
ś
li przykładowo test wykorzystuje jakie
ś
dane z pliku lub bazy danych,
plik ten lub baza danych musi by
ć
zainicjowana by zawierała informacje
potrzebne do wykonania testu.
26
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (26)
Czynno
ś
ci w ramach testowania
1. Identyfikacja warunków testu
2. Zaprojektowanie przypadków testowych
3. Zbudowanie przypadków testowych
–
Przygotowanie procedur testowych
–
Przygotowanie danych wej
ś
ciowych
–
Przygotowanie oczekiwanego wyj
ś
cia
4. Uruchomienie przypadków testowych
5. Porównanie uzyskanych wyników
z oczekiwanymi
Procedura testowa dla testu wprowadzenia ujemnej warto
ś
ci kwoty przelewu:
…
7. Sprawd
ź
czy system pyta o potwierdzenie wykonania operacji. Je
ś
li nie to
oznacza to bł
ą
d systemu. Wtedy wykonaj ...
…
Oczekiwane wyj
ś
cie mo
ż
e by
ć
zorganizowane w pliki by umo
ż
liwi
ć
ich pó
ź
niejsze porównanie w sposób automatyczny np. przy u
ż
yciu narz
ę
dzi
znajduj
ą
cych ró
ż
nice w plikach. Dla r
ę
cznego testowania oczekiwanym wyj
ś
ciem
mog
ą
by
ć
to opisy zawarte w procedurach testowych. Przygotowywanie
oczekiwanego wyj
ś
cia dla zautomatyzowanego porównywania mo
ż
e by
ć
o wiele
bardziej skomplikowane ni
ż
wariant dla r
ę
cznego testowania w postaci notatek.
27
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (27)
Czynno
ś
ci w ramach testowania
1. Identyfikacja warunków testu
2. Zaprojektowanie przypadków testowych
3. Zbudowanie przypadków testowych
4. Uruchomienie przypadków testowych
5. Porównanie uzyskanych wyników
z oczekiwanymi
Po zbudowaniu przypadku testowego w postaci procedur testowych
dla r
ę
cznego testowania lub te
ż
skryptów w przypadku zautomatyzowanej wersji
przeprowadzane jest jego wykonanie. Dla wariantu przeprowadzanego r
ę
cznie
polega to na wykonaniu krok po kroku procedury testowej przez testera. Klika on
na wybranych ikonach, czy te
ż
wprowadza dane zgodnie z opisem procedury
testowej. W przypadku zautomatyzowanego podej
ś
cia skrypty wykonywane s
ą
przez narz
ę
dzie słu
żą
ce do testowania. Wykonanie testu mo
ż
e odby
ć
si
ę
tylko w
przypadku gdy testowana aplikacja istnieje. Wcze
ś
niejsze czynno
ś
ci zwi
ą
zane z
testowaniem mo
ż
na wykona
ć
zanim zaimplementowany jest testowany system.
28
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (28)
Czynno
ś
ci w ramach testowania
1. Identyfikacja warunków testu
2. Zaprojektowanie przypadków testowych
3. Zbudowanie przypadków testowych
4. Uruchomienie przypadków testowych
5. Porównanie uzyskanych wyników
z oczekiwanymi
Ostatni
ą
czynno
ś
ci
ą
jest porównanie uzyskanego wyj
ś
cia z
oczekiwanym. Mo
ż
e si
ę
to odbywa
ć
w sposób nieformalny przez testera, który
sprawdza czy to co uzyskał zgadza si
ę
z tym czego oczekiwał, lub te
ż
w sposób
rygorystyczny przez sprawdzenie zaobserwowanego wyj
ś
cia z opisem zawartym
w procedurze testowej. Porównanie cz
ęś
ci wyników mo
ż
e odbywa
ć
si
ę
w trakcie
wykonywania testów jak np. sprawdzenie czy pojawił si
ę
komunikat prosz
ą
cy o
potwierdzenie podczas wykonywania przypadku testowego sprawdzaj
ą
cego czy
mo
ż
na wykona
ć
przelew o warto
ś
ci ujemnej. W innym przypadku gdy np. chcemy
sprawdzi
ć
czy zawarto
ść
bazy danych uległa zmianie mo
ż
e okaza
ć
si
ę
konieczne
zaczekanie do ko
ń
ca wykonywania wariantu testu.
W najprostszym przypadku porównanie polega na sprawdzeniu czy
uzyskane wyj
ś
cie jest takie same jak oczekiwane. Je
ś
li s
ą
identyczne to
przypadek testowy nie wykrył bł
ę
du. Jest to oczywi
ś
cie najprostszy wariant.
Faktyczne dane mog
ą
nie by
ć
identyczne, ale podobne do tych oczekiwanych.
Mo
ż
na powiedzie
ć
,
ż
e porównanie polega na okre
ś
leniu czy faktyczne wyj
ś
cie
pasuje (ang. match) do oczekiwanego wyj
ś
cia. Narz
ę
dzia automatyzuj
ą
ce t
ę
czynno
ść
dokonuj
ą
tylko porównania a nie weryfikacji. W zwi
ą
zku z tym s
ą
w
stanie wykry
ć
tylko ró
ż
nice. Zadaniem testera jest weryfikacja, czy w przypadku
gdy wykryto niezgodno
ść
wyj
ść
jest to akceptowalne, czy te
ż
powoduje,
ż
e test
nie przeszedł.
29
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (29)
Czynno
ś
ci w ramach testowania
1. Identyfikacja warunków testu
2. Zaprojektowanie przypadków testowych
3. Zbudowanie przypadków testowych
4. Uruchomienie przypadków testowych
5. Porównanie uzyskanych wyników
z oczekiwanymi
Pierwsze dwie aktywno
ś
ci jakimi s
ą
: identyfikacja warunków testu,
oraz zaprojektowanie przypadków testowych, wymagaj
ą
pracy twórczej. To od
nich zale
ż
y jako
ść
testów. Niestety trudno poddaj
ą
si
ę
automatyzacji. Ponadto na
ogół wykonywane s
ą
tylko raz na pocz
ą
tku nie uwzgl
ę
dniaj
ą
c oczywi
ś
cie
przypadków, w których popełniono bł
ą
d na etapie projektowania testów.
Natomiast uruchomienie przypadków testowych oraz porównanie oczekiwanego
wyj
ś
cia z faktycznym to typowo odtwórcze czynno
ś
ci, które wymagaj
ą
ce sporo
wysiłku. Powtarzane s
ą
one wiele razy w przeciwie
ń
stwie do projektowania, które
wykonywane jest tylko raz na pocz
ą
tku.
30
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (30)
Kandydaci do automatyzacji
Czynno
ś
ci w ramach testowania
1. Identyfikacja warunków testu
2. Zaprojektowanie przypadków testowych
3. Zbudowanie przypadków testowych
4. Uruchomienie przypadków testowych
5. Porównanie uzyskanych wyników
z oczekiwanymi
W zwi
ą
zku z tym ostatnie dwie czynno
ś
ci idealnie nadaj
ą
si
ę
do
automatyzacji. Na nast
ę
pnych slajdach zostan
ą
omówione krótko sposoby
automatyzacji ka
ż
dej z nich.
31
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (31)
Automatyzacja projektowania wariantów testu
• Na ogół s
ą
to generatory danych wej
ś
ciowych
• Generuj
ą
du
żą
liczb
ę
testów
• Nie zidentyfikuj
ą
brakuj
ą
cych wymaga
ń
Wspomaganie automatyzacji projektowania przypadków testowych
opiera si
ę
na narz
ę
dziach, które najcz
ęś
ciej automatycznie generuj
ą
tylko dane
wej
ś
ciowe do testów. Nawet w przypadku narz
ę
dzi, które w stanie s
ą
poda
ć
tak
ż
e oczekiwane wyj
ś
cia nie mo
ż
na oczekiwa
ć
cudownych wyników. Nie
zast
ą
pi
ą
one czynno
ś
ci twórczych zwi
ą
zanych z projektowaniem przypadków
testowych, do których najlepiej nadaje si
ę
tester. Najwi
ę
kszym problemem
zwi
ą
zanym z wykorzystaniem tych narz
ę
dzi to fakt,
ż
e generuj
ą
du
żą
liczb
ę
testów. Nie potrafi
ą
rozró
ż
ni
ć
, które z nich s
ą
wa
ż
ne, co cz
ę
sto skutkuje
wytworzeniem du
ż
ej liczby mało istotnych testów. Cz
ęść
z tych narz
ę
dzi ma
wbudowane algorytmy do minimalizacji ich liczby według kryteriów zadanych
przez testera, co mimo wszystko w efekcie daje nadal zbyt wiele testów. W
zwi
ą
zku z tym nale
ż
y korzysta
ć
z rozwag
ą
z tego typu rozwi
ą
za
ń
. Kolejn
ą
powa
ż
n
ą
wad
ą
tych narz
ę
dzi jest fakt,
ż
e nie wykryj
ą
brakuj
ą
cych aspektów lub
wymaga
ń
, ani te
ż
ich złej specyfikacji. To domena testerów, którzy posiadaj
ą
wiedz
ę
dziedzinow
ą
i potrafi
ą
okre
ś
li
ć
kiedy dana powinno
ść
jest nie
wyspecyfikowana lub
ź
le zdefiniowana.
Narz
ę
dzia te generuj
ą
dane wej
ś
ciowe na podstawie trzech
artefaktów: kodu aplikacji, na podstawie interfejsu u
ż
ytkownika, oraz
wykorzystuj
ą
c specyfikacj
ę
systemu.
32
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (32)
Automaty oparte na kodzie aplikacji
• Generuje dane wej
ś
ciowe
• Nie wygeneruje oczekiwanego wyj
ś
cia
• Nie zidentyfikuje brakuj
ą
cych wymaga
ń
if (a > 0) ...
else ...
Wygenerowane dane
wej
ś
ciowe dla a:
0, 1, 1000, -2
Generowanie danych testowych na podstawie kodu aplikacji oparte
jest na analizie struktury kodu programu. Narz
ę
dzia znajduj
ą
instrukcje
warunkowe i staraj
ą
si
ę
okre
ś
li
ć
dla jakich wej
ść
poszczególne gał
ę
zie s
ą
wykonywane.
To podej
ś
cie jest niekompletne gdy
ż
w ten sposób generowane s
ą
tylko dane wej
ś
ciowe, a test potrzebuje jeszcze oczekiwanego wyj
ś
cia. Tego nie
uzyska si
ę
na podstawie analizy kodu aplikacji. T
ą
informacj
ę
mo
ż
na znale
źć
w
specyfikacji wymaga
ń
. Nie uda si
ę
tak
ż
e wykry
ć
tym sposobem złych lub
brakuj
ą
cych wymaga
ń
.
33
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (33)
Automaty oparte na interfejsie u
ż
ytkownika
• Generuje dane wej
ś
ciowe
• Oczekiwane wyj
ś
cie jest cz
ęś
ciowo generowane
•Sprawd
ź
czy dla ka
ż
dej kontrolki istnieje funkcja pomocy
•Sprawd
ź
czy mo
ż
na edytowa
ć
pola tylko do odczytu
•Sprawd
ż
wszystkie linki na stronie www
Kolejnym podej
ś
ciem jest generowanie testów na podstawie
interfejsu u
ż
ytkownika. Generatory potrafi
ą
analizowa
ć
interfejs okienkowy
jak równie
ż
kod html je
ś
li testowana aplikacja oparta jest na stronach
www. Narz
ę
dzie takie identyfikuje kontrolki i nast
ę
pnie sprawdza czy dla
ka
ż
dej z nich istnieje funkcja pomocy. Innym przykładem testu jaki mo
ż
e
by
ć
wygenerowany jest sprawdzenie czy mo
ż
na edytowa
ć
pola
przeznaczone tylko do odczytu. Dla stron www narz
ę
dzie sprawdza
wszystkie hiperł
ą
cza wyst
ę
puj
ą
ce na stronie. W ten sposób jest w stanie
zweryfikowa
ć
czy który
ś
z nich prowadzi do nieistniej
ą
cej strony. Nie jest
oczywi
ś
cie w stanie sprawdzi
ć
czy prowadzi do dobrej strony.
Przy pomocy tego podej
ś
cia mo
ż
na wygenerowa
ć
dane wej
ś
ciowe i
cz
ęś
ciowo oczekiwane wyj
ś
cie w do
ść
ogólnym i negatywnym sensie. Dla
wcze
ś
niejszego przykładu hiperł
ą
cz na stronie mo
ż
liwe jest
wygenerowanie sprawdzenia czy hiperł
ą
cze istnieje (co daje prawidłowy
wynik) oraz czy prowadzi do nieistniej
ą
cej strony (nieprawidłowy wynik).
Sama informacja,
ż
e test przechodzi nie gwarantuje,
ż
e podane hiperł
ą
cze
jest prawidłowe, natomiast je
ś
li test wykryje martwe ł
ą
cze to jest to
informacja o bł
ę
dzie.
34
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (34)
Automaty oparte na specyfikacji
• Specyfikacja musi by
ć
w formie mo
ż
liwej do
analizy przez automat
• Generuje dane wej
ś
ciowe
• Czasem generuje oczekiwane wyj
ś
cie
/**
* @pre arg2 != 0
*/
void show(int arg1, double arg2);
Tworzenie testów w oparciu o specyfikacj
ę
daje mo
ż
liwo
ść
wygenerowania zarówno danych wej
ś
ciowych jak równie
ż
tak
ż
e oczekiwanego
wyj
ś
cia. Warunkiem jest odpowiednia specyfikacja opisuj
ą
ca działanie systemu.
Musi by
ć
stworzona w formie mo
ż
liwej do automatycznej analizy przez generator.
Najcz
ęś
ciej jednak narz
ę
dzia potrafi
ą
tylko generowa
ć
dane wej
ś
ciowe, rzadziej
zdarza si
ę
by mo
ż
liwe było wygenerowanie oczekiwanego wyj
ś
cia. W powy
ż
szym
przykładzie narz
ę
dzie na podstawie specyfikacji zawartej w kodzie programu jest
w stanie wygenerowa
ć
wariant testu sprawdzaj
ą
cy zachowanie aplikacji dla
przypadku kiedy warto
ść
argumentu wyniesie 0. Oczywi
ś
cie specyfikacja nie
musi by
ć
zapisywana tylko i wył
ą
cznie w kodzie programu. Mo
ż
e to by
ć
dokument tekstowy, który zawiera tak
ż
e oczekiwane wyj
ś
cie.
35
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (35)
Automatyzacja porównywania wyników
• Przewid
ź
oczekiwane wyj
ś
cie
• Reference testing
– Oczekiwanym wyj
ś
ciem jest wyj
ś
cie zaobserwowane
przy pierwszym wykonaniu testu
• Co powinno by
ć
porównywane?
• Zautomatyzowane porównanie mo
ż
e ukry
ć
bł
ą
d
(je
ś
li jest bł
ą
d w oczekiwanym wyj
ś
ciu)
Dla ka
ż
dego testu okre
ś
lane jest oczekiwane wyj
ś
cie. Najlepszym
rozwi
ą
zaniem jest sprecyzowanie zawczasu jak ma si
ę
zachowywa
ć
system.
Je
ś
li nie jest ono wyspecyfikowane zanim przypadek testowy zostanie wykonany,
wtedy w celu sprawdzenia czy program działa prawidłowo faktyczne wyj
ś
cie
uzyskane z pierwszego wykonania wariantu testu staje si
ę
oczekiwanym
wyj
ś
ciem, oczywi
ś
cie po uprzednim dokładnym przeanalizowaniu go przez
testera. To wymaga wiedzy dziedzinowej od osoby weryfikuj
ą
cej faktyczne
wyj
ś
cie. Podej
ś
cie, w którym wynik pierwszego wykonania testu jest uznawany
za oczekiwane wyj
ś
cie nazywa si
ę
testowaniem referencyjnym (ang. reference
testing).
Problemem podczas specyfikacji oczekiwanego wyj
ś
cia jest
zdecydowanie co ma by
ć
ze sob
ą
porównane. Je
ś
li wybranych zostanie niewiele
elementów to mo
ż
e okaza
ć
si
ę
,
ż
e wybrano zbyt ogólne oczekiwane wyj
ś
cie.
Spowoduje, to
ż
e bł
ą
d mo
ż
e zosta
ć
nie wykryty, poniewa
ż
porównywane dane
wyj
ś
ciowe nie b
ę
d
ą
zawierały informacji o bł
ę
dnym zachowaniu. Zbyt
szczegółowe wyj
ś
cie z kolei spowoduje,
ż
e test automatyczny b
ę
dzie trudniejszy
do zmodyfikowania oraz bardziej skomplikowany co zwi
ę
ksza ryzyko wyst
ą
pienia
bł
ę
du w takim wariancie.
36
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (36)
Proste porównania
Oczekiwane wyj
ś
cie = faktyczne wyj
ś
cie
Faktura nr F1234/2003
Data: 20-CZE-2003
---------
Lp. | Symbol | Nazwa | Cena |
-----------------------------
1 | P11 | Pióro | 12.50
2 | K32 | Kreda | 3.20
-----------------------------
Razem: 15.70
Płatne do: 30-CZE-2003
Faktura nr F1234/2005
Data: 10-WRZ-2005
---------
Lp. | Symbol | Nazwa | Cena |
-----------------------------
1 | P11 | Pióro | 12.50
-----------------------------
Razem: 12.50
Płatne do: 30-WRZ-2005
Najprostsz
ą
metod
ą
porówna
ń
dost
ę
pn
ą
w narz
ę
dziach
automatyzuj
ą
cych wykonanie testów jest tzw. proste porównanie. Dzi
ę
ki tej
metodzie faktyczne wyj
ś
cie uznawane jest za pasuj
ą
ce do oczekiwanego wyj
ś
cia
tylko w przypadku je
ś
li s
ą
one identyczne. Nie mo
ż
e by
ć
ró
ż
nic mi
ę
dzy tym co
zaobserwowano w wyniku wykonania programu, a tym jak program powinien si
ę
zachowywa
ć
. W przeciwnym przypadku zgłoszone zostan
ą
ró
ż
nice i test nie
powiedzie si
ę
.
Je
ś
li wariant testu miałby sprawdzi
ć
czy generowane przez program
faktury maj
ą
prawidłowy układ, nale
ż
ałoby uprzednio przygotowa
ć
jako
oczekiwane wyj
ś
cie faktur
ę
zawieraj
ą
c
ą
te same dane, które b
ę
d
ą
podane w
ramach testu. W przeciwnym wypadku nawet je
ś
li program generuje faktury o
prawidłowej budowie test nie powiedzie si
ę
ze wzgl
ę
du na ró
ż
nic
ę
w podanych
danych.
Innym rozwi
ą
zaniem s
ą
zło
ż
one porównania polegaj
ą
ce na pomini
ę
ciu informacji
szczegółowych dotycz
ą
cych niektórych pól faktury. Na rynku jest kilka narz
ę
dzi, które posiadaj
ą
tak
ą
funkcjonalno
ść
. Podawane s
ą
pola, które maj
ą
by
ć
pomini
ę
te, lub dla których ma by
ć
wykonane
sprawdzenie typu. Je
ś
li np. pole z dat
ą
posiada nieprawidłowy format to zgłaszany jest bł
ą
d. Nie jest
dokonywane sprawdzenie czy data jest identyczna z t
ą
podan
ą
w oczekiwanym wyj
ś
ciu. Brak zło
ż
onych
porówna
ń
nie przekre
ś
la przydatno
ś
ci narz
ę
dzia. Mo
ż
na w do
ść
prosty sposób zaimplementowa
ć
sobie tak
ą
funkcjonalno
ść
.
37
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (37)
Filtry do porówna
ń
Oczekiwane
Zaobserwowane
Przefiltrowane
oczekiwane
Przefiltrowane
zaobserwowane
Filtr
Filtr
Porównanie
Różnice
Praktycznie stosowanym rozwi
ą
zaniem dla problemu, w którym nie
mo
ż
na zastosowa
ć
zło
ż
onych porówna
ń
(np. u
ż
ywane narz
ę
dzie nie wspiera tej
metody) jest zastosowanie filtrów. Zasada działania jest nast
ę
puj
ą
ca. Zanim
zaobserwowane wyj
ś
cie jest porównane z oczekiwanym, oba wyj
ś
cia przechodz
ą
przez filtr, którego zadaniem jest usuni
ę
cie niepotrzebnych informacji. Po ich
odfiltrowaniu nast
ę
puje porównanie ze sob
ą
wyj
ść
przy pomocy metody prostego
porównania.
Oczywi
ś
cie filtr mo
ż
e si
ę
okaza
ć
tak naprawd
ę
ła
ń
cuchem filtrów,
gdzie ka
ż
dy z nich usuwa pojedyncz
ą
informacj
ę
z danych, które maj
ą
by
ć
porównane. Oprócz usuwania filtr mo
ż
e tak
ż
e sortowa
ć
dane lub dokonywa
ć
ich
zamiany na inn
ą
posta
ć
.
38
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (38)
Filtry do porówna
ń
– c.d.
Faktura nr F1234/2003
Data: 20-CZE-2006
Lp. | Symbol | Nazwa | Cena |
-----------------------------
1
| K32 | Kreda | 3.20
-----------------------------
Razem: 3.20
Filtr
Faktura nr F1235/2003
Data: 20-LIP-2006
Lp. | Symbol | Nazwa | Cena |
-----------------------------
1
| P11 | Pióro | 12.50
-----------------------------
Razem: 12.50
Porównanie
Faktura nr <nr>/<rok>
Data: <data>
Lp. | Symbol | Nazwa | Cena |
-----------------------------
<lp>|<symbol>|<nazwa>|<cena>
-----------------------------
Razem: <cena>
Faktura nr <nr>/<rok>
Data: <data>
Lp. | Symbol | Nazwa | Cena |
-----------------------------
<lp>|<symbol>|<nazwa>|<cena>
-----------------------------
Razem: <cena>
Brak różnic
Dla przykładu z faktur
ą
zarówno oczekiwane wyj
ś
cie jak i
zaobserwowane przepuszczono przez zestaw filtrów. Ka
ż
dy z nich odfiltrowywał
jeden rodzaj pola z dokumentów. Zastosowano filtry odpowiedzialne za wyci
ę
cie
dat, numerów faktur, symboli, nazw oraz cen towarów. W wyniku uzyskano
szablony faktur, które nast
ę
pnie porównano ze sob
ą
przy pomocy prostego
porównania.
39
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (39)
Filtry do porówna
ń
– wady i zalety
Zalety:
• Reu
ż
ywalno
ść
filtrów
• Praca tylko nad wybranymi fragmentami wyj
ś
cia
• Łatwiejsza implementacja testu
• Mo
ż
liwo
ść
stosowania prostych porówna
ń
Wady:
• Wymaga umiej
ę
tno
ś
ci programistycznych
• Wymagana jest piel
ę
gnacja filtrów
• Konieczno
ść
stworzenia dokumentacji
Niew
ą
tpliw
ą
zalet
ą
płyn
ą
c
ą
ze stosowania filtrów jest mo
ż
liwo
ść
pracy tylko nad wybranymi fragmentami wyj
ś
cia. Dla przykładu z faktur
ą
porównywany był tylko jej układ. Filtry usun
ę
ły szczegółowe informacje dot. nr
faktury oraz zakupionych towarów.
Dobrze zaimplementowane filtry mo
ż
na ponownie wykorzysta
ć
.
Usuwanie wybranych typów danych mo
ż
e by
ć
wielokrotnie u
ż
yte przy okazji
innych testów.
Poniewa
ż
ka
ż
dy filtr wykonuje prost
ą
czynno
ść
implementacja ich
nie powinna nastr
ę
czy
ć
wi
ę
kszych problemów. Zło
ż
one porównanie jest
podzielone na wiele małych kroków, co tak
ż
e ułatwia automatyzacj
ę
testu gdy
ż
mo
ż
na zastosowa
ć
proste porównanie.
Niestety stworzenie filtrów wymaga umiej
ę
tno
ś
ci
programistycznych. Na szcz
ęś
cie raz stworzone filtry mo
ż
na ponownie
wykorzysta
ć
. Kolejn
ą
wad
ą
mo
ż
e by
ć
konieczno
ść
ich modyfikacji w przypadku
gdy format wyj
ś
cia ulegnie zmianie.
By filtry mogły by
ć
ponownie wykorzystane musz
ą
by
ć
dobrze
udokumentowane. Inaczej nie b
ę
dzie wiadomo w jaki sposób mo
ż
na ich u
ż
y
ć
.
40
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (40)
Automatyzacja pre- /post-processing
• Pre-processing
– Ustawia stan systemu niezb
ę
dny do wykonania
wariantu testu
– Wiele wariantów ma ustawia ten sam stan
– Warto zautomatyzowa
ć
i reu
ż
ywa
ć
• Post-processing
– „Sprz
ą
ta” po wykonaniu wariantu testu
– Wiele wariantów „sprz
ą
ta” w ten sam sposób
– Warto zautomatyzowa
ć
i reu
ż
ywa
ć
Przed wykonaniem wariantu testu konieczne jest ustawienie
systemu w odpowiedni stan wyspecyfikowany w przypadku testowym. Angielska
nazwa tej fazy to pre-processing. Do przykładów zaliczy
ć
mo
ż
na dodawanie
krotek do bazy danych, które s
ą
niezb
ę
dne do wykonania testu, logowanie
u
ż
ytkownika w systemie itp. Przed wykonaniem ka
ż
dego przypadku testowego
uruchamiany jest pre-processing. Ró
ż
ne warianty testów maj
ą
ró
ż
ne stany do
ustawienia. Cz
ę
sto jednak zdarza si
ę
,
ż
e wiele przypadków testowych wymaga
ustawienia systemu w ten sam stan. Warto, wi
ę
c zautomatyzowa
ć
t
ę
czynno
ść
, a
powstały w ten sposób skrypt (czy te
ż
program) wykorzystywa
ć
ponownie w
ramach tych przypadków testowych, które wymagaj
ą
ustawienia tego samego
stanu systemu.
Po wykonaniu ka
ż
dego wariantu testu wykonywany jest post-
processing, w ramach którego przywracany jest stan systemu sprzed wykonania
testu. Mo
ż
na powiedzie
ć
,
ż
e wykonywane jest „sprz
ą
tanie” po testowaniu.
Podobnie jak w przypadku pre-processing’u wiele wariantów testu sprz
ą
ta w
podobny sposób czyni
ą
c t
ę
czynno
ść
wart
ą
automatyzacji i do ponownego
wykorzystania.
41
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (41)
Automatyzacja – wykonanie testów
Biblioteka JUnit
• Wykonuje testy
automatycznie
• Pokazuje przebieg
wykonania
testów
• Proste
porównania
• Wsparcie dla pre-
/post-processing
• Integracja z IDE
Przedstawione wcze
ś
niej poj
ę
cia zwi
ą
zane z automatyzacj
ą
wykonywania testów skonfrontuj
ę
teraz z popularn
ą
bibliotek
ą
JUnit 3.8.x słu
żą
c
ą
do tworzenia automatycznych przypadków testowych. W chwili tworzenia
wykładu dost
ę
pna jest testowa wersja 4.x tej biblioteki. Jednak ze wzgl
ę
du na
brak dokumentacji do niej oraz fakt,
ż
e mo
ż
na j
ą
wykorzysta
ć
tylko z wersj
ą
j
ę
zyka Java 1.5 nie b
ę
dzie omówiona w ramach tego wykładu. Zainteresowani
mog
ą
znale
źć
dodatkowe informacje na stronie http://www.junit.org/ .
Rodzina bibliotek xUnit dost
ę
pna jest na wiele platform
programistycznych i dla wielu ró
ż
nych j
ę
zyków programowania. JUnit to wariant
biblioteki przeznaczony dla j
ę
zyka Java. Z jego pomoc
ą
uprzednio
zaimplementowane testy mog
ą
by
ć
automatycznie uruchamiane. Biblioteka ta
udost
ę
pnia tak
ż
e szereg klas i metod ułatwiaj
ą
cych tworzenie automatycznych
testów. Mi
ę
dzy innymi implementuje szereg asercji słu
żą
cych do porówna
ń
oczekiwanego wyj
ś
cia z faktycznie zaobserwowanym. S
ą
to tzw. proste
porównania. Nale
ż
y wi
ę
c pami
ę
ta
ć
o konieczno
ś
ci stosowania filtrów w
przypadkach kiedy chcemy usun
ąć
pewne informacje z oczekiwanego i
zaobserwowanego wyj
ś
cia. Ponadto biblioteka wspiera automatyczne
wykonywanie pre- oraz post-processing’u.
42
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (42)
Automatyzacja – wykonanie testów
Biblioteka JUnit
• Wykonuje testy
automatycznie
• Pokazuje przebieg
wykonania
testów
• Proste
porównania
• Wsparcie dla pre-
/post-processing
• Integracja z IDE
Po wykonaniu testów u
ż
ytkownikowi prezentowane s
ą
wyniki ich
wykonania w postaci listy wariantów, które si
ę
nie powiodły wraz z dodatkow
ą
informacj
ą
o przyczynach ich niepowodzenia. Biblioteka oferuje kilka ró
ż
nych
interfejsów u
ż
ytkownika m. in. interfejs tekstowy jak równie
ż
interfejs graficzny
zaprezentowany na powy
ż
szym slajdzie. Oprócz tego w wielu popularnych
ś
rodowiskach programistycznych do j
ę
zyka Java interfejs u
ż
ytkownika biblioteki
jest zintegrowany z interfejsem IDE co
ś
wiadczy o du
ż
ej popularno
ś
ci biblioteki
JUnit.
43
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (43)
Architektura JUnit 3.x
Test
TestResult
TestCase
TestSuite
MoneyTestCase
TestFailure
TestListener
BaseTestRunner
junit.textui.
TestRunner
Biblioteka składa si
ę
z wielu klas i interfejsów jednak omówione
zostan
ą
tylko najwa
ż
niejsze z nich. Klas
ą
bazow
ą
dla wszystkich przypadków
testowych jest klasa TestCase. W zamy
ś
le autorów klasa miała reprezentowa
ć
pojedynczy przypadek testowy. Cho
ć
jest to oczywi
ś
cie mo
ż
liwe, w praktyce w
ramach tej klasy umieszcza si
ę
zbiór przypadków testowych, które maj
ą
te same
metody do pre- i post- processing. Klasa TestCase udost
ę
pnia metody słu
żą
ce
do prostych porówna
ń
, zwane asercjami, o których mowa b
ę
dzie w dalszej cz
ęś
ci
wykładu.
Klasy reprezentuj
ą
ce przypadki testowe mog
ą
by
ć
grupowane w
zbiory wariantów testowych reprezentowane przez klas
ę
TestSuite. Dzi
ę
ki temu
mo
ż
liwe jest utworzenie hierarchii drzewiastej testów, co daje ich lepsze
uporz
ą
dkowanie i łatwiejsze zarz
ą
dzanie nimi. Jak wida
ć
na powy
ż
szym
diagramie zbiór przypadków testowych mo
ż
e zawiera
ć
tak
ż
e inny zbiór wariantów
testów.
Wyniki wykonania testów przechowywane s
ą
w obiekcie klasy
TestResult. Pojedynczy bł
ą
d reprezentowany jest przez obiekt klasy TestFailure.
Istnieje wiele dodatków do biblioteki JUnit umo
ż
liwiaj
ą
cych prezentowanie
wyników testów w wielu ró
ż
nych formatach m. in. pdf, html. Z tej mo
ż
liwo
ś
ci
korzystaj
ą
równie
ż
ś
rodowiska programistyczne (IDE) dopisuj
ą
c własne
rozszerzenia integruj
ą
ce bibliotek
ę
ze swoimi interfejsami.
44
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (44)
Architektura JUnit 3.x
Test
TestResult
TestCase
TestSuite
MoneyTestCase
TestFailure
TestListener
BaseTestRunner
junit.textui.
TestRunner
Kolejnym wa
ż
nym komponentem tej biblioteki jest obiekt klasy
TestRunner. Jego zadaniem jest wykonanie przypadków testowych. Biblioteka
udost
ę
pnia wiele klas pochodnych TestRunner. Umo
ż
liwiaj
ą
one korzystanie z
biblioteki w trybie tekstowym jak równie
ż
i graficznym. Nie trzeba chyba mówi
ć
,
ż
e
ś
rodowiska programistyczne udost
ę
pniaj
ą
swoje własne rozszerzenia, które
integruj
ą
JUnit z IDE.
45
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (45)
TestCase – idea działania
...
protected void setUp()
public void testXXX()
protected void tearDown()
protected void setUp()
public void testYYY()
protected void tearDown()
Wariant testu ma pewn
ą
struktur
ę
. Pojedynczy przypadek testowy
reprezentowany jest przez klas
ę
TestCase. W praktyce jednak obiekt tej klasy
grupuje te warianty testów, dla których wykonywane s
ą
te same metody pre- jak i
post-processing. Pojedynczy przypadek testowy prezentowany jest przez metod
ę
rozpoczynaj
ą
c
ą
si
ę
od nazwy „test”. Metoda pre-processing powinna by
ć
zaimplementowana w metodzie setUp, a post-processing w metodzie tearDown.
Warianty testu wykonywane s
ą
nast
ę
puj
ą
co. Najpierw uruchamiana
jest metoda setUp. Nast
ę
pnie wykonywany jest jeden przypadek testowy przez
uruchomienie metody rozpoczynaj
ą
cej si
ę
od słowa „test”, po czym sterowanie
przechodzi do metody tearDown, która odpowiada za post-processing. Je
ś
li w
klasie zaimplementowano wi
ę
cej ni
ż
jeden wariant testu (wyst
ę
puje wi
ę
cej metod
publicznych rozpoczynaj
ą
cych si
ę
od słowa „test”) to ponownie wykonywana jest
metoda setUp, nast
ę
pnie kolejna metoda rozpoczynaj
ą
ca si
ę
od słowa „test”, i
ponownie tearDown.
46
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (46)
Proste porównania w klasie TestCase
• void assertEquals([msg], oczekiwane, faktyczne)
• void assert[Not]Same([msg], oczekiwane,
faktyczne)
• void assertTrue([msg], warunek)
• void assertFalse([msg], warunek)
• void assertNull([msg], obiekt)
• void assertNotNull([msg], obiekt)
• void fail([msg])
Klasa TestCase posiada wiele metod słu
ż
acych do prostych
porówna
ń
zwanych asercjami. Dzi
ę
ki nim mo
ż
na łatwo zweryfikowa
ć
relacje
mi
ę
dzy oczekiwanym wyj
ś
ciem a faktycznym. Asercje te s
ą
metodami
polimorficznymi maj
ą
cymi postacie dla wielu typów danych w j
ę
zyku Java. Ka
ż
da
z asercji posiada wariant, dla którego istnieje mo
ż
liwo
ść
podania komunikatu
wy
ś
wietlanego gdy wykryte zostan
ą
ró
ż
nice pomi
ę
dzy wyj
ś
ciem oczekiwanym a
zaobserwowanym. Oczywi
ś
cie jest to parametr opcjonalny i mo
ż
e by
ć
pomini
ę
ty.
Asercje składaj
ą
si
ę
z nast
ę
puj
ą
cych grup metod:
•assertEquals – sprawdza czy obiekty s
ą
to
ż
same (lub warto
ś
ci liczbowe s
ą
równe). W przypadku liczb zmiennoprzecinkowych wymagane jest jeszcze
podanie przedziału, dla którego liczba uznawana jest za to
ż
sam
ą
. Dla liczb
porównanie odbywa si
ę
z wykorzystaniem operatora ==, natomiast obiekty
porównywane s
ą
przez wywołanie metody equals.
•assertSame – sprawdza identyczno
ść
obu parametrów, czyli dla ka
ż
dego
przypadku stosuje operator ==.
•assertNotSame – analogicznie co dla assertSame, z tym
ż
e odwrotnie –
sprawdza czy podane obiekty to ró
ż
ne instancje (wykorzystuje operator !=).
•assertTrue – bada prawdziwo
ść
podanego warunku
•assertFalse – bada fałszywo
ść
podanego warunku
•assertNull – sprawdza czy argument jest warto
ś
ci
ą
null
•assertNotNull – weryfikuje czy argument jest obiektem ró
ż
nym od null
•fail – powoduje bezwarunkowe zgłoszenie nieprawdziwo
ś
ci asercji.
47
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (47)
TestCase – przykład
class Pieniadze {
private int kwota;
public Pieniadze(int kwota) {
if (kwota < 0) throw new Exception(„kwota < 0”);
this.kwota = kwota;
}
public boolean equals(Object obj) {
return ((Pieniadze) obj).kwota == kwota;
}
public Pieniadze dodaj(Pieniadze p) {
return new Pieniadze(kwota + p.kwota);
}
public Pieniadze odejmij(Pieniadze p) {
return new Pieniadze(kwota - p.kwota);
}
}
Na dwóch kolejnych slajdach przedstawiony zostanie przykład
implementacji wariantów testuj
ą
cych klas
ę
Pieniadze. Klasa ta reprezentuje
kwot
ę
pieni
ęż
n
ą
i udost
ę
pnia dwie metody: dodawania i odejmowania obiektów
klasy Pieni
ą
dze. Wynikiem ich wykonania s
ą
obiekty klasy Pieni
ą
dze.
Udost
ę
pniana jest równie
ż
metoda equals, która podaje czy dany obiekt jest
to
ż
samy obiektowi klasy Pieni
ą
dze. Obiekty uznawane s
ą
za to
ż
same je
ś
li
reprezentuj
ą
t
ą
sam
ą
kwot
ę
pieni
ęż
n
ą
.
48
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (48)
TestCase – przykład
public class PieniadzeTest extends TestCase {
private Pieniadze pieniadze;
public PieniadzeTest(String nazwa) { super(nazwa); }
protected void setUp() throws Exception {
pieniadze = new Pieniadze(4);
}
protected tearDown() throws Exception {
pieniadze = null;
}
public void testDodaj() {
assertEquals(pieniadze.dodaj(8), new Pieniadze(12));
}
public void testOdejmij() {
assertEquals(pieniadze.odejmij(3), new Pieniadze(1));
}
}
Dla klasy Pieni
ą
dze przygotowano dwa warianty testów po jednym
dla ka
ż
dej z metod: testDodaj oraz testOdejmij. Metoda setUp przygotowuje
obiekt do testów. Jak wida
ć
przygotowanie to polega na utworzeniu instancji
klasy. Metoda tearDown implementuje post-processing, czyli „sprz
ą
tanie” po
testach. Jak wida
ć
zwalniana jest pami
ęć
przydzielona dla obiektu klasy
Pieni
ą
dze, a dokładniej Garbage Collector dostaje informacj
ę
,
ż
e obiekt klasy
Pieni
ą
dze nie jest ju
ż
wykorzystywany i mo
ż
na zwolni
ć
pami
ęć
przez niego
zajmowan
ą
.
Metoda testDodaj implementuje wariant testu sprawdzaj
ą
cy
działanie metody dodaj w klasie Pieni
ą
dze. Wykonywane jest proste porównanie
polegaj
ą
ce na sprawdzeniu czy w wyniku dodawania dwóch kwot pieni
ęż
nych 4
oraz 8 uzyska si
ę
w wyniku obiekt klasy Pieni
ą
dze o warto
ś
ci 12.
Analogicznie zaimplementowany jest przypadek dla odejmowania –
metoda testOdejmij. Tutaj sprawdzane jest czy w wyniku odejmowania 4 od 3
otrzyma si
ę
obiekt klasy Pieniadze o warto
ś
ci 1.
49
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (49)
TestCase – przykład
protected void setUp()
public void testDodaj()
protected void tearDown()
protected void setUp()
public void testOdejmij()
protected void tearDown()
Wykonanie przez obiekt klasy TestRunner wariantów testów
zaimplementowanych w klasie PieniadzeTest obrazuje powy
ż
szy slajd. Najpierw
wykonywana jest metoda setUp ustawiaj
ą
ca obiekt klasy Pieni
ą
dze na kwot
ę
4.
Nast
ę
pnie wykonywany jest pierwszy przypadek testowy zaimplementowany w
metodzie testDodaj. Po wykonaniu przypadku testowego wykonywana jest
metoda tearDown, która „sprz
ą
ta” po testach. Poniewa
ż
w klasie s
ą
dwie metody
„test” uruchamiana jest ponownie metoda setUp przygotowuj
ą
ca obiekt klasy
Pieni
ą
dze dla drugiego wariantu testu. Wykonywany jest nast
ę
pnie przypadek
testowy przez wywołanie metody testOdejmij. Na koniec ponowne wywołanie
metody tearDown „sprz
ą
ta” system po testach.
50
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (50)
Tworzenie zbiorów przypadków testowych
Statyczne
TestCase t=new PieniadzeTest(„testy dla dodaj"){
public void runTest() {
testDodaj();
}
}
public static Test suite() {
TestSuite suite = new TestSuite();
suite.addTest(new PieniadzeTest("testEquals"));
suite.addTest(new PieniadzeTest("testDodaj"));
return suite;
}
Przypadki testowe mo
ż
na ł
ą
czy
ć
w zbiory wariantów testów (ang.
test suite) reprezentowane przez obiekty klasy TestSuite. JUnit umo
ż
liwia
tworzenie takich zbiorów dwoma metodami: statyczn
ą
i dynamiczn
ą
.
Metoda statyczna w przeciwie
ń
stwie do metody dynamicznej
wymaga „r
ę
cznego” podania, które metody reprezentuj
ą
przypadki testowe.
Mo
ż
liwe s
ą
dwa warianty utworzenia zbiorów testów t
ą
drog
ą
. Pierwszy polega
na przeci
ąż
eniu metody runTest interfejsu Test implementowanego przez klas
ę
TestCase. TestRunner biblioteki JUnit tak naprawd
ę
nie rozró
ż
nia obiektów
TestCase od TestSuite. Odwołuje si
ę
do nich przez interfejs Test wywołuj
ą
c
metod
ę
runTest. Rozwi
ą
zanie polega na przeci
ąż
eniu tej metody i wywołanie w
niej metod implementuj
ą
cych przypadki testowe wchodz
ą
ce w skład tworzonego
zbioru. W przykładzie pokazanym na slajdzie tworzony jest zbiór zawieraj
ą
cy
tylko jeden przypadek testowy jakim jest wariant weryfikuj
ą
cy działanie metody
dodaj. Drugie rozwi
ą
zanie opiera si
ę
na wykorzystaniu klasy TestSuite. Do
obiektu tej klasy dodawane s
ą
warianty testów przez wywołanie metody addTest.
Prosz
ę
zwróci
ć
uwag
ę
w jaki sposób tworzone s
ą
obiekty reprezentuj
ą
ce
poszczególne warianty testu. Otó
ż
tworzone s
ą
obiekty klasy PieniadzeTest a
jako argument wywołania konstruktora podawana jest nazwa metody
implementuj
ą
ca wariant testu.
51
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (51)
Tworzenie zbiorów przypadków testowych
Dynamiczne
public class PieniadzeTests {
public static Test suite() {
TestSuite s = new TestSuite("Testy dla klasy
Pieniadze");
suite.addTest(PieniadzeTest.class);
return suite;
}
}
Drugim sposobem tworzenia zbiorów przypadków testowych jest
wykorzystanie mechanizmu refleksji dost
ę
pnego w j
ę
zyku Java. Biblioteka JUnit
wykorzystuje go w przypadku gdy tworzony jest zbiór testów, gdzie jako
przypadek testowy podawana jest klasa reprezentuj
ą
ca ten wariant testu. JUnit
zakłada,
ż
e przypadki testowe reprezentowane s
ą
przez metody rozpoczynaj
ą
ce
si
ę
od słowa „test”. Dlatego tak wa
ż
ne jest odpowiednie nazewnictwo. Dla
ka
ż
dego takiego przypadku testowego tworzony jest obiekt implementuj
ą
cy
interfejs Test, który jest nast
ę
pnie uruchamiany przez odpowiedni TestRunner.
52
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (52)
JUnit – struktura katalogów
• Oddzielenie testów od kodu
• Klasy znajduj
ą
si
ę
w tym samym pakiecie
src
+---elearning
|
+--- Klasa.java
test
+---elearning
|
+--- KlasaTest.java
Kod
ź
ródłowy aplikacji, jak równie
ż
przypadki testowe sprawdzaj
ą
ce
program powinny by
ć
umieszczone w dwóch osobnych katalogach. Separacja
kodu od testów ułatwia zarz
ą
dzanie nim. Prostsze jest na przykład przygotowanie
dystrybucji aplikacji. U
ż
ytkownik nie potrzebuje mie
ć
przecie
ż
w swoim kodzie
produkcyjnym przypadków testowych. Poniewa
ż
testowanie wymaga czasem
dost
ę
pu do metod klasy, które s
ą
tylko widoczne w ramach pakietu zalecane jest
by klasy zawieraj
ą
ce przypadki testowe były w tych samych pakietach co klasy
przez nie testowane. Ułatwia to poza tym znalezienie wariantów testów dla danej
klasy tworz
ą
c czyteln
ą
struktur
ę
projektu.
53
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (53)
JUnit – dobre praktyki programistyczne
Konstruktor vs setUp
public class PieniadzeTest extends TestCase {
private Pieniadze pieniadze = null;
public Pieniadze(String name) {
super(name);
pieniadze = new Pieniadze(-1);
}
}
Nale
ż
y unika
ć
implementacji metody pre-process w konstruktorze
klasy reprezentuj
ą
cej przypadek testowy. Zgodnie ze specyfikacj
ą
j
ę
zyka Java,
jakikolwiek wyj
ą
tek zgłoszony w konstruktorze przerywa proces tworzenia
obiektu. Przykład kodu zawieraj
ą
cego taki bł
ą
d przedstawiony jest na powy
ż
szym
slajdzie. Nast
ę
puje tu próba utworzenia obiektu klasy Pieniadze z warto
ś
ci
ą
ujemn
ą
, której ta klasa nie akceptuje. Powoduje to wyrzucenie wyj
ą
tku przez
konstruktor klasy Pieniadze do konstruktora przypadku testowego, który nie
zostanie utworzony.
54
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (54)
JUnit – dobre praktyki programistyczne
Konstruktor vs setUp
public class PieniadzeTest extends TestCase {
private Pieniadze pieniadze = null;
public Pieniadze(String name) {
super(name);
pieniadze = new Pieniadze(-1);
}
}
Junit.framework.AssertionFailedError: Cannot instantiate test case
PieniadzeTest
at junit.framework.Assert.fail(Assert.java:143)
at junit.framework.TestSuite$1.runTest(TestSuite.java:178)
at junit.framework.TestCase.runBare(TestCase.java:129)
at junit.framework.TestResult$1.protect(TestResult.java:100)
...
Je
ś
li w kodzie inicjuj
ą
cym przypadku testowego wyst
ą
pi bł
ą
d, który
spowoduje wyrzucenie wyj
ą
tku w konstruktorze, a tak si
ę
dzieje w tym przypadku
to obiekt wariantu testu nie zostanie utworzony, a TestRunner powiadomi
u
ż
ytkownika komunikatem o niemo
ż
no
ś
ci utworzenia wariantu testu. Nie poda
natomiast powodu, dla którego tak si
ę
stało. To znacznie utrudni debugowanie w
przypadku gdy kod inicjuj
ą
cy jest rzeczywi
ś
cie skomplikowany.
55
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (55)
JUnit – dobre praktyki programistyczne
Konstruktor vs setUp
public class PieniadzeTest extends TestCase{
private Pieniadze pieniadze = null;
protected void setUp() throws Exception {
super.setUp();
pieniadze = new Pieniadze(-1);
}
}
Poprawne rozwi
ą
zanie tego problemu prezentuje powy
ż
szy slajd.
By wszystko było wykonane „zgodnie ze sztuk
ą
” kod inicjuj
ą
cy znajduj
ą
cy si
ę
w
konstruktorze wariantu testu powinien zosta
ć
przeniesiony do metody setUp.
56
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (56)
JUnit – dobre praktyki programistyczne
Konstruktor vs setUp
public class PieniadzeTest extends TestCase{
private Pieniadze pieniadze = null;
protected void setUp() throws Exception {
super.setUp();
pieniadze = new Pieniadze(-1);
}
}
java.lang.IllegalArgumentException: amount < 0
at elearning.MoneyTest.setUp (MoneyTest:8)
...
Wtedy w przypadku wyst
ą
pienia bł
ę
dy podczas inicjacji, oprócz
informacji o niemo
ż
no
ś
ci przeprowadzenia testu, wy
ś
wietlona zostanie
dodatkowa informacja podaj
ą
ca powód, dla którego wariant testu nie mógł zosta
ć
wykonany.
57
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (57)
JUnit – dobre praktyki programistyczne
Unikaj wpisywania „na sztywno”
ś
cie
ż
ek do
zasobów
...
new FileInputStream(„C:\testy\plik.txt”)
...
Warianty testów przechowywane s
ą
wraz z kodem
ź
ródłowym
testowanego systemu w repozytorium. Stamt
ą
d s
ą
pobierane przez testerów
celem ich wykonania. By warianty testu mogły by
ć
uruchomione bezproblemowo
na ró
ż
nych maszynach, w ró
ż
nych systemach operacyjnych (Java jest przecie
ż
dost
ę
pna na wiele platform) nale
ż
y unika
ć
bezwzgl
ę
dnych odwoła
ń
do zasobów.
Nie mo
ż
na wymaga
ć
by na wszystkich maszynach była taka sama struktura
katalogów i zainstalowany był jedyny słuszny system operacyjny. Je
ś
li tester
pobieraj
ą
cy warianty testów nie umie
ś
ci ich w katalogu testy na dysku C, tylko na
dysku D to warianty testu posiadaj
ą
ce bezwzgl
ę
dne odwołanie do zasobu
zako
ń
cz
ą
si
ę
niepowodzeniem.
58
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (58)
JUnit – dobre praktyki programistyczne
Unikaj wpisywania „na sztywno”
ś
cie
ż
ek do
zasobów
...
new FileInputStream(„plik.txt”);
...
...
getClass().getResourceAsStream(
getClass(), „plik.txt”);
...
Dlatego te
ż
najlepszym rozwi
ą
zaniem jest unikanie wpisywania na
sztywno
ś
cie
ż
ek bezwzgl
ę
dnych do zasobów i umieszczanie ich w katalogu
bie
żą
cym dla wariantów testów lub te
ż
pobieranie tych plików wykorzystuj
ą
c
ClassLoader klasy przypadku testowego jak pokazano w drugim przykładzie. Z
katalogu bie
żą
cego dla klasy reprezentuj
ą
cej przypadek testowy pobrany
zostanie plik o nazwie „plik.txt”.
59
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (59)
JUnit – dobre praktyki programistyczne
Uniezale
ż
nij testy od czasu, lokalizacji itd.
...
assertEquals(„07:52:00”, new Date().toString());
...
Podobnie jak w poprzednim przypadku nale
ż
y pami
ę
ta
ć
,
ż
e
warianty testów mog
ą
by
ć
uruchamiane na ró
ż
nych maszynach, tak
ż
e z ró
ż
nymi
strefami czasowymi. W zwi
ą
zku z tym nale
ż
y unika
ć
pisania przypadków
testowych uzale
ż
nionych od czasu, czy te
ż
lokalizacji systemu operacyjnego.
Inaczej mo
ż
na spodziewa
ć
si
ę
trudnych do zlokalizowania bł
ę
dów.
60
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (60)
JUnit – dobre praktyki programistyczne
Obsługa wyj
ą
tków – wyj
ą
tek = test nie przechodzi
public void testException() {
try {
new Money(0);
} catch (IllegalArgumentException ex) {
fail();
}
public void testException() throws
IllegalArgumentException {
new Money(0);
}
Je
ś
li testowana metoda zgłosi wyj
ą
tek, to wyrzucany jest on do
metody testuj
ą
cej. Wyrzucenie wyj
ą
tku oznacza bł
ą
d w programie. Pojawia si
ę
pytanie w jaki sposób powinien by
ć
zaimplementowany taki przypadek. Cz
ę
sto
stosowanym cho
ć
nieeleganckim rozwi
ą
zaniem jest przechwycenie tego wyj
ą
tku i
wywołanie metody fail, która spowoduje,
ż
e przypadek testowy nie przejdzie
podaj
ą
c bł
ą
d wykonania. Poza rzadkimi sytuacjami nie nale
ż
y stosowa
ć
tego
rozwi
ą
zania. Biblioteka JUnit potrafi obsłu
ż
y
ć
wyj
ą
tek i poda
ć
powód
niepowodzenia testu. W zwi
ą
zku z tym preferowanym rozwi
ą
zaniem jest to, w
którym w klauzuli throws metody testuj
ą
cej podawane jest jakie wyj
ą
tki mog
ą
by
ć
wyrzucone przez testowany obiekt.
61
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (61)
JUnit – dobre praktyki programistyczne
Obsługa wyj
ą
tków – wyj
ą
tek = test przechodzi
public void testException() {
try {
new Money(-1);
fail(„Powinien wyrzuci
ć
wyj
ą
tek”);
} catch (IllegalArgumentException ex) { }
public void testException() { new Money(-1); }
public static Test suite() {
suite.addTest(new ExceptionTestCase(„testException”,
IllegalArgumentException.class));
}
Odmienn
ą
sytuacj
ą
jest przypadek, kiedy wariant testu sprawdza
czy dany wyj
ą
tek jest wyrzucany przy okre
ś
lonych danych wej
ś
ciowych. Nie
wyrzucenie wyj
ą
tku oznacza bł
ą
d w programie. Biblioteka JUnit udost
ę
pnia dwa
mo
ż
liwe rozwi
ą
zania. Mo
ż
na wykorzysta
ć
metod
ę
fail i umie
ś
ci
ć
j
ą
zaraz pod
metod
ą
, która powinna spowodowa
ć
wyrzucenie okre
ś
lonego wyj
ą
tku. Je
ś
li
metoda ta nie zrobi tego to fail zako
ń
czy działanie przypadku testowego z
informacj
ą
o bł
ę
dzie. Nale
ż
y jeszcze zabezpieczy
ć
si
ę
przed ewentualno
ś
ci
ą
wyrzucenia nieprawidłowego wyj
ą
tku. Metoda powinna by
ć
otoczona klauzul
ą
try
.. catch .. przechwytuj
ą
c
ą
tylko dozwolone wyj
ą
tki. Wszystkie pozostałe zostan
ą
odebrane przez bibliotek
ę
JUnit, która poinformuje u
ż
ytkownika o bł
ę
dzie.
Drugim rozwi
ą
zaniem jest zastosowanie klasy ExceptionTestCase
reprezentuj
ą
cej wariant testu, w którym wyrzucenie wyj
ą
tku spowoduje przej
ś
cie
testu. Obiekt tej klasy nale
ż
y doda
ć
do zbioru przypadków testowych, a w
konstruktorze klasy poda
ć
nazw
ę
metody zawieraj
ą
cej implementacj
ę
wariantu
testu, oraz wyrzucany wyj
ą
tek.
62
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (62)
JUnit – dobre praktyki programistyczne
• Zakładaj,
ż
e przypadki testowe s
ą
wykonywane
w dowolnej kolejno
ś
ci
• Unikaj pisania przypadków testowych z efektami
ubocznymi
• Testowanie prywatnych metod
– Unikaj
– Korzystaj z mechanizmu refleksji j
ę
zyka Java
Cz
ę
sto popełnianym bł
ę
dem jest pisanie przypadków testowych
zawieraj
ą
cych efekty uboczne lub te
ż
zakładaj
ą
cych pewn
ą
kolejno
ść
wykonywania si
ę
wariantów testu. Jednym z zało
ż
e
ń
przy
ś
wiecaj
ą
cych twórcom
biblioteki JUnit jest niezale
ż
no
ść
poszczególnych przypadków testowych. Ka
ż
dy
z nich jest poprzedzony wywołaniem metody setUp, która ustawia stan
testowanego systemu, oraz metody tearDown, która przywraca stan jaki był
przed wykonaniem testu. Wszelkie sposoby ustawienia stanu systemu powinny
by
ć
przeniesione z wariantów testu do metody setUp b
ą
d
ź
tearDown.
Testowane powinny by
ć
metody bior
ą
ce udział w interakcji z innymi
obiektami. Do takich zalicza si
ę
metody publiczne i chronione. Czasem mo
ż
e
zdarzy
ć
si
ę
konieczno
ść
przetestowania metody prywatnej ze wzgl
ę
du na jej nie
trywialne zachowanie. W takim przypadku nale
ż
y zastanowi
ć
si
ę
czy nie nale
ż
y
przerobi
ć
projektu klasy. Mo
ż
e to oznacza
ć
, ze metoda ta powinna mie
ć
mniej
restrykcyjny zasi
ę
g. Je
ś
li oczywi
ś
cie taka metoda ma by
ć
prywatna to jedynym
rozwi
ą
zaniem jest wykorzystanie mechanizmu refleksji dost
ę
pnego w j
ę
zyku
Java.
63
In
ż
ynieria oprogramowania I
Automatyzacja wykonywania testów (63)
Podsumowanie
•
„Automatyzacja chaosu daje tylko
szybszy chaos”
•
Automatyzacja wykonywania testów
zmniejsza koszt testowania a
ż
do
80% wysiłku r
ę
cznego testowania
•
Opłacalne jest automatyzowanie
wykonywania testów i porównywania
uzyskanych wyników z oczekiwanymi
•
JUnit jako przykład narz
ę
dzia do
automatyzacji wykonywania testów
Na wykładzie przedstawiono wady i zalety wynikaj
ą
ce z
automatyzacji testów. Do niew
ą
tpliwych zalet nale
ż
y zaliczy
ć
zmniejszenie kosztu
zwi
ą
zanego z testowaniem nawet do 80% wysiłku sp
ę
dzonego na r
ę
cznym
testowaniu kodu. Oszcz
ę
dno
ść
ta umo
ż
liwia dokładniejsze sprawdzenie
programu. Nale
ż
y jednak pami
ę
ta
ć
,
ż
e testy automatyczne nie daj
ą
efektywniejszych wariantów testu od ich „r
ę
cznych odpowiedników”. Jedynie
umo
ż
liwiaj
ą
ich szybsze wykonanie. W zwi
ą
zku z tym warianty testów, poddane
automatyzacji musz
ą
by
ć
dobrej jako
ś
ci.
Na wykładzie przedstawione zostały czynno
ś
ci wchodz
ą
ce w skład
testowania. Dla ka
ż
dej z nich podano potencjalne mo
ż
liwo
ś
ci automatyzacji.
Czynno
ś
ciami, które warto automatyzowa
ć
s
ą
: wykonywanie testów oraz
porównywanie wyników testów z oczekiwanymi. W przypadku pozostałych
opłacalno
ść
automatyzacji jest dyskusyjna.
Jako przykład narz
ę
dzia słu
żą
cego do automatyzacji testów
przedstawiono bibliotek
ę
JUnit 3.8.x. Umo
ż
liwia ona wykonywanie testów i
porównywanie uzyskanych wyników w sposób automatyczny.
Wyszukiwarka
Podobne podstrony:
więcej podobnych podstron