Wykład 10

dr in . Włodzimierz D browski

P

olsko

J

apo ska

W

y sza

S

zkoła

T

echnik

K

omputerowych

Katedra Systemów Informacyjnych, pokój 310

e-mail:

[e-mail]

Materiał wył cznie do u ytku przez studentów PJWSTK kursu BYT.

Copyright © 2002 – 2004 by W. D browski - wszelkie prawa zastrze one.

Materiał ani jego cz

nie mo e by w adnej formie i za pomoc jakichkolwiek rodków technicznych reprodukowany bez zgody wła ciciela praw autorskich.

Wersja PB

Budowa i integracja

systemów informacyjnych

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 10, Slajd 2

marzec, 2004; PB

Faza testowania

Okre lenie wymaga

Projektowanie

Implementacja

Testowanie

Konserwacja

Faza strategiczna

Analiza

Instalacja

Dokumentacja

Rozró nia si nast puj ce terminy:

Weryfikacja (verification) - testowanie zgodno ci systemu z wymaganiami

zdefiniowanymi w fazie okre lenia wymaga .

Atestowanie (validation) - ocena systemu lub komponentu podczas lub na ko cu

procesu jego rozwoju na zgodno ci z wyspecyfikowanymi wymaganiami.

Atestowanie jest wi c weryfikacj ko cow .

Dwa główne cele testowania:

- wykrycie i usuni cie bł dów w systemie

- ocena niezawodno ci systemu

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 10, Slajd 3

marzec, 2004; PB

Weryfikacja oznacza...

Przegl dy, inspekcje, testowanie, sprawdzanie, audytowanie lub inn działalno

ustalaj c i dokumentuj c czy składowe, procesy, usługi lub dokumenty zgadzaj

si z wyspecyfikowanymi wymaganiami.
Oceny systemu lub komponentu maj ce na celu okre lenie czy produkt w danej

fazie rozwoju oprogramowania spełnia warunki zakładane podczas startu tej fazy.

Weryfikacja wł cza nast puj ce czynno ci:
Przegl dy techniczne oraz inspekcje oprogramowania.
Sprawdzanie czy wymagania na oprogramowanie s zgodne z wymaganiami

u ytkownika.
Sprawdzanie czy komponenty projektu s zgodne z wymaganiami na

oprogramowanie.
Testowanie jednostek oprogramowania (modułów).
Testowanie integracji oprogramowania, testowanie systemu.
Testowanie akceptacji systemu przez u ytkowników
Audyt.

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 10, Slajd 4

marzec, 2004; PB

Zwi zek faz projektu z fazami testowania

Definicja wymaga

u ytkownika

Definicja wymaga

na oprogramowanie

Projektowanie

architektury

Szczegółowe

projektowanie

Kodowanie

Testowanie

modułów

Testowanie

integracji

Testowanie cało ci

systemu

Testowanie akceptacji

u ytkowników

Decyzja o budowie

oprogramowania

Zaakceptowane

oprogramowanie

Fazy projektu maj

swoje odpowiedniki w

fazach testowania

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 10, Slajd 5

marzec, 2004; PB

Przegl dy oprogramowania

Przegl d jest procesem lub spotkaniem, podczas którego produkt roboczy lub

pewien zbiór produktów roboczych jest prezentowany dla personelu projektu,

kierownictwa, u ytkowników, klientów lub innych zainteresowanych stron

celem uzyskania komentarzy, opinii i akceptacji.
Przegl dy mog by formalne i nieformalne.

Formalne przegl dy mog mie nast puj c posta :
Przegl d techniczny. Oceniaj elementy oprogramowania na zgodno post pu

prac z przyj tym planem.

(Szczegóły mo na znale w ANSI/IEEE Std 1028-1988

„IEEE Standard for Reviews and Audits”).

Przej cie (walkthrough). Wczesna ocena dokumentów, modeli, projektów i

kodu. Celem jest zidentyfikowanie defektów i rozwa enie mo liwych

rozwi za . Wtórnym celem jest szkolenie i rozwi zanie problemów

stylistycznych (np. z form kodu, dokumentacji, interfejsów u ytkownika).
Audyt. Przegl dy potwierdzaj ce zgodno oprogramowania z wymaganiami,

specyfikacjami, zaleceniami, standardami, procedurami, instrukcjami,

kontraktami i licencjami. Obiektywno audytu wymaga, aby był on

przeprowadzony przez osoby niezale ne od zespołu projektowego.

