Inżynieria oprogramowania, wykład 6, slajd 1

Testowanie oprogramowania

dr inż. Grzegorz
Bliźniuk

Inżynieria oprogramowania

wykład 6

Inżynieria oprogramowania, wykład 6, slajd 2

Plan wykładu

1. Pojęcia podstawowe

2. Przeglądy, audyty, inspekcje oprogramowania

3. Wymiary testów, strategie testów

4. Przykłady narzędzi wspomagających testowanie

5. Podsumowanie

Przygotowane głównie na podstawie wykładu BYT K.Subiety,
materiałów D.Pierzchały,dokumentów legislacyjnych i
materiałów własnych prowadzącego

Inżynieria oprogramowania, wykład 6, slajd 3

Testowanie w procesie zapewnienia

jakości

Norma [PKN ISO 8492] określa jakość jako ogół cech
i właściwości wyrobu lub usługi decydujących o zdolności
tego wyrobu lub usługi do zaspokojenia stwierdzonych lub
przewidywanych potrzeb użytkownika produktu.

Oprogramowanie jest jednym z rodzajów wyrobu, a zatem
powyższa definicja ma również tutaj zastosowanie.

Testowanie (weryfikacja i walidacja) oprogramowania jest
jednym z kluczowych etapów procesu zapewnienia jego
jakości.

Jakość oprogramowania jest jednym decydujących
czynników branych pod uwagę w czasie akceptacji
oprogramowania przez jego użytkownika.

Inżynieria oprogramowania, wykład 6, slajd 4

Składowe jakości oprogramowania

* - dotyczy programów współbieżnych

POPRAWNOŚĆ
Bezpieczeństwo (statyczne)*
Żywotność
Reaktywność
Brak zakleszczeń*
Brak zagłodzeń*
Brak blokad*
Czytelność
Zwięzłość
Jednoznaczność
Dostępność
ADEKWATNOŚĆ
Kompletność
Racjonalność funkcjonalna
Racjonalność komunikacyjna
Zwartość funkcjonalna
Zwartość komunikacyjna
NIEZAWODNOŚĆ
Nieuszkadzalność
Obsługiwalność
Odporność
Odnawialność
Niezmienność zachowań
Utrzymywalność

Testowalność

Przechowywalność

ZŁOŻONOŚĆ OPROGRAMOWANIA
Funkcjonalna
Komunikacyjna
W strukturze procesów
współbieżnych*
W strukturze zadań*
W strukturze modułów programowych
W strukturze aktywnych komponentów
Struktury modułowej
Struktury zadaniowej*
Struktury wewnętrznej tekstu
źródłowego
ZŁOŻONOŚĆ OBLICZENIOWA
ALGORYTMÓW
Złożoność pamięciowa (zasobowa)
Złożoność czasowa
PIELĘGNACYJNOŚĆ
Wdrażalność
Progresywność
Modyfikowalność
Przenośność
Naprawialność

Żródło: Grzegorz Bliźniuk, Badanie jakości programów współbieżnych,
wydanie II, poprawione, Warszawa, 2004, ISBN 83-88442-73-2

Inżynieria oprogramowania, wykład 6, slajd 5

Istota procesu testowania



Testowanie - cele:

–sprawdzanie jak dobry jest (lub wkrótce będzie)

docelowy produkt i/lub jego składowe;

–sprawdzenie czy oprogramowanie spełni swoje

zadanie;



Nie oznacza to, że kod wynikowy będzie

bezbłędny!



Testowaniem nie można wykazać braku

błędów, można w ten sposób jedynie

wykazać ich obecność

[E.W. Dijkstra]



Testuje się zatem tylko wybrane

fragmenty, bo w myśl zasady Pareto:

„20% kodu generuje 80% błędów”;

©2002 Hamilton Richards

Inżynieria oprogramowania, wykład 6, slajd 6

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

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.

Inżynieria oprogramowania, wykład 6, slajd 7

Modele niezwodności oprogramowania



Cel:

–Modelują awarie oprogramowania (nie wykryte w

czasie testowania) jako funkcję czasu pracy systemu;

–Wybrane modele:

»Jelinski-Moranda (1972)
»Logarytmiczny model Poisson’a
»Shooman
»Littlewood-Verrall
»Goel-Okumoto
»Musa-Okumoto
»Littlewood-Verrall Bayesian Model (LV)

Inżynieria oprogramowania, wykład 6, slajd 8

Proces testowania



Modele niezawodności oprogramowania:

–Jelinski-Moranda (1972):

»Wykrywanie błędów jest niezależne;
»Usuwanie wykrytych błędów nie generuje nowych;
»Intensywność wykrywania błędów - proporcjonalna do liczby błędów

pozostających w oprogramowaniu:

gdzie:
»K – stała



r

– wspł. pozostających błędów

»E

T

– stała - początkowa liczba błędów w programie

»I

T

– stała - liczba instrukcji w programie



c

– łączna unormowana liczba błędów usuniętych w przedziale [0,]

z() =

K



r

(



)



r

() = E

T

/ I

T

-



c

()

 

 

























C

T

T

I

E

K

z

1920-2006

Inżynieria oprogramowania, wykład 6, slajd 9

Proces testowania



Modele niezawodności oprogramowania:

–Jelinski-Moranda (1972):

»Funkcja niezawodności:

»MTTF:

 

 

e

C

T

