Budowa i integracja SI

Wprowadzenie do testowania
oprogramowania

Literatura
• W. Dąbrowski, K. Subieta: Podstawy inżynierii oprogramowania, Rozdział 10
Weryfikacja i atestowanie oprogramowania. Wyd. PJWSTK.
• J. Kwiatkowski, H. Łyskawa, B. Wiszniewski: Od projektu do programu. St. Szejko
(red): Metody wytwarzania oprogramowania. MIKOM, 2002, rozdział 4.
• B. Wiszniewski: Weryfikacja, walidacja i testowanie. J. Górski (red.) Inżynieria
oprogramowania w projekcie informatycznym, MIKOM, 2000, rozdział 10.
• B. Wiszniewski, B. Bereza-Jarociński: Teoria i praktyka testowania programów.
PWN, 2006

folia: 1
 Budowa i integracja SI

Testowanie
Testowanie: analiza - statyczna lub dynamiczna - zachowania
produktu w celu pomiaru (oceny) jego jakości i wykrycia defektów

• Powyższe dotyczy każdej reprezentacji systemu, przykładowo dla obiektu

System biblioteczny
– na etapie specyfikacji wymagań:
- czy wymagania zawarte w dokumencie SWS są sformułowane zgodnie ze
standardem?
- jak ma się system zachować w sytuacjach biznesowych ?
- jaki % wymagań funkcjonalnych znalazł odzwierciedlenie na diagramie PU? czy
zawiera przypadki opisujące obsługę sytuacji wyjątkowych?
- ...
– na etapie implementacji
- czy operacja „wyszukaj według tytułu” wyszukuje właściwe pozycje?
i czy wyszukiwane są wszystkie właściwe pozycje i tylko takie?
- Ile czasu trwa wykonanie transakcji wyszukania / zwrotu?
- ...

folia: 2
 Budowa i integracja SI

Motywacje

Proces wytwarzania oprogramowania wymaga ciągłego nadzoru

w celu wykrywania anomalii i usterek, oceny powstających produktów i ich
jakości oraz stwierdzenia ich zgodności z oczekiwaniami

Koszt popełnianych pomyłek i wynikających zeń defektów oprogramowania może być

ogromny, i to nie tylko w wymiarze finansowym.
W lipcu 1988 roku krążownik USS Vincennes patrolował wody Zatoki Perskiej egzekwując embargo
nałożone przez Stany Zjednoczone na Iran. Został zaatakowany około godziny 10:00 przez łodzie
irańskie. Odpowiedział w ich kierunku ogniem. W tym czasie nad nieoczekiwanym polem bitwy
przelatywał pasażerski cywilny samolot Airbus 320 wiozący pasażerów z lotniska Bandar Abbas do Abu
Dhabi. Na skutek defektu w systemie śledzenia obiektów zainstalowanym na krążowniku USS
Vincennes samolot ten został uznany za irański samolot wojskowy F-14 i zestrzelony. Zginęli wszyscy
pasażerowie Airbusa – 290 osób. Za B. Pietrzak: Wprowadzenie do testowania, Uczelnia ONLINE

folia: 3
 Budowa i integracja SI

Motywacje (2)

Testowanie dostarcza przesłanek dla dwu ważnych aspektów

zapewniania jakości: weryfikacji i walidacji oprogramowania

VVT
 testowanie (Testing) : jak dobry jest (będzie) system?

VVT – jak się

 weryfikacja (Verification): czy robimy system dobrze? to prowadzi?

 walidacja (Validation) : czy robimy dobry system?

folia: 4
 Budowa i integracja SI

Weryfikacja
Weryfikacja polega na upewnieniu się, że produkt będący rezultatem
danego etapu rozwoju systemu jest spójny z założeniami wejściowymi
tego etapu (także z reprezentacją utworzoną na etapie poprzedzającym)
– czy to, co robimy, jest realizowane w sposób właściwy
– przydatność metod specyfikacji formalnej

• przykładowo, dla obiektu System biblioteczny

– na etapie specyfikacji wymagań:
- czy wymagania zawarte w dokumencie SWS są precyzyjne, kompletne,
spójne, niesprzeczne?
- czy model przypadków użycia jest zbudowany poprawnie?
- czy w modelu przypadków użycia nie pominięto wymagań funkcjonalnych
lub obsługi sytuacji wyjątkowych?
– na etapie kodowania
- czy kod jest poprawny?
- czy kod odpowiada projektowi?
- czy utworzone tablice bazy danych odpowiadają schematowi logicznemu?
folia: 5
 Budowa i integracja SI

Walidacja
Walidacja polega na upewnieniu się, że to co budujemy jest tym, o co
nam chodziło
- czy robimy właściwą rzecz ? bo można robić dobrze rzeczy bezsensowne...
- uwaga: to wymagania stanowią obraz potrzeb (oczekiwań) użytkownika !

• przykładowo, dla obiektu System biblioteczny

– na etapie specyfikacji wymagań:
- czy wymagania (SWS, modelu PU) odpowiadają celom biznesowym? czy są
zgodne z potrzebami użytkownika?
– na etapie projektowania logicznego
- czy zdefiniowany schemat logiczny bazy danych pozwala odpowiedzieć na
(wymagane) pytania „kto wypożyczył książkę o zadanym tytule” lub „jakie
ksiązki wypożyczył Jan Kowalski?”
– gdy dotyczy produktu końcowego:
- czy system spełnia postawione wymagania?
- czy wykonanie transakcji wyszukania/zwrotu w żadnej sytuacji nie wykracza poza
żądane ramy czasowe?
folia: 6
 Budowa i integracja SI

Motywacje (3)