reviews

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 10, Slajd 6

marzec, 2004; PB

Skład zespołu oceniaj cego oprogramowanie

Dla powa nych projektów ocena oprogramowania nie mo e by wykonana w

sposób amatorski. Musi by powołany zespół, którego zadaniem b dzie zarówno

przygotowanie testów jak i ich przeprowadzenie.

Potencjalny skład zespołu oceniaj cego:

• Kierownik

• Sekretarz

• Członkowie, w tym:

- u ytkownicy

- kierownik projektu oprogramowania

- in ynierowie oprogramowania

- bibliotekarz oprogramowania

- personel zespołu zapewnienia jako ci

- niezale ny personel weryfikacji i atestowania

- niezale ni eksperci nie zwi zani z rozwojem projektu

Zadania kierownika: nominacje na członków zespołu, organizacja przebiegu oceny i

spotka zespołu, rozpowszechnienie dokumentów oceny pomi dzy członków zespołu,

organizacja pracy, przewodniczenie posiedzeniom, wydanie ko cowego raportu, i by

mo e inne zadania.

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 10, Slajd 7

marzec, 2004; PB

Co to jest audyt?

audit

Audytem nazywany jest niezale ny przegl d i ocena jako ci oprogramowania, która

zapewnia zgodno z wymaganiami na oprogramowanie, a tak e ze specyfikacj ,

generalnymi zało eniami, standardami, procedurami, instrukcjami, kodami oraz

kontraktowymi i licencyjnymi wymaganiami.

Aby zapewni obiektywno , audyt powinien by przeprowadzony przez osoby

niezale ne od zespołu projektowego.

Audyt powinien by przeprowadzany przez odpowiedni organizacj audytu (która

aktualnie formuje si w Polsce, Polskie Stowarzyszenie Audytu) lub przez osoby

posiadaj ce uprawnienia/licencj audytorów.

Reguły i zasady audytu s okre lone w normie:

ANSI/IEEE Std 1028-1988 „IEEE Standard for Reviews and Audits”.

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 10, Slajd 8

marzec, 2004; PB

Aspekty audytu

Przykłady

Analiza stanu projektu

Analiza celowo ci

Analiza procesu wytwórczego

Analiza dowolnego procesu

Analiza systemu jako ci

Analiza stosowania systemu jako ci

Relacje odbiorca dostawca

audyt wewn trzny

audyt zewn trzny

audyt „trzeciej strony”

Etapy

planowanie i przygotowanie

wykonywanie

raportowanie

zamkni cie

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 10, Slajd 9

marzec, 2004; PB

Celem audytu projektu informatycznego jest

dostarczenie odbiorcy i dostawcy

obiektywnych, aktualnych i syntetycznych

informacji o stanie całego projektu

Jest to osi gane przez zbieranie dowodów, e

projekt:

posiada mo liwo ci (zasoby, kompetencje,

metody, standardy) by osi gn

sukces,

optymalnie wykorzystuje te mo liwo ci,
rzeczywi cie osi ga zało one cele

(cz stkowe).

Zebrane informacje słu

jako podstawa do

podejmowania strategicznych decyzji w

Audyt projektu informatycznego

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 10, Slajd 10

marzec, 2004; PB

ma to na celu sprawdzenie czy

wykonywane prace oraz sposób ich

wykonywania s prawidłowe

–

produkty (cz stkowe) projektu

informatycznego - ma to na celu

sprawdzenie czy rezultaty

poszczególnych prac odpowiadaj

zakładanym wymaganiom

Perspektywy

–

technologia - ma to na celu

sprawdzenie czy u yte techniki oraz

opracowane rozwi zania s

prawidłowe i prawidłowo stosowane

–

zarz dzanie - ma to na celu

Przedmioty i perspektywy audytu

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 10, Slajd 11

marzec, 2004; PB

Technika o najlepszej skuteczno ci (od 50% do

80%; rednia 60%; dla testowania rednia

30%, max 50%)

Stosowane dla „elitarnych” systemów
Dlaczego nie s powszechne?

–

trudne w sprzeda y: nie potrzeba

narz dzi, potrzeba planowania i

kompetentnych ludzi

–

analiza kosztów i zysków nie jest prosta

Inspekcja to formalna technika oceny, w której wymagania na oprogramowanie,

projekt lub kod s szczegółowo badane przez osob lub grup osób nie b d cych

autorami, w celu identyfikacji bł dów, naruszenia standardów i innych problemów

[IEEE Std. 729-1983]

