Inżynieria oprogramowania

Testowanie, weryfikacja i

walidacja oprogramowania

Slajd 2

Plan wykładu

• Podstawowe pojęcia
• Co testujemy?
• Rodzaje testów
Testy statystyczne
Testy dynamiczne
Testy statyczne
• Narzędzia wykorzystywane podczas

testowania

• Testy systemu
• Audyt
• Inspekcie oprogramowania

Slajd 3

Podstawowe pojęcia

•

Testowanie

Testowanie

- polega na przeprowadzeniu

eksperymentów z pewnymi częściami systemu (lub jego

całością), wykorzystujące specjalnie dobrane dane

testowe i porównaniu wyników uzyskanych z

oczekiwanymi. Tak postępując można w sposób

kontrolowany i systematyczny, zademonstrować

obecność określonej funkcjonalności systemu oraz badać

obecność niepożądanych efektów

•

Weryfikacja

Weryfikacja

jest to testowanie oprogramowania pod

względem wymagań zdefiniowanych w fazie analizy.

•

Walidacja

Walidacja

(ang. validation) - ocena systemu podczas

lub na końcu procesu jego rozwoju na zgodność z

rzeczywistymi wymaganiami użytkownika

Slajd 4

Typowe błędy

Klasa błędu Możliwy błąd

Funkcjonalny

zła lub brakująca funkcja

Systemowy

pomylone interfejsy, nieprawidłowe zarządzanie zasobami

Przetwarzania

niewłaściwe przetwarzanie danych

Danych

błędna specyfikacja, projekt, rozmieszczenie lub inicjalizacja

struktur danych

Kodowania

niewłaściwe użycie języka programowania

Dokumentacyjny niepełna lub błędna treść dokumentu

Slajd 5

Co testujemy?

Slajd 6

Co testujemy? 1/4

•

Kompletność i jakość

Kompletność i jakość założonych funkcji
systemu

•

Wydajność

Wydajność systemu i poszczególnych jego
funkcji

•

Zabezpieczenie systemu

Zabezpieczenie systemu - odporność systemu
na naruszenia prywatności, tajności,
integralności, spójności i dostępności

• Własności operacyjne systemu, np.

wymagania organizacyjne, jakość komunikatów
systemu, jakość informacji o błędach, jakość
pomocy

Slajd 7

Co testujemy? 2/4

•

Przenoszalność oprogramowania

Przenoszalność oprogramowania - poprawność
działania w zróżnicowanym środowisku, różnych
rozmiarach zasobów i rodzajach sprzętu

•

Odtwarzalność oprogramowania

Odtwarzalność oprogramowania (ang.
maintainability) - mierzoną zwykle średnim czasem
doprowadzenia do sprawnego działania po
wystąpieniu awarii (od zgłoszenia awarii do
ponownego działania)

•

Bezpieczeństwo oprogramowania

Bezpieczeństwo oprogramowania - stopień
minimalizacji katastrofalnych skutków wynikających
z niesprawnego działania (standardowy przykład -
awaria zasilania)

Slajd 8

Co testujemy? 3/4

•

Obciążalność systemu

Obciążalność systemu - zdolność do
poprawnej pracy przy dużych obciążeniach; np.
maksymalnej liczbie użytkowników, bardzo
dużych rozmiarach danych; w tych testach czas
nie odgrywa najistotniejszej roli, chodzi
wyłącznie o to, czy system poradzi sobie w
ekstremalnych warunkach)

•

Skalowalność systemu

Skalowalność systemu - spełnienie warunków
(m.in. czasowych) przy znacznym wzroście
obciążenia

•

Niezawodność oprogramowania

Niezawodność oprogramowania - zwykle
mierzoną średnim czasem pomiędzy błędami

Slajd 9

Co testujemy? 4/4

• Modyfikowalność oprogramowania - zdolność do

zmiany przy zmieniających się założeniach lub
wymaganiach

