io-11-wyk

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.

ynieria oprogramowania I

Automatyzacja wykonywania testów (4)

Potrzeba szybkich rozwi

• Testowanie oprogramowania powinno by

– Efektywne

– Wydajne

• Testowanie to ~ 30% - 40% (dla systemów

krytycznych ~80%) całkowitej pracochłonno

• Przetestowane programy zawieraj

bł

Oprogramowanie powinno by

przetestowane by uzyska

pewno

ść

e b

dzie działa

prawidłowo w

rodowisku docelowym. Od testowania wymaga

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

e by

wiele jednak oznacza to,

e nie przetestowano dokładnie systemu.

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

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

na wykona

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

oprogramowanie w krótszym czasie.

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

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

wykonane oczekuje si

e znajd

kszo

ść

bł

dów wyst

puj

cych w

programie.

Wybór przypadków testowych do wykonania jest wi

c bardzo

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

okre

, które warianty testów s

najlepsze?

W kontek

cie automatyzacji testowania przypadki testowe mo

ocenia

na podstawie czterech atrybutów:

efektywno

ci (ang. effective), łatwo

ci zmian (ang. evolvable), przykładno

(ang. exemplary), i ekonomiczno

ci (ang. economic).

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

ść

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

opisuje atrybut przykładno

ść

(ang. exemplary).

Im wi

ksza warto

ść

tego atrybutu tym wi

cej potrafi przetestowa

dany

przypadek testowy.

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

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

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.

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

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.

na wi

c powiedzie

e testowanie to nie tylko zapewnienie,

warianty testu znajd

kszo

ść

bł

dów, ale tak

e zapewnienie,

e te przypadki

testowe s

dobrze zaprojektowane i nie kosztuj

sporo.

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

rol

odgrywa tutaj wybór wariantów testów, które maj

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

cej

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

nie wi

cej) co wykonanie tych testów r

cznie.

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

tem automatyzacji. Test automatorem bywa cz

sto sam tester, cho

e by

nim tak

e osoba spoza zespołu odpowiedzialnego za testowanie. Przykładowo

li w skład zespołu testerów wchodz

osoby, które s

ytkownikami systemu

to posiadaj

oni nieocenion

wiedz

biznesow

, ale nie maj

umiej

tno

technicznych potrzebnych do automatyzacji tych testów. Do tego celu mo

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

zautomatyzowanych wariantów testu. To od umiej

tno

ci test automatora zale

jak łatwo b

dzie doda

lub poprawi

istniej

ce zautomatyzowane warianty

testów, oraz jakie korzy

ci b

płyn

ąć

z automatyzacji.

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

w nocy

Automatyzacja testowania umo

liwia wykonanie wielu czynno

ci znacznie

wydajniej ni

w przypadku gdyby były przeprowadzane r

cznie. Najbardziej oczywist

korzy

płyn

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

na zaliczy

tak

e uruchamianie wi

cej testów cz

ęś

ciej. Dzi

temu,

e testy wykonuj

szybciej mo

na je wykonywa

ęś

ciej. To prowadzi do wi

kszej

pewno

ci,

e tworzony system działa zgodnie z oczekiwaniami klienta.

Niektóre testy bardzo trudno wykona

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

ść

kosztowna i

trudna do zsynchronizowana w przypadku gdyby miała by

przeprowadzona przez testerów.

Odci

ąŜ

c testerów od konieczno

ci wykonywania testów i porównywania

uzyskanego wyj

cia z oczekiwanym, które s

ść

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

ść

powtarzalno

ść

. Testy, które s

powtarzane automatycznie b

powtarzane dokładnie tak samo

(przynajmniej wej

cie, gdy

wyj

cie mo

e si

ró

w zale

ci od np. czasu). To daje poziom

regularno

ci, który jest trudno uzyska

przez testowanie r

czne. Te same testy mog

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.

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

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

w nocy. Testy uruchamiane s

gdy testerzy ko

prac

. Nie trzeba czeka

na wyniki. B

dost

pne

nast

pnego dnia rano.

ynieria oprogramowania I

Automatyzacja wykonywania testów (18)

Ograniczenia automatyzacji

• „Zautomatyzowane testy znajduj

tylko 15% bł

dów.

czne testowanie znajduje 85%.”

Bach, 1997

• Automatyzacja testów nie poprawia ich efektywno

„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

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

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

dobrej jako

ci.

Narz

dzie wykonuj

ce testy mo

e tylko okre

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.

ynieria oprogramowania I

Automatyzacja wykonywania testów (19)

Ograniczenia automatyzacji

• „Zautomatyzowane testy znajduj

tylko 15% bł

dów.

czne testowanie znajduje 85%.”

Bach, 1997

• Automatyzacja testów nie poprawia ich efektywno

„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