Inspekcje

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 10, Slajd 12

marzec, 2004; PB

Sesje s zaplanowane i przygotowane
Bł dy i problemy s notowane
Wykonywana przez techników dla techników

(bez udziału kierownictwa)

Dane nie s wykorzystywane do oceny

pracowników

Zasoby na inspekcje s gwarantowane
Bł dy s wykorzystywane w poprawie

procesu programowego (prewencja)

Proces inspekcji jest mierzony
Proces inspekcji jest poprawiany

Cechy inspekcji

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 10, Slajd 13

marzec, 2004; PB

Wzrost produktywno ci od 30% do 100%
Skrócenie czasu projektu od 10% do 30%
Skrócenie kosztu i czasu wykonywania testów

od 5 do 10 razy (mniej bł dów, mniej testów

regresyjnych)

10 razy mniejsze koszty piel gnacji (naprawczej)
Poprawa procesu programowego
Dostarczanie na czas (bo wcze nie wiemy o

problemach)

Wi kszy komfort pracy (brak presji czasu i

nadgodzin)

Zwi kszenie motywacji

Korzy ci z inspekcji

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 10, Slajd 14

marzec, 2004; PB

Zagro enia inspekcji

Ocena osób na podstawie zebranych metryk
Złe prowadzenie inspekcji - mała

efektywno

i skuteczno

Słabi kontrolerzy
Kontrola indywidualna niewystarczaj ca

(jako

i ilo )

Skłonno

autora do lekcewa enia defektów

na etapie opracowywania dokumentów

(“inspekcja wska e bł dy...”)

Dyskusje o rozwi zaniach podczas spotkania

kontrolnego

Poczucie zagro enia u autora -

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 10, Slajd 15

marzec, 2004; PB

Przebieg inspekcji

Inicjowanie

Planowanie

Spotkanie inicjuj ce

Spotkanie kontrolne (burza mózgów)

Redakcja dokumentu inspekcji

Kontrola indywidualna

Kontrola indywidualna

Dystrybucja wniosków z inspekcji

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 10, Slajd 16

marzec, 2004; PB

Kroki inspekcji (1)

Inicjowanie

zgłoszenie potrzeby inspekcji; wyłonienie lidera inspekcji

Planowanie

lider ustala uczestników, listy kontrolne, zbiory reguł, tempo kontroli, daty

spotka kontrolnych

Spotkanie inicjuj ce

ustalenie ról, ustalenie celów i oczekiwa , dystrybucja dokumentu, szkolenie

w inspekcjach

Kontrola indywidualna

uczestnicy sprawdzaj dokument wzgl dem zadanych kryteriów, reguł i list

kontrolnych (znale jak najwi cej unikalnych bł dów)

Spotkanie kontrolne (burza mózgów)

Notowanie uwag z kontroli indywidualnej;

Ka da uwaga jest kwalifikowana jako „zagadnienie” (potencjalny bł d),

„pytanie o intencj ”, „propozycja poprawy procesu”; Szukanie nowych

zagadnie ; Poprawa procesu inspekcji.

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 10, Slajd 17

marzec, 2004; PB

Kroki inspekcji (2)

Poprawa produktu: edytor (najcz ciej autor)

rozwi zuje zagadnienia; prawdziwy problem

mo e by inny ni jest to zgłoszone;

zagadania s kwalifikowane jako bł dy lub

dokument jest redagowany by unikn

bł dnych interpretacji

Kontynuacja: lider sprawdza, e obsłu ono

wszystkie zagadnienia: s poprawione lub s

w systemie zarz dzania konfiguracj ;

sprawdza kompletno

a nie poprawno

Decyzja o gotowo ci: lider podejmuje decyzj

czy produkt jest gotowy do przekazania dalej

(np. liczba bł dów w okre lonym limicie)

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 10, Slajd 18

marzec, 2004; PB

Rodzaje testów

Testy mo na klasyfikowa z ró nych punktów widzenia:

Wykrywanie bł dów, czyli testy, których głównym celem jest wykrycie jak

najwi kszej liczby bł dów w programie

Testy statystyczne, których celem jest wykrycie przyczyn najcz stszych

bł dnych wykona oraz ocena niezawodno ci systemu.

Z punktu widzenia techniki wykonywania testów mo na je podzieli na:

Testy dynamiczne, które polegaj na wykonywaniu (fragmentów) programu

i porównywaniu uzyskanych wyników z wynikami poprawnymi.