T

I

E

K

R



























 





















C

T

T

I

E

K

1

z(

)

K(E

T

/I

T

)



C

()

E

T

/I

T

Przy , 

c

()  E

T

/I

T

zatem

r

()  0

Inżynieria oprogramowania, wykład 6, slajd 10

Proces testowania



Modele niezawodności oprogramowania:

–Logarytmiczny model Poisson’a:

gdzie:
–f(t) - skumulowana liczba awarii, które wystąpią w

czasie wykonywania oprogramowania do chwili t;

–l

0

- początkowa intensywność awarii (liczba awarii na

jednostkę czasu) - w chwili rozpoczęcia testowania;

–r - współczynnik proporcjonalności zależny od stopnia

redukcji intensywności awarii;

–l(t) - chwilowa intensywność awarii - pochodna

skumulowanej liczby awarii;

( ) (

) (

)

0

1/

ln

1

f t

r

l rt

=

+

( )

(

)

0

0

/

1

l t

l

l pt

=

+

Inżynieria oprogramowania, wykład 6, slajd 11

Piramida propagacji błędów – ujęcie

poglądowe

Pielęgnacja

Implementacja

Projekt

Analiza

Wymag

ania

Rozmiar kosztu usunięcia błędów

E

ta

p

c

yk

lu

ż

yc

ia

op

ro

g

ra

m

ow

an

ia

Inżynieria oprogramowania, wykład 6, slajd 12

Piramida propagacji błędów – ujęcie

szacunkowe

20

200

Czas (Etap realizacji

systemu)

K

o

s

zt

n

a

p

ra

w

y

w

y

k

ry

ty

c

h

b

łę

d

ó

w

Testy

akceptacyjne

Testowanie

jednostkow

e

Implementac

ja

Analiza -

projekt

Wymagan

ia -

analiza

0

Pielęgnacja

po

wdrożeniu

1-2

10

5

50

Koszty wykrycia błędów

Inżynieria oprogramowania, wykład 6, slajd 13

Źródła kosztów nieprawidłowości

oprogramowania



Koszty oprogramowania złej jakości (model ISO 9004-
1:1994):

–1. Koszty jakości:

»koszty błędów (traktowane jako straty),
»koszty oceny (traktowane jako nakłady),
»koszty zapobiegania (traktowane jako nakłady).

–2. Koszty procesu:

»koszty niezgodności (traktowane jako straty),
»koszty zgodności (traktowane jako nakłady).

–3. Straty jakości (skutki odchyleń od wymagań jakościowych)



Wg Roger’a Pressman’a (1997):

–Testowanie: ~ 30 % - 40 % całkowitej pracochłonności;
–Testowanie systemów krytycznych: 70% - 80% całkowitej

pracochłonności (!);

Dodatkowo należy brać pod uwagę tzw. koszty utraconych korzyści

Inżynieria oprogramowania, wykład 6, slajd 14

Testowanie w cyklu życia

oprogramowania

Określenie wymagań Projektowanie Implementacja

Testowanie

Konserwacja

Faza strategiczna

Analiza

Instalacja

Dokumentacja

Pojęcia podstawowe:

Weryfikacja (verification) - testowanie zgodności systemu z
wymaganiami zdefiniowanymi w fazie określenia wymagań.

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

Inżynieria oprogramowania, wykład 6, slajd 15

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 uwzględnia 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.

Inżynieria oprogramowania, wykład 6, slajd 16

Badanie prognostyczne – nie ma kodu

źródłowego

Zanim powstanie implementacja oprogramowania,

jego przyszłe działanie jest badane na podstawie

założeń analitycznych/ projektowych [Bliźniuk, 2000]

Główne zalety podejścia prognostycznego:

• Zwiększenie prawdopodobieństwa uniknięcia lub

zmniejszenia oddziaływania zjawiska propagacji błędów,

• Stosunkowo niskie koszty testowania,
• Możliwość przebadania wielu różnych projektów

oprogramowania w celu wyboru najlepszego do
implementacji.

Wady podejścia prognostycznego:

• Bazowanie na modelu oprogramowania, co może

zmniejszyc dokładność badania (potencjalna rozbieżność z
właściwościami implemetacyjnymi).

Żródło: Grzegorz Bliźniuk, Badanie jakości programów współbieżnych, wydanie II, poprawione, Warszawa,
2004, ISBN 83-88442-73-2

Inżynieria oprogramowania, wykład 6, slajd 17

Metody badania prognostycznego

Bazują na:



Metodach specyfikacji formalnej programów (VDM, VDM+,

Z, CSP) [Jones 1983, 1986, Hoare 1978]



Badaniu

logiki

sterowania

programów

(logika

algorytmiczna) [Pnueli 1991]



Metrykach projektu oprogramowania [Bliźniuk 2000]



Probabilistycznych

metrykach

dynamiki

programów

[Bliźniuk, 2000]



Modelach

grafowych,

sieciowych

i

symulacyjnych

oprogramowania [Bliźniuk, 2000],



Sieciach Petriego [Petri – lata 60-te]



Metodach

symulacji

komputerowej

[Nowicki

1994,

Bliźniuk, 2000]

Dwa komplementarne podejścia:

1. badanie właściwości statycznych

2. badanie właściwości dynamicznych

Żródło: Grzegorz Bliźniuk, Badanie jakości programów współbieżnych, wydanie II, poprawione, Warszawa,
2004, ISBN 83-88442-73-2