Testowanie we wczesnych stadiach rozwoju oprogramowania

pozwala zmniejszyć koszty usuwania defektów; im później wykryty
zostanie błąd tym większy jest koszt usunięcia defektu

faza analiza projekt kodowanie testy testy testy po

jednostkowe integracyjne systemowe wdrożeniu

Koszt 1 5 10 15 22 50 100+
($)
Koszt 6 min 0,5h 1h 1,5h 2,2h 5h 10h+
(czas)

A. Wojciechowski, Inst. Informatyki Politechniki Poznańskiej. Za

http://students.mimuw.edu.pl/SO/Projekt04-05/temat2-g2/index.html

folia: 7
 Budowa i integracja SI

Zasadniczym celem testowania jest

wykrycie defektów
?

może pro- może pro- może pro-

wadzić do wadzić do wadzić do

pomyłka (bład) usterka (defekt, błąd awaria

człowieka bug, pluskwa)
usterka (defekt) – niepoprawny krok, proces lub definicja danych w programie
błąd – stan lub zachowanie programu (systemu) odbiegające od oczekiwań
awaria – niemożność wykonania jakiejś funkcji przez program

Testowanie nie jest w stanie wykazać poprawności programu

– może tylko wykazać obecność w nim defektów

 Testowanie może mieć również inne cele, np. zademonstrowanie wybranych cech programu
folia: 8
 Budowa i integracja SI

Co jest testowaniem ?

Minimalny zbiór warunków, pozwalających uważać eksperymenty

z programem za testowanie:
– środowisko musi umożliwiać nadzorowane wykonywanie się programu
– dane dostarczane programowi dla obliczeń powinny reprezentować
zakresy wartości istotne dla jego działania
– dla każdego zestawu danych wejściowych przed wykonaniem
eksperymentu i rejestracją wyników powinny być
określone oczekiwane wyniki
– musi zostać przeprowadzona analiza
uzyskanych wyników pod kątem ich
zgodności z oczekiwanymi

folia: 9
 Budowa i integracja SI

Model testowania programów

B. Wiszniewski, B. Bereza-Jarociński

oparty na obserwacji zachowania programu

Testowanie

Scenariusze testowe

testowania
Strategie
Instrumentacja kodu Przypadki testowe

Modele środowiska Modele programu Modele błędu

„Bugs”, czyli pluskwy

odwzorowanie działania programu

folia: 10
 Budowa i integracja SI

Krótki opis modelu

Model środowiska reprezentuje operatorów, sprzęt i oprogramowanie nieodzowne
do działania programu.
Model programu reprezentuje wszystkie istotne szczegóły działania kodu programu
(model np. przepływu sterowania, danych, czy model zdarzeniowy).
Model błędu pozwala klasyfikować działania programu, co jest niezbędne do
prawidłowego wykrywania błędów.
Instrumentacja kodu polega na takim przygotowaniu kodu, by można było
obserwować i rejestrować zdarzenia w działaniu programu.
Przypadki testowe dobieramy, by obserwować interesujące nas sytuacje.
Scenariusze testowe to serie przypadków testowych
dobrane według pewnej strategii, stanowiącej zbiór
reguł ich doboru
Testowanie – całość procesu, włącznie
z analizą uzyskiwanych obserwacji.

folia: 11
 Budowa i integracja SI

Cykl życia testu

specyfikacja obiekt testowany, komponenty, cele, zakres i właściwości
podlegające testowaniu, wymagania i funkcje, które
testu nie będą testowane,... [Std. IEEE 829]
strategia doboru scenariusza

scenariusz
testowy
strategia testowania planowanie testu

przypadek
testowy
implementacja
i instrumentacja
realizacja testu
Skrypt
testowy
wykonanie testu

log testowy

raport
ocena wyników
folia: 12
 Budowa i integracja SI

Przypadki testowe
Przypadek testowy – obserwacja działania programu, związana
z interpretacją interesującego nas zdarzenia, danymi, funkcjami

Przypadek Warunki testu, Oczekiwane Kryteria

dane wejściowe Uwagi
testowy wyniki akceptacji
i czynności
AF1 - Warunki testu: Wprowadzone Zapisane dane Sprawdzić przy
Rejestr uruchomiony system, dane zostały są identyczne dodawaniu z
abonentów Dane wejściowe: zapisane w z wprowadzo- pliku i z konsoli
- dodawanie zdefiniowane linie bazie danych; nymi;
danych telefoniczne,
parametry systemu;
Czynności:
dodanie i edycja
danych abonenta Zbiór przypadków
(trzech abonentów); testowych?
Kolejność wykonania?
folia: 13
 Budowa i integracja SI

Scenariusze testowe

Scenariusz testowania – systematyczna obserwacja oczekiwanego

działania programu; najczęściej - sekwencja przypadków testowych

Przykład
Testy końcowe (akceptacyjne) systemu billingowego centrali telefonicznej
zaplanowano w następującej kolejności:
AZ2 - Hasło dostępu (logowanie)
AF1 - Rejestr abonentów
AF2 - Rejestr linii telefonicznych
AF3 - Rejestracja parametrów taryfikacyjnych
AF5 - Naliczenie opłat
AW1 - Czas naliczenia należności dla wszystkich abonentów za dany miesiąc
AF4 - Rejestr faktur
AI1 - Łatwość obsługi
AZ1 - Tworzenie kopii i odtwarzanie
folia: 14
 Budowa i integracja SI