• Jakość dokumentacji, pomocy, materiałów

szkoleniowych

• Wykorzystanie zasobów - np. czas jednostki

centralnej, pamięć operacyjna, przestrzeń dyskowa, ...

• Spełnianie ograniczeń - np. na zajmowaną pamięć,

obciążenia procesora, ...

• Interfejsy systemu na zgodność z wymaganiami
• Akceptowalność systemu, tj. stopień

usatysfakcjonowania użytkowników.

Slajd 10

Rodzaje

testów

Slajd 11

Rodzaje testów

Główne cele testowania:

• wykrycie i usunięcie błędów w systemie
• ocena niezawodności systemu

Na tej podstawie wyróżniamy:

•

Wykrywanie błędów

Wykrywanie błędów

- testy, których

głównym celem jest wykrycie jak
największej liczby błędów w programie

• Testy

statystyczne

statystyczne - celem jest wykrycie

przyczyn najczęstszych błędnych wykonań
oraz ocena niezawodności systemu

Slajd 12

Typowe fazy testowania systemu

• Testy

częściowe

częściowe

(np. modułów)

- wykonywane najczęściej

podczas implementacji, bezpośrednio po zakończeniu
realizacji poszczególnych modułów

• Testy

systemu

systemu

- wykonywane po zintegrowaniu części

składowych; testowane są poszczególne podsystemy oraz
system jako całość

• Testy

akceptacji

akceptacji

(ang. acceptance testing)

- w

przypadku oprogramowania realizowanego na zamówienie
system przekazywany jest klientowi do przetestowania przez
przyszłych użytkowników (testy takie nazywa się testami

alfa

alfa

);w przypadku oprogramowania sprzedawanego rynkowo

testy takie polegają na nieodpłatnym przekazaniu pewnej
liczby kopii systemu grupie użytkowników (testy

beta

beta

)

Slajd 13

Testy statystyczne

Slajd 14

Testy statystyczne

• 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ą nie być
wystarczająco wiarygodne)

• Założeniem jest przetestowanie systemu w:
typowych sytuacjach (pojawiają się znacznie

częściej);

sytuacjach skrajnych.
• Przykład techniki tzw. „brutalnej siły”, która jest

jednak stosunkowo mało efektywna

Slajd 15

Techniki analizy produktu

• Techniki analizy dynamicznej

- testy funkcjonalne
- testy strukturalne

• Techniki analizy statycznej

- dowodzenie poprawności programów
- interpretacja symboliczna

Slajd 16

Testy dynamiczne - funkcjonalne

Slajd 17

Testy funkcjonalne

(ang. black-box testing)

• Sprawdzanie funkcji oprogramowania bez

zaglądania do środka programu; testujący
traktuje sprawdzany moduł jak „czarną
skrzynkę”, której wnętrze jest niewidoczne

• Powinno obejmować cały zakres danych

wejściowych, co zwykle jest praktycznie
niemożliwe ze względu na olbrzymią liczbę
dopuszczalnych danych wejściowych (efekt
„eksplozji danych testowych”)

Slajd 18

Testy funkcjonalne

(ang. black-box testing)

•

Funkcje systemu znajdujące się w poprzedniej

Funkcje systemu znajdujące się w poprzedniej

wersji są istotniejsze niż nowo wprowadzone

wersji są istotniejsze niż nowo wprowadzone
(użytkownicy, którzy posługiwali się daną funkcją w
poprzedniej wersji systemu będą bardzo niezadowoleni
jeżeli w nowej wersji ta funkcja przestanie działać; poza
tym błąd w czymś nowym jest stosunkowo łatwo
wytłumaczalny, natomiast „popsucie” czegoś dobrze
funkcjonującego dużo trudniej)

•

Typowe sytuacje są ważniejsze niż wyjątki lub

Typowe sytuacje są ważniejsze niż wyjątki lub

sytuacje skrajne

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 nietypowych
danych)