Inżynieria oprogramowania, wykład 6, slajd 18

Badanie diagnostyczne – istnieje kod

źródłowy



Analiza dynamiczna:

–eksperymentowanie z działającym kodem programu;



Analiza statyczna:

–praca z kodem źródłowym w celu:

»rozpoznania funkcjonalności testowanego kodu;

»zaprojektowania odpowiednich testów;



Testowanie wykrywa anomalie [J. Górski]:

–Defekt

»nieprawidłowe działanie człowieka w procesie wytwarzania,

np. złe sformułowanie wymagań, zła decyzja projektowa,

pomyłka w implementacji, …;

–Błąd

»każde zdarzenie, w wyniku którego kod produkuje

nieoczekiwany rezultat;

–Awaria

»stan, w którym program nie jest zdolny wykonać prawidłowo

co najmniej jednej ze swoich funkcji;

Inżynieria oprogramowania, wykład 6, slajd 19

Klasyfikacja błędów oprogramowania

Klasa błędu

Typowy, możliwy błąd

Funkcjonalny

Zła lub brakująca funkcja

Systemowy

Błędnie użyte interfejsy, złe

zarządzanie zasobami, zły przepływ

sterowania

Przetwarzania

Niewłaściwe przetwarzanie danych w

module

Danych

Błędna specyfikacja, projekt,

rozmieszczenie lub inicjacja danych

Kodowania

Niewłaściwe użycie instrukcji języka

programowania

Dokumentacyjny

Niepełna lub błędna treść

dokumentacji

Inny

Przyczyny nieznane

Inżynieria oprogramowania, wykład 6, slajd 20

Zjawisko eksplozji kombinacji danych

testowych

W praktyce przetestowanie wszystkich kombinacji danych
wejściowych

(nawet

zredukowanych

do

“typowych”

i

“granicznych”) jest najczęściej niemożliwe. Konieczny jest wybór
tych kombinacji.
Ogólne zalecenia takiego wyboru są następujące:

Możliwość wykonania funkcji jest ważniejsza niż jakość
jej wykonania. Brak możliwości wykonania funkcji jest
poważniejszym błędem niż np. niezbyt poprawne
wyświetlenie jej rezultatów na ekranie.

Funkcje systemu znajdujące się w poprzedniej wersji są
istotniejsze niż nowo wprowadzone. Użytkownicy, którzy
posługiwali się dana funkcją w poprzedniej wersji systemu
będą bardzo niezadowoleni jeżeli w nowej wersji ta funkcja
przestanie działać.

Typowe sytuacje są ważniejsze niż wyjątki lub sytuacje
skrajne. Błąd w funkcji wykonywanej często lub dla danych
typowych jest znacznie bardziej istotny niż błąd w funkcji
wykonywanej rzadko dla dla nietypowych danych.

Inżynieria oprogramowania, wykład 6, slajd 21

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

Inżynieria oprogramowania, wykład 6, slajd 22

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.

Inżynieria oprogramowania, wykład 6, slajd 23

Co to jest audyt?

audit

Audytem nazywany jest niezależny przegląd i ocenę 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”.

Inżynieria oprogramowania, wykład 6, slajd 24

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

Inżynieria oprogramowania, wykład 6, slajd 25

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 projekcie

Audyt projektu informatycznego

Inżynieria oprogramowania, wykład 6, slajd 26

Przedmioty

– procesy projektu informatycznego - 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 sprawdzenie czy sposób

zarządzania projektem umożliwia jego sukces

Przedmioty i perspektywy audytu

Inżynieria oprogramowania, wykład 6, slajd 27

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

Inżynieria oprogramowania, wykład 6, slajd 28

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

Inżynieria oprogramowania, wykład 6, slajd 29

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

– świadomość, że produkt będzie oceniany (wybór

pomiędzy byciem zażenowanym a dumnym)

– nauka przez znajdowanie błędów

Mniejsze koszty marketingu („przykrywanie” braku jakości)

Korzyści z inspekcji

Inżynieria oprogramowania, wykład 6, slajd 30

Zagrożenia inspekcji

1.

Ocena osób na podstawie zebranych metryk

2.

Złe prowadzenie inspekcji - mała efektywność i
skuteczność

3.

Słabi kontrolerzy

4.

Kontrola indywidualna niewystarczająca (jakość i ilość)

5.

Skłonność autora do lekceważenia defektów na etapie
opracowywania dokumentów (“inspekcja wskaże
błędy...”)

6.

Dyskusje o rozwiązaniach podczas spotkania kontrolnego

7.

Poczucie zagrożenia u autora - nieuzasadniona obrona
własnych rozwiązań

8.

Krytyczne nastawienie do autora raportu z inspekcji

Inżynieria oprogramowania, wykład 6, slajd 31

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

Inżynieria oprogramowania, wykład 6, slajd 32

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.

Inżynieria oprogramowania, wykład 6, slajd 33

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)

Rozpowszechnienie dokumentu
Burza mózgów ma na celu identyfikację przyczyn błędów (max

10 najpoważniejszych) i propozycji poprawy procesu
programowego, by błędy te nie powtórzyły się w
przyszłości; idee są notowane bez ich głębokiej oceny

Inżynieria oprogramowania, wykład 6, slajd 34

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 albo modeli symulacyjnych i
porównywaniu uzyskanych wyników z wynikami
poprawnymi.

