Weryfikacja i walidacja

Walidacja – proces oceny oprogramowania na zakończenie procesu (fazy) produkcyjnej w celu
sprawdzenia, czy jest wolne od błędów i niezgodności

Weryfikacja – proces określenia, czy produkt danej fazy produkcyjnej spełnia wymagania
postawione w fazie poprzedniej

Metody:

–

przeglądy techniczne oprogramowania (przegląd techniczny wykonywalnej specyfikacji
programu)

–

dowodzenie poprawności

–

symulacje i prototypowanie

–

śledzenie wymagań

Warto zapamiętać!

–

wydajność testowania to 2-4 błędów/h, a przeglądów 10-12 błędów/h

–

pracochłonność poprawy błędów wykrytych w testowania to 10-40 h/błąd, a w wyniku
przeglądu 1 h/błąd

Testowanie

Testowanie – proces sprawdzania/oceny, czy produkt lub jego część jest „dobra”.

Atestowanie (walidacja) – testowanie zgodności systemu z rzeczywistymi potrzebami
użytkownika

Klasyfikacja testów

Testy statystyczne – wykrywanie przyczyn najczęstszych błędnych wykonań oraz ocena
niezawodności systemu.

Schemat wykonania:

–

losowa konstrukcja danych wejściowych zgodnych 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 działania z poprawnymi wynikami

Niektóre cechy:

–

testowanie systemu w typowych sytuacjach

–

możliwość automatyzacji (brute force, sprawdzanie wszystkich możliwości?)

Miary niezawodności oprogramowania

–

prawdopodobieństwo wystąpienia błędnego wykonania podczas realizacji transakcji
•

stosowane głównie w przypadku testowania systemów o charakterze transakcyjnym
(operacje mogą się zakończyć wyłącznie sukcesem bądź ich anulacją)

•

wyliczane na podstawie częstości transakcji zakończonych niepowodzeniem

–

częstotliwość występowania błędnych wykonań
•

dotyczy głównie systemów, które nie posiadają charakteru transakcyjnego

•

określa przewidywalną liczbę błędnych wykonań w jednostce czasu

–

średni czas między błędnymi wykonaniami

•

szacowany czas pomiędzy wystąpieniem błędnych wykonań

–

dostępność systemu
•

określa prawdopodobieństwo dostępności systemu dla użytkownika w danej chwili

•

tylko błędy prowadzące do czasowej niedostępności systemu mają wpływ na tę miarę

•

zależy też od szybkości powrotu do stanu normalnego

Miary niezawodności pozwalają oszacować koszty konserwacji!

Testy funkcjonalne

–

system traktowany jako czarna skrzynka, która w nieznany sposób realizuje wymagane
funkcje

–

dane wejściowe dzielone na klasy, których działanie powinno być podobne

–

sprawdzamy działania funkcji dla:
•

wszystkich dopuszczalnych warunków wejściowych i opcji

•

danych na granicach dziedzin wejściowych

•

danych na granicach dziedzin wynikowych

•

danych dla granic funkcjonalnych

•

danych niepoprawnych, niespodziewanych i destrukcyjnych

Zasady wyboru testowanych funkcji i danych wejściowych:

–

możliwość wykonania funkcji jest ważniejsza niż jakość wykonania (tj. klient akceptuje
niedopracowane rozwiązanie, jeżeli chce mieć je jak najszybciej)

–

funkcje systemu znajdujące się w poprzedniej wersji są istotniejsze niż nowo wprowadzone

–

typowe sytuacje są ważniejsze niż wyjątki (lepiej żeby się wysypywało czasem niż często)

Testy strukturalne

–

zakładają znajomość sposobu implementacji testowanych funkcji

Wybrane kryteria doboru danych wejściowych

–

kryterium pokrycia wszystkich instrukcji (każda instrukcja wykonana co najmniej raz)

–