Slajd 19

Testy funkcjonalne

(ang. black-box testing)

W praktyce przetestowanie kombinacji danych

wejściowych nawet zredukowanych do
“typowych” i “granicznych” jest najczęściej
niemożliwe; konieczny jest pewien wybór.

•

Możliwość wykonania funkcji jest

Możliwość wykonania funkcji jest

ważniejsza niż jakość jej wykonania

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)

Slajd 20

Testy dynamiczne -

strukturalne

Slajd 21

Testy strukturalne

• W celu odróżnienia od testów funkcjonalnych

nazywane testowaniem na zasadzie białej skrzynki (ang.
white-box testing)

• Celem jest sprawdzanie wewnętrznej logiki

oprogramowania poprzez odpowiedni dobór danych
wejściowych, dzięki czemu można prześledzić wszystkie
istotne ś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

Slajd 22

Testy strukturalne

• Zwykle niezbędne jest wcześniejsze

odpowiednie przygotowanie danych
testowych lub wykorzystanie specjalnych
programów usprawniających testowanie (np.
programu wywołującego testowaną procedurę z
różnymi parametrami)

• Ograniczeniem testów strukturalnych jest

niemożliwość wykrycia brakujących funkcji
w programie (wadę tę usuwa testowanie
funkcjonalne)

Slajd 23

Testy

statyczne

Slajd 24

Testy statyczne

Polegają na analizie kodu bez uruchomienia

programu, możliwe techniki:

• dowody poprawności (nie są praktycznie

osiągalne dla rzeczywistych programów);

• sformalizowane przeglądy;

Slajd 25

Narzędzia

wykorzystywane

podczas testowania

Slajd 26

Narzędzia wykorzystywane

podczas testowania

•

Programy uruchamiające

Programy uruchamiające

(ang. debuggers)

- przydatne dla wewnętrznego testowania jak
i do testowania przez osoby zewnętrzne
(zakładają znajomość kodu)

•

Analizatory przykrycia kodu

Analizatory przykrycia kodu

(ang. coverage

analysers) - umożliwiają ustalenie obszarów
kodu źródłowego; umożliwiają wykrycie
martwego kodu, kodu uruchamianego przy
bardzo specyficznych danych wejściowych
oraz kodu wykonywanego bardzo często (co
może być przyczyną wąskiego gardła w
programie)

Slajd 27

Narzędzia wykorzystywane

podczas testowania

•

Programy porównujące

Programy porównujące

(ang. comparators) -

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; wygodne do porównania
wyników testów z wynikami oczekiwanymi;

• Różnorodne inne narzędzia

np. do

planowania testów, automatycznego
zarządzania danymi wyjściowymi,
automatyczna generacja raportów z testów,
generowanie statystyk jakości i niezawodności,
wspomaganie powtarzalności testów, ...

Slajd 28

Testy systemu

Slajd 29

Testy systemu

•

Testowanie wstępujące

Testowanie wstępujące: najpierw testowane są
pojedyncze moduły, następnie moduły coraz wyższego
poziomu, aż do osiągnięcia poziomu całego systemu; nie
zawsze jest to możliwe, zwłaszcza gdy moduły są od
siebie zależne; niekiedy moduły współpracujące
można zastąpić implementacjami szkieletowymi

•

Testowanie zstępujące

Testowanie zstępujące: rozpoczyna się od testowania
modułów wyższego poziomu; moduły niższego poziomu
zastępuje się implementacjami szkieletowymi; po
przetestowaniu modułów wyższego poziomu dołączane są
moduły niższego poziomu; proces ten jest kontynuowany
aż do zintegrowania i przetestowania całego systemu

Slajd 30

Testy systemu

•

Testy obciążeniowe

Testy obciążeniowe (ang. stress testing) - 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; polegają na wymuszeniu obciążenia
równego lub większego od maksymalnego

•

Testy odporności