Testy statyczne, oparte na analizie kodu albo modeli
analitycznych/projektowych

Inżynieria oprogramowania, wykład 6, slajd 35

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

- ....

Inżynieria oprogramowania, wykład 6, slajd 36

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

Inżynieria oprogramowania, wykład 6, slajd 37

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.

Inżynieria oprogramowania, wykład 6, slajd 38

Czynności procesu testowania



Według Sommerville:

Raport

z testowania

Raport

z testowania

Wyniki

testów

Wyniki

testów

Dane

testowe

Dane

testowe

Przypadki

testowe

Przypadki

testowe

Opracuj przypadki

testowe

Opracuj przypadki

testowe

Przygotuj dane

testowe

Przygotuj dane

testowe

Uruchom program

na danych testowych

Uruchom program

na danych testowych

Porównaj wyniki

z przypadkami

testowymi

Porównaj wyniki

z przypadkami

testowymi

WEJŚCIE

WYJŚCIE

Inżynieria oprogramowania, wykład 6, slajd 39

Przypadek testowy – test case



Przypadek testowy (ang. test case) - specyfikacja:

–stan początkowy, czyli stan testowanego systemu (lub

jego fragmentu) przed testem,

–dane wejściowe,
–warunki testu,
–dane wyjściowe (oczekiwane wyniki);



Jakość przypadku testowego :

–prawdopodobieństwo znalezienia jeszcze nie

wykrytego błędu;



Test zakończony powodzeniem:

–

WYKRYWA

dotychczas nie wykryty błąd;

[G. Myers, The Art. Of Software Testing, 1979]

Inżynieria oprogramowania, wykład 6, slajd 40

Kiedy przestać ? …….



Kryterium zakończenia testowania:

–Nie istnieje definitywne kryterium zakończenia testowania;



Podejście pragmatyczne:

»Testowanie nigdy nie jest zakończone - od pierwszej instalacji

prototypu oprogramowanie testowane jest przez Użytkownika;

»Testowanie jest zakończone, gdy skończył się czas lub budżet;



Kryterium statystyczne:

–Stawiana jest teza, iż liczba wykonanych testów zapewnia

prawdopodobieństwo bezawaryjnej pracy oprogramowania
przez określony czas nie mniejsze niż p;

–Tym samym dopuszczamy wystąpienie błędu z

prawdopodobieństwem „1-p”;

Inżynieria oprogramowania, wykład 6, slajd 41

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

Inżynieria oprogramowania, wykład 6, slajd 42

wymagan

ia

użytkowe

specyfikac

ja

systemu

projekt

architektu

ry

projekt

szczegółow

y

testowanie

jednostkowe

(komponentów)

testowanie

integracyjn

e

kodowanie

testowanie

systemowe

testowanie

akceptacyjn

e

wytwarzanie
lokalizacja
błędu
weryfikacja

Proces testowania w modelu V – cd.

Model "V"

P

o

zi

o

m

y

te

st

o

w

a

n

ia

Inżynieria oprogramowania, wykład 6, slajd 43

Poziomy testowania



Testy jednostkowe (komponentów):

–Testują oprogramowanie na najniższym poziomie, czyli na

poziomie małych modułów, klas, metod;

–Mogą być zrobione w oddzieleniu od reszty systemu;
–Wymagają dostępu do kodu źródłowego i wsparcia

narzędziowego (np. debugger’ów);

–Wykorzystują zaślepki (ang. „stub”), symulatory,…;
–Mogą obejmować testowanie:

»funkcjonalności,
»niefunkcjonalnych charakterystyk, takich jak zasoby (np.

wycieki pamięci),

»odporności na atak,
»testowanie strukturalne (np. pokrycie gałęzi);

Inżynieria oprogramowania, wykład 6, slajd 44

Poziomy testowania



Testy integracyjne:

–Sprawdzają interfejsy pomiędzy komponentami i

współpracę różnych części systemu, np. systemu
operacyjnego, systemu plików, oprzyrządowania;

–Strategie integracji bazują na:

»architekturze systemu (np. z góry na dół, z dołu do góry),
»funkcjonalności,
»sekwencjach wymiany danych;

–Integracja powinna raczej być wykonywana

stopniowo, a nie metodą wszystko na raz (tzw.
„big bang”);

Inżynieria oprogramowania, wykład 6, slajd 45

Poziomy testowania



Testy systemowe:

–Dotyczą sprawdzenie zachowania całości

systemu w porównaniu z założeniami wstępnymi
projektu;

–Środowisko testowe powinno być zbliżone do

docelowego, w jakim system będzie pracował;

–Wykonywane są zazwyczaj przez niezależny

zespół testowy;

–Testy obejmują wymagania funkcjonalne i

różnego rodzaju wymagania niefunkcjonalne
(szybkość, bezpieczeństwo, niezawodność, …);

Inżynieria oprogramowania, wykład 6, slajd 46

Wymiary testowania



Testy akceptacyjne:

–Pozwalają sprawdzić, na ile oprogramowanie działa zgodnie z

wymaganiami klienta;

–Leżą w gestii klienta lub użytkownika systemu oraz również

współudziałowcy;

–Szukanie defektów nie jest głównym celem tego testowania;
–Dzielą się na testy:

»użytkownika - weryfikuje dopasowanie systemu do potrzeb użytkowników;
»operacyjne - akceptacja systemu przez administratorów systemu

zawierające: sprawdzenie kopii zapasowej i zdolności do przywrócenia
funkcjonalności po wystąpieniu problemów, zarządzanie użytkownikami,
zadania serwisowe, cykliczne sprawdzenie bezpieczeństwa;

»kontraktowe i regulacyjne - testowanie kryteriów wytworzenia

oprogramowania specyfikowanego dla klienta (np. są wykonywane w
zgodzie z rządowymi lub legislacyjnymi uregulowaniami);

»alfa / beta – dla systemów: na zamówienie / „z półki”;

Inżynieria oprogramowania, wykład 6, slajd 47

Kompletność testów akceptacyjnych

(1)

Macierz przykrycia testów akceptacyjnych:

Funkcjonaln

ość

oprogramow

ania

Funkcjonaln

ość 1

TC 1

TC 3

TC m

Funkcjonaln

ość 2

TC 2

Funkcjonaln

ość 3

TC 1

TC 4

Funkcjonaln

ość 4

……

TC 2

Funkcjonaln

ość n

TC 1

TC m

Numery przypadków testowych

BŁĄD: funkcjonalność nie jest testowana !!!!!

Inżynieria oprogramowania, wykład 6, slajd 48

Kompletność testów akceptacyjnych

(2)

Macierz przykrycia testów akceptacyjnych:

Funkcjonaln

ość

oprogramow

ania

Funkcjonaln

ość 1

TC 1

Funkcjonaln

ość 2

TC 2

Funkcjonaln

ość 3

TC 1

TC 5

Funkcjonaln

ość 4

TC 4

……

TC 2

Funkcjonaln

ość n

TC 1

Numery przypadków testowych

BŁĄD: nadmiarowy przypadek testowy !!!!!

TC m

Inżynieria oprogramowania, wykład 6, slajd 49

Wymogi polskiego prawa – testy

akceptacyjne

W rozporządzeniu zdefiniowano podstawowe definicje pojęć i sposób

przeprowadzania testów oprogramowania interfejsowego

umożliwiającego kontakt z instytucjami publicznymi w Polsce. Zostały

zdefiniowane również formularze wykorzystywane do opisu

poszczególnych przypadków testowych i scenariuszy testowych.

!!! Znajomość tego rozporządzenia będzie wymagana na zaliczeniu
przedmiotu !!!

Inżynieria oprogramowania, wykład 6, slajd 50

Metody regresyjne



Testy regresyjne:

–Celem tej kategorii testów jest sprawdzenie, czy

dodając nową funkcjonalność i/lub poprawiając
wykryte błędy nie naruszamy poprawności
oprogramowania;

–Wykorzystują ponownie opracowane wcześniej

testy wszystkich 4-ech poziomów;



Testy „smoke test”:

–Uproszczona forma testowania regresyjnego;
–Sprawdza, czy w wyniku modyfikacji program

nadal się uruchamia;

Inżynieria oprogramowania, wykład 6, slajd 51

Wymiary testowania



Testy instalacyjne (konfiguracji):

–Służą do sprawdzenia, jak oprogramowanie zachowuje się na

różnych:

»platformach sprzętowo-programowych,
»wersjach systemów,
»przy różnym zestawie oprogramowania dodatkowego, które może mieć

odbiorca;



Testy używalności:

–Sprawdzają, jak szybko potencjalni użytkownicy mogą nauczyć się

systemu oraz na ile użyteczna i jasna jest dokumentacja (itp.);



Testy post-awaryjne:

–Sprawdzają, czy aplikacja zachowuje się poprawnie po wystąpieniu

sytuacji awaryjnej;

–Np. producent bazy danych powinien sprawdzić, jak awaria wpłynie

na integralność przechowywanych danych;

Inżynieria oprogramowania, wykład 6, slajd 52

Testowanie integracyjne



Skokowe - grupują wybrane (lub wszystkie)
jednostki w celu ich równoczesnego
przetestowania



Przyrostowe - zakładają dołączenie do
tworzonej całości za każdym razem tylko
jednej uprzednio przetestowanej jednostki:

–zstępujące (odgórne) - integruje się i testuje się

komponenty wysokiego poziomu przed ukończeniem
ich projektu i implementacji;

–wstępujące (oddolne) - testuje się i integruje

komponenty niskiego poziomu przed ukończeniem
budowy komponentów wyższego poziomu;

Inżynieria oprogramowania, wykład 6, slajd 53

Testowanie integracyjne



Testowanie zstępujące (odgórne):

A

B

C

D

E

F

Krok

Obiekt testu

Środowisko testu

1

A

namiastki B i C

2

A+B

namiastki C,D i E

3

A+B+C

namiastki D i E

4

A+B+C+D

namiastka E

5

A+B+C+D+E

namiastka F

6

A+B+C+D+E+

F

--

Namiastka (stub):

•imituje jednostki niższego poziomu

•zastępuje moduły wywoływane przez
testowany moduł

Inżynieria oprogramowania, wykład 6, slajd 54

Testowanie integracyjne



Testowanie wstępujące (oddolne):

A

B

C

D

E

F

Kro

k

Obiekt testu

Środowisko

testu

1

D

sterownik dla D

2

F

sterownik dla F

3

E+F

sterownik dla E

4