kryterium pokrycia instrukcji warunkowych (każdy warunek instrukcji warunkowej został
co najmniej raz spełniony i raz niespełniony

Dobór danych wejściowych dla pętli:

–

tak, by nie wykonała się żadna iteracja (lub minimalna liczba)

–

tak, aby wykonała się maksymalna liczba iteracji

–

tak, aby wykonała się przeciętna liczba iteracji

Testy statyczne

–

analiza kodu bez uruchomienia programu (efektywniejsze od strukturalnych!)

Techniki:

–

dowody poprawności (trudne)

–

metody nieformalne (inspekcje Fagana)
●

śledzenie przebiegu programu

●

wyszukiwanie typowych błędów, np.:
•

niezainicjowane zmienne

•

porównania liczb zmiennoprzecinkowych

•

indeksy wykraczające poza tablice

•

błędne operacja na wskaźnikach

•

błędy w instrukcjach warunkowych

•

niekończące się pętle

•

błędy popełniane dla granicznych wartości

•

błędne użycie/pominięcie nawiasów w złożonych wyrażeniach

•

nieuwzględnienie błędnych danych

Ocena liczby błędów

–

liczba błędów nie musi mieć związku z niezawodnością oprogramowania

–

liczba błędów ma bezpośredni wpływ na konserwację oprogramowania

Technika posiewania błędów

–

wprowadzamy celowo błędy w miejsca, w których potencjalnie mogą znajdować się inne
błędy

–

wykrywanie błędów może dodatkowo ujawnić te, które nie zostały wprowadzone celowo

–

wymaga znajomości na temat tego, w których częściach programu mogą znajdować się
błędy

Testy systemu
Techniki:

–

testy pod obciążeniem

–

testy odporności
•

zanik zasilania

•

awaria sprzętowa

•

wprowadzenie niepoprawnych danych

•

sekwencja niepoprawnych poleceń

Bezpieczeństwo oprogramowania

–

systemy krytyczne z punktu widzenia bezpieczeństwa to takie, w których błędne wykonania
mogą prowadzić do zagrożenia życia i zdrowia ludzkiego oraz spowodować duże straty
materialne lub złamanie przepisów prawnych

–

bezpieczeństwo nie jest tożsame z niezawodnością
•

system zawodny może być bezpieczny, jeżeli skutki błędnych wykonań nigdy nie są
groźne

•

niezawodność nie opisuje sytuacji wyjątkowych

•

niebezpieczeństwo może wynikać z awarii sprzętowych

Analiza drzewa błędów jako podstawowa technika zwiększania bezpieczeństwa

–

korzeniem drzewa jest jedna z rozważanych niebezpiecznych sytuacji

–

wierzchołkami są pośrednie sytuacje

–

unikanie niebezpieczeństwa polega na unikaniu jego przyczyn, czyli:
•

unikanie błędów podczas implementacji „wierzchołków” drzewa

•

zlecenie realizacji „wierzchołków” doświadczonym programistom

•

stosowanie technik programowania N-wersyjnego (tworzymy kilka implementacji tego
samego algorytmu i sprawdzamy, czy wszystkie dają ten sam wynik)

•

szczególnie dokładne testowanie „wierzchołków”

W drzewach błędów można używać operatorów logicznych sumy, koniunkcji, wykluczenia.

Systemy jakości
Analogia między produkcją systemów informatycznych a produkcją towarów pzrzemysłowych na
początku XX wieku:

–

oprogramowanie jest zawodne

–

producent dyktuje warunki

–

niezadowalająca obsługa klienta

By poprawić sytuację stosuje się systemy jakości.

Zagadnienia systemów jakości:

–

powtarzalność
•

norma ISO9001 - „opisz to, co robisz, a potem postępuj tak jak napisano”

–

zapewnienie minimalnej liczby defektów
•

sprawność procesów biznesowych na poziomie „pięciu dziewiątek” (99,999%)

–

tworzenie coraz lepszych produktów
•

japońskie określenie „kaizen” - wprowadzanie stałych, drobnych informacji

•

„jeżeli możesz coś zrobić lepiej bez dodatkowego nakładu pracy, zrób to”

Jakość kosztuje:

–

opracowanie i wdrożenie standardów

–

stosowanie automatycznych narzędzi testujących

–

utrzymanie wewnętrznego działu jakości

–

znalezienie najlepszych ludzi

–

szkolenia

Klient musi mieć świadomość, że płaci dodatkowo za jakość.

CMM (Capability Maturity Model)

–

model dojrzałości procesu wytwarzania, opracowany przez Instytut Inżynierii
Oprogramowania (ang. się) w Carnegie Mellon University w Pittsburghu na początku lat
90tych dla Departamentu Obrony USA

–

celem było uzyskanie metody oceny przydatności potencjalnych wykonawców (ustalono
próg na poziomie trzecim)

–

obecnie wykorzystywany jest SPICE korzystający z cech modeli CMM, Bootstrap i
ISO9003