Inżynieria Oprogramowania
Inżynieria
Oprogramowania
Wykład
Testowanie Oprogramowania
Outline:
Testy jednostkowe a testy systemowe
Testowanie zatwierdzające a testowanie usterek
Testy jednostkowe
Test Driven Development
Asercje
Testy systemowe
Testy wydajności
Testy obciążenia
Testy czarnej i białej skrzynki
1
Inżynieria Oprogramowania
Proces testowania
Testy komponentów (testy jednostkowe)
Testowanie indywidualnych komponentów
Zazwyczaj dokonywanie przez programistę
Wywodzą się z doświadczenia programisty
Testy systemowe
Testowanie grupy komponentów zintegrowanych do
systemu/pod-systemu
Wykonywane przez niezależne zespoły testerów
Bazujące na specyfikacji systemu
Co to znaczy, że test zakończył
się powodzeniem?
2
Inżynieria Oprogramowania
Typy testów czyli różne cele
testowania
Testy zatwierdzające
Wykazanie twórcom i klientom systemu, że spełnia on
wymagania
Pomyślny test wykazuje, że system pracuje tak jak
powinien
Testy usterek
Wykrycie błędów w oprogramowaniu, niepoprawnego
zachowania lub niezgodności ze specyfikacją
Pomyślny test wykazuje niepoprawne działanie,
eksponując usterkę systemu.
Proces testowania oprogramowania
Raport
Przypadek Dane Rezultaty
testu
testowy testowe testu
Zaprojektuj Przygotuj dane Uruchom program Porównaj z
przypadek testowy testowe Z danymi testowymi przypadkiem testowym
3
Inżynieria Oprogramowania
Testowanie komponentów
Testy komponentów (testy jednostkowe)
Komponenty są testowane w izolacji
Są to testy usterek
Przez komponent rozumiemy:
Pojedynczą funkcję lub metodę w klasie
Klasy obiektów z kilkoma atrybutami i metodami
Zbiory komponentów wraz z interfejsem
zdefiniowanym dla wykorzystania ich funkcjonalności
Testowanie klas obiektów
Kompletne testy pokrywające klasę składają się
z :
Testowania wszystkich operacji obiektu
Ustawiania i odczytywania stanu obiektu
Przećwiczenia obiektu we wszystkich możliwych
stanach
Mechanizmy takie jak dziedziczenie powodują
trudności z projektowaniem testów dla klas.
4
Inżynieria Oprogramowania
Test Driven Development (TDD)
Podejście do procesu implementacji
oprogramowania mające na celu:
Podniesienie jakości końcowego produktu.
Minimalizację czas wytwarzania
Strukturalizacja procesu pomaga pokonać
problemy, które się pojawiają
TDD nie jest mechanizmem testowania
oprogramowania tylko podejściem do procesu
jego tworzenia
Proces TDD
1. Napisz test
Napisz test tak jakby testowany kod istniał.
Programista skupia się na użyciu (interfejsie
programistycznym)
Uruchomienie testu zakończy się niepowodzeniem
2. Napisz testowany kod
3. Zrefaktoryzuj kod
4. Napisz kolejny test aby rozszerzyć
funkcjonalność (iteracje)
5
Inżynieria Oprogramowania
Zalety
Początkowo programista koncentruje się na API
a nie na pisaniu kodu
Jeżeli napiszesz test po napisaniu funkcjonalność test
zapewne się powiedzie (co nie znaczy, że kod jest
dobry)
Test napisany przed napisaniem kodu może być
wielokrotnie używany (testy jednostkowe jako
część procesu budowy systemu)
Każda zmiana wprowadzona do kodu może być
zweryfikowana przez wcześniej napisany test
Motywy
KISS   Keep It Simple, Stupid  struktura jest
prostsza ponieważ poprzez napisanie testu
skupiamy się na użyciu
YAGNI   You Ain t Gonna Need It  nie
dodajemy funkcjonalności, która nie zostało
uwzględniona w testowaniu.
6
Inżynieria Oprogramowania
Korzyści dla programistów
Zazwyczaj
stają się bardziej produktywni
rzadziej korzystają z debuggera
są bardziej zadowoleni ponieważ działają na zasadzie
małych kroków bez potrzeby myślenia o całości
systemu
produkują modularny, bardziej zrozumiały kod, który
jest łatwiejszy w zarządzaniu
gdy nie mogą znalez
ć błędu w kodzie, mogą zawsze
zrobić mały krok wstecz bez nadmiernej straty czasu
JUnit
Framework do tworzenia  powtarzalnych testów
jednostkowych
Wykorzystywany do automatyzacji procesu
testowania w środowisku Java
Niekoniecznie musi być wykorzystywany w
kontekście TDD
7
Inżynieria Oprogramowania
Przykład
Programowanie z użyciem asercji
Asercja  predykat umieszczony w kodzie
programu, który według programisty powinien
być zawsze prawdziwy
Wykorzystywane do specyfikacji programów
oraz weryfikacji ich poprawności
8
Inżynieria Oprogramowania
Design/Programming by Contract
Język Eiffel (twórca: Bertrand Meyer)
Projektowanie na zasadzie metafory klienta i dostawcy
Asercje stanowią formę dokumentacji programu
Precondition
Assercja umieszczona na początku bloku kodu
Zestaw warunków wymaganych dla poprawnego działania
Postcondition
Asercja umieszczona na końcu bloku kodu
Opis oczekiwanego stanu systemu po zakończeniu wykonywania
instrukcji
Invariants  niezmiennik wymagany podczas działania
Weryfikacja poprzez assercje
Weryfikacja czy założenia poczynione przez programistę
podczas pisania kodu są spełnione w czasie jego
wykonania.
int total = countNumberOfUsers();
if (total % 2 == 0)
{
// total parzysty
} else
{
// total nieparzysty
assert total % 2 == 1 :  nieparzysty ;
}
9
Inżynieria Oprogramowania
Polityka testowania
Tylko wyczerpujące testy mogą wykazać, że program nie
ma poważniejszych usterek.
Ale takie testy są w praktyce niemożliwe :&
Polityka testowania definiuje podejście wykorzystywane
do wyboru testów systemowych:
Wszystkie funkcje dostępne z interfejsu powinny być
przetestowane
Kombinacje funkcji dostępnych z tego samego menu powinny
być przetestowane
Tam gdzie wymagane jest wprowadzanie danych funkcje muszą
być testowane z poprawnymi i niepoprawnymi danymi
Testy systemowe
Uwzględniają integrację komponentów
tworzących system / pod-system
Mogą uwzględniać testowanie inkrementacji
systemu dostarczanej klientowi
Fazy:
Testy integracyjne
Zespól testujący ma dostęp do kodu z
ródłowego. System
jest testowany w trakcie integracji komponentów.
Testy wydania
Zespół testujący testuje kompletny system.
10
Inżynieria Oprogramowania
Testy integracyjne
Testowanie problemów powstających na styku
komponentów
Integracja Top-Down
Opracowanie szkieletu systemu i wypełnienie go
komponentami
Integracja Bottom-Up
Zintegrowanie komponentów infrastruktury a
następnie dodanie komponentów funkcjonalnych
Uproszczenie - inkrementacje
Przyrostowe testy integracyjne
Sekwencja 1 Sekwencja 2 Sekwencja 3
11
Inżynieria Oprogramowania
Testy wydania
Test dystrybucji systemu, który ma być
dostarczony do klientów
Celem jest zwiększenie przekonania klientów, że
produkt spełnia wymagania
Zazwyczaj są to testy typu czarnej skrzynki
(black-box) nazywane również testami
funkcjonalnymi
Bazują tylko na specyfikacji systemu
Zespół testujący nie ma wiedzy o implementacji
systemu
Testowanie metodą czarnej skrzynki
Wejścia
Wejściowe powodujące
dane testowe anormalne
zachowanie
Wyjścia
ujawniające
istnienie
Wyjściowe defektów
dane testowe
12
Inżynieria Oprogramowania
Testowanie - wskazówki
Wybierz takie wejścia, które wymusza
wygenerowanie wszystkich komunikatów o
błędach
Zaprojektuj dane wejściowe tak, żeby
spowodować przepełnienie bufora
Powtarzaj kilkukrotnie te same dane wejściowe
lub ich serie
Wymuś generację błędnych danych wyjściowych
Wymuś zbyt duże lub zbyt małe rezultaty
Testy wydajności
Stanowią zazwyczaj część testów wydania i
uwzględniają takie własności systemu jak
wydajność i niezawodność
Wymagają serii testów o wzrastającym
obciążeniu, aż do poziomu, który powoduje
spadek wydajności nie do zaakceptowania
13
Inżynieria Oprogramowania
Testy obciążenia
Testowanie powyżej maksymalnego obciążenia
aż do pojawienia się awarii
Testują zachowanie systemu w sytuacji błędu.
Szczególnie użyteczne dla systemów
rozproszonych, które mogą być narażone na
przeciążenia sieci komputerowej
Pomysły na testy - Burza
mózgów
Pole przyjmuje wartości całkowite z przedziału
<20,50>
Jakie testy powinniśmy przeprowadzić?
14
Inżynieria Oprogramowania
Typowe odpowiedzi:
Test Dlaczego? Oczekiwany
rezultat
20 Najmniejsza poprawna Akceptuj
wartość
19 Najmniejsza -1 Odrzuć, komunikat
o błędzie
0 0 jest zawsze interesujące Odrzuć, komunikat
o błędzie
Blank Puste pole, co powoduje? Odrzuć? Ignoruj?
30 Poprawna wartość Akceptuj
50 Największa poprawna Akceptuj
wartość
51 Największa +1 Odrzuć, komunikat
o błędzie
-1 Wartość ujemna Odrzuć, komunikat
o błędzie
4294967296 2^32, integer overflow? Odrzuć, komunikat
o błędzie
Skąd brać pomysły na testy?
Modele
Specyfikacje
Narzekania klientów
Burze mózgów
15
Inżynieria Oprogramowania
Klasy równoważności
Dane wejściowe oraz rezultaty można często
podzielić na klasy (dziedziny).
Liczby dodatnie, liczby ujemne, napisy bez białych
znaków
W ramach wartości należących do danej klasy
program zachowuje się w porównywalny
sposób.
Przypadki testowe powinny być określane ta, aby
uwzględniały wszystkie klasy.
Klasy równoważności
Niepoprawne
Poprawne
dane wejściowe
dane wejściowe
Dane wyjściowe
16
Inżynieria Oprogramowania
Wybieranie wartości testowych dla
klas równoważności
Liczba wartości wejściowych
Mniej niż 4 Między 4 a 10 Więcej niż 10
Wartości wejściowe
Mniej niż 10000 Między 10000 a 99999 Więcej niż 99999
Przykład  procedura wyszukująca
procedure Search (K : ELEM ; T: SEQ of ELEM;
Found : in out BOOLEAN; L: in out ELEM_INDEX) ;
Pre-condition
-- ciąg ma przynamniej jeden element
T FIRST <= T LAST
Post-condition
-- element został znaleziony i L jest jego referencją
( Found and T (L) = K)
or
-- elementu nie ma w ciągu
( not Found and
not (exists i, T FIRST >= i <= T LAST, T (i) = K ))
17
Inżynieria Oprogramowania
Procedura wyszukiwania  klasy
równoważności (1)
Dane wejściowe, w których element kluczowy
znajduje się w ciągu (Found = true)
Dane wejściowe, w których element kluczowy
nie występuje w ciągu
Dodatkowe założenia
Testuj na ciągach, które składają się tylko z
jednej wartości
Użyj ciągów rozmaitych rozmiarów w różnych
testach
Opracuj testy, aby można było odczytać
pierwszy, środkowy i ostatni element ciągu
18
Inżynieria Oprogramowania
Procedura wyszukiwania  klasy
równoważności (2)
Dane wejściowe, w których element kluczowy
znajduje się w ciągu (Found = true)
Dane wejściowe, w których element kluczowy
nie występuje w ciągu
Ciąg wejściowy zawiera jedną wartość
Liczba elementów ciągu wejściowego jest
większa niż 1
Procedura wyszukiwania  klasy
równoważności (3)
Ciąg Element
T K Found (L)
Jedna wartość Jest w ciągu
17 17 True, 1
Jedna wartość Nie ma w ciągu
17 1 False, ??
> 1 wartość Jest pierwszym
17,29,21,23 17 True, 1
elementem
41,18,9,31,30, 45 True, 7
> 1 wartość Jest ostatnim
16,45
elementem
12,15,4,34,45 4 True, 3
> 1 wartość Jest środkowym
elementem
21,23,29,34,1 22 False, ??
> 1 wartość Nie ma w ciagu
5,32,11
19
Inżynieria Oprogramowania
Testy strukturalne
Nazywane również testami białej skrzynki
(white-box testing)
Opracowywane na podstawie wiedzy o
strukturze i implementacji oprogramowania
Celem jest zapewnienie aby każde instrukcja
programu była wykonana co najmniej raz (nie
wszystkie możliwe ścieżki programu).
Dla stosunkowo niewielkich komponentów
Wyszukiwanie binarne
Przykład
20
Inżynieria Oprogramowania
Dodatkowe klasy równoważności
Granice klas równoważności
Wyszukiwanie binarne  klasy
równoważności
T K Result (found,
position)
17 17 True, 1
17 1 False, ??
17, 21,23, 29 17 True, 1
9,16,18,30,31,41,45 45 True, 7
17,18,21,23,29,33,38 23 True, 4
17,18,21,23,29,33,41 21 True, 3
17,18,21,23,32 23 True, 4
21,23,29,33,38,55,64,65 22 False, ??
21
Inżynieria Oprogramowania
Wyszukiwanie binarne  klasy
równoważności
Przykład cd.
Testowanie ścieżek
Odmiana testowania strukturalnego, której
celem jest zbadanie każdej niezależnej ścieżki
wykonania programu
Punktem startu jest opracowanie grafu strumieni
(grafu przepływu) programu
Węzły reprezentują decyzje (instrukcje decyzyjne)
Krawędzie reprezentują przepływ sterowania
Metoda wykorzystywana najczęściej w ramach
testów jednostkowych
22
Inżynieria Oprogramowania
Wyszukiwanie binarne  graf
strumieni
1
2
3
while(start <= end)
start > end
4
5
table[center] == key
6
9
table[center] < key
11 10
7 8
Niezależne ścieżki
1,2,3,4,5,9,10,11
1,2,3,4,11
1,2,3,4,5,6,7,4
1,2,3,4,5,6,8,4
Przypadki testowe powinny uruchomić wszystkie
ścieżki
23
Inżynieria Oprogramowania
Testowanie interfejsów
Wykorzystywane po zintegrowaniu modułów lub
podsystemów
Celem jest wykrycie usterek (testy defektów),
które pojawiły się z powodu błędów w
interfejsach (np. błędne założenia)
Niewłaściwe użycie interfejsu
Niezrozumienie interfejsu
Błędy synchronizacji
Typy interfejsów
Interfejsy parametryczne
Przekazują dane z jednego komponentu do drugiego
Interfejsy w pamięci dzielonej
Dane w pamięci współdzielonej
Interfejsy proceduralne
Jeden podsystem obudowuje procedury udostępniane innym
podsystemom
Interfejsy z przekazywaniem komunikatów
Jeden podsystem żąda usługi innego przez przesłanie
komunikatu. Komunikat zwrotny zawiera wynik wykonania usługi
24
Inżynieria Oprogramowania
Testowanie interfejsów - porady
Jawnie wypisz wszystkie wywołania zewnętrznych
komponentów. Opracuj zbiór testów, w których wartości
parametrów leżą na granicach zakresów
W przypadku przekazywania wskaz
ników (referencji)
przetestuj z zerowymi wartościami (null)
Gdy komponent wywoływany jest przez interfejs
proceduralny opracuj testy powodujące awarię
Najczęstsze nieporozumienia
Dla interfejsów z przekazywaniem komunikatów wykonaj
testy obciążeniowe.
Jeżeli komponenty komunikują się za pomocą pamięci
współdzielonej opracuj testy różniące się porządkiem
inicjalizacji komponentów
Podsumowanie
Testowanie może wykazać istnienie defektów w
oprogramowania.
Testowanie nie jest w stanie zapewnić, że błędów nie
ma.
Za testowanie komponentów odpowiedzialni są
programiści
Za testowanie systemu odpowiedzialne są odrębne
zespoły testujące.
Testy integracyjne to testy inkrementacji
Testy wydania to testy systemu przygotowanego do
wdrożenia
25
Inżynieria Oprogramowania
Weryfikacja i
zatwierdzanie
Czyli szerszy kontekst
Weryfikacja a zatwierdzanie
Weryfikacja
Czy odpowiednio budujemy system
Oprogramowanie powinno być zgodne ze
specyfikacją
Zatwierdzanie (walidacja)
Czy budujemy odpowiedni produkt
Oprogramowanie powinno być tym czego użytkownicy
rzeczywiście potrzebują
26
Inżynieria Oprogramowania
Statyczna i dynamiczna weryfikacja
Inspekcje oprogramowania
Analiza statycznej reprezentacji systemu
Testowanie
Dynamiczna analiza poprzez obserwacje zachowania
systemu
Statyczna i dynamiczna weryfikacja
Inspekcje
oprogramowania
Specyfikacja
Specyfikacja Model systemu Projekt
Program
systemu
wymagań systemu
Testowanie
Prototyp
27
Inżynieria Oprogramowania
Inspekcje oprogramowania
Analiza z
ródłowej reprezentacji systemu mająca
na celu wykrycie defektów i anomalii
(wymagania, kod z
ródłowy, projekt, dane
konfiguracyjne)
Nie wymagają działającego systemu
Praktyka wykazała, że jest to efektywna technika
wykrywanie błędów.
Inspekcje cd.
W czasie pojedynczej inspekcji może zostać
wykrytych wiele błędów systemu.
w testowaniu jeden defekt może maskować inny więc
wymagane jest wielokrotne uruchamianie
Wiele usterek jest powtarzalnych co powoduje,
że doświadczeni inspektorzy są w stanie łatwo je
zlokalizować
28
Inżynieria Oprogramowania
Inspekcje cd.
Inspekcje nie są w stanie:
Zweryfikować czy system odpowiada użytkownikom
Sprawdzić realizacji wymagań niefunkcjonalnych
Powinny więc być uzupełnieniem procesu
testowania.
Pewność systemów
Bo wszystkiego nie da się
przewidzieć
29
Inżynieria Oprogramowania
Pewność systemu
Nieformalna właściwość odpowiedzialna za poziom
zaufania do systemu
Wymiary
Dostępność (D)
Prawdopodobieństwo, że system w ustalonej chwili będzie działał i
realizował użyteczne usługi
Niezawodność (N)
Prawdopodobieństwo, że system w ustalonym okresie czasu będzie
poprawnie realizował zlecone usługi
Bezpieczeństwo (B)
Możliwość wyrządzenia szkód (ludziom, środowisku, etc.)
Zabezpieczenie (Z)
Odporność systemu na przypadkowe lub celowe wtargnięcie intruza
Koszty pewności
Koszty rosną wykładniczo wraz ze zwiększaniem
pewności (D,N,B,Z)
W większości przypadków wysoki poziom pewności
można osiągnąć jedynie kosztem efektywności
Ale pewność jest zwykle ważniejsza od efektywności
Niepewne systemy zwykle nie są używane
Koszt awarii może być olbrzymi
Trudno jest odzyskać pewność
Brak efektywności można zrekompensować
Niepewny system może spowodować utratę informacji
30
Inżynieria Oprogramowania
Niezawodność
Prawdopodobieństwo bezawaryjnego działania
w ciągu ustalonego czasu w zadanym
środowisku w określonym celu
Pojęcia
Awaria systemu  zdarzenie zaprzestania realizacji usługi
Błąd systemu  zachowanie niezgodne ze specyfikacją
Usterka systemu  niepoprawny stan systemu
Błąd człowieka  działanie człowieka powodujące usterkę
Własności niezawodności
Postrzeganie niezawodności
Niezawodność oprogramowania zależy od
prawdopodobieństwa, że w konkretnym uruchomieniu
dane wejściowe będą należeć do zbioru danych
wejściowych powodujących błędne wyjścia
Niezawodność związana jest z
prawdopodobieństwem wystąpienia błędu
Program może zawierać błędy i być uznawany za
niezawodny
Użytkownik może nauczyć się omijać usterki
31
Inżynieria Oprogramowania
Bezpieczeństwo
Zdolność systemu do (nie)normalnego działania
bez wywoływania zagrożeń
Niezawodny system nie musi być bezpieczny
Niekompletna specyfikacja
Niewłaściwe działanie sprzętu
Dane, które nie są błędne, ale w nieprzewidzianych
konfiguracjach mogą powodować niewłaściwe
zachowanie
Bezpieczeństwo - pojęcia
Wypadek
niezaplanowane zdarzenie powodujące szkody
Zagrożenie
sytuacja mogąca powodować, lub przyczyniać się do wypadku
Szkoda
Miara strat powstałych w wyniku wypadku
Waga zagrożenia
Oszacowanie największych szkód, które mogą być wynikiem
konkretnego zagrożenia
Prawdopodobieństwo zagrożenia
Prawdopodobieństwo wystąpienia zdarzenia powodującego zagrożenie
Ryzyko
Miara prawdopodobieństwa, że system spowoduje awarię
32
Inżynieria Oprogramowania
Zabezpieczenie
Stopień odporności systemu na ataki z zewnątrz
Brak rozsądnego poziomu zabezpieczeń może
zniweczyć pozostałe atrybuty pewności
Błędy przy budowie systemu mogą powodować
luki w zabezpieczeniach
Szkody ataku z zewnątrz
Zaprzestanie obsługi (Denial of Service)
Zmuszenie systemu do przyjęcia stanu uniemożliwiającego
normalną realizację usług (wpływ na dostepność)
Uszkodzenie programów lub danych
Podmiana komponentów systemu powodująca zmianę jego
zachowania (niezawodność i bezpieczeństwo)
Ujawnienie poufnej informacji
Może wpłynąć na bezpieczeństwo systemu, umożliwić dalsze
ataki, które ograniczą dostepność i niezawodność
33
Inżynieria Oprogramowania
Zabezpieczenie - pojęcia
Odsłonięcie
możliwość straty lub szkody w systemie
Słabość
Słaby punkt systemu
Atak
Wykorzystanie słabości
Groz
ba
Sytuacja, która może doprowadzić do szkód
Nadzór
Miara ochrony, która zmniejsza słabości systemu
Survival czyli zdolność przetrwania
Zdolność systemu do ciągłej realizacji usług
Nawet w trakcie ataku czy odłączenia części systemu
Mechanizmy poprawy zdolności przetrwania
Odpieranie ataków
Rozpoznawanie ataków
Odtwarzanie po szkodach
34
Inżynieria Oprogramowania
Podsumowanie
Pewność jest z reguły pojęciem nieformalnym
opartym albo o prawdopodobieństwo lub
subiektywne opinie
Nie da się zrealizować systemu niezawodnego
w 100% (koszt byłby nieskończony)
W dobie aplikacji webowych wymiar
zabezpieczeń staje się coraz istotniejszy
35