io-10-wyk

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

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

jako

ść

efektu ko

cowego. Dobrze jest wi

c spojrze

ogólnie na proces weryfikacji

i walidacji i zastanowi

do czego tak naprawd

testowanie mo

wykorzysta

. Maj

c to na uwadze proponuj

stwu – w ramach in

ynierii

oprogramowania - wykład wprowadzaj

cy do testowania.

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.

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

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.

ynieria oprogramowania I

Wprowadzenie do testowania (4)

Notoryczne bł

• 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

ąŜ

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

przypadek

mierci pacjentów chorych na raka,

którzy otrzymali nadmierne dawki promieniowania. Therac-25, maszyna słu

Ŝą

do terapii raka, na skutek sytuacji wy

cigu, czyli bł

dnej implementacji

współbie

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ł

ynieria oprogramowania I

Wprowadzenie do testowania (5)

Notoryczne bł

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

kszo

ść

sprzedawanych obecnie komputerów oparta jest na produktach tej

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,

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.

ynieria oprogramowania I

Wprowadzenie do testowania (6)

Notoryczne bł

• 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

e przechowa

zmienna 16-bitowa, co

spowodowało utrat

orientacji w przestrzeni i zmian

kierunku lotu powoduj

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.

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

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

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.

ynieria oprogramowania I

Wprowadzenie do testowania (8)

Proces weryfikacji i walidacji

• Weryfikacja i walidacja musi wykonywana na

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

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

sze koszty usuwania znalezionych bł

dów. Cz

sto zdarza si

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.

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

ęś

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.

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

statyczne techniki mo

liwe jest sprawdzenie systemu od specyfikacji wymaga

projektu architektury systemu, specyfikacji formalnej a

po program

sko

czywszy, podczas gdy dynamiczn

technik

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.

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

wtedy mo

na uzna

e proces weryfikacji i walidacji zako

czył si

powodzeniem.

ynieria oprogramowania I

Wprowadzenie do testowania (12)

Poziom pewno

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

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

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

ąć

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

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.

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

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

oby

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

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

na wiele. W planie testów powinno by

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.

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ł

Efektywno

ść

testu = zdolno

ść

znajdywania bł

dów

Zdefiniujmy poj

cie testowania. Według definicji podanej w ksi

ąŜ

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

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

cznie lub poddaje automatyzacji,

czyli napisaniu oprogramowania, które wypróbowuje inny system
oprogramowania w celu znalezienia bł

du. Uzyskane wyniki analizuje si

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

test jest efektywny je

li znajduje bł

dy z maksymalnym prawdopobie

stwem.

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

nast

puj

elementy:

- stan wst

pny, czyli stan testowanego systemu b

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.

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

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ł

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

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.

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

na sprawdzi

tylko i wył

cznie przy pomocy testowania.

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;

}

1025

1 152 921 504 606 847 200

Path No.

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

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

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

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

odczytania tej liczby. W ka

dym razie jest ona bardzo du

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

z jego cz

ęś

ci składowych i je

li zmontuj

wła

ciwie”

Nie mo

na zało

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

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.

ynieria oprogramowania I

Wprowadzenie do testowania (22)

Aksjomat antyekstensjonalno

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

ąć

100% pokrycia dla sortowania heapsort. Jako inny

przykład zwi

zany z dziedziczeniem mo

e posłu

metoda obliczaj

dko

ść

. Zestaw testów dla wariantu podaj

cego wynik w metrach na sekund

dzie nieadekwatny dla metody przykrytej przez klas

, w której wynik podawany

jest w kilometrach na godzin

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.

ynieria oprogramowania I

Wprowadzenie do testowania (24)

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

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.

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

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.

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

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.

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.

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

zaprezentowana na

slajdzie implementacja mno

enia. Programista popełnił bł

d pisz

c t

metod

zamiast operatora mno

enia wstawił operator dodawania. W zale