Zautomatyzowane testy s

mniej podatne na zmiany ni

testy

wykonywane r

cznie. Wymagaj

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

e zmiana wariantów testów jest nieopłacalna

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

wiele razy uruchamiane. Dzi

temu koszt zwi

zany z ich wytworzeniem si

zwróci.

Automatyczne testy to tylko program posłusznie wykonuj

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.

ynieria oprogramowania I

Automatyzacja wykonywania testów (20)

Kiedy testowa

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

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

takie przypadki, które łatwiej b

dzie wykona

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

e nie zwróci

. 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

okaza

e nie warto automatyzowa

testów sprawdzaj

cych te jego

fragmenty, które cz

sto podlegaj

modyfikacji. Wraz ze zmianami w programie

ąŜ

e si

potrzeba dostosowywania testów co zwi

ksza koszt zwi

zany z ich

utrzymaniem i mo

e okaza

nieopłacalne.

Równie

nie warto automatyzowa

testów, które łatwe s

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

wydobywa si

w momencie wywołania okre

lonego zdarzenia w systemie s

ść

trudne do sprawdzenia przez program, a nie sprawiaj

kszych

problemów testerowi.

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

ąć

kart

przez czytnik kart.

ynieria oprogramowania I

Automatyzacja wykonywania testów (22)

Czynno

ci w ramach testowania

1. Identyfikacja warunków testu

element lub zdarzenie, które mo

zweryfikowane przez testy

Warunek 1: przelew < 0

Warunek 2: u

ytkownik posiada konto

Pierwsz

czynno

jak

nale

y wykona

to okre

lenie co b

dzie

testowane. Przez warunek testu rozumie si

element lub zdarzenie, które mo

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

ynieria oprogramowania I

Automatyzacja wykonywania testów (23)

Czynno

ci w ramach testowania

Identyfikacja warunków testu

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

Warunki testu

Krok

Zaprojektowanie przypadków testowych okre

la w jaki sposób

warunki testu b

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

wyniku wykonania testu itd. Zbiór oczekiwanego wyj

cia mo

e by

całkiem spory.

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.

li kroki te wykonywane s

automatycznie to mówi si

o skryptach testowych.

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

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.

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

tylko w

przypadku gdy testowana aplikacja istnieje. Wcze

niejsze czynno

ci zwi

zane z

testowaniem mo

na wykona

zanim zaimplementowany jest testowany system.

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

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

w trakcie

wykonywania testów jak np. sprawdzenie czy pojawił si

komunikat prosz

cy o

potwierdzenie podczas wykonywania przypadku testowego sprawdzaj

cego czy

na wykona

przelew o warto

ci ujemnej. W innym przypadku gdy np. chcemy

sprawdzi

czy zawarto

ść

bazy danych uległa zmianie mo

e okaza

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.

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

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

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

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.

ynieria oprogramowania I

Automatyzacja wykonywania testów (31)

Automatyzacja projektowania wariantów testu

• Na ogół s

to generatory danych wej

ciowych

• Generuj

Ŝą

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

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

Ŝą

liczb

testów. Nie potrafi

rozró

, które z nich s

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

. Kolejn

powa

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

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.

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

okre

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

na znale

źć

specyfikacji wymaga

. Nie uda si

tak

e wykry

tym sposobem złych lub

brakuj

cych wymaga

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

dej z nich istnieje funkcja pomocy. Innym przykładem testu jaki mo

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

ęś

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.

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.

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ł

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

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

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

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.

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

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

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

te same dane, które b

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

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

ść

ynieria oprogramowania I

Automatyzacja wykonywania testów (37)

Filtry do porówna

Oczekiwane

Zaobserwowane

Przefiltrowane
oczekiwane

Przefiltrowane
zaobserwowane

Filtr

Porównanie

RóŜnice

Praktycznie stosowanym rozwi

zaniem dla problemu, w którym nie

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

porównane. Oprócz usuwania filtr mo

e tak

e sortowa

dane lub dokonywa

ich

zamiany na inn

posta

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 |

-----------------------------

| K32 | Kreda | 3.20

-----------------------------

Razem: 3.20

Filtr

Faktura nr F1235/2003

Data: 20-LIP-2006

Lp. | Symbol | Nazwa | Cena |

-----------------------------

| P11 | Pióro | 12.50

-----------------------------

Razem: 12.50

Porównanie

Faktura nr <nr>/<rok>

Data: <data>

Lp. | Symbol | Nazwa | Cena |

-----------------------------

-----------------------------

Razem: <cena>

Faktura nr <nr>/<rok>

Data: <data>

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.

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

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

dy filtr wykonuje prost

czynno

ść

implementacja ich

nie powinna nastr

czy

kszych problemów. Zło

one porównanie jest

podzielone na wiele małych kroków, co tak