Strategie doboru
scenariuszy testowych
Typowe strategie:
– testy statyczne (analiza, dowodzenie poprawności)
i dynamiczne
– wybrane ścieżki przepływu sterowania
– sekwencja logiczna, np. według
- kolejnych działań (diagramów czynności, scenariuszy biznesowych)
- przypadków użycia
– rozszerzanie obszarów testowania
- zwykle przy sprawdzaniu poprawności działania
– zawężanie obszarów testowania
- przy lokalizacji usterki
– negatywny scenariusz testowy (testy błędów)
- oparty na niewłaściwych danych testowych

folia: 15
 Budowa i integracja SI

Metody testowania
 Analiza statyczna
Statyczna analiza kodu to proces, w którym w oparciu
o istniejące reguły analizujemy kod źródłowy w celu
• stwierdzenia jego właściwości
• wychwycenia potencjalnych problemów związanych
z kodem aplikacji
• dowodzenia poprawności programów, produktów
etapowych

 Testowanie dynamiczne
Analizujemy dynamikę, zachowanie działającego bądź
symulowanego systemu w celu stwierdzenia (nie)zgodności
z oczekiwaniami lub zademonstrowania działania

folia: 16
 Budowa i integracja SI

Metody analizy statycznej

 Wyszukiwanie w kodzie źródłowym konstrukcji, które można

uznać za potencjalnie niewłaściwe

 Obliczanie metryk kodu źródłowego. Dostarczają nam informacji

o jakości kodu źródłowego na podstawie danych statystycznych
 Śledzenie zgodności, wyszukiwanie braków

 Formalne metody, opierające się na matematycznej definicji

zachowania programu. Formalne metody wymagają zwykle
opisywania aplikacji i/lub jej właściwości

Nieodzowne jest wsparcie narzędziowe – narzędzia na podstawie dostarczonych

reguł analizują np. pliki źródłowe w celu wychwycenia potencjalnych problemów
związanych z kodem aplikacji lub obliczenia wartości metryk

folia: 17
 Budowa i integracja SI

Ponadto…
SolDevelo: Wykład „Praktyczne
środowiska implementacyjne”

Analiza statyczna kodu programu pozwala na:

• uniknięcie typowych usterek podczas programowania

• zwiększenie wydajności i stabilności poprzez zasady oparte
na dobrych praktykach
• dostarczenie struktury do zarządzania standardami kodu
• wymuszenie własnych zasad pisania kodu

folia: 18
 Budowa i integracja SI

Testowanie dynamiczne

 Testowanie “czarnej skrzynki” (ang. black box testing)

- funkcjonalne – oparte na specyfikacji, ukierunkowane
na zewnętrzny obraz błędnego działania

 Testowanie “białej skrzynki” (ang. white box testing)

- strukturalne – wykorzystuje wiedzę o wewnętrznej
strukturze modułu

folia: 19
 Budowa i integracja SI

Testowanie czarnej skrzynki (funkcjonalne):

Idea testowania
specyfikacja implementacja

Testowanie na podstawie
specyfikacji
 ukierunkowane na
fspec fimp
błędne wykonania operacji
błędy interfejsów
błędy w dostepie do danych
zewnętrznych
błedy wydajnościowe
błędy inicjalizacji i terminacji
we wy
x1 y1
x2 y2 fimp(x1)=y1
... ... fimp(x2)=y2
xn yn fimp(x3)=y3
...
fimp(xn)=yn

folia: 20
 Budowa i integracja SI

Testowanie czarnej skrzynki (funkcjonalne):

Dobór przypadków testowych

Intuicje przy doborze przypadków testowych [J. Górski]:

• sprawdzić czy program posiada wyspecyfikowaną właściwość
• sprawdzić, gdy dane wejściowe reprezentują sytuacje typowe
• sprawdzić, czy moduł nie jest szczególnie wrażliwy na pewne „specjalne”
dane wejściowe
• sprawdzić granice dziedzin danych wejściowych
• sprawdzić zachowanie programu dla limitów rozmiaru i częstości
danych (wartości granicznych)
• sprawdzić, jakie skutki spowodują specyficzne „specjalne” kombinacje
danych wejściowych
• sprawdzić typowe scenariusze używania rozpatrywanego obiektu (modułu)

folia: 21
 Budowa i integracja SI

Testowanie czarnej skrzynki (funkcjonalne):

Podział na klasy równoważności
Różne przypadki wykonania programu można pogrupować tak, że poprawne
działanie dla reprezentanta grupy oznacza poprawne działanie dla całej grupy

podział na klasy równoważności:

– dziedziny wejściowej Przykład:
– dziedziny wyjściowej PARAMETR 1 : REAL
PARAMETR 2 : INTEGER ,  5 ,  11