Testy odporności (ang. robustness testing)
-sprawdzenie działania w przypadku zajścia
niepożądanych zdarzeń, np. awarii sprzętu,
wprowadzenia niepoprawnych danych czy wydania
sekwencji niepoprawnych poleceń

Slajd 31

Audyt

Slajd 32

Audyt

Audyt

- 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

Celem audytu

projektu informatycznego jest

dostarczenie odbiorcy
i dostawcy obiektywnych, aktualnych i syntetycznych
informacji
o stanie całego projektu

Przedmioty audytu:

*procesy projektu informatycznego - celem jest
sprawdzenie
prawidłowości wykonywanych prac jak i sposobu ich
wykonywania
*produkty (cząstkowe) projektu informatycznego -
celem jest
sprawdzenie czy rezultaty poszczególnych prac
odpowiadają
zakładanym wymaganiom

Slajd 33

Audyt projektu informatycznego

• Aby zapewnić obiektywność, audyt powinien być

przeprowadzony przez osoby niezależne od
zespołu projektowego (np. odpowiednią organizacje
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”

Slajd 34

Inspekcje

oprogramowania

Slajd 35

Inspekcje oprogramowania

• „

Inspekcja

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”

Slajd 36

Inspekcje oprogramowania

• Technika o (potencjalnie) dużej

skuteczności (średnia 60%).

• Stosowana dla najważniejszych

systemów, bądź ich najbardziej istotnych
części.

• Dlaczego nie są powszechne?

- nie potrzeba w zasadzie specjalnych

narzędzi, ale potrzeba planowania i
kompetentnych ludzi

- analiza kosztów i zysków nie jest prosta

Slajd 37

Cele oraz cechy inspekcji

Cele inspekcji:

•

doraźne:

–

wykrywanie defektów w produktach procesu
wytwarzania oprogramowania a następnie ich usunięcie

–

formalne potwierdzenie jakości produktu

•

strategiczne:

–

doskonalenie procesu wytwórczego w oparciu o analizę
przyczyn znalezionych defektów

–

obniżenie kosztów wytwarzania

–

poprawa jakości produktów

–

doskonalenie samych inspekcji i rozwój kultury jakości w
organizacji

Slajd 38

Cele oraz cechy inspekcji

Pożądane cechy inspekcji:
• 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

• Błędy są wykorzystywane w poprawie

procesu programowego (prewencja)

Slajd 39

Schemat inspekcji

Inicjowanie i dopuszczenie do inspekcji

Organizacja i zaplanowanie przebiegu

Spotkanie inicjujące

Spotkanie kontrolne (burza mózgów)

Redakcja dokumentu inspekcji

Kontrola indywidualna

Kontrola indywidualna

Dystrybucja wniosków z inspekcji

Kontrola indywidualna ...

Slajd 40

Korzyści inspekcji

• wzrost produktywności (od 30% do 100%)
• skrócenie czasu projektu (od 10% do 30%)
• skrócenie czasu wykonywania testów (5x-10x) a

przez to i ich kosztu

• mniejsze koszty pielęgnacji naprawczej
• większy komfort pracy (brak presji czasu i

nadgodzin) oraz większa pewność dostarczania na

czas (bo wcześnie wiemy o problemach)

• zwiększenie motywacji pracowników:

– świadomość, że produkt będzie oceniany
– nauka przez znajdowanie błędów

Slajd 41

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ść autorów do lekceważenia defektów na

etapie opracowywania dokumentów (“inspekcja
wskaże błędy...”)

• Poczucie zagrożenia u autora - nieuzasadniona

obrona własnych rozwiązań

• Krytyczne nastawienie do autora

Slajd 42

O czym był wykład?

• Podstawowe pojęcia
• Co testujemy?
• Rodzaje testów
Testy statystyczne
Testy dynamiczne
Testy statyczne
• Narzędzia wykorzystywane podczas

testowania

• Testy systemu
• Audyt
• Inspekcie oprogramowania