D+E+F+B

sterownik dla B i

E

5

C+E+F

sterownik dla C i

E

6

A+B+C+D+E+

F

--

Sterownik (driver):

•dostarcza jednostkom niższego poziomu dane

•zastępuje moduł wywołujący testowane moduły

Inżynieria oprogramowania, wykład 6, slajd 55

Testowanie integracyjne



Testowanie interfejsu jest wykonywane po zintegrowaniu
modułów lub podsystemów w większe systemy.



Każdy moduł i podsystem ma zdefiniowany interfejs,
który jest wywoływany przez inne komponenty
programu, np.:

–Interfejsy parametryczne,
–Interfejs w pamięci dzielonej,
–Interfejsy proceduralne,
–Interfejsy z przekazywaniem komunikatów;



Celem testowania interfejsu jest wykrycie usterek, które
pojawiły się w systemie z powodu błędów w interfejsach
lub nieprawdziwych założeniach o interfejsach.

Inżynieria oprogramowania, wykład 6, slajd 56

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.

Inżynieria oprogramowania, wykład 6, slajd 57

Testy pod obciążeniem, testy

odporności

Testy obciążeniowe (stress testing). Celem tych testów jest
zbadanie wydajności i niezawodności systemu podczas pracy pod
pełnym lub nawet nadmiernym obciążeniem. Dotyczy to
szczególnie systemów wielodostępnych i sieciowych. Systemy
takie muszą spełniać wymagania dotyczące wydajności, liczby
użytkowników, liczby transakcji na godzinę. Testy polegają na
wymuszeniu obciążenia równego lub większego od
maksymalnego.

Testy odporności (robustness testing). Celem tych testów jest
sprawdzenie działania w przypadku zajścia niepożądanych
zdarzeń, np.

• zaniku zasilania

• awarii sprzętowej

• wprowadzenia niepoprawnych danych

• wydania sekwencji niepoprawnych poleceń

Inżynieria oprogramowania, wykład 6, slajd 58

Technika “zasiewania błędów”.

Polega na tym, że do programu celowo wprowadza się pewną
liczbę błędów podobnych do tych, które występują w programie.
Wykryciem tych błędów zajmuje się inna grupa programistów niż
ta, która dokonała “zasiania” błędów.

Załóżmy, że:

N oznacza liczbę zasianych błędów
M oznacza liczbę wszystkich wykrytych błędów
X oznacza liczbę zasianych błędów, które zostały wykryte

Szacunkowa liczba błędów przed wykonaniem testów:

(M - X) * N/X

Szacunkowa liczba błędów po usunięciu wykrytych
(“zasiane” błędy zostały też usunięte):

(M - X) * (N/X - 1)

Szacunki te mogą być mocno chybione, jeżeli “zasiane” błędy nie będą
podobne do rzeczywistych błędów występujących w programie.
Technika ta pozwala również na przetestowanie skuteczności metod
testowania.
Zbyt mała wartość X/N oznacza konieczność poprawy tych metod.

Inżynieria oprogramowania, wykład 6, slajd 59

Drzewo błędów

fault tree

Korzeniem drzewa są jest jedna z rozważanych niebezpiecznych
sytuacji.
Wierzchołkami są sytuacje pośrednie, które mogą prowadzić do
sytuacji odpowiadającej wierzchołkowi wyższego poziomu.

Błędne
rozliczenie
podatnika

Błędne
rozliczenie
podatnika

Wprowadzenie
błędnych danych

Wprowadzenie
błędnych danych

Błąd
obliczenio
wy

Błąd
obliczenio
wy

Błędny
wydruk
rozliczenia

Błędny
wydruk
rozliczenia

Błędnie obliczona
podstawa
opodatkowania

Błędnie obliczona
podstawa
opodatkowania

Błędnie
obliczony
podatek

Błędnie
obliczony
podatek

Błędnie
obliczona
nadpłata/dopł
ata

Błędnie
obliczona
nadpłata/dopł
ata

Błędnie
zsumowane
dochody

Błędnie
zsumowane
dochody

Błędnie
zsumowane ulgi

Błędnie
zsumowane ulgi

lub

lub

lub

Inżynieria oprogramowania, wykład 6, slajd 60

Testowanie strategią białej skrzynki

(struktura)

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.

Inżynieria oprogramowania, wykład 6, slajd 61

Testy białej skrzynki



Testy strukturalne - testy białej
skrzynki:

–Testy opracowuje się na podstawie wiedzy i

implementacji oprogramowania;

–Stosuje się do stosunkowo niewielkich

jednostek programów, takich jak
podprogramy i operacje związane z obiektem;

–Tester może analizować kod i korzystać z

wiedzy o strukturze komponentu przy
opracowywaniu danych testowych;

Inżynieria oprogramowania, wykład 6, slajd 62

Testy białej skrzynki



Testy strukturalne – strategia „Testowanie
ścieżek”:

–

Celem jest zbadanie każdej niezależnej ścieżki
wykonania komponentu lub programu;

»Jeśli wykonano każdą niezależną ścieżkę, to wszystkie instrukcje

komponentu musiały być wykonane co najmniej raz;

–

Liczba ścieżek w programie jest zwykle proporcjonalna
do jego rozmiaru;

–

Testowanie ścieżek jest więc najczęściej stosowane w
fazach testowania jednostkowego i testowania modułów;

–

