1
In
ż
ynieria oprogramowania I
Wprowadzenie do testowania
Bła
ż
ej Pietrzak
Blazej.Pietrzak@cs.put.poznan.pl
Testowanie to cz
ę
sto niedoceniana technika weryfikacji i walidacji
oprogramowania. Zdarzaj
ą
si
ę
przypadki, gdzie tworzony produkt nie jest w ogóle
sprawdzany pod k
ą
tem wad i oczekiwa
ń
klienta. Bywa równie
ż
całkiem
odwrotnie, gdzie testowanie uwa
ż
ane jest za jedyn
ą
technik
ę
gwarantuj
ą
c
ą
jako
ść
efektu ko
ń
cowego. Dobrze jest wi
ę
c spojrze
ć
ogólnie na proces weryfikacji
i walidacji i zastanowi
ć
si
ę
do czego tak naprawd
ę
testowanie mo
ż
na
wykorzysta
ć
. Maj
ą
c to na uwadze proponuj
ę
Pa
ń
stwu – w ramach in
ż
ynierii
oprogramowania - wykład wprowadzaj
ą
cy do testowania.
2
In
ż
ynieria oprogramowania I
Wprowadzenie do testowania (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 automatyzacji testowania oraz
refaktoryzacji, gdzie testowanie odgrywa kluczow
ą
rol
ę
podczas
weryfikacji poprawno
ś
ci przekształce
ń
refaktoryzacyjnych.
3
In
ż
ynieria oprogramowania I
Wprowadzenie do testowania (3)
Plan wykładu
• Weryfikacja i walidacja
• Testowanie oprogramowania
• Aksjomaty testowania
• Rodzaje testów
• Metoda czarnej skrzynki
• Metoda białej skrzynki
• Testowanie a debugowanie
• Inspekcje a testowanie
Plan wykładu wygl
ą
da nast
ę
puj
ą
co. Na pocz
ą
tku dowiecie si
ę
Pa
ń
stwo czym jest proces weryfikacji i walidacji oraz jakie s
ą
jego cele.
Przedstawione zostan
ą
ponadto dwie najwa
ż
niejsze techniki weryfikacji i
walidacji. Omówione zostanie tak
ż
e poj
ę
cie testowania oprogramowania oraz
ograniczenia tej
ż
e techniki, co w konsekwencji doprowadzi do sformułowania
aksjomatów testowania. Dalej zapoznani zostaniecie z rodzajami testów oraz
metod
ą
czarnej i białej skrzynki. Wreszcie na koniec omówione zostan
ą
relacje
testowania z debugowaniem i inspekcjami kodu.
4
In
ż
ynieria oprogramowania I
Wprowadzenie do testowania (4)
Notoryczne bł
ę
dy
• Zestrzelenie samolotu Airbus 320, 1988
– 290 zabitych
•
Ś
mier
ć
pacjentów chorych na raka, 1985-87
• Pentium floating point, 1994
– Koszt ~ 475 000 000$
• Rakieta Ariane 5, 1996
– Budowa ~ 7 000 000 000$, Straty ~ 500 000 000$
– Rakieta i jej cztery satelity nie były ubezpieczone
Dzi
ę
ki post
ę
powi technologicznemu wci
ąż
ro
ś
nie zło
ż
ono
ść
programów. Niestety za tym id
ą
bł
ę
dy, które kosztuj
ą
coraz wi
ę
cej i to nie tylko
pieni
ę
dzy. W lipcu 1988 roku kr
ąż
ownik USS Vincennes patrolował wody Zatoki
Perskiej egzekwuj
ą
c embargo nało
ż
one przez Stany Zjednoczone na Iran. Został
zaatakowany około godziny 10:00 przez łodzie ira
ń
skie. Odpowiedział w ich
kierunku ogniem. W tym czasie nad nieoczekiwanym polem bitwy przelatywał
pasa
ż
erski samolot cywilny Airbus 320 wioz
ą
cy 290 cywilów z lotniska Bandar
Abbas do Abu Dhabi. Na skutek bł
ę
du w systemie
ś
ledzenia obiektów
zainstalowanym na kr
ąż
owniku USS Vincennes samolot ten został uznany za
ira
ń
ski samolot wojskowy F-14 i zestrzelony przez załog
ę
statku. Zgin
ę
li wszyscy
pasa
ż
erowie samolotu Airbus – 290 osób.
Jako inny tragiczny przykład spowodowany bł
ę
dem w
oprogramowaniu mo
ż
e posłu
ż
y
ć
przypadek
ś
mierci pacjentów chorych na raka,
którzy otrzymali nadmierne dawki promieniowania. Therac-25, maszyna słu
żą
ca
do terapii raka, na skutek sytuacji wy
ś
cigu, czyli bł
ę
dnej implementacji
współbie
ż
no
ś
ci zada
ń
, podawała nadmierne dawki promieniowania chorym
pacjentom. Wielu z nich zmarło na skutek takiej „kuracji”, pozostali odnie
ś
li trwały
uszczerbek na zdrowiu. Leczenie z wykorzystaniem tej maszyny było
prowadzone przez dwa lata zanim zauwa
ż
ony został bł
ą
d.
5
In
ż
ynieria oprogramowania I
Wprowadzenie do testowania (5)
Notoryczne bł
ę
dy
• Zestrzelenie samolotu Airbus 320, 1988
– 290 zabitych
•
Ś
mier
ć
pacjentów chorych na raka, 1985-87
• Pentium floating point, 1994
– Koszt ~ 475 000 000$
• Rakieta Ariane 5, 1996
– Budowa ~ 7 000 000 000$, Straty ~ 500 000 000$
– Rakieta i jej cztery satelity nie były ubezpieczone
Od momentu wyprodukowania pierwszego mikroprocesora w 1971
roku, Intel stał si
ę
liderem na skal
ę
ś
wiatow
ą
w produkcji układów scalonych.
Wi
ę
kszo
ść
sprzedawanych obecnie komputerów oparta jest na produktach tej
ż
e
firmy. Jednak
ż
e mimo ci
ęż
kiej pracy specjalistów z firmy Intel ich mikroprocesory
posiadały wiele bł
ę
dów. Do najgło
ś
niejszych z nich nale
ż
ał bł
ą
d zwi
ą
zany z
instrukcj
ą
FDIV w procesorze Pentium. Nieprawidłowe wpisy w tablicy
wyszukuj
ą
cej (ang. lookup table) wykorzystywanej przez algorytm SRT
odpowiedzialny za dzielenie liczb powodowały,
ż
e wynik ilorazu był bł
ę
dny. W
tablicy tej przechowywane były po
ś
rednie wyniki ilorazu liczb
zmiennoprzecinkowych. Pi
ęć
z 1066 wpisów nie było pobieranych w wyniku
bł
ę
du programistycznego. W momencie dost
ę
pu do którejkolwiek z tych pi
ę
ciu
komórek przez jednostk
ę
zmiennoprzecinkow
ą
(ang. Floating Point Unit, w
skrócie FPU) pobierano zero zamiast prawidłowej warto
ś
ci. To powodowało,
ż
e
wynik dzielenia był nieprawidłowy. Bł
ą
d ten dotykał nie tylko samej instrukcji FDIV
cho
ć
tak go sklasyfikowano, ale tak
ż
e pozostałych instrukcji korzystaj
ą
cych z niej
i odwołuj
ą
cych si
ę
do tablicy wyszukiwawczej. Intel wymienił wszystkie „bł
ę
dne
procesory”. Poza utrat
ą
reputacji, któr
ą
przyszło mu ci
ęż
ko odbudowywa
ć
, koszt
tego bł
ę
du oceniono na około czterysta siedemdziesi
ą
t pi
ęć
milionów dolarów.
6
In
ż
ynieria oprogramowania I
Wprowadzenie do testowania (6)
Notoryczne bł
ę
dy
• Zestrzelenie samolotu Airbus 320, 1988
– 290 zabitych
•
Ś
mier
ć
pacjentów chorych na raka, 1985-87
• Pentium floating point, 1994
– Koszt ~ 475 000 000$
• Rakieta Ariane 5, 1996
– Budowa ~ 7 000 000 000$, Straty ~ 500 000 000$
– Rakieta i jej cztery satelity nie były ubezpieczone
W dniu 4 czerwca 1996 roku nieuzbrojona rakieta Ariane 5
wystrzelona przez Europejsk
ą
Agencj
ę
Kosmiczn
ą
(ang. European Space
Agency) na wysoko
ś
ci 3700 metrów, 40 sekund po starcie zmieniła kurs lotu,
rozpadła si
ę
na cz
ęś
ci i wybuchła.
Ś
ledztwo wykazało,
ż
e powodem usterki był
bł
ą
d programistyczny. Liczba 64-bitowa okre
ś
laj
ą
ca poziome przyspieszenie
rakiety została przekonwertowana do liczby całkowitej 16-bitowej ze znakiem.
Oczywi
ś
cie warto
ść
przechowywana była wi
ę
ksza od 32 768, czyli była wi
ę
ksza
od maksymalnej liczby jak
ą
mo
ż
e przechowa
ć
zmienna 16-bitowa, co
spowodowało utrat
ę
orientacji w przestrzeni i zmian
ę
kierunku lotu powoduj
ą
c
zniszczenie rakiety.
Rakieta udawała si
ę
w swój pierwszy rejs, po dziesi
ę
ciu latach
budowy, które kosztowały siedem miliardów dolarów. J
ą
sam
ą
i ładunek
wyceniono na pi
ęć
set milionów dolarów. Rakieta i jej cztery satelity nie były
ubezpieczone.
7
In
ż
ynieria oprogramowania I
Wprowadzenie do testowania (7)
Weryfikacja a Walidacja
• Weryfikacja (ang. verification)
„Czy budujemy prawidłowo produkt?”
• Walidacja (ang. validation)
„Czy budujemy prawidłowy produkt?”
Jak wida
ć
bł
ę
dy mog
ą
mie
ć
fatalne skutki. Dlatego te
ż
, wa
ż
ne jest
by ju
ż
podczas wytwarzania produktu mo
ż
na było stwierdzi
ć
czy tworzony system
jest zgodny ze specyfikacj
ą
oraz czy spełnione s
ą
oczekiwania klienta. To jest
nazywane procesem weryfikacji i walidacji. Oba aspekty s
ą
wa
ż
ne, poniewa
ż
fakt
zgodno
ś
ci ze specyfikacj
ą
nie oznacza,
ż
e system jest technicznie poprawny i
odwrotnie.
Proces weryfikacji i walidacji jest szczególnie wa
ż
ny w przypadku
wytwarzania oprogramowania. Przez ostatnie 20 - 30 lat produkcja
oprogramowania ewoluowała z małych zada
ń
tworzonych przez grupki kilku ludzi
do wielkich systemów, w których udział bior
ą
setki czy nawet tysi
ą
ce
programistów. Z powodu tych zmian proces weryfikacji i walidacji równie
ż
musiał
ulec zmianie. Pocz
ą
tkowo weryfikacja i walidacja była nieformalnym procesem
wykonywanym przez in
ż
yniera oprogramowania. Jednak
ż
e ci
ą
gły wzrost
zło
ż
ono
ś
ci oprogramowania oznaczał,
ż
e stosowanie tych technik musi ulec
zmianie. Inaczej nie mo
ż
naby było polega
ć
na wynikowym produkcie.
Czym
ż
e jest ów proces walidacji i weryfikacji? Jak sama nazwa
wskazuje składa si
ę
z dwóch składowych: weryfikacji i walidacji. Na etapie
weryfikacji sprawdzane jest czy produkty danej fazy wytwarzania s
ą
zgodne z
nało
ż
onymi na ni
ą
zało
ż
eniami. Natomiast nie jest sprawdzane czy specyfikacja
jest prawidłowa, co jest przedmiotem walidacji. Weryfikacja nie wykryje bł
ę
dów
zwi
ą
zanych z nieprawidłow
ą
specyfikacj
ą
wymaga
ń
. Walidacja natomiast
sprawdza czy oprogramowanie wykonuje to czego wymaga od niego u
ż
ytkownik,
czyli jest odpowiedzialna za znalezienie bł
ę
dów w specyfikacji systemu.
8
In
ż
ynieria oprogramowania I
Wprowadzenie do testowania (8)
Proces weryfikacji i walidacji
• Weryfikacja i walidacja musi wykonywana na
ka
ż
dym etapie tworzenia oprogramowania
• Główne cele:
– Wykrycie bł
ę
dów w systemie
– Ocena czy system jest mo
ż
liwy do
wykorzystania w „sytuacji bojowej”
Głównymi celami weryfikacji i walidacji jest wykrycie bł
ę
dów w
systemie oraz sprawdzenie czy system spełnia oczekiwania klienta. Oznacza to
nie tylko znalezienie bł
ę
dów wynikaj
ą
cych ze złej implementacji specyfikacji, ale
tak
ż
e nieprawidłowo wyspecyfikowanych oczekiwa
ń
klienta. Mo
ż
e si
ę
zdarzy
ć
,
ż
e
klient oczekuje funkcjonalno
ś
ci, która wogóle nie została uwzgl
ę
dniona w
specyfikacji, lub te
ż
opis jest niejednoznaczny.
Weryfikacja i walidacja powinna by
ć
wykonywana na ka
ż
dym etapie
tworzenia oprogramowania. Wiele firm waliduje produkt dopiero na ko
ń
cu czego
efektem s
ą
wy
ż
sze koszty usuwania znalezionych bł
ę
dów. Cz
ę
sto zdarza si
ę
te
ż
,
ż
e gdy ostatni
ą
faz
ą
jest weryfikacja i walidacja to brakuje zasobów na ich
przeprowadzenie, poniewa
ż
poprzednie fazy wytwarzania pochłon
ę
ły ich wi
ę
cej
ani
ż
eli wynikało to z harmonogramu. Dlatego te
ż
, przeprowadzenie weryfikacji i
walidacji na ka
ż
dym etapie pozwala na przynajmniej cz
ęś
ciowe sprawdzenie
systemu (póki s
ą
zasoby) oraz zmniejsza koszt usuni
ę
cia bł
ę
du, poniewa
ż
usterki
znajdywane s
ą
szybciej co ułatwia ich usuni
ę
cie.
9
In
ż
ynieria oprogramowania I
Wprowadzenie do testowania (9)
Statyczna i dynamiczna weryfikacja
• Inspekcje kodu (statyczna)
– Zwi
ą
zane z analiz
ą
statycznej reprezentacji
systemu w celu wykrycia problemów
• Testowanie oprogramowania (dynamiczna)
– System jest uruchamiany z danymi testowymi
i sprawdzane jest jego zachowanie
Istnieje wiele ró
ż
nych technik weryfikacji oprogramowania. Do
dwóch najwa
ż
niejszych nale
żą
: inspekcje kodu oraz dynamiczne testowanie
oprogramowania.
Inspekcje kodu zwi
ą
zane s
ą
z analiz
ą
statycznej reprezentacji
systemu w celu wykrycia potencjalnych problemów w niej wyst
ę
puj
ą
cych. Proces
ten mo
ż
e by
ć
cz
ęś
ciowo zautomatyzowany. Wtedy kod programu analizowany
jest najpierw przez automat, który znajduje potencjalne nieprawidłowo
ś
ci.
Podejrzane fragmenty kodu s
ą
nast
ę
pnie analizowane przez u
ż
ytkownika by
stwierdzi
ć
czy znalezione przez automat naruszenia maj
ą
rzeczywi
ś
cie miejsce.
Dynamiczne testowanie oprogramowania jest drug
ą
z technik, która
polega na uruchomieniu aplikacji, zasileniu jej pewnymi danymi testowymi i
sprawdzeniu jakie zachowanie generowane jest przez system. Nast
ę
pnie
zaobserwowane zachowanie jest porównywane z oczekiwanym.
10
In
ż
ynieria oprogramowania I
Wprowadzenie do testowania (10)
Statyczna i dynamiczna V&V
Statyczna
weryfikacja i walidacja
Specyfikacja
wymaga
ń
Projekt
architektury
systemu
Specyfikacja
formalna
Projekt
szczegółowy
Program
Prototyp
Dynamiczna
weryfikacja
i walidacja
Poni
ż
szy slajd pokazuje mo
ż
liwo
ś
ci zastosowania technik statycznej i
dynamicznej analizy systemu.
Jak wida
ć
statyczna weryfikacja i walidacja mo
ż
e by
ć
zastosowana
praktycznie na wszystkich etapach wytwarzania oprogramowania. Wykorzystuj
ą
c
statyczne techniki mo
ż
liwe jest sprawdzenie systemu od specyfikacji wymaga
ń
,
projektu architektury systemu, specyfikacji formalnej a
ż
po program
sko
ń
czywszy, podczas gdy dynamiczn
ą
technik
ą
mo
ż
na sprawdzi
ć
tylko przy
okazji specyfikacji wymaga
ń
i na ko
ń
cu po napisaniu cz
ęś
ci systemu. Analiza
wymaga
ń
w sposób dynamiczny jest mo
ż
liwa po uprzednim napisaniu prototypu,
który spełnia analizowane wymagania.
11
In
ż
ynieria oprogramowania I
Wprowadzenie do testowania (11)
Cele weryfikacji i walidacji
• Weryfikacja i walidacja != brak bł
ę
dów w
programie
• Uzyskanie poziomu pewno
ś
ci działania systemu
Celem weryfikacji i walidacji jest sprawdzenie czy oprogramowanie
spełni swoje zadanie. Nie oznacza to,
ż
e kod wynikowy b
ę
dzie bezbł
ę
dny.
Oznacza to po prostu,
ż
e b
ę
dzie on na tyle dobry by mógł by
ć
wykorzystany
przez u
ż
ytkownika. Jako cel proces weryfikacji i walidacji stawia sobie uzyskanie
pewnego poziomu pewno
ś
ci działania systemu. Je
ś
li ten poziom jest osi
ą
gni
ę
ty
wtedy mo
ż
na uzna
ć
,
ż
e proces weryfikacji i walidacji zako
ń
czył si
ę
powodzeniem.
12
In
ż
ynieria oprogramowania I
Wprowadzenie do testowania (12)
Poziom pewno
ś
ci
• Zale
ż
y od nast
ę
puj
ą
cych czynników:
– Funkcja oprogramowania
– Oczekiwania u
ż
ytkownika
– Rynek
Poziom pewno
ś
ci zale
ż
y od wielu czynników. Jednym z
najwa
ż
niejszych jest przeznaczenie oprogramowania, czyli okre
ś
lenie jak
ą
funkcj
ę
ma ono pełni
ć
dla organizacji. Poziom pewno
ś
ci zale
ż
y od tego jak
krytyczne jest to oprogramowanie dla organizacji.
Oczekiwania u
ż
ytkownika, to drugi z czynników wpływaj
ą
cych na
poziom pewno
ś
ci. U
ż
ytkownicy mog
ą
mie
ć
niskie oczekiwania w stosunku do
pewnych rodzajów oprogramowania lub fragmentów systemu, co mo
ż
e oznacza
ć
mniej restrykcyjne weryfikowanie i walidowanie.
Wreszcie sam rynek dostarcza informacji o tym jak wysoki poziom
pewno
ś
ci powinien posiada
ć
system. Mo
ż
e si
ę
okaza
ć
,
ż
e wcze
ś
niejsze
wypuszczenie produktu na rynek jest wa
ż
niejsze ni
ż
znajdywanie bł
ę
dów w
programie.
13
In
ż
ynieria oprogramowania I
Wprowadzenie do testowania (13)
Planowanie
• Wcze
ś
nie planuj!
• Statyczna weryfikacja czy testowanie?
• Standardy czy opis testów?
• Zasada Pareto (80/20)
Bardzo wa
ż
n
ą
spraw
ą
podczas wytwarzania oprogramowania jest
odpowiednie planowanie. Ta sama zasada tyczy si
ę
równie
ż
fazy weryfikacji i
walidacji. Im wcze
ś
niej rozpocznie si
ę
planowanie tym lepiej. Najlepiej je zacz
ąć
ju
ż
na etapie analizy wymaga
ń
. To umo
ż
liwia lepsze zrozumienie jak ma działa
ć
budowany system. Plan powinien identyfikowa
ć
równowag
ę
pomi
ę
dzy statyczn
ą
weryfikacj
ą
a testowaniem. Obydwie techniki powinny by
ć
wykorzystywane w
procesie weryfikacji i walidacji. Metody statyczne nie sprawdz
ą
wszystkich cech
produktu jak np. wydajno
ść
systemu. Do tego celu idealnie nadaje si
ę
testowanie.
Odwrotna sytuacja te
ż
jest niedopuszczalna. Statyczne techniki umo
ż
liwiaj
ą
sprawdzenie mi
ę
dzy innymi poprawno
ś
ci specyfikacji i wykrycie brakuj
ą
cych
wymaga
ń
, jak równie
ż
identyfikacj
ę
takich, które s
ą
niejednoznaczne co przy
pomocy testowania jest niemo
ż
liwe.
Czy plan powinien uwzgl
ę
dnia
ć
testy wszystkich mo
ż
liwych
elementów systemu? W praktyce testuje si
ę
tylko jego wybrane fragmenty w my
ś
l
zasady Pareto,
ż
e 20% kodu generuje 80% bł
ę
dów.
Celem planowania testów jest bardziej definiowanie standardów dla
testowania ani
ż
eli opisywanie samych testów jakim poddany b
ę
dzie produkt.
14
In
ż
ynieria oprogramowania I
Wprowadzenie do testowania (14)
Plan testów oprogramowania
• Proces testowania
•
Ś
ledzenie wymaga
ń
• Testowane elementy
• Harmonogram testów
• Procedury nagrywania testów
• Wymagania odno
ś
nie sprz
ę
tu i oprogramowania
• Ograniczenia
Dokument planu testów powinien zawiera
ć
opis procesu
testowania, czyli w jaki sposób b
ę
dzie przeprowadzany, oraz kto b
ę
dzie za niego
odpowiedzialny. Plan testów oprogramowania powinien by
ć
tak skonstruowany
by móc umo
ż
liwi
ć ś
ledzenie wymaga
ń
. W przypadku gdy dane wymaganie
ulegnie zmianie, szybko b
ę
dzie mo
ż
na zaktualizowa
ć
tak
ż
e plan co zmniejszy
szans
ę
pomyłki podczas weryfikacji i walidacji systemu. Wszystkie testy powinny
by
ć
powi
ą
zane z wymaganiami u
ż
ytkownika. Nie warto testowa
ć
cech systemu, o
których nie ma
ż
adnej informacji w jego specyfikacji. Oczywi
ś
cie plan nie mo
ż
e
oby
ć
si
ę
bez harmonogramu. Powinno by
ć
w nim zawarte co i kiedy jest
testowane oraz kto ma to przeprowadzi
ć
. Sposób w jaki test b
ę
dzie wykonywany,
jakie techniki maj
ą
by
ć
wykorzystane oraz jak przeprowadzana jest rejestracja
testu jest bardzo wa
ż
ny. Bez logów i informacji dla jakich danych test nie
przeszedł niemo
ż
liwe jest usuni
ę
cie bł
ę
du. Sama informacja,
ż
e s
ą
bł
ę
dy nie zda
si
ę
na wiele. W planie testów powinno by
ć
te
ż
opisane
ś
rodowisko testowe, na
jakim sprz
ę
cie wykonane zostanie uruchomienie systemu, oraz z jakiego systemu
operacyjnego i innego oprogramowania system ma korzysta
ć
.
Szczegóły dotycz
ą
ce dokumentowania planu testów mo
ż
na znale
źć
w standardzie IEEE 829 (Std 829-1998). Celem tego wykładu jest jedynie
zaznajomienie Pa
ń
stwa z podstawowymi hasłami dotycz
ą
cymi zagadnie
ń
testowania.
15
In
ż
ynieria oprogramowania I
Wprowadzenie do testowania (15)
Czym jest testowanie?
Testowanie oprogramowania jest wykonaniem
kodu dla kombinacji danych wej
ś
ciowych i
stanów w celu wykrycia bł
ę
dów
Robert V. Binder: „Testing Object-Oriented
Systems. Models, Patterns, and Tools”
Udany test = wykrycie bł
ę
du
Efektywno
ść
testu = zdolno
ść
do
znajdywania bł
ę
dów
Zdefiniujmy poj
ę
cie testowania. Według definicji podanej w ksi
ąż
ce
Roberta V. Bindera pt.: „Testowanie systemów obiektowych. Modele, wzorce i
narz
ę
dzia” testowanie oprogramowania to wykonanie kodu dla kombinacji danych
wej
ś
ciowych i stanów w celu wykrycia bł
ę
dów. Prosz
ę
zauwa
ż
y
ć
,
ż
e celem
testów jest wykrycie bł
ę
dów. Nie jest to analiza statyczna, ale dynamiczna, bo
testowany kod jest wykonywany. Testy projektuje si
ę
, analizuj
ą
c testowany
system i rozstrzygaj
ą
c, do jakiego stopnia jest on obci
ąż
ony ryzykiem bł
ę
dów.
Zaprojektowane testy nast
ę
pnie wykonuje si
ę
r
ę
cznie lub poddaje automatyzacji,
czyli napisaniu oprogramowania, które wypróbowuje inny system
oprogramowania w celu znalezienia bł
ę
du. Uzyskane wyniki analizuje si
ę
i
okre
ś
la czy test wykrył bł
ą
d, czy te
ż
było to prawidłowe zachowanie systemu.
Test uznaje si
ę
za udany je
ś
li wykryje nie znaleziony jeszcze bł
ą
d. Mówi si
ę
,
ż
e
test jest efektywny je
ś
li znajduje bł
ę
dy z maksymalnym prawdopobie
ń
stwem.
16
In
ż
ynieria oprogramowania I
Wprowadzenie do testowania (16)
Czym jest testowanie? – c.d.
Zaobserwowane
wyj
ś
cie
Testowana implementacja
Stan wst
ę
pny
Dane wej
ś
ciowe
Wariant testu (przypadek testowy, ang. test case)
W ramach projektowania testu wyodr
ę
bnia si
ę
i analizuje
powinno
ś
ci testowanego systemu. Nast
ę
pnie projektuje si
ę
warianty testu. Na
wariant testu zwany inaczej przypadkiem testowym składaj
ą
si
ę
nast
ę
puj
ą
ce
elementy:
- stan wst
ę
pny, czyli stan testowanego systemu b
ą
d
ź
jego fragmentu jaki
wyst
ę
puje tu
ż
przed testem
- Dane wej
ś
ciowe lub warunki testu
- Oczekiwane wyniki
Wynik oczekiwany okre
ś
la, co testowana implementacja powinna wyprodukowa
ć
z danych testowych.
Natomiast rzeczywiste wyj
ś
cie, czyli wynik wykonania testu na testowanej
implementacji (systemie lub jego fragmencie) nazywany jest zaobserwowanym
wyj
ś
ciem.
17
In
ż
ynieria oprogramowania I
Wprowadzenie do testowania (17)
Czym jest testowanie? – c.d.
Wyrocznia
Testowany
system
Porównanie
Dane
wej
ś
ciowe
Dane
wej
ś
ciowe
Oczekiwane
wyj
ś
cie
Faktyczne
wyj
ś
cie
Wynik
testu
Stan wst
ę
pny
Stan wst
ę
pny
Po zaprojektowaniu wariantów testu przychodzi czas na ich
przeprowadzenie. Wykonanie przypadku testowego mo
ż
na opisa
ć
przy pomocy
nast
ę
puj
ą
cych kroków. Testowany system b
ą
d
ź
jego fragment s
ą
ustawiane w
stanie wst
ę
pnym. Nast
ę
pnie podawane s
ą
dane wej
ś
ciowe do testowanej
implementacji.
Te same dane podawane s
ą
wyroczni. Wyrocznia jest
ś
rodkiem do
wytwarzania wyników oczekiwanych. Najcz
ęś
ciej wyroczniami s
ą
wyj
ś
cia
ustalone przez projektanta testu. Mo
ż
e to by
ć
tak
ż
e wynik wykonania systemu
zaufanego.
Nast
ę
pnie zaobserwowane wyj
ś
cie jest porównywane z wyj
ś
ciem
oczekiwanym z wyroczni w celu ustalenia czy test ujawnił bł
ą
d czy te
ż
nie. Za
udany test uwa
ż
a si
ę
taki, który wykryje przynajmniej jeden bł
ą
d.
18
In
ż
ynieria oprogramowania I
Wprowadzenie do testowania (18)
Ograniczenia testowania
„Testowanie mo
ż
e ujawni
ć
obecno
ść
bł
ę
dów, ale nigdy
ich braku”
Dijkstra
Pojawia si
ę
zatem pytanie czy testowanie jest wystarczaj
ą
c
ą
metod
ą
zapewniania jako
ś
ci. Słynne jest powiedzenie profesora Dijkstry, które
mówi,
ż
e przy pomocy testowania mo
ż
emy ujawni
ć
obecno
ść
bł
ę
dów, ale nie ich
brak. Zatem testowanie jako jedyna technika zapewniania jako
ś
ci jest
niewystarczaj
ą
ca.
19
In
ż
ynieria oprogramowania I
Wprowadzenie do testowania (19)
Ograniczenia testowania – c.d.
• Testowanie + statyczna weryfikacja = pełne
pokrycie dla weryfikacji i walidacji
• Testowanie jest jedyn
ą
technik
ą
walidacji dla
wymaga
ń
niefunkcjonalnych
Testowanie powinno by
ć
wykorzystywane wraz z technikami
statycznej weryfikacji w celu osi
ą
gni
ę
cia pełnego pokrycia dla weryfikacji i
walidacji.
W przypadku wymaga
ń
niefunkcjonalnych testowanie jest jedyn
ą
technik
ą
walidacji. Wymagania takie jak wydajno
ść
systemu czy obci
ąż
enie
mo
ż
na sprawdzi
ć
tylko i wył
ą
cznie przy pomocy testowania.
20
In
ż
ynieria oprogramowania I
Wprowadzenie do testowania (20)
Ograniczenia testowania – c.d.
Wyczerpuj
ą
ce testowanie jest na ogół niemo
ż
liwe (trudne)
for (int i = 0; i < n; i++) {
if (a.get(i) == b.get(i))
x[i] = x[i] + 100;
else
x[i] = x[i] / 2;
}
3
5
1025
1 152 921 504 606 847 200
1
2
10
60
Path No.
n
Istniej
ą
dwa podej
ś
cia na okre
ś
lenie czy system jest wolny od
bł
ę
dów. Mo
ż
na na zasadzie dowodu poprawno
ś
ci udowodni
ć
,
ż
e system jest
bezbł
ę
dny lub te
ż
przetestowa
ć
system wyczerpuj
ą
co, czyli sprawdzi
ć
wszystkie
mo
ż
liwe jego zachowania. Je
ś
li dla wszystkich mo
ż
liwych kombinacji stanów i
wej
ść
system zachowuje si
ę
prawidłowo to znaczy,
ż
e jest bezbł
ę
dny. Niestety
zarówno dowodzenie poprawno
ś
ci jak i wyczerpuj
ą
ce testowanie s
ą
mo
ż
liwe
tylko dla małych systemów. Jako przykład niech posłu
ż
y przedstawiony fragment
kodu. Jak wida
ć
liczba przypadków testowych ro
ś
nie wykładniczo wraz ze
wzrostem liczby wykona
ń
p
ę
tli. Dla jednego jej przebiegu potrzebne s
ą
trzy
przypadki testowe. Dla dwóch przej
ść
potrzebnych jest a
ż
5 wariantów testu, dla
dziesi
ę
ciu ju
ż
tysi
ą
c dwadzie
ś
cia pi
ęć
, a dla sze
ść
dziesi
ę
ciu nawet nie podejm
ę
si
ę
odczytania tej liczby. W ka
ż
dym razie jest ona bardzo du
ż
a.
21
In
ż
ynieria oprogramowania I
Wprowadzenie do testowania (21)
Ograniczenia testowania – c.d.
„Mój wyrób spełni zało
ż
enia, je
ś
li spełni je ka
ż
da
z jego cz
ęś
ci składowych i je
ś
li zmontuj
ę
je
wła
ś
ciwie”
Nie mo
ż
na zało
ż
y
ć
,
ż
e z poszczególnych
poprawnych cz
ęś
ci zawsze powstaje poprawna
cało
ść
Weyuker
Czy w takim razie je
ś
li system podzielony zostanie na mniejsze
podsystemy, które zostan
ą
przetestowane wyczerpuj
ą
co i oka
ż
e si
ę
,
ż
e s
ą
bezbł
ę
dne to oznacza
ć
to b
ę
dzie,
ż
e jest bezbł
ę
dny?
To pytanie skłoniło Elaine Weyuker do sformułowania aksjomatów
testowania, które okre
ś
laj
ą
granice testowania. Niestety nie mo
ż
na zało
ż
y
ć
,
ż
e z
poszczególnych poprawnych cz
ęś
ci zawsze powstaje poprawna cało
ść
. Granice
testowania okre
ś
lone zostały przez trzy aksjomaty: aksjomat
antyekstensjonalno
ś
ci, antydekompozycji oraz aksjomat antykompozycji.
22
In
ż
ynieria oprogramowania I
Wprowadzenie do testowania (22)
Aksjomat antyekstensjonalno
ś
ci
double predkosc(double droga, double czas) {
return (droga / czas);
}
MetryNaSekunde
double predkosc(double droga, double czas) {
return (droga / czas) * 3.6;
}
KilometryNaGodzine
droga=10 metrów,
czas=1 sekunda,
oczekiwany wynik = 10
droga=10 metrów,
czas=1 sekunda,
oczekiwany wynik = 10
Pierwszy z nich, aksjomat antyekstensjonalno
ś
ci, czyli
nierozszerzalno
ś
ci mówi,
ż
e zestaw testów pokrywaj
ą
cy jedn
ą
implementacj
ę
danej specyfikacji nie musi pokrywa
ć
jej innej implementacji. Zestaw testów
odpowiedni dla metody nadklasy mo
ż
e nie by
ć
odpowiedni je
ś
li metoda została
odziedziczona i zasłoni
ę
ta.
Na przykład zestaw testów przygotowany dla algorytmu sortowania
quicksort mo
ż
e nie osi
ą
gn
ąć
100% pokrycia dla sortowania heapsort. Jako inny
przykład zwi
ą
zany z dziedziczeniem mo
ż
e posłu
ż
y
ć
metoda obliczaj
ą
ca
pr
ę
dko
ść
. Zestaw testów dla wariantu podaj
ą
cego wynik w metrach na sekund
ę
b
ę
dzie nieadekwatny dla metody przykrytej przez klas
ę
, w której wynik podawany
jest w kilometrach na godzin
ę
.
23
In
ż
ynieria oprogramowania I
Wprowadzenie do testowania (23)
Aksjomat antydekompozycji
double odwrotnosc(double liczba) {
if (liczba == 0) return 0;
return Math.div(1, liczba);
}
KlasaKorzystujacaZKlasyMath
double div(double arg1, double arg2) {
if (arg2 == 0)
throw new DzieleniePrzezZero();
return arg1 / arg2;
}
Math
Pokrycie instrukcji = 100%
Pokrycie instrukcji = 50%
Aksjomat antydekompozycji mówi,
ż
e pokrycie uzyskane dla
testowanego modułu nie zawsze jest uzyskane dla modułów przez niego
wywoływanych. Zestaw testów pokrywaj
ą
cy klas
ę
lub metod
ę
nie musi pokrywa
ć
obiektów serwera tej klasy lub metody. W przykładzie, który Pa
ń
stwo widzicie
nast
ę
puj
ą
ce warianty testów dla klasy korzystaj
ą
cej z klasy Math spowoduj
ą
100% pokrycie instrukcji tej klasy:
-liczba = 0, wyj
ś
cie = 0;
-liczba = 2, wyj
ś
cie = 0.5
Natomiast nie spowoduj
ą
one wykonania wszystkich instrukcji w klasie Math.
Otó
ż
nie wykonana zostanie ani razu instrukcja wyrzucaj
ą
ca wyj
ą
tek
DzieleniePrzezZero, poniewa
ż
w klasie klienta sprawdzanie jest wyst
ą
pienie
warunku dla 0. Zatem pokrycie instrukcji dla klasy Math wyniesie tylko 50%, co
jest zgodne z aksjomatem antydekompozycji.
24
In
ż
ynieria oprogramowania I
Wprowadzenie do testowania (24)
Aksjomat antykompozycji
Aksjomat antykompozycji
– Zestawy testów, z których ka
ż
dy osobno jest
adekwatny dla segmentów w module,
niekoniecznie s
ą
odpowiednie dla modułu
jako cało
ś
ci
Zestawy testów, z których ka
ż
dy osobno jest adekwatny dla
segmentów w module, niekoniecznie s
ą
odpowiednie dla modułu jako cało
ś
ci. O
tym mówi ostatni z aksjomatów – aksjomat antykompozycji.
25
In
ż
ynieria oprogramowania I
Wprowadzenie do testowania (25)
Pokrycie kodu
• Ile kodu jest pokryte przez testy?
• Pokrycie instrukcji (ang. statement coverage)
– Ka
ż
da instrukcja jest sprawdzana
• Pokrycie gał
ę
zi (ang. branch coverage)
– Ka
ż
da gał
ąź
była odwiedzona
– Instrukcja warunkowa musi by
ć
przynajmniej
raz prawdziwa i przynajmniej raz fałszywa
Posiadaj
ą
c przypadki testowe warto jest wiedzie
ć
jak dokładnie
sprawdzaj
ą
one kod analizowanego systemu. Modele pokrycia kodu umo
ż
liwiaj
ą
zmierzenie ile kodu jest sprawdzane przez testy. Do najpopularniejszych modeli
pokrycia nale
żą
: pokrycie instrukcji oraz pokrycie gał
ę
zi.
Instrukcja jest uznana za pokryt
ą
je
ś
li test wymusi jej wykonanie
przynajmniej raz. Zatem pokrycie instrukcji wynosi 100% je
ś
li ka
ż
da instrukcja w
analizowanym fragmencie kodu jest przynajmniej raz wykonana przez testy.
Drugim popularnym modelem jest pokrycie gał
ę
zi. Wynosi ono
100% w przypadku gdy ka
ż
da gał
ąź
w analizowanym fragmencie kodu jest
przynajmniej raz odwiedzona. Ka
ż
da instrukcja warunkowa musi mie
ć
przynajmniej raz prawdziwy i przynajmniej raz fałszywy warunek by mo
ż
na było
uzna
ć
,
ż
e zostało uzyskane pokrycie gał
ę
zi dla analizowanego fragmentu
programu.
26
In
ż
ynieria oprogramowania I
Wprowadzenie do testowania (26)
Pokrycie instrukcji - przykład
Wystarczy przypadek testowy z liczba = 4
void func(int liczba) {
if ((liczba % 2) == 0)
System.out.println(„liczba parzysta");
for (; liczba < 5; liczba++)
System.out.println(„liczba "+liczba);
}
Przedstawiona tutaj metoda wy
ś
wietla napis „liczba parzysta” w
przypadku gdy podany argument wywołania metody jest liczb
ą
parzyst
ą
. Ponadto
metoda ta wypisuje liczby od 0 do 4, w przypadku gdy argument liczba jest
mniejszy od 5.
By uzyska
ć
pełne pokrycie instrukcji (100%) nale
ż
y zapewni
ć
,
ż
e
liczba jest parzysta oraz,
ż
e jest mniejsza od 5. Wtedy wy
ś
wietlony zostanie
napis „liczba parzysta” oraz wykonana zostanie p
ę
tla. Takie warunki spełnia
przypadek testowy dla argumentu liczba = 4.
27
In
ż
ynieria oprogramowania I
Wprowadzenie do testowania (27)
Pokrycie gał
ę
zi - przykład
void func(int liczba) {
if ((liczba % 2) == 0)
System.out.println(„liczba parzysta");
for (; liczba < 5; liczba++)
System.out.println(„liczba "+liczba);
}
Dwa przypadki testowe: liczba = 4 i liczba = 13
W przypadku pokrycia gał
ę
zi warunek w instrukcji warunkowej if
musi by
ć
przynajmniej raz prawdziwy i przynajmniej raz fałszywy. Tak samo jest
dla warunku w p
ę
tli for.
W pierwszym przypadku, dla instrukcji warunkowej if, by mo
ż
liwe
było spełnienie prawdziwo
ś
ci i fałszywo
ś
ci warunku musi by
ć
podana liczba
parzysta i liczba nieparzysta.
Dla drugiego przypadku wystarczy poda
ć
liczb
ę
mniejsz
ą
od 5.
Warunek p
ę
tli i tak b
ę
dzie fałszywy gdy w wyniku wykonywania p
ę
tli iterowana
zmienna liczba osi
ą
gnie warto
ść
5. W zwi
ą
zku z tym potrzebne s
ą
dwa warianty
testu: liczba = 4 i liczba = 13.
28
In
ż
ynieria oprogramowania I
Wprowadzenie do testowania (28)
Czarne strony pokrycia kodu
• Dla arg1 = 0 oraz arg2 = 0 funkcja przyjmuje
prawidłowy wynik, pokrycie 100%
long multiply(int arg1, int arg2) {
return arg1 + arg2;
}
Niestety uzyskanie pokrycia równego 100% nie gwarantuje
bezbł
ę
dnego programu. Jako przykład mo
ż
e posłu
ż
y
ć
zaprezentowana na
slajdzie implementacja mno
ż
enia. Programista popełnił bł
ą
d pisz
ą
c t
ą
metod
ę
i
zamiast operatora mno
ż
enia wstawił operator dodawania. W zale
ż
no
ś
ci od
danych wej
ś
ciowych bł
ą
d mo
ż
e zosta
ć
nie znaleziony. Je
ś
li wariantem testu
b
ę
dzie przypadek dla argumentów wywołania metody arg1 = 0 i arg2 = 0 to
metoda przyjmie prawidłowy wynik. Pokrycie instrukcji dla takiego przypadku
testowego osi
ą
gnie 100% co mogłoby oznacza
ć
,
ż
e testowany kod jest
bezbł
ę
dny. Nic bardziej mylnego!
29
In
ż
ynieria oprogramowania I
Wprowadzenie do testowania (29)
Czarne strony pokrycia kodu – c.d.
Pokrycie 100% nie zawsze jest mo
ż
liwe
long multiply(int arg1, int arg2) {
return arg1 + arg2;
System.out.println(„Martwy kod");
}
Pokrycie kodu równe 100% nie zawsze jest mo
ż
liwe do osi
ą
gni
ę
cia.
Fragmenty kodu, których nie mo
ż
na uruchomi
ć
(np. martwy kod) spowoduj
ą
zani
ż
enie warto
ś
ci pokrycia mimo i
ż
system mo
ż
e by
ć
przetestowany gruntownie.
W przykładzie pokazanym na slajdzie instrukcja wy
ś
wietlaj
ą
ca napis „martwy
kod” nigdy nie zostanie wykonana, poniewa
ż
wyst
ę
puje po instrukcji powrotu z
metody. Jest to przykład tzw. martwego kodu. Wiele j
ę
zyków w tym m.in. Java
sygnalizuje wyst
ą
pienie takich konstrukcji programu, jednak nie wszystkie np.
kompilator C tego nie zauwa
ż
a.
Mimo swoich słabo
ś
ci modele pokrycia s
ą
szeroko stosowanym
narz
ę
dziem przez osoby testuj
ą
ce oprogramowanie. Umo
ż
liwiaj
ą
one skutecznie
oszacowa
ć
ile systemu zostało sprawdzone przez testy. Nie oceniaj
ą
jednak
efektywno
ś
ci samych przypadków testowych.
30
In
ż
ynieria oprogramowania I
Wprowadzenie do testowania (30)
Testowanie mutacyjne
• Sprawdzanie efektywno
ś
ci testu
• Test T – program działa prawidłowo
• Test T jest efektywny gdy wykryje zmutowany
kod programu.
Do oceny efektywno
ś
ci napisanych testów, czyli skuteczno
ś
ci w
znajdywaniu bł
ę
dów słu
ż
y metoda zwana testowaniem mutacyjnym. Testowanie
mutacyjne powstało na pocz
ą
tku lat 90-tych dwudziestego wieku. Polega ono na
dokonaniu prostej modyfikacji na testowanym kodzie zwanej mutacj
ą
i nast
ę
pnie
sprawdzeniu czy zostanie ona wykryta przez testy. Dobrze napisany wariant testu
powinien zauwa
ż
y
ć
zmian
ę
w zachowaniu kodu b
ę
d
ą
c
ą
wynikiem mutacji i
wykry
ć
tym samym bł
ą
d. Je
ś
li modyfikacja nie zostanie zauwa
ż
ona to oznacza,
ż
e test wymaga najprawdopodobniej uszczegółowienia by móc wykry
ć
zmian
ę
zachowania programu.
31
In
ż
ynieria oprogramowania I
Wprowadzenie do testowania (31)
Testowanie mutacyjne – przykład
Przypadki testowe:
arg1 = 0 i arg2 = 0 – nie wykrywa zmiany
arg1 = 1 i arg2 = 1 – wykrywa zmian
ę
long dodawanie(int arg1, int arg2) {
return arg1 * arg2;
}
W powy
ż
szym przykładzie dla funkcji dodawanie powstał mutant,
który zamiast dodawa
ć
mno
ż
y argumenty funkcji. Przypadek testowy dla obu
argumentów przyjmuj
ą
cych warto
ść
zero nadal przechodzi. Nie wykrywa zmiany,
poniewa
ż
mno
ż
enie dwóch zer daje liczb
ę
0 co jest takim samym wynikiem jak
dodanie ze sob
ą
dwóch zer. Ten przypadek testowy powinien by
ć
poprawiony lub
usuni
ę
ty z listy przypadków testowych, poniewa
ż
nie jest w stanie wykry
ć
bł
ę
du,
który wprowadził mutant.
Dla przypadku gdy oba argumenty przyjmuj
ą
warto
ść
1 bł
ą
d
wprowadzony przez mutanta zostanie wykryty. Ten przypadek testowy jest
uznany za dobry.
Niestety testowanie mutacyjne nie jest szeroko wykorzystywane w
praktyce ze wzgl
ę
du na do
ść
du
ż
y czas potrzebny na jego przeprowadzenie.
Trzeba wykona
ć
mutacj
ę
na kodzie, przekompilowa
ć
go i nast
ę
pnie uruchomi
ć
dla niego testy. To wszystko zajmuje sporo czasu je
ś
li we
ź
mie si
ę
pod uwag
ę
rozmiar obecnie wytwarzanego oprogramowania.
32
In
ż
ynieria oprogramowania I
Wprowadzenie do testowania (32)
Rodzaje testów
• Testy jednostkowe
• Testy integracyjne
• Testy systemowe
• Testy akceptacyjne
Testy mo
ż
na podzieli
ć
ze wzgl
ę
du na przedmiot testowania.
Standard IEEE 610.12 z roku 1990 definiuje testy jednostkowe, integracyjne oraz
systemowe.
33
In
ż
ynieria oprogramowania I
Wprowadzenie do testowania (33)
Rodzaje testów
• Testy jednostkowe
• Testy integracyjne
• Testy systemowe
• Testy akceptacyjne
Testy jednostkowe wykonuje programista w
ś
rodowisku
laboratoryjnym. Celem tych testów jest sprawdzenie pojedynczej jednostki
oprogramowania jak
ą
jest klasa, metoda, czy te
ż
zbiór współpracuj
ą
cych ze sob
ą
klas (tzw. klaster klas).
34
In
ż
ynieria oprogramowania I
Wprowadzenie do testowania (34)
Rodzaje testów
• Testy jednostkowe
• Testy integracyjne
• Testy systemowe
• Testy akceptacyjne
Przetestowane jednostki kodu s
ą
nast
ę
pnie ł
ą
czone w wi
ę
ksz
ą
cało
ść
. Podczas integracji przeprowadzane s
ą
testy integracyjne. Ich zadaniem
jest sprawdzenie ł
ą
czonych fragmentów kodu. Weryfikowana jest współpraca
integrowanych jednostek mi
ę
dzy sob
ą
. Celem jest okre
ś
lenie czy po
zintegrowaniu otrzymany podsystem nadaje si
ę
do dalszego testowania. Proces
ł
ą
czenia i testowania jest powtarzany a
ż
do powstania całego systemu. Testy te
wykonywane s
ą
przez grup
ę
programistów w
ś
rodowisku laboratoryjnym
odpowiedzialn
ą
za ł
ą
czone moduły.
35
In
ż
ynieria oprogramowania I
Wprowadzenie do testowania (35)
Rodzaje testów
• Testy jednostkowe
• Testy integracyjne
• Testy systemowe
• Testy akceptacyjne
Testy systemowe wykonywane s
ą
po pomy
ś
lnej integracji jednostek
wchodz
ą
cych w skład systemu b
ę
d
ą
cego przedmiotem testowania. Wykonywane
s
ą
przez programistów lub niezale
ż
ny zespół w kontrolowanym
ś
rodowisku
laboratoryjnym. Sprawdzaj
ą
one czy system jako cało
ść
spełnia wymagania
funkcjonalne i jako
ś
ciowe postawione przez klienta.
36
In
ż
ynieria oprogramowania I
Wprowadzenie do testowania (36)
Rodzaje testów
• Testy jednostkowe
• Testy integracyjne
• Testy systemowe
• Testy akceptacyjne
Przetestowany system trafia nast
ę
pnie do u
ż
ytkowników
ko
ń
cowych (klienta), gdzie nast
ę
pnie poddawany jest kolejnym testom. Tym
razem to u
ż
ytkownik lub reprezentant klienta sprawdza system. Testy
przeprowadzane s
ą
w
ś
rodowisku docelowym lub jak najbardziej zbli
ż
onym do
niego. Sprawdzane jest czy system spełnia oczekiwania klienta.
Testowanie nale
ż
y przeprowadza
ć
zaczynaj
ą
c od testów
jednostkowych (zaczynaj
ą
c od metod przechodz
ą
c nast
ę
pnie w klasy, klastry,
pakiety itd.), przez testy integracyjne na testach systemowych sko
ń
czywszy.
Niestety wi
ę
kszo
ść
firm testuje tylko na poziomie systemowym nie doceniaj
ą
c
ni
ż
szych warstw testowania co zwi
ę
ksza koszty zwi
ą
zane z usuwaniem bł
ę
dów,
bo wykrywane jest mniej bł
ę
dów, a te znalezione trudniej jest zlokalizowa
ć
i
poprawi
ć
.
37
In
ż
ynieria oprogramowania I
Wprowadzenie do testowania (37)
Testowanie regresyjne
Testowanie regresyjne
– Ponowne wykonanie opracowanych
wcze
ś
niej testów
Test na dym (ang. smoke test)
– Czy program nadal si
ę
uruchamia?
W przypadku gdy przetestowany wcze
ś
niej system uległ modyfikacji
czy to na skutek poprawy bł
ę
du, czy te
ż
w wyniku zmiany wymaga
ń
ze strony
klienta, nale
ż
y go ponownie przetestowa
ć
. Do tego celu mog
ą
słu
ż
y
ć
opracowane
wcze
ś
niej testy. Testowanie takie nazywa si
ę
testowaniem regresyjnym. Jest to
ponowne wykonanie opracowanych wcze
ś
niej testów by sprawdzi
ć
czy
wprowadzone modyfikacje w programie nie spowodowały powstania bł
ę
du.
Uproszczona forma testowania regresyjnego zwana testem na dym (ang. smoke
test) sprawdza czy w wyniku modyfikacji program nadal si
ę
uruchamia.
Testowanie regresyjne mo
ż
e by
ć
przeprowadzone je
ś
li modyfikacje systemu nie
były znacz
ą
ce. W przeciwnym przypadku konieczna jest tak
ż
e modyfikacja
samych wariantów testu.
38
In
ż
ynieria oprogramowania I
Wprowadzenie do testowania (38)
Metody tworzenia testów
• Metoda białej skrzynki (ang. white-box testing)
– Sprawdza wewn
ę
trzn
ą
struktur
ę
programu
– testy jednostkowe, testy integracyjne
• Metoda czarnej skrzynki (ang. black-box testing)
– Nie bierze pod uwag
ę
wewn
ę
trznej struktury
programu
– Wszystkie rodzaje testowania
Przy przygotowywaniu wariantów testu stosowane s
ą
generalnie
dwie techniki: metoda białej skrzynki oraz metoda czarnej skrzynki.
Metoda białej skrzynki opiera si
ę
na analizie kodu, który ma by
ć
testowany. Sprawdzana jest jego wewn
ę
trzna struktura. Na podstawie tych
informacji konstruowane s
ą
przypadki testowe. Niestety wykorzystuj
ą
c tylko t
ą
metod
ę
łatwo jest pomin
ąć
pewne przypadki testowe, gdy
ż
analiza samego kodu
nie poda nie zaimplementowanych wariantów zachowania systemu. Ta metoda
nadaje si
ę
do testów jednostkowych, oraz integracyjnych, dla których znajomo
ść
kodu
ź
ródłowego jest konieczna.
Testowanie metod
ą
czarnej skrzynki nazywane te
ż
inaczej
testowaniem funkcjonalnym opiera si
ę
na analizie powinno
ś
ci testowanego
systemu np. na podstawie specyfikacji wymaga
ń
. W ten sposób nie pominie si
ę
testowania istotnych zachowa
ń
systemu. Ta metoda nadaje si
ę
do wszystkich
rodzajów testowania, jednak nie wyklucza stosowania metody białej skrzynki. Ze
wzgl
ę
du na du
ż
y koszt zwi
ą
zany z testowaniem metod
ą
czarnej skrzynki stosuje
si
ę
obie metody. Testowanie metod
ą
białej skrzynki wykorzystywane jest
wsz
ę
dzie tam gdzie testy wykonane metod
ą
czarnej skrzynki s
ą
zbyt kosztowne.
W pozostałych przypadkach testy tworzone s
ą
w oparciu o powinno
ś
ci systemu.
39
In
ż
ynieria oprogramowania I
Wprowadzenie do testowania (39)
Profil bł
ę
dów
0
5
10
15
20
25
30
35
Requirements
analysis
High-level
design
Low-level
design
Coding
Unit test
Integration
test
System test Beta ship
Bł
ę
dy/KLOC
Poznaj
ą
c rodzaje testów nasuwa si
ę
pytanie, do którego etapu
warto testowa
ć
? Przedstawiony na tym slajdzie wykres uzasadnia konieczno
ść
stosowania ró
ż
nych rodzajów testowania. Na wykresie pokazana jest ilo
ść
bł
ę
dów przypadaj
ą
cych na 1000 linii kodu
ź
ródłowego w zale
ż
no
ś
ci od fazy
wytwarzania oprogramowania.
Warto zauwa
ż
y
ć
,
ż
e na ka
ż
dym etapie wykrywane s
ą
bł
ę
dy.
Najwi
ę
cej przypada na etap kodowania. Najmniej powinno przypada
ć
po oddaniu
systemu do produkcji. Nasuwa si
ę
wniosek,
ż
e testowanie jednostkowe nie
wykrywa wszystkich bł
ę
dów, podobnie jak testy systemowe. W zwi
ą
zku z tym
ka
ż
dy z rodzajów testowania jest konieczny do uzyskania produktu, który spełni
oczekiwania klienta.
40
In
ż
ynieria oprogramowania I
Wprowadzenie do testowania (40)
Koszt poprawienia bł
ę
du
Problem Y2K
– Koszt ~ 1/1000 (nie uwzgl
ę
dniaj
ą
c inflacji)
Wyniki bada
ń
przeprowadzonych przez Boehma w latach
osiemdziesi
ą
tych jak i obecnie prowadzone badania potwierdzaj
ą
,
ż
e koszt
poprawy bł
ę
du ro
ś
nie wykładniczo w zale
ż
no
ś
ci od etapu wytwarzania
oprogramowania. Najmniej kosztuje poprawa na etapie analizy, najwi
ę
cej po
wdro
ż
eniu systemu do produkcji.
Je
ś
liby bł
ą
d zwi
ą
zany z rokiem 2000 usun
ąć
na etapie
implementacji to koszt z tym zwi
ą
zany byłby tysi
ą
ckrotnie ni
ż
szy w stosunku do
kosztu zwi
ą
zanego z jego popraw
ą
po wdro
ż
eniu systemu.
W wi
ę
kszo
ś
ci procesów wytwarzania testowanie systemu jest
wykonywane na samym ko
ń
cu. Oznacza to,
ż
e jest ono szczególnie nara
ż
one na
przekroczenie kosztów i harmonogramu, co oznacza po prostu,
ż
e czas
potrzebny na testowanie jest obcinany, poniewa
ż
wcze
ś
niejsze fazy przekroczyły
termin i bud
ż
et.
41
In
ż
ynieria oprogramowania I
Wprowadzenie do testowania (41)
Testowanie a debugowanie
Wyniki testów
Specyfikacja
Przypadki
testowe
Lokalizacja
bł
ę
du
Projekt
naprawy bł
ę
du
Naprawa
bł
ę
du
Ponowne
testy kodu
Testowanie != debugowanie
Testowanie jest cz
ę
sto mylone z debugowaniem. Powy
ż
szy
schemat ilustruje z jakich cz
ęś
ci składa si
ę
debugowanie. Na samym pocz
ą
tku po
wykonaniu testów wyniki ich wykonania s
ą
analizowane by znale
źć
te warianty,
które wykryły bł
ą
d. Na podstawie logów z wykonania testu lokalizowana jest
usterka. Nast
ę
pnie w oparciu o specyfikacj
ę
systemu, tworzony jest projekt jego
naprawy. Zawiera on list
ę
czynno
ś
ci, które musz
ą
by
ć
wykonane by usterka była
poprawiona. Miejsce, w którym bł
ą
d jest zaszyty zostanie nast
ę
pnie poprawione
zgodnie z wcze
ś
niej ustalonym projektem. Zmodyfikowany system jest ponownie
testowany by sprawdzi
ć
czy zmiany nie wprowadziły nowych bł
ę
dów, a tak
ż
e po
to by zweryfikowa
ć
czy modyfikacja została przeprowadzona prawidłowo.
Jak wida
ć
testowanie i debugowanie to dwa osobne procesy.
Testowanie koncentruje si
ę
na znajdywaniu bł
ę
dów podczas gdy debugowanie
zajmuje si
ę
ich lokalizacj
ą
i usuwaniem.
42
In
ż
ynieria oprogramowania I
Wprowadzenie do testowania (42)
Inspekcje a testowanie
• Anga
ż
uj
ą
ludzi do
przegl
ą
dania
ź
ródłowej
reprezentacji systemu
• Nie wymagaj
ą
uruchomienia systemu,
wi
ę
c mog
ą
by
ć
u
ż
yte przed
jego stworzeniem
• Mog
ą
by
ć
zastosowane dla
dowolnej reprezentacji
systemu (wymagania,
projekt itd.)
• Bardzo efektywna technika
znajdowania bł
ę
dów
Inspekcje nale
żą
do statycznych technik analizy. Statyczna
reprezentacja systemu (np. kod
ź
ródłowy) jest przegl
ą
dana przez ludzi w celu
wykrycia anomalii i defektów. Technika ta nie wymaga uruchomienia systemu,
wi
ę
c mo
ż
e by
ć
u
ż
yta przed jego stworzeniem na dowolnym etapie jego
wytwarzania. Tego niestety nie mo
ż
na powiedzie
ć
o testowaniu. Mało tego, przy
pomocy inspekcji mo
ż
na zweryfikowa
ć
o wiele wi
ę
cej ró
ż
nego rodzaju artefaktów.
Testowanie mo
ż
e sprawdzi
ć
tylko i wył
ą
cznie działanie systemu lub ewentualnie
zweryfikowa
ć
specyfikacj
ę
wymaga
ń
badaj
ą
c prototyp, który powstanie na jej
podstawie. Inspekcja jest bardzo efektywn
ą
metod
ą
znajdywania bł
ę
dów,
skuteczniejsz
ą
od samego testowania. Wymaga jednak zaanga
ż
owania wi
ę
kszej
grupy ludzi. Jednak ten koszt jest szybko równowa
ż
ony zyskiem zwi
ą
zanym z
usuni
ę
ciem bł
ę
du na samym pocz
ą
tku jego wyst
ę
powania w stosunku do faz
ko
ń
cowych kiedy to bł
ę
dy mogłyby by
ć
znalezione przez testowanie.
43
In
ż
ynieria oprogramowania I
Wprowadzenie do testowania (43)
Inspekcje a testowanie – c.d.
• Wiele ró
ż
nych bł
ę
dów mo
ż
e zosta
ć
znalezione
przez pojedyncz
ą
inspekcj
ę
• W przypadku testowania, bł
ą
d mo
ż
e ukry
ć
inny
bł
ą
d
• Powtórne wykonanie testu w przypadku
znalezienia i usuni
ę
cia bł
ę
du
Ponadto przy pomocy pojedynczej inspekcji mo
ż
liwe jest
znalezienie wielu ró
ż
nych bł
ę
dów. Niestety w przypadku testowania, bł
ą
d mo
ż
e
ukrywa
ć
inny bł
ą
d. Usuwaj
ą
c usterk
ę
mo
ż
na doprowadzi
ć
do ujawnienia innej. W
przypadku gdy bł
ą
d zostanie znaleziony i usuni
ę
ty wymagane jest powtórne
wykonanie testów celem zweryfikowania czy wprowadzone modyfikacje odniosły
nale
ż
yty skutek.
44
In
ż
ynieria oprogramowania I
Wprowadzenie do testowania (44)
Inspekcje a testowanie – c.d.
• Inspekcje i testowanie s
ą
komplementarnymi technikami
weryfikacji
• Obie powinny by
ć
u
ż
ywane podczas procesu weryfikacji
i walidacji
• Inspekcje mog
ą
znale
źć
zgodno
ść
ze specyfikacj
ą
• Nie sprawdz
ą
zgodno
ś
ci z rzeczywistymi oczekiwaniami
u
ż
ytkownika
• Inspekcje nie mog
ą
sprawdzi
ć
wymaga
ń
niefunkcjonalnych takich jak np. wydajno
ść
Porównuj
ą
c inspekcje i testowanie dochodzi si
ę
do wniosku,
ż
e s
ą
to komplementarne techniki weryfikacji i walidacji. Nie s
ą
przeciwstawne, w
zwi
ą
zku z tym mog
ą
by
ć
wykonywane razem. Inspekcje mog
ą
znale
źć
bł
ę
dy
zwi
ą
zane z niezgodno
ś
ci
ą
ze specyfikacj
ą
, ale nie sprawdz
ą
zgodno
ś
ci z
rzeczywistymi oczekiwaniami u
ż
ytkownika. Do tego najlepiej nadaj
ą
si
ę
testy.
Ponadto inspekcje nie sprawdz
ą
wymaga
ń
niefunkcjonalnych jakimi s
ą
mi
ę
dzy
innymi ograniczenia wydajno
ś
ciowe, czy obci
ąż
eniowe. Do tego równie
ż
najlepiej
nadaje si
ę
testowanie. Podczas gdy inspekcje mo
ż
na praktycznie wykorzysta
ć
na
ka
ż
dym etapie wytwarzania oprogramowania, testowanie jest jedynie w stanie
zwalidowa
ć
zaimplementowany ju
ż
system lub te
ż
sprawdzi
ć
wymagania na
podstawie zaimplementowanego prototypu.
45
In
ż
ynieria oprogramowania I
Wprowadzenie do testowania (45)
Podsumowanie
• Weryfikacja
„Czy budujemy prawidłowo produkt?”
• Walidacja
„Czy budujemy prawidłowy produkt?”
• Testowanie – wykonanie kodu dla
kombinacji danych wej
ś
ciowych i
stanów w celu wykrycia bł
ę
dów
• „Nie mo
ż
na zało
ż
y
ć
,
ż
e z
poszczególnych poprawnych cz
ęś
ci
zawsze powstaje poprawna cało
ść
”
• Testowanie != debugowanie
• Testowanie != Inspekcje
Na koniec wykładu pragn
ę
podsumowa
ć
zagadnienia, które poznali
Pa
ń
stwo w ci
ą
gu tej godziny.
Po pierwsze zdefiniowane zostało czym jest weryfikacja, a czym
walidacja oprogramowania. Weryfikacja to znajdywanie bł
ę
dów zwi
ą
zanych z
nieprawidłow
ą
implementacj
ą
wymaga
ń
. Walidacja to sposób na znajdywanie
bł
ę
dów zwi
ą
zanych z nieprawidłow
ą
definicj
ą
wymaga
ń
.
Testowanie polega na wykonaniu kodu dla kombinacji danych
wej
ś
ciowych i stanów w celu wykrycia bł
ę
dów. Prosz
ę
zauwa
ż
y
ć
,
ż
e jest to
technika dynamiczna – wymaga uruchomienia systemu (lub jego fragmentu), a jej
cel to wykazanie,
ż
e system zawiera bł
ę
dy.
Niestety na mocy trzech aksjomatów testowania nie mo
ż
na zało
ż
y
ć
,
ż
e z poszczególnych poprawnych cz
ęś
ci zawsze powstaje poprawna cało
ść
.
Testowanie jako technika weryfikacji i walidacji, skupia si
ę
na
wykryciu bł
ę
du podczas gdy debugowanie koncentruje si
ę
na lokalizacji i
naprawie tych bł
ę
dów.
Inspekcje i testowanie to komplementarne techniki weryfikacji, które
mog
ą
by
ć
stosowane razem.