Testy statyczne, oparte na analizie kodu

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 10, Slajd 19

marzec, 2004; PB

Bł d i bł dne wykonanie

Bł d (failure, error) - niepoprawna konstrukcja znajduj ca si w programie, która

mo e doprowadzi do niewła ciwego działania.

Bł dne wykonanie (failure) - niepoprawne działanie systemu w trakcie jego

pracy.

Bł d mo e prowadzi do ró nych bł dnych wykona .

To samo bł dne wykonanie mo e by spowodowane ró nymi bł dami.

Proces weryfikacji oprogramowania mo na okre li jako poszukiwanie i

usuwanie bł dów na podstawie obserwacji bł dnych wykona oraz innych

testów.

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 10, Slajd 20

marzec, 2004; PB

Typowe fazy testowania systemu

Testy modułów: S one wykonywane ju w fazie implementacji bezpo rednio

po zako czeniu realizacji poszczególnych modułów

Testy systemu: W tej fazie integrowane s poszczególne moduły i testowane s

poszczególne podsystemy oraz system jako cało

Testy akceptacji (acceptance testing): W przypadku oprogramowania

realizowanego na zamówienie system przekazywany jest do przetestowania

przyszłemu u ytkownikowi. Testy takie nazywa si wtedy testami

alfa. W

przypadku oprogramowania sprzedawanego rynkowo testy takie polegaj na

nieodpłatnym przekazaniu pewnej liczby kopii systemu grupie u ytkowników.

Testy takie nazywa si testami

beta.

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 10, Slajd 21

marzec, 2004; PB

Co podlega testowaniu (1)?

Wydajno systemu i poszczególnych jego funkcji (czy jest satysfakcjonuj ca).

Interfejsy systemu na zgodno z wymaganiami okre lonymi przez u ytkowników

Własno ci operacyjne systemu, np. wymagania logistyczne, organizacyjne,

u yteczno / stopie skomplikowania instrukcji kierowanych do systemu,

czytelno ekranów, operacje wymagaj ce zbyt wielu kroków, jako

komunikatów systemu, jako informacji o bł dach, jako pomocy.

Testy zu ycia zasobów: zu ycie czasu jednostki centralnej, zu ycie pami ci

operacyjnej, przestrzeni dyskowej, itd.

Zabezpieczenie systemu: odporno systemu na naruszenia prywatno ci, tajno ci,

integralno ci, spójno ci i dost pno ci. Testy powinny np. obejmowa :

- zabezpieczenie haseł u ytkowników

- testy zamykania zasobów przed niepowołanym dost pem

- testy dost pu do plików przez niepowołanych u ytkowników

- testy na mo liwo zablokowania systemu przez niepowołane osoby

- ....

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 10, Slajd 22

marzec, 2004; PB

Co podlega testowaniu (2)?

Przenaszalno oprogramowania: czy oprogramowanie b dzie działa w

zró nicowanym rodowisku (np. ró nych wersjach Windows 95, NT, Unix), przy

ró nych wersjach instalacyjnych, rozmiarach zasobów, kartach graficznych,

rozdzielczo ci ekranów, oprogramowaniu wspomagaj cym (bibliotekach), ...

Niezawodno oprogramowania, zwykle mierzon rednim czasem pomi dzy

bł dami.

Odtwarzalno oprogramowania (maintainability), mierzon zwykle rednim

czasem reperowania oprogramowania po jego awarii. Pomiar powinien

uwzgl dnia redni czas od zgłoszenia awarii do ponownego sprawnego działania.

Bezpiecze stwo oprogramowania: stopie minimalizacji katastrofalnych skutków

wynikaj cych z niesprawnego działania. (Przykładem jest wył czenie pr du

podczas działania w banku i obserwacja, co si w takim przypadku stanie.)

Kompletno i jako zało onych funkcji systemu.

Nie przekraczanie ogranicze , np. na zajmowan pami , obci enia procesora,...

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 10, Slajd 23

marzec, 2004; PB

Co podlega testowaniu (3)?

Modyfikowalno oprogramowania, czyli zdolno jego do zmiany przy

zmieniaj cych si zało eniach lub wymaganiach

Obci alno oprogramowania, tj. jego zdolno do poprawnej pracy przy

ekstremalnie du ych obci eniach. Np. maksymalnej liczbie u ytkowników, bardzo

du ych rozmiarach plików, du ej liczbie danych w bazie danych, ogromnych

(maksymalnych) zapisach, bardzo długich liniach danych ródłowych. W tych