W programie z pętlami jest nieskończenie wiele
możliwych kombinacji ścieżek;

Inżynieria oprogramowania, wykład 6, slajd 63

Testy białej skrzynki



Testy strukturalne – strategia „Testowanie ścieżek”:
„graf strumieni programu”:

–Na wstępie należy wykonać „graf strumieni programu”, będący

szkieletowym modelem wszystkich ścieżek;

–Składa się z węzłów reprezentujących decyzje i krawędzi

odpowiadających przepływom sterowania;

–Powstaje przez zastąpienie instrukcji sterujących programu

równoważnymi diagramami;

–Utworzenie grafu jest łatwe, jeżeli w programie nie ma

instrukcji skoku;

–Budując graf strumieni można pominąć instrukcje sekwencyjne

(przypisania, wywołania procedur i instrukcje we/wy).;

–Każda gałąź instrukcji warunkowej if-then-else lub case jest

przedstawiona w postaci odrębnej ścieżki;

–Pętle obrazuje się za pomocą strzałki wstecznie wskazującej

węzeł warunku pętli;

Inżynieria oprogramowania, wykład 6, slajd 64

Testy białej skrzynki



Testy strukturalne – strategia „Testowanie
ścieżek”:

–Przykład: podprogram wyszukiwania

binarnego:

»Pobiera uporządkowaną tablicę obiektów oraz

klucz i przekazuje obiekt z dwoma atrybutami:



pozycja - numer pozycji w tablicy,



znaleziono - wartość logiczna wskazująca, czy klucz znajduje się
w tablicy, czy nie;

»Jeśli elementu nie znaleziono:



pozycja ma wartość „-1”;



znaleziono ma wartość „false”;

Inżynieria oprogramowania, wykład 6, slajd 65

Testy białej skrzynki –

badanie grafu sterowania programu



Testy strukturalne – strategia „Testowanie
ścieżek”:

–Przykładowy graf strumieni podprogramu wyszukującego

binarnie:

1

8

5

6

2

9

7

4

3

początek > koniec

while początek <= koniec

if ( tablica[środek] == klucz)

if ( tablica[środek] < klucz)

Inżynieria oprogramowania, wykład 6, slajd 66

Testy białej skrzynki –

metryki złożoności struktury wewnętrznej

programów

Metryki programów nieobiektowych:

1. Halstesad’a (operatory, argumenty)

2. McCabe’a, McClure (graf sterowania

programu),

3. Ejiogu’a, Junga (struktura modułowa),

4. Hall’a i Preiser’a (wywołania współbieżne).

Metryki programów obiektowych:

1. Chidamber’a i Kemerer’a (drzewo klas)
2. OOP-McCabe’a (enkapsulacja danych,

polimorfizm

inkluzyjny i metod,

cyklomatyka metod).

Żródło: Grzegorz Bliźniuk, Badanie jakości programów współbieżnych, wydanie II, poprawione, Warszawa,
2004, ISBN 83-88442-73-2

Inżynieria oprogramowania, wykład 6, slajd 67

Testowanie strategią czarnej skrzynki

(funkcje)

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.

Inżynieria oprogramowania, wykład 6, slajd 68

Testy czarnej skrzynki



Testy funkcjonalne - testy czarnej
skrzynki:

Testowe dane

wejściowe

Wyniki wyjściowe

testów

System

Wejście-b

Wyjście-b

Dane wejściowe

powodujące

anomalia

zachowania

Dane wyjściowe trudne

do interpretacji

(problemy z wykryciem defektów)

Inżynieria oprogramowania, wykład 6, slajd 69

Testy czarnej skrzynki



Testy funkcjonalne - testy czarnej skrzynki:

–Tester zadaje dane wejściowe i analizuje dane wyjściowe;

»Jeżeli dane wyjściowe (wyniki) nie są zgodne z założeniami, to

test pozytywnie wykrył defekt oprogramowania;

–Zadaniem testera jest taki wybór danych wejściowych, aby z

dużym p-stwem były elementami zbioru „Wejście-b”;

–Dane wejściowe mogą być dzielone na klasy równoważności

(dziedziny) o wspólnych cechach (np. liczby dodatnie);

»Zakłada się, że programy działają zwykle w porównywalny

sposób dla wszystkich elementów jednej klasy;

»Przypadki testowe projektuje się tak, aby dane wejściowe i

wyjściowe leżały wewnątrz tych klas;

Inżynieria oprogramowania, wykład 6, slajd 70

Testy czarnej skrzynki



Testy funkcjonalne - testy czarnej skrzynki:

System

Niedopuszczalne
dane wejściowe

Dopuszczalne

dane wejściowe

Dane wyjściowe

Klasy równoważności

Inżynieria oprogramowania, wykład 6, slajd 71

Testy czarnej skrzynki



Testy funkcjonalne - testy czarnej skrzynki:

–Klasy równoważności można rozpoznawać na

podstawie specyfikacji, dokumentacji
użytkownika lub doświadczenia osoby testującej;

–Po zidentyfikowaniu zbioru klas wybiera się

przypadki testowe z każdej z tych klas:

»

typowe wartości danych wejściowych, czyli punkty

środkowe klas;

»

skrajne przypadki, leżące na granicach klas – błędy

programów często pojawiają się dla wartości
granicznych;

Inżynieria oprogramowania, wykład 6, slajd 72

