Inżynieria oprogramowania
Testowanie oprogramowania
1
Testowanie - definicje
testowanie -> proces badania eksperymentalnego
aplikacji, który polega na próbnym wykonaniu
aplikacji w znanych warunkach, zarejestrowaniu
wyników i ocenieniu na ich podstawie określonych
właściwości aplikacji lub jej części (modułu)
zakres oceny podczas testowania:
Ä„ð poprawność wyników dziaÅ‚ania aplikacji
Ä„ð wydajność/szybkość dziaÅ‚ania
Ä„ð niezawodność, jakość oprogramowania
Ä„ð zgodność z cechami okreÅ›lonymi w specyfikacji wymagaÅ„
2/44
Testowanie - cechy
nie jest zwykle możliwe pełne przetestowanie aplikacji
(wszystkie możliwe zestawy danych wejściowych we
wszystkich konfiguracjach) ze względu na zbyt dużą liczbę
przypadków testowych
na etapie projektowania testów określa się zestaw
przypadków testowych
testowanie wykonywane jest na wielu etapach procesu
wytwórczego
stwierdzenie braku błędów podczas testowania nie uprawnia
do stwierdzenia o tym że w aplikacji błędy nie wystąpią
w niektórych przypadkach (systemy o wysokim stopniu
bezpieczeństwa) koszty testowania mogą być nawet
kilkukrotnie wyższe niż koszty pozostałych prac wytwórczych
3/44
Zasady testowania
testy powinny być projektowane na podstawie
wymagań klienta
testowanie powinno być zaplanowane odpowiednio
wcześnie  po utworzeniu specyfikacji wymagań, po
wykonaniu projektu architektury
wykonywanie testowania -> od szczegółu do ogółu
testowanie całkowite jest niewykonalne
testowanie powinno być prowadzone przez
niezależne osoby (większe prawdopodobieństwo
wykrycia błędów)
4/44
Testowalność
testowalność -> łatwość testowania, może być jednym z celów
podczas projektowania aplikacji
cechy zwiększające testowalność
Ä„ð operatywność -> lepszy program to mniej bÅ‚Ä™dów i Å‚atwiejsze testowanie
Ä„ð obserwowalność -> testowanie uÅ‚atwia obserwacja zachowania i
wyników
Ä„ð sterowność -> lepsza kontrola aplikacji uÅ‚atwia testowanie
Ä„ð podzielność -> testowanie modułów, szybsze wyszukiwanie bÅ‚Ä™dów
Ä„ð prostota -> mniejsze skomplikowanie kodu, struktury i funkcji oznacza
mniej testów
Ä„ð stabilność -> mniej zmian to mniej przeszkód w testowaniu
Ä„ð zrozumiaÅ‚ość-> wiÄ™cej informacji to skuteczniejsze testy
5/44
Projektowanie testów
metoda białej skrzynki -> analiza struktury aplikacji,
zgodność modułów ze specyfikacją, współpraca
modułów, działanie procedur, badanie ścieżek
przepływu sterowania
metoda czarnej skrzynki -> analiza poprawności
funkcjonalności aplikacji, badanie interfejsów
aplikacji, struktura wewnętrzna nie jest brana pod
uwagÄ™
6/44
Metoda białej skrzynki
testowanie obejmuje
Ä„ð niezależne Å›cieżki w module
Ä„ð możliwe kombinacje decyzji logicznych
Ä„ð wielokrotne wykonywanie pÄ™tli z uwzglÄ™dnieniem wartoÅ›ci brzegowych
Ä„ð sprawdzenie poprawnoÅ›ci wewnÄ™trznych struktur danych
dobór wartości danych wejściowych powinien zapewniać pełne
pokrycie kodu wg określonego kryterium, np. metryk pokrycia
kodu
wadą jest zależność od wewnętrznej struktury aplikacji  zmiana
struktury może wymagać zmiany przypadków testowych
metoda stosowana na wszystkich poziomach testowania z
wyjątkiem testów akceptacyjnych, ale głównie w testach
jednostkowych
7/44
Testowanie ścieżek podstawowych
projektant testów oblicza miarę złożoności logicznej projektu
procedury i na jej podstawie definiuje bazowy zestaw ścieżek
wykonania
sprawdzenie bazowego zestawu ścieżek gwarantuje w
procedurze testowej co najmniej jednokrotne wykonanie każdej
instrukcji programu i co najmniej dwukrotne sprawdzenie
każdego warunku (dwie różne wartości logiczne)
do bazowego zestawu ścieżek zalicza się tzw. ścieżki niezależne
ścieżka jest niezależna jeżeli zawiera nowy blok instrukcji lub
sprawdzenie nowego warunku
opis przepływu sterowania w aplikacji można przedstawić za
pomocą tzw. grafów przepływu
liczba testów może być wyznaczona na podstawie analizy
złożoności cyklomatycznej programu
8/44
Obliczanie złożoności cyklomatycznej
analiza złożoności cyklomatycznej wykonywana jest na
podstawie grafu przepływu
stanowi górne ograniczenie ścieżek niezależnych w bazie
czyli jednocześnie określa liczbę testów gwarantujących min.
jednokrotne sprawdzenie wszystkich instrukcji procedury
1. sposób: V(G)=E-N+2
gdzie: E-liczba krawędzi, N-liczba wierzchołków
2. sposób: V(G)=P+1
gdzie: P  liczba wierzchołków predykatów (zawierających
warunek, wychodzą z nich min. 2 krawędzie)
9/44
Graf i złożoność cyklomatyczna -
przykład
2 instrukcje nie
będące warunkiem
3,4
1 2 9 10
6
5 8
7
właściwości grafu: liczba węzłów (N) = 9, liczba krawędzi (E) = 11, liczba
wierzchołków predykatów (P) = 3
złożoność: 1. sposób: V(G)=E-N+2=11-9+2=4 , 2. sposób: V(G)=P+1=3+1=4
ścieżki niezależne: 1) 1,2,3,4,9,1 2) 1,2,3,4,9,10
3) 1,2,5,6,8,9,& 4) 1,2,5,7,8,9,&
ścieżki 3 i 4 można zakończyć w dowolny sposób
10/44
Macierz grafu i złożoność
cyklomatyczna - przykład
1 2 3 4 5 6
3
1 1 1-1=0
5
1 2 6
2 1 1
2-1=1
4
3 1
1-1=0
4 1
1-1=0
1 istnieje krawędz
Å‚Ä…czÄ…ca
5 1 1 2-1=1
0 nie istnieje krawędz
Å‚Ä…czÄ…ca
6
0
obliczenie złożoności cyklomatycznej: V=(0+1+0+0+1+0)+1=3
11/44
Testowanie ścieżek podstawowych -
podsumowanie
wartości testowe mogą być wybierane przez testera
na podstawie np. analizy warunków rozgałęzień
albo mogą być dobierane losowo
wyniki są porównywane wartościami obliczonymi na
podstawie specyfikacji
poprawność (zgodność z oczekiwaniami) wszystkich
wyników testowania oznacza brak błędów w
aplikacji
poważnym ograniczeniem metody jest niekiedy
ogromna liczba przypadków testowych
12/44
Testowanie struktury sterowania
testowanie warunków -> sprawdzanie warunków
logicznych w module/procedurze
testowanie przepływu danych -> wykonywane na
podstawie miejsc definicji i miejsc użycia zmiennych
testowanie pętli -> sprawdzanie poprawności
wyłącznie pętli
13/44
Testowanie warunków
wyrażenie relacyjne: E1E2
operator relacji: <, d", e", >, `"
warunki złożone budowane są z użyciem operatorów logicznych:
OR, AND, NOT
błędy w wyrażeniach logicznych:
Ä„ð bÅ‚Ä™dy operatorów ( niewÅ‚aÅ›ciwy, pominiÄ™ty, niepotrzebny)
Ä„ð bÅ‚Ä™dy zmiennych
Ä„ð bÅ‚Ä™dy nawiasów
Ä„ð bÅ‚Ä™dy operatorów relacji
Ä„ð bÅ‚Ä™dy wyrażeÅ„ arytmetycznych
pozwala wykryć również inne błędy w programie
14/44
Strategie testowania warunków
testowanie gałęzi -> w wyrażeniu złożonym
sprawdzenie wszystkich kombinacji wartości
logicznych i co najmniej jednokrotne sprawdzenie
wszystkich wyrażeń prostych
testowanie dziedziny -> w wyrażeniu typu
E1E2 wykonanie testów dla
wartości E1 <, = oraz > od E2
testowanie gałęzi i relacji (strategia BRO) ->
połączenie obu powyższych technik
15/44
Testowanie przepływu danych
łańcuch definicja-użycie (DU) zmiennej X: [X,S,S ]
gdzie: S oraz S sÄ… numerami instrukcji definicji i
użycia zmiennej X
testowanie przepływu danych polega na
sprawdzeniu wszystkich par DU
test nie gwarantuje sprawdzenia wszystkich ścieżek
w programie ale niesprawdzonych jest mało
przydatne zwłaszcza gdy występują zagnieżdżone
instrukcje warunkowe i pętle
16/44
Testowanie pętli
pętle proste (o max. liczbie kroków =n) -> pominięcie pętli,
wykonanie jednokrotne, dwukrotne, m-krotne (mkrotne
pętle zagnieżdżone -> wykonanie j.w. niemożliwe ze względu na
zbyt dużą liczbę przypadków, testowanie rozpoczyna się od
najbardziej wewnętrznej pętli testowanej jak prosta, pozostałe
wykonywane z minimalnymi wartościami liczników, testowanie
co raz bardziej zewnętrznych pętli z minimalnymi wartościami
liczników pętli oraz najbardziej typowymi wartościami pętli
wewnętrznych, można wprowadzić wartości zmiennych spoza
zakresów
pętle połączone -> mogą być testowane jak proste ale gdy ich
liczniki nie są zależne od siebie (np. pierwszy służy do inicjowania
drugiego), w przeciwnym przypadku postępowanie jak w pętlach
zagnieżdżonych
pętle niestrukturalne -> należy unikać takich pętli w programach
17/44
Testowanie mutacyjne
celem jest identyfikacja tzw. skutecznych przypadków
testowych oraz ograniczenie rozmiaru danych wynikowych
testów poprzez odrzucenie przypadków testowych
nieskutecznych
wykonanie -> ten sam test realizowany dla dwóch wersji
programu: oryginalnej i celowo zmienionej poprzez
wprowadzenie pewnej liczby defektów
przypadek testowy który nie wykryje błędu (nie zwróci
innych wyników dla obu wersji) uznawany jest za
nieskuteczny
przygotowanie testów mutacyjnych nie wymaga analizy
statycznej programu, zaletÄ… jest Å‚atwa automatyzacja
18/44
Metoda czarnej skrzynki
oznacza testowanie zachowania aplikacji, bazuje na
wymaganiach funkcjonalnych aplikacji, sprawdza zgodność
aplikacji z wymaganiami
jest uzupełnieniem dla testów typu biała skrzynka
błędy wyszukiwane metodą czarnej skrzynki
Ä„ð pominiÄ™ta lub bÅ‚Ä™dnie zaimplementowana funkcja
Ä„ð bÅ‚Ä™dny interfejs
Ä„ð bÅ‚Ä™dy w strukturach danych lub metodach dostÄ™pu do danych
zewnętrznych
Ä„ð niewÅ‚aÅ›ciwe zachowanie lub niska efektywność
Ä„ð niewÅ‚aÅ›ciwe uruchamianie lub wyÅ‚Ä…czanie aplikacji
stosowana głównie na dalszych etapach testowania
19/44
Testowanie metodÄ… czarnej skrzynki
rodzaje testów
Ä„ð analiza klas równoważnoÅ›ci
Ä„ð analiza wartoÅ›ci brzegowych
Ä„ð testowanie porównawcze
Ä„ð testowanie przypadków użycia
Ä„ð testowanie losowe
projektowanie testów polega na określeniu zbioru
poprawnych i niepoprawnych wartości danych wejściowych
zapewniających pokrycie całej przestrzeni zachowań
programu
ocena kompletności testu -> metryki pokrycia wymagań
umożliwia wykrycie odstępstw i braków implementacji ale
nie gwarantuje sprawdzenia wszystkich wewnętrznych
elementów programu
20/44
Analiza klas równoważności
polega na podziale możliwych wartości danych wejściowych na klasy (zbiory)
przetwarzane w podobny sposób
kolejnym krokiem (po podziale na klasy równoważności) jest wybór pewnej
liczby danych testowych z każdej klasy
należy uwzględnić klasy odpowiadające zarówno poprawnym jaki i błędnym
danym wejściowym
dane wejściowe mogą być konkretnymi wartościami liczbowymi,
przedziałami, zbiorami lub warunkami logicznymi
zasady definicji klas równoważności
Ä„ð jeżeli warunek wejÅ›ciowy jest opisany przedziaÅ‚em lub konkretnÄ… liczbÄ…,
należy rozważyć 1 poprawną i 2 niepoprawne klasy równoważności
Ä„ð jeżeli warunek wejÅ›ciowy jest opisany zbiorem lub warunkiem
logicznym, należy rozważyć 1 poprawną i 1 niepoprawną klasę
równoważności
21/44
Analiza wartości brzegowych
stosowanie tego testu jest uzasadnione częstymi błędami
działania aplikacji w przypadkach używania skrajnych wartości
danych wejściowych
metoda ta uzupełnia metodę analizy równoważności klas ale
zamiast dowolnych wartości z danej klasy wybierane są wartości
brzegowe
zasady projektowania testów:
Ä„ð przedziaÅ‚ (a,b)  wartoÅ›ci a, b oraz nieco wiÄ™ksze i nieco mniejsze
Ä„ð zbiór liczb - najwiÄ™ksza, najmniejsza oraz bliskie im wartoÅ›ci
Ä„ð podobne zasady dotyczÄ… danych wyjÅ›ciowych
Ä„ð należy sprawdzić również struktury o ograniczonych rozmiarach -> co
będzie w przypadku przekroczenia tego rozmiaru
22/44
Testowanie porównawcze
stosowane w przypadku systemów o wymaganej dużej
niezawodności, posiadających w związku z tym zdublowane
moduły tworzone często przez inne zespoły
testowanie polega wówczas na sprawdzeniu czy dla tych
samych danych wejściowych oba zwracają takie same dane
wyjściowe
testowanie porównawcze nie musi spowodować wykrycia
wszystkich błędów:
Ä„ð jeżeli specyfikacja zawieraÅ‚a bÅ‚Ä…d to obie niezależne wersje bÄ™dÄ… go
zawierały
Ä„ð generowanie przez niezależne wersje bÅ‚Ä™dnych ale takich samych
danych utrudni wykrycie błędu
23/44
Testowanie sposobów użycia
polega na analizie wszystkich sposobów użycia programu
przez użytkownika
szczegóły metody są uzależnione od specyfikacji programu
jeżeli specyfikacja ma postać hierarchii funkcji wykonywana
jest sekwencja funkcji
jeżeli specyfikacja ma postać modelu przypadków użycia,
sprawdzany jest każdy przypadek użycia
przypadki testowe powinny sprawdzić wykonanie wszystkich
funkcji lub wszystkich scenariuszy przypadków użycia
metoda ta jest wykorzystywana w testach akceptacyjnych
wiarygodność testu rośnie ze wzrostem liczby przypadków
testowych
24/44
Testowanie losowe
do weryfikacji działania programu używane są liczby losowe
zakłada się że liczby losowe rozłożą się w całym możliwym
przedziale wartości danych wejściowych a przy dostatecznie
dużej liczbie prób pokryją cały zakres przetwarzania aplikacji
liczba przypadków testowych może być wyznaczona za
pomocÄ… tzw. metryk pokrycia lub arbitralnie
do testowania używany jest filtr liczb losowych,
pozostawiający jedynie przypadki z zakresu wartości
wejściowych oraz rejestrator wielkości wyjściowych
zalety: uproszczenie projektowania testu oraz łatwość
automatyzacji
wady: brak gwarancji wystarczającego pokrycia testów
25/44
Metryki testowania
metryki testowania -> ilościowe miary określające różne cechy
zaprojektowanych lub wykonanych testów
wykorzystywane do określania
Ä„ð jakoÅ›ci testów (wiarygodność testów uzależniona m. in. od iloÅ›ci
przypadków testowych i pokrycia przestrzeni danych wejściowych)
Ä„ð postÄ™pu testów
rodzaje
Ä„ð metryki pokrycia kodu: pokrycie bloków instrukcji, pokrycie decyzji,
pokrycie ścieżek
Ä„ð metryki pokrycia wymagaÅ„: bÅ‚Ä™dów, testowania przypadków użycia
Ä„ð inne metryki: liczba wykrytych defektów, liczba defektów komponentu,
częstość defektów, procent defektów poprawionych, szacowanie liczby
wszystkich defektów
26/44
Metryki pokrycia kodu
testowanie metodą białej skrzynki
wadÄ… jest brak jednolitej definicji  pokrycia
zaletą łatwa interpretacja wyników
pokrycie bloków instrukcji -> stosunek liczby bloków
przetestowanych do liczby wszystkich bloków (nie zawierają
instrukcji rozgałęzienia typu: if, switch, for, itp.), wada: słabe
odzwierciedlenie jakość testów, nie wychwytywane wszystkie
błędy (np.. dzielenia przez 0)
pokrycie decyzji -> decyzja to wartość warunku w instrukcji
powodującej rozgałęzienie, wartość metryki obliczana jako
stosunek liczby przetestowanych wyjść z instr. rozgał. do liczby
wszystkich wyjść z istniejących rozgałęzień
pokrycie ścieżek -> ścieżka to sekwencja instrukcji prowadząca
od początku do końca programu, wartość metryki obliczana jako
stosunek liczby sprawdzonych ścieżek do liczby wszystkich
27/44
Metryki pokrycia wymagań
prowadzona metodÄ… czarnej skrzynki, dotyczy
wewnętrznej struktury programu, oparta na analizie
wymagań
miarą jakości testów jest stopień pokrycia zbioru
wymagań przypadkami testowymi
zaleta: ocena jakości testów odpowiada ocenie
spełnienia wymagań
wada: brak jednolitej definicji pokrycia wymagań i
metryk
28/44
Metryki pokrycia wymagań - rodzaje
pokrycie wymagań -> stosunek liczby przetestowanych
wymagań do liczby wszystkich zapisanych w specyfikacji
pokrycie błędów -> wartością metryki jest stosunek liczby
błędów zademonstrowanych podczas testów do liczby
wszystkich błędów obsługiwanych wg dokumentacji
programu
testowanie przypadków użycia -> pokrycie przypadków
użycia przypadkami testowymi, jeżeli liczba przypadków
testowych jest mniejsza od liczby scenariuszy przypadku
użycia, oznacza to pominięcie pewnych scenariuszy
29/44
Inne metryki
liczba wykrytych defektów -> pozwala ocenić początkową jakość kodu, przyrost
jakość kodu w wyniku usuwania błędów, efektywność metod testowania
początek testów,
stabilizacja, może
mało błędów
stanowić kryterium
zakończenia testów
czas testowania
częstość defektów -> stosunek liczby defektów do liczby linii kodu, problemem jest
różna interpretacja linii kodu (z
ródłowy czy wynikowy, komentarze, nagłówki, 1
instrukcja w kilku wierszach)
procent defektów poprawionych -> stosunek defektów poprawionych do liczby
defektów wykrytych testami, stosowany do oceny prac nad usuwaniem defektów
szacowanie liczby wszystkich defektów -> wykorzystuje się fakt wprowadzenia
sztucznie pewnej liczby błędów i założeniu że procent ich wykrycia jest podobny jak
procent wykrycia istniejących błędów
30/44
liczba defektów
Elementy strategii testowania
inżynieria systemów
testy systemu
analiza wymagań
testy zgodności
projektowanie
testy scalenia
kodowanie testy modułów
testowanie modułów -> sprawdza poprawność kodu na najniższym
poziomie (poszczególnych modułów), głównie metodą białej skrzynki
testy scalenia -> sprawdzanie projektu i konstrukcji architektury systemu,
stosowane metody czarnej skrzynki i uzupełniająco białej skrzynki
(przepływy sterowania)
testy zgodności -> spełnianie założeń i wymagań dotyczących
funkcjonalności, efektywności, zachowania, ograniczeń itp. ustalonych w
ramach analizy wymagań, metody czarnej skrzynki
testy systemu -> sprawdzanie systemu jako całości, wspópraca z innymi
32/44
kierunek testowania
kierunek wytwarzania
Zakończenie testowania
testowanie nie kończy się nigdy, po przekazaniu
programu użytkownikowi każde użycie jest rodzajem
testu programu
testowanie kończy się gdy brakuje na nie czasu albo
pieniędzy
zastosowanie metod prawdopodobieństwa i teorii
niezawodności do określenia czasu testowania celem
uzyskania akceptowalnie małej ilości awarii, np. wg
modelu Poissona
33/44
Rozkład Poissona
przewidywana
dane zebrane
częstość awarii l(t)
podczas testowania
l0
f(t) = (1/p)ln(l0pt+1)
l(t) = l0 / (l0pt+1)
czas wykonania, t
f(t)  całkowita oczekiwana liczba awarii podczas testowania programu przez
określony czas t
l0  początkowa częstość awarii
p - współczynnik redukcji wykładniczej liczby awarii zmieniający się w miarę
wykrywania i usuwania błędów
l(t)  chwilowa częstość awarii ( pochodna f(t) )
jeżeli dane rzeczywiste zgadzają się z danymi na podstawie modelu to można określić
całkowity czas testowania potrzebny do osiągnięcia akceptowalnie małej liczby awarii
34/44
godzinÄ™
liczba awarii na
Testowanie modułów  rodzaje testów
interfejs (wymiana informacji z otoczeniem), kluczowy dla
wiarygodności innych testów
lokalne struktury danych
warunki brzegowe
ścieżki niezależne w strukturze sterowania -> najistotniejsze,
zastosowanie: metoda ścieżek podstawowych oraz testowanie
pętli, wykrywane błędy: obliczeniowe, logiczne, przepływu
sterowania
obsługa błędów -> niezrozumiałość komunikatów, komunikat
stwierdzający inny błąd, przerwanie działania programu przez
obsługą błędu, niepoprawne rozpoznawanie wyjątków, zbyt
mało informacji o błędzie
35/44
Testowanie modułów  procedury
testowanie modułów może rozpoczynać się równolegle z
pisaniem kodu
moduł nie jest samodzielną jednostką, dlatego do testowania
może być potrzebny dodatkowy moduł sterujący (pilot 
przekazuje dane do testowanego modułu i wyświetla wyniki)
oraz namiastki niektórych innych powiązanych modułów
(wywoływane z testowanego modułu)
niekiedy testy modułów muszą zostać przełożone do fazy
scalania systemu, powodem brak możliwości testowania
używając  namiastek powiązanych modułów
moduły wykonujące jedno określone zadanie są łatwiejsze do
testowania
automatyczne narzędzia -> wbudowane w środowiska
programistyczne
36/44
Testowanie scalenia
umożliwia zbudowanie z testowanych oddzielenie
modułów aplikacji działającej zgodnie z projektem
architektury
umożliwia wykrycie błędów niepożądanych zależności
między modułami
może być prowadzone metodami:
Ä„ð  wielkiego skoku  jednoczesne poÅ‚Ä…czenie wszystkich
modułów i testowanie całości
Ä„ð scalanie przyrostowe  testowanie stopniowe z
dodawaniem kolejnych modułów, łatwiejsza lokalizacja i
usuwanie błędów
37/44
Scalanie zstępujące
moduły scalane są w kierunku od góry do dołu hierarchii
sterowania
może być prowadzone metodami
Ä„ð  w gÅ‚Ä…b -> integracja modułów wzdÅ‚uż głównych Å›cieżek hierarchii
modułów
Ä„ð  wszerz -> integracja modułów na tych samych poziomach hierarchii
w kolejnych krokach namiastki są zastępowane właściwymi
modułami
po dołączeniu każdego modułu wykonywane są testy
dodatkowo można wykonać testowanie regresyjne aby
sprawdzić czy dodanie nowego modułu nie spowodowało
błędów w innych modułach
kłopotem mogą być przypadki gdy działanie modułów
niskopoziomowych jest niezbędne do testowania działania
modułów wyższych poziomów
38/44
Scalanie wstępujące
rozpoczyna się od modułów położonych najniżej w
strukturze programu
nie ma potrzeby używania namiastek ponieważ istnieją już
moduły podrzędne
czynności:
Ä„ð Å‚Ä…czenie modułów niskopoziomowych w klastry wykonujÄ…ce
pojedyncze podfunkcje systemu
Ä„ð tworzenie pilota dostarczajÄ…cego dane i przekazujÄ…cego dany
wyjściowe
Ä„ð testowanie klastra modułów
Ä„ð usuniÄ™cie pilota i scalenie klastra z moduÅ‚ami nadrzÄ™dnymi
wraz z postępem scalania potrzeba coraz mniej pilotów,
scalanie upraszcza siÄ™
39/44
Testy zgodności (zatwierdzanie)
polega na sprawdzaniu zgodności programu z założeniami
określonymi w specyfikacji wymagań używając zdefiniowanych
kryteriów zatwierdzania
stosowana metoda czarnej skrzynki
sprawdzaniu podlegajÄ… wymagania funkcjonalne, zachowanie,
efektywność, dokumentacja i inne (np. przenośność, zgodność z
normami, łatwość pielęgnacji, odporność na usterki) oraz
przeglÄ…d konfiguracji
testowanie może być wykonywane przez użytkowników
aplikacji:
Ä„ð testy  alfa  wykonywane pod nadzorem i obserwacjÄ… twórców
Ä„ð testy  beta  sprawdzenie programu przez wybranych użytkowników
40/44
Testowanie systemów
polega na testowaniu systemu jako całości oraz we współpracy z
innymi systemami
rodzaje testów systemów:
Ä„ð testy wznowieÅ„ -> sprawdzanie zdolnoÅ›ci do dziaÅ‚ania systemów po
wywołaniu awarii (czasu do wznowienia, poprawność reinicjacji,
punktów kontrolnych, odtwarzania danych)
Ä„ð testy bezpieczeÅ„stwa -> mechanizmy obrony przed niepożądanym
dostępem/atakiem
Ä„ð testy obciążeniowe -> poddanie próbie czÄ™stego wykonania dużej liczby
operacji z wykorzystaniem dużych zasobów
Ä„ð testowanie wrażliwoÅ›ci -> na dane rzadko spotykane, czy spowodujÄ…
niestabilność lub błędne działanie
Ä„ð testy efektywnoÅ›ci -> szybkość dziaÅ‚ania programu (ważne szczególnie w
systemach czasu rzeczywistego)
41/44
Przyczyny trudności w szukaniu
błędów w programach
przyczyna leży daleko od skutku ,zwłaszcza jeżeli występują
sprzężenia między modułami
tymczasowe znikanie objawów błędów po poprawieniu
innego błędu
błędy działania mogą być spowodowane błędami zaokrągleń
przyczyną może być niewłaściwe użytkowanie
trudna do odzyskania kombinacja danych wejściowych
powodująca błędna działanie
sporadyczne występowanie błędów
przyczyny mogą być powodowane kilkoma procesami
42/44
Metody usuwania błędów
metoda brutalna -> najczęściej stosowana, najmniej
skuteczna, stosowana gdy inne zawiodÄ…, wykonywane zrzuty
pamięci, analizuje ślady wykonywania programu
metoda powrotów -> skuteczna w małych programach,
polega na przeglądaniu kodu od miejsca wystąpienia błędu
do miejsca przyczyny tego błędu
metoda eliminacji przyczyn -> analiza danych o wystÄ…pieniu
błędów, eliminacja kolejnych za pomocą testów
analiza błędów
Ä„ð czy taki sam bÅ‚Ä…d wystÄ™puje w innych fragmentach kodu
Ä„ð czy po wprowadzeniu poprawek nie powstanÄ… inne nowe bÅ‚Ä™dy
Ä„ð co można zrobić aby uniknąć powstania analizowanego bÅ‚Ä™du
43/44
Dziękuję za uwagę
z
ródła:
 Praktyczne podejście do inżynierii oprogramowania , R.S. Pressman
 Inżynieria oprogramowania , Krzysztof Sacha, Wydawnictwo Naukowe PWN 2010
44