testach czas nie odgrywa roli, chodzi wył cznie o to, czy system poradzi sobie z

ekstremalnymi rozmiarami danych lub ich komponentów oraz z maksymalnymi

obci eniami na jego wej ciu.

Skalowalno systemu, tj. spełnienie warunków (m.in. czasowych) przy znacznym

wzro cie obci enia.

Akceptowalno systemu, tj. stopie usatysfakcjonowania u ytkowników.

Jako dokumentacji, pomocy, materiałów szkoleniowych, zmniejszenia bariery

dla nowicjuszy.

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 10, Slajd 24

marzec, 2004; PB

Schemat testów statystycznych

Losowa konstrukcja danych wej ciowych zgodnie z rozkładem

prawdopodobie stwa tych danych

Okre lenie wyników poprawnego działania systemu na tych danych

Uruchomienie systemu oraz porównanie wyników jego działania z

poprawnymi wynikami.

Powy sze czynno ci powtarzane s cyklicznie.

Stosowanie testów statystycznych wymaga okre lenia rozkładu prawdopodobie stwa danych

wej ciowych mo liwie bliskiemu rozkładowi, który pojawi si w rzeczywisto ci. Dokładne

przewidzenie takiego rozkładu jest trudne, w zwi zku z czym wnioski wyci gni te na

podstawie takich testów mog by nietrafne.

Zało eniem jest przetestowanie systemu w typowych sytuacjach. Istotne jest tak e

przetestowanie systemu w sytuacjach skrajnych, nietypowych, ale dostatecznie wa nych.

Istotn zalet testów statystycznych jest mo liwo ich automatyzacji, a co za tym idzie,
mo liwo ci wykonania du ej ich liczby. Technika ta jest jednak mało efektywna.

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 10, Slajd 25

marzec, 2004; PB

Testowanie na zasadzie białej skrzynki

white-box testing

Tak okre la si sprawdzanie wewn trznej logiki oprogramowania.

(Lepszym

terminem byłoby „testowanie n/z szklanej skrzynki”.)

Testowanie n/z białej skrzynki pozwala sprawdzi wewn trzn logik programów

poprzez odpowiedni dobór danych wej ciowych, dzi ki czemu mo na prze ledzi

wszystkie cie ki przebiegu sterowania programu.
Tradycyjnie programi ci wstawiaj kod diagnostyczny do programu aby ledzi

wewn trzne przetwarzanie. Debuggery pozwalaj programistom obserwowa

wykonanie programu krok po kroku.
Cz sto niezb dne staje si wcze niejsze przygotowanie danych testowych lub

specjalnych programów usprawniaj cych testowanie (np. programu wywołuj cego

testowan procedur z ró nymi parametrami).
Dane testowe powinny by dobrane w taki sposób, aby ka da cie ka w programie

była co najmniej raz przetestowana.
Ograniczeniem testowania na zasadzie białej skrzynki jest niemo liwo pokazania

brakuj cych funkcji w programie. Wad t usuwa testowanie n/z czarnej skrzynki.

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 10, Slajd 26

marzec, 2004; PB

Testowanie na zasadzie czarnej skrzynki

black-box testing

Tak okre la si sprawdzanie funkcji oprogramowania bez zagl dania do rodka

programu. Testuj cy traktuje sprawdzany moduł jak „czarn skrzynk ”, której

wn trze jest niewidoczne.
Testowanie n/z czarnej skrzynki powinno obejmowa cały zakres danych

wej ciowych.
Testuj cy powinni podzieli dane wej ciowe w „klasy równowa no ci”, co do

których istnieje du e przypuszczenie, e b d produkowa te same bł dy.

Np.

je eli testujemy warto „Malinowski”, to prawdopodobnie w tej samej klasie
równowa no ci jest warto „Kowalski”. Celem jest unikni cie efektu „eksplozji danych

testowych”.

„Klasy równowa no ci” mog by równie zale ne od wyników zwracanych

przez testowane funkcje.

Np. je eli wej ciem jest wiek pracownika i istnieje funkcja

zwracaj ca warto ci „młodociany”, „normalny” „wiek emerytalny”, wówczas implikuje to

odpowiednie klasy równowa no ci dla danych wej ciowych.

Wiele wej dla danych (wiele parametrów funkcji) mo e wymaga zastosowania

pewnych systematycznych metod okre lania ich kombinacji, np. tablic

decyzyjnych lub grafów przyczyna-skutek.