KLASY
1 : < MINREAL , 0), 0 , (0, MAXREAL>
2 : < MININT , 4> , < 5, 10 >, < 11, MAXINT>

PRZYPADKI TESTOWE :
( -3.75 , 3 ) ( 0, -378) (127800, -13759)
( -275.93 , 6) ( 0 ,7) ( 1.999 , 10)
( -0.093 , 12) ( 0 , 11) ( 476, 1111119)

folia: 22
 Budowa i integracja SI

Testowanie czarnej skrzynki (funkcjonalne):

Metody specjalnych wartości

Sprawdzenie działania programu dla wartości granicznych, wyjątkowych,

pozwalających jak najlepiej scharakteryzować badaną funkcję

• operacje arytmetyczne
- liczby pierwsze, jedynka, zero, MIN i MAX wartości operandów
• konwersje typów
- podstawienia, argumenty wywołania, wartości zwracane, konwersje
niejawne, konwersje jawne
• tablice
- obiekt pusty, prawidłowe i nieprawidłowe wartości indeksów
• listy
- lista pusta, lista jednoelementowa, lista wieloelementowa

folia: 23
 Budowa i integracja SI

Testowanie czarnej skrzynki (funkcjonalne):

Analiza wartości granicznych

Obserwacja:
– błędne zachowania programu częściej występują na granicach
dziedziny wejściowej
 Stąd wskazówki dla doboru testów:
– jeżeli dana wejściowa przebiega zakres między X i Y, to testuj dla X, dla Y
oraz dla wartości bezpośrednio sąsiadujących z X i Y
– jeżeli dziedzina wejściowa obejmuje skończony zbiór uporządkowanych wartości,
to testuj dla wartości MAX i MIN oraz w ich bezpośrednim sąsiedztwie
– powyższe zasady należy również zastosować do wartości wyjściowych, np. aby
wyprodukować wartość MAX i MIN na wyjściu
– jeżeli zadano ograniczenia pojemności modułu (ilość danych, obciążenie), to
powinny być one również przetestowane

folia: 24
 Budowa i integracja SI

Testowanie czarnej skrzynki (funkcjonalne):

Metody Monte-Carlo

– sprawdzenie działania programu w oparciu o generowanie losowych

wartości wejściowych
– sprawdzenie działania programu dla możliwie najbardziej typowych
i najczęściej spotykanych wartości wejściowych
– przydatne szczególnie do testowania programów o dużej liczbie danych
wejściowych i nietrywialnych obliczeniach

Generator liczb Filtr Kod

pseudolosowych odwzorowujący programu

Dziennik (log) testu

rejestracja i analiza wartości

folia: 25
 Budowa i integracja SI

Testowanie białej skrzynki (strukturalne)

Testowanie z wykorzystaniem wiedzy o strukturze wewnętrznej

badanego obiektu (programu)
– wykonanie wszystkich niezależnych ścieżek sterowania w programie
– wykonanie wszystkich decyzji dla warunku: True i False
– wykonanie wszystkich pętli w programie dla warunku granicznego
(0 razy, Max razy) oraz dla przypadku w założonych granicach powtórzeń
pętli (0<n<Max)
– wykonanie dostępu do wszystkich wewnętrznych struktur danych

folia: 26
 Budowa i integracja SI

Testowanie białej skrzynki (strukturalne):

Testowanie ścieżek

• Struktura przepływu sterowania w programie może być

reprezentowana w postaci grafu przepływu sterowania
• Niezależna ścieżka - różni się co najmniej jedną instrukcją lub
warunkiem od innych ścieżek
• Liczba cyklomatyczna programu – podaje liczbę niezależnych
ścieżek w grafie przepływu sterowania programu

folia: 27
 Budowa i integracja SI
1

Liczba cyklomatyczna jest równa liczbie

3
rozłącznych obszarów w grafie przepływu
sterowania 6 4

7 8 5
9
10

C= E - N + 2 Liczba cyklomatyczna jest 2 11

gdzie równa liczbie łuków minus

E – liczba łuków liczba węzłów plus 2 1

N – liczba węzłów Edge

2,3 Node

4,5
6
R2

7 R3 8

R1 Region
C= PR + 1 Liczba cyklomatyczna jest 9

PR – liczba węzłów o 1 większa od liczby 10

R4

decyzyjnych węzłów decyzyjnych

(warunków
11

INDEPENDENT PATHS
logicznych)
P 1: 1 - 11 C=4
P 2: 1-2-3-4-5-10-1-11
P 3: 1-2-3-6-8-9-10-1-11
folia: 28 P 4: 1-2-3-6-7-9-10-1-11
12
 Budowa i integracja SI

Testowanie białej skrzynki (strukturalne):

Testowanie ścieżek - budowa scenariuszy testowych

• zbuduj graf przepływu sterowania

• określ złożoność cyklomatyczną
• dobierz zestaw niezależnych ścieżek
• dobierz przypadki testowe (dane wejściowe),
które wymuszają wykonanie tych ścieżek
Uwaga: należy rozważyć wspomaganie narzędziowe

Miara: Pokrycie testami

Tc = N / C*100%

Tc – pokrycie (procent przetestowanych ścieżek)

N – liczba przetestowanych niezależnych ścieżek
C – liczba cyklomatyczna badanego programu

folia: 29
 Budowa i integracja SI

Testowanie białej skrzynki (strukturalne):

Testowanie warunków

• Warunek prosty
– BOOLEAN VAR | RELATIONAL EXPRESSION
B X>7 gdzie B: BOOLEAN, X:INTEGER
• Warunek złożony
– warunki proste połączone operatorami logicznymi AND, OR

• Cel testowania
– przetestowanie każdego warunku oraz każdej ścieżki wychodzącej
z tego warunku

– UWAGA: optymalizacja kodu powoduje, że nie zawsze wszystkie warunki proste są

obliczane podczas wyznaczania wartości warunku złożonego
Jeżeli W1=F to wartość W=F niezależnie od
W =W1 AND W2 AND ...
wartości pozostałych warunków

folia: 30
 Budowa i integracja SI

Testowanie białej skrzynki (strukturalne):

Testowanie przepływu (łańcuchów) danych
S:
• Cel XDEF(S)

– testowanie spójności pomiędzy definicją i użyciem zmiennych

• Dla każdego zdania S w programie:

 DEF(S) – zbiór zmiennych X takich, że w S znajduje się
nadanie wartości X
 USE(S’) - zbiór zmiennych X takich, że w S’ znajduje się
użycie X
 Istnieje ścieżka (łańcuch) od S do S’, który nie redefiniuje X

 Strategia testowania:
• Każdy łańcuch jest wykonany przynajmniej raz

S’:
XUSE(S’)

folia: 31
 Budowa i integracja SI

Testowanie białej skrzynki (strukturalne):

Testowanie pętli

• Badane przypadki dla pętli

o N przebiegach
– ominięcie pętli
– jeden przebieg przez pętlę
– dwa przebiegi przez pętlę
– M przebiegów, M<N
– N-1, N i N+1 przebiegów

folia: 32
 Budowa i integracja SI

Co może pomóc w lokalizacji defektu?

• Uruchamianie (ang. debugging) debugging – uruchamianie

– Budowanie i eliminacja hipotez programu, z wykrywaniem
– Strategia (np. zawężanie usterek, ich lokalizacją
obszaru testowania) i usuwaniem

• Narzędzia
– Listingi
– Wydruki kontrolne
– Zrzut pamięci, ang. core dump (analiza post-mortem)
– Log, dziennik (ang. trace file)
– Powtórzenia akcji
– Wstawki programowe - instrumentacja kodu

folia: 33
 Budowa i integracja SI

Dynamiczna instrumentacja kodu

Dynamiczna instrumentacja kodu wykorzystuje mecha-
nizmy implementowane w oparciu o system obsługi
przerwań procesora i jądro systemu operacyjnego
(przerwania programowe, rejestry sprzętowe, dodatkowe
urządzenia monitorujące dołączane do szyny adresowej)

• Zawieszanie wykonania
• Wznawianie wykonania
• Sygnały
• Rejestrowanie danych
• Ślad programu
• Rejestrowanie zdarzeń
• Wymuszanie działania programu

folia: 34
 Budowa i integracja SI

Zawieszanie i wznawianie wykonywania programu

 Zawieszanie (ang. suspending)
 Pułapka dynamiczna (breakpoint)
 pozwala zawiesić wykonywanie (i wznowić), gdy program osiągnie wskazany punkt
 trwała (permanent) lub tymczasowa (temporary)
 sprzętowa lub programowa (przerwanie)
break linenum/ function / address if condition
 Punkt monitorujący (watchpoint)
 pozwala zawiesić wykonywanie programu, gdy wartość zmiennej lub wyrażenia ulega
zmianie
watch expression
 Punkt monitorujący (catchpoint)
 pozwala zawiesić wykonywanie programu gdy nastąpi zdarzenie wyjątkowe
(niepożądane wyjście z bloku, zawieszenie procesu ojca po forku gdy proces potomny
kontynuuje, zawieszenie po załadowaniu biblioteki)
catch throw / catch fork / catch load libname
 Wznawianie (ang. resuming)
 Ciągłe (continuing) vs. krokowe (stepping)
 Wymuszanie zmiany działania programu
folia: 35
 Budowa i integracja SI

Sygnały
Sygnał to w systemie operacyjnym
przerwanie wskazujące, że w
środowisku programu wystąpiło
zdarzenie asynchroniczne
 Sygnały krytyczne (fatal)
• sygnalizacja zdarzeń wymagających natychmiastowego przerwania działania
programu i podjęcia akcji przez system operacyjny

 Sygnały użytkowe (non-erroneous)

• sygnalizacja zdarzeń mogących być obsługiwane przez program

 Obsługa sygnałów
stop / ignore / noignore
 Imitowanie sygnałów

folia: 36
 Budowa i integracja SI

Rejestrowanie danych

 Rejestrowanie bezpośrednie
• zapisywane są rejestry maszyny (komórki pamięci)

 Rejestrowanie pośrednie
• rejestrowane są zmienne programu (lub wyrażenia)
• wstawianie zmiennych śledzących przebieg

 Zrzut pamięci (core dump)

 Wartości zapisywane w dzienniku (logu)

 Wyświetlanie wznawianie działania programu

folia: 37
 Budowa i integracja SI

Rejestrowanie zdarzeń

 Rejestrowanie akcji
• wykorzystanie pułapek

 Rejestrowanie stanów
• wykorzystanie punktów monitorujących

 Gdy zbyt inwazyjne

 instrumentujemy w sposób umożliwiający zapisanie zawartości
wybranych rejestrów w dzienniku
 analizujemy off-line

folia: 38
 Budowa i integracja SI

Problem: kto ma testować?

Problem psychologiczny
• wytwarzanie - postawa twórcza
• testowanie - postawa destrukcyjna
• twórca nie jest zainteresowany wykazaniem własnych błędów
• strategie praktyczne - podejście mieszane
– wytwórca
– podmiot niezależny (np. opłacany za znajdowane defekty)

folia: 39
 Budowa i integracja SI

Problem: kiedy zakończyć testowanie?

 Możliwe kryteria:
– nigdy, co najwyżej jest dalej kontynuowane przez użytkownika -
klienta
– wtedy, gdy skończą się pieniądze lub wyczerpie czas przeznaczony
na testowanie
– wtedy, gdy potrafimy wyliczyć, że prawdopodobieństwo poprawnego
funkcjonowania jest wystarczająco wysokie, np. 0,999 na godz.
 ale jak to wyliczyć?
– gdy wykryjemy wszystkie „zasiane” defekty
 technika zasiewania defektów
– gdy zrealizujemy zbudowany wcześniej i zatwierdzony plan testów

folia: 40
 Budowa i integracja SI

Poziomy testowania
aplikacji
 testowanie akceptacyjne
Celem jest zademonstrowanie zgodnego z wymaganiami działania systemu

 testy systemowe i walidacyjne

Celem jest pokazanie, że oprogramowanie wykonuje swoje funkcje,
jest kompletne i może być wykorzystane w zakładanym środowisku

 testy integracyjne
Celami są:
- sprawdzenie przygotowania SYSTEM ACCEPTANCE
SYSTEM
komponentów do współpracy, ANALYSIS TEST
ich interfejsy SYSTEM AND
- sprawdzenie współpracy SOFTWARE VALIDATION TEST
scalonych komponentów REQUIREMENTS
Implemen-

DESIGN INTEGRATION TEST

 testy jednostkowe
Głównym celem jest
tacja

IMPLEMENTATION UNIT TEST

lokalizacja i usuniecie defektów
CODE
folia: 41
 Budowa i integracja SI

Testowanie w modelu kaskadowym

Planowanie
Analiza

Projektowanie Testowanie Testowanie Testowanie

jednostkowe integracyjneakceptacyjne
i systemowe
Implementacja

Testowanie

Wdrażanie
i pielęgnacja

Testowanie to 30-40% ogólnej pracochłonności projektu informatycznego. W przypadku syst.

krytycznych (sterowania samolotem, pracą elektrowni jądrowej) - 70-80%. R. Pressman
folia: 42
 Budowa i integracja SI

Testowanie jednostkowe
(ang. unit, module, developer tests)
 Lokalizacja i usuwanie defektów
• Techniki
– analiza kodu źródłowego Var i: int;
A: array [1..N] of 1..N;
– uruchamianie „wyizolowane” procedure p (var x: int;
– wsparcie narzędziowe begin
x := x+1;
i: = i+1;
• Wykonanie
– konstruktorzy, programiści
– testowanie koleżeńskie (80% skuteczności!)

• Niektóre problemy testowania jednostkowego

– konstruktorzy, programiści – brak pełnej motywacji,
testerzy – brak pełnej wiedzy
– częste braki w praktyce testów jednostkowych
- brak sformalizowania, niska waga w procesie wytwarzania, niedoczas i „konflikt
interesów” pomiędzy konstrukcją a testowaniem
– problemy organizacji testowania i środowiska testowego
– trudność 100% pokrycia
–folia:koszt
43 pozostawienia usterki
 Budowa i integracja SI

Testowanie integracyjne
(ang. Integration testing)

 Testy interfejsów, scalenia i współdziałania

komponentów systemu

• Strategie integracji
– Strategia skokowa (bezprzyrostowa, ang. big-bang
integration)
- jednoczesne scalanie wszystkich komponentów
- może przynieść spore korzyści, ale i znaczne jest
ryzyko niepowodzenia
– Integracja przyrostowa
- wstępująca (oddolnie, 4 -zstępująca (odgórnie, 1
ang. bottom-up) ang. top-down)
- symulacja,
3 2 użycie atrap 3 2

Strzałki określają podtrzy-

manie(udostępnianie usług) 1 4
folia: 44
 Budowa i integracja SI

Testowanie systemowe i walidacyjne

(ang. System testing)

 Działanie w zamierzonym środowisku, posiadanie przezeń wymaganych

cechy jakościowych i użytkowych; walidacja systemu, kompletność
wykonywanych funkcji

• Cel narzuca dobór scenariuszy i przypadków testowych

– testy funkcjonalne i walidacji logicznej
– testy interfejsu
– testy dostosowania do środowiska,
- ewentualnie – przenośności
– testy wymaganych cech jakościowych
- bezpieczeństwa, wydajności, przenośności,...
– testy wymaganych cech użytkowych
- łatwości użycia, zrozumiałości,...
• Niektóre problemy testowania systemowego
– środowisko testowania? instrumentacja?
– kto testuje, deweloperzy?
– znaczący koszt testowania systemowego
folia: 45
 Budowa i integracja SI

Testowanie akceptacyjne
(ang. Acceptance testing)
 Ostateczna odpowiedź, czy zbudowano oczekiwany system, czy jest on gotów
do pełnienia funkcji biznesowych zamawiającego (wprowadzenia na rynek)
• Zademonstrowanie spełniania kryteriów akceptacji
– kryteria te powinien określać dokument specyfikacji wymagań (SWS)
• Zespół testujący
– klient, jego dane, ...
– udział developerów ?
 praktyka: mieszane zespoły
lub nawet trzecia strona
• Środowisko testowania
– testy alfa – testy (z udziałem klienta!) w środowisku wytwórczym
– testy beta – testy u klienta – w środowisku docelowym lub, często,
laboratoryjnym
• Wynik
przyjęcie – odrzucenie – akceptacja warunkowa

folia: 46
 Budowa i integracja SI

Niektóre inne terminy

(nazwy) testów
• Testy funkcjonalne – pojęcie bliskie testom walidacyjnym; niekiedy
nazywa się tak testy sprawdzające działanie oprogramowania zgodnie ze
specyfikacją funkcjonalną w ramach testów akceptacyjnych
• Testy regresyjne – ważny rodzaj testów, których celem jest sprawdzenie,
czy rozbudowując / zmieniając oprogramowanie, dodając nową funkcjo-
nalność lub poprawiając błędy nie naruszyliśmy innych właściwości
oprogramowania. Testy regresyjne powinny być wykonywanie zarówno
na poziomie kodu programu (jeśli to możliwe), ale przede wszystkim na
poziomie działania zintegrowanej aplikacji
• Testy instalacyjne/testy konfiguracji –sprawdzenie, jak oprogramowanie
zachowuje się na różnych platformach sprzętowych, systemach
operacyjnych, różnych wersjach tych systemów, przy różnym zestawie
oprogramowania, jakie może mieć odbiorca
• Testy używalności – tzw. usability tests, służą temu by ocenić użytkową
przydatność oprogramowania dla jego potencjalnych użytkowników
folia: 47
 Budowa i integracja SI

Proces testowania

• Określenie celu (poziomu) i zakresu testowania

– poziomy: jednostkowego testowania, integracyjnego,
walidacyjnego/systemowego, akceptacyjnego
• Przygotowanie planu testów dla wybranego poziomu
– organizacja i strategia testowania, uczestnicy,
konfiguracja oprogramowania, harmonogram
• Projektowanie przypadków testowych
– dla poszczególnych przypadków dobierane są odpowiednie dane
testowe, podawane oczekiwane wyniki,
określane kryteria zaliczenia testu,...
• Wykonanie testów i zebranie danych
– raporty z przeprowadzonych testów
• Ocena wyników testów

folia: 48
 Budowa i integracja SI
1. Wprowadzenie ....................................................................................................................... 4
1.1. Opis systemu ............................................................................................................................... 4
1.2. Cel i zakres dokumentu .............................................................................................................. 5
1.3. Powiązania z innymi planami .................................................................................................... 5
Dokumenty powiązane ............................................................................................................... 6
Plan testów –
1.4.
2. Strategia testowania .............................................................................................................. 6
2.1.
2.2.
przykładowy
Testy akceptacyjne ..................................................................................................................... 6
Testy walidacyjne ....................................................................................................................... 6
spis treści
3. dokumentu
Środowisko testowania .......................................................................................................... 6
3.1. Uczestnicy procesu testowania i ich role ................................................................................... 6
3.2. Organizacja testów ..................................................................................................................... 7
4. Opis testów ............................................................................................................................. 7
4.1. Informacja ogólna....................................................................................................................... 7
4.1.1. Klasy testów ........................................................................................................................................... 7
4.1.2. Ogólne warunki wykonania testów ........................................................................................................ 8
4.2. Zaplanowane testy ...................................................................................................................... 8
4.2.1. Testy akceptacyjne ................................................................................................................................. 8
4.2.1.1. Testy funkcjonalne: ....................................................................................................................... 8
4.2.1.2. Testy wydajnościowe:................................................................................................................... 9
4.2.1.3. Testy zabezpieczenia .................................................................................................................. 10
4.2.1.4. Testy interfejsów......................................................................................................................... 10
4.2.1.5. Harmonogram testów akceptacyjnych ........................................................................................ 11
4.2.2. Testy walidacyjne ................................................................................................................................. 11
4.2.2.1. Testy funkcjonalne: ..................................................................................................................... 11
4.2.2.2. Testy wydajnościowe:................................................................................................................. 14
4.2.2.3. Testy zabezpieczenia .................................................................................................................. 14
4.2.2.4. Testy interfejsów......................................................................................................................... 15
4.2.2.5. Testy błędów ............................................................................................................................... 15
4.2.2.6. Testy inne: .................................................................................................................................. 15
4.2.2.7. Harmonogram testów walidacyjnych .......................................................................................... 16
5. Formularz raportowania testów ......................................................................................... 17
folia: 49
 Budowa i integracja SI

Planowanie testów – przykład

Klasa testów Cel
Testy testy funkcjonalne wykazanie poprawnej realizacji zadanych funkcji systemu
akceptacyjne
testy potwierdzenie realizacji zadanych funkcji w określonym
wydajnościowe czasie na określonej ilości danych
testy utwierdzenie w poczuciu, że system jest zabezpieczony
zabezpieczenia zgodnie z oczekiwaniami klienta
testy interfejsów wykazanie, że system jest zgodny ze standardami i
przyjazny w obsłudze dla użytkownika
Testy testy funkcjonalne sprawdzenie poprawnej realizacji zadanych funkcji
walidacyjne systemu
testy sprawdzenie realizacji zadanych funkcji w określonym
wydajnościowe czasie na określonej ilości danych oraz ocena wydajności
systemu
testy sprawdzenie czy system jest zabezpieczony zgodnie ze
zabezpieczenia specyfikacją
testy interfejsów ocena czy system jest zgodny ze standardami i przyjazny
w obsłudze dla użytkownika
testy błędów sprawdzenie odporności systemu na błędne dane
wprowadzane przez użytkownika
testy sprawdzenie realizacji zadanych funkcji w określonym
maksymalnego czasie na maksymalnej ilości danych oraz ocena
obciążenia odporności systemu przy granicznych ilościach danych

Przypadek Warunki testu, dane Oczekiwane Kryteria Uwagi

testowy wejściowe i czynności wyniki akceptacji
AF1 - Warunki testu: Wprowadzone Zapisane dane
Rejestr uruchomiony system, dane zostały identyczne z
abonentów Dane wejściowe: zapisane w bazie wprowadzonymi;
zdefiniowane linie danych;
telefoniczne, parametry
systemu;
Czynności:
dodanie i edycja danych
abonenta (trzech
abonentów);
folia: 50
 Budowa i integracja SI

Planowanie testów

• Planowanie testów
– SWS a plany testów akceptacyjnych

– Plany testów akceptacyjnych

i walidacyjnych – zakres

folia: 51
 Budowa i integracja SI

Planowanie testów - przykład

• STACT - opis i diagram PU

• Plan testów akceptacyjnych

i walidacyjnych

folia: 52
 Budowa i integracja SI

Dokumentowanie Projekt: Przygotował:

i raportowanie testów Faza : Testowanie

Nazwa dokumentu : Raport z wykonania testów walidacyjnych

Wersja Rozdział/Str Opis Data / Autor

1.0 1 ...... 26-01-02

1. Wyniki testów
Testowanie wykonano zgodnie z harmonogramem testów walidacyjnych. Wyniki testowania:
Liczba wykonanych przypadków testowych: 14
• Raport podsumowujacy Liczba wykonanych z negatywnym wynikiem: 4

Lista negatywnych przypadków:

• Dokumentacja testów
1. V.1.1 – Bill Calculation
Niepoprawne zachowanie systemu dla opóźnionych płatności – po wprowadzeniu danych
o opóźnionej płatności system nie uwzględnia zapłaconej faktury – traktuje abonenta tak,
jakby miał nadal zaległości.

• Praktyczny 2. V.1.4 – Clearnes of complaints

Brak możliwości zmiany statusu finansowego.
3. Poprawność formatów danych
System umożliwia wprowadzanie niepoprawnych znaków (np. liter) do numeru linii.
4. Niezgodność ze standardem interfejsu użytkownika
Nieopisana kolumna na ekranie zawierającym dane faktury.

2. Wnioski

Znalezione błędy, szczególnie pierwszy i drugi, nie pozwalają na przekazanie systemu do

testów akceptacyjnych u klienta. Błędy te powodują niepoprawne działanie systemu w zakresie
obsługi statusu finansowego abonenta oraz spłacania zaległych faktur. Konsekwencje takiego
stanu rzeczy są zatrważające: nieprawidłowe wyznaczenie wiarygodności i solidności abonenta
powodujące odłączenie linii a w dalszej kolejności wystąpienie na drogę egzekucji należności
prowadzić może do spraw sądowych, odszkodowań a także utraty pozycji firmy na rynku.

folia: 53
 Budowa i integracja SI

Dokumentowanie
i raportowanie testów
Id. wymagania
Przykład formatki opisu testu
Identification TF07.01 Id. testu
Tested ite ms Correctness of calculating invoices
• Raport podsumowujacy
Input specification At least three invoices calculated manually basing on the just read-
in billing data. The invoices should be calculated for subscribers
with different numbers of lines, some of them should contain
• Dokumentacja penalty.

testów Details of charging a subscriber (Appendix B).

Output specification The invoices calculated by the system.
Description Starting calculating invoices.
• Praktyczny Items pass/fail criteria The invoices calculated by the system are the same as those
calculated manually.
Special require ments User logged in the system should be of Operator class.
A file with billing data has to be successfully read-in before
starting calculating invoices.
Tariff tables and parameters should exist and contain correct data.
Invoices prepared manually are calculated correctly.
folia: 54
 Budowa i integracja SI

Dokumentowanie
i raportowanie testów

• Raport podsumowujacy

• Dokumentacja IDENTYFIKATOR
F-07

testów
WYMAGANIA

OPIS
Dla bazy Oracle powinna istnieć możliwość wykonywania pełnej kopii bazy danych

• Praktyczny KRYTERIUM
AKCEPTACJI
Program poprawnie wykonuje kopie pełne, co należy sprawdzić wykonując próbę
odtworzenia bazy danych z jednej z tych kopii

PRZEBIEG TESTU
- Wykonano kopię zapasową bazy danych Oracle przy pomocy programu DB
Backup

- Pomyślnie odtworzono bazę danych z kopii zapasowej wykonanej

w punkcie pierwszym

P. Palczewski
folia: 55
 Budowa i integracja SI

Użycie
oprogramowania do Automatyzacja
ustalenia warunków
początkowych
testowania, wykonania
testów, porównania
rzeczywistych
rezultatów
z oczekiwanymi, lub
w celu realizacji innych
funkcji sterowania
i raportowania testów

Arndt R., Jaśkowski M., Szydłowska A.: Prezentacja na

potrzeby przedmiotu PIO420 2007/2008 , UAM Poznań
folia: 56
 Budowa i integracja SI

Zalety i wady automatyzacji

testów
+ Istotne przyspieszenie procesu testowania
+ Zmniejszenie kosztu testowania
+ Lepszej jakości oprogramowanie wytworzone szybciej
+ Ogromna użyteczność w przypadku powtarzania testów
czy prowadzenia testów regresyjnych

- Spore nakłady na przygotowanie; ‘brak rąk’ po temu

- Przy krótkich okresach wytwarzania / sprintach – duże nakłady czasu na testowanie
- Kosztuje! - dobór narzędzia, zakup licencji, wdrożenie wybranego rozwiązania.
Czasem nie ma gotowego rozwiązania i trzeba uruchomić osobny projekt na napisanie
narzędzia, które pozwoli zautomatyzować testy w organizacji.
http://www.computerworld.pl/artykuly/381609/Automatyzacja.testow.musi.byc.przemyslana.html
- Trudno uchwycić pełen wachlarz interakcji systemu z użytkownikami, często więc
nie prowadzi do ujawnienia błędów tej sfery
- Braki w dokumentacji  niekompletne specyfikacje testowe
- Niespójność narzędzi
folia: 57
 Budowa i integracja SI

Arndt R., Jaśkowski M., Szydłowska A.: Prezentacja na

folia: 58
potrzeby przedmiotu PIO420 2007/2008 , UAM Poznań
 Budowa i integracja SI

Szerzej rozumiany proces

testowania [J.Górski]
konfiguracja
oprogramowania wyniki
testów
TESTOWANIE OCENA

konfiguracja
testów
intensywność
awarii

Modelowanie Uruchamianie
cechy, np. (debugging)
niezawodności
Weryfikacja
Walidacja
poprawione
szacowana oprogramowanie
niezawodność

Niezawodność - prawdopodobieństwo bezawaryjnego funkcjonowania

w określonym przedziale czasu i w określonych warunkach operacyjnych
folia: 59
 Budowa i integracja SI

Testowanie oprogramowania

Testowanie nie zastąpi dobrej

konstrukcji programu !

Jakości nie da się wbudować w program

wyłącznie poprzez testowanie !

folia: 60