Testy czarnej skrzynki



Testy funkcjonalne - testy czarnej
skrzynki – przykład klas równoważności:

–Ze specyfikacji wynika, że program pobiera

od 4 do 10 danych wejściowych które są
pięciocyfrowymi liczbami większymi od
10.000;

–Przykładowe klasy równoważności:

Mniej niż 10.000

Więcej 99.000

Między 10.000 a 99.999

9.999

100.000

10.000 50.000

99.999

Inżynieria oprogramowania, wykład 6, slajd 73

Narzędzia do testowania

diagnostycznego

Warsztat testera (testy manualne/ testy

automatyczne):

Kod

źródłowy

Kod

źródłowy

Raport

z wykonania

Raport

z wykonania

Testowany

program

Testowany

program

Dane

testowe

Dane

testowe

Spodziewane

wyniki

Spodziewane

wyniki

Wyniki

testów

Wyniki

testów

Raport z

wynikami testów

Raport z

wynikami testów

Specyfikacja

Specyfikacja

Generator

danych

testowych

Generator

danych

testowych

Symulator

Symulator

Menedżer

testów

Menedżer

testów

Wyrocznia

Wyrocznia

Narzędzia do

porównywania

plików

Narzędzia do

porównywania

plików

Generator

raportów

Generator

raportów

Analizator

dynamiczny

Analizator

dynamiczny

Inżynieria oprogramowania, wykład 6, slajd 74

Analizatory przykrycia kodu

coverage analysers

Są to programy umożliwiające ustalenie obszarów kodu
źródłowego, które były wykonane w danym przebiegu
testowania. Umożliwiają wykrycie martwego kodu, kodu
uruchamianego przy bardzo specyficznych danych wejściowych
oraz (niekiedy) kodu wykonywanego bardzo często (co może
być przyczyną wąskiego gardła w programie).

Bardziej zaawansowane analizatory przykrycia kodu
umożliwiają:

Zsumowanie danych z kilku przebiegów (dla różnych
kombinacji danych wejściowych) np. dla łatwiejszego wykrycia
martwego kodu.

Wyświetlenie grafów sterowania, dzięki czemu można łatwiej
monitorować przebieg programu

Wyprowadzenie informacji o przykryciu, umożliwiające
poddanie przykrytego kodu dalszym testom.

Operowanie w środowisku rozwoju oprogramowania.

Inżynieria oprogramowania, wykład 6, slajd 75

Narzędzia automatyzujące testowanie -

Rational

Przygotowanie środowiska do tworzenia i zarządzania testami –

przykład z RUP:



Udostępnić w systemie kontroli dokumenty, w tym:

–

Dokumentów zawierających wymagania i scenariusze

–

Plików z danymi używanymi do testowania

–

Planu testów;



Opracować reguły pracy związane z wystąpieniem różnego rodzaju

zdarzeń:

–

w przypadku błędu: informacja kierowana do osoby przydzielającej

zadanie usunięcia usterki.

–

gdy oprogramowanie zostanie poprawione informacja o tym trafia do

zespołu testującego, który ponownie uruchamia skrypty testowe na

zmodyfikowanej wersji aplikacji.



Wykorzystanie mogą znaleźć następujące narzędzia:

–

TestManager – zarządzanie testami, dokumentowanie testów

–

Purify – testowanie zgodności z wymaganiami

–

TestQuantify – testowanie wydajności

–

PureCoverage – testowanie pokrycia

–

TestFactory – konstruowanie testów automatycznych

–

Robot – budowa skryptów do testów automatycznych

Inżynieria oprogramowania, wykład 6, slajd 76

Programy porównujące

Są to narzędzia programistyczne umożliwiające porównanie
dwóch programów, plików lub zbiorów danych celem wykrycia
cech wspólnych i różnic. Często są niezbędne do porównania
wyników testów z wynikami oczekiwanymi. Programy
porównujące przekazują w czytelnej postaci różnice pomiędzy
aktualnymi i oczekiwanymi danymi wyjściowymi.

Ekranowe programy porównujące mogą być bardzo użyteczne
dla testowania oprogramowania interakcyjnego. Są
niezastąpionym środkiem dla testowania programów z
graficznym interfejsem użytkownika.

comparators

Inne narzędzia do testowania:

Duża różnorodność narzędzi stosowanych w różnych fazach
rozwoju oprogramowania - wspomaganie do planowania testów,
automatyczne zarządzania danymi wyjściowymi, automatyczna
generacja raportów z testów, generowanie statystyk jakości i
niezawodności, wspomaganie powtarzalności testów, itd.

Inżynieria oprogramowania, wykład 6, slajd 77



Testowanie oprogramowania jest nieodłączną częścią jego

procesu wytwarzania i wdrażania,



Możemy testować prognostycznie i diagnostycznie,



Strategia procesu testowania zależy w dużej mierze od

przyjętego modelu cyklu życia oprogramowania, rodzaju

oprogramowania, dojrzałości zespołu testerów, posiadanych

narzędzi do testowania,



Im bardziej odpowiedzialny system, tym większe znaczenie

testów i ich udział w kosztach całego systemu,



Pozytywne przejście testów nie jest gwarancją bezbłędności i

bezawaryjności testowanego oprogramowania.

Podsumowanie

dziękuję za uwagę

Inżynieria oprogramowania, wykład 6, slajd 78

Warto postudiować ….