ci od

danych wej

ciowych bł

d mo

e zosta

nie znaleziony. Je

li wariantem testu

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!

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

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.

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

zmian

w zachowaniu kodu b

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.

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ł

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

ść

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.

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.

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

cego przedmiotem testowania. Wykonywane

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.

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

cowych (klienta), gdzie nast

pnie poddawany jest kolejnym testom. Tym

razem to u

ytkownik lub reprezentant klienta sprawdza system. Testy

przeprowadzane s

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

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

poprawi

ynieria oprogramowania I

Wprowadzenie do testowania (37)

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

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.

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

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.

ynieria oprogramowania I

Wprowadzenie do testowania (39)

Profil bł

dów

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

ci od fazy

wytwarzania oprogramowania.

Warto zauwa

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

dy z rodzajów testowania jest konieczny do uzyskania produktu, który spełni

oczekiwania klienta.

ynieria oprogramowania I

Wprowadzenie do testowania (40)

Koszt poprawienia bł

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

ci od etapu wytwarzania

oprogramowania. Najmniej kosztuje poprawa na etapie analizy, najwi

cej po

wdro

eniu systemu do produkcji.

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.

ynieria oprogramowania I

Wprowadzenie do testowania (41)

Testowanie a debugowanie

Wyniki testów

Specyfikacja

Przypadki

testowe

Lokalizacja

bł

Projekt

naprawy bł

Naprawa

bł

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

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.

ynieria oprogramowania I

Wprowadzenie do testowania (42)

Inspekcje a testowanie

• Anga

ludzi do

przegl

dania

ródłowej

reprezentacji systemu

• Nie wymagaj

uruchomienia systemu,
wi

c mog

yte przed

jego stworzeniem

• Mog

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

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

cowych kiedy to bł

dy mogłyby by

znalezione przez testowanie.

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ł

• Powtórne wykonanie testu w przypadku

znalezienia i usuni

cia bł

Ponadto przy pomocy pojedynczej inspekcji mo

liwe jest

znalezienie wielu ró

nych bł

dów. Niestety w przypadku testowania, bł

d mo

ukrywa

inny bł

d. Usuwaj

c usterk

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.

ynieria oprogramowania I

Wprowadzenie do testowania (44)

Inspekcje a testowanie – c.d.

• Inspekcje i testowanie s

komplementarnymi technikami

weryfikacji

• Obie powinny by

ywane podczas procesu weryfikacji

i walidacji

• Inspekcje mog

znale

źć

zgodno

ść

ze specyfikacj

• Nie sprawdz

zgodno

ci z rzeczywistymi oczekiwaniami

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

wykonywane razem. Inspekcje mog

znale

źć

bł

zwi

zane z niezgodno

ze specyfikacj

, ale nie sprawdz

zgodno

ci z

rzeczywistymi oczekiwaniami u

ytkownika. Do tego najlepiej nadaj

testy.

Ponadto inspekcje nie sprawdz

wymaga

niefunkcjonalnych jakimi s

dzy

innymi ograniczenia wydajno

ciowe, czy obci

ąŜ

eniowe. Do tego równie

najlepiej

nadaje si

testowanie. Podczas gdy inspekcje mo

na praktycznie wykorzysta

dym etapie wytwarzania oprogramowania, testowanie jest jedynie w stanie

zwalidowa

zaimplementowany ju

system lub te

sprawdzi

wymagania na

podstawie zaimplementowanego prototypu.

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

e z

poszczególnych poprawnych cz

ęś

zawsze powstaje poprawna cało

ść

”

• Testowanie != debugowanie
• Testowanie != Inspekcje

Na koniec wykładu pragn

podsumowa

zagadnienia, które poznali

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

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

e z poszczególnych poprawnych cz

ęś

ci zawsze powstaje poprawna cało

ść

Testowanie jako technika weryfikacji i walidacji, skupia si

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

stosowane razem.