e ułatwia automatyzacj

testu gdy

na zastosowa

proste porównanie.

Niestety stworzenie filtrów wymaga umiej

tno

programistycznych. Na szcz

ęś

cie raz stworzone filtry mo

na ponownie

wykorzysta

. Kolejn

wad

e by

konieczno

ść

ich modyfikacji w przypadku

gdy format wyj

cia ulegnie zmianie.

By filtry mogły by

ponownie wykorzystane musz

dobrze

udokumentowane. Inaczej nie b

dzie wiadomo w jaki sposób mo

na ich u

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

na dodawanie

krotek do bazy danych, które s

niezb

dne do wykonania testu, logowanie

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

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.

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

Ŝą

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

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

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

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.

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.

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

Ŝą

do prostych porówna

, zwane asercjami, o których mowa b

dzie w dalszej cz

ęś

wykładu.

Klasy reprezentuj

ce przypadki testowe mog

grupowane w

zbiory wariantów testowych reprezentowane przez klas

TestSuite. Dzi

ki temu

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

korzystaj

równie

rodowiska programistyczne (IDE) dopisuj

c własne

rozszerzenia integruj

ce bibliotek

ze swoimi interfejsami.

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

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.

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

dzy oczekiwanym wyj

ciem a faktycznym. Asercje te s

metodami

polimorficznymi maj

cymi postacie dla wielu typów danych w j

zyku Java. Ka

z asercji posiada wariant, dla którego istnieje mo

liwo

ść

podania komunikatu

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

z nast

puj

cych grup metod:

•assertEquals – sprawdza czy obiekty s

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

null

•assertNotNull – weryfikuje czy argument jest obiektem ró

nym od null

•fail – powoduje bezwarunkowe zgłoszenie nieprawdziwo

ci asercji.

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

ęŜ

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

samy obiektowi klasy Pieni

dze. Obiekty uznawane s

za to

same je

reprezentuj

sam

kwot

pieni

ęŜ

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

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.

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

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.

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.

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

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

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

poszczególne warianty testu. Otó

tworzone s

obiekty klasy PieniadzeTest a

jako argument wywołania konstruktora podawana jest nazwa metody
implementuj

ca wariant testu.

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

od słowa „test”. Dlatego tak wa

ne jest odpowiednie nazewnictwo. Dla

dego takiego przypadku testowego tworzony jest obiekt implementuj

interfejs Test, który jest nast

pnie uruchamiany przez odpowiedni TestRunner.

ynieria oprogramowania I

Automatyzacja wykonywania testów (52)

JUnit – struktura katalogów

• Oddzielenie testów od kodu

• Klasy znajduj

w tym samym pakiecie

src

+---elearning

+--- Klasa.java

test

+---elearning

+--- KlasaTest.java

Kod

ródłowy aplikacji, jak równie

przypadki testowe sprawdzaj

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.

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

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

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.

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)

...

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

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.

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

niepowodzeniem.

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

warianty testów mog

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

trudnych do zlokalizowania bł

dów.

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

}

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

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

wyrzucone przez testowany obiekt.

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

liwe rozwi

zania. Mo

na wykorzysta

metod

fail i umie

zaraz pod

metod

, która powinna spowodowa

wyrzucenie okre

lonego wyj

tku. Je

metoda ta nie zrobi tego to fail zako

czy działanie przypadku testowego z

informacj

o bł

dzie. Nale

y jeszcze zabezpieczy

przed ewentualno

wyrzucenia nieprawidłowego wyj

tku. Metoda powinna by

otoczona klauzul

try

.. catch .. przechwytuj

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.

ynieria oprogramowania I

Automatyzacja wykonywania testów (62)

JUnit – dobre praktyki programistyczne

• Zakładaj,

e przypadki testowe s

wykonywane

w dowolnej kolejno

• Unikaj pisania przypadków testowych z efektami

ubocznymi

• Testowanie prywatnych metod

– Unikaj

– Korzystaj z mechanizmu refleksji j

zyka Java

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

przy

wiecaj

cych twórcom

biblioteki JUnit jest niezale

ść

poszczególnych przypadków testowych. Ka

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

tearDown.

Testowane powinny by

metody bior

ce udział w interakcji z innymi

obiektami. Do takich zalicza si

metody publiczne i chronione. Czasem mo

zdarzy

konieczno

ść

przetestowania metody prywatnej ze wzgl

du na jej nie

trywialne zachowanie. W takim przypadku nale

y zastanowi

czy nie nale

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.

ynieria oprogramowania I

Automatyzacja wykonywania testów (63)

Podsumowanie

•

„Automatyzacja chaosu daje tylko
szybszy chaos”

•

Automatyzacja wykonywania testów
zmniejsza koszt testowania a

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

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

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

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