Inżynieria oprogramowania
Testowanie, weryfikacja i
walidacja oprogramowania
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