Io 10 Wprowadzenie do testowania

background image

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.

background image

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.

background image

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.

background image

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

ą

ę

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.

background image

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

ę

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.

background image

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ł

ą

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.

background image

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

ć

ę

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.

background image

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.

background image

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.

background image

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.

background image

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.

background image

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.

background image

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.

background image

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

ą

ę

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.

background image

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.

background image

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.

background image

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.

background image

18

In

ż

ynieria oprogramowania I

Wprowadzenie do testowania (18)

Ograniczenia testowania

„Testowanie mo

ż

e ujawni

ć

obecno

ść

ę

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

ść

ę

dów, ale nie ich

brak. Zatem testowanie jako jedyna technika zapewniania jako

ś

ci jest

niewystarczaj

ą

ca.

background image

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.

background image

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

ę

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.

background image

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.

background image

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

ę

.

background image

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.

background image

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.

background image

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.

background image

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.

background image

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.

background image

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!

background image

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.

background image

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.

background image

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

ć

ę

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.

background image

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.

background image

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

background image

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.

background image

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.

background image

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

ć

.

background image

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.

background image

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.

background image

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

ę

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

ść

ę

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

ą

ę

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.

background image

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.

background image

41

In

ż

ynieria oprogramowania I

Wprowadzenie do testowania (41)

Testowanie a debugowanie

Wyniki testów

Specyfikacja

Przypadki

testowe

Lokalizacja

ę

du

Projekt

naprawy bł

ę

du

Naprawa

ę

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.

background image

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.

background image

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

ą

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.

background image

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

źć

ę

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.

background image

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

ę

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.


Wyszukiwarka

Podobne podstrony:
4.1.2 Fale sinusoidalne i prostokątne, 4.1 Wprowadzenie do testowania kabli opartego na częstotliwoś
10 wprowadzenie do robotyki nowy
4.1.3 Wykładniki i logarytmy, 4.1 Wprowadzenie do testowania kabli opartego na częstotliwości
10. Wprowadzenie do mózgowia. 18.04.2012, I rok, I rok, Anatomia
4.1.7 Szum w dziedzinie czasu i częstotliwości, 4.1 Wprowadzenie do testowania kabli opartego na czę
4.1.5 Przedstawianie sygnałów w dziedzinie czasu i częstotliwości, 4.1 Wprowadzenie do testowania ka
4.1.6 Sygnały analogowe i cyfrowe w dziedzinie czasu i częstotliwości, 4.1 Wprowadzenie do testowani
4.1.4 Decybele, 4.1 Wprowadzenie do testowania kabli opartego na częstotliwości
4.1.8 Szerokość pasma, 4.1 Wprowadzenie do testowania kabli opartego na częstotliwości
10 wprowadzenie do robotyki nowy
10 Wprowadzenie do mózgowia  04 2012
10 Wprowadzenie do Oracle 2012
10 Wprowadzenie do mózgowia  04 2012
4.1.1 Fale, 4.1 Wprowadzenie do testowania kabli opartego na częstotliwości
10 Wprowadzenie do programowania robotów przemysłowych
4.1.2 Fale sinusoidalne i prostokątne, 4.1 Wprowadzenie do testowania kabli opartego na częstotliwoś
10 wprowadzenie do robotyki nowy

więcej podobnych podstron