Wykrywanie, ocena skutecznoĹłci i

Transkrypt

POLITECHNIKA WARSZAWSKA
Wydział Elektroniki i Technik Informacyjnych
ROZPRAWA DOKTORSKA
mgr inż. Piotr Paweł Nazimek
Wykrywanie, ocena skuteczności i optymalizacja wykorzystania asercji
w programach
Promotor
prof. dr hab. inż. Janusz Sosnowski
Warszawa, 2011
Streszczenie
Asercje programowe sa˛ jednym z mechanizmów stosowanych w celu podniesienia wiarygodności systemów komputerowych.
Moga˛ one zostać określone poprzez zastosowanie
algorytmów dynamicznego wykrywania asercji, które umożliwiaja˛ wyznaczenie dużej liczby
różnego rodzaju zależności wyłacznie
˛
na podstawie informacji zebranych podczas wykonania
programu, bez statycznej analizy jego kodu źródłowego. Charakter tych algorytmów oraz
ograniczona ilość informacji, jaka˛ maja˛ do dyspozycji, rodza˛ pytania dotyczace
˛ przydatności
stosowania wykrytych asercji oraz sposobu wyboru ich podzbioru umożliwiajacego
˛
skuteczna˛
detekcj˛e bł˛edów.
W rozprawie zdefiniowane zostały miary pozwalajace
˛
wyrazić skuteczność oraz
nieskuteczność asercji w procesie detekcji bł˛edów zarówno w sposób bezwzgl˛edny jak
i wzgl˛edem innych asercji w badanym programie. Wyróżniono także szereg innych wielkości
charakteryzujacych
˛
asercje takich jak: koszt statyczny, koszt dynamiczny, czas wykrycia bł˛edu
i inne. Zaproponowane zostały metody ich pomiaru. Omówiony został także ogólny model
optymalizacyjny w formie zadania programowania całkowitoliczbowego, którego celem jest
wybór najlepszego zestawu asercji o preferowanych właściwościach. Uwzgl˛ednia on funkcje
celu takie jak: skuteczność, nieskuteczność, koszt, liczba asercji oraz pokrycie bł˛edów.
Praca zawiera również analiz˛e metody podniesienia skuteczności wykrywanych asercji
poprzez uzupełnienie ich o ślad opisujacy
˛ przebieg wykonania programu z jakim sa˛ zwiazane.
˛
Poza zdefiniowaniem poj˛ecia śladu, operacji na śladzie i asercji ze śladem zaproponowano
algorytmy służace
˛ wykrywaniu asercji ze śladem, redukcji liczby śladów w zbiorze asercji
ze śladem, skracania śladów w zbiorze asercji ze śladem oraz redukcji liczby identyfikatorów
punktów programu dla zbiorów asercji ze śladem. Omówiono również sposoby weryfikacji
asercji ze śladem w programach.
Do badania proponowanych algorytmów opracowano oryginalne metody przeprowadzania
eksperymentów. W rozprawie zawarto opis wykonanych eksperymentów, przedstawiono otrzymane wyniki oraz wypływajace
˛ z nich wnioski. W eksperymentach wykorzystano rzeczywiste
aplikacje takie jak: sterownik linii produkcyjnej, implementacj˛e algorytmu rozwiazywania
˛
układu równań liniowych metoda˛ eliminacji Gaussa czy różne implementacje algorytmu
kompresji danych z rodziny ZIP.
Słowa kluczowe: asercja, asercja ze śladem, wykrywanie asercji, optymalizacja, wiarygodność oprogramowania, testowanie oprogramowania, detekcja bł˛edów, lokalizacja bł˛edów,
tolerowanie bł˛edów.
3
Abstract
Discovering, efficiency measurement and usage optimization of software assertions
Software assertions are used to improve software reliability. One way of determining them
is to use algorithms for dynamic detection of assertions that serve to identify high number of
different conditions, based only on informations collected during execution of the program,
without the static analysis of its source code. The nature of these algorithms and the limited
amount of information to analyze needs to investigate the usefulness of discovered assertions
and method of selecting a subset of them to ensure efficient detection of errors.
Assertions (also called invariants, properties or conditions) dynamic detection algorithms
are designed to find different types of dependences in programs based only on informations
collected during their execution without static analysis. Specificity of those algorithms and
limited quantity of data to analyze needs to investigate the usage principle of discovered
dependences for software dependability increase.
This thesis defines different types of measures to express efficiency and inefficiency of
discovered assertions during error tolerance inspection or fault detection process. Also other
measures like static cost, dynamic cost, error detection latency were defined. The methods of
measurement are described for proposed values. There were also presented general optimization
models in the form of integer programming problems with goal functions like efficiency,
inefficiency, cost, number of assertions or error coverage.
This dissertation introduces techniques for increasing efficiency of detected assertions
through using program execution trace.
Conceptions of trace, assertion with trace and
trace operations were defined. The work describes several algorithms that allow discovering
assertions with trace, reducing number of traces in assertions with trace set, shortening traces in
assertions with trace set and reducing number of observation point id’s for assertions with trace
sets. Different ways of assertions with trace verification are presented.
Presented algorithms were investigated using original experimental methods. For several
applications, like manufacture line control driver or implementations of compressing algorithm
from ZIP family, experiments description and results have been presented.
Keywords: assertion, assertion with trace, discovering assertions, optimization, software
dependability, software testing, software fault detection, software debugging, error tolerance
inspection.
4
Podzi˛ekowania
Pragnałbym
˛
podzi˛ekować profesorowi Januszowi Sosnowskiemu za opiek˛e przez cały okres
studiów doktoranckich oraz pomoc podczas tworzenia niniejszej rozprawy.
Dzi˛ekuj˛e Rodzicom, Rodzinie, Koleżankom i Kolegom z Wydziału za wsparcie i pomoc podczas
pracy nad doktoratem.
Spis treści
1. Wprowadzenie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
1.1.
Tło badań i przeglad
˛ literatury . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
1.2.
Teza i cel rozprawy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
1.3.
Struktura rozprawy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2. Wykrywanie asercji w programach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
2.1.
Algorytmy dynamicznego wykrywania asercji . . . . . . . . . . . . . . . . . . . . . .
17
2.1.1.
Instrumentacja programu . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.1.2.
Kolekcjonowanie danych . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
2.1.3.
Wykrywanie asercji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
2.1.4.
Analiza asercji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
2.1.5.
Prezentacja wyników . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
Schematy systemów dynamicznego wykrywania asercji . . . . . . . . . . . . . . . . .
24
2.2.1.
Tryb odroczony . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
2.2.2.
Tryb ciagły
˛ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
2.3.
Wykrywane asercje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
2.4.
Zastosowania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
3. Parametry asercji i metoda selekcji asercji . . . . . . . . . . . . . . . . . . . . . . . . . .
33
2.2.
3.1.
Definicje podstawowych poj˛eć . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
3.2.
Parametry asercji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
3.2.1.
Aktywność asercji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
3.2.2.
Liczba sprawdzeń asercji . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
3.2.3.
Koszt statyczny asercji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
3.2.4.
Koszt dynamiczny asercji . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
3.2.5.
Koszt położenia asercji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
3.2.6.
Czas detekcji bł˛edu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
3.2.7.
Zaufanie do asercji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
3.2.8.
Atrybuty asercji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
3.2.9.
Charakterystyki i profile asercji . . . . . . . . . . . . . . . . . . . . . . . . . .
41
3.2.10. Skuteczność i nieskuteczność asercji . . . . . . . . . . . . . . . . . . . . . . .
43
Metoda selekcji asercji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
3.3.1.
Obserwacja asercji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
3.3.2.
Wybór asercji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
3.3.
7
3.3.3.
Weryfikacja wyników . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
3.3.4.
Przykłady zastosowania metody selekcji asercji . . . . . . . . . . . . . . . . .
55
Podsumowanie i wnioski . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
4. Asercje ze śladem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
3.4.
4.1.
Ślad wykonania programu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
4.1.1.
Rejestracja śladu wykonania programu . . . . . . . . . . . . . . . . . . . . . .
62
4.2.
Poj˛ecie asercji ze śladem wykonania . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
4.3.
Parametry asercji ze śladem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
4.4.
Wykrywanie asercji ze śladem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
4.4.1.
Algorytm redukcji liczby śladów w zbiorze asercji ze śladem . . . . . . . . . .
66
4.4.2.
Algorytm skracania śladów w zbiorze asercji ze śladem . . . . . . . . . . . . .
67
Weryfikacja asercji ze śladem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
4.5.
4.5.1.
Algorytm redukcji liczby identyfikatorów punktów programu dla zbiorów
asercji ze śladem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
4.6.
Przykład działania zaproponowanych algorytmów . . . . . . . . . . . . . . . . . . . .
72
4.7.
Prezentacja asercji ze śladem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
4.7.1.
Wykaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
4.7.2.
Digraf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
4.7.3.
Multigraf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
4.7.4.
Kolorowany multigraf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
Podsumowanie i wnioski . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
5. Optymalizacja wykorzystania asercji w programach . . . . . . . . . . . . . . . . . . . . .
81
4.8.
5.1.
5.2.
Redukcja liczby asercji w programie . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
5.1.1.
Charakterystyka badanych programów . . . . . . . . . . . . . . . . . . . . . .
82
5.1.2.
Wykrywanie asercji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
5.1.3.
Pomiar parametrów asercji . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
5.1.4.
Wybór zestawów asercji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
5.1.5.
Eksperymenty weryfikujace
˛ . . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
5.1.6.
Wnioski . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Asercje ze śladem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
5.2.1.
Charakterystyka badanych bibliotek . . . . . . . . . . . . . . . . . . . . . . . 115
5.2.2.
Wykrywanie asercji ze śladem . . . . . . . . . . . . . . . . . . . . . . . . . . 115
5.2.3.
Liczba wykrytych asercji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
5.2.4.
Analiza procesu wykrywania asercji . . . . . . . . . . . . . . . . . . . . . . . 118
5.2.5.
Analiza nieprawidłowych naruszeń asercji . . . . . . . . . . . . . . . . . . . . 127
5.2.6.
Analiza wykrywania bł˛edów przez asercje . . . . . . . . . . . . . . . . . . . . 129
5.2.7.
Operacje na asercjach ze śladem . . . . . . . . . . . . . . . . . . . . . . . . . 134
5.2.8.
Wnioski . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
8
6. Zastosowania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
6.1.
6.2.
Wybrane obszary zastosowań . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
6.1.1.
Systemy wykrywania asercji . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
6.1.2.
Detekcja bł˛edów w programach . . . . . . . . . . . . . . . . . . . . . . . . . . 140
6.1.3.
Lokalizacja bł˛edów w programach . . . . . . . . . . . . . . . . . . . . . . . . 140
6.1.4.
Detekcja anomalii w działaniu programów . . . . . . . . . . . . . . . . . . . . 141
6.1.5.
Wspomaganie pracy programisty/analityka/użytkownika . . . . . . . . . . . . . 141
6.1.6.
Systemy weryfikacji oprogramowania . . . . . . . . . . . . . . . . . . . . . . 142
6.1.7.
Inne zastosowania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
System nadzoru transportu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
7. Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
7.1.
Spostrzeżenia i wnioski . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
7.2.
Kierunki dalszych badań . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Bibliografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
A. Zaimplementowane oprogramowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
A.1. Pakiet AEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
A.1.1. Program aemshm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
A.1.2. Program aemtool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
A.1.3. Biblioteka aem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
A.1.4. Skrypt aem2stats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
A.1.5. Skrypt aem2report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
A.2. Pakiet FlowGraph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
A.2.1. Skrypt invariant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
A.2.2. Skrypt analyze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
A.2.3. Skrypt injector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
A.2.4. Skrypt transform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
9
1. Wprowadzenie
Zadania wykonywane przez współczesne systemy informatyczne staja˛ si˛e coraz bardziej
krytyczne i cz˛esto bezpośrednio wpływaja˛ na jakość oraz bezpieczeństwo życia człowieka.
Ich całościowa weryfikacja z użyciem metod formalnych lub wykorzystaniem wiedzy zespołu
doświadczonych inżynierów jest w wi˛ekszości przypadków niewykonalna.
to zarówno czynniki techniczne jak i ekonomiczne.
Wpływaja˛ na
Przykładem pierwszych moga˛ być
czas i wiedza wymagana do efektywnego stosowania metod formalnych, do drugich można
zaliczyć elementy takie jak zmniejszanie kosztów tworzenia oprogramowania czy też czas
wprowadzania produktu na rynek.
Ograniczenia jakie maja˛ współczesne metody weryfikacji poprawności systemów informatycznych oraz oczekiwania jakie si˛e przed nimi stawia wymuszaja˛ poszukiwanie nowych
metod ułatwiajacych
˛
i zwi˛ekszajacych
˛
efektywność tych procesów. Szczególnie interesujace
˛ sa˛
te, w których minimalizuje si˛e zaangażowanie człowieka, a mimo to charakteryzuja˛ si˛e wysoka˛
skutecznościa˛ oraz pewnymi wartościami dodanymi. Jedna˛ z takich metod jest dynamiczna
analiza programów w celu wykrycia w nich pewnych właściwości przydatnych mi˛edzy innymi
w procesie testowania, weryfikacji, detekcji czy lokalizacji bł˛edów.
1.1. Tło badań i przeglad
˛ literatury
Asercja˛ w dziedzinie inżynierii oprogramowania nazywamy formalna˛ zależność opisujac
˛ a˛
zachowanie systemu, które jest wymagane podczas jego działania [91]. Zależność ta może
być określona w sposób bardzo zróżnicowany, na przykład poprzez wyrażenie algebraiczne,
logiczne lub w sposób opisowy.
Systemem zaś może być program [83] czy też układ
elektroniczny [10, 34] realizujacy
˛ określone zadania. Asercje moga˛ być określane manualnie
przez projektanta lub przy zastosowaniu jednej z automatycznych metod ich wykrywania.
Wśród nich wyróżniamy metody statyczne, dynamiczne i mieszane. Metody statycznego
wykrywania asercji [7, 80, 88, 94] bazuja˛ na algorytmach, które odkrywaja˛ je na podstawie
statycznej analizy kodu źródłowego lub budowy układu. Metody dynamicznego wykrywania
asercji wykorzystuja˛ proces dynamicznej analizy programu [6] w celu poszukiwania asercji
w oparciu o dane, jakie można zebrać podczas jego wykonania lub działania badanego układu.
Metody mieszane [90, 108] bazuja˛ na algorytmach zarówno statycznego jak i dynamicznego
wykrywania asercji.
11
Wśród wymienionych metod wykrywania asercji na szczególna˛ uwag˛e zasługuja˛ metody
dynamiczne i na nich skupiono si˛e w rozprawie. Pozwalaja˛ one odkrywać asercje w sposób
automatyczny, bez lub z minimalnym udziałem projektanta lub programisty. Tak znalezione
asercje prezentuja˛ zachowanie danego systemu podczas jego działania i pozwalaja˛ wyeliminować pewne ograniczenia metod statycznych, jak na przykład zbyt duża ogólność asercji
czy niemożność zaawansowanej analizy programu wykorzystujacego
˛
dynamicznie tworzone
struktury danych lub polimorfizm. Problematyka wykrywania asercji metodami dynamicznymi
oraz ich wykorzystania jest tematem wielu prac badawczych, artykułów i rozpraw. Jednym
z pierwszych i obecnie najbardziej zaawansowanych narz˛edzi w tej dziedzinie jest Daikon1 .
Powstało ono jako efekt rozprawy [29] majacej
˛
na celu zbadanie możliwości wykrywania
i zastosowania asercji (nazywanych tu prawdopodobnymi niezmiennikami) w programach.
Wykrywa ono ponad siedemdziesiat
˛ typów różnych warunków arytmetycznych i logicznych
opisujacych
˛
zwiazki
˛ pomi˛edzy zmiennymi w programie lub elementami struktur danych takich
jak tablice czy listy dynamiczne.
W pracach
[21, 29, 30, 32, 79] zaprezentowano różnorodne metody oraz algorytmy
stosowane na etapie pozyskiwania danych oraz dynamicznego wykrywania asercji w pakiecie
Daikon [33, 66] oraz rozważono problemy takie jak określanie poziomu zaufania do
znalezionych asercji czy też eliminacji nadmiarowych asercji, na przykład takich, których
warunki si˛e pokrywaja˛ lub po przekształceniach wyrażaja˛ identyczna˛ zależność. Nieco mniej
zaawansowanym narz˛edziem o podobnym działaniu jest DIDUCE2 [44]. Wykrywa on mniejsza˛
liczb˛e różnego rodzaju asercji. Narz˛edzie to posiada możliwość automatycznego wprowadzania, a tym samym weryfikacji wykrytych asercji w analizowanym programie. Upraszcza
to praktyczne wykorzystanie znalezionych asercji. Jako przykład kolejnego narz˛edzia tego
typu można podać pakiet Axiom Meister3 [16], który jest oprogramowaniem komercyjnym,
w przeciwieństwie do Daikon i DIDUCE. Wymienione dotychczas narz˛edzia i prace skupiaja˛
si˛e na wykrywaniu asercji, które opieraja˛ swoje działanie na detekcji bł˛edów w danych, jakie
przetwarza analizowany program. Innym rodzajem asercji sa˛ asercje badajace
˛ poprawność
wykonania programu w odniesieniu do weryfikacji kolejności realizowanych przez niego
operacji. Szereg prac poświ˛econych jest dynamicznemu wykrywaniu zależności temporalnych
na podstawie obserwacji przebiegu wykonania programu. Do najważniejszych należy zaliczyć
projekt Perracotta4 [111–115] oraz prace zwiazane
˛
z badaniem zależności pomi˛edzy wołanymi
metodami (tak zwane wydobywanie specyfikacji) [3, 4]. W artykule [86] zaproponowano
metod˛e monitorowania aplikacji polegajacego
˛
na wykonywaniu pomiarów czasu pomi˛edzy
wybranymi jego punktami, a nast˛epnie wykorzystania zebranych danych do weryfikacji
1
2
3
4
http://pag.csail.mit.edu/daikon/
http://sourceforge.net/projects/diduce/
http://research.microsoft.com/projects/mutt/
http://www.cs.virginia.edu/perracotta/
12
poprawności jego wykonania. Można uznać to za jedna˛ z metod wykrywania asercji badajacych
˛
poprawność przebiegu działania programu. Inne metody wykrywania asercji majacych
˛
na celu
weryfikacj˛e poprawności przebiegu programu bazuja˛ na jego analizie podczas kompilacji lub
przez programist˛e. Należy zakwalifikować je do rodziny metod statycznego wykrywania asercji
w programie. Interesujace
˛ dla omawianego zagadnienia sa˛ w nich metody reprezentacji asercji
bazujace
˛ na: wykorzystaniu kolejek w metodzie CCA [1], przyporzadkowaniu
˛
odpowiednich
liczb pierwszych blokom programu i operacjach na nich w metodzie ECCA [2], wykorzystaniu
sygnatur w metodzie CFCSS [75] i CEDA [104], wykorzystaniu zmiennej w programie, która
jest w odpowiedni sposób modyfikowana w każdym jego bloku i pewne jej wartości reprezentuja˛ prawidłowy przebieg (metoda YACCA) [38] oraz użyciu mechanizmu wyrażeń regularnych
do konstrukcji asercji [8]. Techniki umożliwiajace
˛ usuwanie lub łaczenie
˛
odpowiednich bloków
w programie, dla których wyznaczane maja˛ być asercje badajace
˛ poprawność przebiegu jego
wykonania, tak aby uwzgl˛edniony był założony koszt zwiazany
˛
z użyciem dodatkowych
instrukcji w badanym programie zaproponowano w pracy [105].
Naturalnym, bezpośrednim sposobem zastosowania znalezionych warunków jest wykorzystanie ich w postaci asercji programowych. Pozwala to zaobserwować sytuacje, w której dojdzie
do niespełnienia znalezionej asercji. Dzi˛eki temu mechanizmowi w wielu przypadkach możliwa
jest szybka detekcja i lokalizacja bł˛edów. Sformalizowanie tej idei w postaci określania
warunków poczatkowych,
˛
niezmienników oraz warunków końcowych przy wykonywaniu
obliczeń przez programy [45] stało si˛e podstawa˛ do opracowania metodologii projektowania
zwiazanego
˛
umowa˛ [61,100]. Jest ona wykorzystywana jako podstawa j˛ezyków programowania
takich jak Eiffel5 oraz bibliotek [39,49] i narz˛edzi wspomagajacych
˛
projektowanie i weryfikacj˛e
oprogramowania, wśród których można wymienić JML6 [12, 54, 55, 65] oraz ESC/Java27
[15, 52, 67, 73] dedykowane dla j˛ezyka Java8 , JACK9 [13] przeznaczone dla apletów dla kart
inteligentnych Java Card10 [64, 71] czy Spec#11 dedykowane dla środowiska .NET12 . Moga˛ one
wykorzystywać również asercje wykryte w sposób dynamiczny [20]. Do innych zastosowań
efektów pracy narz˛edzi dynamicznie wykrywajacych
˛
asercje należy zaliczyć: automatyczna˛
generacj˛e przypadków testowych dla badanych programów [22, 76, 110, 116], wspomaganie
procesu testowania [109] oraz integracji [59, 60] oprogramowania w złożonych środowiskach,
profilowanie oprogramowania [28], wspomaganie lokalizacji lub automatyczne lokalizowanie
różnego rodzaju bł˛edów [11, 57, 62, 84, 85], zautomatyzowane generowanie specyfikacji
badanego oprogramowania [74] oraz jego refaktoryzacj˛e [50]. Metody te stosowane sa˛ również
5
http://www.eiffel.com
http://www.cs.iastate.edu/ leavens/JML/
7
http://sort.ucd.ie/projects/escjava/
8
http://java.sun.com
9
http://www-sop.inria.fr/everest/soft/Jack/jack.html
10
http://java.sun.com/javacard/
11
http://research.microsoft.com/projects/specsharp/
12
http://www.microsoft.com/net/
6
13
w obszarze zwiazanym
˛
z detekcja˛ bł˛edów sprz˛etowych [93]. Techniki sprz˛etowej implementacji wykrytych asercji zaproponowano w [78]. Znalezione asercje (niezmienniki) programu
moga˛ również być użyte w procesie rozwoju i weryfikacji oprogramowania, które bazuja˛ na
zastosowaniu metod formalnych [89, 101]. Podobne prace prowadzone były w Instytucie
Informatyki Politechniki Warszawskiej [23, 53]. Niektóre z narz˛edzi, jak wspomniany już
DIDUCE, posiadaja˛ możliwość automatycznego wprowadzania znalezionych już asercji do
badanego programu w trakcie procesu jego dynamicznej analizy.
W literaturze omawiana jest również problematyka określania i poprawy jakości wykrytych
asercji oraz różnorodne sposoby ich oceny. Poza wymienionymi już metodami wyznaczania
wartości wyrażajacej
˛
zaufanie do znalezionych asercji oraz eliminacji wybranych z nich
rozważone zostały zagadnienia dotyczace
˛ uogólniania wykrytych asercji poprzez eliminacj˛e
warunków wynikajacych
˛
z polimorfizmu w obiektowych j˛ezykach programowania, pomijania
nadmiarowych asercji czy nieistotnych danych zebranych na etapie obserwacji programu [27,
29, 31]. Poruszone zostało również zagadnienie wykorzystania losowych oraz pseudolosowych
danych wejściowych dla badanych programów [29], które uruchamiane sa˛ w celu obserwacji
skutkujacej
˛ wyszukiwaniem asercji. Przedstawione zostały inne metody oceny asercji bazujace
˛
na analizie pokrycia strukturalnego badanego programu [42] przez wykryte asercje, zastosowaniu testowania strukturalnego w ocenie wykrytych asercji [87] oraz stosowaniu metody
ograniczeń [25] w procesie analizy poprawności znalezionych asercji. Autorzy opracowań
dotyczacych
˛
przedstawionych problemów skupili si˛e na realizacji postawionych zadań na etapie
procesu wykrywania asercji.
Należy zauważyć, że tematyka dynamicznego wykrywania asercji i ich późniejszego
wykorzystania nie jest jedynie domena˛ akademickich projektów badawczych. Realizowane
sa˛ również badania w prywatnych ośrodkach i powstaja˛ narz˛edzia komercyjne przeznaczone do
tego celu. Przykładem takiego pakietu może być AgitarOne13 wspomagajacy
˛ testowanie oprogramowania w j˛ezyku Java, którego jednym z elementów jest moduł dynamicznie wykrywajacy
˛
mi˛edzy innymi szeroka˛ gam˛e prostych warunków arytmetycznych [95].
Wymienione prace skupiaja˛ si˛e głównie na problematyce wykrywania asercji oraz ich
zastosowania do detekcji i lokalizacji bł˛edów na etapie testowania oraz weryfikacji oprogramowania. W marginalny sposób poruszane sa˛ problemy takie jak wykorzystanie asercji do
detekcji bł˛edów podczas walidacji lub produkcyjnego działania systemu. Istotna staje si˛e wtedy
redukcja liczby sprawdzanych asercji tak, aby zapewnić odpowiednia˛ wydajność systemu, co
oznacza, że konieczne jest wybranie najskuteczniejszych z nich [68, 107]. Interesujace
˛ również
jest zbadanie możliwości automatycznego wykrywania metodami dynamicznymi takich asercji,
których manualne określenie jest trudne, ale sama ich interpretacja nie jest skomplikowana
(nie opisuja˛ skomplikowanych zależności). Należa˛ do nich asercje zależne od przebiegu
13
http://www.agitar.com
14
wykonania programu, utworzone poprzez połaczenie
˛
asercji weryfikujacych
˛
poprawność
danych przetwarzanych w programie oraz asercji badajacych
˛
poprawność przebiegu wykonania
programu [69].
1.2. Teza i cel rozprawy
Teza rozprawy brzmi nast˛epujaco:
˛
Poprzez zastosowanie odpowiedniej strategii selekcji asercji w programie oraz
uzależnienie ich od przebiegu wykonania programu możliwa jest redukcja liczby
stosowanych asercji przy zachowaniu wysokiego poziomu detekcji bł˛edów.
Celem rozprawy jest:
Zaproponowanie zestawu parametrów umożliwiajacych
˛
ocen˛e asercji oraz metody
ich selekcji dla programu pod wzgl˛edem zdefiniowanych kryteriów oraz opracowanie
metody automatycznego wykrywania asercji zależnych od przebiegu (śladu) wykonania
programu.
Tak postawiony cel rozprawy osiagni˛
˛ eto poprzez analiz˛e poniższych zagadnień oraz
opracowanie ich rozwiazań,
˛
w których zawartych jest szereg oryginalnych koncepcji autora:
— zaproponowanie miar pozwalajacych
˛
ocenić asercje stosowane w programie pod wzgl˛edem zróżnicowanych kryteriów takich jak koszt statyczny, dynamiczny, skuteczność oraz
nieskuteczność w detekcji bł˛edów,
— opracowanie metody pozwalajacej
˛ na optymalny wybór asercji pod wzgl˛edem zdefiniowanych kryteriów opisujacych
˛
ich właściwości i zachowanie z uwzgl˛ednieniem określonych
ograniczeń,
— zaproponowanie kryteriów i metody selekcji asercji,
— eksperymentalna weryfikacja zaproponowanej metody selekcji asercji z wykorzystaniem
symulatorów bł˛edów,
— opracowanie algorytmu wyznaczania i eksperymentalne zbadanie asercji zależnych od
przebiegu programu (asercji ze śladem),
— zaproponowanie algorytmów zwiazanych
˛
z wydajnym stosowaniem asercji ze śladem
umożliwiajacych
˛
eliminacj˛e nadmiarowych śladów, ich skracanie oraz redukcj˛e liczby
identyfikatorów stosowanych w śladach.
Istotnym elementem pracy jest również opracowanie metodyki badań eksperymentalnych
oraz modułów programowych wspomagajacych
˛
przeprowadzenie testów i analiz˛e otrzymanych
wyników. Wykorzystane zostały one w praktyce podczas analizy przykładowych programów
w aspekcie omawianej tematyki.
15
1.3. Struktura rozprawy
Rozprawa złożona jest z siedmiu rozdziałów, bibliografii oraz dodatku. Rozdział pierwszy
poświ˛econo nakreśleniu tła tematu pracy, przegladu
˛ literatury oraz sformułowaniu tezy i celu
rozprawy.
W rozdziale drugim przedstawiono i usystematyzowano metody dynamicznego wykrywania
asercji w programach, zaprezentowano ich zalety i wady, stosowane algorytmy i rodzaje wykrywanych asercji. Omówiono również wybrane zastosowania wykrytych asercji oraz ich wpływ
na podnoszenie wiarygodności systemów w kontekście możliwych bł˛edów programowych,
sprz˛etowych, środowiska i konfiguracji.
Rozdział trzeci wprowadza definicje miar pozwalajacych
˛
na ocen˛e asercji stosowanych
w oprogramowaniu. Zaprezentowano także metod˛e pozwalajac
˛ a˛ na wybór najlepszych asercji
według kryteriów zwiazanych
˛
mi˛edzy innymi z ich skutecznościa,˛ nieskutecznościa,˛ kosztem
stosowania wraz z uwzgl˛ednieniem narzuconych ograniczeń.
W rozdziale czwartym zaproponowano oryginalna˛ metod˛e podniesienia wiarygodności
wykrywanych asercji poprzez uzależnienie ich od przebiegu wykonania programu. Wprowadzono poj˛ecie śladu wykonania programu oraz asercji ze śladem. Przedstawione zostały metody
pozwalajace
˛ na dynamiczne wykrywanie tego typu asercji oraz ich późniejsza,˛ praktyczna˛
weryfikacj˛e w badanym oprogramowaniu. Zaprezentowano również algorytmy przeznaczone
do wydajnego stosowania asercji ze śladem.
Rozdział piaty
˛ poświ˛econy jest badaniom metod zaprezentowanych w dwóch poprzednich
rozdziałach. Dla wybranych programów takich jak sterownik linii produkcyjnej, implementacja
algorytmu rozwiazywania
˛
układu równań liniowych metoda˛ eliminacji Gaussa czy różne
implementacje algorytmu kompresji danych z rodziny ZIP zastosowane zostały zaproponowane
algorytmy. W rozdziale przedstawiono opis przeprowadzonych eksperymentów, otrzymane
wyniki oraz wypływajace
˛ z nich wnioski. Treść rozdziału jest potwierdzeniem możliwości
oraz zasadności stosowania omówionych metod w praktyce inżynierskiej.
Wybrane zastosowania opracowanych metod w szeroko poj˛etym procesie rozwoju oprogramowania zostały rozważone w rozdziale szóstym. Zaprezentowano w nim nie tylko możliwość użycia asercji do detekcji i lokalizacji bł˛edów programowych, które jest głównie omawiane w literaturze, ale również do wykrywania innego typu bł˛edów zwiazanych
˛
z konfiguracja˛
czy środowiskiem działania aplikacji. W rozdziale omówiono również wyniki wykorzystania
asercji ze śladem dla aplikacji komercyjnej działajacej
˛ w środowisku produkcyjnym.
Rozdział siódmy poświ˛econo na podsumowanie treści rozprawy, zaprezentowanie
spostrzeżeń oraz wniosków i nakreślenie kierunków dalszych badań majacych
˛
na celu rozwój
omawianej tematyki.
W dodatku zamieszczono opis pakietów oprogramowania stworzonych w celu
przeprowadzenia eksperymentów w ramach niniejszej rozprawy.
2. Wykrywanie asercji w programach
Metody dynamicznego wykrywania asercji wykorzystuja˛ techniki dynamicznej analizy
programu w celu poszukiwania asercji w oparciu o dane, jakie można zebrać podczas jego
wykonania.
Poniżej omówiono struktury algorytmów używanych w tym procesie wraz
z wykorzystywanymi narz˛edziami i metodami. Zaprezentowano zalety i wady przedstawionych
rozwiazań.
˛
Omówione zostały również wybrane zastosowania wykrytych asercji oraz ich
wpływ na podnoszenie wiarygodności systemów.
2.1. Algorytmy dynamicznego wykrywania asercji
Dynamiczne metody wykrywania asercji bazuja˛ wyłacznie
˛
na informacjach, które można
zebrać podczas wykonania programu, bez statycznej analizy jego kodu źródłowego. W metodach tych można wyróżnić nast˛epujace
˛ kroki:
1. instrumentacja programu – wyposażenie badanego programu w mechanizmy umożliwiajace
˛ współprac˛e z systemem wykrywania asercji, które pozwola˛ na obserwacj˛e jego
działania,
2. kolekcjonowanie danych – zebranie danych z uruchomienia (uruchomień) badanego
programu, które poddane zostana˛ dalszej analizie w celu wykrycia asercji,
3. wykrywanie asercji – wykonanie algorytmu (algorytmów) wykrywania określonego
rodzaju asercji na podstawie wcześniej zebranych danych,
4. analiza wykrytych asercji – etap ten ma na celu automatyczne usuni˛ecie nieodpowiednich
asercji (na przykład nadmiarowych asercji, które zostały znalezione przez różne algorytmy
wykrywania asercji, a weryfikuja˛ identyczne warunki),
5. prezentacja wyników – prezentacja wykrytych asercji użytkownikowi lub ich eksport
w formie pozwalajacej
˛ na użycie w innych systemach (na przykład przeznaczonych do
specyfikacji lub weryfikacji oprogramowania).
Poniżej omówione zostały szczegóły dotyczace
˛ kolejnych etapów metod dynamicznego
wykrywania asercji.
17
2.1.1. Instrumentacja programu
Instrumentacja programu ma na celu wyposażenie go w mechanizmy, które pozwola˛ na
zebranie niezb˛ednych informacji przeznaczonych dla przeprowadzenia procesu wykrywania
asercji. Musza˛ być one przygotowane w takim formacie, aby były zrozumiałe dla systemu wykrywania asercji.
Modyfikacja może być wykonana r˛ecznie, poprzez wstawienie
odpowiednich instrukcji do kodu źródłowego programu i ponowna˛ jego kompilacj˛e, lub
automatycznie, przy wykorzystaniu narz˛edzi modyfikujacych
˛
kod źródłowy lub wykonywalny
badanej aplikacji.
W celu odpowiedniej instrumentacji programu należy wybrać w nim pewne punkty,
w których dokonywana b˛edzie obserwacja wybranych jego parametrów oraz zmiennych.
Takie miejsca, nazywane punktami obserwacji w programie, zostaja˛ wybrane poprzez ich
wskazanie lub ustalenie pewnego szablonu, na podstawie którego sa˛ określane.
Sposób
wyboru konkretnych typów punktów obserwacji zależy od możliwości stosowanych narz˛edzi.
Przykładowymi punktami obserwacji moga˛ być:
— wywołania metod (funkcji, procedur) – obserwowane moga˛ być parametry wejściowe
wywoływanych metod,
— wyjścia z metod (funkcji, procedur) – obserwowany może być efekt działania metod (na
przykład wartość zwracana z funkcji),
— miejsca b˛edace
˛ poczatkiem
˛
lub końcem wydzielonego bloku programu – obserwowane
moga˛ być wartości zmiennych przed lub po wykonaniu określonego bloku programu (na
przykład p˛etli czy instrukcji warunkowej),
— miejsca, w których odczytywana lub modyfikowana jest wartość określonej zmiennej,
— miejsca wybranie na podstawie odpowiedniej strategii, w których umieszczenie wykrytych
asercji może być najbardziej korzystne z uwagi na detekcj˛e bł˛edów [77].
Wprowadzane do programu modyfikacje musza˛ mieć charakter pasywny, co oznacza, że
nie moga˛ one zmieniać rejestrowanych wartości lub przebiegu wykonania programu. Mogłoby
mieć to wpływ na działanie całej aplikacji. Najcz˛eściej w punktach obserwacji dokonuje
si˛e zebrania dost˛epnych informacji takich jak wartości wybranych zmiennych lokalnych
i globalnych.
Narz˛edzia wykrywajace
˛ asercje posiadaja˛ wbudowane mechanizmy pozwalajace
˛ na
odpowiednia˛ instrumentacj˛e programu lub korzystaja˛ z zewn˛etrznych aplikacji umożliwiaja˛
cych zebranie danych do dalszej analizy. Przykładem realizacji pierwszego podejścia jest
analizator kodu bajtowego dla j˛ezyka Java wbudowany bezpośrednio w pakiet DIDUCE [44].
Umożliwia on obserwacj˛e wybranych klas, metod lub zmiennych globalnych bez dost˛epu do
kodu źródłowego badanego programu. Rozwiazania
˛
tego typu stosowane sa˛ również w oprogramowaniu komercyjnym, takim jak AgitarOne [95]. Wada˛ tak realizowanej instrumentacji
programów jest brak praktycznej możliwości wykorzystania wymienionych narz˛edzi wykry18
wajacych
˛
asercje dla innych j˛ezyków programowania niż te, dla których je przygotowano. Odmienne podejście zastosowane zostało w pakiecie Daikon [29]. Posiada on budow˛e modułowa.˛
Podsystem wykrywajacy
˛ asercje oczekuje na odpowiednio przygotowane dane, które zebrane
zostaja˛ w pliku podczas uruchomienia badanego programu. Moga˛ one zostać przygotowane
dzi˛eki użyciu narz˛edzi opracowanych dla wybranych j˛ezyków programowania. Narz˛edzia te
przeprowadzaja˛ proces instrumentacji i obserwacji programu. Wybierajac
˛ jako kryterium form˛e
analizowanych aplikacji można wyróżnić dwa typy tego rodzaju oprogramowania: pracujace
˛
bezpośrednio z użyciem plików wykonywalnych (programy skompilowane dla określonej
platformy sprz˛etowej i systemu operacyjnego) oraz modyfikujace
˛ kod źródłowy.
Dla j˛ezyków C/C++, na bazie oprogramowania Valgrind1 [72] przeznaczonego do analizy plików wykonywalnych o formatach obejmujacych
˛
różne platformy sprz˛etowe, systemy
operacyjne oraz kompilatory, przygotowane zostało rozszerzenie Fjalar2 [40], które stanowi
baz˛e do realizacji procesu kolekcjonowania danych niezb˛ednych do wykrywania asercji. Sa˛
one realizowane przez narz˛edzie Kvasir3 [26], które umożliwia śledzenie wartości zmiennych
w programie oraz DynComp4 [41], które pozwala na obserwacj˛e obiektów tworzonych
dynamicznie podczas działania badanej aplikacji.
Narz˛edzia te dodaja˛ w odpowiednich
miejscach plików wykonywalnych dodatkowy kod maszynowy rejestrujacy
˛ wybrane zdarzenia
takie jak zmiana wartości obserwowanej zmiennej lub wywołanie metody.
Kod bajtowy
j˛ezyka Java analizowany jest z użyciem Chicory [26], który posiada podobne możliwości jak
analizator wbudowany w pakiet DIDUCE. Oprogramowaniem, którego możliwości pozwalaja˛
na zastosowanie w procesie instrumentacji plików wykonywalnych jest również pakiet Pin5 [58]
udost˛epniony przez firm˛e Intel. Jednak obecnie nie jest on bezpośrednio wykorzystywany przez
żadne z narz˛edzi wykrywajacych
˛
asercje.
Inne aplikacje przeznaczone do instrumentacji programu wymagaja˛ dost˛epu do jego kodu
źródłowego, ponieważ bezpośrednio w nim wprowadzane sa˛ odpowiednie zmiany. Nast˛epnie
badana aplikacja musi zostać ponownie skompilowana, jeśli stworzona jest w j˛ezyku, który tego
wymaga. Po wykonaniu tych operacji może zostać poddana obserwacji.
W pakiecie Daikon przygotowane zostało rozszerzenie Mangel-Wurzel dla j˛ezyków C/C++
współpracujace
˛ z komercyjnym narz˛edziem Rational Purify6 . Modyfikuje ono bezpośrednio kod źródłowy badanej aplikacji.
Analogiczne narz˛edzia umożliwiaja˛ instrumentacj˛e
programów w innych j˛ezykach programowania.
W ramach projektu CITADEL7 [81, 82]
przygotowany został analizator dla programów zaimplementowanych w j˛ezyku Eiffel. Możliwe
1
2
3
4
5
6
7
http://valgrind.org/
http://groups.csail.mit.edu/pag/fjalar/
http://groups.csail.mit.edu/pag/daikon/
http://groups.csail.mit.edu/pag/daikon/
http://www.pintool.org/
http://www-01.ibm.com/software/awdtools/purify/
http://se.inf.ethz.ch/people/polikarpova/citadel.html
19
jest także wykrywanie asercji dla programów stworzonych w IOA8 [24,35] oraz instrumentacja
skryptów w j˛ezyku Perl9 za pomoca˛ narz˛edzia dfepl [26].
Wynikiem działania wymienionych narz˛edzi sa˛ programy w formie wykonywalnej lub ich
kody źródłowe przygotowane do przeprowadzenia kolejnego kroku dynamicznego wykrywania
asercji jakim jest proces kolekcjonowania danych. Zebrane w ten sposób informacje zostaja˛
nast˛epnie poddane dalszej analizie na etapie wykrywania asercji. Otwarta specyfikacja budowy
plików przetwarzanych przez systemy wykrywania asercji takie jak Daikon pozwala na ich
integracj˛e z każdym j˛ezykiem programowania.
Inne narz˛edzia zwiazane
˛
z wykrywaniem asercji w programach, jak na przykład Perracotta [115], pomijaja˛ problematyk˛e instrumentacji badanych programów oczekujac
˛ jedynie
odpowiednio przygotowanego pliku opisujacego
˛
przebieg jego wykonania.
Podczas przeprowadzania eksperymentów w ramach niniejszej rozprawy dla j˛ezyków Java
oraz C/C++ zastosowano z sukcesem technik˛e programowania aspektowego [14]. Wśród
dost˛epnych narz˛edzi oraz w literaturze niespotykane sa˛ przykłady stosowania tej metody.
Umożliwia ona obserwacj˛e wybranych punktów programu poprzez implementacj˛e aspektów
rejestrujacych
˛
stan wybranych zmiennych programu. Aspekty te zostana˛ wykonane w wyznaczonych miejscach takich jak na przykład przed lub po uruchomieniu metody. Należy jednak
zwrócić uwag˛e, że niektóre z implementacji idei programowania aspektowego moga˛ wymagać
dost˛epu do kodu źródłowego programu.
Zaleta˛ rozwiazań
˛
bazujacych
˛
na bezpośredniej instrumentacji plików wykonywalnych jest
brak konieczności posiadania kodów źródłowych badanych programów. Jednak rozwiazania
˛
te sa˛ trudniejsze do praktycznej realizacji i cz˛esto niemożliwe jest zaawansowane śledzenie
programu z uwagi na brak wbudowanych w plik wykonywalny dodatkowych informacji kompilatora oraz wykonana˛ przez niego optymalizacj˛e. Narz˛edzia przeprowadzajace
˛ instrumentacj˛e
bezpośrednio z użyciem kodów źródłowych sa˛ łatwiejsze w implementacji, a wykryte w ten
sposób asercje powiazane
˛
sa˛ z konkretnymi miejscami w źródłach badanych aplikacji. Pozwala
to na łatwiejsza˛ lokalizacj˛e bł˛edów wykrytych za pomoca˛ znalezionych asercji.
2.1.2. Kolekcjonowanie danych
Etap ten służy wydobyciu z informacji uzyskiwanych podczas uruchomienia programu
danych, które w nast˛epnym kroku b˛eda˛ analizowane w celu wykrycia asercji. Dane zbierane sa˛
w sposób zależny od wcześniejszej modyfikacji badanej aplikacji. W momencie osiagni˛
˛ ecia
określonego miejsca w programie, który został wybrany jako punkt obserwacji, informacje
takie jak identyfikator danego punktu w programie oraz wartości obserwowanych zmiennych
gromadzone sa˛ na potrzeby dalszej analizy na etapie wykrywania asercji. Istniejace
˛ rozwiazania
˛
8
9
http://groups.csail.mit.edu/tds/ioa/
http://www.perl.org/
20
zapisuja˛ je do pliku tekstowego (Daikon), przechowuja˛ w pami˛eci operacyjnej (DIDUCE) lub
bazie danych (AgitarOne). Dane nie musza˛ być kolekcjonowane na tej samej maszynie, na
której uruchamiany jest badany program. Takie rozwiazanie
˛
zastosowano w AgitarOne. Polega
ono na użyciu zewn˛etrznej bazy danych w celu zwi˛ekszenia wydajności działania systemu
wykrywajacego
˛
asercje i odcia˛żenia maszyny, na której uruchamiana jest aplikacja.
Uruchomienie badanego programu może wiazać
˛
si˛e z potrzeba˛ przygotowania zestawu
(zestawów) danych wejściowych, jeśli sa˛ konieczne do jego działania. Od nich zależne sa˛
informacje zebrane podczas obserwacji programu, a w efekcie liczba i jakość wykrytych
asercji. Dane te moga˛ być przygotowane manualnie lub w sposób automatyczny. Manualne
opracowanie danych wejściowych może zostać zrealizowane na przykład poprzez implementacj˛e zróżnicowanych scenariuszy testowych dla badanej aplikacji, w których bada si˛e jej
zachowanie i ocenia jego poprawność przy wyznaczonych warunkach wst˛epnych. Z uwagi
na zaangażowanie człowieka jest to proces czasochłonny i kosztowny. Tej wady moga˛ być
pozbawione metody automatycznej generacji danych wejściowych. Przy zastosowaniu generatorów losowych dla określonych typów danych wejściowych jakie oczekiwane sa˛ przez program
możliwe jest wytworzenie dużej ich liczby niewielkim kosztem [43]. Sposób ten może jednak
prowadzić do niezadowalajacego
˛
pokrycia kodu badanej aplikacji, a w efekcie do wykrycia
asercji o niskiej jakości lub dla mniejszej liczby punktów obserwacji. Jest to metoda, która
nie powinna być stosowania do wszystkich typów aplikacji, w szczególności, kiedy aplikacja
stworzona jest do przetwarzania jedynie pewnego zakresu danych lub pomi˛edzy danymi
wejściowymi musza˛ wyst˛epować określone wst˛epne zależności, aby wygenerowane wyniki
miały praktyczna˛ wartość. Losowe generowanie danych wejściowych może być przydatne
dla aplikacji bez ściśle określonych warunków, jakie musza˛ one spełniać. Przykładami takich
programów moga˛ być aplikacje obliczeniowe rozwiazuj
˛ ace
˛ układy równań lub realizujace
˛
algorytmy kompresji danych. Technika losowego generowania danych wejściowych została
wykorzystana w pracy dla konkretnych implementacji wymienionych klas aplikacji, których
użyto podczas przeprowadzania eksperymentów. Bardziej zaawansowane metody, tworzace
˛
dane wejściowe w sposób pseudolosowy, polegaja˛ na wykorzystaniu algorytmów generujacych
˛
dane wejściowe z uwzgl˛ednieniem ich odpowiedniej jakości odzwierciedlajacej
˛ si˛e na przykład
w zapewnieniu wysokiego poziomu pokrycia kodu lub uwzgl˛ednieniu specyfiki działania
badanego programu [29]. Najcz˛eściej wymagaja˛ one stworzenia dedykowanego generatora
danych wejściowych dla badanej aplikacji, który b˛edzie uwzgl˛edniał sposób jej implementacji
i działania. Do ich oceny można stosować różne miary pokrycia wykorzystywane w procesie
testowania oprogramowania [96].
Proces kolekcjonowania danych może również zostać zrealizowany przy wykorzystaniu
istniejacych
˛
już dzienników działania aplikacji, które opisuja˛ przebieg jej wykonania i zawieraja˛
informacje, takie jak wartości zmiennych programu, potrzebne do wykrycia żadanych
˛
asercji.
21
W takim przypadku konieczne jest jedynie odpowiednie przetworzenie posiadanych informacji
na potrzeby dalszej analizy. Oznacza to, że nie zawsze na etapie kolekcjonowania danych musi
zachodzić konieczność uruchamiania i obserwowania badanego programu.
2.1.3. Wykrywanie asercji
Asercje wykrywane sa˛ z użyciem dedykowanych algorytmów zależnych od rodzaju wyst˛epujacego
˛
w nich warunku. Każde z narz˛edzi implementuje pewien skończony zbiór typów
wykrywanych asercji.
Jest to najcz˛eściej realizowane poprzez implementacj˛e odr˛ebnych
modułów, które analizuja˛ zebrane dane w celu znalezienia warunku określonego rodzaju.
Otwarte narz˛edzia, na przykład Daikon, umożliwiaja˛ dodanie nowych typów poszukiwanych
warunków poprzez implementacj˛e dodatkowego modułu przeznaczonego do analizy zebranych
danych w sposób umożliwiajacy
˛ wykrycie asercji określonego rodzaju.
Podczas procesu wykrywania asercji analizowane sa˛ dane zebrane w trakcie obserwacji
programu. Niektóre rodzaje warunków, w szczególności opisujace
˛ właściwości tylko jednej
zmiennej, moga˛ być wykrywane równolegle z etapem kolekcjonowania danych. Sa˛ to asercje,
do których wykrycia nie jest potrzebny pełny zbiór danych do analizy. Przykładem takiej
asercji może być asercja sprawdzajaca
˛ czy wybrana zmienna przyjmuje wartości wi˛eksze od
zera. W takim przypadku dane przetwarzane sa˛ na bieżaco
˛ przez algorytmy wykrywajace
˛
określone asercje. Główna˛ zaleta˛ takiego rozwiazania
˛
jest brak konieczności przechowywania
zebranych danych, których ilość może być znaczna. Do wad należy zaliczyć brak możliwości
wykrywania niektórych typów asercji, szczególnie bardziej złożonych lub wykrywajacych
˛
zależności pomi˛edzy wieloma zmiennymi programu. Asercje tego typu wymagaja˛ zbiorczej
analizy wszystkich zebranych danych.
Ponadto, w zależności od sposobu implementacji
systemu wykrywajacego
˛
asercje, możliwe jest wydłużenie czasu działania badanego programu
z uwagi na konieczność dodatkowej, równoległej analizy dużej ilości danych.
Może to
prowadzić do istotnych zakłóceń w jego działaniu jeśli wyst˛epuja˛ w nim elementy zależne
od czasu wykonania, jak na przykład określony czas oczekiwania na zakończenie wybranych
operacji takich jak proces komunikacji z serwerem czy przeprowadzenie wymaganych obliczeń.
DIDUCE wykrywa asercje podczas uruchomienia badanego programu, dane nie sa˛
kolekcjonowane do oddzielnego zbioru w celu ich późniejszego wykorzystania.
Daikon,
z uwagi na modularna˛ budow˛e, przetwarza zebrane dane w odr˛ebnym procesie po zakończeniu
działania badanej aplikacji. AgitarOne potrafi działać w obu opisanych trybach, a ponadto
proces wykrywania asercji może być przeprowadzany na innej maszynie niż ta, na której działa
obserwowana aplikacja. Pozwala to zminimalizować wpływ obcia˛żenia spowodowanego duża˛
ilościa˛ przeprowadzanych obliczeń zwiazanych
˛
z procesem wykrywania asercji w badanym
programie.
Rodzaje wykrywanych asercji przez istniejace
˛ narz˛edzia, przykłady algorytmów oraz ich
22
parametrów omówiono w dalszej cz˛eści rozdziału.
W ramach rozprawy zaproponowano rozszerzenie wykrywanych asercji o dodatkowy
element wia˛żacy
˛ dana˛ asercj˛e ze śladem przebiegu programu opisujacym
˛
odwiedzone punkty
programu. Technika ta omówiona jest szczegółowo w rozdziale 4.
2.1.4. Analiza asercji
Celem procesu analizy zbioru wykrytych asercji jest wybranie spośród wszystkich
znalezionych asercji tych, które maja˛ być ostatecznie zaprezentowane użytkownikowi. Jest
to krok opcjonalny, który może obejmować na przykład procedur˛e usuwania redundantnych
asercji, jakie moga˛ zostać wykryte w wyniku stosowania algorytmów wykrywajacych
˛
asercje
różnych rodzajów. Przykładowo, jeżeli wykryte zostana˛ asercje: x 6= 0, x > 0, x ⊆ {4, 6, 8},
x jest parzyste to moga˛ one zostać zastapione
˛
jedna˛ asercja˛ x ⊆ {4, 6, 8}.
Na tym etapie moga˛ być podejmowane również inne czynności, których końcowym efektem
jest wybór najlepszych z wykrytych asercji. Pakiet Daikon dodatkowo wyznacza dla każdej
asercji parametr wyrażajacy
˛ zaufanie. Użytkownikowi zaprezentowane zostana˛ jedynie te
asercje, dla których parametr ten przekroczył określona˛ wartość. Sposób obliczania zaufania
przez pakiet Daikon dla wybranych rodzajów asercji zostanie omówiony w dalszej cz˛eści
rozdziału.
W ramach rozprawy opracowana została nowa metoda analizy i selekcji asercji. Umożliwia
ona wybór tych spośród nich, które spełniaja˛ wybrane kryteria zwiazane
˛
mi˛edzy innymi ze
skutecznościa˛ detekcji bł˛edów. Metoda została szczegółowo przedstawiona w rozdziale 3.
2.1.5. Prezentacja wyników
W ostatnim kroku asercje oraz opisujace
˛ je parametry prezentowane sa˛ użytkownikowi.
Niektóre z narz˛edzi posiadaja˛ możliwość zapisu asercji w różnych popularnych notacjach
z myśla˛ o aplikacjach, które moga˛ je wykorzystać do dalszych celów jakimi sa˛ na przykład
specyfikacja czy weryfikacja oprogramowania. Umożliwia to mi˛edzy innymi system Daikon,
który potrafi uzupełnić kody źródłowe badanych aplikacji o odpowiednie adnotacje opisujace
˛
wykryte asercje.
Zaimplementowano w nim kilka popularnych formatów wyjściowych
obejmujacych
˛
mi˛edzy innymi notacje takie jak JML czy ESC/Java2.
Możliwa jest również integracja prezentacji wyników ze środowiskami do rozwoju aplikacji. Znalezione asercje wyświetlane sa˛ na przykład jako pomoc kontekstowa dla danej klasy
lub metody. Rozwiazanie
˛
to zostało zaimplementowane w pakiecie AgitarOne. DIDUCE
prezentuje wykryte asercje w trakcie przegladania
˛
kolejnych linii kodu źródłowego. Daikon
umożliwia stworzenie adnotacji JML w kodzie źródłowym, które moga˛ zostać zintegrowane
z dokumentacja˛ badanego programu.
23
2.2. Schematy systemów dynamicznego wykrywania asercji
W zależności od metody powiazania
˛
procesów wyst˛epujacych
˛
w systemach wykrywajacych
˛
asercje w sposób dynamiczny można wyróżnić różne schematy ich działania. Omówione
wcześniej etapy moga˛ być wykonywane niezależnie lub moga˛ si˛e wzajemnie przeplatać.
Cz˛esto, z uwagi na konieczność zaawansowanej analizy struktury badanego programu, docelowa implementacja i sposób działania silnie zależa˛ od możliwości oferowanych przez
stosowana˛ technologi˛e, jak na przykład system operacyjny, na którym przeprowadzany jest
proces wykrywania asercji czy kompilator, z użyciem którego został przygotowany badany
program.
Można wskazać dwa ogólne schematy działania systemów dynamicznego wykrywania
asercji:
— działajace
˛ w trybie odroczonym – etapy kolekcjonowania danych oraz wykrywania asercji
sa˛ rozdzielone,
— działajace
˛ w trybie ciagłym
˛
– etap kolekcjonowania danych oraz wykrywania asercji
(a cz˛esto również ich prezentacji oraz weryfikacji) przeplataja˛ si˛e.
Systemy działajace
˛ w trybie odroczonym kolekcjonuja˛ całość danych przechowujac
˛ je do
dalszej analizy na etapie wykrywania asercji. Dane te analizowane sa˛ całościowo. Systemy
działajace
˛
sa˛ pewnego rodzaju monitorami aplikacji. W poczatkowym
˛
etapie
działania kolekcjonuja˛ one dane i w wybranym momencie moga˛ zostać dodatkowo przełaczone
˛
w tryb weryfikacji znalezionych warunków. System Daikon jest przedstawicielem systemu
działajacego
˛
w trybie odroczonym. Przykładem systemu działajacego
˛
w trybie ciagłym
˛
jest
pakiet DIDUCE.
2.2.1. Tryb odroczony
Ogólny schemat systemu wykrywajacego
˛
asercje działajacego
˛
w trybie odroczonym
pokazano na rysunku 2.1. Oryginalny program, w wersji źródłowej lub wykonywalnej, po
procesie instrumentacji (krok pierwszy), poddawany jest obserwacji z użyciem przygotowanych
danych wejściowych (krok drugi). Na podstawie zebranych informacji wykrywane sa˛ w nim
asercje (krok trzeci), które moga˛ zostać wprowadzone do aplikacji poddanej badaniu (krok
czwarty). Każdy z tych kroków wykonywany jest niezależnie i najcz˛eściej odpowiada za niego
odr˛ebny moduł systemu.
Modułowa budowa systemów dynamicznego wykrywania asercji działajacych
˛
w trybie
odroczonym jest ich podstawowa˛ zaleta.˛ Taka architektura umożliwia łatwa˛ implementacj˛e
procesu instrumentacji dla wielu j˛ezyków programowania lub stosowania kilku modułów
wykrywajacych
˛
różnorodne asercje. Utrudniona jest jednak obserwacja programów działaja˛
cych bardzo długo lub w sposób ciagły.
˛
Jest to spowodowane koniecznościa˛ tymczasowego
24
program
przystosowany
do obserwacji
2
1
oryginalny
program
instrumentacja
programu
SRC
BIN
LOG
DAT
dane
wejściowe
dane zebrane na podstawie
obserwacji programu
3
4
integracja asercji
program
z asercjami
obserwacja
działania programu
(kolekcjonowanie
danych)
SRC
BIN
SRC
BIN
wykrywanie asercji
TXT
wykryte
asercje
Rysunek 2.1. Schemat systemu wykrywajacego
˛
asercja w trybie odroczonym
przechowania dużej ilości danych otrzymanych w wyniku obserwacji takich aplikacji. Przechowywanie tych danych, a przez to możliwość ich całościowej analizy, jest zaleta˛ w przypadku, kiedy algorytmy wykrywajace
˛ asercje wykrywaja˛ warunki możliwe do wyznaczenia
jedynie poprzez dost˛ep do pełnego zbioru danych.
2.2.2. Tryb ciagły
˛
Schemat systemu wykrywajacego
˛
asercje działajacego
˛
w trybie ciagłym
˛
jest analogiczny
do przedstawionego na rysunku 2.1, z ta˛ różnica,˛ że procesy obserwacji programu (krok drugi)
oraz wykrywania asercji (krok trzeci) sa˛ połaczone.
˛
Oryginalny program, w wersji źródłowej
lub wykonywalnej, po procesie instrumentacji, poddawany jest obserwacji z użyciem pewnych
danych wejściowych, która połaczona
˛
jest z wykrywaniem asercji. Oznacza to, że zebrane dane
analizowane sa˛ na bieżaco
˛ i nie musza˛ być przechowywane. Nast˛epnie wykryte asercje moga˛
zostać wprowadzone do badanego programu.
Dodatkowo w systemach działajacych
˛
w trybie ciagłym
˛
proces integracji asercji z aplikacja˛
może odbywać si˛e łacznie
˛
z procesem kolekcjonowania danych i wykrywania asercji. Takie
rozwiazanie
˛
jest najcz˛eściej stosowane dla aplikacji działajacych
˛
bez określonego momentu
zakończenia. Przykładami moga˛ być systemy operacyjne, serwery transakcyjne lub programy
dla mikrokontrolerów. Aplikacje takie moga˛ być obserwowane przez pewien okres czasu i w
momencie wykrycia odpowiednich warunków moga˛ być one wprowadzone do nich w trakcie
ich działania.
25
Systemy dynamicznego wykrywania asercji działajace
˛
sa˛ najcz˛eściej
monolitycznymi aplikacjami, jak na przykład DIDUCE, w których wszystkie procesy sa˛
zintegrowane. Wada˛ takiego rozwiazania
˛
jest utrudniona rozbudowa tych systemów o nowe
funkcje takie jak obsługiwane j˛ezyki programowania, platformy sprz˛etowe czy rodzaje
wykrywanych asercji.
Ponadto, z uwagi na brak przechowywania danych z obserwacji
aplikacji, istnieje możliwość wykrywania jedynie zaw˛eżonego zbioru typów asercji. Zaleta˛
systemów o omawianym schemacie jest możliwość obserwacji aplikacji działajacych
˛
długo lub
nieprzerwanie. Ponieważ systemy te zazwyczaj przetwarzaja˛ dane na bieżaco
˛ nie jest konieczne
przechowywanie dużej ilości informacji zwiazanych
˛
z obserwacja˛ aplikacji.
2.3. Wykrywane asercje
Na podstawie analizy narz˛edzi wykrywajacych
˛
asercje można określić różne klasy wykrywanych warunków. W ich poniższym wykazie x, y, z oznaczaja˛ dowolne zmienne programu
typu liczbowego, obiekty lub literały (jeśli nie zaznaczono inaczej). Stałe wartości wyznaczone
przez algorytmy wykrywajace
˛ asercje oznaczono a, b, c. Dla asercji badajacych
˛
zależności
pomi˛edzy różnymi zmiennymi przyj˛eto, że sa˛ one tego samego typu oraz zdefiniowany jest dla
nich określony operator lub określona funkcja wyst˛epujaca
˛ w warunku.
Wśród wykrywanych asercji zaimplementowanych w dost˛epnych narz˛edziach wyróżnić
można klasy wykrywanych warunków określajace:
˛
— x 6= null – czy zmienna została zainicjalizowana,
— x = a – stała wartość zmiennej,
— x 6= 0 – zmienna typu liczbowego nie przyjmuje wartości zero,
— x ⊆ {a, b, c} – wartości zmiennej pochodza˛ z określonego, niewielkiego zbioru wartości
o mocy zazwyczaj nie przekraczajacej
˛ 10 elementów,
— x ≥ a, x ≤ b, a ≤ x ≤ b – określenie zakresu zmiennej,
— x = a mod b, x 6= a mod b – stała wartość zmiennej wyznaczona modulo wzgl˛edem
innej stałej wartości w relacji równości badź
˛ nierówności,
— wymienione dotychczas typy asercji dla zmiennych typu liczbowego wykrywane sa˛ również
dla sumy lub różnicy dwóch zmiennych (za x należy przyjać
˛ odpowiednio y + z lub y − z),
— x > y, x < y, x ≥ y, x ≤ y, x = y, x 6= y – relacje pomi˛edzy zmiennymi,
— y = ax + b, z = ax + by + c – zależność liniowa pomi˛edzy dwoma lub trzema zmiennymi
liczbowymi (wi˛eksza liczba zmiennych liczbowych nie jest implementowana w dost˛epnych
narz˛edziach),
— zależności logiczne dla wybranych bitów lub pomi˛edzy wybranymi pojedynczymi bitami
w obr˛ebie jednej zmiennej,
— y = f (x) – zależności funkcyjne pomi˛edzy dwiema zmiennymi typu liczbowego takie jak
26
wartość bezwzgl˛edna, wartość przeciwna, negacja bitowa,
— z = f (x, y) – zależności funkcyjne pomi˛edzy trzema zmiennymi typu liczbowego takie
jak wi˛eksza wartość, mniejsza wartość, mnożenie, dzielenie, najwi˛ekszy wspólny dzielnik,
dzielenie modulo, przesuni˛ecie bitowe w lewo, przesuni˛ecie bitowe w prawo, koniunkcja
bitowa, alternatywa bitowa, różnica symetryczna,
— zależności dla kolekcji zmiennych określajace
˛ najwi˛eksza,˛ najmniejsza˛ wartość w kolekcji,
sposób uporzadkowania
˛
kolekcji (rosnacy,
˛
malejacy,
˛
wszystkie elementy maja˛ t˛e sama˛
wartość), zależności pomi˛edzy konkretnymi dwoma lub trzema elementami w kolekcji
traktowanymi jako niezależne zmienne (wcześniej wymienione rodzaje warunków dla
dwóch lub trzech zmiennych),
— zależności dla dwóch kolekcji zmiennych określajace
˛ zależność pomi˛edzy wszystkimi
elementami kolekcji o tym samym indeksie lub odpowiadajacych
˛
indeksach w odwrotnej
kolejności (wcześniej wymienione rodzaje zależności dla dwóch zmiennych), zawieranie
si˛e jednej kolekcji w drugiej,
— zależności pomi˛edzy wartościami wybranych zmiennych i wołanymi metodami,
— zależności pomi˛edzy kolejnościa˛ wołanych metod lub wykonywanych bloków programu,
asercje opisujace
˛ poprawny przebieg działania programu w odniesieniu do kolejności
wykonywania określonych operacji.
Przy wyborze klas wykrywanych warunków twórcy systemów kierowali si˛e głównie
łatwościa˛ interpretacji znaczenia asercji przez programist˛e oraz możliwościa˛ ich weryfikacji
w badanym programowaniu.
Najcz˛eściej algorytmy wykrywajace
˛ asercje badaja˛ statystyczne własności dla danego
warunku. System Daikon wykrywajac
˛ asercj˛e x 6= 0 bada czy x przyjmuje wartość 0. Jeśli
taka sytuacja zaistnieje asercja tego typu jest odrzucana (nie zostanie wykryta). W przeciwnym
wypadku asercja zostanie zaprezentowana użytkownikowi, jeżeli zaufanie do niej przekroczy
pewna˛ określona˛ wartość. Twórcy Daikon zdefiniowali ten parametr jako liczb˛e z zakresu
< 0, 1 > określajac
˛ sposób jej obliczania odr˛ebnie dla każdej z klas wykrywanych warunków.
Dla opisywanej asercji jest ona definiowana jako prawdopodobieństwo pojawienia si˛e wartości
różnej od 0 dla danej zmiennej. W pojedynczym pomiarze, zakładajac
˛ jednostajny rozkład
przyjmowanych wartości przez zmienna˛ x, jest ona określona jako 1 − 1r , gdzie r określa
liczb˛e różnych wartości, jakie może przyjać
˛ zmienna x. Dla n pomiarów prawdopodobieństwo
wystapienia
˛
wartości różnej od zera wynosi (1 − 1r )n . Jeśli wartość tego wyrażenia b˛edzie
mniejsza niż określona przez użytkownika asercja nie zostanie zaraportowana z uwagi na zbyt
małe zaufanie. Celem wprowadzenia tego parametru było usuni˛ecie wykrytych asercji, dla
których ilość danych, na podstawie jakich zostały wykryte, była niewielka [29], a tym samym
prawdopodobieństwo ich naruszenia przy braku wystapienia
˛
bł˛edu mogło być znaczne.
Innym przykładem może być moduł wykrywajacy
˛ asercj˛e x ⊆ {4, 6, 8}, który analizujac
˛
27
dane z obserwacji sprawdza, czy x przyjmuje pewne określone powtarzajace
˛ si˛e wartości. Jeżeli
liczba różnych wartości przyjmowanych przez x jest niewielka (na przykład od jednej do pi˛eciu)
i wyst˛epuja˛ one z cz˛estotliwościa,˛ która gwarantuje odpowiedni stopień zaufania, to na ich
podstawie asercja zostanie zaprezentowana użytkownikowi w zbiorze wykrytych asercji.
Nie zawsze systemy dynamicznie wykrywajace
˛ asercje wykrywaja˛ warunki, które operuja˛
bezpośrednio na zmiennych i obiektach w badanym programie.
W pakiecie DIDUCE
zastosowano rozwiazanie
˛
polegajace
˛ na konwersji wszystkich obserwowanych obiektów do
zmiennej całkowitoliczbowej. DIDUCE obserwuje punkty programu, w których modyfikowana
jest wartość określonego obiektu, konwertuje go do literału opisujacego
˛
jego referencj˛e
i wartość, a nast˛epnie oblicza dla niego wartość typu całkowitoliczbowego na podstawie
funkcji mieszajacej
˛ wykorzystujac
˛ standardowy algorytm zaimplementowany w j˛ezyku Java
dla obiektów reprezentujacych
˛
ciagi
˛ znakowe. Dopiero jej wartości sa˛ analizowane celem
wykrycia różnych zależności logicznych dla wybranych bitów lub pomi˛edzy wybranymi
pojedynczymi bitami i generowane sa˛ odpowiednie asercje opisujace
˛ zmiany poszczególnych
bitów w powiazaniu
˛
z ich wcześniej obserwowanymi wartościami. Jeżeli podczas wykonania
programu zaobserwowane zostana˛ inne modyfikacje bitów, niż wcześniej wykryte, pakiet
DIDUCE zgłosi wystapienie
˛
bł˛edu w punkcie wykrycia takiej sytuacji [44].
Wykrywanie asercji zwiazanych
˛
z zależnościami pomi˛edzy wołanymi metodami w systemie
Perracotta polega na wykrywaniu wszystkich powtarzajacych
˛
si˛e sekwencji wykonywanych
metod a nast˛epnie na wybieraniu tych z nich, które moga˛ okazać si˛e interesujace
˛ dla
programisty. Stosowane sa˛ w tym celu różne heurystyki. Jedna z nich polega na badaniu
podobieństwa w nazwach wołanych metod wyrażanego na przykład poprzez wykrycie w nich
identycznego prefiksu lub znalezienie wspólnego podciagu
˛ znaków o pewnej długości, przy
czym im długość wspólnego podciagu
˛ znaków jest wi˛eksza, tym nazwy metod przyjmuje si˛e
za bardziej podobne. Zakłada si˛e, że im wi˛eksze podobieństwo nazw metod tym bardziej
wykryta sekwencja może okazać si˛e interesujaca.
˛
Na etapie analizy wykrytych zależności
dokonuje si˛e również połaczenia
˛
odr˛ebnych sekwencji wywołań jeśli istnieje taka możliwość
[115]. W innych narz˛edziach wykrywajacych
˛
tego typu asercje stosowano również algorytmy
systemów uczacych
˛
si˛e [18] przekazujac
˛ im jako dane wejściowe nazwy wołanych metod [3].
Trzeba wyraźnie zaznaczyć, że narz˛edzia wykrywajace
˛ asercje w sposób dynamiczny nie
sa˛ nieomylne i nie wykrywaja˛ wszystkich klas możliwych warunków. Nie istnieja˛ również
uniwersalne algorytmy wykrywania asercji. W praktyce optymalny algorytm zależy od rodzaju
poszukiwanego warunku. Ostateczna decyzja czy wykryta asercja jest spełniona dla całej
dziedziny wartości, z którymi jest powiazana
˛
należy do narz˛edzia formalnie dowodzacego
˛
poprawność asercji wprowadzonej do programu lub człowieka.
28
2.4. Zastosowania
Znalezione asercje w różnej formie moga˛ być wprowadzane podczas etapu projektowania,
implementacji oraz testowania oprogramowania. Ich umiej˛etne zastosowanie przyczynia si˛e do
zwi˛ekszenia wiarygodności [96] badanego oprogramowania poprzez eliminacj˛e, we wczesnym
etapie jego tworzenia, bł˛edów projektowych i implementacji. Asercje zabezpieczaja˛ również
oprogramowanie przed skutkami wystapienia
˛
bł˛edów w trakcie działania. Jednym z przykładów
jest wykorzystanie asercji w ochronie systemu wykorzystujacego
˛
techniki kryptograficzne
przedstawione w [70], gdzie w badaniu eksperymentalnym autor zastosował asercje do ochrony
systemu przed wyciekiem tekstu jawnego w wyniku bł˛edu działania oprogramowania na
skutek zakłóceń w obszarze sprz˛etowym. Taka metoda zastosowania asercji może chronić
systemy wykorzystujace
˛ na przykład oprogramowanie działajace
˛ w kartach inteligentnych.
Przy zapewnieniu bezpieczeństwa istotniejsze może okazać si˛e odmówienie wykonania danej
usługi na skutek wykrytego naruszenia asercji niż jej wykonanie, które może prowadzić do
kompromitacji całego systemu lub jego cz˛eści.
Bezpośrednim sposobem wykorzystania znalezionych warunków jest wykorzystanie ich
w postaci asercji programowych. Pozwala to zaobserwować sytuacj˛e w której dojdzie do
naruszenia asercji ze wzgl˛edu na nieprawidłowe dane, jakie pojawia˛ si˛e w programie, wadliwa˛
implementacj˛e przetwarzajacego
˛
je algorytmu lub niepoprawny przebieg wykonania programu.
Wprowadzenie asercji do aplikacji może być wykonane r˛ecznie, z użyciem mechanizmów
zaimplementowanych w bibliotekach danego j˛ezyka (na przykład funkcja assert z nagłówka
assert.h w j˛ezyku C) lub w samym j˛ezyku (na przykład słowo kluczowe assert w j˛ezyku
Java). Można skorzystać również z jednego z narz˛edzi, które automatycznie wprowadza asercje
do badanej aplikacji lub oprogramowania wykrywajacego
˛
asercje zintegrowanego z modułem
do ich późniejszej weryfikacji.
Bardziej zaawansowane asercje, których wyrażenie lub
sprawdzenie nie jest możliwe bezpośrednio przez stosowany j˛ezyk programowania, moga˛ być
weryfikowane przez specjalizowane mechanizmy służace
˛ na przykład kontroli czasu wykonania
funkcji programu (procesy monitorujace
˛ działanie aplikacji), kontroli przepływu [1, 38, 104,
106] lub kontroli dost˛epu do zasobów [46]. Istnieja˛ również dedykowane j˛ezyki, których
przeznaczeniem jest opisywanie warunków asercji. Przykładem może być Schematron10 , który
przeznaczony jest do tworzenia asercji dla dokumentów XML opisujacych
˛
ich budow˛e oraz zawartość. J˛ezyk ten opisany jest w normie mi˛edzynarodowej ISO 19757-3:2006 [47]. Dost˛epne
sa˛ również biblioteki, które pozwalaja˛ rozszerzyć i zoptymalizować mechanizm wykorzystania
asercji w określonym j˛ezyku. Za przykład może służyć GNU Nana11 przeznaczona dla j˛ezyków
C/C++. Pozwala ona na wyrażenie wielu złożonych warunków (na przykład opisujacych
˛
struktury danych), pełna˛ implementacj˛e programowania zwiazanego
˛
umowa˛ w tworzonych
10
11
http://www.schematron.com/
http://savannah.gnu.org/projects/nana
29
aplikacjach oraz zaawansowanego raportowania wykrytych bł˛edów. Asercje moga˛ być również
wyrażone i weryfikowane poprzez analiz˛e wystapień
˛
i treści wpisów do dziennika badanej
aplikacji.
W [29] wskazane zostały inne aspekty wykorzystania asercji wykrytych automatycznie.
Moga˛ stać si˛e one elementem dokumentacji programu, który b˛edzie umożliwiał łatwiejsze
zrozumienie działania fragmentów kodu, który jest, nie jest lub jest niedostatecznie udokumentowany. Takie zastosowanie wykrytych asercji może uprościć analiz˛e budowy nieznanego
programu oraz pomóc zrozumieć specyfik˛e jego działania przez programist˛e. Znalezione
asercje moga˛ zostać skonfrontowane z formalna˛ specyfikacja,˛ jeśli została ona wcześniej
stworzona przez programist˛e.
Może to być szczególnie użyteczne w przypadku, gdy
wykorzystano metodologi˛e projektowania zwiazanego
˛
umowa,˛ z uwagi na to, że systemy
wykrywania asercji prezentuja˛ je w podobnej formie. Wykryte asercje moga˛ zostać wykorzystane również w procesie modyfikacji oraz rozbudowy programu. Moga˛ one nakierować
programist˛e na lepszy kierunek zmian. Dzi˛eki znalezionym asercjom, które na przykład
opisuja˛ zależności pomi˛edzy elementami w złożonych strukturach danych, programista może
wprowadzać takie modyfikacje, które doprowadza˛ do wydajniejszego działania lub lepszego
wykorzystania odpowiednio dobranych struktur danych. Ponadto analiza asercji znalezionych
przed i po wprowadzeniu modyfikacji do programu umożliwia wczesne wykrycie takich
zmian w specyfice jego działania, które moga˛ różnić si˛e od oczekiwanych przez użytkownika.
Kolejny obszar wykorzystania asercji to automatyzacja generowania testów oraz możliwość
sprawdzenia istniejacych
˛
przypadków testowych dla programu. Może to zostać zrealizowanie
poprzez przygotowanie danych wejściowych dla programu lub przypadku testowego, który b˛eda˛
prowadziły do naruszenia znalezionych asercji. Wykorzystujac
˛ specjalistyczne narz˛edzia, takie
jak DIDUCE, możliwa jest lokalizacja prawdopodobnych bł˛edów oraz odkrywania potencjalnie
niezamierzonych efektów działania badanego oprogramowania. Autor [29] zwraca również
uwag˛e na walor edukacyjny i poznawczy asercji wykrytych automatycznie. Moga˛ one być
pouczajace
˛ dla programistów i pozwolić im spojrzeć z innej perspektywy i bardziej krytycznie
na tworzony kod.
Stosowanie asercji jest jedna˛ z najstarszych technik ułatwiajacych
˛
proces rozwoju oprogramowania. Nie jest to jednak metoda idealna. Wśród wad asercji oraz problemów zwiazanych
˛
z ich stosowaniem można wymienić brak metod służacych
˛
ocenie wprowadzonych do programu
asercji pod wzgl˛edem ich poprawności oraz użyteczności w odniesieniu do wymienionych
wcześniej obszarów zastosowań. Autor ksia˛żki [98] zwraca uwag˛e na problem trudności
oceny jakie asercje powinny zostać wprowadzone, aby efektywnie wykorzystać ich możliwości
w detekcji bł˛edów. Zagadnienia te rozważono w niniejszej pracy proponujac
˛ metody oraz miary
dla oceny asercji. Do wad stosowania asercji należy również zaliczyć spowalnianie działania
oprogramowania, w szczególności jeśli opisuja˛ rozbudowane warunki, na przykład dla kolekcji
30
danych, oraz czynnik ludzki ich stosowania. Wielu projektantów i programistów nie chce
stosować asercji w tworzonym oprogramowaniu uznajac
˛ ich wprowadzanie za niepotrzebna˛
strat˛e czasu.
Asercje programowe sa˛ nadal aktywnie używana˛ i rozwijana˛ technika˛ w inżynierii oprogramowania. Dowodem na to jest mi˛edzy innymi wprowadzenie słowa kluczowego assert
do wersji 1.4 j˛ezyka Java oraz rozwijanie metod efektywnego wykorzystania tych konstrukcji
w nowoczesnych środowiskach takich jak platforma .NET. W celu zminimalizowania wpływu
asercji na czas wykonania programu oraz zmniejszenia wykorzystywanych przez nie zasobów
systemowych moga˛ być one poddawane przez kompilatory zaawansowanej optymalizacji [103].
Poza asercjami programowymi stosowane sa˛ również asercje sprz˛etowe, które umożliwiaja˛
wczesna˛ reakcj˛e na bł˛edy mogace
˛ zakłócić prac˛e układu elektronicznego, a w konsekwencji
wykonywanych programów. Do bł˛edów takich zaliczyć można polecenie wykonania nieprawidłowej instrukcji, dzielenia przez zero lub też żadania
˛
dost˛epu do nieprawidłowego obszaru
pami˛eci.
Niektóre z asercji moga˛ być zaimplementowane zarówno w sposób programowy jak
i sprz˛etowy. Przykładem moga˛ być asercje chroniace
˛ dost˛ep do stosu wykonywanego programu
lub jego obszaru danych, które zapobiegaja˛ efektom bł˛edów takich jak przepełnienie bufora
prowadzace
˛ w konsekwencji do wykonania poleceń przekazanych w danych dla aplikacji.
Mechanizmy takiej ochrony realizowane sa˛ sprz˛etowo przez niektóre z procesorów jak również
zaimplementowane w sposób programowy w systemach z rodziny Microsoft Windows.
31
3. Parametry asercji i metoda selekcji asercji
W poprzednim rozdziale przedstawione zostały metody automatycznego wykrywania asercji na podstawie analizy wykonania programu. Sprowadzaja˛ si˛e one do opracowania algorytmu,
który na podstawie dost˛epnych informacji zebranych podczas wykonania aplikacji wygeneruje
asercj˛e danego rodzaju lub zaniecha jej poszukiwania. Problemem może być znaczaca
˛ liczba
znalezionych asercji.
Może ona być trudna lub wr˛ecz niemożliwa do zinterpretowania,
a przez to również do wykorzystania przez programist˛e. Tylko niektóre z asercji sa˛ usuwane
automatycznie, jeśli istnieja˛ ku temu odpowiednie przesłanki, najcz˛eściej zwiazane
˛
z pokrywaniem si˛e tego samego warunku logicznego w wielu asercjach lub możliwościa˛ połaczenia
˛
kilku asercji w jedna˛ [31].
Narz˛edzia wykrywajace
˛ asercje w programach nie posiadaja˛
mechanizmów, które pozwoliłyby ocenić ich praktyczna˛ przydatność w procesie wykrywania
bł˛edów. Wykorzystanie wszystkich znalezionych warunków może doprowadzić do sytuacji,
w której wielkość wygenerowanego kodu wykonywalnego programu wielokrotnie przekroczy
jego wielkość poczatkow
˛
a,˛ a czas wykonania istotnie wzrośnie. Brak dodatkowych metod
eliminacji nieefektywnych asercji powoduje, że otrzymany zysk (wykrycie bł˛edu) w stosunku
do kosztu (zwi˛ekszenie rozmiaru aplikacji oraz czasu wykonania) jest nieakceptowalny.
Poniżej zaproponowano oryginalna˛ metod˛e, w której poprzez pomiar określonych
parametrów i obserwacj˛e zachowania asercji dla pewnego zestawu testów, dokonywana jest ich
ocena oraz wybór takiego podzbioru, który w optymalny sposób spełni określone kryteria. Dla
potrzeb metody zaproponowane zostały różne miary oceny asercji, które uwzgl˛edniaja˛ mi˛edzy
innymi ich koszt statyczny, dynamiczny, skuteczność oraz nieskuteczność. Przedstawiony
został ogólny sposób formułowania zadania programowania liniowego, którego rozwiazanie
˛
wyznacza podzbiór asercji najlepiej spełniajacy
˛ wyznaczone wymagania. Zaprezentowane
zostały również charakterystyki miar pozwalajacych
˛
w intuicyjny sposób określić skuteczności
oraz nieskuteczności asercji.
3.1. Definicje podstawowych poj˛eć
Poniżej określone zostało znaczenie podstawowych poj˛eć używanych w niniejszym
rozdziale.
Programem nazywamy całość systemu (na przykład wiele współdziałajacych
˛
aplikacji),
samodzielny program jak i również jego fragment, którym może być wydzielony moduł, klasa
33
czy kilka wybranych metod lub funkcji. Programem może być zarówno sam algorytm jak i jego
konkretna implementacja. W szczególności, w badanym systemie można wyznaczyć wiele
programów, które b˛eda˛ analizowane niezależnie od siebie. Badany program zawiera pewien
zbiór składajacy
˛ si˛e z n asercji. W dalszej cz˛eści rozdziału dla oznaczenia konkretnej i-tej
asercji ze zbioru n asercji stosowany b˛edzie identyfikator i, i = 1 . . . n.
Pod poj˛eciem asercji rozumie si˛e predykat zwiazany
˛
z programem dzi˛eki któremu możliwe
jest sprawdzenie stanu wybranych zmiennych i wywołanie określonej reakcji w przypadku
jego niespełnienia. Zmiennymi moga˛ być zarówno zmienne wyst˛epujace
˛ w programie jak
i parametry środowiska, w którym jest on wykonywany. Predykat ten nie wpływa na inne
asercje oraz na działanie programu. Reakcja˛ w przypadku niespełnienia asercji może być na
przykład natychmiastowe przerwanie działania programu, wyświetlenie komunikatu na ekranie
informujacego
˛
o jej naruszeniu, zgłoszenie wyjatku
˛ lub wywołanie akcji naprawczej.
Intencja˛ powyższej definicji poj˛ecia asercji jest możliwe szerokie obj˛ecie nia˛ wszelkich
struktur programowych, które sprawdzaja˛ stan programu i środowisko jego wykonania za
pomoca˛ określonego predykatu. Celem takiego sprawdzenia jest podniesienie wiarygodności
oprogramowania wskutek możliwości mi˛edzy innymi detekcji, raportowania i lokalizacji
bł˛edów przez takie struktury.
Proces, który podczas działania programu określa, czy asercja jest prawdziwa lub fałszywa
przy pewnym stanie zmiennych nazywamy sprawdzeniem asercji. Jego efektem może być
naruszenie lub spełnienie sprawdzanej asercji. Naruszeniem asercji lub inaczej niespełnieniem
asercji określamy sytuacj˛e, w której sprawdzony predykat jest fałszywy. Spełnieniem asercji
lub inaczej nienaruszeniem asercji określamy sytuacj˛e, w której sprawdzony predykat jest
prawdziwy. Zakłada si˛e, że spełnienie asercji nie ma wpływu na działanie programu oraz na
proces sprawdzania innych asercji.
Skutkiem działania asercji nazywamy akcje podj˛ete wskutek naruszenia asercji. Akcjami
podj˛etymi wskutek naruszenia asercji sa˛ na przykład: natychmiastowe przerwanie programu,
podj˛ecie działań przywracajacych
˛
jego poprawne działanie lub wygenerowanie raportu o detekcji bł˛edu. Naruszenie asercji może wpływać na działanie programu oraz działanie innych
asercji.
Testem nazywamy wykonanie programu, któremu przyporzadkowujemy
˛
wynik testu.
Wynik testu opisuje status wykonania programu (na przykład poprawny, niepoprawny, przerwany przez asercj˛e, przerwany przez system operacyjny) określony przez niezależna˛ metod˛e
oceny przebiegu i efektu jego wykonania.
Każdemu z możliwych statusów wykonania
programu przyporzadkowujemy
˛
pewna˛ wartość e z określonego dla programu zbioru E =
{e1 , e2 , . . . , ek }, która˛ nazywamy wynikiem testu.
Zbiór testów nazywamy eksperymentem.
34
3.2. Parametry asercji
Podczas każdego z przeprowadzanych testów możliwe jest przyporzadkowanie
˛
asercjom
w programie pewnych ich własności, które można określić w wymierny i jednoznaczny sposób.
Nazywane b˛eda˛ one parametrami asercji. Umożliwia˛ porównanie asercji pomi˛edzy soba˛
z uwzgl˛ednieniem wybranych kryteriów, które b˛eda˛ charakteryzowały dany parametr asercji.
Poniżej zdefiniowane zostały parametry dla asercji jakie moga˛ zostać wykorzystane
w trakcie procesu selekcji asercji, którego algorytm omówiono w dalszej cz˛eści rozdziału.
Przedstawiony został sposób wyznaczania proponowanych parametrów oraz możliwe ich
zastosowania. Kluczowymi parametrami dla metody selekcji asercji sa˛ ich charakterystyki
oraz profile omówione w punkcie 3.2.9, a także wielkości wyrażajace
˛ skuteczność oraz
nieskuteczność asercji dla danego eksperymentu przedstawione w punkcie 3.2.10.
3.2.1. Aktywność asercji
Metoda selekcji asercji służy do wyznaczenia pewnego podzbioru asercji spośród wszystkich wyst˛epujacych
˛
w programie, których wybrane parametry b˛eda˛ spełniać określone wymagania. Konieczne jest wi˛ec zdefiniowanie parametru, który b˛edzie określał czy asercja należy
do wyznaczonego podzbioru czy znajduje si˛e poza nim. Taki parametr nazwiemy aktywnościa˛
asercji.
Definicja 3.2.1. Parametr vi określa aktywność i-tej asercji. Jeżeli nie jest dopuszczone
sprawdzenie asercji podczas działania programu to vi = 0 i asercj˛e taka˛ nazywamy nieaktywna.˛
Jeżeli dopuszczone jest sprawdzanie asercji podczas wykonywania programu i podejmowane
jest adekwatne działanie w przypadku jej naruszenia to vi = 1 i asercj˛e taka˛ nazywamy aktywna.˛
Parametr określajacy
˛ aktywność asercji może zostać wyznaczony manualnie przez programist˛e, który arbitralnie zdecyduje o aktywności lub nieaktywności wybranej asercji. Wartość
tego parametru jest również wyznaczana jako wynik działania algorytmu selekcji asercji.
Wartość aktywności asercji nie jest wyznaczana na podstawie lub dla konkretnego testu programu, dlatego przyjmuje si˛e, że obowiazuje
˛
ona dla całego przeprowadzanego eksperymentu.
Aktywność asercji nie jest bezpośrednio zwiazana
˛
z faktem sprawdzenia tej asercji w danym
teście programu. W szczególności może zaistnieć sytuacja, kiedy wybrana asercja jest aktywna,
ale nie jest sprawdzona podczas pewnego testu programu, ponieważ nie została wykonana
funkcja w programie, gdzie dana asercja zostałaby sprawdzona.
3.2.2. Liczba sprawdzeń asercji
Podczas wykonania programu zawarte w nim asercje moga˛ nie zostać sprawdzone, być
sprawdzone jednokrotnie lub wielokrotnie, jeśli znajduja˛ si˛e w p˛etli lub gdy pewna funkcja
35
programu jest wykonywana wiele razy. Parametr, który opisuje t˛e ich własność nazwiemy
liczba˛ sprawdzeń asercji.
Definicja 3.2.2. Liczba sprawdzeń i-tej asercji oznaczona symbolem qi,t określa jak wiele razy
asercja w programie była sprawdzana w danym teście t.
Wartość
tego
parametru
może
być
wyznaczona
automatycznie
dla
każdego
z przeprowadzanych testów poprzez zastosowanie odpowiedniej aplikacji monitorujacej
˛
wykonanie programu i zliczajacej
˛
liczb˛e wykonań instrukcji realizujacych
˛
konkretne
asercje. Jeśli każda z asercji rejestruje fakt swojego sprawdzenia poprzez odpowiedni wpis
w dzienniku aplikacji liczb˛e sprawdzeń można wyznaczyć poprzez zliczenie liczby wpisów
charakterystycznych dla każdej z asercji po zakończeniu wykonania programu. Wyznaczenie
wartości tego parametru w sposób manualny wia˛że si˛e ze zliczeniem przez programist˛e
w trakcie śledzenia aplikacji liczby sprawdzeń danej asercji. Jest to proces czasochłonny
i z uwagi na możliwość popełnienia licznych bł˛edów nie powinien być stosowany.
Liczba sprawdzeń danej asercji jest wyznaczana dla konkretnego testu programu i może
być różna w zależności od sposobu zachowania aplikacji w ich trakcie. Jeżeli parametr ten
ma być wykorzystany do obliczeń w algorytmie selekcji asercji należy wybrać konkretna˛ jego
wartość. W szczególności może to być wartość wyznaczona podczas wybranego testu programu
b˛edacego
˛
testem wzorcowym. Dla zbioru wartości tego parametru wyznaczonych poprzez
przeprowadzenie serii testów możliwe jest również wyznaczenie wybranej statystycznej własności takiej jak:
— wartość maksymalna – wybrana zostaje maksymalna wartość liczby sprawdzeń asercji,
— wartość minimalna – wybrana zostaje minimalna wartość liczby sprawdzeń asercji,
— wartość skumulowana – obliczona zostaje wartość b˛edaca
˛ suma˛ liczby sprawdzeń asercji,
— wartość średnia – obliczona zostaje średnia wartość liczby sprawdzeń asercji,
— mediana – obliczona zostaje wartość środkowa liczby sprawdzeń asercji.
3.2.3. Koszt statyczny asercji
Każda z asercji wprowadzonych do programu wpływa na wielkość jego kodu źródłowego
lub wynikowego otrzymanego w procesie kompilacji. Przyrost rozmiaru aplikacji na skutek
wprowadzenia danej asercji nazwiemy jej kosztem statycznym.
Definicja 3.2.3. Koszt statyczny i-tej asercji oznaczony symbolem si,t określa przyrost
wielkości kodu statycznego programu w danym teście t na skutek wprowadzenia do niego
asercji.
Koszt statyczny asercji wyznacza narzut statyczny kodu powstały w wyniku wprowadzenia
asercji do programu. Może być wyrażony na przykład poprzez liczb˛e instrukcji maszynowych,
liczb˛e dodatkowych bajtów kodu wynikowego programu, liczb˛e użytych operatorów relacji
36
oraz logicznych w asercji czy też liczb˛e różnych zmiennych oraz stałych wyst˛epujacych
˛
w danej asercji. Porównanie konkretnych wartości kosztu statycznego różnych asercji w danym
programie możliwe jest w przypadku, kiedy do ich wyrażenia użyto tej samej miary, która może
być jedna˛ z wyżej zaproponowanych.
Koszt statyczny asercji jest wyznaczany dla konkretnego testu programu i może być inny
w zależności od mi˛edzy innymi zastosowanego kompilatora lub opcji kompilacji użytych podczas przygotowania aplikacji dla danego testu. Jako wartość wykorzystywana˛ na etapie selekcji
asercji można przyjać
˛ wartość otrzymana˛ na podstawie testu wzorcowego lub wyznaczona˛
jako jedna˛ z jego statystycznych własności, podobnie jak dla parametru określajacego
˛
liczb˛e
sprawdzeń asercji (punkt 3.2.2).
Wartość kosztu statycznego asercji może być określana manualnie przez programist˛e lub
wyliczana automatycznie przez preprocesor lub kompilator czy inne przygotowane do tego
celu narz˛edzie. Jego sposób działania uzależniony jest od wybranej miary wartości kosztu
statycznego, która wpływa na stosowana˛ metod˛e pomiaru. Przykładowo, jeśli przyjać
˛ za miar˛e
liczb˛e użytych operatorów relacji lub logicznych w asercji, zastosować można oprogramowanie
operujace
˛ na wyrażeniach regularnych.
3.2.4. Koszt dynamiczny asercji
Podczas wykonania programu każda ze sprawdzanych w nim asercji wpływa na czas jego
wykonania lub na podniesienie zużycia innych zasobów przydzielanych w trakcie działania
aplikacji. Przyrost zużycia tych zasobów na skutek wprowadzenia danej asercji do programu
nazwiemy kosztem dynamicznym asercji.
Definicja 3.2.4. Koszt dynamiczny i-tej asercji oznaczony symbolem di,t określa ilość zasobów
jakie zostały poświ˛econe na jednostkowe sprawdzenie asercji w programie w danym teście t.
Celem kosztu dynamicznego jest wyrażenie narzutu dynamicznego kodu, który powstaje
w wyniku wprowadzenia asercji do programu. Jeżeli dana asercja wyst˛epuje w p˛etli programu
lub funkcja w jakiej została użyta wywoływana jest wielokrotnie to celowe jest wprowadzenie
całkowitego kosztu dynamicznego asercji. B˛edzie on odzwierciedlał sumaryczny koszt jaki
został poświ˛econy na jej sprawdzanie podczas całego testu.
Definicja 3.2.5. Całkowity koszt dynamiczny i-tej asercji w programie dla danego testu t jest
wyznaczony jako Di,t = qi,t ∗ di,t .
Miara˛ kosztu dynamicznego asercji i całkowitego kosztu dynamicznego asercji może
być na przykład liczba wykonanych instrukcji maszynowych podczas sprawdzenia asercji,
czas poświ˛econy na sprawdzenie asercji lub rozmiar pami˛eci jaka˛ należy przydzielić by
zrealizować t˛e operacj˛e.
Jako wartość wykorzystywana˛ na etapie selekcji asercji można
przyjać
˛ wartość otrzymana˛ na podstawie wybranego testu programu lub wyznaczona˛ jako jedna˛
37
z jego statystycznych wielkości, podobnie jak dla parametru określajacego
˛
liczb˛e sprawdzeń
asercji. Może zostać ona wyznaczona manualnie przez programist˛e lub zmierzona przez
oprogramowanie monitorujace
˛ wykonanie aplikacji i dokonujace
˛ pomiaru na przykład czasu
poświ˛econego na sprawdzenie danego warunku.
3.2.5. Koszt położenia asercji
Od momentu uruchomienia programu do pierwszego sprawdzenia wybranej asercji upływa
pewien czas lub wykonywana jest pewna liczba instrukcji. Wartość ta określa koszt położenia
asercji w programie.
Definicja 3.2.6. Koszt położenia i-tej asercji oznaczony symbolem zi,t określa ilość zasobów
jaka zostaje wykorzystana do momentu pierwszego sprawdzenia tej asercji w programie dla
danego testu t.
Miara˛ dla położenia asercji może być na przykład liczba wykonanych instrukcji lub czas
od poczatku
˛
działania programu do pierwszego sprawdzenia asercji lub narzut zwiazany
˛
z położeniem asercji w określonym module programu. Sposób wyznaczenia i wykorzystania
tego parametru jest analogiczny do omówionego w punkcie 3.2.4 kosztu dynamicznego asercji.
3.2.6. Czas detekcji bł˛edu
Od chwili wprowadzenia lub wystapienia
˛
bł˛edu w programie do momentu jego wykrycia
przez asercj˛e upływa pewien czas, który nazywany jest czasem detekcji bł˛edu. Jego wartość
może być istotnym kryterium w metodzie selekcji asercji kiedy ważne b˛edzie wybranie takich
asercji, dla których czas detekcji bł˛edu b˛edzie jak najmniejszy.
Definicja 3.2.7. Czas detekcji bł˛edu dla i-tej asercji oznaczony symbolem hi,t określa okres jaki
upłynał
˛ od uaktywnienia bł˛edu w programie do momentu wykrycia go przez asercj˛e w danym
teście t.
Miara˛ czasu detekcji bł˛edu może być na przykład liczba wykonanych instrukcji lub czas
jaki upłynał
˛ pomi˛edzy momentem wystapienia
˛
bł˛edu i jego wykryciem przez asercj˛e. Jeżeli
w danym teście nie wystapił
˛ żaden bład
˛ lub asercja go nie wykryła wartość tego parametru
pozostaje dla niej nieokreślona. Ponieważ parametr ten jest wyznaczany dla wielu testów
programu to jako wartość wykorzystywana˛ na etapie selekcji asercji należy przyjać
˛ jedna˛
z jego statystycznych wielkości, podobnie jak dla parametru określajacego
˛
liczb˛e sprawdzeń
asercji. Wartość tego parametru powinna zostać wyznaczona automatycznie przez system
wprowadzania bł˛edów do badanego programu. Manualna metoda wyznaczania tej wartości
może być bardzo pracochłonna dla dużej liczby przeprowadzanych testów ponieważ wia˛że si˛e
ze żmudnym procesem śledzenia wykonania programu.
38
3.2.7. Zaufanie do asercji
Niektóre z systemów dynamicznego wykrywania asercji, na przykład Daikon [29], wyznaczaja˛ dla znalezionych warunków pewna˛ wartość określajac
˛ a˛ zaufanie do asercji. Parametr
ten jest propozycja˛ określenia w wymierny sposób stopnia poprawności znalezionego warunku,
przy czym pod poj˛eciem poprawności rozumie si˛e tu najcz˛eściej prawdopodobieństwo braku
detekcji bł˛edu przez asercj˛e, jeśli on nie wystapił
˛ (prawdopodobieństwo braku fałszywego
alarmu) albo prawdopodobieństwo detekcji bł˛edu przez asercj˛e, jeśli on wystapił
˛ (prawdopodobieństwo prawidłowego alarmu). Innymi słowy im wi˛eksze zaufanie do asercji tym mniejsze
prawdopodobieństwo, że zostanie ona naruszona nie z powodu zaistniałego bł˛edu w programie,
ale z powodu jej niedoskonałości b˛edacej
˛ skutkiem stosowanej metody wykrywania asercji
(brak fałszywego alarmu) albo tym wi˛eksze prawdopodobieństwo, że zostanie ona naruszona
z powodu zaistniałego bł˛edu w programie (prawidłowy alarm).
Definicja 3.2.8. Zaufanie do i-tej asercji oznaczone jest symbolem ci i wyraża stopień
poprawności wykrytej asercji.
Przykładowe metody wyznaczania wartości zaufania do asercji zostały przedstawione
w punkcie 2.3.
Na etapie realizacji algorytmu selekcji asercji parametr ten może być
wykorzystany poprzez zdefiniowanie ograniczenia dla minimalnego zaufania jakim maja˛
charakteryzować si˛e wybrane asercje.
3.2.8. Atrybuty asercji
Dla asercji w badanej aplikacji może zajść konieczność przyporzadkowania
˛
pewnych
własności, które moga˛ wyrażać ich interesujace
˛ cechy.
Ten ogólny parametr nazwiemy
atrybutami asercji. Określone cechy moga˛ zostać wyrażone na różne sposoby (opis, konkretne
wartości). Zakłada si˛e, że ich liczba jest skończona. Aby zapewnić uniwersalne znaczenie
tego parametru zdefiniowany on zostanie w uogólniony sposób pozwalajacy
˛ na późniejsze
doprecyzowanie.
Definicja 3.2.9. Atrybutami i-tej asercji nazywamy podzbiór elementów z określonego dla
programu zbioru R = {r1 , r2 , . . . , rm } zawierajacego
˛
wszystkie możliwe atrybuty jakie można
przyporzadkować
˛
asercjom.
W zależności od wybranych cech asercji, jakie maja˛ zostać uwzgl˛ednione, ich atrybuty
moga˛ być zwiazane
˛
z:
— możliwościa˛ poprawienia bł˛edu przez asercj˛e – elementy zbioru R moga˛ określać czy
wskutek naruszenia danej asercji istnieje możliwość przywrócenia poprawnego stanu
programu (poprawienia bł˛edu przez asercj˛e) czy też takiej możliwości nie ma; każdej
39
asercji w programie, w zależności od cechy jaka˛ si˛e charakteryzuje, zwiazanej
˛
z możliwościa˛ poprawienia zaistniałego bł˛edu, przyporzadkowany
˛
zostaje podzbiór zawierajacy
˛
adekwatny element ze zbioru R,
— budowa˛ asercji – elementy zbioru R moga˛ na przykład określać czy jest to asercja, której
warunek wyrażony jest z użyciem określonych operacji arytmetycznych na zmiennych
programu (dodawanie, odejmowanie, mnożenie, dzielenie zmiennych),
— sposobem wprowadzenia asercji do programu – elementy zbioru R moga˛ określać czy jest
to asercja wykryta automatycznie lub zaimplementowana w programie przez programist˛e,
— efektami działania asercji – elementy zbioru R moga˛ określać czy wskutek naruszenia danej
asercji program zostanie przerwany, zaraportuje informacj˛e o bł˛edzie czy też podejmie
prób˛e jego naprawy,
— przynależnościa˛ asercji do danej metody lub modułu w programie – elementy zbioru R
zwiazane
˛
sa˛ z położeniem asercji w programie, może to być na przykład wykaz jego
modułów,
— rodzajem wykrywanego bł˛edu przez asercj˛e – elementami zbioru R moga˛ być różne
klasy bł˛edów, na przykład obliczeniowe, logiczne, mutacyjne, funkcjonalne, czasowe,
wydajnościowe, bł˛edy w danych lub sprz˛etowe,
— stopniem dotkliwości wykrywanego bł˛edu przez asercj˛e – elementami zbioru R moga˛ być
różne stopnie dotkliwości wykrytego bł˛edu, na przykład pomijalny, łagodny, krytyczny,
katastroficzny,
— innymi cechami asercji takimi jak jej niski lub wysoki koszt statyczny czy też niski lub
wysoki koszt dynamiczny.
Atrybuty asercji moga˛ być określone manualnie przez eksperta lub automatycznie przez
system wykrywania asercji lub na etapie przeprowadzania testów w metodzie selekcji asercji
(na przykład rodzaj wykrytego bł˛edu przez asercj˛e lub stopień jego dotkliwości). W programie można zdefiniować kilka niezależnych zbiorów atrybutów asercji (różnych zbiorów
R) zwiazanych
˛
z różnymi cechami asercji. Idea˛ tego parametru jest umożliwienie wyrażenia
pewnych specyficznych własności asercji, w szczególności charakterystycznych jedynie dla
badanej aplikacji.
Atrybuty asercji moga˛ być użyte jako jedna ze strategii selekcji asercji. Przykładowo, zbiór
wybieranych asercji może zostać zaw˛eżony jedynie do asercji, które po wykryciu bł˛edu moga˛
przywrócić poprawny stan wykonywanego programu, przynależa˛ do określonego jego modułu
lub stopień dotkliwości bł˛edów przez nie wykrywanych jest co najmniej krytyczny.
40
3.2.9. Charakterystyki i profile asercji
Po każdym teście badanego programu dla każdej z asercji można określić właściwości, które
opisuja˛ jej zachowanie. Zostały one przedstawione w tabeli 3.1. Właściwości asercji określane
sa˛ przy założeniu, że jej naruszenie nie powoduje żadnych skutków działania, które wpływaja˛
na przebieg wykonania programu. Należa˛ do nich na przykład zatrzymanie programu, podj˛ecie
działań naprawczych lub maskujacych
˛
zaistniały bład.
˛ Oznacza to, że wszystkie asercje sa˛
sprawdzane, ale bez wzgl˛edu na to czy zostały naruszone czy spełnione nie podejmuje si˛e
żadnych dodatkowych działań wpływajacych
˛
na przebieg działania aplikacji. Celem takiego
post˛epowania jest rejestracja właściwości dla wszystkich asercji bez ewentualnego wpływu ich
skutków działania na inne asercje.
Przykładowo, w przypadku poprawnego wykonania programu, sprawdzane asercje
w badanym programie powinny zachowywać si˛e zgodnie z właściwościa˛ przedstawiona˛
w wierszu oznaczonym identyfikatorem b w tabeli 3.1. Wynika to z faktu, iż żadna z asercji nie
powinna zostać naruszona podczas przeprowadzania tego rodzaju testu.
a
Asercja jako pierwsza, w zbiorze wszystkich asercji w programie, została
naruszona podczas wykonania danego testu. Oznacza to, że dana asercja jako
pierwsza w określonym teście została naruszona bez wzgl˛edu na to jak wiele
razy ta lub inne asercje zostały wcześniej sprawdzone bez naruszenia oraz jakie
sa˛ wyniki sprawdzeń tej lub innej asercji po jej pierwszym naruszeniu. Asercja,
która jako pierwsza została naruszona podczas danego testu, potencjalnie jako
pierwsza wykryła wprowadzony w nim bład.
˛
b Asercja została sprawdzona i jest spełniona przy założeniu, że żadna ze
sprawdzonych dotychczas asercji nie została naruszona podczas wykonania
danego testu. Oznacza to, że żadna z dotychczas sprawdzonych asercji
w określonym teście nie została naruszona. Jeśli w danym teście został
wprowadzony bład
˛ to nie został on wykryty przez żadna˛ z asercji.
c
Asercja została sprawdzona i naruszona przy założeniu, że co najmniej jedna
z asercji została już naruszona podczas wykonania testu. Oznacza to, że
sprawdzona asercja jest kolejna˛ z asercji, których sprawdzenie skończyło si˛e
naruszeniem. Zakłada si˛e, że mogła być to również ta sama asercja przy jej
kolejnym sprawdzeniu podczas wykonywania danego testu. Asercja, która
jako kolejna została naruszona podczas danego testu, potencjalnie wykrywa
wprowadzony w nim bład,
˛ który został już wykryty przez nia˛ sama˛ albo inna˛
z asercji.
d Asercja została sprawdzona i nie została naruszona przy założeniu, że co
najmniej jedna z asercji została już naruszona podczas wykonania testu.
Zakłada si˛e, że mogła być to również ta sama asercja przy jej kolejnym
sprawdzeniu podczas wykonywania danego testu. Taka asercja potencjalnie nie
wykrywa w danym teście bł˛edu, jeśli został on wprowadzony.
Tabela 3.1. Właściwości asercji określane dla danego testu programu
41
Przy tak zdefiniowanych właściwościach możliwe jest przyporzadkowanie
˛
do każdej asercji
w programie dowolnego ich podzbioru.
Podzbiór ten nazwiemy charakterystyka˛ asercji.
W szczególności, jeśli asercja nie zostanie sprawdzona podczas testu programu, żadna z przedstawionych właściwości nie b˛edzie jej przyporzadkowana.
˛
Oznacza to, że zbiór właściwości tej
asercji b˛edzie zbiorem pustym.
Definicja 3.2.10. Charakterystyka˛ asercji dla wykonanego testu programu nazywamy
określona˛ na jego podstawie przynależność asercji do pewnego podzbioru jej właściwości.
Możliwe charakterystyki asercji zebrano w tabeli 3.2.
Wyznaczone one zostały jako
wszystkie n-elementowe kombinacje bez powtórzeń zbioru {a, b, c, d} złożonego z czterech
P
właściwości asercji, gdzie n = 0 . . . 4. Ich liczba jest równa 4n=0 n4 = 24 = 16. Oznaczenia
właściwości w tabeli 3.2 dla danych charakterystyk sa˛ zgodne z przyj˛etymi w tabeli 3.1. Kropka˛
oznaczono przynależność danej właściwości do asercji. Po każdym teście programu dla każdej
z asercji można jednoznacznie przyporzadkować
˛
jedna˛ z możliwych szesnastu charakterystyk.
Podczas przeprowadzania eksperymentu wykonywanych może być wiele testów.
Dla
każdego z nich przyporzadkowywane
˛
sa˛ pewne charakterystyki dla wszystkich asercji w programie. Interesujac
˛ a˛ informacja˛ może być przynależność nie jednej wybranej charakterystyki
do asercji, ale pewnego ich podzbioru, które można zaobserwować dla danej asercji w trakcie
przeprowadzania eksperymentu. Podzbiór taki nazwiemy profilem asercji.
Charakterystyki
k
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Właściwości
(tabela 3.1)
a
b
c
d
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
A
B
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
C
Profile
(tabela 3.3)
D E
F
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
I
•
•
•
Tabela 3.2. Charakterystyki i wybrane profile asercji
42
H
•
•
•
•
•
•
•
•
G
•
•
•
•
•
•
•
•
Definicja 3.2.11. Profilem asercji nazywamy określony zbiór wybranych charakterystyk asercji.
Poj˛ecie profilu asercji umożliwia uproszczenie sposobu opisu zbioru charakterystyk danej
asercji. Dzi˛eki niemu można uniknać
˛ konieczności ciagłego
˛
przedstawiania jej wszystkich
interesujacych
˛
charakterystyk, które moga˛ pojawić si˛e w eksperymencie.
W kolumnach tabeli 3.2 oznaczonych literami od A do I wyróżniono dziewi˛eć przykładowych profili asercji poprzez oznaczenie znakiem • przynależności danej charakterystyki asercji
do określonego profilu. Przedstawione profile opisuja˛ najcz˛eściej spotykany lub pożadany
˛
charakter danej asercji. Ich znaczenie zostało opisane w tabeli 3.3. Zastosowano w niej
oznaczenia profili odpowiadajace
˛ identyfikatorom użytym w tabeli 3.2. Liczba wszystkich
możliwych profili asercji odpowiada liczbie wszystkich n-elementowych kombinacji bez
powtórzeń zbioru złożonego z szesnastu charakterystyk asercji, gdzie n = 0 . . . 16. Jest ona
P
16
16
= 65536.
równa 16
n=0 n = 2
Poj˛ecie profilu asercji umożliwia określenie sposobu jej zachowania w przeprowadzonym
teście. Po wybraniu pewnego profilu i przeprowadzeniu testu programu możliwe jest określenie
dla każdej z asercji czy spełniła lub nie spełniła ona jego warunki to jest czy jej charakterystyka
w danym teście należała do wybranych, oznaczonych znakiem • w tabeli 3.2, charakterystyk
dla danego profilu. Przyporzadkowanie
˛
to nazwiemy przynależnościa˛ asercji do wybranego
profilu w teście.
Definicja 3.2.12. Przynależność i-tej asercji w danym teście t do wybranego profilu określa
funkcja p(i, t). Przyjmuje ona wartość 1 jeżeli asercja programu należy do wybranego profilu.
W przeciwnym wypadku wartość tej funkcji wynosi 0.
Powyższa definicja funkcji określajacej
˛
przynależność asercji do wybranego profilu
umożliwi zdefiniowanie poj˛eć skuteczności i nieskuteczności asercji.
3.2.10. Skuteczność i nieskuteczność asercji
Po wprowadzeniu asercji do programu może zajść konieczność selekcji tych z nich, które
charakteryzuja˛ si˛e najwyższym lub najniższym poziomem detekcji bł˛edów wprowadzanych
do programu w przygotowanym zestawie testów. Zasadne jest zaproponowanie miar, które
pozwoliłyby wartościować asercje wzgl˛edem opisanego kryterium.
Skuteczność i nieskuteczność asercji dla wykonanej serii uruchomień programu (testów) T
opisuja˛ w wymierny sposób zachowania asercji według wybranego profilu. Intuicyjnie celem
tych miar jest wyrażenie efektywności w detekcji nieprawidłowego zachowania programu
przez asercje. Skuteczność i nieskuteczność asercji sa˛ parametrami wyznaczanymi dla danego
eksperymentu i moga˛ różnić si˛e dla różnych eksperymentów.
43
A
Asercja została sprawdzona. W trakcie wykonania programu osiagni˛
˛ eto takie
jego miejsce, w którym doszło do określenia czy dana asercja została spełniona
lub naruszona (doszło do sprawdzenia danej asercji). Profil ten opisuje asercje,
które zostały użyte podczas uruchomienia programu.
B
Asercja została sprawdzona przed pierwszym naruszeniem innej lub tej samej
asercji. Profil ten opisuje asercje, które nie wykryły wprowadzonego bł˛edu,
jeśli został on wprowadzony do badanego programu przed ich sprawdzeniem.
C
Asercja została sprawdzona po pierwszym naruszeniu innej lub tej samej
asercji. Profil ten opisuje asercje, które zostały użyte po wykryciu bł˛edu przez
dowolna˛ z asercji programu bez wzgl˛edu na to, jakim wynikiem skończyło si˛e
ich sprawdzenie.
D
Asercja została sprawdzona i została naruszona jako pierwsza asercja. Podczas wykonania programu osiagni˛
˛ eto takie jego miejsce, w którym doszło
do sprawdzenia danej asercji i została ona naruszona jako pierwsza asercja.
Asercja ta mogła być już wcześniej sprawdzana, jednak nie była naruszona.
Profil ten opisuje asercje, które potencjalnie jako pierwsze wykryły bład
˛
w badanym programie.
E
Asercja została sprawdzona i została naruszona. Podczas wykonania programu
osiagni˛
˛ eto takie jego miejsce, w którym doszło do sprawdzenia danej asercji
i nie została ona spełniona bez wzgl˛edu na to, jakim wynikiem kończyły si˛e
sprawdzenia tej lub innych asercji w badanym programie. Profil ten opisuje
asercje, które potencjalnie wykrywaja˛ bład
˛ w badanym programie.
F
Asercja została sprawdzona, została naruszona i nie zaobserwowano innych jej
sprawdzeń bez naruszenia. Profil ten opisuje asercje, które stale sa˛ naruszane
podczas wykonania badanego programu.
G Asercja została sprawdzona i nie została naruszona. W trakcie wykonania
programu osiagni˛
˛ eto takie jego miejsce, w którym doszło do sprawdzenia danej
asercji i nie została ona naruszona bez wzgl˛edu na to, jakim wynikiem kończyły
si˛e sprawdzenia tej lub innych asercji w badanym programie. Profil ten opisuje
asercje, których co najmniej jedno sprawdzenie nie skończyło si˛e naruszeniem
podczas wykonania badanego programu.
H Asercja została sprawdzona przed i po pierwszym naruszeniu innej lub tej
samej asercji. Podczas wykonania programu osiagni˛
˛ eto takie jego miejsce,
w którym doszło do sprawdzenia wybranej asercji zarówno przed jak i po
pierwszym naruszeniu dowolnej z asercji programu.
I
Asercja została sprawdzona i po pierwszym naruszeniu innej lub tej samej
asercji zgłasza wyłacznie
˛
naruszenia. W trakcie wykonania programu dana
asercja zgłasza wyłacznie
˛
naruszenia pod warunkiem, że doszło do pierwszego
naruszenia tej lub innej asercji w badanym programie. Profil ten opisuje asercje, które po potencjalnym wykryciu bł˛edu przez dowolna˛ z asercji badanego
programu stale zgłaszaja˛ naruszenie.
Tabela 3.3. Opis wybranych profili asercji
44
Uwzgl˛ednienie
wybranych
testów
przy
wyliczaniu
wartości
skuteczności
lub
nieskuteczności asercji dla danego eksperymentu dla każdego ze zdefiniowanych wyników
testu programu b˛edzie możliwe po przyporzadkowaniu
˛
liczby określajacej
˛
jego wag˛e.
Umożliwia ona wartościowanie zebranych informacji o asercjach otrzymanych w skutek testu
t programu zakończonego z wynikiem e.
Definicja 3.2.13. Waga˛ dla danego wyniku testu e nazywamy wartość funkcji w(e) ∈ R, e ∈ E.
Konkretna postać funkcji w(e) powinna zostać zdefiniowana przez eksperta. Dodatnie
wartości funkcji wag b˛eda˛ wpływać na wzrost wartości danej miary, wartości ujemne b˛eda˛
powodować jej spadek. W szczególności umożliwiaja˛ pomini˛ecie testów o danym wyniku e
jeśli w(e) = 0.
Skuteczność bezwzgl˛edna i wzgl˛edna asercji
Miara skuteczności bezwzgl˛ednej wartościuje przynależność asercji do wybranego profilu
dla zbioru testów według określonej funkcji wag. Jest ona wyliczana jedynie z uwzgl˛ednieniem
wyników otrzymanych dla danej asercji.
Definicja 3.2.14. Skuteczność bezwzgl˛edna i-tej asercji w programie jest określana jako:
X
w(et ) ∗ p(i, t)
(3.1)
t∈T
gdzie T jest zbiorem przeprowadzanych testów, et wynikiem testu t, w(et ) określa wartość wagi
dla wyniku testu et , a p(i, t) jest wartościa˛ funkcji przynależności i-tej asercji do wybranego
profilu w teście t.
Miara skuteczności wzgl˛ednej wartościuje przynależność asercji do wybranego profilu dla
zbioru testów według określonej funkcji wag w uzależnieniu od liczby innych aktywnych
asercji przynależacych
˛
do tego samego profilu.
Definicja 3.2.15. Jeżeli ∃t ∈ T dla którego p(i, t) 6= 0 to skuteczność wzgl˛edna i-tej asercji
w programie jest określana jako:
X
w(et ) ∗
t∈T,p(i,t)6=0
p(i, t)
n
X
(3.2)
vk ∗ p(k, t)
k=1
gdzie T jest zbiorem przeprowadzanych testów, n liczba˛ asercji w programie, et wynikiem testu
t, w(et ) określa wartość wagi dla wyniku testu et , p(i, t) jest wartościa˛ funkcji przynależności
i-tej asercji do wybranego profilu w teście t, vk określa aktywność k-tej asercji, a p(k, t) jest
wartościa˛ funkcji przynależności k-tej asercji do wybranego profilu w teście t. Jeżeli ∼ ∃t ∈ T
dla którego p(i, t) 6= 0 to skuteczność wzgl˛edna i-tej asercji w programie jest nieokreślona.
45
W szczególności wartości skuteczności wzgl˛ednej i skuteczności bezwzgl˛ednej b˛eda˛ równe,
jeśli dana asercja jest jedyna˛ asercja˛ przynależac
˛ a˛ do wybranego profilu dla całego zbioru testów
o wynikach e dla których w(e) 6= 0.
Nieskuteczność bezwzgl˛edna i wzgl˛edna asercji
Miary nieskuteczności asercji, w przeciwieństwie do miar ich skuteczności, uwzgl˛edniaja˛
brak przynależności asercji do wybranego profilu w teście. Miara nieskuteczności bezwzgl˛ednej wartościuje brak przynależność asercji do wybranego profilu dla zbioru testów według
określonej funkcji wag. Jest ona wyliczana jedynie z uwzgl˛ednieniem wyników otrzymanych
dla danej asercji.
Definicja 3.2.16. Nieskuteczność bezwzgl˛edna i-tej asercji w programie jest określana jako:
X
w(et ) ∗ (1 − p(i, t))
(3.3)
t∈T
gdzie T jest zbiorem przeprowadzanych testów, et wynikiem testu t, w(et ) określa wartość wagi
dla wyniku testu et , a p(i, t) jest wartościa˛ funkcji przynależności i-tej asercji do wybranego
profilu w teście t.
Miara nieskuteczności wzgl˛ednej wartościuje brak przynależność asercji do wybranego
profilu dla zbioru testów według określonej funkcji wag w uzależnieniu od liczby innych
aktywnych asercji nieprzynależacych
˛
do tego samego profilu.
Definicja 3.2.17. Jeżeli ∃t ∈ T dla którego p(i, t) 6= 1 to nieskuteczność wzgl˛edna i-tej asercji
w programie jest określana jako:
X
t∈T,p(i,t)6=1
w(et ) ∗
1 − p(i, t)
n
X
(3.4)
vk ∗ (1 − p(k, t))
k=1
gdzie T jest zbiorem przeprowadzanych testów, n liczba˛ asercji w programie, et wynikiem testu
t, w(et ) określa wartość wagi dla wyniku testu et , p(i, t) jest wartościa˛ funkcji przynależności
i-tej asercji do wybranego profilu w teście t, vk określa aktywność k-tej asercji, a p(k, t) jest
wartościa˛ funkcji przynależności k-tej asercji do wybranego profilu w teście t. Jeżeli ∼ ∃t ∈ T
dla którego p(i, t) 6= 1 to nieskuteczność wzgl˛edna i-tej asercji w programie jest nieokreślona.
Wartości nieskuteczności bezwzgl˛ednej i nieskuteczności wzgl˛ednej b˛eda˛ równe, jeśli dana
asercja jest jedyna˛ asercja˛ nieprzynależac
˛ a˛ do wybranego profilu dla całego zbioru testów
o wynikach e dla których w(e) 6= 0.
46
Charakterystyka miar skuteczności i nieskuteczności
Z zaproponowanych miar służacych
˛
parametryzacji asercji miary skuteczności
i nieskuteczności sa˛ nowatorskimi sposobami ich wartościowania. Dlatego też niezb˛edne
jest przedstawienie charakterystyk tych miar. Pozostałe z nich, takie jak koszt statyczny,
dynamiczny sa˛ intuicyjne i stosowane sa˛ również w innych dziedzinach zwiazanych
˛
z inżynieria˛ oprogramowania.
Rysunek 3.1(a) przedstawia wartość skuteczności bezwzgl˛ednej asercji w zależności od
liczby testów w eksperymencie o pewnym wyniku testu e, dla którego wybrana asercja należy
do określonego profilu. Sporzadzono
˛
go dla trzech funkcji określajacych
˛
wag˛e danego wyniku
testu w obserwowanym profilu, przy czym w1 (e) < w2 (e) < w3 (e), e ∈ E. Wartość
skuteczności bezwzgl˛ednej jest wprost proporcjonalna do liczby testów, w których asercja
należy do określonego profilu. Im wi˛eksza wartość funkcji wag dla wyniku testu e tym
wi˛eksza jest wartość skuteczności bezwzgl˛ednej asercji. Przykładowo, przyporzadkowanie
˛
dużej wartości wagi dla wyniku testu wyrażajacego
˛
nieprawidłowe zachowanie badanego
programu pozwala promować te asercje, które zostały naruszone, jeśli założony profil asercji
obejmuje taki przypadek.
Na rysunku 3.1(b) przedstawiono wartość skuteczności wzgl˛ednej asercji w zależności od
liczby testów w eksperymencie o pewnym wyniku testu e, dla którego wybrana asercja należała
do określonego profilu. Charakterystyki zakładaja˛ stała˛ liczb˛e innych asercji, które dla testów
o wyniku e należały do tego samego profilu co badana asercja. Wykres sporzadzono
˛
dla
trzech funkcji określajacych
˛
wag˛e danego wyniku testu w obserwowanym profilu, przy czym
w1 (e) < w2 (e) < w3 (e), e ∈ E. Wartość skuteczności wzgl˛ednej jest wprost proporcjonalna
do liczby testów, w których asercja należy do określonego profilu. Im wi˛eksza wartość funkcji
wag dla pewnego wyniku testu tym wi˛eksza jest wartość skuteczności wzgl˛ednej. Podobnie jak
w przypadku skuteczności bezwzgl˛ednej przyporzadkowanie
˛
dużej wartości wag umożliwia
promowanie naruszanych asercji dla danego wyniku testu programu.
Rysunek 3.1(c) przedstawia charakterystyk˛e skuteczności wzgl˛ednej asercji w zależności
od liczby testów w eksperymencie o ustalonym wyniku testu e, dla którego wybrana asercja
należała do określonego profilu. Sporzadzony
˛
został dla trzech różnych liczb innych asercji,
które dla testów o wyniku e należa˛ do tego samego profilu co wybrana asercja, dla której
wyznaczamy wartość skuteczności wzgl˛ednej, przy czym dla każdego z testów spełniony jest
P
Pn
Pn
warunek nk=1 vk ∗ p1 (k, t) <
k=1 vk ∗ p2 (k, t) <
k=1 vk ∗ p3 (k, t), gdzie n oznacza
liczb˛e wszystkich asercji. Wszystkie charakterystyki zostały sporzadzone
˛
dla tej samej funkcji
w(e). Wartość skuteczności wzgl˛ednej jest wprost proporcjonalna do liczby testów, w których
asercja należy do określonego profilu. Im wi˛eksza liczba innych asercji, które należa˛ do tego
samego profilu, tym mniejsza jest wartość skuteczności wzgl˛ednej. Takie zachowanie wartości
skuteczności wzgl˛ednej umożliwia promowanie asercji, które na przykład jako jedyne lub jedne
47
(a) skuteczność bezwzgl˛edna (dla różnych funkcji w(e))
(b) skuteczność wzgl˛edna (dla różnych funkcji w(e))
(c) skuteczność wzgl˛edna (dla różnych liczb innych asercji,
które należały do tego samego profilu co badana asercja)
(d) skuteczność wzgl˛edna (dla różnych funkcji w(e))
(e) skuteczność wzgl˛edna (dla różnych liczb innych asercji,
Rysunek 3.1. Charakterystyki skuteczności
48
z niewielu sa˛ naruszane w testach o wyniku opisujacym
˛
nieprawidłowe zachowanie programu.
Przedstawiaja˛ to również kolejne dwie charakterystyki.
Na rysunku 3.1(d) przedstawiono wartość skuteczności wzgl˛ednej asercji w zależności od
liczby innych asercji p, które w danej serii testów o pewnym wyniku testu e, należały do tego
samego profilu co badana asercja. Sporzadzono
˛
go dla trzech funkcji określajacych
˛
wag˛e
danego wyniku testu w obserwowanym profilu, przy czym w1 (e) < w2 (e) < w3 (e), e ∈ E.
Wartość skuteczności wzgl˛ednej jest odwrotnie proporcjonalna do liczby asercji, które należa˛
do tego samego profilu w danym teście co badana asercja. Im wi˛eksza wartość funkcji wag dla
pewnego wyniku testu tym wi˛eksza jest wartość skuteczności wzgl˛ednej.
Rysunek 3.1(e) przedstawia charakterystyk˛e skuteczności wzgl˛ednej asercji w zależności od
liczby innych asercji p, które w danej serii testów o pewnym wyniku testu e, należały do tego
samego profilu co badana asercja. Wszystkie charakterystyki zostały sporzadzone
˛
dla tej samej
funkcji w(e). Wykres przygotowano dla trzech różnych eksperymentów o rosnacej
˛ liczbie
testów o wyniku e. Wartość skuteczności wzgl˛ednej jest odwrotnie proporcjonalna do liczby
asercji, które należa˛ do tego samego profilu w danym teście co badana asercja. Im wi˛eksza
liczba testów w eksperymencie, w których badana asercja należała do wybranego profilu tym
wi˛eksza jest wartość skuteczności wzgl˛ednej.
Rysunek 3.2(a) przedstawia wartość nieskuteczności bezwzgl˛ednej asercji w zależności od
liczby testów w eksperymencie o pewnym wyniku testu e, dla którego wybrana asercja należy
do określonego profilu. Sporzadzony
˛
został dla trzech funkcji określajacych
˛
wag˛e danego
wyniku testu w obserwowanym profilu, przy czym w1 (e) < w2 (e) < w3 (e), e ∈ E. Wartość
nieskuteczności bezwzgl˛ednej jest wprost proporcjonalna do liczby testów, w których asercja
należy do określonego profilu. Im wi˛eksza wartość funkcji wag dla pewnego wyniku testu tym
wi˛eksza jest wartość nieskuteczności bezwzgl˛ednej.
Na rysunku 3.2(b) przedstawiono wartość nieskuteczności wzgl˛ednej asercji w zależności
od liczby testów w eksperymencie o pewnym wyniku testu e, dla którego wybrana asercja
należała do określonego profilu. Charakterystyki zakładaja˛ stała˛ liczb˛e innych asercji, które dla
testów o wyniku e należały do tego samego profilu co badana asercja. Wykres sporzadzono
˛
dla
trzech funkcji określajacych
˛
wag˛e danego wyniku testu w obserwowanym profilu, przy czym
w1 (e) < w2 (e) < w3 (e), e ∈ E. Wartość nieskuteczności wzgl˛ednej jest wprost proporcjonalna
do liczby testów, w których asercja należy do określonego profilu. Im wi˛eksza wartość funkcji
wag dla pewnego wyniku testu tym wi˛eksza jest wartość nieskuteczności wzgl˛ednej.
Rysunek 3.2(c) przedstawia charakterystyk˛e nieskuteczności wzgl˛ednej asercji w zależności
od liczby testów w eksperymencie o ustalonym wyniku testu e, dla którego wybrana asercja
należała do określonego profilu. Sporzadzono
˛
go dla trzech różnych liczb innych asercji,
które dla testów o wyniku e należa˛ do tego samego profilu co wybrana asercja, przy czym
Pn
Pn
Pn
k=1 vk ∗ (1 − p1 (k, t)) <
k=1 vk ∗ (1 − p2 (k, t)) <
k=1 vk ∗ (1 − p3 (k, t)), gdzie n
49
(a) nieskuteczność bezwzgl˛edna (dla różnych funkcji w(e))
(b) nieskuteczność wzgl˛edna (dla różnych funkcji w(e))
(c) nieskuteczność wzgl˛edna (dla różnych liczb innych asercji,
(d) nieskuteczność wzgl˛edna (dla różnych funkcji w(e))
(e) nieskuteczność wzgl˛edna (dla różnych liczb innych asercji,
Rysunek 3.2. Charakterystyki nieskuteczności
50
oznacza liczb˛e wszystkich asercji. Wszystkie charakterystyki zostały sporzadzone
˛
dla tej samej
funkcji w(e). Wartość nieskuteczności wzgl˛ednej jest wprost proporcjonalna do liczby testów,
w których asercja należy do określonego profilu. Im wi˛eksza liczba innych asercji, które należa˛
do tego samego profilu, tym mniejsza jest wartość nieskuteczności wzgl˛ednej.
Na rysunku 3.2(d) przedstawiono wartość nieskuteczności wzgl˛ednej asercji w zależności
od liczby innych asercji p, które w danej serii testów o pewnym wyniku testu e, należały do tego
samego profilu co badana asercja. Sporzadzony
˛
został dla trzech funkcji określajacych
˛
wag˛e
danego wyniku testu w obserwowanym profilu, przy czym w1 (e) < w2 (e) < w3 (e), e ∈ E.
Wartość nieskuteczności wzgl˛ednej jest odwrotnie proporcjonalna do liczby asercji, które
należa˛ do tego samego profilu w danym teście co badana asercja. Im wi˛eksza wartość funkcji
wag dla pewnego wyniku testu tym wi˛eksza jest wartość nieskuteczności wzgl˛ednej.
Rysunek 3.2(e) przedstawia charakterystyk˛e nieskuteczności wzgl˛ednej asercji w zależności
od liczby innych asercji p, które w danej serii testów o wyniku testu e, należały do tego samego
profilu co badana asercja. Wszystkie charakterystyki zostały sporzadzone
˛
dla tej samej funkcji
w(e). Wykres został przygotowany dla trzech różnych eksperymentów o rosnacej
˛ liczbie testów
o wyniku e. Wartość nieskuteczności wzgl˛ednej jest odwrotnie proporcjonalna do liczby asercji,
które należa˛ do tego samego profilu w danym teście co badana asercja. Im wi˛eksza liczba testów
w eksperymencie, w których badana asercja należała do wybranego profilu tym wi˛eksza jest
wartość nieskuteczności wzgl˛ednej.
3.3. Metoda selekcji asercji
Metoda selekcji asercji, których parametry b˛eda˛ spełniały w optymalny sposób pewne
wybrane kryteria wyrażone z użyciem zaprezentowanych wcześniej miar, składa si˛e z nast˛epujacych
˛
kroków:
— obserwacja asercji w badanym programie
— wyznaczenie parametrów asercji,
— wybór asercji według wybranej strategii,
— weryfikacja otrzymanych wyników poprzez eksperyment z rejestracja˛ naruszeń wybranych
asercji w programie,
— analiza otrzymanych rezultatów.
Powiazania
˛
pomi˛edzy poszczególnymi krokami metody selekcji asercji przedstawiono
na rysunku 3.3.
Na podstawie przygotowanego zestawu testów o pewnych parametrach
oraz przygotowanych danych wejściowych dla programu (jeśli sa˛ konieczne) dokonywana
jest seria jego uruchomień, w czasie której przeprowadzana jest obserwacja zachowania
asercji (krok pierwszy).
Zebrane wyniki testów pozwalaja˛ na wyznaczenie wybranych
parametrów asercji (krok drugi). Sa˛ one nast˛epnie użyte do przeprowadzenia procesu selekcji
51
asercji z uwzgl˛ednieniem wymaganych kryteriów (krok trzeci).
Program z wybranymi
asercjami poddawany jest analogicznemu zestawowi testów do użytego na potrzeby obserwacji
asercji (krok czwarty).
Zebrane informacje o naruszeniach wybranych asercji i liczbie
wykrytych bł˛edów moga˛ zostać porównane z wynikami jakie otrzymano, gdy wszystkie
asercje w programie były aktywne lub odnieść do rezultatów jakie otrzymano dla programu
z wybranymi asercjami na podstawie innych kryteriów (krok piaty).
˛
wyniki
testów
1
parametry
przeprowadzanych DAT
testów
4
wyniki
testów
LOG
2
obserwacja asercji
w badanym
programie
DAT
rejestracja naruszeń
wybranych asercji
w badanym programie
LOG
wyznaczenie
parametrów asercji
dane
wejściowe
badanego
programu
TXT
3
TXT
selekcja asercji
wybrane
asercje
5
analiza wyników
parametry
asercji
TXT
TXT
strategie
selekcji
asercji
wnioski
z analizy
wyników
Rysunek 3.3. Przebieg procesu selekcji asercji
3.3.1. Obserwacja asercji
Na etapie obserwacji asercji wykonywana jest seria uruchomień programu zgodnie z zakładanym scenariuszem testowym T zawierajacym
˛
określony zbiór testów. Może on zostać
wygenerowany automatycznie na przykład z wykorzystaniem narz˛edzi, takich jak FITS [9, 37]
czy FERRARI [48], przeznaczonych do zakłócania wykonania aplikacji i obserwacji jej zachowania w celu analizy wiarygodności. Pojedynczy test t polega na jednokrotnym wykonaniu
programu w ustalonym, najcz˛eściej zakłóconym w pewien sposób, środowisku. Podczas testów
asercje sa˛ aktywne, ale ich skutki działania nie moga˛ wpływać na przebieg wykonania programu
i na inne asercje. Oznacza to, że potencjalne naruszenie jest rejestrowane lecz nie powoduje
52
przerwania programu. Na tym etapie same asercje nie moga˛ być zakłócane ponieważ w sposób
wiarygodny musza˛ być rejestrowane ich właściwości. Dla każdego testu zapisywany jest kod
zakończenia programu oraz charakterystyki wszystkich asercji w badanym programie.
Proces obserwacji asercji może być operacja˛ czasochłonna.˛ Jej czas jest wprost proporcjonalny do liczby przeprowadzanych testów oraz średniego czasu wykonania pojedynczego testu.
Ponieważ do obserwowanego programu wprowadzona jest zazwyczaj duża liczba asercji może
ona istotnie wpłynać
˛ na czas jego wykonania. Średni czas wykonania pojedynczego testu może
zostać oszacowany na podstawie pomiaru czasu działania programu zawierajacego
˛
wszystkie
asercje.
W tym kroku należy również określić pożadany
˛
profil asercji oraz wagi dla wyników testu.
Sa˛ one wyznaczane przez eksperta, który uwzgl˛ednia oczekiwany sposób zachowania asercji
podczas testów zakończonych danym wynikiem.
Wybrane parametry asercji, w zależności od ich charakteru, moga˛ zostać określone dla
każdego z testów, na podstawie testu wzorcowego lub poprzez wyznaczenie parametrów
statystycznych, a także wyznaczone przez eksperta. W szczególności parametr określajacy
˛
aktywność asercji b˛edzie wynikiem działania omawianego algorytmu selekcji asercji.
3.3.2. Wybór asercji
W kolejnym kroku na podstawie ustalonych oraz zmierzonych parametrów asercji można
utworzyć model matematyczny b˛edacy
˛ zadaniem programowania liniowego [99] o rozwiaza˛
niach w zbiorze liczb całkowitych.
Jego rozwiazanie
˛
da odpowiedź na pytanie, które
z asercji powinny być aktywne (parametr vi ), aby określony, wybrany profil zachowania asercji
w programie był optymalny według wyznaczonej funkcji celu i narzuconych ograniczeń.
Ze wzgl˛edu na przyj˛ete ograniczenia dotyczace
˛ zmiennych, które sa˛ rozwiazaniem
˛
tak
sformułowanego zadania programowania liniowego może być rozwiazywane
˛
za pomoca˛
algorytmu sympleksowego [99] wraz z metoda˛ rozgał˛ezień i ograniczeń lub, z uwagi na
binarny charakter wartości rozwiazań
˛
poszukiwanej zmiennej, specjalizowanym algorytmem
rozgał˛ezień i ograniczeń dla zadań binarnego programowania całkowitoliczbowego [17].
Funkcja celu zadania programowania liniowego
Celem sformułowanego zadania programowania liniowego jest znalezienie takiego zestawu
aktywnych asercji, dla którego wybrane parametry, w zależności od potrzeb, b˛eda˛ osiagały
˛
wartość minimalna˛ lub maksymalna.˛ W szczególności funkcjami celu zadania programowania
liniowego moga˛ być:
— maksymalizacja wartości sumy skuteczności bezwzgl˛ednej lub wzgl˛ednej wszystkich aktywnych asercji w programie wpływajaca
˛ na liczb˛e wykrywanych zakłóceń w działaniu
badanego programu,
53
— minimalizacja wartości sumy nieskuteczności bezwzgl˛ednej lub wzgl˛ednej wszystkich aktywnych asercji w programie wpływajaca
˛ na liczb˛e niewykrywanych zakłóceń w działaniu
badanego programu,
— minimalizacja wartości sumy średniego całkowitego kosztu dynamicznego wszystkich
aktywnych asercji w programie wpływajaca
˛ na czas działania badanego programu,
— minimalizacja wartości sumy średniego kosztu statycznego wszystkich aktywnych asercji
w programie wpływajaca
˛ na rozmiar badanego programu,
— maksymalizacja lub minimalizacja wartości sumy średniej wartości parametrów położenia
wszystkich aktywnych asercji w programie wpływajaca
˛ na przykład na moment wykrycia
zakłóceń w działaniu badanego programu.
Ograniczenia
Narzucone ograniczenia w omawianym zadaniu programowania liniowego obejmuja:
˛
— ograniczenie na dopuszczalny zbiór wartości zmiennej vi :
∀i=1...n vi = 0 ∨ vi = 1
(3.5)
— dolne lub górne ograniczenie na wartość jednej lub wielu sum wartości parametrów
charakteryzujacych
˛
aktywne asercje badanego programu; konkretne wartości wybranego
ograniczenia wybierane sa˛ przez eksperta,
— ograniczenia zwiazane
˛
z innymi parametrami asercjami takimi jak wybór asercji
określonego rodzaju lub z określonych grup asercji.
3.3.3. Weryfikacja wyników
Ostatnim, opcjonalnym krokiem metody selekcji asercji jest weryfikacja teoretycznie
osiaganych
˛
wyników oszacowanych na podstawie obserwacji asercji. Polega ona na ponownym
wykonaniu testów dla programu, w którym aktywne sa˛ wyłacznie
˛
wybrane asercje. Na tym
etapie dopuszcza si˛e możliwość zakłócania działania samych asercji, aby w możliwie jak
najlepszym stopniu odzwierciedlić rzeczywiste zakłócenia, jakim poddana może być aplikacja.
Stosowany zbiór testów nie musi być identycznym zbiorem stosowanym na etapie obserwacji
asercji. Celem weryfikacji jest zbadanie zachowania wybranych asercji w pewnych określonych
warunkach, które w szczególności moga˛ pokrywać si˛e z testami stosowanymi na etapie
obserwacji asercji. Wyniki weryfikacji można porównać z wynikami testów podczas obserwacji
asercji określajac
˛ na przykład ile bł˛edów zostało w praktyce przez nie wykrytych.
Podczas eksperymentu majacego
˛
na celu weryfikacj˛e wyników rejestrowane sa˛ wyniki
testów (w szczególności program zakończony naruszeniem asercji) oraz ewentualnie
szczegółowe informacje o asercjach, które zostały naruszone.
54
3.3.4. Przykłady zastosowania metody selekcji asercji
Poniżej zaprezentowano przykładowe sformułowania zadań programowania liniowego
majacych
˛
na celu redukcj˛e liczby stosowanych asercji w programie z uwzgl˛ednieniem kryteriów maksymalizacji całkowitej wartości ich skuteczności bezwzgl˛ednej i wzgl˛ednej. Do
przeprowadzenia obliczeń wykorzystano dane zebrane podczas eksperymentu z wykorzystaniem aplikacji symulujacej
˛
działanie sterownika produkcyjnego, który szczegółowo został
opisany w punkcie 5.1 rozdziału piatego.
˛
W aplikacji użytych zostało 1851 asercji, co
wpłyn˛eło na duża˛ liczb˛e składników wyst˛epujacych
˛
w funkcjach celu oraz ograniczeniach.
Z tego powodu, tam gdzie było to konieczne, zaprezentowano jedynie ich wybrana˛ cz˛eść,
zast˛epujac
˛ wielokropkiem pomini˛ete składniki. Parametry asercji określajace
˛ ich skuteczność
i nieskuteczność zostały wyznaczone na podstawie eksperymentu, na który składało si˛e 5087
testów. Czas jednokrotnego wykonania programu zawierajacego
˛
wszystkie asercje wynosił
około 380 sekund, co oznacza, że obserwacja programu trwała około 22 dni.
Dla maksymalizacji wartości sumy skuteczności bezwzgl˛ednej wszystkich n asercji przy
wybranym profilu oraz wagach wyników testu funkcja celu dla zadania programowania
liniowego przyjmuje ogólna˛ postać:
n
X
i=1
(vi ∗
X
w(et ) ∗ p(i, t)) → max
t∈T
Po przeprowadzeniu podczas eksperymentu pomiarów dla badanego programu określone
zostały wartości skuteczności bezwzgl˛ednej, wzgl˛ednej oraz całkowitego kosztu dynamicznego
dla każdej z asercji. Wyznaczono je z wykorzystaniem oprogramowania z pakietu AEM
przedstawionego w dodatku A.1, służacego
˛
do automatyzacji pomiarów parametrów asercji
takich jak ich skuteczność, nieskuteczność oraz liczba sprawdzeń asercji. Dla przyj˛etej funkcji
w(e) w postaci 5.1 (strona 86) określaja˛ one liczb˛e testów, dla których dana asercja wykryła
wprowadzony bład
˛ skutkujacy
˛ nieprawidłowym działaniem programu pomniejszona˛ o liczb˛e
testów, dla których dana asercja wykryła wprowadzony bład,
˛ mimo iż nie miał on wpływu na
wynik działania programu. Dla 915 asercji wartość skuteczności bezwzgl˛ednej wynosi 0, dla
166 asercji jest dodatnia i mniejsza niż 10, dla 23 kształtuje si˛e pomi˛edzy wartościa˛ 10 a 100,
dla pozostałych zawiera si˛e pomi˛edzy 260 a 390. Funkcja celu dla zadania programowania
liniowego przyj˛eła nast˛epujac
˛ a˛ postać:
5v1 + 3v2 + v3 + 2v4 + 2v5 + 3v6 + v7 + v8 + v9 + 311v10 + . . .
. . . + 298v1842 + 301v1843 + 298v1844 + 288v1845 + 298v1846 +
+284v1847 + 300v1848 + 302v1849 + 299v1850 + 301v1851 → max
Ogólna formuła funkcji celu zadania programowania liniowego dla maksymalizacji wartości
55
skuteczności wzgl˛ednej n asercji w programie przy wybranym profilu oraz wagach wyników
testu jest nast˛epujaca:
˛
n
X
i=1
(vi ∗
X
w(et ) ∗
t∈T,p(i,t)6=0
p(i, t)
n
X
) → max
vk ∗ p(k, t)
k=1
W trakcie przeprowadzania testów określane zostały również wartości skuteczności wzgl˛ednej dla wszystkich asercji w programie. Stosowana była funkcja w(e) w postaci 5.1. Podczas
obliczania wartości skuteczności wzgl˛ednej przyj˛eto, że wszystkie asercje w programie sa˛
aktywne. Dla 19 asercji wartość skuteczności wzgl˛ednej jest ujemna, dla 869 przyjmuje
wartości dodatnie pomi˛edzy 0 a 1, dla 48 jest wi˛eksza niż 1 przyjmujac
˛ dla jednej z asercji
najwi˛eksza˛ obserwowana˛ wartość wynoszac
˛ a˛ 6,317, dla pozostałych wartość ta wynosi 0.
Funkcja celu zadania programowania liniowego dla omawianego programu przyj˛eła postać:
0, 02v1 + 0, 12v2 + 0, 003v3 + 0, 005v4 − 0, 057v5 + 0, 005v6 + v7 + . . .
. . . + 0, 435v1842 + 0, 452v1843 + 0, 458v1844 + 0, 429v1845 + 0, 457v1846 +
+0, 418v1847 + 0, 436v1848 + 0, 507v1849 + 0, 432v1850 + 0, 464v1851 → max
Wartość przedstawionych powyżej funkcji celu zostały zoptymalizowane przy nast˛epuja˛
cych ograniczeniach:
— na górna˛ wartość Uv liczby asercji, jakie moga˛ zostać użyte w programie; może zostać ona
wyznaczona z użyciem parametru opisujacego
˛
aktywność asercji (suma aktywnych asercji):
n
X
vi ≤ Uv
i=1
— na górna˛ wartość UD całkowitego kosztu dynamicznego (definicja 3.2.5) wszystkich asercji
określonego na podstawie niezakłóconego wykonania programu (test gr):
n
X
vi ∗ Di,gr ≤ UD
i=1
— na dopuszczalny zbiór wartości zmiennej vi w postaci 3.5.
Dla pierwszego z ograniczeń określajacego
˛
liczb˛e użytych asercji przyj˛eto górna˛ wartość
wynoszac
˛ a˛ do 10 wybranych asercji:
1851
X
vi ≤ 10
i=1
Ponieważ każda z asercji wyst˛epujacych
˛
w badanym programie zawierała dokładnie
56
jeden operator badajacy
˛ zależność pomi˛edzy wartościami dwóch zmiennych lub zmiennej
i pewnej stałej liczbowej przyj˛eto jednostkowy koszt dla operacji sprawdzenia warunku
w asercji. Wartość kosztu dynamicznego określonego w teście wzorcowym określała zatem
ile razy asercja została podczas tego testu sprawdzona. Wartość t˛e wyznaczono automatycznie
korzystajac
˛ z możliwości pakietu AEM. Najniższy uzyskany koszt dynamiczny pojedynczej
asercji wynosi 300 i 906 asercji przyj˛eło taka˛ wartość kosztu, dla 227 wynosi on 600, dla 240
został określony na 5400, dla kolejnych 240 przyjmuje wartość 58800, dla 238 osiaga
˛ wartość
59400. Górna˛ wartość sumarycznego całkowitego kosztu dynamicznego asercji określono na
dziesi˛eciokrotna˛ wielokrotność najmniejszego kosztu dynamicznego pojedynczej asercji, to jest
UD = 3000:
300v1 + 300v2 + 300v3 + 300v4 + 300v5 + . . .
. . . + 5400v250 + 5400v251 + . . . + 58800v750 + 58800v751 + . . .
. . . + 59400v1000 + . . . + 600v1200 + . . . + 300v1850 + 300v1851 ≤ 3000
Ostatnie z wymienionych ograniczeń dla omawianego zadania programowania całkowitoliczbowego przyj˛eło nast˛epujac
˛ a˛ postać:
∀i=1...1851 vi = 0 ∨ vi = 1
Tak przygotowane dwa zadania programowania liniowego zostały rozwiazane
˛
za pomoca˛
pakietu AEM, który wykorzystuje do tego celu algorytm sympleksowy [99].
i
P
skuteczność całkowity koszt
bezwzgl˛edna
dynamiczny
32
91
589
601
648
660
834
846
892
906
327
327
330
329
329
329
329
329
329
329
300
300
300
300
300
300
300
300
300
300
10
3287
3000
Tabela 3.4. Rozwiazanie
˛
zadania maksymalizacji całkowitej wartości skuteczności bezwzgl˛ednej asercji
Rozwiazanie
˛
zadania majacego
˛
na celu maksymalizacj˛e funkcji określajacej
˛
całkowita˛
wartość skuteczności bezwzgl˛ednej asercji w programie zaprezentowano w tabeli 3.4. W ko57
skuteczność całkowity koszt
wzgl˛edna
dynamiczny
i
P
7
65
223
281
282
601
691
1,000
2,006
1,524
2,200
4,940
0,652
1,000
300
300
600
600
600
300
300
7
13,322
3000
Tabela 3.5. Rozwiazanie
˛
zadania maksymalizacji całkowitej wartości skuteczności wzgl˛ednej asercji
lejnych kolumnach podano indeksy wybranych asercji, wartości ich skuteczności bezwzgl˛ednej
oraz kosztu dynamicznego. W ostatnim wierszu podano liczb˛e wybranych asercji, znaleziona˛
maksymalna˛ wartość funkcji celu przy narzuconych ograniczeniach i sumaryczna˛ wartość
kosztu dynamicznego wybranych asercji.
Analogiczne wyniki dla zadania majacego
˛
na
celu maksymalizacj˛e funkcji określajacej
˛ całkowita˛ wartość skuteczności wzgl˛ednej asercji
w programie zaprezentowano w tabeli 3.5.
3.4. Podsumowanie i wnioski
W rozdziale zaprezentowana została metoda umożliwiajaca
˛ wybór podzbioru asercji,
które w optymalny sposób b˛eda˛ spełniać założone kryteria. Metoda została sformułowana
w sposób uniwersalny, który pozwala na jej dostosowanie do specyficznych wymagań oraz
dopuszcza ewentualne rozszerzenia. Zdefiniowano również szereg miar, które moga˛ posłużyć
do wymiernej oceny asercji.
Należy jednak zwrócić uwag˛e na aspekty, które stanowia˛ ograniczenie proponowanej
metody. W ramach niniejszej rozprawy zakłada si˛e, że stosowany zbiór testów jest reprezentatywny, to jest uwzgl˛ednia szeroki zakres przypadków modyfikacji i zakłóceń środowiska,
danych wejściowych oraz samej badanej aplikacji. Użycie niewielkiego lub nieadekwatnego
zbioru testów może skutkować otrzymaniem wyników, które moga˛ nie mieć praktycznego
zastosowania.
Ze wzgl˛edu na konieczność przeprowadzenia dużej liczby testów i pomiarów stosowanie
proponowanej metody może być pracochłonne i czasochłonne. Istnieje konieczność opracowania testów oraz przygotowania środowiska do przeprowadzenia badań. Niekiedy dostosowanie
samej badanej aplikacji może okazać si˛e skomplikowanym zadaniem. Duża liczba asercji
w programie, których zachowanie jest obserwowane, może skutkować długim czasem wykonania każdego z testów. Może on przekraczać czas wykonania programu bez wprowadzonych
58
asercji.
Proponowana metoda pozostawia konieczność podj˛ecia pewnych założeń w r˛ekach
eksperta. Osoba taka musi zdecydować o stosowanym zbiorze testów oraz strategii optymalizacji określajac
˛ funkcje celu oraz ograniczeń. Podejmowane decyzje zależa˛ od badanego
oprogramowania oraz docelowych jego parametrów jakie musza˛ być osiagni˛
˛ ete. Podejmowanie
tych decyzji wymaga pewnego doświadczenia w stosowaniu metody.
Uwzgl˛edniajac
˛ powyższe uwagi konieczne jest eksperymentalne zweryfikowanie praktycznego zastosowania opisanej metody. Uczyniono to w dalszej cz˛eści pracy poświ˛econej
przeprowadzonym doświadczeniom (rozdział piaty).
˛
Zaproponowane miary dla oceny asercji wzgl˛edem zróżnicowanych kryteriów moga˛ być
wykorzystane nie tylko dla celów opisanej metody selekcji asercji.
Możliwe jest ich
stosowanie podczas innych procedur majacych
˛
na celu profilowanie programu (na przykład
z uwzgl˛ednieniem różnego rodzaju kosztów użycia asercji w programie) oraz do tworzenia
jego zaawansowanej dokumentacji (na przykład załaczenie
˛
informacji o rodzajach bł˛edów oraz
ich dotkliwości wykrywanych przez dane asercje).
59
4. Asercje ze śladem
Algorytmy wykrywajace
˛ asercje w programach bazuja˛ na analizie danych zgromadzonych
w jego wybranych punktach.
Można zaproponować dodatkowa˛ klasyfikacj˛e tych danych
z uwzgl˛ednieniem wcześniejszego przebiegu programu czyli osiagni˛
˛ etych punktów w programie (śladu wykonania). Asercje wykrywane byłyby nie z całego zbioru zgromadzonych
danych dla punktu programu, ale jedynie z określonych jego elementów wybranych na
podstawie wcześniejszego przebiegu programu. Wykryte w ten sposób asercje b˛eda˛ od niego
zależne, a przez to bardziej wyspecjalizowane.
Konstrukcje programowe umożliwiajace
˛ praktycznie zastosowanie asercji zależnych od
przebiegu programu nazwiemy asercja˛ ze śladem. Jest to połaczenie
˛
asercji weryfikujacej
˛
prawidłowość przetwarzanych danych z asercja˛ sprawdzajac
˛ a˛ poprawność przebiegu wykonania programu.
4.1. Ślad wykonania programu
Dany jest program, w którym wyznaczono n punktów mp , p = 1 . . . n.
Funkcja ID(mp ) = idp , której dziedzina˛ jest zbiór wszystkich punktów programu,
przyporzadkowuje
˛
każdemu punktowi unikalny identyfikator idp .
Definicja 4.1.1. Śladem wykonania programu w punkcie mp , p = 1 . . . n nazywamy skończony
ciag
˛ (tl ), którego kolejnymi wyrazami ti , i = 1 . . . l sa˛ wartości funkcji ID(mk ) dla wartości k
określajacych
˛
kolejno odwiedzone punkty programu uporzadkowane
˛
według kolejności wizyt
od ostatnio odwiedzonego punktu. Ślad wykonania jest również nazywany śladem.
Definicja 4.1.2. Liczb˛e wyrazów ciagu
˛ (tl ) oznaczamy l i nazywamy długościa˛ śladu wykonania.
Definicja 4.1.3. Pustym śladem wykonania nazywamy ślad dla którego l = 0.
Dla dwóch śladów wykonania w danym punkcie programu możemy określić relacj˛e
zawierania si˛e śladów oraz równości śladów.
Definicja 4.1.4. Ślad (tl ) zawiera si˛e w śladzie (ul0 ) wtedy i tylko wtedy jeżeli 1 ≤ l ≤
l0 ∧ ∀i=1...l ti = ui albo l = 0 albo l = 0 ∧ l0 = 0. Relacj˛e zawierania si˛e śladu (tl ) w śladzie
(ul0 ) oznaczamy (tl ) ∈ (ul0 ).
61
Definicja 4.1.5. Ślad (tl ) jest równy śladowi (ul0 ) wtedy i tylko wtedy jeżeli l = l0 ∧(tl ) ∈ (ul0 ).
Relacj˛e równości śladów (tl ) i (ul0 ) oznaczamy (tl ) = (ul0 ).
C
A
B
E
D
Rysunek 4.1. Fragment schematu blokowego programu
Na rysunku 4.1 przedstawiono fragment schematu blokowego pewnego programu. Jeżeli za
punkty w tym programie uznać miejsca b˛edace
˛ poczatkiem
˛
wydzielonego bloku to przykładowymi możliwymi śladami wykonania programu w punkcie E sa:
˛
— ślady o długości jeden: (C), (D),
— ślady o długości dwa: (C, B), (D, B),
— ślady o długości trzy: (C, B, A), (C, B, C), (D, B, A), (D, B, C),
— ślady o długości cztery: (C, B, A, E), (C, B, C, B), (D, B, A, E), (D, B, C, B).
Podana definicja śladu wykonania programu uniezależnia go od dodatkowych wymagań
jakie spotykane sa˛ w metodach sprawdzania poprawności wykonania programu. Należa˛ do
nich na przykład konieczność podziału programu na odr˛ebne bloki z wymaganiem jednej
ścieżki wejścia i wyjścia zwiazanej
˛
z danym fragmentem kodu [2]. Do decyzji eksperta należy
odpowiedni dobór punktów programu. B˛edzie on miał wpływ na charakter otrzymanego śladu
zwiazany
˛
z jego ziarnistościa˛ (punkty programu na poziomie modułów, poszczególnych funkcji,
czy poszczególnych instrukcji).
4.1.1. Rejestracja śladu wykonania programu
W uruchamianym programie obserwacja śladu wykonania może odbywać si˛e poprzez
implementacj˛e struktury danych w rodzaju kolejki FIFO o nast˛epujacych
˛
własnościach:
— jej elementami sa˛ identyfikatory punktów w programie,
— określona jest liczba elementów w kolejce; wartość ta odpowiada poj˛eciu długości śladu,
— osiagni˛
˛ ecie obserwowanego punktu w programie powoduje umieszczenie nowego elementu
w kolejce (identyfikatora osiagni˛
˛ etego punktu).
Aktualny stan kolejki w danym punkcie wyrażony w postaci skończonego ciagu
˛ jej
elementów b˛edzie odzwierciedlał aktualny ślad wykonania programu.
62
Na rysunku 4.2 przedstawiono fragment schematu blokowego pewnego programu wraz
ze stanami kolejki FIFO o długości do trzech elementów dla jego przykładowego przebiegu.
Punktami w tym programie sa˛ miejsca b˛edace
˛ poczatkiem
˛
wydzielonego bloku. Kolejne stany
kolejki oznaczono rosnaco
˛ wartościami od 1 do 13 z założeniem, że poczatkowo
˛
w punkcie A
kolejka jest pusta. Zawartość kolejki została umieszczona obok punktów programu.
2 BA
10 B A E
12 B C B
1
5
9
11
4 ECB
8 EDB
A
A
AEC
AED
CBA
C
B
3 CBA
7 DBA
13 C B C
E
D
6 BAC
Rysunek 4.2. Fragment schematu blokowego programu wraz z kolejnymi stanami kolejki FIFO przechowujacej
˛ aktualny ślad jego wykonania
Metody implementacji
W zależności od liczby obserwowanych punktów w programie (liczby identyfikatorów),
wymaganej długości kolejki (długości śladu), zastosowanego j˛ezyka oraz metody programowania możliwych jest wiele metod implementacji struktury danych przechowujacej
˛ ślad wykonania. Poza zastosowaniem dost˛epnych implementacji kolejek (na przykład z biblioteki STL
j˛ezyka C++ lub standardowego pakietu j˛ezyka Java) w niektórych przypadkach istotne może
być uproszczenie tej struktury, aby operacje z jej udziałem nie wpływały w istotny sposób
na czas działania aplikacji. Jeżeli możliwe jest zakodowanie poszczególnych identyfikatorów
punktów na k bitach, a dost˛epny system pozwala na użycie zmiennych o długości równej co
najmniej pewnej wielokrotności k bitów (długość śladu) to możliwe jest jego przechowywanie
w postaci zmiennej liczbowej. Operacj˛e aktualizacji śladu s w danym punkcie programu
o identyfikatorze i można wtedy ogólnie zapisać wyrażeniem (stosujac
˛ konwencj˛e notacji
j˛ezyka C) (s << k)|i, gdzie << jest operatorem przesuni˛ecia bitowego, a | to operator sumy
bitowej.
Poza zastosowaniem kolejki FIFO w formie jawnej implementacji struktury danych
przechowujacej
˛ ślad wykonania programu możliwe jest również zaadoptowanie wybranych
technik stosowanych dla asercji weryfikujacych
˛
poprawność przebiegu programu. Koncepcja
kolejek stosowana jest w metodzie CCA [1].
Innym sposobem implementacji jest przy-
porzadkowanie
˛
odpowiednich liczb pierwszych punktom programu, a poprzez operacje na
nich odzwierciedlenie przebiegu wykonania programu (metoda ECCA [2]).
Podobna do
proponowanej implementacji kolejki na zmiennej w programie jest metoda YACCA [38],
63
w której poprzez odpowiednie modyfikowanie zmiennej liczbowej otrzymywane sa˛ wartości
reprezentujace
˛ poprawny przebieg działania programu. Inne metody polegaja˛ na stosowaniu
sygnatur [75, 104] oraz użyciu mechanizmu wyrażeń regularnych do konstrukcji warunków
asercji [8], które porównywane sa˛ z aktualnym śladem programu. Stosowanie w warunkach
asercji oraz przechowywanie śladu wykonania programu w formacie kolejki przechowujacej
˛
kolejno odwiedzone punkty jest metoda,˛ która dodatkowo pozwala na łatwa˛ interpretacj˛e przez
programist˛e, w przeciwieństwie do algorytmów stosujacych
˛
inne sposoby kodowania, z reguły
zorientowane na skrócenie czasu sprawdzania asercji.
4.2. Poj˛ecie asercji ze śladem wykonania
Zaproponowany powyżej ślad wykonania programu może zostać skojarzony z odpowiednimi asercjami. Otrzymana konstrukcja b˛edzie wyrażała asercj˛e, która spełniona jest pod
warunkiem określonego przebiegu programu. Dzi˛eki temu, w danym punkcie programu lub
pomi˛edzy dwoma kolejnymi punktami programu, w których rejestrowany jest ślad b˛eda˛ mogły
być weryfikowane różne zestawy asercji zależne od przebiegu programu. W wielu przypadkach
może pozwolić to na ich lepsza˛ specjalizacj˛e i, co si˛e z tym wia˛że, na lepsza˛ efektywność
w detekcji bł˛edów.
Definicja 4.2.1. Asercja˛ ze śladem S nazywamy par˛e uporzadkowan
˛
a˛ (a, (tl )), gdzie a jest
asercja,˛ a (tl ) śladem.
Podczas wykonania programu w danym jego punkcie sprawdzenie asercji a zawartej
w pewnej asercji ze śladem S nast˛epuje jedynie w sytuacji gdy (tl ) ∈ (sl0 ), gdzie (sl0 ) oznacza
bieżacy
˛ ślad wykonania programu. W przeciwnym przypadku asercja a nie powinna zostać
sprawdzona, ponieważ nie obowiazuje
˛
ona dla aktualnego przebiegu programu. Oznacza to,
że w danym punkcie programu lub pomi˛edzy jego dwoma kolejnymi punktami sprawdzane sa˛
jedynie te asercje, które odzwierciedlaja˛ żadany
˛
stan zmiennych aplikacji dla aktualnego jego
przebiegu.
4.3. Parametry asercji ze śladem
Dla asercji ze śladem możliwe jest określenie wszystkich parametrów zaproponowanych
w rozdziale 3.2.
Na koszt asercji ze śladem składa si˛e koszt śladu oraz koszt zwiazanej
˛
z nia˛ asercji.
Określenie kosztu asercji ze śladem, zarówno statycznego jak i dynamicznego, jest zależne od
stosowanej implementacji, a w szczególności od sposobu przechowywania i kodowania śladów
wykonania programu. Należy zauważyć, że całkowity koszt dynamiczny wszystkich asercji ze
64
śladem w danym punkcie programu, może być zależny od jego przebiegu, ze wzgl˛edu na brak
konieczności weryfikacji wszystkich asercji.
Dodatkowym elementem, który powinien zostać uwzgl˛edniony w koszcie statycznym i dynamicznym asercji ze śladem jest konieczność zastosowania dodatkowego modułu programu,
którego celem jest obserwacja i przechowywanie aktualnego śladu badanej aplikacji. Statyczny
koszt tego modułu jest stały i nie zależy od liczby stosowanych w programie asercji ze śladem
oraz liczby obserwowanych punktów. Obie wymienione wielkości maja˛ jednak wpływ na koszt
dynamiczny sprawdzenia asercji ze śladem.
4.4. Wykrywanie asercji ze śladem
Wykrywanie asercji ze śladem wia˛że si˛e ze wst˛epnym pogrupowaniem danych wejściowych
dla algorytmów wykrywania asercji według aktualnego stanu śladu wykonania w danym
punkcie.
Po zebraniu danych asercje wykrywane sa˛ niezależnie dla każdego ze śladów
z wykorzystaniem znanych algorytmów wykrywajacych
˛
asercje w programach. W ten sposób
w danym punkcie programu otrzymuje si˛e tyle asercji danego typu ile różnych śladów
wykonania prowadzi do tego punktu. Połaczenie
˛
wykrytych asercji ze śladami, wzgl˛edem
których dokonano klasyfikacji zebranych danych tworzy odpowiednia˛ asercj˛e ze śladem.
W aplikacjach wielowatkowych,
˛
w zależności od pożadanego
˛
efektu, możliwych jest kilka
scenariuszy post˛epowania. Pierwszy z nich polega na globalnej obserwacji programu, to
jest wspólnej dla wszystkich watków.
˛
Takie zachowanie umożliwia rejestracj˛e ewentualnych
zależności czasowych pomi˛edzy osiaganymi
˛
punktami programu w różnych watkach.
˛
Jego
wada˛ jest rejestrowanie jako różnych śladów wyścigów mi˛edzy watkami,
˛
co może prowadzić
do wykrycia niepełnych lub nieprawidłowych asercji. Z tego powodu może być konieczny
dodatkowy wst˛epny krok polegajacy
˛ na rozdzieleniu danych pochodzacych
˛
od różnych watków.
˛
Każdy z watków
˛
traktowany jest w takim przypadku jak oddzielny program co oznacza, że ślad
obserwowany jest oddzielnie dla każdego z nich. Kolekcjonowane dane moga˛ być łaczone
˛
dla
danych punktów w programie lub przechowywane oddzielnie z uwzgl˛ednieniem identyfikatora
watku.
˛
W zależności od wybranego sposobu post˛epowania znalezione zestawy asercji b˛eda˛
określały ogólne zachowanie wszystkich watków
˛
lub każdego z nich osobno. Należy zauważyć,
że rozdzielenie danych ze wzgl˛edu na identyfikator watku
˛ może być konieczne dla niektórych
typów asercji, na przykład narzucajacych
˛
ograniczenia na zmienne lokalne lub tworzone
dynamicznie w danym watku.
˛
Istotnym elementem algorytmów wykrywajacych
˛
asercje w programach jest wst˛epna
redukcja ich liczby uwzgl˛edniajaca
˛ na przykład pokrycie przez różne asercje tych samych
bł˛edów lub możliwość łaczenia
˛
kilku asercji w jedna,˛ tak jak to ma miejsce w systemie
Daikon [29]. Podobne algorytmy można zaproponować dla wykrytych zbiorów asercji ze
65
śladem. W dalszej cz˛eści rozdziału przedstawione zostały algorytmy umożliwiajace
˛ realizacj˛e
operacji takich jak redukcja liczby śladów oraz ich skracanie dla zbioru asercji ze śladem
w danym punkcie programu. Przykład działania tych algorytmów został zaprezentowany
w końcowej cz˛eści rozdziału.
4.4.1. Algorytm redukcji liczby śladów w zbiorze asercji ze śladem
Celem algorytmu 4.1 redukcji liczby śladów w zbiorze asercji ze śladem jest zmniejszenie
liczby asercji ze śladem poprzez połaczenie
˛
asercji o zawierajacych
˛
si˛e śladach. Pod poj˛eciem
zbioru asercji ze śladem rozumie si˛e tu zbiór asercji w danym punkcie programu. Algorytm
przeszukuje zbiór asercji ze śladem i łaczy
˛
sprawdzane asercje w przypadku, gdy zachodzi
relacja zawierania si˛e śladów. Po wykonaniu tej operacji asercja z krótszym śladem jest
usuwana ze zbioru asercji ze śladem. Przykładowo, jeżeli w danym punkcie programu istnieja˛
trzy asercje ze śladem o takich samych śladach to dwie z nich moga˛ zostać usuni˛ete, a asercje
w nich stosowane skonkatentowane z asercja˛ w trzeciej.
Jeżeli ślad pewnej asercji ze śladem zawiera si˛e w kilku innych śladach to asercja z tej
asercji ze śladem zostanie połaczona
˛
ze wszystkimi asercjami z pozostałych asercji ze śladem.
W takim przypadku, mimo zmniejszenia liczby asercji ze śladem, zwi˛ekszona zostanie liczba
przechowywanych asercji w pozostałych asercjach ze śladem, gdyż niektóre z nich b˛eda˛
zduplikowane.
wejście: zbiór A asercji ze śladem
wyjście: zbiór A asercji ze śladem ze zredukowana˛ liczba˛ śladów
begin
foreach S ∈ A do
c ← f alse
foreach S 0 ∈ A\S do
if (tl )S ∈ (tl )S 0 then
aS 0 ← aS 0 ∧ aS
c ← true
if c then
A ← A\S
Algorytm 4.1. Algorytm redukcji liczby śladów w zbiorze asercji ze śladem
Efektem działania algorytmu redukcji liczby śladów może być utrata informacji. Dzieje si˛e
tak w przypadku wyst˛epowania w zbiorze asercji ze śladem śladów o różnych długościach
przy założeniu, że wyst˛epujace
˛ dłuższe ślady, do których dołaczane
˛
sa˛ asercje z asercji ze
śladem o krótszych śladach nie wyczerpuja˛ wszystkich możliwych śladów, jakie moga˛ pojawić
si˛e w danym punkcie programu czyli innych śladów, w których może zawierać si˛e krótszy
66
ze śladów.
Utrata informacji w takim przypadku zajdzie na etapie sprawdzenia asercji.
W momencie pojawienia si˛e śladu, w którym zawierałby si˛e ślad asercji wchłoni˛etej poprzez
algorytm redukcji liczby śladów do innej asercji, nie zostanie ona sprawdzona.
Po wykonaniu algorytmu dla poszczególnych zestawów asercji zawartych we wszystkich
asercjach ze śladem powinny zostać wykonane algorytmy optymalizujace
˛ ich liczb˛e (dokonujace
˛ usuni˛ecia lub połaczenia
˛
odpowiednich asercji w powstałej koniunkcji). Dla asercji bez
śladu algorytmy takie zaimplementowane sa˛ w pakiecie Daikon [29].
4.4.2. Algorytm skracania śladów w zbiorze asercji ze śladem
Przeznaczeniem algorytmu 4.2 skracania śladów w zbiorze asercji ze śladem jest zmniejszenie długości istniejacych
˛
śladów na tyle, aby zachować ich rozróżnienie. Oznacza to, że
nie zajdzie sytuacja, w której skracany ślad, który przed operacja˛ skrócenia nie zawierał si˛e
w innym śladzie, po jej wykonaniu wejdzie w taka˛ relacj˛e z dowolnym śladem z badanego
zbioru. Przykładowo, jeżeli w danym punkcie programu istnieja˛ dwie asercje ze śladem,
których pierwszy element śladu jest identyczny i drugi element śladu różny to kolejne elementy
ich śladów moga˛ zostać usuni˛ete, gdyż nie wpływaja˛ one na rozróżnienie tych dwóch śladów.
Skrócenie śladów tych asercji nie doprowadzi do sytuacji wyboru nieprawidłowego zestawu
asercji do sprawdzenia podczas wykonania programu. Usuni˛ecie drugiego elementu śladów
tych asercji spowodowałoby sprawdzenie wszystkich asercji, co byłoby bł˛edne.
wejście: zbiór A asercji ze śladem
wyjście: zbiór A asercji ze śladem ze skróconymi śladami
begin
c ← true
while c do
foreach S ∈ A ∧ lS > 1 do
c ← true
Q←S
lQ ← lQ − 1
foreach S 0 ∈ A\S do
if (tl )Q ∈ (tl )S 0 then
c ← f alse
break
if c then
S←Q
break
Algorytm 4.2. Algorytm skracania śladów w zbiorze asercji ze śladem
Algorytm zakłada, że w badanym zbiorze asercji ze śladem istniejace
˛ ślady wyczerpuja˛
67
wszystkie możliwości pojawienia si˛e śladów o określonych długościach. W przeciwnym
wypadku wynik działania algorytmu b˛edzie bł˛edny. Podczas wykonania programu b˛edzie
mogła zaistnieć sytuacja sprawdzenia asercji, które w przypadku zastosowania oryginalnego
zbioru nie byłyby sprawdzone.
4.5. Weryfikacja asercji ze śladem
Można wyszczególnić nast˛epujace
˛
metody weryfikacji zbioru asercji ze śladem
w określonym punkcie programu:
— weryfikacja całkowita – sprawdzenie wykrytych asercji oraz poprawności aktualnego
śladu wykonania,
— weryfikacja cz˛eściowa – sprawdzenie wykrytych asercji bez sprawdzania poprawności
aktualnego śladu wykonania.
Jeżeli zbiór sprawdzanych śladów wyczerpuje wszystkie prawidłowe ślady jakie moga˛
pojawić si˛e w danym punkcie programu to weryfikacja całkowita pozwala na wykrycie niedozwolonego przejścia pomi˛edzy punktami w programie. Weryfikacja całkowita musi uwzgl˛edniać sprawdzenie wszystkich możliwych śladów, nawet tych, dla których nie znaleziono
asercji. Dla takich śladów należy wprowadzić asercj˛e ze śladem, w której asercj˛e zastapiono
˛
zawsze spełniona˛ asercja.˛ Tego typu asercja bada jedynie poprawność przepływu sterowania
w programie.
Dla danego punktu programu, w którym określono zbiór A zawierajacy
˛ k asercji ze śladem,
przy czym żaden ze śladów w tym zbiorze nie zawiera si˛e w innym ze śladów, schemat
weryfikacji całkowitej można przedstawić w nast˛epujacy
˛ sposób:
begin
if (tl )1 ∈ (sl0 ) then
assert (a1 )
else if (tl )2 ∈ (sl0 ) then
assert (a2 )
...
else if (tl )k ∈ (sl0 ) then
assert (ak )
else
obsługa niedozwolonego przebiegu programu
...
Struktura weryfikacji całkowitej umożliwia wykluczenie konieczności sprawdzania wszyst68
kich możliwych śladów przy każdym osiagni˛
˛ eciu danego punktu w programie, co przekłada si˛e
na skrócenie czasu potrzebnego na wykonanie tej procedury. Zastosowanie tego schematu dla
zbioru A asercji ze śladem jest możliwe, jeśli wykonany zostanie algorytm 4.1 redukcji liczby
śladów w zbiorze asercji ze śladem.
W przypadku, gdy zachodzi sytuacja zawierania si˛e śladów wybranych asercji ze śladem
ze zbioru A sprawdzone musza˛ zostać wszystkie asercje z tego zbioru. Schemat weryfikacji
całkowitej b˛edzie miał nast˛epujacy
˛ przebieg:
begin
c ← true
foreach S ∈ A do
if (tl )S ∈ (sl0 ) then
assert (aS )
c ← f alse
if c then
obsługa niedozwolonego przebiegu programu
...
Ten schemat weryfikacji jest mniej wydajny z uwagi na konieczność sprawdzenia wszystkich możliwych śladów ze zbioru A oraz konieczność wprowadzenia dodatkowej zmiennej c,
która przechowuje informacj˛e o sprawdzeniu co najmniej jednej asercji ze śladem.
Analogiczne procedury weryfikacji asercji ze śladem jakie przedstawiono dla weryfikacji
całkowitej można zaproponować w schemacie weryfikacji cz˛eściowej, która nie obejmuje
sprawdzenia poprawności śladu wykonania programu w danym punkcie.
Dla danego punktu programu, w którym określono zbiór A zawierajacy
˛ k asercji ze śladem,
przy czym żaden ze śladów w tym zbiorze nie zawiera si˛e w innym ze śladów schemat
weryfikacji cz˛eściowej można przedstawić w nast˛epujacy
˛ sposób:
begin
if (tl )1 ∈ (sl0 ) then
assert (a1 )
else if (tl )2 ∈ (sl0 ) then
assert (a2 )
...
else if (tl )k ∈ (sl0 ) then
assert (ak )
...
69
W przypadku, gdy zachodzi sytuacja zawierania si˛e śladów wybranych asercji ze śladem
ze zbioru A sprawdzone musza˛ zostać wszystkie asercje z tego zbioru. Schemat weryfikacji
cz˛eściowej b˛edzie miał nast˛epujacy
˛ przebieg:
begin
foreach S ∈ A do
if (tl )S ∈ (sl0 ) then
assert (aS )
...
Weryfikacja cz˛eściowa obejmuje sprawdzenie wybranych śladów. Dopuszcza ona sytuacj˛e,
w której żaden ze śladów w zbiorze asercji ze śladem nie zawiera si˛e w aktualnym śladzie
wykonania. Uniemożliwia ona jednak wykrycie sytuacji, gdy aktualny ślad wykonania nie
był nigdy wcześniej obserwowany czyli zachodzi podejrzenie nieprawidłowego przebiegu
programu.
Przy zastosowaniu metody weryfikacji całkowitej asercja ze śladem staje si˛e konstrukcja˛
analogiczna˛ do asercji sprawdzajacej
˛ poprawność wykonania programu. Szczególnym przypadkiem może być taka asercja ze śladem, w której asercja jest zawsze spełniona. Tego
typu asercja ze śladem przy zastosowaniu metody weryfikacji całkowitej odpowiada asercji
sprawdzajacej
˛ poprawność przebiegu programu.
4.5.1. Algorytm redukcji liczby identyfikatorów punktów programu dla zbiorów asercji
ze śladem
Algorytm 4.3 redukcji liczby identyfikatorów punktów programu dla zbiorów asercji ze
śladem ma na celu rozwiazanie
˛
problemu odpowiedniego przydziału nowych identyfikatorów,
tak aby ich liczba była możliwie minimalna, ale zachowana była możliwość rozróżniania
śladów w poszczególnych punktach programu.
Algorytm korzysta z faktu, że istnieje
możliwość zastosowania tego samego identyfikatora dla dwóch różnych punktów programu,
jeżeli liczba innych punktów osiaganych
˛
w programie pomi˛edzy nimi przekracza najwi˛eksza˛
z długości obserwowanych śladów.
Zaproponowany algorytm działa w sposób zachłanny. Dla wszystkich aktualnych identyfikatorów przeszukuje on ślady w dost˛epnych asercjach sprawdzajac
˛ możliwość przyporzad˛
kowania nowych kolejnych wartości dla badanego identyfikatora tak, aby zachować rozróżnialność śladu definiowana˛ jako rozróżnienie wszystkich identyfikatorów w wyst˛epujacych
˛
poszczególnych śladach. Każda konieczność przydziału innej wartości skutkuje koniecznościa˛
ponownego przeszukania zbioru śladów w celu sprawdzenia czy warunek rozróżnialności nie
został naruszony.
Wynikiem działania algorytmu jest funkcja przyporzadkowuj
˛
aca
˛ nowe wartości poprzednim
70
wejście: uporzadkowany
˛
zbiór DID bieżacych
˛
identyfikatorów dla punktów programu,
zbiór PA wszystkich zbiorów asercji ze śladem w punktach programu
wyjście: funkcja ID(id), id ∈ DID przyporzadkowuj
˛
aca
˛ nowe wartości dla
identyfikatorów punktów programu
begin
foreach id ∈ DID do
ID(id) ← 1
begin check
foreach A ∈ PA do
foreach S ∈ A do
(tl ) ← (tl )S
for i ← 1 to l do
if exists ID(ti ) ∧ ID(ti ) = ID(id) then
ID(id) ← ID(id) + 1
goto check
Algorytm 4.3. Algorytm redukcji liczby identyfikatorów punktów programu dla zbiorów asercji ze
śladem
wartościom identyfikatorów. Jest to jedno z możliwych przyporzadkowań.
˛
Ponieważ algorytm
działa w sposób zachłanny, nie analizujac
˛ wszystkich możliwych kombinacji przyporzadkowań,
˛
otrzymany wynik zależy od kolejności analizowanych asercji ze śladem we wszystkich
zbiorach.
Algorytm nie uwzgl˛ednia nieistotnych cz˛eści śladów, które nie maja˛ wpływu na rozróżnienie pomi˛edzy śladami w zbiorze asercji ze śladem dla danego punktu. Może to wpłynać
˛ na użycie wi˛ekszej liczby nowych identyfikatorów. Z tego powodu przed wykonaniem omawianego
algorytmu wskazane jest uruchomienie dla wszystkich zbiorów asercji ze śladem ze zbioru
PA algorytmu skracania śladów w zbiorze asercji ze śladem omówionego w punkcie 4.4.2.
Dzi˛eki temu liczba nowych identyfikatorów może okazać si˛e mniejsza przy zapewnieniu
warunku rozróżniania śladów. Nowe identyfikatory można zastosować na zbiorze śladów
sprzed operacji ich skracania. Istotne jest uruchomienie algorytmu z uwzgl˛ednieniem w zbiorze
wejściowym wszystkich asercji ze śladem jakie maja˛ być sprawdzane w programie. Późniejsze
usuni˛ecie z programu asercji ze śladem może spowodować jedynie użycie zbyt dużej liczby
identyfikatorów niż byłoby to możliwe po powtórnym zastosowaniu algorytmu. Po dodaniu
asercji konieczne jest powtórne uruchomienie algorytmu, ponieważ zastosowane dodatkowe
identyfikatory moga˛ prowadzić do sytuacji braku rozróżnienia nowego śladu w zbiorze śladów
już istniejacych,
˛
co może skutkować ich bł˛edna˛ weryfikacja.˛
Ze wzgl˛edu na redukcj˛e liczby identyfikatorów zastosowanie omawianego algorytmu
prowadzi do utraty informacji. Może zaistnieć sytuacja braku wykrycia bł˛edu nieprawidłowego
71
przejścia w programie lub sprawdzenia nieodpowiednich asercji, w przypadku gdy dla dwóch
punktów programu, do których przejścia sa˛ odpowiednio poprawne i niepoprawne, został
przyporzadkowany
˛
ten sam identyfikator.
4.6. Przykład działania zaproponowanych algorytmów
Poniżej przedstawiono rezultaty działania zaprezentowanych algorytmów otrzymane
poprzez użycie skryptu z pakietu FlowGraph omówionego w dodatku A.2. Przykładowe dane
wejściowe przygotowano na cele prezentacji, bez odniesienia do rzeczywistego programu.
Założono, że w pewnym programie wyznaczono dziesi˛eć punktów obserwacji.
Asercje
ze śladem zostały przygotowane dla trzech punktów programu o identyfikatorach 1, 2, 3.
W każdym z tych punktów programu przygotowano pi˛eć asercji ze śladem. Poczatkowa
˛
zawartość zbiorów asercji ze śladem jest nast˛epujaca:
˛
A1 = { (
a1,1
, (9)
),
(
a1,2
, (10, 9)
),
(
a1,3
, (9, 8, 10)
),
(
a1,4
, (10, 10, 5)
),
(
a1,5
, (9, 5, 10, 9)
)
A2 = { (
a2,4
, (7)
),
(
a2,2
, (9, 5)
),
(
a2,3
, (10, 9)
),
(
a2,1
, (7, 9, 7, 5)
),
(
a2,5
, (5, 5, 5, 10)
)
A3 = { (
a3,5
, (3, 3)
),
(
a3,1
, (2, 2, 2)
),
(
a3,2
, (2, 3, 4)
),
(
a3,4
, (3, 4, 3)
),
(
a3,3
, (2, 2, 4, 4)
)
}
}
}
Łaczna
˛
liczba znalezionych śladów wynosi 15, a suma ich długości 41. W asercjach ze
śladem sprawdzanych jest łacznie
˛
15 różnych asercji (oznaczonych identyfikatorami ai,j , gdzie
i jest identyfikatorem punktu programu, j numerem porzadkowym
˛
asercji w zbiorze asercji ze
śladem). W śladach użytych zostało 8 z 10 różnych identyfikatorów punktów programu.
Algorytm 4.1 redukcji liczby śladów wykonany dla zbioru A1 asercji ze śladem dołaczy
˛
do
asercji z warunkiem a1,3 oraz a1,5 warunek a1,1 z uwagi na zawieranie si˛e śladów. W drugim
zbiorze połaczone
˛
zostana˛ asercje z warunkami a2,1 oraz a2,4 . Trzeci zbiór asercji pozostanie
bez zmian.
72
Jeżeli asercje ze śladem o dłuższych śladach, do których zostały dołaczone
˛
asercje z asercji
ze śladem o krótszym śladzie, nie wyczerpuja˛ wszystkich możliwości pojawienia si˛e krótszego
śladu to w wyniku wykonania algorytmu dojdzie do opisywanej wcześniej utraty informacji na
etapie weryfikacji. Przykładowo, gdyby w pierwszym z punktów programu pojawił si˛e ślad
(9, 2) to dla zbioru przed wykonaniem algorytmu redukcji liczby śladów sprawdzona zostanie
asercja a1,1 , dla zbioru po wykonaniu algorytmu – żadna z asercji.
Po wykonaniu algorytmu 4.1 redukcji liczby śladów dla kolejnych zbiorów asercji ze śladem
ich zawartość b˛edzie nast˛epujaca:
˛
A1 = { (
a1,2
, (10, 9)
),
(
a1,3 ∧ a1,1
, (9, 8, 10)
),
(
a1,4
, (10, 10, 5)
),
(
a1,5 ∧ a1,1
, (9, 5, 10, 9)
)
A2 = { (
a2,2
, (9, 5)
),
(
a2,3
, (10, 9)
),
(
a2,1 ∧ a2,4
, (7, 9, 7, 5)
),
(
a2,5
, (5, 5, 5, 10)
)
A3 = {
(
a3,5
, (3, 3)
),
(
a3,1
, (2, 2, 2)
),
(
a3,2
, (2, 3, 4)
),
(
a3,4
, (3, 4, 3)
),
(
a3,3
, (2, 2, 4, 4)
)
}
}
}
Ogólna liczba śladów w nowych zbiorach wynosi 13, a suma ich długości 39. W asercjach
ze śladem sprawdzanych jest łacznie
˛
16 asercji. Liczba sprawdzeń wzrosła, ponieważ jedna
z asercji sprawdzana jest w dwóch różnych asercjach ze śladem. W śladach użytych zostało
8 różnych identyfikatorów punktów programu.
Algorytm 4.2 skracania śladów wykonany dla pierwszego ze zbiorów asercji ze śladem
zmodyfikuje wszystkie ślady dłuższe niż dwa identyfikatory skracajac
˛ je do długości dwóch
identyfikatorów. W zbiorze drugim wszystkie ślady moga˛ zostać skrócone do długości jednego
identyfikatora. W zbiorze trzecim asercje z warunkami a3,2 , a3,4 oraz a3,5 po wykonaniu
algorytmu b˛eda˛ miały długość dwóch identyfikatorów, a pozostałe – trzech identyfikatorów.
Jeżeli w punkcie programu, dla którego stosowany jest zbiór A1 asercji ze śladem podczas
wykonania pojawiłby si˛e aktualny ślad o długości 4 w postaci (9, 5, 10, 1) to po zastosowaniu
zbioru ze skróconymi śladami doszłoby do weryfikacji warunku a1,5 ∧ a1,1 , ponieważ skrócony
ślad zawierałby si˛e w aktualnym śladzie. Sprawdzana asercja mogłaby okazać si˛e bł˛edna.
Z tego powodu istotne jest zbadanie, czy istniejace
˛ ślady wyczerpuja˛ wszystkie możliwe ślady
o danych długościach przed zastosowaniem algorytmu.
73
Wynik działania algorytmu 4.2 skracania śladów dla zbiorów asercji ze śladem powstałych
w wyniku zastosowania algorytmu 4.1 redukcji liczby śladów jest nast˛epujacy:
˛
A1 = { (
a1,2
, (10, 9)
),
(
a1,3 ∧ a1,1
, (9, 8)
),
(
a1,4
, (10, 10)
),
(
a1,5 ∧ a1,1
, (9, 5)
)
A2 = { (
a2,2
, (9)
),
(
a2,3
, (10)
),
(
a2,1 ∧ a2,4
, (7)
),
(
a2,5
, (5)
)
A3 = { (
a3,5
, (3, 3)
),
(
a3,1
, (2, 2, 2)
),
(
a3,2
, (2, 3)
),
(
a3,4
, (3, 4)
),
(
a3,3
, (2, 2, 4)
)
}
}
}
Ogólna liczba śladów po wykonaniu algorytmu skracania śladów pozostała bez zmian
i wynosiła 13, a suma ich długości 24. W asercjach ze śladem jest 16 asercji. Do konstrukcji
śladów użyto 8 różnych identyfikatorów.
Algorytm 4.3 redukcji liczby identyfikatorów znajduje jedna˛ z możliwości przyporzad˛
kowania nowych identyfikatorów dla zbiorów ze skróconymi śladami tak, aby na etapie
weryfikacji były one nadal jednoznaczne we wszystkich punktach weryfikacji asercji ze śladem.
W wyniku działania tego algorytmu dla prezentowanych przykładowych zbiorów znalezione
zostało przyporzadkowanie:
˛
ID(1) = 10 , ID(2) = 10 , ID(3) = 20 , ID(4) = 30 , ID(5) = 10 ,
ID(6) = 10 , ID(7) = 20 , ID(8) = 20 , ID(9) = 30 , ID(10) = 40 .
Do zakodowania poprzednio wykorzystanych ośmiu identyfikatorów konieczne było zastosowanie co najmniej trzech bitów. Po redukcji można zastosować dwa bity do zakodowania identyfikatorów punktów programu tak, aby stosowane ślady pozostały jednoznaczne.
Poczatkowe
˛
zbiory asercji ze śladem po zastosowaniu nowych identyfikatorów b˛eda˛ miały
nast˛epujac
˛ a˛ postać:
A1 = {
(
a1,1
, (30 )
(
a1,2
, (40 , 30 )
0
),
0
),
0
(
a1,3
, (3 , 2 , 4 )
),
(
a1,4
, (40 , 40 , 10 )
),
(
a1,5
, (30 , 10 , 40 , 30 )
)
}
74
A2 = { (
A3 = {
a2,4
, (20 )
0
),
0
(
a2,2
, (3 , 1 )
),
(
a2,3
, (40 , 30 )
),
(
a2,1
, (20 , 30 , 20 , 10 )
0
0
0
0
),
(
a2,5
, (1 , 1 , 1 , 4 )
)
(
a3,5
, (20 , 20 )
),
(
a3,1
, (10 , 10 , 10 )
),
(
a3,2
, (10 , 20 , 30 )
),
0
0
0
(
a3,4
, (2 , 3 , 2 )
),
(
a3,3
, (10 , 10 , 30 , 30 )
)
}
}
4.7. Prezentacja asercji ze śladem
Jednym z zastosowań asercji ze śladem jest możliwość wykorzystania ich do dokumentowania programu oraz podczas jego analizy przez człowieka. W takich zastosowaniach
asercje ze śladem moga˛ być szczególnie przydatne, gdyż wia˛ża˛ przebieg wykonania programu
z jego właściwościami.
Tego typu asercje przedstawione w formie rysunków cz˛esto sa˛
bardziej zrozumiałe i przydatne niż opis tekstowy. Świadczy o tym chociażby kariera notacji
graficznych w projektowaniu oprogramowania.
Z tych powodów istotne jest rozważenie
różnych możliwości prezentacji asercji ze śladem.
Poniżej przedstawiono cztery propozycje wizualizacji asercji ze śladem: w formie wykazu,
digrafu, multigrafu oraz kolorowanego multigrafu. Wszystkie zaproponowane wizualizacje
przedstawiono na rysunku 4.3. Przygotowane zostały dla przykładowych zbiorów asercji ze
śladem przygotowanych na cele prezentacji, bez użycia rzeczywistej aplikacji. Punkty programu oznaczono jako litery w prostokatach.
˛
Rysunki nie zostały przygotowane automatycznie.
Przygotowanie odpowiedniego narz˛edzia do wizualizacji zbiorów asercji ze śladem leży poza
zakresem niniejszej pracy.
Poza możliwościami prezentacji asercji ze śladem opisane wizualizacje moga˛ być wykorzystane do implementacji określonych struktur danych, takich jak listy dynamiczne, tablice
czy grafy, których celem b˛edzie przechowywanie obiektów tego typu. Cennym rozszerzeniem
środowisk do rozwoju aplikacji, które zintegrowane sa˛ już z mechanizmami do dynamicznego
wykrywania asercji, może być wbudowanie w nie opisanych sposobów wizualizacji asercji ze
śladem.
Zaproponowane metody prezentacji asercji ze śladem nie wyczerpuja˛ wszystkich potencjalnych sposobów ich wizualizacji. Dla pewnych zastosowań użyteczniejsze moga˛ być inne
rodzaje ich graficznego przedstawienia.
75
(A,B) q ≤ −1
(B,A) d ≤ −1
(B,A) p ≤ −5
A
C
(B,A) n = 2
(C,A) n ≥ 0
(A,B) i 6= 1
(C,B) n ≤ 6
B
D
(a) wykaz
(A,B) i 6= 1
(B,A) n = 2
(C,A) n ≥ 0
B
(B,A) d ≤ −1
(C,B) n ≤ 6
A
D
C
(A,B) d ≤ −1
(B,A) d ≤ −5
(b) digraf
1
) i 6=
A
) n
=2
(B,A) d ≤ −5
1
≤−
) d
≤6
) n
(B,A
(A,B
(B,A
B
(A,B
(C,B
) d
≤−
1
C
D
≥0
) n
(C,A
(c) multigraf
(A,B) i 6= 1
(B,A) n = 2
(C,A) n ≥ 0
B
(B,A) d ≤ −1
(C,B) n ≤ 6
A
D
C
(A,B) d ≤ −1
(B,A) d ≤ −5
(d) kolorowany multigraf
Rysunek 4.3. Różne formy prezentacji asercji ze śladem dla przykładowego programu
76
4.7.1. Wykaz
Wizualizacja asercji w formie wykazu (listy) polega na wymienieniu punktów programu
wraz z obowiazuj
˛ acymi
˛
w nich asercjami ze śladem. Przykładowy wykaz został przedstawiony
na rysunku 4.3(a). Przy każdym z punktów programu wymieniono możliwe ślady (ciag
˛
punktów programu zapisano w nawiasach) wraz z asercjami, jakie dla nich sa˛ obowiazuj
˛ ace.
˛
Zaleta˛ tej formy prezentacji jest jej prostota. Może być ona wykorzystana w środowiskach nie
posiadajacego
˛
interfejsu graficznego. Forma ta jest przejrzysta dla małej liczby punktów programu z niewielka˛ liczba˛ asercji. Wada˛ jest brak wykorzystania informacji o przechowywanych
śladach w celu ułatwienia analizy przez człowieka.
Idea wykazu asercji ze śladem przekłada si˛e na struktur˛e danych przeznaczona˛ do ich
przechowywania dla całego programu w postaci implementacji listy dynamicznej lub tablicy,
której elementami sa˛ obserwowane jego punkty oraz wskazania na list˛e (tablic˛e) zawierajac
˛ a˛
asercje ze śladem obowiazuj
˛ ace
˛ w określonych punktach. Lista punktów programu i asercji ze
śladem może być tworzona, aktualizowana i weryfikowana w dowolnym momencie wykonania
programu.
4.7.2. Digraf
Wykorzystanie informacji o przechowywanych śladach w asercjach prowadzi do wizualizacji prezentujacych
˛
wybrane elementy przebiegu programu. Naturalnym sposobem prezentacji
takich asercji jest struktura grafu. Na rysunku 4.3(b) przedstawiono zbiór asercji ze śladem
zobrazowany w formie digrafu. Informacje, pozyskane na podstawie przechowywanych śladów,
posłużyły do wykreślenia kraw˛edzi mi˛edzy wierzchołkami grafu reprezentujacymi
˛
punkty
w programie. Kraw˛edź pomi˛edzy dwoma punktami oznacza potencjalna˛ możliwość bezpośredniego przejścia mi˛edzy nimi podczas wykonania programu. Zaleta˛ tej formy prezentacji
jest uproszczenie analizy asercji ze śladem powiazanych
˛
z przebiegiem wykonania programu
oraz wizualizacja potencjalnych ścieżek wykonania w programie. Wada˛ jest niejednoznaczność
śladów wytyczanych poprzez kraw˛edzie o długości dłuższej niż jedno przejście, ponieważ nie
wszystkie kombinacje przejść musza˛ być prawidłowe. Z tego powodu asercje przechowywane
sa˛ w wierzchołkach grafu wraz z pełnymi śladami.
Digraf prezentujacy
˛ asercje ze śladem przekłada si˛e na struktur˛e danych przeznaczona˛ do
ich przechowywania dla całego programu w formie digrafu, w którym w wierzchołkach przechowywana jest lista dynamiczna lub tablica asercji ze śladem obowiazuj
˛ acych
˛
w określonym
punkcie programu oraz lista kraw˛edzi skierowanych do wierzchołków, do których kolejne
przejścia sa˛ możliwe.
Dla dużych analizowanych programów przechowywanie danych
w takiej strukturze może znaczaco
˛ przyspieszyć czas wyszukiwania odpowiednich asercji
do sprawdzenia. Struktura tego typu może być tworzona, aktualizowana i weryfikowana
w dowolnym momencie wykonania programu.
77
4.7.3. Multigraf
Przeniesienie informacji o asercjach ze śladem w danym punkcie programu z wierzchołków
grafu do jego kraw˛edzi prowadzi do wizualizacji w formie multigrafu, którego przykład
pokazano na rysunku 4.3(c). W kraw˛edzi wchodzacej
˛ do danego wierzchołka przechowywany
jest jeden z możliwych śladów wraz z odpowiadajacymi
˛
mu asercjami. Zaleta˛ multigrafu jest
uproszczenie analizy asercji ze śladem powiazanych
˛
z przebiegiem wykonania programu oraz
wizualizacja fragmentów ścieżek wykonania w programie. Forma ta jest przydatna, kiedy
w wierzchołku (punkcie programu) wyst˛epuje duża liczba asercji. Poprzez przeniesienie ich
do oddzielnych kraw˛edzi uzyskano wi˛eksza˛ przejrzystość. Wada˛ jest reprezentacja dłuższych
śladów w formie jednej kraw˛edzi charakteryzujacej
˛ jedynie jednostkowy jego fragment.
Multigraf prezentujacy
˛ asercje ze śladem odpowiada strukturze multigrafu przeznaczonej do
ich przechowywania dla całego analizowanego programu. Dla każdej z kraw˛edzi wchodzacej
˛
do danego wierzchołka przechowywana jest etykieta zawierajaca
˛ określony ślad oraz lista
dynamiczna lub tablica asercji obowiazuj
˛ acych
˛
w określonym punkcie programu dla danego
śladu.
Struktura tego typu może być tworzona i aktualizowana w dowolnym momencie
wykonania programu. Może ona zostać także wykorzystana do obserwacji przebiegu programu
i selekcji odpowiednich asercji podczas procesu weryfikacji.
4.7.4. Kolorowany multigraf
Na rysunku 4.3(d) przedstawiono zbiór asercji ze śladem zobrazowany w formie
kolorowanego multigrafu. Dla każdej asercji ze śladem wykreślono pełen przebieg śladu
w formie kraw˛edzi określonego koloru. Zakończenie kraw˛edzi danego koloru powiazane
˛
jest
z wystapieniem
˛
w wierzchołku asercji o identycznym oznaczeniu. Zaleta˛ takiego rozwiazania
˛
jest wizualizacja pełnego śladu dla asercji na grafie prezentujacym
˛
przebieg programu. Jest
to wizualizacja dobra dla aplikacji o niewielkiej liczbie zróżnicowanych śladów lub dla
fragmentów aplikacji. Przy ich znacznej liczbie rysunek może stać si˛e nieczytelny. W takim
przypadku może być prezentowana na przykład jedynie cz˛eść asercji ze śladem.
4.8. Podsumowanie i wnioski
W rozdziale zaproponowana została metoda podniesienia wiarygodności wykrywanych
asercji poprzez uzależnienie ich od śladu wykonania programu. Przedstawione zostały metody
pozwalajace
˛ na wykrywanie tego typu asercji oraz ich późniejsza˛ weryfikacj˛e w oprogramowaniu. Asercje tego typu można uznać za połaczenie
˛
asercji weryfikujacych
˛
poprawność danych
w programie oraz przebiegu jego wykonania. Różne metody weryfikacji asercji ze śladem
w oprogramowaniu pozwalaja˛ na ich wykorzystanie zarówno w celu wyłacznie
˛
wi˛ekszej
78
specjalizacji asercji sprawdzajacych
˛
dane jak i dodatkowo kontroli poprawności przebiegu
wykonania programu.
Dla zbiorów asercji ze śladem zaproponowano trzy algorytmy, których przeznaczeniem jest
ich przetwarzanie w celu:
— redukcji liczby śladów w zbiorze asercji ze śladem (algorytm 4.1),
— skracania śladów w zbiorze asercji ze śladem (algorytm 4.2),
— redukcji liczby identyfikatorów punktów programu dla zbiorów asercji ze śladem (algorytm 4.3).
W rozdziale przedstawione zostały także przykładowe sposoby wizualizacji zbiorów asercji
ze śladem w postaci wykazu, digrafu, multigrafu i kolorowanego multigrafu. Moga˛ one
być uzupełnieniem środowisk graficznych przeznaczonych do rozwoju oraz analizy działania
aplikacji.
Badanie asercji ze śladem może być szczególnie interesujace
˛ dla aplikacji reaktywnych,
w których interakcja z użytkownikiem (lub działanie zależne od użytkownika) jest bardzo
silne. Przykładem moga˛ być inteligentne systemy sterujace
˛ na przykład oświetleniem w domu,
które swoje działanie dostosowuja˛ do specyficznych zachowań użytkownika oraz systemy
analizujace
˛ sposób wykorzystania karty płatniczej lub usług sieciowych [63]. Dla takich
aplikacji proces wykrywania asercji jest realizowany przez pewna˛ cz˛eść czasu pracy systemu,
a nast˛epnie wykryte asercje zaczynaja˛ być sprawdzane lub oba procesy trwaja˛ jednocześnie
aż do osiagni˛
˛ ecia ustalonej minimalnej liczby zgłaszanych nieprawidłowych naruszeń asercji.
Asercje ze śladem wykryte w takich systemach moga˛ odzwierciedlać zachowania specyficzne
dla danego użytkownika, czy miejsca lub czasu zastosowania systemu. Asercje ze śladem moga˛
w takim przypadku pełnić nie tylko rol˛e zabezpieczeń programu, ale również sposobu jego
używania ponieważ opisuja˛ jego własności dynamiczne.
79
5. Optymalizacja wykorzystania asercji
w programach
Niezb˛ednym elementem pracy badawczej w dziedzinie inżynierii oprogramowania sa˛
różnego rodzaju eksperymenty pozwalajace
˛ na obserwacj˛e, analiz˛e oraz ocen˛e działania
proponowanych metod w praktycznych zastosowaniach, a także na dostrzeżenie problemów
zwiazanych
˛
z ich użyciem. Z wyżej wymienionego oraz innych powodów przedstawionych
w pracach [5, 102, 117] eksperymenty powinny nast˛epować po etapie teoretycznych rozważań
i stanowić ich uzupełnienie.
W rozdziale trzecim oraz czwartym zaproponowano metody, których celem jest poprawienie wybranych parametrów zestawu asercji lub podniesienie ich skuteczności. W niniejszym
rozdziale przedstawiono metodologi˛e analizy opisanych metod oraz, na przykładzie konkretnych aplikacji, dokonana została eksperymentalna weryfikacja ich efektywności.
5.1. Redukcja liczby asercji w programie
W punkcie 3.3 przedstawiona została metoda selekcji asercji umożliwiajaca
˛ wyznaczenie
pewnego ich podzbioru, który w optymalny sposób spełni narzucone kryteria.
Celem badania jest sprawdzenie w jaki sposób redukcja liczby dynamicznie wykrytych asercji wpłynie na parametry aplikacji takie jak jej kosz statyczny (punkt 3.2.3) i dynamiczny (punkt
3.2.4) oraz poziom detekcji bł˛edów wyrażony miara˛ skuteczności bezwzgl˛ednej i wzgl˛ednej
(punkt 3.2.10).
W pierwszym etapie badane aplikacje zostana˛ uruchomione w środowisku przeznaczonym
do dynamicznego wykrywania asercji (rozdział drugi). Wszystkie wykryte asercje zostana˛
wprowadzone do programów. Tak wzbogacone ich wersje zostana˛ wielokrotnie uruchomione
w systemie FITS [36, 37, 97] przeznaczonym do zakłócania działania aplikacji. W każdym
z uruchomień do aplikacji zostanie wprowadzony losowy bład
˛ skutkujace
˛ określonym zachowaniem asercji, które b˛edzie obserwowane. Dane zebrane podczas obserwacji umożliwia˛
wyznaczenie parametrów asercji (punkt 3.3.1).
Dane zebranie w trakcie obserwacji zachowania asercji zostana˛ wykorzystane na kolejnym
etapie badania majacym
˛
na celu wybranie pewnego ich podzbioru (punkt 3.3.2). Wykorzystane
zostana˛ różne kryteria selekcji asercji, co umożliwi ich późniejsza˛ analiz˛e porównawcza˛ pod
81
wzgl˛edem redukcji liczby asercji oraz zmiany innych parametrów programu. Na podstawie
otrzymanych wyników przygotowane zostana˛ wersje aplikacji, w których zastosowane b˛eda˛
wyznaczone zbiory asercji. Programy te zostana˛ poddane eksperymentom weryfikujacym
˛
(punkt 3.3.3).
Po otrzymaniu wyników z eksperymentów weryfikujacych
˛
możliwa b˛edzie analiza porównawcza liczby wykrytych bł˛edów przy zastosowaniu różnych podzbiorów wybranych asercji
w stosunku do liczby bł˛edów wykrytych w aplikacjach, w których zastosowano wszystkie
wykryte asercje lub nie stosowano mechanizmu asercji. W tym aspekcie porównane zostana˛
również inne parametry aplikacji takie jak liczba instrukcji stosowanych w różnych jej wersjach.
W kolejnych punktach przedstawiono charakterystyk˛e badanych aplikacji oraz zaprezentowano szczegółowy przebieg eksperymentów wraz z przyj˛etymi parametrami.
Do ich
przeprowadzenia wykorzystano narz˛edzia z pakietu AEM szczegółowo opisane w dodatku A.1.
Umożliwiaja˛ one automatyzacj˛e szeregu operacji wymaganych w metodzie takich jak pomiar parametrów asercji czy wyznaczanie ich podzbiorów, a także opracowanie wyników
przeprowadzonych eksperymentów.
W poniższym opisie każdemu z opisywanych eksperymentów przyporzadkowano
˛
zestaw
identyfikatorów, których układ odpowiada badaniu jednej z wersji wymienionych aplikacji,
różniacej
˛ si˛e na przykład podzbiorem wybranych asercji.
Przedstawiona metodologia analizy jest uniwersalna. Przedstawiony sposób post˛epowania
oraz przygotowane oprogramowanie wspomagajace
˛ omówiony proces może być zastosowane
dla innych aplikacji.
5.1.1. Charakterystyka badanych programów
W badaniu wykorzystano program symulujacy
˛ działanie linii produkcyjnej (identyfikator
k) oraz aplikacj˛e przeznaczona˛ do rozwiazywania
˛
układu równań liniowych metoda˛ eliminacji
Gaussa [19] (identyfikator g).
Aplikacje stworzone zostały w j˛ezyku C++. Obliczenia przeprowadzane w programach
zaimplementowano na dwa sposoby:
— z wykorzystaniem operacji na liczbach zmiennoprzecinkowych realizowanych bezpośrednio przez rozkazy procesora (identyfikator f),
— realizujacej
˛
operacje na liczbach zmiennoprzecinkowych poprzez bibliotek˛e SoftFloat1 ,
która implementuje je z wykorzystaniem rozkazów procesora operujacych
˛
na liczbach
całkowitych (identyfikator i).
Każda z aplikacji posiada moduł, który umożliwia ocen˛e poprawności przeprowadzonych
obliczeń. Był on wykorzystywany w trakcie eksperymentów w celu oceny skutków wprowadzonych bł˛edów na wynik działania aplikacji. Moduł ten był niezależny i wyłaczony
˛
z procesu
1
http://www.cs.berkeley.edu/ jhauser/arithmetic/SoftFloat.html
82
wykrywania asercji oraz wprowadzania bł˛edów.
Jako środowiska służacego
˛
do przeprowadzenia wszystkich eksperymentów użyto systemu
Windows XP2 wraz z kompilatorem Visual C++3 . Zastosowany został komputer osobisty
wyposażony w procesor Intel Core 2 CPU T7200 2.00 GHz.
5.1.2. Wykrywanie asercji
W celu wykrycia asercji aplikacja k została uruchomiona pod kontrola˛ pakietu Daikon [29,
33] dla jednego zestawu danych wejściowych charakteryzujacych
˛
poprawne działanie sterownika. W wyniku analizy zebranych danych otrzymano 1851 asercji w module aplikacji
przeprowadzajacym
˛
symulacj˛e działania linii produkcyjnej. Otrzymane asercje były identyczne
zarówno dla aplikacji w wersji f jak i w wersji i. Do kodu źródłowego aplikacji wprowadzono
wszystkie wykryte asercje.
Automatycznie wykryte przez pakiet Daikon asercje dla aplikacji g opisywały jej zachowanie jedynie dla jednego zestawu danych wejściowych, którym był losowo wygenerowany
układ równań liniowych posiadajacy
˛ jedno rozwiazanie.
˛
Danych tych użyto podczas uruchomienia podlegajacego
˛
obserwacji. Wykryte asercje były całkowicie zależne od danych
wejściowych, co oznacza, że użycie innego układu równań spowodowałoby zgłaszanie przez
nie naruszeń. Z tego powodu, na podstawie proponowanych asercji, manualnie wprowadzono
zestaw zmodyfikowanych asercji, które uogólniono w taki sposób, aby były całkowicie
niezależne od danych wejściowych. Asercjom przyporzadkowano
˛
atrybut (punkt 3.2.8) charakteryzujacy
˛ moduł programu w jakim wystapiły:
˛
wyznaczajacy
˛ lub sprawdzajacy
˛ rozwiazanie
˛
układu równań. W cz˛eści aplikacji wyznaczajacej
˛ rozwiazanie
˛
układu równań zastosowano
sześćdziesiat
˛ asercji. We fragmencie weryfikujacym
˛
otrzymane rozwiazanie
˛
użyto sześciu
asercji. Te same asercje zastosowano dla aplikacji w wersji f oraz i aplikacji g.
Asercje wprowadzone do badanych programów opisywały asercj˛e typu a ◦ b, gdzie:
— a było zmienna˛ liczbowa˛ używana˛ w programie,
— b określało pewna˛ stała˛ wartość lub inna˛ zmienna˛ liczbowa˛ badanej aplikacji,
— ◦ było jednym z operatorów <, >, =, 6=, ≤, ≥ określajacym
˛
zależność mi˛edzy a i b.
Ponadto siedem asercji w aplikacji g opisywało zależność pomi˛edzy poprzednia˛ a aktualna˛
wartościa˛ danej zmiennej podczas iteracji na etapie obliczeń. Poprzednia wartość sprawdzanej
zmiennej była przechowywana z użyciem dodatkowej zmiennej pomocniczej.
5.1.3. Pomiar parametrów asercji
Pojedyncze uruchomienie programu (pojedynczy test) polegał na wykonaniu pełnego jego
przebiegu z wygenerowanym losowym pojedynczym zakłóceniem cz˛eści aplikacji wykonujacej
˛
2
3
http://www.microsoft.com/windowsxp/
http://msdn.microsoft.com/visualc/
83
symulacj˛e (aplikacja k) lub wyznaczajacym
˛
rozwiazanie
˛
układu równań oraz je weryfikujacym
˛
(aplikacja g) w jednym z nast˛epujacych
˛
modułów systemu komputerowego:
— rejestrów procesora,
— rejestrach jednostki zmiennoprzecinkowej (FPU),
— pami˛eci operacyjnej, w szczególności:
— adresów w obszarze danych,
— instrukcji przed jej wykonaniem,
— kodu statycznego programu.
Jako szczegółowe wartości parametrów generowanych bł˛edów wybrano domyślne ustawienia systemu FITS [37]. Bł˛edy generowane były w przypadkowych momentach. Stosowano
jednobitowe inwersje w zakłócanych obszarach (rejestry, pami˛eć operacyjna). Bł˛edy miały
charakter przemijajacy
˛ – czas utrzymania bł˛edu określono na jedna˛ instrukcj˛e. W wersji
aplikacji realizujacej
˛
w sposób programowy operacje na liczbach zmiennoprzecinkowych
obszar wprowadzania zakłóceń obejmował również bibliotek˛e SoftFloat. Liczba wykonanych
testów była wybrana przez system FITS w taki sposób, aby zapewnić maksymalne pokrycie
kodu z zakłócanego obszaru aplikacji.
Tak wybrane parametry wprowadzanych bł˛edów
pozwalaja˛ na poddanie aplikacji wpływom efektów działania zróżnicowanych rodzajów zakłóceń. Umożliwia to selekcj˛e asercji na podstawie wyników otrzymanych wskutek szerokiego
przekroju profili obserwacji.
Dla każdego z testów przeprowadzonego pod kontrola˛ systemu FITS określono wynik,
którego możliwe wartości przedstawione zostały w tabeli 5.1. Zbiór możliwych wyników testu
wynika z charakteru implementacji systemu FITS.
W każdym z opisywanych poniżej eksperymentów wykonano około pi˛eciu tysi˛ecy testów
zakłócajacych
˛
wyżej wymienione obszary wstrzykiwania bł˛edów.
Celem pierwszej serii eksperymentów było zebranie danych wykorzystywanych do
późniejszej selekcji zestawu asercji takich jak ich całkowity koszt dynamiczny oraz liczba
wykrytych bł˛edów przekładajaca
˛ si˛e na wartość parametru skuteczności asercji. Podczas
uruchomień badanych aplikacji zakłócany był jedynie obszar wykonujacy
˛ symulacj˛e (aplikacja
k) lub wyznaczajacy
˛ rozwiazanie
˛
układu równań oraz je weryfikujacym
˛
(aplikacja g) z pomini˛eciem wprowadzonych asercji.
Gdy dochodziło do naruszenia asercji podczas testu,
nie przerywano działania programu, a jedynie rejestrowano zaistniały fakt poprzez wpis do
dziennika działania aplikacji. W efekcie, mimo iż sprawdzano wprowadzone asercje, nie miały
one wpływu na przebieg działania programu. System FITS przekazywał otrzymany wynik testu
oraz dzienniki działania aplikacji do narz˛edzi z pakietu AEM, które umożliwiały automatyczna˛
rejestracj˛e obserwacji oraz analiz˛e naruszeń asercji.
Dla aplikacji g zastosowano cztery różne zestawy danych wejściowych opisujace
˛ układ
równań liniowych majacy
˛ jedno rozwiazanie
˛
o dwóch niewiadomych i dwóch równa-
84
N
Zakłócenie niewprowadzone. System FITS nie zdołał wprowadzić zakłócenia w realizowanym teście wskutek czego program zadziałał prawidłowo
(program zakończył si˛e i wygenerował prawidłowy wynik). Brak możliwości wprowadzenia bł˛edu do programu wynika z charakteru implementacji
i wewn˛etrznej budowy systemu FITS. Testy zakończone tego rodzaju wynikiem
były pomijane w trakcie obliczeń dzi˛eki zastosowaniu odpowiedniej funkcji
wag. Nie miały one wpływu na selekcj˛e asercji.
C
Poprawny wynik obliczeń. System FITS wprowadził zakłócenie, ale jego
efekt nie został wykryty przez funkcj˛e kontrolujac
˛ a˛ poprawność działania
aplikacji, co oznacza, że program zadziałał prawidłowo (program zakończył
si˛e i wygenerował prawidłowy wynik).
I
Niepoprawny wynik obliczeń. Żadna z asercji nie wykryła wprowadzonego
zakłócenia. Jego efekt został wykryty przez funkcj˛e kontrolujac
˛ a˛ poprawność
działania aplikacji (program zakończył si˛e i wygenerował nieprawidłowy
wynik).
A
Naruszenie asercji. Podczas wykonania programu jedna z wprowadzonych
asercji została naruszona w wyniku czego przerwano jego wykonanie.
E
Wyjatek
˛ systemowy. W trakcie wykonywania testu zgłoszony został wyjatek
˛
systemowy na skutek wprowadzonego bł˛edu.
T
Przekroczony czas oczekiwania. Wprowadzone zakłócenie uniemożliwiło
w określonym czasie zakończenie programu, skutkujacego
˛
otrzymaniem jednego z wyników wymienionych powyżej (program został przerwany przez
system FITS).
Tabela 5.1. Wykaz możliwych wyników testu w systemie FITS
85
niach (identyfikator g2), pi˛eciu niewiadomych i pi˛eciu równaniach (identyfikator g5),
pi˛etnastu niewiadomych i pi˛etnastu równaniach (identyfikator g15) oraz dwudziestu pi˛eciu
niewiadomych i dwudziestu pi˛eciu równaniach (identyfikator g25).
Obserwacje przeprowadzono oddzielnie dla każdej z wersji (f oraz i) badanych programów.
Oznacza to, że dla aplikacji k wykonano dwa, a dla aplikacji g osiem eksperymentów
obserwacyjnych.
5.1.4. Wybór zestawów asercji
Podczas procesu selekcji asercji stosowano trzy różne postacie funkcji w(e) określajacej
˛
wartość wagi dla danego wyniku testu (definicja 3.2.13 w punkcie 3.2.10). Dla przewidzianych
wyników testu przedstawionych w tabeli 5.1 przygotowano nast˛epujace
˛ funkcje:



0,






−1,



w(e) = 1,











w(e) =



0,









dla testów, w których nie wprowadzono zakłócenia (N),
dla testów zakończonych poprawnym wynikiem obliczeń (C),
dla testów zakończonych niepoprawnym wynikiem obliczeń (I)
przekroczonym czasem oczekiwania (T) lub
wyjatkiem
˛
systemowym (E).
dla testów, w których nie wprowadzono zakłócenia (N)
zakończonych wyjatkiem
˛
systemowym (E) lub
przekroczonym czasem oczekiwania (T),





−1, dla testów zakończonych poprawnym wynikiem obliczeń (C),





1,
dla testów zakończonych niepoprawnym wynikiem obliczeń (I).
w(e) =



0,









(5.1)
(5.2)
dla testów, w których nie wprowadzono zakłócenia (N)
testów z niepoprawnym wynikiem obliczeń (I) lub
przekroczonym czasem oczekiwania (T),





−1, dla testów zakończonych poprawnym wynikiem obliczeń (C),





1,
dla testów zakończonych wyjatkiem
˛
systemowym (E).
(5.3)
Zaproponowane funkcje w(e) miały na celu ignorowanie wyników testów, w których systemowi FITS nie udało si˛e wprowadzić bł˛edu. Liczba takich testów nie miała wpływu na wartość
86
wykorzystanych parametrów asercji. Funkcja w(e) w postaci 5.1 promowała asercje wykrywajace
˛ dowolny z wyników testów, który użytkownik może uznać za niesatysfakcjonujacy
˛
(niepoprawny, wyjatek
˛ systemowy, przekroczenie czasu oczekiwania). W przypadku funkcji
w(e) w postaci 5.2 ograniczono liczb˛e promowanych asercji, wybierajac
˛ jedynie te, które
zapobiegały niepoprawnemu wynikowi obliczeń, a testy zakończone pozostałymi wynikami zakwalifikowano do ignorowanych. W analogiczny sposób funkcja w(e) w postaci 5.3 promowała
asercje, które zapobiegały powstaniu wyjatku
˛
systemowego wskutek wprowadzonego bł˛edu.
Dla wszystkich zaproponowanych funkcji test zakończony wynikiem poprawnym obniżał
wartość wybranego parametru asercji określajacego
˛
skuteczność. Oznacza to, że asercja,
która wykryła bład,
˛ mimo iż jego skutek nie wpłynał
˛ na poprawny wynik działania aplikacji,
miała niższa˛ wartość badanego parametru niż asercja, dla której takie zachowanie nie zostało
zaobserwowane. Obniża to wartość skuteczności dla asercji, które zgłaszaja˛ fałszywe alarmy.
Przyporzadkowanie
˛
wag o tej samej wartości bezwzgl˛ednej miało na celu zrównoważenie
wpływu negatywnego i pozytywnego na parametr asercji dla jednostkowego testu.
Strategie selekcji zestawów asercji dla aplikacji k oraz g zastosowane zarówno dla implementacji typu f oraz i przedstawiono odpowiednio w tabelach 5.2 i 5.3. Wyniki eksperymentów
wprowadzania zakłóceń w aplikacjach, w których nie zastosowano asercji oraz wprowadzono
wszystkie asercje posłuża˛ jako dane referencyjne do analizy wyników z pozostałych wersji
aplikacji. Parametry dla metody selekcji asercji, takie jak liczba asercji oraz ograniczenia na
ich całkowity koszt dynamiczny zostały wybrane arbitralnie z uwzgl˛ednieniem zapewnienia
istotnego spadku ich wartości w programie. Tak wybrane parametry metody powinny pozwolić
wykazać zasadność jej stosowania.
Zestawy asercji były wybierane na podstawie całościowego wyniku eksperymentu
z punktu 5.1.3 dla jednej z dwóch wersji badanej aplikacji k oraz na podstawie całościowych
i dedykowanych danej wersji z określona˛ liczba˛ stosowanych równań wyników eksperymentów
aplikacji g. W każdym przypadku brano pod uwag˛e wszystkie obserwowane obszary zakłóceń.
Nie wybierano zestawów asercji zoptymalizowanych tylko dla jednego z obszarów zakłóceń
w celu przygotowania uniwersalnego podzbioru asercji reagujacego
˛
na różnorodne rodzaje
bł˛edów.
Zestawy asercji dla badanego programu zostały wybrane poprzez rozwiazania
˛
zadania programowania liniowego dla funkcji celu opisujacej
˛ maksymalizacj˛e skuteczności bezwzgl˛ednej
lub wzgl˛ednej (w zależności od wybranej strategii) przy ograniczeniach zwiazanych
˛
z liczba˛
aktywnych asercji, całkowitym kosztem dynamicznym asercji (wybrane kryteria dla aplikacji k)
lub położeniem asercji w programie (wybrane kryteria dla aplikacji g). Zostały one wyznaczone
przez narz˛edzie z pakietu AEM automatyzujace
˛ selekcj˛e asercji na podstawie zadanej strategii
oraz posiadanych danych z etapu obserwacji asercji. Przykłady przebiegu obliczeń zostały
przedstawione w punkcie 3.3.4.
87
B
Wszystkie asercje w programie zostały usuni˛ete (brak asercji).
W
Wszystkie asercje sa˛ stosowane w programie.
N
Wybór do dziesi˛eciu asercji przy zastosowaniu funkcji celu maksymalizujacej
˛
całkowita˛ skuteczność bezwzgl˛edna.˛ Stosowano funkcj˛e w(e) w postaci 5.1.
Z
Wybór do dziesi˛eciu asercji przy zastosowaniu funkcji celu maksymalizujacej
˛
całkowita˛ skuteczność wzgl˛edna.˛ Stosowano funkcj˛e w(e) w postaci 5.1.
DN Wybór asercji według funkcji celu maksymalizujacej
˛ całkowita˛ skuteczność
bezwzgl˛edna˛ przy ograniczeniu na całkowity koszt dynamiczny wybranych
asercji ustalony na dziesi˛eciokrotność kosztu asercji o najmniejszym całkowitym koszcie dynamicznym. Stosowano funkcj˛e w(e) w postaci 5.1.
Dodatkowe ograniczenie na całkowity koszt dynamiczny wybranych asercji
miało na celu maksymalne skrócenie czasu działania aplikacji przeznaczonego na sprawdzanie asercji.
DZ
Wybór asercji według funkcji celu maksymalizujacej
˛ całkowita˛ skuteczność
wzgl˛edna˛ przy ograniczeniu na całkowity koszt dynamiczny wybranych
asercji ustalony na dziesi˛eciokrotność kosztu asercji o najmniejszym całkowitym koszcie dynamicznym. Stosowano funkcj˛e w(e) w postaci 5.1.
Dodatkowe ograniczenie na całkowity koszt dynamiczny wybranych asercji
miało na celu maksymalne skrócenie czasu działania aplikacji przeznaczonego na sprawdzanie asercji.
I
Przy selekcji asercji zastosowano funkcj˛e w(e) w postaci 5.2 zamiast funkcji
w(e) w postaci 5.1.
X
w(e) w postaci 5.1.
Tabela 5.2. Strategie selekcji asercji dla aplikacji k
88
B
Wszystkie asercje w programie zostały usuni˛ete (brak asercji).
W Wszystkie asercje sa˛ stosowane w programie.
R
Stosowane sa˛ asercje z cz˛eści wyznaczajacej
˛
rozwiazanie
˛
układu równań.
Asercje z cz˛eści przeprowadzajacej
˛
weryfikacj˛e znalezionego rozwiazania
˛
układu równań zostały usuni˛ete.
S
Stosowane sa˛ asercje z cz˛eści przeprowadzajacej
˛ weryfikacj˛e znalezionego
rozwiazania
˛
układu równań. Asercje z cz˛eści wyznaczajacej
˛
rozwiazanie
˛
układu równań zostały usuni˛ete.
N
Co najmniej pi˛eciokrotne zmniejszenie liczby asercji przy zastosowaniu funkcji celu maksymalizujacej
˛
całkowita˛ skuteczność bezwzgl˛edna.˛
Stosowano funkcj˛e w(e) w postaci 5.1.
Z
Co najmniej pi˛eciokrotne zmniejszenie liczby asercji przy zastosowaniu
funkcji celu maksymalizujacej
˛ całkowita˛ skuteczność wzgl˛edna.˛ Stosowano
funkcj˛e w(e) w postaci 5.1.
I
w(e) w postaci 5.1.
X
w(e) w postaci 5.1.
d
Przy selekcji asercji wykorzystano wyniki testów otrzymane dla określonej
wersji programu (wyłacznie
˛
wyniki z obserwacji aplikacji g2 dla kolejnych
procedur selekcji asercji wzgl˛edem różnych kryteriów dla aplikacji w wersji
g2 itd.).
t
Przy selekcji asercji wykorzystano wyniki testów otrzymane dla wszystkich
wersji programu (łaczne
˛
wyniki z obserwacji aplikacji g2, g5, g15 i g25 dla
kolejnych procedur selekcji asercji wzgl˛edem różnych kryteriów dla aplikacji
w wersji g2 itd.).
Tabela 5.3. Strategie selekcji asercji dla aplikacji g
89
Przyrost statycznej (w kodzie) i dynamicznej (wykonanych) liczby instrukcji w badanych
wersjach programów oraz liczb˛e wybranych asercji przedstawiono odpowiednio w tabeli 5.4 dla
aplikacji k i tabeli 5.5 dla wybranych wersji aplikacji g (dla 2 i 25 rozwiazywanych
˛
równań).
W pierwszej cz˛eści tabel przedstawiono dane dotyczace
˛ wersji programów operujacych
˛
na
liczbach zmiennoprzecinkowych, w drugiej wykorzystujacych
˛
bibliotek˛e SoftFloat. Stosowane
identyfikatory aplikacji sa˛ zgodne z przedstawionymi strategiami selekcji asercji w tabelach 5.2
i 5.3. Pomiar liczby instrukcji został wykonany z użyciem systemu FITS. Przyrosty podano
wzgl˛edem wersji aplikacji, w której nieaktywne były wszystkie asercje (program bez asercji).
Przyrost liczby instrukcji, zarówno w kodzie statycznym jak i wykonanych, przekładajacy
˛
si˛e mi˛edzy innymi na szybkość wykonania programu, jest mniejszy po zastosowaniu metody
selekcji asercji dla wszystkich wersji badanych aplikacji.
Eksperyment
Liczba instrukcji
Liczba asercji
w kodzie
przyrosta
wykonanych
przyrosta
fB
fW
fN
fZ
fDN
fDZ
fDNI
fDZI
fDNX
fDZX
157
9368
207
207
207
188
207
193
182
182
–
5866,9
31,8
31,8
31,8
19,7
31,8
22,9
15,9
15,9
2811600
152564400
5781600
5193600
2826600
2825400
2826600
2825400
2826600
2826600
–
5326,25
105,63
84,72
0,53
0,49
0,53
0,49
0,53
0,53
0
1851
10
10
10
7
10
8
5
5
iB
iW
iN
iZ
iDN
iDZ
iDNI
iDZI
iDNX
iDZX
1224
24314
1453
1464
1453
1464
1431
1466
1431
1466
–
78075350
1886,4 2014764686
18,7
114726900
19,6
98697171
18,7
114726900
19,6
98697171
16,9
94966343
19,8 102049629
16,9
94966343
19,8 102049629
–
2480,54
46,94
26,41
46,94
26,41
21,63
30,71
21,63
30,71
0
1851
10
10
10
10
10
8
10
10
a
przyrosty podano w procentach wzgl˛edem wielkości implementacji bez asercji
Tabela 5.4. Liczba instrukcji dla poszczególnych wersji aplikacji k
Dla aplikacji kf przy zastosowaniu metody selekcji asercji bez kryterium uwzgl˛edniajacego
˛
koszt wybranych asercji otrzymano prawie dwustukrotnie mniejszy przyrost liczby instrukcji
w kodzie aplikacji oraz ponad pi˛ećdziesi˛eciokrotnie mniejszy wzrost liczby instrukcji wykonanych niż w wersji programu, w której stosowano wszystkie asercje. Po dodaniu kryterium
90
Eksperyment
a
Liczba instrukcji
Liczba asercji
w kodzie
przyrosta
wykonanych
przyrosta
2fB
2fW
2fRW
2fSW
2fdRN
2fdRNI
2fdRNX
2fdRZ
2fdRZI
2fdRZX
2ftRN
2ftRNI
2ftRNX
2ftRZ
2ftRZI
2ftRZX
2fdSN
2fdSNI
2fdSNX
2fdSZ
2fdSZI
2fdSZX
2ftSN
2ftSNI
2ftSNX
2ftSZ
2ftSZI
2ftSZX
216
631
536
327
287
281
290
288
286
309
296
326
282
296
326
288
283
283
216
283
283
216
283
283
216
283
283
216
–
192,13
148,15
51,39
32,87
30,09
34,26
33,33
32,41
43,06
37,04
50,93
30,56
37,04
50,93
33,33
31,02
31,02
0,00
31,02
31,02
0,00
31,02
31,02
0,00
31,02
31,02
0,00
368
2136
1708
796
856
827
859
859
833
874
908
877
823
735
882
670
511
511
368
511
511
368
511
511
368
511
511
368
–
480,43
364,13
116,30
132,61
124,73
133,42
133,42
126,36
137,50
146,74
138,32
123,64
99,73
139,67
82,07
38,86
38,86
0,00
38,86
38,86
0,00
38,86
38,86
0,00
38,86
38,86
0,00
0
66
60
6
12
12
12
12
12
12
12
12
12
12
12
12
1
1
0
1
1
0
1
1
0
1
1
0
25fB
25fW
25fRW
25fSW
25fdRN
25fdRNI
25fdRNX
25fdRZ
25fdRZI
25fdRZX
25ftRN
25ftRNI
25ftRNX
25ftRZ
25ftRZI
25ftRZX
25fdSN
25fdSNI
25fdSNX
25fdSZ
25fdSZI
25fdSZX
25ftSN
25ftSNI
25ftSNX
25ftSZ
25ftSZI
25ftSZX
299
631
536
410
331
334
309
339
334
340
333
326
315
314
326
312
387
387
299
387
387
299
387
387
299
387
387
299
–
111,04
79,26
37,12
10,70
11,71
3,34
13,38
11,71
13,71
11,37
9,03
5,35
5,02
9,03
4,35
29,43
29,43
0,00
29,43
29,43
0,00
29,43
29,43
0,00
29,43
29,43
0,00
66447
924137
876306
114278
451754
499101
216651
451000
499101
406330
450953
517733
208402
201755
517531
174918
70503
70503
66447
70503
70503
66447
70503
70503
66447
70503
70503
66447
–
1290,79
1218,80
71,98
579,87
651,13
226,05
578,74
651,13
511,51
578,67
679,17
213,64
203,63
678,86
163,24
6,10
6,10
0,00
6,10
6,10
0,00
6,10
6,10
0,00
6,10
6,10
0,00
0
66
60
6
12
12
12
12
12
12
12
12
12
12
12
12
1
1
0
1
1
0
1
1
0
1
1
0
Tabela 5.5. Liczba instrukcji dla poszczególnych wersji aplikacji g
91
Eksperyment
a
Liczba instrukcji
Liczba asercji
w kodzie
przyrosta
wykonanych
przyrosta
2iB
2iW
2iRW
2iSW
2idRN
2idRNI
2idRNX
2idRZ
2idRZI
2idRZX
2itRN
2itRNI
2itRNX
2itRZ
2itRZI
2itRZX
2idSN
2idSNI
2idSNX
2idSZ
2idSZI
2idSZX
2itSN
2itSNI
2itSNX
2itSZ
2itSZI
2itSZX
1524
3114
2666
2030
1860
1854
1665
1851
1851
1665
2109
2255
1661
1827
2003
1661
1825
1825
1524
1825
1825
1524
1825
1825
1524
1825
1825
1524
–
104,33
74,93
33,20
22,05
21,65
9,25
21,46
21,46
9,25
38,39
47,97
8,99
19,88
31,43
8,99
19,75
19,75
0,00
19,75
19,75
0,00
19,75
19,75
0,00
19,75
19,75
0,00
8830
34370
25739
17461
17257
17250
9391
17227
17227
9391
19787
22308
9388
15560
17055
9388
12365
12365
8830
12365
12365
8830
12365
12365
8830
12365
12365
8830
–
289,24
191,49
97,75
95,44
95,36
6,35
95,10
95,10
6,35
124,09
152,64
6,32
76,22
93,15
6,32
40,03
40,03
0,00
40,03
40,03
0,00
40,03
40,03
0,00
40,03
40,03
0,00
0
66
60
6
12
12
12
12
12
12
12
12
12
12
12
12
1
1
0
1
1
0
1
1
0
1
1
0
25iB
25iW
25iRW
25iSW
25idRN
25idRNI
25idRNX
25idRZ
25idRZI
25idRZX
25itRN
25itRNI
25itRNX
25itRZ
25itRZI
25itRZX
25idSN
25idSNI
25idSNX
25idSZ
25idSZI
25idSZX
25itSN
25itSNI
25itSNX
25itSZ
25itSZI
25itSZX
1674
3297
2816
2211
2384
2440
1869
1992
2274
1869
2257
2403
1811
1975
2151
1811
2006
2006
1674
2006
2006
1674
2006
2006
1674
2006
2006
1674
–
96,95
68,22
32,08
42,41
45,76
11,65
19,00
35,84
11,65
34,83
43,55
8,18
17,98
28,49
8,18
19,83
19,83
0,00
19,83
19,83
0,00
19,83
19,83
0,00
19,83
19,83
0,00
5015184
15891646
14613810
6293020
12088750
12056480
5200029
5402979
5841979
5200029
12291052
12290928
5034234
5923590
6061107
5034234
5477478
5477478
5015184
5477478
5477478
5015184
5477478
5477478
5015184
5477478
5477478
5015184
–
216,87
191,39
25,48
141,04
140,40
3,69
7,73
16,49
3,69
145,08
145,07
0,38
18,11
20,86
0,38
9,22
9,22
0,00
9,22
9,22
0,00
9,22
9,22
0,00
9,22
9,22
0,00
0
66
60
6
12
12
12
12
12
12
12
12
12
12
12
12
1
1
0
1
1
0
1
1
0
1
1
0
Tabela 5.5. Liczba instrukcji dla poszczególnych wersji aplikacji g (c.d.)
92
ograniczenia kosztu dla instrukcji wykonanych dodatkowo spadła liczba instrukcji w kodzie
średnio o 30% dla wszystkich wersji aplikacji poza fDN oraz liczba instrukcji wykonanych
o około 50%. W zależności od strategii selekcji aktywnych było od pi˛eciu do dziesi˛eciu asercji.
Wersja i programu k bez asercji charakteryzowała si˛e wi˛eksza˛ liczba˛ instrukcji w stosunku
do kfB z uwagi na użycie implementacji programowej do wykonywania obliczeń zmiennoprzecinkowych. Zastosowanie metody selekcji asercji spowodowało ponad stukrotny spadek
przyrostu liczby instrukcji w kodzie i ponad pi˛ećdziesi˛eciokrotny spadek liczby instrukcji
wykonanych. Dla wi˛ekszości wersji wybrano dziesi˛eć asercji. Zastosowanie dodatkowego
kryterium uwzgl˛edniajacego
˛
koszt nie wpłyn˛eło w znaczacy
˛ sposób na spadek przyrostu liczby
instrukcji. Powodem był wpływ optymalizacji kodu stosowanej przez kompilator.
Aplikacja g charakteryzowała si˛e w wi˛ekszości przypadków wi˛ekszymi przyrostami liczby
instrukcji niż aplikacja k, ponieważ podczas selekcji asercji nie stosowano w niej bezpośrednio
ograniczenia zwiazanego
˛
z kosztem. Należy również zauważyć, że suma przyrostów liczby
instrukcji dla aplikacji 2fSW i 2fRW nie jest równa przyrostowi dla aplikacji 2fW. Jest to
skutkiem działania optymalizacji kodu stosowanej przez kompilator. Analogiczna sytuacja
wyst˛epuje w wersji i aplikacji g.
Wraz ze wzrostem liczby rozwiazywanych
˛
równań przyrost liczby instrukcji w kodzie
wzgl˛edem implementacji bez asercji maleje dla różnych strategii selekcji asercji, przy czym
spadki te sa˛ wi˛eksze dla implementacji typu f. Liczba instrukcji wykonanych przy tych samych
założeniach rośnie w przypadku stosowania strategii R i odpowiednio maleje przy stosowaniu
strategii S. Wia˛że si˛e to z lokalizacja˛ asercji. W pierwszym przypadku sa˛ one sprawdzane
wielokrotnie w trakcie rozwiazywania
˛
układu równań. Dla strategii S sprawdzenie odbywa si˛e
jednokrotnie, po zakończeniu etapu wyznaczania rozwiazania
˛
układu równań, co wpływa na
mniejszy przyrost liczby instrukcji.
Zastosowanie złożonych strategii optymalizacji SNX i SZX skutkowało wyborem pustego
zbioru asercji. Oznacza to, że nie obserwowano naruszeń asercji dla tych strategii i niemożliwe
było rozwiazanie
˛
zadania programowania liniowego. Dla pozostałych wersji aplikacji, w zależności od strategii selekcji, aktywnych było od jednej do dwunastu asercji.
Dla aplikacji g o liczbie równań, dla których nie przedstawiono w tabelach szczegółowych
wyliczeń, podane wyżej wnioski sa˛ analogiczne.
Porównanie przyrostu liczby wykonanych instrukcji pomi˛edzy wersja˛ aplikacji ze wszystkimi asercjami a wersjami, w której wybrano pewna˛ liczb˛e asercji pokazuje jak istotne jest
wprowadzenie odpowiednich ograniczeń podczas procedury selekcji asercji, w szczególności
zwiazanych
˛
z kosztem ich stosowania.
93
5.1.5. Eksperymenty weryfikujace
˛
W końcowym etapie, w celu weryfikacji wyników zastosowania metody selekcji optymalnego zestawu asercji według ustalonej strategii przeprowadzono eksperymenty z wybranymi
aktywnymi asercjami przy założeniu możliwości ich zakłócania oraz, w wypadku ich
naruszenia, przerywania działania programu (wynik testu A według tabeli 5.1).
Do
przeprowadzenia eksperymentów weryfikujacych
˛
użyto tego samego środowiska, które
posłużyło do pomiarów parametrów asercji. Scharakteryzowane zostało ono w punktach 5.1.1
i 5.1.3. Bł˛edy wprowadzano do badanych wersji programów z użyciem systemu FITS, wyniki
były analizowane i opracowane za pomoca˛ narz˛edzi z pakietu AEM.
Przeprowadzono eksperymenty weryfikujace
˛ skuteczność wybranych asercji w procesie
wykrywania bł˛edów na nast˛epujacych
˛
wersjach programu:
— z nieaktywnymi wszystkimi asercjami (identyfikator B),
— z aktywnymi wszystkimi asercjami (identyfikator W),
— z aktywnymi wybranymi asercjami (identyfikatory eksperymentów zgodne z przedstawionymi strategiami selekcji asercji w tabelach 5.2 i 5.3).
Dla wyżej opisanych eksperymentów weryfikujacych
˛
używano takich samych parametrów
zwiazanych
˛
z wprowadzaniem bł˛edów do aplikacji jakie przedstawiono w punkcie 5.1.3.
Niektóre z nich, z uwagi na losowy charakter, mogły różnić si˛e na poziomie na przykład
zakłóconego bitu w kodzie instrukcji. Wybrane asercje były przygotowane do wykrywania tego
rodzaju bł˛edów. Dodatkowo przeprowadzono seri˛e eksperymentów dla aplikacji k i g, która
polegała na wprowadzeniu mutacji do programu i obserwacji zachowania asercji. Dzi˛eki temu
b˛edzie możliwa ocena skuteczności wybranych asercji na podstawie zamkni˛etej klasy bł˛edów
do wykrywania zakłóceń innego rodzaju. Dla badanych aplikacji przygotowano skrypt, który
dokonywał losowej zamiany zmiennych tego samego typu w kodzie źródłowym określonej
wersji badanego programu. Przygotowana aplikacja była automatycznie kompilowana i uruchamiana. Rejestrowany był wynik przeprowadzonego testu. Dla każdej z badanych wersji
aplikacji przygotowano pi˛eć tysi˛ecy mutacji.
Dla każdej z mutacji generowano dziesi˛eć
losowych układów równań o ilości niewiadomych od dwóch do dwudziestu pi˛eciu i dokonywano testowego uruchomienia programu.
Poniżej przedstawiono wyniki oraz wnioski z przeprowadzonych eksperymentów. W przypadku aplikacji g, z uwagi na duża˛ liczb˛e wersji testowanych programów, po analizie otrzymanych rezultatów zdecydowano o umieszczeniu szczegółowych wyników tylko dla wersji
aplikacji o skrajnych liczbach równań (wersje g2 i g25). Dla pozostałych dwóch wersji aplikacji
charakter otrzymanych wyników oraz wnioski sa˛ zbieżne z zaprezentowanymi.
Załaczone
˛
rysunki prezentuja˛ procentowy rozkład wszystkich możliwych wyników
przeprowadzonych testów. Ich udział dla ograniczonego zestawu wyników testu zaprezentowano w formie tabelarycznej.
94
95
(e) kod statyczny
(d) rejestry FPU
(b) adresy obszaru danych
Rysunek 5.1. Rozkład wyników testów aplikacji k dla określonych obszarów zakłóceń
(c) wykonane instrukcje
(a) rejestry procesora
Na rysunku 5.1 przedstawiono histogramy opisujace
˛ procentowy rozkład wyników
testów przeprowadzonych eksperymentów z użyciem FITS dla wszystkich wersji aplikacji
k w poszczególnych obszarach wprowadzania zakłóceń wymienionych w punkcie 5.1.3.
Zastosowane identyfikatory wyników testu sa˛ zgodne z przedstawionymi w tabeli 5.1.
Uwzgl˛edniono jedynie te testy podczas których systemowi FITS udało si˛e wygenerować
bład
˛ w działaniu aplikacji (pomini˛eto testy z wynikiem N). Wprowadzone asercje maja˛
wpływ głównie na obniżenie liczby niepoprawnych zakończeń programów dzi˛eki wcześniejszej
detekcji bł˛edów. Najwi˛eksza liczba wykrytych bł˛edów dotyczy zakłóceń w obszarach instrukcji
i kodu statycznego aplikacji. Najmniejszy wpływ wybranych asercji zaobserwowano dla
bł˛edów generowanych w rejestrach procesora dla wersji f aplikacji. Wynika to z faktu, iż
wykryte asercje opisywały głównie zależności dla zmiennych zmiennoprzecinkowych programu. Mimo istotnego zmniejszenia liczby asercji pomi˛edzy wersja˛ W a zoptymalizowanymi
wersjami programu w wi˛ekszości przypadków nie jest zauważalna proporcjonalna zmiana
liczby naruszeń asercji. Dla wersji i omawianej aplikacji nie rejestrowano naruszeń asercji
w obszarze zakłóceń rejestrów jednostki zmiennoprzecinkowej ponieważ implementacja ta nie
wykorzystywała liczb zmiennoprzecinkowych. Ponadto obserwowana jest mniejsza o około
od 5% (obszar rejestrów procesora) do nawet 40% (obszar adresów) liczba rejestrowanych
wyjatków
˛
systemowych. Zauważalny jest także (w przypadku zakłóceń rejestrów procesora)
do 3% wzrost liczby naruszeń asercji. Asercje wybrane dla wersji i, poza strategia˛ DNX,
umożliwiaja˛ efektywna˛ detekcj˛e bł˛edów, które prowadziły do otrzymania nieprawidłowego
wyniku działania aplikacji. Zastosowanie strategii DNX prowadziło do selekcji takiego zbioru
aktywnych asercji, która wykrywała niewiele niepoprawnych wyników I. Rezultat ten znacznie
si˛e poprawił przy zastosowaniu strategii wykorzystujacej
˛
miar˛e skuteczności wzgl˛ednej.
Pomimo zastosowania strategii X nie zauważono wzrostu detekcji bł˛edów prowadzacych
˛
do
wystapienia
˛
wyjatku
˛ systemowego. W obszarze zakłóceń adresów wybranie podzbioru asercji
pozwoliło na ograniczanie fałszywych alarmów, w przypadku gdy test kończył si˛e wynikiem C
mimo wprowadzonego zakłócenia.
Analogiczne histogramy dla aplikacji g2 i g25 przedstawiono na rysunku 5.2. Pomini˛eto obszar zakłóceń w rejestrach jednostki zmiennoprzecinkowej, w którym stosunek testów o wyniku
innym niż C do testów o wyniku C był bliski zera. Wprowadzone asercje maja˛ wpływ głównie
na obniżenie liczby niepoprawnych zakończeń programów poprzez wcześniejsze wykrycie
bł˛edów. Dla wszystkich obszarów zakłóceń wi˛eksze pokrycie bł˛edów zapewnia selekcja asercji
według strategii S w porównaniu do strategii R zapewniajac
˛ poziom maksymalnie do 3%
mniejszy dla wyników I niż przy zastosowaniu wszystkich asercji. Nie dotyczy to eksperymentów, w których stosowano dodatkowo strategi˛e X. Wprowadzone asercje nie wykrywały
bł˛edów z efektem wyjatku
˛
systemowego. W obszarze rejestrów procesora dla aplikacji g25
zaobserwowano wzrost liczby testów z wynikiem C o około 20% po wprowadzeniu asercji
96
97
Rysunek 5.2. Rozkład wyników testów aplikacji g dla określonych obszarów zakłóceń
(b) rejestry procesora (wersja i)
(a) rejestry procesora (wersja f)
(c) adresy obszaru danych (wersja f)
(d) adresy obszaru danych (wersja i)
Rysunek 5.2. Rozkład wyników testów aplikacji g dla określonych obszarów zakłóceń (c.d.)
98
99
(f) wykonane instrukcje (wersja i)
(e) wykonane instrukcje (wersja f)
(g) kod statyczny (wersja f)
(h) kod statyczny (wersja i)
100
do programu. Może to być spowodowane innym zbiorem wygenerowanych zakłóceń przez
system FITS dla konkretnej wersji aplikacji, gdyż asercje nie miały wpływu na przywrócenie
prawidłowego stanu działania programu (wprowadzone asercje badały jedynie stan zmiennych
w programie, bez ich modyfikacji). Podobna sytuacja obserwowana była w przypadku obszaru
kodu statycznego dla niektórych wersji aplikacji. W obszarze adresów zauważalny był spadek
liczby testów z wynikiem I przy jednoczesnym wzroście naruszeń asercji dla wzrastajacej
˛ liczby
równań w rozwiazywanym
˛
układzie. Asercje wykrywały wprowadzone zakłócenia, mimo iż nie
miały one wpływu na wynik przeprowadzonych obliczeń. Zauważalne jest to w szczególności
dla asercji wybranych według strategii R.
Tabele 5.6 i 5.7 przedstawiaja˛ procentowy udział testów (z wykluczeniem testów o wyniku
N) przeprowadzonych w systemie FITS zakończonych naruszeniem asercji w ogólnej liczbie
wszystkich testów zakończonych innym wynikiem testu niż wynik poprawny (niepoprawny,
wyjatek
˛
systemowy, przekroczony czas oczekiwania).
W kolejnych kolumnach podano
identyfikator eksperymentu, procentowy udział testów dla poszczególnych obszarów zakłóceń
oraz ogólny udział testów dla wcześniej wymienionych obszarów. Aplikacja k w wersji f
charakteryzuje si˛e najwi˛ekszym pokryciem bł˛edów przez asercje w obszarach jednostki
zmiennoprzecinkowej (od 62% do 87%), najmniejszym w obszarze rejestrów (do 3%). Dla
pozostałych obszarów pokrycie bł˛edów wynosi około 20%-30%. Różnica pomi˛edzy pokryciem
bł˛edów dla wersji W a pozostałymi wersjami o ograniczonej liczbie asercji wynosi średnio
5 punktów procentowych.
Dla wersji i aplikacji k pokrycie bł˛edów przez asercje było
najwi˛eksze w obszarze adresów i wynosiło do 51%. Ogólne pokrycie wynosiło około 17%,
poza wersja˛ X aplikacji, dla której spadło do 3%. Dla aplikacji g wraz ze wzrostem liczby
równań w rozwiazywanym
˛
układzie obserwowany jest wzrost pokrycia bł˛edów przez asercje.
Stosowanie optymalizacji liczby asercji z atrybutem R powodowało spadek pokrycia do 50%.
Dla asercji z obszaru S utrzymywało si˛e ono na stałym poziomie z wykluczeniem wersji
aplikacji dla których nie znaleziono rozwiazań
˛
w metodzie selekcji asercji. Aplikacja w wersji
i charakteryzowała si˛e mniejszym pokryciem bł˛edów o średnio 8 punktów procentowych.
Znaczaco
˛ odbiegajacy
˛ od średniego spadek zaobserwowano dla strategii X. Stosowanie strategii
d i t dawało zróżnicowane efekty.
Dla aplikacji g2 lepsze wyniki osiagni˛
˛ eto stosujac
˛
całościowy zbiór zebranych danych z obserwacji przy selekcji asercji. Z kolei dla aplikacji
g25 w wi˛ekszości przypadków wyniki te sa˛ gorsze o kilka punktów procentowych. Zbyt
mała ilość danych z obserwacji zachowania asercji wpłyn˛eła na wybór gorszego ich podzbioru.
Zbyt duża ilość danych może pogorszyć parametry wybranych asercji, jednak różnice te nie
sa˛ tak znaczace
˛ jak w poprzednim przypadku. Pojawiajace
˛ si˛e niekiedy wzrosty pokrycia
bł˛edów dla aplikacji o pomniejszonej liczbie asercji należy uznać za przypadkowe wahania
wynikajace
˛ z charakteru przeprowadzanych testów. Wprowadzane do programów zakłócenia
były generowane w sposób losowy.
101
Eksperyment
a
Lokalizacja zakłóceń
Ogółem
rejestry
adresy
FPU
instrukcje
koda
fW
fN
fZ
fDN
fDZ
fDNI
fDZI
fDNX
fDZX
1,54
0,96
0,68
0,32
1,44
1,19
0,68
2,93
1,57
34,95
28,33
34,76
22,66
23,03
23,66
17,65
18,40
19,21
87,76
84,31
73,17
77,78
84,85
64,71
86,96
63,64
61,90
30,40
28,50
30,26
21,47
22,47
26,20
24,95
18,35
22,67
26,05
25,19
28,18
24,34
23,14
25,50
22,22
21,11
22,93
26,26
24,63
26,66
20,65
20,60
22,70
21,22
17,91
20,22
iW
iN
iZ
iDN
iDZ
iDNI
iDZI
iDNX
iDZX
22,13
2,68
8,28
2,65
8,28
6,58
3,57
1,62
4,25
96,15
47,62
46,88
50,00
46,88
16,67
25,00
21,74
51,61
–
–
–
–
–
–
–
–
–
22,53
20,03
20,61
19,89
20,95
15,76
16,51
1,71
20,89
19,17
18,63
22,21
18,54
21,78
17,72
17,55
4,32
19,37
22,80
16,88
19,66
16,80
19,63
15,00
14,64
3,03
17,98
wszystkie wielkości podano w procentach
Tabela 5.6. Udział testów aplikacji k, w których doszło do naruszeń asercji, w liczbie testów o innym
kodzie zakończenia niż poprawny
102
Eksperyment
a
Ogółem
rejestry
adresy
FPU
instrukcje
koda
2fW
2fRW
2fSW
2fdRN
2fdRNI
2fdRNX
2fdRZ
2fdRZI
2fdRZX
2ftRN
2ftRNI
2ftRNX
2ftRZ
2ftRZI
2ftRZX
2fdSN
2fdSNI
2fdSNX
2fdSZ
2fdSZI
2fdSZX
2ftSN
2ftSNI
2ftSNX
2ftSZ
2ftSZI
2ftSZX
25,00
20,75
11,60
7,21
4,91
7,88
7,21
8,27
5,74
11,36
17,22
8,67
18,42
15,79
4,90
17,26
17,26
0,00
17,26
17,26
0,00
17,26
17,26
0,00
17,26
17,26
0,00
67,96
53,41
56,90
30,91
33,93
30,30
26,79
32,31
26,98
34,72
30,26
39,06
27,69
30,14
33,33
29,63
29,63
0,00
29,63
29,63
0,00
29,63
29,63
0,00
29,63
29,63
0,00
33,33
33,33
40,00
26,67
9,09
20,00
33,33
16,67
14,29
12,50
20,00
16,67
12,50
33,33
16,67
57,14
57,14
0,00
57,14
57,14
0,00
57,14
57,14
0,00
57,14
57,14
0,00
26,21
19,61
19,75
15,05
13,91
12,31
14,24
13,64
12,64
15,52
20,84
14,46
18,58
18,54
11,66
18,36
18,36
0,00
18,36
18,36
0,00
18,36
18,36
0,00
18,36
18,36
0,00
32,68
28,60
24,10
8,83
9,02
9,07
12,11
13,85
7,71
7,66
17,66
8,75
12,72
13,23
9,47
15,57
15,57
0,00
15,57
15,57
0,00
15,57
15,57
0,00
15,57
15,57
0,00
30,28
24,30
20,74
12,30
11,33
11,42
12,82
13,57
10,43
13,24
19,66
12,68
17,35
17,23
10,70
18,22
18,22
0,00
18,22
18,22
0,00
18,22
18,22
0,00
18,22
18,22
0,00
25fW
25fRW
25fSW
25fdRN
25fdRNI
25fdRNX
25fdRZ
25fdRZI
25fdRZX
25ftRN
25ftRNI
25ftRNX
25ftRZ
25ftRZI
25ftRZX
25fdSN
25fdSNI
25fdSNX
25fdSZ
25fdSZI
25fdSZX
25ftSN
25ftSNI
25ftSNX
25ftSZ
25ftSZI
25ftSZX
35,85
24,86
28,04
18,03
20,84
12,38
17,99
21,26
25,97
18,29
25,48
10,30
21,14
25,18
7,66
32,66
32,66
0,00
32,66
32,66
0,00
32,66
32,66
0,00
32,66
32,66
0,00
76,52
50,00
73,33
37,25
18,05
27,47
32,50
18,05
28,57
36,19
24,63
30,65
31,61
26,98
34,87
66,67
66,67
0,00
66,67
66,67
0,00
66,67
66,67
0,00
66,67
66,67
0,00
80,00
50,00
44,44
50,00
21,05
14,29
33,33
21,05
25,00
46,15
12,50
15,79
14,29
42,86
9,09
46,67
46,67
0,00
46,67
46,67
0,00
46,67
46,67
0,00
46,67
46,67
0,00
31,14
30,68
28,02
22,00
29,13
21,14
23,07
29,13
22,65
20,54
25,55
15,99
26,87
28,68
17,79
37,38
37,38
0,00
37,38
37,38
0,00
37,38
37,38
0,00
37,38
37,38
0,00
34,08
29,84
26,35
13,10
16,42
13,31
13,78
16,42
13,21
12,23
20,87
11,86
17,31
19,81
11,97
23,28
23,28
0,00
23,28
23,28
0,00
23,28
23,28
0,00
23,28
23,28
0,00
36,74
30,87
28,93
19,01
22,29
17,37
19,40
22,38
20,38
18,31
23,86
14,37
23,08
25,04
14,87
32,03
32,03
0,00
32,03
32,03
0,00
32,03
32,03
0,00
32,03
32,03
0,00
Tabela 5.7. Udział testów aplikacji g, w których doszło do naruszeń asercji, w liczbie testów o innym
kodzie zakończenia niż poprawny
103
Eksperyment
a
Ogółem
rejestry
adresy
FPU
instrukcje
koda
2iW
2iRW
2iSW
2idRN
2idRNI
2idRNX
2idRZ
2idRZI
2idRZX
2itRN
2itRNI
2itRNX
2itRZ
2itRZI
2itRZX
2idSN
2idSNI
2idSNX
2idSZ
2idSZI
2idSZX
2itSN
2itSNI
2itSNX
2itSZ
2itSZI
2itSZX
18,90
13,11
15,90
8,50
10,67
0,98
9,94
9,94
0,98
13,58
12,61
0,65
8,96
7,08
0,65
15,92
15,92
0,00
15,92
15,92
0,00
15,92
15,92
0,00
15,92
15,92
0,00
64,10
68,57
67,92
41,67
43,75
2,00
43,24
43,24
2,00
58,82
42,42
5,26
39,02
51,28
5,26
59,57
59,57
0,00
59,57
59,57
0,00
59,57
59,57
0,00
59,57
59,57
0,00
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
25,52
13,99
22,94
11,35
9,95
2,80
10,57
10,57
2,80
12,78
13,25
3,41
8,55
10,28
3,41
22,48
22,48
0,00
22,48
22,48
0,00
22,48
22,33
0,00
22,33
22,33
0,00
21,84
17,08
18,03
8,22
8,67
1,45
5,83
5,83
1,45
11,45
13,57
3,43
11,49
10,64
3,43
18,85
18,85
0,00
18,85
18,85
0,00
18,85
18,85
0,00
18,85
18,85
0,00
23,95
16,00
21,28
10,32
10,25
1,99
9,48
9,48
1,99
13,43
13,82
2,96
10,33
10,70
2,96
21,09
21,09
0,00
21,09
21,09
0,00
21,09
21,02
0,00
21,02
21,02
0,00
25iW
25iRW
25iSW
25idRN
25idRNI
25idRNX
25idRZ
25idRZI
25idRZX
25itRN
25itRNI
25itRNX
25itRZ
25itRZI
25itRZX
25idSN
25idSNI
25idSNX
25idSZ
25idSZI
25idSZX
25itSN
25itSNI
25itSNX
25itSZ
25itSZI
25itSZX
21,70
24,55
28,27
17,95
20,91
2,51
1,81
6,77
2,59
23,25
22,35
1,25
6,73
6,81
1,20
27,12
27,18
0,00
27,54
27,54
0,00
27,39
26,67
0,00
27,52
27,05
0,00
78,67
76,47
78,38
64,10
58,54
7,55
16,13
14,89
8,16
74,07
83,33
7,14
11,11
16,33
6,25
60,00
60,00
0,00
60,00
60,00
0,00
60,00
58,97
0,00
60,00
60,53
0,00
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
31,39
20,77
26,47
20,19
19,50
9,48
13,47
9,28
11,42
19,69
21,85
11,95
11,16
11,33
9,48
29,47
26,66
0,00
28,68
28,68
0,00
27,83
26,56
0,00
29,27
29,39
0,00
26,11
17,98
20,92
13,38
15,99
9,73
10,79
12,94
8,43
15,96
14,15
5,89
11,58
11,39
6,06
23,85
23,01
0,00
22,28
22,28
0,00
23,51
21,31
0,00
21,76
23,26
0,00
28,90
21,99
25,88
18,40
19,39
8,32
10,25
10,27
8,66
19,90
20,37
7,57
10,51
10,56
6,59
27,74
26,26
0,00
26,91
26,91
0,00
26,97
25,43
0,00
27,00
27,54
0,00
Tabela 5.7. Udział testów aplikacji g, w których doszło do naruszeń asercji, w liczbie testów
o innym kodzie zakończenia niż poprawny (c.d.)
104
W tabelach 5.8 i 5.9 przedstawiono analogiczne do poprzednich wyliczenia obejmujace
˛
procentowy udział testów (z wykluczeniem testów o wyniku N) przeprowadzonych w systemie
FITS zakończonych naruszeniem asercji w ogólnej liczbie wszystkich testów zakończonych
nieprawidłowym wynikiem obliczeń.
Pokrycie bł˛edów dla wszystkich wersji badanych
aplikacji jest nawet kilkukrotnie wyższe od przedstawionego wcześniej pokrycia bł˛edów obejmujacych
˛
różne skutki w działaniu programu. Dla niektórych wersji aplikacji zaobserwowano
pełne pokrycie bł˛edów, najcz˛eściej dla zakłóceń w obszarze jednostki zmiennoprzecinkowej,
rzadziej w obszarze adresów i rejestrów. Oznacza to, że wykryte asercje w wysokim stopniu
pokrywały bł˛edy, które prowadziły do nieprawidłowego wyniku obliczeń.
Zastosowanie
optymalizacji liczby asercji zmniejszało dla wi˛ekszości wersji poziom pokrycia, ale spadek
ten jest niewspółmierny do spadku kosztów stosowania asercji omówionych wcześniej. Dla
aplikacji k ogólne pokrycie wynosiło od około 72% do 89% (poza wersja˛ iDNX dla której
było istotnie niższe). Dla aplikacji g przy stosowaniu strategii S ogólne pokrycie było wi˛eksze
niż 90% (z wykluczeniem wersji, dla których nie znaleziono rozwiazań).
˛
Mniejsze pokrycie
bł˛edów obserwowane jest dla wersji aplikacji, dla których stosowano strategi˛e X. Strategia ta
promowała asercje wykrywajace
˛ wyjatki
˛ systemowe.
Eksperyment
a
Ogółem
rejestry
adresy
FPU
instrukcje
koda
fW
fN
fZ
fDN
fDZ
fDNI
fDZI
fDNX
fDZX
10,00
5,08
4,55
2,00
9,09
8,33
5,00
16,22
8,82
90,28
100,00
97,01
90,91
95,35
89,80
88,24
82,98
86,67
100,00
100,00
100,00
100,00
100,00
100,00
100,00
100,00
100,00
92,93
92,31
96,60
89,47
95,69
93,02
94,26
84,03
94,37
85,45
84,03
89,68
79,40
84,72
77,86
72,87
72,15
73,05
84,51
82,49
87,99
79,11
83,84
81,10
80,00
72,80
77,56
iW
iN
iZ
iDN
iDZ
iDNI
iDZI
iDNX
iDZX
70,67
16,67
44,83
16,33
44,83
35,09
22,64
9,43
23,64
100,00
100,00
100,00
100,00
100,00
100,00
100,00
71,43
100,00
–
–
–
–
–
–
–
–
–
93,53
97,96
95,68
97,95
95,78
83,09
88,89
12,00
94,38
93,44
95,92
97,19
95,89
96,07
82,17
76,88
24,03
89,09
88,46
86,08
89,35
85,80
88,97
75,14
73,70
18,34
82,58
Tabela 5.8. Udział testów aplikacji k, w których doszło do naruszeń asercji, w liczbie testów zakończonych niepoprawnym wynikiem obliczeń
105
Eksperyment
a
Ogółem
rejestry
adresy
FPU
instrukcje
koda
2fW
2fRW
2fSW
2fdRN
2fdRNI
2fdRNX
2fdRZ
2fdRZI
2fdRZX
2ftRN
2ftRNI
2ftRNX
2ftRZ
2ftRZI
2ftRZX
2fdSN
2fdSNI
2fdSNX
2fdSZ
2fdSZI
2fdSZX
2ftSN
2ftSNI
2ftSNX
2ftSZ
2ftSZI
2ftSZX
98,86
77,78
91,89
33,85
29,79
38,33
34,38
44,90
29,31
52,17
70,27
34,21
66,22
68,00
20,00
94,44
94,44
0,00
94,44
94,44
0,00
94,44
94,44
0,00
94,44
94,44
0,00
98,59
73,44
84,62
48,57
48,72
52,63
41,67
53,85
44,74
55,56
48,94
56,82
51,43
51,16
54,29
57,14
57,14
0,00
57,14
57,14
0,00
57,14
57,14
0,00
57,14
57,14
0,00
100,00
72,73
100,00
80,00
100,00
60,00
100,00
100,00
66,67
50,00
75,00
66,67
100,00
85,71
100,00
100,00
100,00
0,00
100,00
100,00
0,00
100,00
100,00
0,00
100,00
100,00
0,00
92,23
72,68
88,00
59,60
54,11
50,34
59,06
54,17
52,32
60,51
64,18
62,96
61,39
64,77
46,15
78,31
78,31
0,00
78,31
78,31
0,00
78,31
78,31
0,00
78,31
78,31
0,00
95,08
77,44
84,81
34,34
31,19
37,78
43,43
50,00
28,70
36,36
55,47
36,08
42,57
56,52
34,18
76,47
76,47
0,00
76,47
76,47
0,00
76,47
76,47
0,00
76,47
76,47
0,00
95,14
75,19
87,32
47,04
42,98
45,29
49,01
51,74
40,78
52,34
61,23
48,73
56,37
62,34
38,70
80,12
80,12
0,00
80,12
80,12
0,00
80,12
80,12
0,00
80,12
80,12
0,00
25fW
25fRW
25fSW
25fdRN
25fdRNI
25fdRNX
25fdRZ
25fdRZI
25fdRZX
25ftRN
25ftRNI
25ftRNX
25ftRZ
25ftRZI
25ftRZX
25fdSN
25fdSNI
25fdSNX
25fdSZ
25fdSZI
25fdSZX
25ftSN
25ftSNI
25ftSNX
25ftSZ
25ftSZI
25ftSZX
96,97
67,69
95,00
54,35
62,24
33,99
49,34
63,19
63,29
58,96
67,95
30,83
53,76
64,38
18,97
95,59
95,59
0,00
95,59
95,59
0,00
95,59
95,59
0,00
95,59
95,59
0,00
100,00
69,39
100,00
60,32
34,78
58,14
66,10
34,78
61,54
70,37
40,74
50,00
62,89
49,28
64,63
87,50
87,50
0,00
87,50
87,50
0,00
87,50
87,50
0,00
87,50
87,50
0,00
100,00
100,00
100,00
100,00
66,67
100,00
100,00
66,67
100,00
100,00
50,00
60,00
28,57
85,71
33,33
100,00
100,00
0,00
100,00
100,00
0,00
100,00
100,00
0,00
100,00
100,00
0,00
95,95
81,27
95,77
69,07
77,08
49,07
70,46
77,35
67,76
69,09
79,44
43,38
55,17
80,73
45,40
95,97
95,97
0,00
95,97
95,97
0,00
95,97
95,97
0,00
95,97
95,97
0,00
88,34
73,99
89,31
43,78
43,92
38,53
42,27
43,92
40,74
41,27
57,20
40,00
48,87
55,65
43,93
91,22
91,22
0,00
91,22
91,22
0,00
91,84
91,84
0,00
91,22
91,22
0,00
94,31
75,00
94,31
57,39
59,26
44,25
56,25
59,53
57,65
58,54
65,21
40,83
53,94
66,53
40,36
94,60
94,60
0,00
94,60
94,60
0,00
94,74
94,74
0,00
94,60
94,60
0,00
Tabela 5.9. Udział testów aplikacji g, w których doszło do naruszeń asercji, w liczbie testów zakończonych niepoprawnym wynikiem obliczeń
106
Eksperyment
a
Ogółem
rejestry
adresy
FPU
instrukcje
koda
2iW
2iRW
2iSW
2idRN
2idRNI
2idRNX
2idRZ
2idRZI
2idRZX
2itRN
2itRNI
2itRNX
2itRZ
2itRZI
2itRZX
2idSN
2idSNI
2idSNX
2idSZ
2idSZI
2idSZX
2itSN
2itSNI
2itSNX
2itSZ
2itSZI
2itSZX
98,41
76,79
96,72
67,44
72,92
5,77
77,27
77,27
5,66
77,36
84,00
4,17
58,49
68,57
4,17
98,04
98,04
0,00
98,04
98,04
0,00
98,04
98,04
0,00
98,04
98,04
0,00
100,00
85,71
97,30
71,43
73,68
3,45
59,26
59,26
3,45
86,96
70,00
8,82
57,14
74,07
8,82
100,00
100,00
0,00
100,00
100,00
0,00
100,00
100,00
0,00
100,00
100,00
0,00
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
98,92
60,71
96,59
48,55
48,05
15,44
48,24
48,24
15,44
58,18
55,03
17,14
40,96
49,04
17,14
96,34
96,34
0,00
96,34
96,34
0,00
96,34
96,32
0,00
96,91
96,32
0,00
98,17
74,38
97,94
37,31
40,91
7,55
30,51
30,51
7,55
57,66
62,81
19,79
52,24
49,28
19,79
87,50
87,50
0,00
87,50
87,50
0,00
87,50
87,50
0,00
87,50
87,50
0,00
98,69
69,44
97,04
47,98
50,14
10,22
46,80
46,80
10,19
62,78
62,50
15,09
48,56
52,94
15,09
94,08
94,08
0,00
94,08
94,08
0,00
94,08
94,07
0,00
94,33
94,07
0,00
25iW
25iRW
25iSW
25idRN
25idRNI
25idRNX
25idRZ
25idRZI
25idRZX
25itRN
25itRNI
25itRNX
25itRZ
25itRZI
25itRZX
25idSN
25idSNI
25idSNX
25idSZ
25idSZI
25idSZX
25itSN
25itSNI
25itSNX
25itSZ
25itSZI
25itSZX
100,00
81,00
100,00
80,33
75,34
9,76
7,37
25,88
9,76
88,73
77,63
4,76
22,11
25,49
4,65
100,00
100,00
0,00
100,00
100,00
0,00
100,00
100,00
0,00
100,00
100,00
0,00
100,00
92,86
100,00
86,21
85,71
9,76
22,22
21,88
10,53
95,24
92,59
9,09
13,89
23,53
8,11
100,00
100,00
0,00
100,00
100,00
0,00
100,00
100,00
0,00
100,00
100,00
0,00
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
100,00
64,61
100,00
58,60
55,00
32,46
40,15
34,15
34,84
59,28
69,52
35,74
40,30
40,76
31,28
100,00
100,00
0,00
100,00
100,00
0,00
100,00
99,43
0,00
100,00
100,00
0,00
98,48
65,76
95,65
54,41
60,87
41,32
39,15
52,94
35,58
59,87
59,52
24,03
43,27
45,83
23,98
93,96
97,84
0,00
98,50
98,50
0,00
93,24
97,64
0,00
98,37
92,54
0,00
99,50
69,95
98,65
62,13
61,55
29,92
33,22
37,89
29,41
65,98
69,47
25,30
35,98
38,25
22,84
98,03
99,31
0,00
99,54
99,54
0,00
97,74
99,00
0,00
99,52
97,60
0,00
zakończonych niepoprawnym wynikiem obliczeń (c.d.)
107
Tabele 5.10 i 5.11 przedstawiaja˛ procentowy udział testów (z wykluczeniem testów
o wyniku N) przeprowadzonych w systemie FITS zakończonych naruszeniem asercji w ogólnej
liczbie wszystkich testów zakończonych wyjatkiem
˛
systemowym. Pokrycie bł˛edów dla wszystkich wersji badanych aplikacji jest zbliżone (z dokładnościa˛ do kilku punktów procentowych)
od przedstawionego w tabelach 5.6 i 5.7. Oznacza to, że wykryte asercje w podobnym
stopniu pokrywały bł˛edy, które prowadziły do powstania wyjatku
˛ systemowego jak i skutkujace
˛
wszystkimi możliwymi bł˛ednymi efektami działania aplikacji. Mniejsze pokrycie bł˛edów
obserwowane jest dla wersji aplikacji, dla których stosowano strategi˛e X, ale spadek ten
jest niższy niż dla wyliczeń przedstawionych w tabelach 5.8 i 5.9. Oznacza to, że asercje
wprowadzone do programów, które lepiej pokrywały wyjatki
˛ systemowe, gorzej reagowały na
bł˛edy prowadzace
˛ do innych wyników testu aplikacji.
Eksperyment
a
Ogółem
rejestry
adresy
FPU
instrukcje
koda
fW
fN
fZ
fDN
fDZ
fDNI
fDZI
fDNX
fDZX
1,79
1,17
0,79
0,38
1,68
1,41
0,79
3,51
1,89
36,31
28,33
35,14
23,19
23,30
24,72
18,40
19,50
19,80
87,76
84,31
73,17
77,78
84,85
68,75
90,91
66,67
65,00
31,72
29,78
31,11
23,00
23,84
28,10
26,62
19,92
24,06
28,08
27,82
30,09
27,21
25,24
28,90
25,47
23,65
26,35
28,10
26,68
28,19
22,54
22,16
25,00
23,36
19,84
22,28
iW
iN
iZ
iDN
iDZ
iDNI
iDZI
iDNX
iDZX
24,37
3,10
9,22
3,08
9,22
7,52
4,07
1,92
4,92
98,04
47,62
46,88
50,00
46,88
16,67
25,00
23,81
51,61
–
–
–
–
–
–
–
–
–
22,96
20,78
21,26
20,63
21,60
16,79
17,54
2,11
21,85
19,43
19,08
22,58
19,00
22,29
18,48
18,89
5,07
20,08
23,54
17,71
20,40
17,64
20,42
16,01
15,83
3,63
19,03
Tabela 5.10. Udział testów aplikacji k, w których doszło do naruszeń asercji, w liczbie testów
˛
systemowym
Podsumowujac
˛ omówione wyniki dla aplikacji k, mimo wprowadzenia silnego ograniczenia
przy optymalizacji liczby wszystkich aktywnych asercji lub całkowity koszt dynamiczny
asercji, spadek wykryć bł˛edów przez asercje jest niewielki dla wi˛ekszości wersji f we
wszystkich obszarach, natomiast dla wersji i w obszarach instrukcji i kodu statycznego.
Asercje najskuteczniej wykrywały zakłócenia w jednostce zmiennoprzecinkowej (wersja f
108
Eksperyment
a
Ogółem
rejestry
adresy
FPU
instrukcje
koda
2fW
2fRW
2fSW
2fdRN
2fdRNI
2fdRNX
2fdRZ
2fdRZI
2fdRZX
2ftRN
2ftRNI
2ftRNX
2ftRZ
2ftRZI
2ftRZX
2fdSN
2fdSNI
2fdSNX
2fdSZ
2fdSZI
2fdSZX
2ftSN
2ftSNI
2ftSNX
2ftSZ
2ftSZI
2ftSZX
25,07
22,06
11,72
8,43
5,56
9,02
8,37
9,21
6,67
12,68
18,57
10,40
20,33
17,06
6,09
17,44
17,44
0,00
17,44
17,44
0,00
17,44
17,44
0,00
17,44
17,44
0,00
68,63
66,20
63,46
45,95
52,78
41,67
42,86
44,68
40,48
48,08
44,23
55,56
37,50
42,31
46,34
38,10
38,10
0,00
38,10
38,10
0,00
38,10
38,10
0,00
38,10
38,10
0,00
33,33
38,10
40,00
28,57
9,09
23,08
33,33
16,67
15,38
14,29
21,43
18,18
12,50
35,29
16,67
57,14
57,14
0,00
57,14
57,14
0,00
57,14
57,14
0,00
57,14
57,14
0,00
26,99
21,46
20,72
17,01
16,09
14,23
16,03
15,66
14,47
17,37
24,16
15,95
21,46
21,19
13,95
19,58
19,58
0,00
19,58
19,58
0,00
19,58
19,58
0,00
19,58
19,58
0,00
33,62
31,67
25,28
10,76
11,41
10,76
14,48
16,32
9,60
8,89
20,76
10,42
15,52
14,86
11,74
16,67
16,67
0,00
16,67
16,67
0,00
16,67
16,67
0,00
16,67
16,67
0,00
30,94
26,68
21,60
14,43
13,51
13,37
14,93
15,71
12,38
15,12
22,75
14,72
20,27
19,51
13,12
19,27
19,27
0,00
19,27
19,27
0,00
19,27
19,27
0,00
19,27
19,27
0,00
25fW
25fRW
25fSW
25fdRN
25fdRNI
25fdRNX
25fdRZ
25fdRZI
25fdRZX
25ftRN
25ftRNI
25ftRNX
25ftRZ
25ftRZI
25ftRZX
25fdSN
25fdSNI
25fdSNX
25fdSZ
25fdSZI
25fdSZX
25ftSN
25ftSNI
25ftSNX
25ftSZ
25ftSZI
25ftSZX
36,26
28,21
28,46
21,25
23,86
16,30
22,06
24,27
30,58
20,95
28,96
13,40
25,83
29,26
11,38
33,16
33,16
0,00
33,16
33,16
0,00
33,16
33,16
0,00
33,16
33,16
0,00
76,52
64,15
73,33
49,35
27,27
34,25
39,00
27,27
34,78
42,70
38,37
44,19
38,85
37,36
43,09
73,68
73,68
0,00
73,68
73,68
0,00
73,68
73,68
0,00
73,68
73,68
0,00
80,00
50,00
44,44
50,00
23,53
14,29
33,33
23,53
25,00
46,15
14,29
17,65
22,22
46,15
11,11
46,67
46,67
0,00
46,67
46,67
0,00
46,67
46,67
0,00
46,67
46,67
0,00
31,98
33,72
28,49
24,51
32,27
27,46
25,89
32,22
25,58
22,89
27,67
20,42
34,61
30,96
22,95
38,14
38,14
0,00
38,14
38,14
0,00
38,14
38,14
0,00
38,14
38,14
0,00
36,01
33,81
27,34
15,91
20,93
17,00
17,06
20,93
16,45
14,86
25,23
14,53
21,26
23,79
14,23
23,98
23,98
0,00
23,98
23,98
0,00
23,94
23,94
0,00
23,98
23,98
0,00
37,88
34,87
29,52
22,26
26,51
22,39
23,02
26,58
24,08
21,16
27,64
18,28
28,87
28,81
19,21
32,75
32,75
0,00
32,75
32,75
0,00
32,73
32,73
0,00
32,75
32,75
0,00
˛
systemowym
109
Eksperyment
a
Ogółem
rejestry
adresy
FPU
instrukcje
koda
2iW
2iRW
2iSW
2idRN
2idRNI
2idRNX
2idRZ
2idRZI
2idRZX
2itRN
2itRNI
2itRNX
2itRZ
2itRZI
2itRZX
2idSN
2idSNI
2idSNX
2idSZ
2idSZI
2idSZX
2itSN
2itSNI
2itSNX
2itSZ
2itSZI
2itSZX
19,02
13,69
16,12
8,90
11,18
1,17
10,27
10,27
1,17
14,29
12,92
0,77
9,57
7,36
0,77
16,08
16,08
0,00
16,08
16,08
0,00
16,08
16,08
0,00
16,08
16,08
0,00
67,57
77,42
69,23
50,00
51,85
4,55
61,54
61,54
4,55
64,52
53,85
12,00
55,17
62,50
12,00
60,87
60,87
0,00
60,87
60,87
0,00
60,87
60,87
0,00
60,87
60,87
0,00
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
26,67
16,16
24,18
13,55
11,82
3,52
12,54
12,54
3,52
14,86
15,63
4,42
10,45
12,07
4,42
23,58
23,58
0,00
23,58
23,58
0,00
23,58
23,47
0,00
23,47
23,47
0,00
22,25
18,33
18,30
9,80
10,11
1,79
6,81
6,81
1,79
12,75
15,20
4,09
13,16
12,16
4,09
19,68
19,68
0,00
19,68
19,68
0,00
19,68
19,68
0,00
19,68
19,68
0,00
24,64
17,66
21,95
11,98
11,80
2,50
10,91
10,91
2,50
15,08
15,56
3,72
12,04
12,15
3,72
21,90
21,90
0,00
21,90
21,90
0,00
21,90
21,85
0,00
21,85
21,85
0,00
25iW
25iRW
25iSW
25idRN
25idRNI
25idRNX
25idRZ
25idRZI
25idRZX
25itRN
25itRNI
25itRNX
25itRZ
25itRZI
25itRZX
25idSN
25idSNI
25idSNX
25idSZ
25idSZI
25idSZX
25itSN
25itSNI
25itSNX
25itSZ
25itSZI
25itSZX
21,70
26,05
28,27
18,77
22,45
3,27
2,34
8,40
3,40
24,05
23,98
1,67
8,82
8,50
1,60
27,12
27,18
0,00
27,54
27,54
0,00
27,39
26,67
0,00
27,52
27,05
0,00
78,67
81,25
78,38
71,43
64,86
25,00
37,04
33,33
26,67
76,92
89,29
25,00
35,71
34,78
21,43
60,00
60,00
0,00
60,00
60,00
0,00
60,00
58,97
0,00
60,00
60,53
0,00
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
31,86
23,75
27,13
23,73
23,61
12,50
17,41
11,82
15,40
23,09
24,39
15,61
14,09
13,92
12,50
31,02
28,21
0,00
30,09
30,09
0,00
28,99
27,44
0,00
30,33
30,41
0,00
26,54
20,17
21,46
15,26
18,11
11,71
13,33
15,08
10,19
18,38
15,89
7,44
13,94
13,60
7,66
24,91
23,73
0,00
22,90
22,90
0,00
24,56
21,79
0,00
22,28
24,41
0,00
29,25
24,57
26,40
20,88
22,36
10,75
13,22
12,75
11,31
22,56
22,60
9,95
13,33
13,02
8,71
28,79
27,20
0,00
27,73
27,73
0,00
27,87
26,00
0,00
27,63
28,42
0,00
˛
systemowym (c.d.)
110
programu), najgorzej w rejestrach (dla obu wersji). Dla wersji f programu spowodowane
jest to zastosowaniem w badanym programie w przeważajacej
˛ liczbie zmiennych zmiennoprzecinkowych, co wpłyn˛eło na charakter wykrytych asercji, a w efekcie na pokrywane przez
nie bł˛edy.
Biorac
˛ pod uwag˛e metod˛e wykrycia asercji (automatyczna) oraz przyrost wielkości programu po selekcji asercji pokrycie bł˛edów dla wi˛ekszości zbiorów wybranych asercji można
uznać za zadowalajace
˛ w odniesieniu do wzrostu rozmiarów aplikacji oraz stopy wykrywania
bł˛edów przez asercje w programie zawierajacym
˛
wszystkie asercje (wersja W).
W przypadku aplikacji g asercje lepiej wykrywały wprowadzone bł˛edy wraz ze wzrostem
liczby rozwiazywanych
˛
równań we wszystkich badanych obszarach poza obszarem adresów
w wersji f, dla którego w wi˛ekszości wersji zanotowano spadek o kilka punktów procentowych.
Najwyższy poziom detekcji bł˛edów otrzymywano przy stosowaniu strategii S selekcji
asercji (poza eksperymentami dodatkowo stosujacymi
˛
strategi˛e X). Był on zbliżony do poziomu
dla wersji ze wszystkimi asercjami. Oznacza to, że przy założeniu możliwości detekcji na etapie
sprawdzania wyznaczonego rozwiazania
˛
układu równań jedna z asercji umożliwiała wykrycie
przeważajacej
˛ liczby wprowadzonych zakłóceń.
Utrzymanie pokrycia bł˛edów na poziomie powyżej 15% w odniesieniu do pokrycia w zakresie 22%-36% otrzymanego w aplikacji ze wszystkimi asercjami (wersja W) dla wi˛ekszości
zbiorów wybranych asercji można uznać za zadowalajace
˛ w odniesieniu do pi˛eciokrotnego
zredukowania ich liczby w badanych wersjach programu.
Rysunek 5.3. Rozkład rezultatów testów aplikacji k w eksperymentach z losowa˛ zamiana˛ zmiennych
programu
Na rysunku 5.3 przedstawiono procentowy rozkład wyników testów aplikacji k dla
wszystkich przeprowadzonych eksperymentów polegajacych
˛
na wprowadzeniu prostej losowej
mutacji do programu zamieniajacej
˛ miejscami dwie zmiennie w jego kodzie źródłowym. Wersje
programu z mutacja˛ wygenerowano za pomoca˛ dedykowanego skryptu w j˛ezyku Perl. Dla
wersji f programu k bez asercji około 4% testów zakończyło si˛e wynikiem poprawnym a 96%
111
wynikiem niepoprawnym. Nie zaobserwowano testów, w których zakłócenie powodowałoby
przekroczenie czasu oczekiwania na zakończenie programu (nieskończona p˛etla) lub wyjatkiem
˛
systemowym (dzielenie przez zero). Po wprowadzeniu asercji do badanego programu liczba
testów z poprawnym wynikiem zakończenia w kolejnych eksperymentach utrzymywała si˛e na
poziomie od około 0,1%. Wynik ten wskazuje, że testy, które powinny zakończyć si˛e wynikiem
poprawnym zostały zakończone naruszeniem asercji. Sa˛ to fałszywe alarmy generowane przez
asercje. Wynikaja˛ one z niedoskonałości asercji wykrytych w sposób automatyczny.
Naruszenia asercji zaobserwowano w od około 90% testów (eksperymenty fDNX, fDZX,
fDNI, fDZI) do prawie 100% testów (eksperymenty fW, fN, fZ). W eksperymentach o najmniejszej liczbie obserwacji naruszeń asercji obserwowano w przeważajacej
˛ wi˛ekszości testy
zakończone wynikiem nieprawidłowym. Podane rezultaty wskazuja,˛ że przy innym zestawie
testów i generowanych w nich bł˛edów wybrane asercje dobrze radziły sobie z wykrywaniem
zakłóceń, które mogły doprowadzić do wygenerowania nieprawidłowego wyniku testu. Uruchomienia, które mimo wprowadzonego bł˛edu były prawidłowa˛ symulacja˛ nie były przerywane
przez naruszenie asercji.
Dla wersji i programu k bez asercji około 3% testów zakończyło si˛e wynikiem poprawnym
a 97% wynikiem niepoprawnym. Nie zaobserwowano testów o innych wynikach. W eksperymentach iW, iN, iZ zaobserwowano około 99% liczby testów, w których zaobserwowano
naruszenie asercji.
Obserwowanemu wzrostowi towarzyszył odpowiedni spadek liczby
testów z wynikiem poprawnym. Nie zaobserwowano żadnego testu zakończonego wynikiem
niepoprawnym. Rezultaty tej serii eksperymentów wskazuja˛ na fałszywe alarmy generowane
przez asercje na poziomie około 2%. Testy, które powinny zakończyć si˛e wynikiem poprawnym
zostały zakończone naruszeniem asercji. Pozytywnym aspektem jest całkowity brak testów
zakończonych wynikiem niepoprawnym. Dla pozostałych wersji aplikacji i obserwowano do
5% testów zakończonych wynikiem niepoprawnym.
Rysunek 5.4. Rozkład rezultatów testów aplikacji g w eksperymentach z losowa˛ zamiana˛ zmiennych
programu
112
Na rysunku 5.4 przedstawiono procentowy rozkład wyników testów aplikacji g dla
wybranych strategii selekcji asercji.
Stosowano analogiczne mutacje programów jak we
wcześniej opisanej serii eksperymentów. Zarówno dla wersji f jak i wersji i programu g bez
asercji około 1% testów zakończyło si˛e wynikiem poprawnym, a pozostałe 99% wynikiem
niepoprawnym.
Nie zaobserwowano testów zakończonych wyjatkiem
˛
systemowym oraz
przekroczonym czasem oczekiwania na zakończenie programu. Wprowadzone zakłócenia
były w całości wykrywane przez asercje z grupy S (sprawdzajacej
˛ znalezione rozwiazanie
˛
układu równań).
Dla asercji wybranych z użyciem strategii R obserwowano 1% testów
z niepoprawnym wynikiem obliczeń. Pozytywnym aspektem jest utrzymanie si˛e około 1%
liczby testów z wynikiem poprawnym dla wszystkich eksperymentów. Oznacza to, że asercje
nie generowały fałszywych alarmów.
5.1.6. Wnioski
Zastosowanie zaproponowanej metody selekcji asercji pozwoliło na redukcj˛e ich liczby oraz
kosztu stosowania wyrażonego poprzez liczb˛e instrukcji w kodzie programu i wykonanych
podczas jego działania. Jednocześnie, dla niektórych przeprowadzonych procedur selekcji
asercji, utrzymany został poziom detekcji bł˛edów z ich użyciem, zbliżony do bazowej
wersji aplikacji z wszystkimi asercjami. W przypadkach, w których nie udało si˛e utrzymać
odpowiedniego poziomu wykrywalności wprowadzanych bł˛edów, możliwa była obserwacja
takiej sytuacji na etapie eksperymentów weryfikujacych
˛
b˛edacych
˛
cz˛eścia˛ zaproponowanej
metody. Umożliwia to odrzucenie proponowanego zbioru wybranych asercji i selekcj˛e innego
poprzez zastosowanie odmiennej strategii. Zaobserwowano również przypadki (wersje iSX
aplikacji g), dla których zastosowanie algorytmu selekcji asercji nie zwracało rozwiazania.
˛
Oznaczało to, iż w zbiorze testów, na podstawie którego dokonywano optymalizacji liczby
asercji nie wyst˛epowały testy o wynikach uwzgl˛ednionych w kryteriach selekcji.
Analiza wyników otrzymanych dla aplikacji g pokazała, że istotny jest dobór zbioru danych
obserwacyjnych używanych do wyznaczenia podzbioru asercji. Zastosowanie zbyt małej ilości
danych obserwacyjnych, nawet dedykowanych określonej wersji aplikacji, może skutkować
wyborem gorzej sprawdzajacym
˛
si˛e podczas eksperymentów weryfikujacych.
˛
Zastosowanie
zbyt dużego zbioru danych obserwacyjnych może mieć podobne skutki, choć obserwowane
różnice nie były tak duże jak w poprzednim przypadku. Etap eksperymentów weryfikujacych
˛
umożliwia wykrycie tych sytuacji i selekcj˛e lepszego zbioru asercji. Zastosowanie metody
selekcji asercji z pewnymi danymi obserwacyjnymi nie wyklucza użycia wybranych asercji
do detekcji bł˛edów innych klas niż te, dla których przeprowadzano obserwacj˛e. Dla obu
badanych aplikacji pokrycie bł˛edów mutacyjnych było bardzo wysokie, mimo iż stosowane
asercje wybrano na podstawie innych zakłóceń.
Na podstawie przeprowadzonych eksperymentów można uznać prawdziwość tezy, iż
113
zastosowanie odpowiedniej strategii selekcji asercji pozwala na zmniejszenie ich liczby przy
zachowaniu możliwie wysokiego poziomu detekcji wybranych typów bł˛edów.
Przedstawiona metodyka eksperymentu jest uniwersalna i może zostać zastosowana
również do analizy innych aplikacji.
5.2. Asercje ze śladem
W punkcie 4.2 wprowadzono poj˛ecie asercji ze śladem. Struktura tego typu umożliwia
sprawdzenie wybranych asercji w zależności od przebiegu programu. Wybranie odpowiedniej
metody weryfikacji (punkt 4.5) pozwala również na badanie poprawności samego przebiegu
wykonania programu przez asercje ze śladem.
Celem eksperymentów jest sprawdzenie w jaki sposób wprowadzenie do programu asercji
ze śladem o zróżnicowanej długości śladu wpłynie na liczb˛e wykrytych asercji, zaufanie do
wykrytych asercji wyrażane liczba˛ ich zmian dla określonej ilości analizowanych danych,
stop˛e wykrywanych przez nie bł˛edów powstałych wskutek zakłócania działania aplikacji oraz
fałszywych alarmów generowanych dla nieznanych na etapie wykrywania asercji ze śladem
zbiorów danych wejściowych.
W pierwszym etapie eksperymentu dla wybranych bibliotek, zawierajacych
˛
implementacje
algorytmów z rodziny ZIP, przygotowano aplikacje realizujace
˛ operacje kompresji i dekompresji oraz kilkanaście zbiorów danych wejściowych. Programy zostały uruchomione w celu
uzyskania dzienników ich wykonania, na podstawie których wykryte zostały asercje ze śladem.
Analiza zebranych dzienników została przeprowadzona z użyciem specjalnie przygotowanych skryptów z pakietu FlowGraph. Przedstawiono je szczegółowo w dodatku A.2. Na
podstawie danych zebranych w wybranych punktach bibliotek znalezione zostały asercje ze
śladem.
Wykorzystujac
˛ aplikacje wzbogacone o wykryte asercje ze śladem przeprowadzonych
zostało kilka eksperymentów. W pierwszym z nich aplikacje uruchomione zostały w niezakłócanym środowisku z zastosowaniem nieznanych na etapie wykrywania asercji zbiorów danych
wejściowych. Umożliwiło to obserwacj˛e ewentualnych fałszywych alarmów zgłaszanych przez
asercje ze śladem.
Nast˛epne badanie polegało na uruchomieniu aplikacji w zakłócanym
środowisku (zakłócenia generowane przez narz˛edzia z pakietu FlowGraph) z zastosowaniem
zarówno znanych jak i nieznanych na etapie wykrywania asercji ze śladem zbiorów danych
wejściowych. Analiza zachowania asercji ze śladem pozwoliła na określenie ich przydatności
w procesie detekcji bł˛edów.
W końcowej cz˛eści analizy dla wykrytych zbiorów asercji ze śladem zaprezentowano wynik
działania nast˛epujacych
˛
algorytmów: redukcji liczby śladów w zbiorze asercji ze śladem
(algorytm 4.1), skracania śladów w zbiorze asercji ze śladem (algorytm 4.2), redukcji liczby
114
identyfikatorów punktów programu dla zbiorów asercji ze śladem (algorytm 4.3). Otrzymane
rezultaty ich działania pozwalaja˛ oszacować oszcz˛edności zwiazane
˛
z narzutem dodatkowego
kodu jakie można uzyskać na etapie integracji asercji ze śladem z badanymi programami.
W kolejnych punktach przedstawiono charakterystyk˛e badanych bibliotek oraz zaprezentowano wyniki przeprowadzonych badań wraz z wnioskami z nich wynikajacymi.
˛
Omówiona poniżej procedura analizy asercji ze śladem oraz przygotowane oprogramowanie
wspomagajace
˛ moga˛ zostać wykorzystane do badania innych aplikacji.
5.2.1. Charakterystyka badanych bibliotek
W celu zilustrowania zastosowania zaproponowanych w rozdziale czwartym asercji ze
śladem wykorzystane zostały trzy różne implementacje algorytmu kompresujacego
˛
z rodziny
ZIP dostarczane przez biblioteki JZlib4 , jazzlib5 , bzip26 .
liczba pakietów
liczba klas
liczba metod
JZlib
1
15
119
jazzlib
1
28
259
bzip2
1
4
74
Tabela 5.12. Podstawowe parametry opisujace
˛ badane implementacje algorytmu kompresujacego
˛
z rodziny ZIP
Badane implementacje wykonane zostały w j˛ezyku Java. Ich podstawowe parametry [92]
takie jak liczba pakietów, klas, metod oraz TLOC (liczba linii kodu źródłowego) zebrane zostały
w tabeli 5.12. Na rysunku 5.5 przedstawiono histogramy porównujace
˛ liczb˛e metod o danej
złożoności cyklomatycznej oraz liczbie parametrów wejściowych. Powyższe charakterystyki
badanych implementacji zostały przygotowane z użyciem pakietu metrics7 .
Zaprezentowane metryki wskazuja˛ na zróżnicowany styl programowania stosowany przy
implementacji. Ze wzgl˛edu na wybrane punkty obserwacji programu ich wartości b˛eda˛ mogły
mieć wpływ na wyniki otrzymane w trakcie eksperymentów.
5.2.2. Wykrywanie asercji ze śladem
Dla wymienionych bibliotek przygotowano programy realizujace
˛ operacje kompresji
i dekompresji danych wejściowych. Do automatycznej modyfikacji aplikacji, które umożliwiły
ich obserwacj˛e, wykorzystano pakiet AspectJ8 pozwalajacy
˛ na zastosowanie programowania
aspektowego w środowisku Java. Zadaniem stworzonego aspektu była obserwacja nast˛epuja˛
cych punktów w badanych aplikacjach:
4
5
6
7
8
http://www.jcraft.com/jzlib/
http://jazzlib.sourceforge.net/
http://www.kohsuke.org/bzip2/
http://metrics.sourceforge.net/
http://www.eclipse.org/aspectj/
115
(a) liczba metod o danej złożoności cyklomatycznej (CC)
(b) liczba metod o danej liczbie parametrów wejściowych (NOPm)
Rysunek 5.5. Liczba metod o danych własnościach dla badanych programów
116
— wywołanie konstruktora klasy,
— zakończenie konstruktora klasy,
— wywołanie metody wraz z obserwacja˛ parametrów wejściowych typu liczbowego,
— zakończenie metody wraz z obserwacja˛ wartości zwracanej typu liczbowego,
— punkty odczytu wartości zmiennych globalnych typu liczbowego,
— punkty przypisania wartości do zmiennych globalnych typu liczbowego.
Dla każdego z wyżej wymienionych punktów w programie utworzony aspekt rejestrował
do plikowego dziennika aplikacji identyfikator punktu składajacy
˛ si˛e z jego typu (wywołanie
konstruktora, zakończenie konstruktora, wywołanie metody, zakończenie metody, odczyt
wartości zmiennej, przypisanie wartości do zmiennej), nazwy klasy obiektu, w którym nastapiło
˛
zdarzenie, nazw˛e metody (w przypadku zdarzeń typu wywołanie lub zakończenie metody) oraz
wszystkie nazwy zmiennych typu liczbowego wraz z ich wartościami. Dla tak przygotowanych
programów wygenerowano po 32 zestawy losowych danych wejściowych o długościach 512,
1024, 2048 i 4096 bajtów. Dla wszystkich badanych implementacji użyto tych samych danych.
W kolejnym kroku uruchomiono programy dla wszystkich zestawów danych wejściowych
rejestrujac
˛ ślad ich wykonania w postaci plików tekstowych zgodnie z opisanymi wyżej
założeniami. W ten sposób dla każdej badanej aplikacji otrzymano po 32 zbiory uczace
˛ dla
każdej z czterech długości danych wejściowych.
5.2.3. Liczba wykrytych asercji
Zebrane dzienniki wykonania badanych aplikacji zostały poddane analizie przez algorytm
wykrywajacy
˛ asercje ze śladem. Dla wszystkich zmiennych, których wartości zostały zarejestrowane w danych punktach obserwacji wykrywano asercje typu z ≤ zmax oraz z ≥ zmin ,
odpowiadajace
˛ odpowiednio maksymalnej i minimalnej wartości osiaganej
˛
przez zmienna˛ z.
Wykrywano asercje spełnione lokalnie w punktach obserwacji o długościach śladów l z zakresu
< 0, 8 >.
W tabelach 5.13, 5.14 i 5.15 zawarto statystyki liczby wykrytych asercji osobno dla każdej
z badanych implementacji z podziałem na stosowane wielkości zbiorów danych wejściowych s
oraz długości śladów l. Pod poj˛eciem wykrycia asercji rozumie si˛e konieczność zdefiniowania
nowej asercji dla obserwowanej zmiennej, której wcześniej, nawet dla innych wartości maksymalnej i minimalnej, nie obserwowano. Taka sytuacja zachodzi w przypadku, gdy osiagni˛
˛ eto
punkt w programie wcześniej nie obserwowany lub punkt, do którego prowadził ślad zarejestrowany po raz pierwszy. W kolejnych kolumnach wyróżniono długość śladu l, liczb˛e asercji
wykrytych po zastosowaniu pierwszego zbioru uczacego
˛
n1 , łaczn
˛ a˛ liczb˛e asercji wykrytych dla
32
X
kolejnych trzydziestu jeden zbiorów uczacych
˛
ni oraz właściwości statystyczne zmiennej
i=2
losowej N , której wartościami sa˛ liczby wykrytych asercji po zastosowaniu kolejnych zbiorów
117
uczacych
˛
poza pierwszym. Właściwościami tymi sa˛ kolejno: wartość minimalna min(N )
(minimalna liczba wykrytych asercji), wartość maksymalna max(N ) (maksymalna liczba
wykrytych asercji), mediana med(N ) (mediana liczby wykrytych asercji), wartość średnia
N̄ (średnia liczba wykrytych asercji), odchylenie średniej d(N ) oraz odchylenie standardowe
σ(N ). Statystyki zostały sporzadzone
˛
za pomoca˛ narz˛edzi z pakietu FlowGraph.
Dla każdej implementacji liczba asercji wykrytych po analizie pierwszego zbioru uczacego
˛
przekracza, niekiedy kilkunastokrotnie, łaczn
˛ a˛ liczb˛e asercji wykrytych po zastosowaniu kolejnych zbiorów. Liczba wykrytych asercji rośnie wraz ze wzrostem długości obserwowanego
śladu, co świadczy o zróżnicowanym przebiegu dojścia do wybranych punktów obserwacji.
Mediana liczby wykrytych asercji dla kolejnych zbiorów uczacych
˛
równa wartości minimalnej
świadczy o tym, że dla wi˛ekszości zbiorów nie sa˛ wykrywane nowe asercje. Ma to wpływ
na znaczace
˛ wartości odchylenia średniego i standardowego zmiennej losowej N , które
świadcza˛ o incydentalnym pojawianiu si˛e znaczacej
˛ liczby nowych asercji w kolejnych zbiorach
uczacych.
˛
Wartości statystyczne rosna˛ wraz z badanymi długościami śladów asercji.
Zauważalna jest również korelacja pomi˛edzy liczba˛ metod o dużej złożoności cyklomatycznej oraz dużej liczbie parametrów wejściowych w odniesieniu do liczby wykrytych asercji.
Implementacja JZlib posiada najwi˛ecej takich metod, co w pewnym stopniu przekłada si˛e na
liczb˛e wykrytych asercji. Analogiczny wniosek można wyciagn
˛ ać
˛ dla implementacji bzip2,
gdzie liczba takich metod jest niewielka, co skutkuje mniejsza˛ liczba˛ asercji. Ze wzgl˛edu
na obserwowane punkty w programie (nie sa˛ to tylko wywołania metod) oraz obserwowane
zmienne (nie sa˛ to tylko zmienne wyst˛epujace
˛ jako dane wejściowe do metod) nie można jednak
wnioskować o ścisłej korelacji w tym przypadku.
5.2.4. Analiza procesu wykrywania asercji
W tabelach 5.16, 5.17 i 5.18 zawarto statystyki liczby niezb˛ednych zmian wykrytych asercji
podczas fazy nauki dla badanych implementacji. Zmiany te były wynikiem pojawienia si˛e
wartości prowadzacej
˛ do naruszenia już istniejacej
˛ asercji. Aby uniknać
˛ takiej sytuacji asercja
musiała być aktualizowana. Dla każdej implementacji podano odr˛ebne statystyki w podziale
na stosowane wielkości zbiorów danych wejściowych s, długości śladów l oraz wykrywane
rodzaje asercji (z ≤ zmin oraz z ≥ zmax ). W kolejnych kolumnach zawarto liczb˛e zmian
podczas analizy pierwszego zbioru uczacego
˛
u1 , stosunek liczby zmian do liczby wszystkich
sprawdzeń danych asercji wyrażony w procentach oraz analogiczne, łaczn
˛ a˛ liczb˛e zmian dla
32
X
kolejnych trzydziestu jeden zbiorów uczacych
˛
ui i stosunek liczby wszystkich zmian do
i=2
liczby wszystkich sprawdzeń danych asercji dla kolejnych trzydziestu jeden zbiorów uczacych
˛
wyrażony w procentach. W dalszej cz˛eści opisu stosunek liczby zmian do liczby wszystkich
sprawdzeń asercji b˛edzie nazywany zmiennościa˛ asercji.
118
l
n1
32
X
ni
min(N ) max(N ) med(N )
N̄
d(N )
σ(N )
0,62
2,12
3,87
5,51
7,53
10,75
14,97
19,70
25,08
1,77
6,01
10,95
14,17
17,23
22,60
28,62
35,17
43,33
s = 512
0
1
2
3
4
5
6
7
8
450
844
1118
1346
1550
1766
1984
2202
2422
10
34
64
98
144
214
310
428
590
0
0
0
0
0
0
0
0
0
10
34
62
80
96
122
148
178
212
0
0
0
0
0
0
0
0
2
0,32
1,10
2,06
3,16
4,65
6,90
10,00
13,81
19,03
s = 1024
0
1
2
3
4
5
6
7
8
460
876
1178
1428
1644
1884
2116
2342
2576
0
2
6
24
68
128
226
368
548
0
0
0
0
0
0
0
0
0
0
2
4
6
16
30
46
62
80
0
0
0
0
0
0
12
18
18
0,00 0,00 0,00
0,06 0,12 0,35
0,19 0,36 0,78
0,77 1,25 1,74
2,19 2,89 4,04
4,13 4,84 6,89
7,29 8,12 11,22
11,87 12,20 16,29
17,68 16,98 22,12
s = 2048
0
1
2
3
4
5
6
7
8
460
876
1174
1424
1642
1882
2130
2364
2606
0
2
10
30
72
140
238
396
592
0
0
0
0
0
0
0
0
0
0
2
10
20
38
64
92
128
170
0
0
0
0
0
0
2
2
2
0,00 0,00
0,06 0,12
0,32 0,62
0,97 1,69
2,32 3,49
4,52 6,38
7,68 9,54
12,77 13,76
19,10 19,12
s = 4096
i=2
0
1
2
3
4
5
6
7
8
460
876
1176
1430
1656
1902
2148
2390
2648
0
2
10
26
60
114
190
306
460
0
0
0
0
0
0
0
0
0
0
2
4
10
24
44
66
92
122
0
0
0
0
0
0
0
0
12
0,00 0,00 0,00
0,06 0,12 0,35
0,32 0,58 1,03
0,84 1,46 2,32
1,94 3,12 5,27
3,68 5,54 9,79
6,13 8,72 14,99
9,87 13,22 21,50
14,84 18,85 29,59
Tabela 5.13. Statystyki liczby wykrytych asercji dla implementacji JZlib
119
0,00
0,35
1,77
3,62
6,91
11,83
17,16
24,38
32,69
l
n1
32
X
ni
N̄
d(N )
σ(N )
1,50
3,86
7,48
11,59
15,41
19,29
23,75
27,68
33,78
4,24
10,60
19,51
28,94
37,38
45,87
55,85
64,06
73,64
s = 512
0 228
1 496
2 728
3 906
4 1086
5 1240
6 1414
7 1574
8 1750
24
64
124
192
266
356
462
568
722
0
0
0
0
0
0
0
0
0
24
60
110
162
208
254
308
352
402
0
0
0
0
0
0
0
0
0
0,77
2,06
4,00
6,19
8,58
11,48
14,90
18,32
23,29
s = 1024
0 252
1 554
2 836
3 1044
4 1244
5 1418
6 1618
7 1796
8 1996
0
6
22
78
140
222
316
440
584
0
0
0
0
0
0
0
0
0
0
4
8
14
36
60
78
98
122
0
0
0
0
0
10
10
14
16
0,00 0,00 0,00
0,19 0,36 0,78
0,71 1,05 1,57
2,52 3,48 4,37
4,52 5,76 7,93
7,16 8,28 12,01
10,19 11,10 15,85
14,19 14,96 20,39
18,84 19,66 25,88
s = 2048
0 252
1 552
2 832
3 1036
4 1234
5 1408
6 1602
7 1792
8 2002
0
8
28
86
146
226
324
440
588
0
0
0
0
0
0
0
0
0
0
4
10
32
62
100
140
172
210
0
0
0
0
0
0
0
0
10
0,00
0,26
0,90
2,77
4,71
7,29
10,45
14,19
18,97
0,00
0,48
1,52
4,57
7,43
11,07
15,60
20,32
26,21
0,00
0,98
2,53
7,29
12,68
19,67
27,50
34,60
43,09
s = 4096
i=2
0 252
1 552
2 834
3 1044
4 1244
5 1432
6 1638
7 1838
8 2054
0
10
32
98
182
274
380
506
666
0
0
0
0
0
0
0
0
0
0
4
8
24
46
58
74
92
112
0
0
0
0
0
0
0
14
104
0,00
0,32
1,03
3,16
5,87
8,84
12,26
16,32
21,48
0,00
0,56
1,73
5,04
8,82
12,58
16,40
20,76
26,20
0,00
0,89
2,43
7,14
12,72
17,71
22,81
28,22
34,75
Tabela 5.14. Statystyki liczby wykrytych asercji dla implementacji jazzlib
120
l
n1
32
X
ni
N̄
d(N )
σ(N )
s = 512
0 142
1 332
2 488
3 612
4 730
5 864
6 1024
7 1174
8 1340
2
8
22
34
54
80
130
208
298
0
0
0
0
0
0
0
0
0
2
8
16
22
28
32
38
46
54
0
0
0
0
0
0
0
14
2
0,06 0,12 0,35
0,26 0,50 1,41
0,71 1,28 2,90
1,10 1,91 4,09
1,74 2,92 5,49
2,58 3,78 6,37
4,19 5,45 7,97
6,71 8,23 10,53
9,61 11,35 13,87
s = 1024
0 142
1 334
2 492
3 632
4 750
5 886
6 1048
7 1202
8 1374
0
10
18
24
38
60
106
172
244
0
0
0
0
0
0
0
0
0
0
6
8
12
16
20
24
52
84
0
0
0
0
0
0
0
0
0
0,00 0,00 0,00
0,32 0,60 1,25
0,58 1,05 1,98
0,77 1,35 2,52
1,23 2,06 3,40
1,94 3,12 4,61
3,42 5,17 6,93
5,55 8,07 11,53
7,87 11,16 17,09
s = 2048
0 142
1 332
2 488
3 630
4 766
5 900
6 1060
7 1218
8 1392
2
8
20
28
42
66
114
181
256
0
0
0
0
0
0
0
0
0
2
8
16
22
28
34
42
52
62
0
0
0
0
0
0
0
0
14
0,06 0,12 0,35
0,26 0,50 1,41
0,65 1,17 2,85
0,90 1,63 3,93
1,35 2,36 5,06
2,13 3,31 6,32
3,68 5,18 8,35
5,84 7,32 11,25
8,26 10,08 15,04
s = 4096
i=2
0 154
1 352
2 522
3 678
4 826
5 996
6 1194
7 1376
8 1568
0
10
32
52
80
116
164
258
388
0
0
0
0
0
0
0
0
0
0
4
6
8
18
22
36
66
98
0
0
0
0
0
0
0
0
14
0,00 0,00 0,00
0,32 0,56 0,89
1,03 1,53 1,89
1,68 2,38 2,92
2,58 3,66 4,61
3,74 4,94 6,22
5,29 6,91 9,26
8,32 10,78 15,96
12,52 14,67 22,99
Tabela 5.15. Statystyki liczby wykrytych asercji dla implementacji bzip2
121
z ≥ zmin
l
u1
%
32
X
z ≤ zmax
ui
%
u1
%
ui
%
s = 512
0
1
2
3
4
5
6
7
8
503
2214
3327
3584
3994
4183
4410
4589
4722
0,52
2,29
3,44
3,71
4,13
4,33
4,56
4,75
4,88
27
108
188
279
373
490
650
826
1029
0,03
0,11
0,19
0,29
0,39
0,51
0,67
0,85
1,07
2208
5670
7328
7999
8258
8380
8484
8629
8849
2,28
5,86
7,58
8,27
8,54
8,67
8,77
8,92
9,15
83
217
321
442
563
709
885
1080
1316
0,09
0,22
0,33
0,46
0,58
0,73
0,92
1,12
1,36
s = 1024
0
1
2
3
4
5
6
7
8
524
3294
4958
5237
5640
5823
6065
6257
6384
0,44
2,76
4,15
4,39
4,73
4,88
5,08
5,24
5,35
65
164
254
347
470
621
790
996
1247
0,05
0,14
0,21
0,29
0,39
0,52
0,66
0,83
1,05
3606
9680
12872
14055
14316
14455
14564
14720
14960
3,02
8,11
10,79
11,78
12,00
12,11
12,20
12,33
12,54
72
210
335
455
586
748
912
1098
1321
0,06
0,18
0,28
0,38
0,49
0,63
0,76
0,92
1,11
s = 2048
i=2
0
1
2
3
4
5
6
7
8
543
5429
8210
8501
8923
9126
9379
9566
9702
0,33
3,27
4,95
5,13
5,38
5,50
5,66
5,77
5,85
70
169
279
380
509
678
858
1097
1356
0,04
0,10
0,17
0,23
0,31
0,41
0,52
0,66
0,82
6541
18055
24309
26501
26770
26912
27024
27189
27439
3,95
10,89
14,66
15,99
16,15
16,23
16,30
16,40
16,55
100
254
397
546
680
843
1021
1215
1450
0,06
0,15
0,24
0,33
0,41
0,51
0,62
0,73
0,88
s = 4096
i=2
32
X
0
1
2
3
4
5
6
7
8
564
9811
14958
15273
15692
15896
16158
16371
16543
0,22
3,76
5,73
5,85
6,01
6,09
6,19
6,27
6,34
55
149
247
352
459
619
786
991
1255
0,02
0,06
0,09
0,13
0,18
0,24
0,30
0,38
0,48
12189
34990
47339
51523
51809
51953
52065
52223
52483
4,67
13,41
18,14
19,74
19,85
19,90
19,95
20,01
20,11
125
297
427
554
669
840
999
1191
1436
0,05
0,11
0,16
0,21
0,26
0,32
0,38
0,46
0,55
Tabela 5.16. Liczba zmian istniejacych
˛
asercji oraz stosunek liczby zmian istniejacych
˛
asercji do ich
wszystkich sprawdzeń wyrażony w procentach dla implementacji JZlib
122
z ≥ zmin
l
u1
%
32
X
z ≤ zmax
ui
%
u1
%
ui
%
s = 512
0
1
2
3
4
5
6
7
8
170
1872
2556
2685
2807
2900
3020
3125
3225
0,58
6,37
8,69
9,13
9,55
9,86
10,27
10,63
10,97
39
110
234
372
518
678
836
994
1173
0,13
0,37
0,80
1,27
1,76
2,31
2,85
3,38
3,99
3868
7918
9109
9231
9331
9438
9530
9627
9727
13,16
26,93
30,98
31,40
31,74
32,10
32,42
32,75
33,09
110
223
380
543
705
859
1047
1237
1433
0,37
0,76
1,29
1,85
2,40
2,92
3,56
4,21
4,87
s = 1024
0
1
2
3
4
5
6
7
8
177
3454
4698
4860
4981
5089
5228
5344
5465
0,33
6,52
8,87
9,17
9,40
9,60
9,87
10,08
10,31
66
175
325
468
642
808
984
1186
1385
0,12
0,33
0,61
0,88
1,21
1,53
1,86
2,24
2,61
6717
14566
16834
16972
17094
17202
17305
17417
17535
12,68
27,49
31,77
32,03
32,26
32,46
32,66
32,87
33,09
73
190
350
529
701
889
1092
1306
1544
0,14
0,36
0,66
1,00
1,32
1,68
2,06
2,46
2,91
s = 2048
i=2
0
1
2
3
4
5
6
7
8
189
6634
9011
9158
9284
9409
9538
9660
9778
0,19
6,56
8,92
9,06
9,19
9,31
9,44
9,56
9,67
66
169
342
512
680
851
1046
1281
1528
0,07
0,17
0,34
0,51
0,67
0,84
1,04
1,27
1,51
12368
27913
32423
32575
32706
32813
32921
33020
33143
12,24
27,62
32,08
32,23
32,36
32,47
32,57
32,67
32,79
76
198
379
543
716
897
1085
1300
1531
0,08
0,20
0,38
0,54
0,71
0,89
1,07
1,29
1,52
s = 4096
i=2
32
X
0
1
2
3
4
5
6
7
8
198
13016
17743
17898
18042
18177
18311
18446
18604
0,10
6,54
8,91
8,99
9,06
9,13
9,20
9,27
9,35
59
149
307
480
670
850
1028
1264
1498
0,03
0,07
0,15
0,24
0,34
0,43
0,52
0,63
0,75
23621
54675
63888
64126
64284
64411
64532
64662
64815
11,87
27,47
32,10
32,22
32,30
32,36
32,42
32,49
32,56
125
277
455
612
774
952
1169
1389
1658
0,06
0,14
0,23
0,31
0,39
0,48
0,59
0,70
0,83
˛
˛
asercji do ich
wszystkich sprawdzeń wyrażony w procentach dla implementacji jazzlib
123
z ≥ zmin
l
u1
%
32
X
z ≤ zmax
ui
%
u1
%
ui
%
s = 512
0 135
1 289
2 403
3 507
4 591
5 668
6 787
7 911
8 1033
0,21
0,45
0,62
0,79
0,92
1,04
1,22
1,41
1,60
73
124
193
283
353
421
536
640
787
0,12
0,20
0,31
0,45
0,56
0,67
0,85
1,01
1,24
3154
5840
6964
7661
8005
8151
8319
8413
8571
4,89
9,05
10,8
11,88
12,41
12,64
12,90
13,04
13,29
59
132
216
309
384
488
647
780
948
0,09
0,21
0,34
0,49
0,61
0,77
1,02
1,23
1,49
s = 1024
0 122
1 253
2 358
3 461
4 542
5 636
6 763
7 884
8 1026
0,10
0,21
0,30
0,38
0,45
0,53
0,63
0,74
0,85
59
110
166
240
294
359
474
579
732
0,05
0,09
0,14
0,20
0,24
0,30
0,39
0,48
0,60
6587
11894
14059
15257
15626
15790
15930
16043
16160
5,48
9,89
11,69
12,69
13,00
13,13
13,25
13,34
13,44
69
123
179
264
319
415
536
663
827
0,06
0,10
0,15
0,22
0,26
0,34
0,44
0,55
0,68
s = 2048
i=2
0 149
1 314
2 434
3 543
4 648
5 740
6 868
7 1003
8 1143
0,06
0,13
0,18
0,23
0,27
0,31
0,36
0,42
0,48
55
98
144
230
298
363
497
610
754
0,02
0,04
0,06
0,10
0,12
0,15
0,21
0,25
0,31
12413
22741
26916
29197
29556
29728
29953
30139
30333
5,19
9,51
11,26
12,22
12,37
12,44
12,53
12,61
12,69
93
176
271
365
427
532
679
806
981
0,04
0,07
0,11
0,15
0,18
0,22
0,28
0,34
0,41
s = 4096
i=2
32
X
0 191 0,06
1 366 0,11
2 508 0,16
3 638 0,20
4 741 0,23
5 868 0,27
6 1025 0,31
7 1160 0,35
8 1284 0,39
85
160
225
315
396
501
632
789
1009
0,03
0,05
0,07
0,10
0,12
0,15
0,19
0,24
0,31
20325
40909
49168
53460
53827
54026
54173
54295
54404
6,22
12,52
15,04
16,36
16,47
16,53
16,58
16,61
16,65
67
151
241
340
419
520
679
825
1047
0,02
0,05
0,07
0,10
0,13
0,16
0,21
0,25
0,32
˛
˛
asercji do ich
wszystkich sprawdzeń wyrażony w procentach dla implementacji bzip2
124
Badane implementacje charakteryzuja˛ si˛e zauważalnym spadkiem liczby zmian asercji po
analizie pierwszego zbioru trenujacego.
˛
Oznacza to, że kolejne zbiory w coraz mniejszym
stopniu wpływaja˛ na wykrywanie asercji odzwierciedlajacych
˛
działanie programów. Ewentualne odst˛epstwa od tej zasady spowodowane sa˛ pojawieniem si˛e zbioru danych wejściowych,
dla którego przebieg algorytmu mógł przebiegać inna˛ ścieżka˛ niż dla wi˛ekszości pozostałych
danych. Wartość tego spadku zmniejsza si˛e wraz z długościa˛ śladu wykrywanych asercji.
Powodem takiej sytuacji jest zmniejszajaca
˛ si˛e ilość danych uczacych.
˛
Liczba obserwowanych zmian zwiazana
˛
jest również z wcześniej przedstawiona˛ liczba˛
wykrytych asercji dla badanych implementacji.
Rośnie ona wraz ze wzrostem liczby
znalezionych asercji. Liczba pojawiajacych
˛
si˛e nowych asercji dla kolejnych zbiorów uczacych
˛
wpływa również na liczb˛e koniecznych ich zmian.
W analizowanych programach obserwowalna jest wi˛eksza liczba koniecznych zmian dla
asercji z ≤ zmax w stosunku do asercji z ≥ zmin . Wynika to z charakteru programów,
gdzie wi˛ekszość zmiennych przyjmuje wartości naturalne oraz zmienia si˛e proporcjonalnie
wraz z kolejnymi partiami danych wejściowych.
Na rysunku 5.6 przedstawiono zestawienie udziału asercji o danym zakresie zmienności
obliczanym oddzielnie dla każdej asercji.
Dane dla histogramów przygotowane zostały
za pomoca˛ skryptów z pakietu FlowGraph dla implementacji bzip2 badanej dla danych
wejściowych o rozmiarze 4096 bajtów. Poszczególne wykresy przedstawiaja˛ procentowy udział
liczby asercji o danym zakresie zmienności w ogólnej liczbie wszystkich asercji. Uwzgl˛edniono
na nich dziesi˛eć proporcjonalnych przedziałów dla wartości określajacej
˛ zmienność asercji:
< 0%, 10%), < 10%, 20%), . . . , < 80%, 90%), < 90%, 100% >. Sa˛ one oznaczone kolorami:
zielonym dla zakresów z przedziału < 0%, 50%) (od jasnozielonego do ciemnozielonego)
oraz czerwonym dla zakresów z przedziału < 50%, 100% > (od ciemnoczerwonego do
jasnoczerwonego). Kolejne wykresy przedstawiaja˛ udział asercji o danym zakresie zmienności
po zastosowaniu różnej liczby zbiorów trenujacych.
˛
Przy ustalonej liczbie przeanalizowanych zbiorów uczacych
˛
widoczna jest zależność
pomi˛edzy udziałem asercji o dużej wartości zmienności a długościa˛ śladu asercji. Dla asercji
o dłuższym śladzie jest ich wi˛ecej. Jest to skutkiem malejacej
˛ ilości danych uczacych
˛
wraz ze
wzrostem długości śladu przez co wysoki stopień zmienności utrzymuje si˛e dłużej. Z kolei,
wraz ze wzrostem liczby zbiorów uczacych,
˛
zwi˛eksza si˛e liczba asercji o mniejszej wartości
zmienności zast˛epujac
˛ asercje o dużej zmienności. Wniosek ten potwierdza wcześniejsza˛
obserwacj˛e dotyczac
˛ a˛ zmienności danych typów asercji w zależności od liczby zbiorów
uczacych.
˛
Wraz ze wzrostem liczby przeanalizowanych zbiorów uczacych
˛
i długości śladów
asercji zast˛epowanie asercji o dużej zmienności przez asercji o mniejszej zmienności nast˛epuje
z coraz mniejsza˛ intensywnościa.˛ Ewentualne fluktuacje moga˛ być wynikiem pojawienia si˛e
takiego zbioru danych wejściowych, dla którego zaszła konieczność zmian w dużej liczbie
125
(a) jeden zbiór uczacy
˛
(b) dwa zbiory uczace
˛
(c) trzy zbiory uczace
˛
(d) cztery zbiory uczace
˛
(e) osiem zbiorów uczacych
˛
(f) dwanaście zbiorów uczacych
˛
(g) szesnaście zbiorów uczacych
˛
(h) trzydzieści dwa zbiory uczace
˛
Rysunek 5.6. Rozkład liczby asercji o danym zakresie zmienności po analizie różnej liczby zbiorów
uczacych
˛
(implementacja bzip2, dane wejściowe o wielkości 4096 bajtów)
126
wykrytych asercji.
Charakter analogicznych zestawień dla innych implementacji i stosowanych wielkości
zbiorów danych wejściowych jest podobny do przedstawionego.
5.2.5. Analiza nieprawidłowych naruszeń asercji
Celem eksperymentu zwiazanego
˛
z badaniem zgłaszania fałszywych alarmów przez asercje
(nieprawidłowych naruszeń asercji) była obserwacja zachowania wykrytych asercji dla uruchomień programu z danymi wejściowymi obejmujacymi
˛
zbiory, które nie były uwzgl˛ednione
podczas procesu wykrywania asercji. W trakcie eksperymentu przebieg programu nie był
w żaden sposób zakłócany, a stosowane dane wejściowe były prawidłowe. Oznacza to, że
teoretycznie nie powinny pojawić si˛e żadne naruszenia asercji. Jednak charakter asercji,
które wykryte sa˛ poprzez dynamiczna˛ analiz˛e programu oraz charakter zbiorów trenujacych
˛
(ograniczona liczba możliwych danych wejściowych) moga˛ spowodować sytuacje, że niektóre
z asercji zostana˛ naruszone.
Jeśli takie zachowanie zostanie zaobserwowane b˛edzie ono
fałszywym alarmem. Jest to naruszenie, które nie powinno si˛e pojawić dla prawidłowych
uruchomień programów i wynika ono z niedoskonałości wykrytych asercji.
Eksperymenty tego typu wykonano dla wszystkich badanych bibliotek oraz stosowanych
wielkości zbiorów danych wejściowych wraz z zestawami asercji wykrytymi po pierwszym,
drugim, trzecim, czwartym, ósmym, szesnastym i trzydziestym drugim zbiorze uczacym.
˛
Obserwowano liczb˛e sprawdzeń asercji wraz z ich efektem (asercja nienaruszona albo asercja
naruszona).
Dla każdej kombinacji obejmujacej
˛
rodzaj implementacji, wielkość danych
wejściowych i liczb˛e zbiorów trenujacych
˛
wykonano osiem eksperymentów z zastosowaniem
różnych zbiorów danych wejściowych. Całościowe wyniki zebrano w tabeli 5.19. Dla każdej
z badanej liczby zestawów zbiorów trenujacych
˛
k (wyróżnione cz˛eści tabeli) oraz możliwych długości śladów l (kolejne wiersze w wyróżnionych cz˛eściach tabeli) podano stosunek
nieprawidłowych naruszeń asercji do ogólnej liczby ich sprawdzeń wyrażony w procentach
(nazywany dalej udziałem nieprawidłowych naruszeń asercji) w podziale na zakresy zmienP
ności asercji (punkt 5.2.4). W ostatniej kolumnie
podana została ogólna wartość udziału
nieprawidłowych naruszeń asercji, bez uwzgl˛ednienia wyróżnionych zakresów zmienności
asercji. Dane zostały opracowane za pomoca˛ skryptu z pakietu FlowGraph umożliwiajacego
˛
obserwacj˛e zachowania wykrytych asercji i rejestrujacym
˛
niezb˛edne statystyki.
Linia trendu dla ogólnej wartości udziału nieprawidłowych naruszeń asercji w badanym
zakresie liczby zbiorów uczacych
˛
opisuje odwrotnie proporcjonalny spadek udziału fałszywych
alarmów dla wzrostu liczby zbiorów trenujacych.
˛
Dwukrotne zwi˛ekszenie liczby zbiorów
trenujacych
˛
powoduje od około dwukrotnego do czterokrotnego spadku udziału nieprawidłowych naruszeń w odniesieniu do wszystkich sprawdzeń asercji. Przykładowo, dla asercji ze
śladem o l = 8 po zastosowaniu jednego zbioru trenujacego
˛
udział ten wynosi 0,69%, dwóch 127
k=1
0
1
2
3
4
5
6
7
8
0,16b
0,67
0,71
0,72
0,71
0,71
0,72
0,72
0,72
1,55
0,03
0,09
0,23
0,52
0,71
1,14
1,37
2,61
0,88
0,15
1,43
0,47
1,59
2,35
3,04
3,37
2,81
0,08
0,07
0,28
0,19
0,61
0,84
1,11
1,28
1,54
0,02
0,02
1,43
4,84
4,41
3,64
2,14
1,84
1,52
8,62
0,12
0,19
0,20
0,18
0,21
0,25
0,29
0,34
0,13
3,77
4,73
3,18
8,09
10,20
10,08
8,58
8,36
0,08
0,00
0,26
0,88
1,31
1,26
2,32
5,62
7,97
0,30
0,37
6,79
1,61
1,20
0,79
1,64
2,48
2,29
0,13
0,10
0,12
0,16
0,21
0,25
0,30
0,36
0,42
0,41
0,53
0,59
0,60
0,62
0,63
0,65
0,67
0,69
k=2
0
1
2
3
4
5
6
7
8
0,17
0,34
0,37
0,38
0,38
0,38
0,39
0,39
0,39
0,33
0,06
0,42
0,19
0,63
0,83
1,07
1,24
1,20
0,10
0,04
0,13
0,15
0,14
0,16
0,18
0,19
0,22
0,10
2,77
3,24
2,52
3,83
4,96
5,95
6,59
7,06
0,02
0,01
0,02
0,03
0,02
0,03
0,03
0,04
0,05
0,66
0,15
0,11
0,13
0,16
0,18
0,23
0,25
0,28
0,00
4,95
4,57
6,52
7,67
7,57
7,08
7,77
7,57
0,81
8,79
10,48
10,19
10,79
11,31
11,63
11,73
11,79
–
–
–
7,89
4,88
3,61
2,25
3,41
5,32
17,97
19,59
21,28
22,34
22,59
22,55
22,79
22,78
23,02
0,17
0,29
0,32
0,33
0,34
0,35
0,36
0,37
0,39
k=3
0
1
2
3
4
5
6
7
8
0,11
0,25
0,27
0,28
0,28
0,28
0,29
0,29
0,30
0,06
0,03
0,08
0,09
0,10
0,11
0,13
0,15
0,16
0,05
0,72
1,85
1,48
1,82
1,48
1,46
1,60
1,68
0,07
0,04
0,04
0,05
0,06
0,07
0,07
0,08
0,09
1,96
2,66
2,53
3,11
3,55
3,24
3,12
3,30
3,30
14,71
9,29
8,58
9,25
9,38
9,87
9,75
9,70
9,86
7,14
8,24
9,29
9,99
11,2
11,67
12,32
12,42
12,63
–
0,00
0,00
6,56
10,31
7,30
6,07
5,26
7,29
–
–
–
–
7,14
8,04
9,76
7,36
9,47
14,91
19,12
22,35
22,53
23,22
24,20
23,27
23,36
23,07
0,11
0,21
0,24
0,24
0,25
0,25
0,27
0,27
0,28
k=4
P
0
1
2
3
4
5
6
7
8
0,04
0,15
0,16
0,16
0,17
0,17
0,18
0,18
0,18
0,03
0,03
0,09
0,11
0,09
0,10
0,11
0,13
0,15
0,07
0,03
0,03
0,04
0,04
0,05
0,06
0,07
0,08
3,21
3,74
4,14
4,11
4,25
4,41
4,46
4,28
4,26
10,00
8,28
8,84
10,61
10,75
11,01
10,56
9,82
8,86
12,98
10,75
10,42
9,93
10,44
10,51
10,18
10,36
10,40
–
–
12,79
17,96
13,49
12,80
12,77
12,66
13,29
5,47
7,14
10,25
11,3
12,15
12,55
12,44
11,89
12,54
–
–
–
–
17,86
36,36
–
3,13
16,67
22,00
28,10
26,62
25,76
25,51
26,61
26,01
25,91
26,00
0,04
0,13
0,14
0,15
0,15
0,16
0,17
0,17
0,18
k=8
< 10, 20) < 20, 30) < 30, 40) < 40, 50) < 50, 60) < 60, 70) < 70, 80) < 80, 90) < 90, 100 >
0
1
2
3
4
5
6
7
8
0,02
0,03
0,04
0,04
0,04
0,04
0,04
0,05
0,05
0,03
0,01
0,01
0,01
0,02
0,02
0,03
0,03
0,03
5,12
3,97
3,99
3,93
3,95
4,19
4,11
4,25
4,35
6,25
8,15
7,25
6,71
6,61
6,45
6,53
6,45
6,56
6,00
11,76
12,56
12,84
12,13
13,09
12,19
10,90
10,94
12,50
11,29
12,07
12,11
11,97
12,48
12,14
12,16
12,25
–
30,77
17,33
15,63
13,93
13,74
12,70
13,23
13,06
–
0,00
23,08
24,14
19,32
15,38
16,78
16,39
14,87
–
–
–
–
31,25
25,00
23,08
30,00
21,05
–
8,33
16,67
21,61
23,76
23,95
22,24
22,47
21,92
0,02
0,03
0,03
0,04
0,04
0,04
0,05
0,05
0,06
k = 16
< 0, 10)a
0
1
2
3
4
5
6
7
8
0,01
0,02
0,02
0,02
0,02
0,02
0,02
0,02
0,03
4,62
2,41
2,19
2,07
2,14
2,28
2,19
2,12
2,09
5,52
8,16
7,58
6,76
6,39
5,95
5,55
5,32
5,31
–
14,29
6,45
7,12
6,11
6,22
5,87
5,77
5,73
–
0,00
4,17
10,91
8,96
10,11
9,84
10,74
9,31
–
5,56
10,42
10,65
9,52
10,78
11,01
11,79
12,06
–
–
16,67
17,50
20,00
15,29
13,60
16,40
17,69
–
–
–
12,50
14,29
17,86
20,45
17,19
19,15
–
–
0,00
0,00
0,00
5,56
9,09
11,54
12,50
–
50,00
21,43
33,33
31,01
30,08
27,88
28,05
27,83
0,01
0,02
0,02
0,02
0,03
0,03
0,03
0,03
0,03
k = 32
l
0
1
2
3
4
5
6
7
8
0,01
0,02
0,02
0,02
0,02
0,02
0,02
0,02
0,02
3,18
2,68
2,15
2,01
2,10
2,24
2,05
1,99
2,07
–
0,00
4,62
5,78
4,86
4,59
4,73
4,74
4,50
–
0,00
5,00
7,04
7,61
7,77
7,64
7,29
7,22
–
–
0,00
4,17
4,76
7,55
11,31
14,29
11,81
–
–
10,00
7,89
8,33
8,33
8,43
10,42
11,66
–
50,00
50,00
50,00
40,00
22,73
17,24
18,42
18,28
–
–
–
25,00
12,50
10,00
8,33
21,43
26,92
–
–
–
–
–
–
25,00
27,78
28,57
–
0,00
0,00
8,33
8,93
15,45
14,53
16,56
17,26
0,01
0,02
0,02
0,02
0,02
0,02
0,02
0,02
0,02
a
b
górne i dolne ograniczenia przedziałów podano w procentach
wartości podano w procentach
Tabela 5.19. Rozkład nieprawidłowych naruszeń asercji w ogólnej liczbie sprawdzeń asercji dla różnej
liczby wykorzystanych zbiorów uczacych
˛
128
0,39%, czterech – 0,18%, ośmiu – 0,06%. Dla asercji ze śladem o l = 4 wartości te wynosza˛
odpowiednio 0,62%, 0,34%, 0,15%, 0,04%. Stosowanie wi˛ekszej liczby zbiorów trenujacych
˛
pozytywnie wpływa na otrzymany wynik, jednak wraz z rosnac
˛ a˛ liczba˛ zbiorów wpływ ten jest,
w wartościach bezwzgl˛ednych, coraz mniejszy. Należy zauważyć, że nawet po zastosowaniu
tylko jednego zbioru trenujacego
˛
udział fałszywych alarmów jest niewielki.
Wraz ze zwi˛ekszajac
˛ a˛ si˛e długościa˛ śladu badanych asercji rośnie liczba ich nieprawidłowych naruszeń. Jest to skutek wi˛ekszej specjalizacji tych asercji co skutkuje ich wi˛eksza˛
wrażliwościa˛ nie tylko na bł˛edy, ale również w sytuacjach badanych w tym eksperymencie.
Zachowanie to należy uznać za wad˛e stosowania asercji ze śladem. Najwi˛ekszy przyrost udziału
nieprawidłowych asercji można zaobserwować porównujac
˛ asercje bez śladu oraz asercje ze
śladem jednostkowej długości. Dalsze wydłużanie śladu ma coraz mniejszy wpływ na wzrost
tej wartości.
Najbardziej zbliżonymi do ogólnej wartości (kolumna
P
) udziału nieprawidłowych
naruszeń asercji sa˛ wartości dla asercji o małym zakresie zmienności. Wartości, które w istotny
sposób odbiegaja˛ od wartości ogólnej (maja˛ istotnie wyższa˛ lub niższa˛ wartość) można uznać
za lokalne anomalie w odniesieniu do wartości ogólniej. Wynikaja˛ one z niewielkiej liczby
sprawdzeń asercji podlegajacych
˛
obserwacji w danym przedziale zmienności.
5.2.6. Analiza wykrywania bł˛edów przez asercje
Seria eksperymentów dotyczacych
˛
wykrywania bł˛edów przez asercje ze śladem miała na
celu zbadanie zachowania asercji podczas uruchomień programów w zaburzonym środowisku.
Podczas eksperymentów wprowadzano nast˛epujace
˛ rodzaje zakłóceń do wykonywanych programów:
— zakłócenie wartości zmiennej w programie polegajace
˛ na losowej inwersji jednego bitu
w losowej zmiennej z zakresów od najmłodszego do: pierwszego, drugiego, trzeciego,
czwartego, ósmego, szesnastego i trzydziestego drugiego bitu; zmienny zakres miał na
celu wprowadzenie zróżnicowania zakresu zmiany wybranej zmiennej (od najmniejszej do
najwi˛ekszej),
— zakłócenie przebiegu wykonania programu, gdzie symulowano pomini˛ecie losowego
punktu obserwacji poprzez usuni˛ecie go z aktualnie obserwowanego śladu jej wykonania;
miało to na celu wprowadzenie zakłócenia w śladzie wykonania programu.
Wszystkie wprowadzane zakłócenia miały charakter przemijajacy
˛ i ich wpływ obejmował
jeden punkt w programie. Do realizacji eksperymentów wykorzystano skrypt injector z pakietu
FlowGraph.
W eksperymentach wykorzystano wszystkie badane programy. Aplikacje uruchamiano
stosujac:
˛
— pierwszy zbiór danych uczacych,
˛
ponieważ były to dane wejściowe znane na etapie
129
wykrywania asercji dla wszystkich zbiorów asercji ze śladem zwiazanych
˛
odpowiednia˛
z liczba˛ zbiorów uczacych,
˛
— nieznany na etapie wykrywania asercji losowy zbiór danych wejściowych.
Sumaryczne wyniki naruszeń asercji w przypadku zakłóconych wartości zmiennych przy
zastosowaniu danych wejściowych wykorzystanych w fazie nauki zebrano w tabeli 5.20.
W każdej komórce tabeli podano procentowy udział uruchomień programów zakończonych
wykryciem wprowadzonego bł˛edu w stosunku do wszystkich uruchomień badanych programów. Wyniki przedstawiono dla różnych zakresów obszaru zakłóceń zmiennych (kolumny
1–1, 1–2, 1–4, 1–8, 1–16, 1–32) oraz zestawów asercji o określonych długościach śladów l
P
znalezionych po zastosowaniu danej liczby zbiorów trenujacych
˛
k. W ostatniej kolumnie
podano wynik dla wszystkich zakresów obszaru zakłóceń zmiennych. W każdym z eksperymentów wykonano w sumie około dwóch milionów uruchomień badanych implementacji.
Analogiczne wyniki dla nieznanego w fazie nauki zbioru danych wejściowych przedstawia
tabela 5.21.
Analiza otrzymanych wyników wskazuje, że stosowanie coraz wi˛ekszego zakresu zakłócania zmiennych skutkuje wi˛eksza˛ liczba˛ bł˛edów wykrywanych przez asercje. Wartości te
rosna˛ od około 8% dla obszaru 1–1 do 24% dla obszaru 1–32. Analogiczny efekt powoduje
stosowanie asercji z wi˛eksza˛ długościa˛ śladu - wartości rosna˛ o około od trzech punktów
procentowych dla obszaru 1–1 do jednego punktu procentowego dla obszaru 1–32 wraz ze
zwi˛ekszajacymi
˛
si˛e długościami śladu l.
Liczba obserwowanych naruszeń jest wi˛eksza przy zastosowaniu danych wejściowych
nieznanych w trakcie nauki.
Jest to wynikiem dodatkowych nieprawidłowych naruszeń
omawianych w poprzednim punkcie.
Różnica ta jest jednak wi˛eksza niż obserwowane
wcześniej nieprawidłowe naruszenia (punkt 5.2.5, tabela 5.19). Jest to spowodowane wpływem
stosowanych zakłóceń.
Podobnie jak w przypadku fałszywych alarmów asercji wraz ze
wzrostem długości śladu l obserwowany jest coraz wi˛ekszy przyrost zgłaszanych naruszeń.
Wynosi on od dwóch do ośmiu punktów procentowych dla k = 1 i maleje do kilku setnych
punktu procentowego dla k = 32.
Porównujac
˛
ogólna˛
liczb˛e
nieprawidłowych
naruszeń
asercji
przedstawionych
w punkcie 5.2.5 z naruszeniami asercji spowodowanymi bł˛edami podczas wykonania
programu dla danych wejściowych nieznanych w fazie nauki zauważalna jest istotna różnica
w ich liczbie. Przykładowo, dla k = 1 i l = 8 wartości wynosza˛ odpowiednio 0,69% i 14,67%,
dla k = 32 i l = 8 – 0,02% i 14,24%. Istotne różnice świadcza˛ o dobrej jakości wykrywanych
asercji mimo stosowania ograniczonej liczby zbiorów trenujacych.
˛
Może to pozwolić na
rozróżnienie czy naruszenia asercji sa˛ wynikiem ich niedoskonałości czy też pojawiajacych
˛
si˛e bł˛edów. Sposób ten był z powodzeniem używany przy zastosowaniu asercji w systemie
nadzoru transportu (punkt 6.2).
130
a
b
l
1–1a
1–2
1–3
1–4
1–8
1–16
1–32
P
k=1
0
1
2
3
4
5
6
7
8
8,10b
9,34
10,10
10,03
10,27
10,27
10,37
10,57
10,55
8,61
9,57
10,35
10,49
10,55
10,62
10,80
10,87
10,88
8,59
9,80
10,50
10,64
10,73
10,83
11,15
11,15
11,29
8,85
10,10
10,97
11,13
11,31
11,50
11,74
11,83
12,00
11,10
12,63
13,33
13,50
13,63
13,79
14,13
14,04
14,04
17,54
18,42
18,86
19,06
19,43
19,31
19,40
19,38
19,46
23,46
23,91
24,35
24,33
24,45
24,40
24,52
24,53
24,46
12,32
13,39
14,06
14,17
14,34
14,39
14,59
14,62
14,67
k=2
0
1
2
3
4
5
6
7
8
7,88
9,00
9,85
9,87
10,02
10,12
10,09
10,25
10,30
8,15
9,25
10,04
10,01
10,19
10,21
10,40
10,48
10,53
8,29
9,62
10,19
10,30
10,51
10,49
10,79
10,85
11,07
8,60
9,90
10,78
10,98
11,14
11,26
11,45
11,54
11,85
11,09
12,46
13,31
13,38
13,66
13,63
13,77
14,02
13,96
17,40
18,28
18,94
19,07
19,02
19,27
19,37
19,26
19,46
23,45
23,89
24,18
24,16
24,42
24,33
24,50
24,42
24,56
12,12
13,20
13,90
13,97
14,14
14,19
14,34
14,40
14,53
k=3
0
1
2
3
4
5
6
7
8
7,80
8,95
9,72
9,67
9,88
9,89
9,91
10,08
10,15
7,99
9,09
9,96
9,98
10,10
10,12
10,21
10,40
10,50
8,25
9,32
10,19
10,35
10,42
10,50
10,69
10,74
10,93
8,58
9,73
10,71
10,89
10,98
11,19
11,52
11,64
11,69
11,01
12,30
13,22
13,32
13,54
13,55
13,88
13,86
13,87
17,46
18,29
18,86
18,81
18,95
19,27
19,35
19,37
19,31
23,37
23,77
24,22
24,28
24,26
24,41
24,55
24,51
24,54
12,07
13,06
13,84
13,90
14,02
14,13
14,30
14,37
14,43
k=4
0
1
2
3
4
5
6
7
8
7,84
8,92
9,64
9,74
9,79
9,96
10,03
9,89
9,99
8,05
9,02
9,88
9,78
10,04
10,00
10,21
10,34
10,48
8,16
9,38
10,12
10,32
10,32
10,46
10,70
10,79
10,93
8,59
9,79
10,61
10,80
10,99
11,16
11,31
11,51
11,73
11,09
12,23
13,23
13,25
13,45
13,63
13,75
13,96
13,87
17,35
18,39
18,86
18,93
19,01
19,18
19,17
19,35
19,47
23,54
23,92
24,12
24,00
24,22
24,30
24,46
24,54
24,60
12,08
13,09
13,77
13,83
13,97
14,09
14,22
14,34
14,43
k=8
0
1
2
3
4
5
6
7
8
7,72
8,88
9,68
9,60
9,76
9,83
9,88
9,95
10,02
8,00
9,02
9,78
9,95
9,97
10,01
10,25
10,30
10,43
8,22
9,36
10,04
10,09
10,20
10,32
10,57
10,60
10,82
8,47
9,67
10,49
10,74
10,85
11,15
11,26
11,35
11,52
11,00
12,33
13,00
13,17
13,31
13,51
13,61
13,81
13,81
17,41
18,25
18,69
18,82
19,13
19,14
19,26
19,34
19,42
23,22
23,94
24,06
24,44
24,41
24,35
24,09
24,35
24,53
12,00
13,06
13,67
13,82
13,94
14,04
14,13
14,24
14,36
k = 16
0
1
2
3
4
5
6
7
8
7,67
8,75
9,53
9,44
9,55
9,69
9,76
9,77
9,81
7,96
9,00
9,76
9,79
9,88
9,90
10,05
10,17
10,33
8,23
9,21
10,06
10,01
10,10
10,13
10,48
10,45
10,73
8,47
9,64
10,51
10,86
10,82
11,03
11,18
11,31
11,45
10,96
12,25
12,96
13,17
13,34
13,47
13,53
13,74
13,71
17,20
18,14
18,66
18,70
19,12
19,16
19,12
19,31
19,26
23,46
23,96
24,18
24,12
24,15
24,27
24,40
24,36
24,50
11,99
12,99
13,67
13,73
13,85
13,95
14,08
14,16
14,26
k = 32
0
1
2
3
4
5
6
7
8
7,69
8,73
9,44
9,51
9,56
9,71
9,67
9,81
9,82
7,89
8,88
9,82
9,82
9,93
9,92
10,02
10,21
10,26
8,15
9,22
9,95
10,11
10,18
10,27
10,35
10,53
10,81
8,45
9,57
10,39
10,57
10,74
10,92
11,13
11,27
11,39
10,86
12,25
13,04
13,11
13,26
13,42
13,51
13,71
13,70
17,47
18,13
18,62
18,74
18,95
19,20
19,14
19,17
19,25
23,39
23,76
24,06
24,23
24,30
24,22
24,27
24,33
24,45
11,99
12,94
13,62
13,73
13,85
13,95
14,01
14,15
14,24
obszar obejmowany zakłóceniem liczony od najmłodszego bitu
Tabela 5.20. Rozkład wykrytych zakłóceń dla znanego przebiegu programu w ogólnej liczbie zakłóceń
danego rodzaju dla różnej liczby wykorzystanych zbiorów uczacych
˛
131
a
b
l
1–1a
1–2
1–3
1–4
1–8
1–16
1–32
P
k=1
0
1
2
3
4
5
6
7
8
10,24b
15,09
16,83
17,34
18,12
19,20
20,59
22,18
23,81
10,70
15,47
17,08
17,73
18,47
19,57
21,02
22,49
24,37
10,86
15,55
17,26
18,01
18,77
19,77
21,21
22,79
24,68
11,08
16,01
17,82
18,39
19,24
20,53
21,96
23,58
25,28
13,51
18,46
20,15
20,81
21,62
22,74
24,24
25,76
27,51
19,86
24,19
25,69
26,03
27,32
28,37
29,59
31,03
32,81
25,89
29,69
30,95
31,57
32,38
33,28
34,61
36,19
37,75
14,60
19,17
20,64
20,89
21,19
21,41
21,79
22,04
22,31
k=2
0
1
2
3
4
5
6
7
8
8,60
13,38
14,42
14,76
15,37
16,10
16,75
17,77
18,88
8,98
13,57
14,58
15,13
15,61
16,30
17,12
18,19
19,20
9,18
13,77
14,83
15,18
15,87
16,52
17,42
18,35
19,40
9,48
14,16
15,41
15,75
16,38
17,26
18,06
19,17
20,41
11,98
16,74
17,81
18,28
18,71
19,54
20,41
21,54
22,47
18,32
22,63
23,44
23,91
24,37
25,16
25,90
26,79
28,03
24,28
28,16
28,64
29,17
29,74
30,32
30,96
31,80
33,07
12,97
17,47
18,35
18,56
18,76
19,00
19,20
19,43
19,69
k=3
0
1
2
3
4
5
6
7
8
7,91
12,61
13,50
13,56
14,11
14,55
15,17
15,83
16,69
8,08
12,78
13,78
13,92
14,25
14,91
15,33
16,12
17,06
8,37
12,88
14,00
14,21
14,52
15,18
15,80
16,64
17,41
8,70
13,41
14,42
14,62
15,15
15,81
16,34
17,29
18,25
11,12
15,87
16,83
17,07
17,58
18,08
18,68
19,55
20,33
17,49
21,83
22,46
22,59
23,23
23,74
24,25
24,96
25,68
23,61
27,31
27,86
28,02
28,38
28,89
29,36
29,94
30,91
12,18
16,67
17,53
17,60
17,83
18,08
18,24
18,42
18,59
k=4
0
1
2
3
4
5
6
7
8
7,70
12,55
13,41
13,42
14,00
14,28
14,76
15,33
15,96
7,99
12,68
13,54
13,77
14,05
14,58
15,01
15,53
16,39
8,28
12,82
13,94
14,01
14,32
14,76
15,40
16,07
16,73
8,66
13,25
14,31
14,41
15,02
15,56
16,01
16,80
17,41
11,04
15,70
16,72
17,00
17,25
17,79
18,34
19,03
19,68
17,33
21,80
22,17
22,62
22,94
23,39
23,92
24,51
25,14
23,60
27,36
27,79
27,91
28,36
28,65
28,97
29,57
30,36
12,08
16,58
17,38
17,49
17,70
17,88
18,05
18,22
18,37
k=8
0
1
2
3
4
5
6
7
8
7,72
8,95
9,66
9,74
9,92
10,12
10,20
10,49
10,78
8,07
9,12
10,02
10,08
10,18
10,15
10,54
10,90
11,21
8,24
9,31
10,15
10,25
10,37
10,57
10,93
11,24
11,48
8,53
9,77
10,63
10,75
11,02
11,34
11,67
11,96
12,37
10,89
12,21
13,13
13,25
13,37
13,76
13,95
14,45
14,79
17,43
18,10
18,83
18,98
18,94
19,34
19,65
19,84
19,90
23,32
23,84
24,13
24,49
24,35
24,38
24,93
24,93
25,12
12,04
13,05
13,80
13,94
14,00
14,16
14,39
14,52
14,62
k = 16
0
1
2
3
4
5
6
7
8
7,75
8,81
9,55
9,61
9,75
9,78
9,97
10,05
10,19
8,02
9,09
9,75
9,84
9,93
10,1
10,15
10,44
10,69
8,22
9,21
10,01
10,21
10,30
10,41
10,55
10,79
11,03
8,39
9,65
10,53
10,75
10,93
11,15
11,28
11,58
11,78
10,98
12,20
13,16
13,21
13,52
13,44
13,83
13,92
14,19
17,28
18,46
18,87
18,99
18,97
19,31
19,42
19,49
19,68
23,38
24,13
24,27
24,34
24,37
24,59
24,64
24,73
24,61
12,00
13,08
13,73
13,85
13,96
14,08
14,22
14,33
14,41
k = 32
0
1
2
3
4
5
6
7
8
7,70
8,89
9,46
9,54
9,62
9,74
9,89
9,93
10,08
7,95
8,91
9,74
9,86
9,98
10,02
10,12
10,35
10,49
8,24
9,21
10,07
10,10
10,25
10,41
10,37
10,69
10,91
8,46
9,62
10,42
10,72
10,91
11,18
11,28
11,38
11,59
10,83
12,19
13,15
13,17
13,42
13,51
13,82
13,77
13,95
17,28
18,27
18,86
18,86
19,07
19,27
19,21
19,37
19,29
23,34
23,90
24,26
24,08
24,29
24,36
24,65
24,48
24,62
11,97
13,00
13,71
13,77
13,93
14,06
14,17
14,26
14,35
obszar obejmowany zakłóceniem liczony od najmłodszego bitu
Tabela 5.21. Rozkład wykrytych zakłóceń dla nieznanego przebiegu programu w ogólnej liczbie
zakłóceń danego rodzaju dla różnej liczby wykorzystanych zbiorów uczacych
˛
132
Rezultaty dla eksperymentów, w których symulowano zakłócenie przebiegu wykonania
programu poprzez usuwanie punktu obserwacji z rejestrowanego śladu wykonania przy znanych
w fazie nauki danych wejściowych przedstawia tabela 5.22.
W każdej komórce tabeli
podano łaczny
˛
rezultat dla wszystkich badanych implementacji określajacy
˛ udział uruchomień
programów zakończonych wykryciem zakłócenia w stosunku do wszystkich uruchomień
programów w rozdzieleniu na stosowane zestawy asercji znane po określonej liczbie zbiorów
uczacych
˛
k i długości śladów asercji l. Z powodu wykrywania bł˛edów wykrytych przez
asercje o krótszym śladzie również przez asercje ze śladem dłuższym wyniki podano w sposób
przyrostowy. Oznacza to, że na przykład udział wykrytych bł˛edów dla asercji ze śladem
o długości trzech punktów jest suma˛ udziału wykrytych bł˛edów dla asercji bez zastosowanego
śladu do śladu o długości trzech punktów. Taki sposób przedstawienia wyników pozwala na obserwacj˛e zysku przy wydłużeniu śladu o jeden punkt. W każdym z eksperymentów wykonano
w sumie około pi˛ećdziesi˛eciu tysi˛ecy uruchomień badanych programów. Analogiczne wyniki
dla nieznanego w fazie nauki zbioru danych wejściowych zebrano w tabeli 5.23.
k
l
1
0
0,00a
1 19,01
2 16,88
3
5,90
4 4,08
5
0,27
6 0,24
7
0,18
8 0,34
a
2
3
4
8
16
32
0,00
19,34
17,40
5,73
4,04
0,29
0,23
0,18
0,35
0,00
19,22
17,44
5,62
4,22
0,32
0,22
0,16
0,36
0,00
19,10
17,74
5,45
4,15
0,29
0,21
0,14
0,40
0,00
19,13
17,28
5,77
4,18
0,30
0,27
0,12
0,49
0,00
19,20
17,18
5,83
4,17
0,34
0,27
0,15
0,39
0,00
19,12
17,69
5,47
4,10
0,31
0,20
0,13
0,51
Tabela 5.22. Rozkład wykrytych zakłóceń w przebiegu programu dla znanego zbioru danych wejściowych w ogólnej liczbie zakłóceń dla różnej liczby wykorzystanych zbiorów uczacych
˛
Przeważajacy
˛ wzrost liczby wykrytych bł˛edów obserwowany jest dla śladów o długości
jednego i dwóch punktów. Odpowiednio wynosi on około dziewi˛etnaście i siedemnaście
punktów procentowych. Dla śladów o długości trzech i czterech punktów jest on już ponad
czterokrotnie mniejszy, a dla wi˛ekszych długości staje si˛e pomijalny. Ogólny udział wykrytych
zakłóceń dla asercji o długości czterech punktów kształtuje si˛e na poziomie około 45% (suma
wykrytych zakłóceń dla l = 1 . . . 4).
Zwi˛ekszanie liczby zbiorów uczacych
˛
skutkuje w wi˛ekszości przypadków wzrostem liczby
wykrywanych bł˛edów, jednak jest to wpływ niewielki, rz˛edu dziesiatych
˛
cz˛eści punktu
procentowego. Świadczy to o niewielkim przyroście asercji uwzgl˛edniajacych
˛
nowe ślady
wykonania po zastosowaniu kolejnych zbiorów trenujacych.
˛
Wyst˛epujace
˛ spadki można uznać
za wyjatki
˛ b˛edace
˛ skutkiem losowego wprowadzania bł˛edów do aplikacji.
133
k
l
1
a
0
0,00
1 20,27
2 16,81
3
4,68
4 4,04
5
0,33
6 0,24
7
0,21
8 0,42
a
2
3
4
8
16
32
0,00
20,31
17,62
4,79
4,05
0,35
0,24
0,20
0,40
0,00
20,13
17,36
5,14
4,09
0,31
0,24
0,17
0,38
0,00
19,73
17,60
5,05
4,20
0,37
0,25
0,15
0,45
0,00
19,04
17,49
5,88
4,22
0,30
0,23
0,14
0,51
0,00
19,31
17,42
5,71
4,06
0,28
0,22
0,17
0,59
0,00
19,06
17,44
5,82
4,17
0,33
0,25
0,12
0,44
Tabela 5.23. Rozkład wykrytych zakłóceń w przebiegu programu dla nieznanych zbiorów danych
wejściowych w ogólnej liczbie zakłóceń dla różnej liczby wykorzystanych zbiorów uczacych
˛
Różnice obserwowane pomi˛edzy tabela˛ 5.22 a 5.23 nie wykazuja˛ określonego trendu.
Można je uznać za fluktuacje b˛edace
˛ nast˛epstwem losowego charakteru zakłóceń. Oznacza
to, że przebieg działania badanych aplikacji, mimo stosowania różnych danych wejściowych,
jest podobny.
5.2.7. Operacje na asercjach ze śladem
Na wykrytych zbiorach asercji ze śladem wykonano algorytmy zaproponowane w rozdziale
czwartym. Wykorzystana została ich implementacja zrealizowana w pakiecie FlowGraph.
W tabeli 5.24 przedstawione zostały łacznie
˛
liczby stosowanych śladów dla wszystkich
punktów programu przed (n) i po (n0 ) zastosowaniu algorytmu redukcji liczby śladów
(algorytm 4.1). W ostatniej kolumnie dla każdej z badanych implementacji podano wyrażony
w procentach spadek liczby stosowanych śladów wyliczony jako
n−n0
.
n
Wyniki rozdzielono
wzgl˛edem stosowanych wielkości zbiorów uczacych
˛
s oraz długości śladów wykrytych asercji
l. W każdym przypadku osiagni˛
˛ ety spadek liczby stosowanych śladów wynosi ponad 50%.
Wynika to z typu wykrywanych asercji. Dla każdej ze zmiennych wykryte były zawsze dwie
asercje o tym samym śladzie, co spowodowało redukcj˛e ich liczby o co najmniej połow˛e.
Dodatkowy spadek wynika z wi˛ekszej liczby zmiennych w danym punkcie obserwacji, których
ślady wykrytych asercji ze śladem mogły zostać połaczone.
˛
Tabela 5.25 zawiera procentowy spadek łacznej
˛
długości wszystkich stosowanych śladów
dla badanych implementacji w wyniku zastosowania algorytmu skracania śladów (algorytm 4.2). W zależności od badanej biblioteki osiagni˛
˛ eto spadek łacznej
˛
długości stosowanych
śladów od około 14% do 76%. Pozwala to na zmniejszenie rozmiaru aplikacji z uwagi na
mniejsza˛ liczb˛e punktów obserwacji przechowywanych w śladach asercji. Spadek łacznej
˛
długości śladów rośnie wraz ze wzrostem ich długości. Różnice obserwowane dla różnej
wielkości stosowanych zbiorów uczacych
˛
s wynosza˛ do dwóch punktów procentowych.
134
JZlib
n0
n
%
n
n0
%
s = 512
%
0
1
2
3
4
5
6
7
8
460 203
878 382
1182 510
1444 615
1694 720
1980 850
2294 991
2630 1132
3012 1296
55,87 252 110
56,49 560
242
56,85 852 370
57,41 1098 489
57,50 1352 593
57,07 1596 641
56,80 1876 791
56,96 2142 901
56,97 2472 1048
56,35 144 60
56,79 340 146
56,57 510 218
55,46 646 282
56,14 784 350
59,84 944 427
57,84 1154 518
57,94 1382 623
57,61 1638 738
58,33
57,06
57,25
56,35
55,36
54,77
55,11
54,92
54,95
s = 1024
n0
0
1
2
3
4
5
6
7
8
460 202
878 380
1184 514
1452 610
1712 728
2012 841
2342 1002
2710 1129
3124 1289
56,09 252 108
56,72 560
238
56,59 858 362
57,99 1122 470
57,48 1384 581
58,20 1640 689
57,22 1934 810
58,34 2236 947
58,74 2580 1076
57,14 142 59
57,50 344 146
57,81 510 216
58,11 656 280
58,02 788 346
57,99 946 422
58,12 1154 512
57,65 1374 612
58,29 1618 721
58,45
57,56
57,65
57,32
56,09
55,39
55,63
55,46
55,44
s = 2048
n
bzip2
0
1
2
3
4
5
6
7
8
460 203
878 381
1184 513
1454 615
1714 721
2022 856
2368 987
2760 1118
3198 1284
55,87 252 110
56,61 560
238
56,67 860 363
57,70 1122 471
57,93 1380 578
57,67 1634 682
58,32 1926 810
59,49 2232 937
59,85 2590 1078
56,35 144 60
57,50 340 146
57,79 508 217
58,02 658 283
58,12 808 353
58,26 966 429
57,94 1174 519
58,02 1399 622
58,38 1648 734
58,33
57,06
57,28
56,99
56,31
55,59
55,79
55,54
55,46
s = 4096
l
jazzlib
0
1
2
3
4
5
6
7
8
460 203
878 384
1186 512
1456 614
1716 732
2016 863
2338 1007
2696 1149
3108 1313
55,87 252 109
56,26 562
239
56,83 866 359
57,83 1142 469
57,34 1426 601
57,19 1706 720
56,93 2018 842
57,38 2344 980
57,75 2720 1124
56,75
57,47
58,55
58,93
57,85
57,80
58,28
58,19
58,68
59,09
57,73
57,94
57,53
56,95
56,83
57,07
57,04
57,31
154
362
554
730
906
1112
1358
1634
1956
63
153
233
310
390
480
583
702
835
Tabela 5.24. Zmiana liczby stosowanych śladów we wszystkich punktach obserwacji po zastosowaniu
algorytmu 4.1 redukcji liczby śladów
135
JZlib
jazzlib
bzip2
l
%
%
%
s = 512
1
2
3
4
5
6
7
8
0,00
19,61
22,49
30,56
38,02
47,11
58,05
64,71
0,00
14,32
26,84
42,49
56,00
61,82
69,57
75,46
0,00
33,24
40,66
47,32
52,67
59,07
66,34
75,34
s = 1024
1
2
3
4
5
6
7
8
0,00
19,84
21,04
30,29
38,36
46,57
58,00
65,07
0,00
14,74
27,66
43,20
56,01
62,08
70,46
76,26
0,00
33,33
40,85
47,30
52,47
58,78
66,25
75,36
s = 2048
1
2
3
4
5
6
7
8
0,00
19,88
22,49
30,51
37,34
48,40
58,70
64,93
0,00
14,88
27,99
43,50
57,10
62,72
70,98
76,34
0,00
33,27
41,29
46,66
52,46
59,28
66,40
75,34
s = 4096
1
2
3
4
5
6
7
8
0,00
19,92
22,37
31,28
38,59
46,74
57,86
64,55
0,00
14,90
27,00
42,95
57,73
63,64
70,79
76,91
0,00
33,57
39,18
46,80
53,90
59,88
67,26
75,45
Tabela 5.25. Procentowy spadek łacznej
˛
długości śladów dla wszystkich punktów obserwacji po
zastosowaniu algorytmu 4.2 skracania śladów
przed redukcja˛
po redukcji
JZlib
194
34
jazzlib
161
33
bzip2
106
30
Tabela 5.26. Liczba stosowanych różnych identyfikatorów punktów obserwacji przed i po zastosowaniu
algorytmu 4.3 redukcji identyfikatorów
136
W tabeli 5.26 przedstawiono poczatkow
˛
a˛ liczb˛e stosowanych identyfikatorów punktów
obserwacji oraz uzyskana˛ w wyniku zastosowania algorytmu redukcji liczby identyfikatorów
punktów programu w zbiorach asercji ze śladem (algorytm 4.3). Dla każdej implementacji
zaobserwowano spadek liczby identyfikatorów. Do zakodowania poczatkowej
˛
liczby identyfikatorów dla implementacji JZlib oraz jazzlib należałoby zastosować co najmniej 8 bitów,
dla implementacji bzip2 co najmniej 7 bitów. W wyniku redukcji liczby identyfikatorów
punktów obserwacji liczba bitów potrzebnych do kodowania jest mniejsza o 3 bity dla każdej
z implementacji.
5.2.8. Wnioski
Przedstawione rezultaty pozwalaja˛ na stwierdzenie, iż mimo niedoskonałości znalezionych
asercji, która jest skutkiem stosowania ograniczonego zbiór danych trenujacych
˛
i przejawia
si˛e zgłaszaniem fałszywych alarmów przez asercje ze śladem (punkt 5.2.5) możliwe jest
wykrycie nieprawidłowego zachowania aplikacji, które jest skutkiem wystapienia
˛
w niej
bł˛edów prowadzacych
˛
do zakłócenia w śladzie wykonania lub wartości zmiennych programu
(punkt 5.2.6). Najcz˛eściej nast˛epuje w takich przypadkach istotny wzrost udziału naruszeń asercji w ogólnej liczbie ich sprawdzeń, co może być przesłanka˛ do wniosku o jej nieprawidłowym
zachowaniu. Zastosowanie modyfikacji algorytmów wykrywajacych
˛
asercje w programach
poprzez uzależnienie wykrywanych asercji od śladu wykonania pozwala na podwyższenie
poziomu detekcji bł˛edów z ich użyciem. Na podstawie przeprowadzonych eksperymentów
wzrost ten wyniósł od kilku do 130%, przy procentowym udziale wykrytych bł˛edów w zakresie
od 8% do 37% (punkt 5.2.6, tabele 5.20 i 5.21) oraz stopie fałszywych alarmów wynoszacej
˛ do
0,7% (punkt 5.2.5, tabela 5.19).
137
6. Zastosowania
W niniejszym rozdziale przedstawiono wybrane obszary zastosowań opisanej w rozdziale
trzecim metody selekcji asercji oraz specjalizacji wykrywanych asercji poprzez wykorzystanie
asercji ze śladem zaprezentowanej w rozdziale czwartym. W pierwszej cz˛eści skupiono si˛e na
analizie możliwości rozszerzenia istniejacych
˛
systemów wykrywania asercji o nowe funkcje
oraz na wykorzystaniu zaproponowanych metod w zastosowaniach takich jak lokalizacja
bł˛edów w oprogramowaniu, automatycznej detekcji anomalii w działaniu programów czy też
wspomaganiu pracy programisty, analityka lub użytkownika systemów. W drugiej cz˛eści
rozdziału przedstawiono raport z zastosowania pakietu FlowGraph (dodatek A.2) w detekcji
i lokalizacji bł˛edów wyst˛epujacych
˛
w systemie nadzoru transportu.
6.1. Wybrane obszary zastosowań
6.1.1. Systemy wykrywania asercji
Istniejace
˛ systemy wykrywajace
˛ asercje w programach (rozdział drugi), takie jak pakiet
Daikon [33, 66], DIDUCE [44] czy AgitarOne [95], moga˛ zostać rozszerzone o możliwość
obserwacji śladu wykonania badanych aplikacji oraz takiej klasyfikacji kolekcjonowanych
danych, aby wykrywane były asercje ze śladem (punkt 4.4). Dodanie takich funkcji nie powinno
być operacja˛ trudna,˛ a tym bardziej nie wymagajac
˛ a˛ istotnej modyfikacji struktury istniejacych
˛
systemów. Obserwacja pojedynczego punktu programu, jaka ma miejsce przy wykrywaniu
asercji w nim spełnionych, powinna zostać zastapiona
˛
obserwacja˛ punktu programu zależna˛ od
jego przebiegu w wyznaczonej długości. Implementacje algorytmów wykrywajacych
˛
asercje
na zmiennych programu w określonym jego punkcie pozostaja˛ niezmienione. Korzystaja˛ one
jedynie z innego zestawu zebranych danych, rozdzielonych w zależności od przebiegu programu. W systemach wykrywania asercji zaimplementowane moga˛ zostać również algorytmy
redukcji liczby śladów w zbiorze asercji ze śladem (punkt 4.4.1), skracania śladów w zbiorze
asercji ze śladem (punkt 4.4.2) oraz redukcji liczby identyfikatorów punktów programu dla
zbiorów asercji ze śladem (punkt 4.5.1). Dzi˛eki temu przedstawiony jako wynik zbiór asercji ze
śladem może być wst˛epnie przygotowany do dalszego wykorzystania. Uzupełnienie systemów
wykrywania asercji o możliwość wykrywania asercji ze śladem przy ustalonej długości śladu
nie wpłynie w sposób istotny na czas wykrywania asercji mimo iż ich liczba może być dużo
wi˛eksza. Zmniejsza si˛e jednak ilość danych przeznaczonych do analizy na cele wykrycia
139
pojedynczej asercji. Wykrywanie asercji dla różnych długości śladów, w zależności od ich
typu, może sprowadzać si˛e do łaczenia
˛
odpowiednich asercji znalezionych w asercjach ze
śladem o dłuższym śladzie lub konieczności ponownej analizy wszystkich danych zebranych
dla danego śladu.
Określenie, pomiar i analiza wybranych parametrów asercji (punkt 3.2) oraz wybór
podzbioru asercji poprzez optymalizacj˛e jego parametrów wzgl˛edem określonych kryteriów
(punkt 3.3) może również stać si˛e cz˛eścia˛ implementacji systemów wykrywania asercji.
Operacja ta może być przeprowadzona w końcowej fazie działania, kiedy eliminowane sa˛
asercje, które po uwzgl˛ednieniu pewnych kryteriów uznawane sa˛ za nadmiarowe. Wymagane
jest jednak określenie pewnego zbioru testów na podstawie którego dokonana zostanie analiza
parametrów znalezionych asercji. Wszystkie wykryte asercje moga˛ zostać automatycznie
wprowadzone do badanego programu i po wykonaniu testów przeprowadzona zostać może faza
ich selekcji. Operacje takie realizowane sa˛ przez pakiet AEM (dodatek A.1). Rozszerzenie
systemów wykrywania asercji o automatyczny etap przeprowadzenia testów (punkt 5.1.3) na
cele optymalizacji w istotny sposób wpłynie na czas działania tych systemów z uwagi na
czasochłonność zwiazan
˛ a˛ z przeprowadzeniem odpowiedniej liczby testów.
6.1.2. Detekcja bł˛edów w programach
Asercje wykryte automatycznie i wprowadzone do programu umożliwiaja˛ detekcj˛e nie
tylko bł˛edów programowych, ale również powstałych na skutek niestabilności pracy wykorzystywanego sprz˛etu, systemu operacyjnego, środowiska, zastosowanej konfiguracji czy też
powstałych w wyniku interakcji z innymi modułami. Bł˛edy takie wprowadzano do programów
badanych w punkcie 5.1 i zastosowane tam asercje umożliwiały ich detekcj˛e. W zależności
od rodzaju wykrytego bł˛edu asercje moga˛ nie tylko przerywać działanie programu, ale również
skutkować wywołaniem procedury majacej
˛ na celu podj˛ecie akcji awaryjnej, jak na przykład
próba naprawy konfiguracji.
6.1.3. Lokalizacja bł˛edów w programach
Stosowanie wykrytych asercji we wczesnej fazie testowania oprogramowania umożliwia
wykrycie oraz lokalizacj˛e potencjalnych bł˛edów w tworzonym oprogramowaniu. Szczególne
przydatne moga˛ być asercje ze śladem ze wzgl˛edu na możliwość określenia bardziej
szczegółowych warunków, w których doszło do naruszenia asercji. Ponadto asercje, które
wykryte zostaja˛ w uzależnieniu od przebiegu programu, charakteryzuja˛ si˛e wi˛eksza˛ specjalizacja˛ co cz˛esto przekłada si˛e na wi˛eksze pokrycie bł˛edów, jakie moga˛ pojawić si˛e podczas jego
wykonania (punkt 5.2). Na etapie produkcyjnego stosowania aplikacji, w której wprowadzono
weryfikacj˛e asercji ze śladem, dane o jej naruszeniu moga˛ umożliwić określenie bardziej
140
szczegółowych warunków oraz przyczyny naruszenia jakie zostało zaobserwowane [51].
Zastosowanie takie przedstawiono w punkcie 6.2.
6.1.4. Detekcja anomalii w działaniu programów
Użycie asercji ze śladem może być przydatne w systemach przetwarzajacych
˛
dane w pewien
określony, stały sposób. Uzależnienie asercji jakie wykryte moga˛ zostać w przetwarzanym
zbiorze danych od śladu wykonania może pozwolić na wczesna˛ detekcj˛e anomalii podczas jego
działania, charakteryzujac
˛ a˛ si˛e na przykład znaczacym
˛
wzrostem naruszeń asercji (punkt 5.2.6).
Dynamiczne wykrywanie i wykorzystanie asercji, w szczególności asercji ze śladem może
zostać zintegrowane z badanym programem poprzez odpowiedni moduł b˛edacy
˛ jego cz˛eścia˛ lub
aplikacj˛e monitorujac
˛ a.˛ Przykładem takiego narz˛edzia jest pakiet FlowGraph (dodatek A.2).
W poczatkowej
˛
fazie działania programu moduł ten przetwarza określone dane pozyskiwane
z programu wykrywajac
˛ i przechowujac
˛ określone asercje.
W kolejnej fazie naruszenia
znalezionych asercji moga˛ być raportowane jako wykryte anomalie w działaniu programu,
a sam moduł może nadal modyfikować znalezione asercje ze wzgl˛edu na nowo otrzymane
dane lub bazować na znalezionych już asercjach. Zakres wykrywanych asercji może być
zróżnicowany i uzależniony od rodzaju badanej aplikacji. Ze wzgl˛edu na charakter działania
wykrywane asercje powinny należeć do takiej grupy, dla której możliwe jest znalezienie
i modyfikacja w trybie rzeczywistym.
6.1.5. Wspomaganie pracy programisty/analityka/użytkownika
Dynamiczne wykrywanie asercji podczas rozwoju oprogramowania umożliwia programiście niezależna˛ weryfikacj˛e poprawności tworzonego kodu w odniesieniu do własności
zmiennych jakie zostaja˛ wykryte. Niektóre ze znalezionych asercji pozwalaja˛ na szybkie
wykrycie popełnionych bł˛edów lub eliminacj˛e drobnych nieścisłości, które moga˛ prowadzić do
poważnych awarii w produkcyjnym działaniu aplikacji. Szczególna˛ rol˛e odgrywaja˛ tu asercje
ze śladem, które moga˛ być trudne do bezpośredniego określenia przez programist˛e.
Znalezione asercje moga˛ być szczególnie pomocne podczas analizy nieznanego oprogramowania.
Prezentuja˛ one własności programu obowiazuj
˛ ace
˛ w trakcie jego działania
i dzi˛eki temu umożliwiaja˛ szybsze powiazanie
˛
przegladanego
˛
kodu źródłowego z regułami
biznesowymi. Asercje ze śladem, zawierajace
˛ dodatkowa˛ informacj˛e o przebiegu programu,
pozwalaja˛ zrozumieć jego zachowanie oraz znaleźć zależności pomi˛edzy przebiegiem działania
programu a regułami biznesowymi które dla danych przebiegów obowiazuj
˛ a.˛
Istotna˛ rol˛e odgrywać moga˛ metody wizualizacji asercji ze śladem omówione w punkcie
4.7. Wykrywane asercje moga˛ zostać wykorzystane podczas tworzenia poimplementacyjnej
specyfikacji lub dokumentacji oprogramowania oraz na etapie jego implementacji poprzez
141
integracj˛e prezentowania wykrytych asercji w środowisku rozwoju aplikacji na przykład
z użyciem pomocy kontekstowej.
Obserwowane naruszenia asercji, rejestrowane na przykład w dzienniku działania aplikacji,
moga˛ pomóc jej użytkownikom w efektywnym zgłaszaniu anomalii.
6.1.6. Systemy weryfikacji oprogramowania
Systemy weryfikacji oprogramowania, wykorzystujace
˛ wykryte asercje w celu jego statycznej lub dynamicznej analizy moga˛ zostać rozszerzone o możliwość stosowania asercji ze
śladem. W systemach, w których zaimplementowano już weryfikacj˛e asercji kontrolujacych
˛
przebieg programu konieczne jest umożliwienie sprawdzenia pewnego podzbioru asercji
obowiazuj
˛ acego
˛
dla wybranego przebiegu.
Można to osiagn
˛ ać
˛ poprzez połaczenie
˛
tych
asercji w odpowiednim warunku logicznym lub poprzez zawarcie ich w bloku programu
weryfikujacym
˛
asercje ze śladem w wybrany sposób.
6.1.7. Inne zastosowania
Metoda selekcji asercji oraz wykorzystanie informacji jakie niosa˛ proponowane parametry
asercji moga˛ zostać wykorzystane do analizy innych konstrukcji programowych, których celem
jest w szczególności usuwanie awarii powstałych podczas działania programów. Modyfikacja
pewnych elementów zaproponowanej metody poprzez wprowadzenie lub usuni˛ecie wybranych
ograniczeń oraz parametrów pozwoli na zastosowanie jej dla pewnych specyficznych aplikacji,
w których konieczne może być uwzgl˛ednienie dodatkowych własności badanych struktur
programu jak na przykład wielkość dodatkowej pami˛eci operacyjnej jaka musi zostać zarezerwowana w celu ich wykonania.
Idea asercji ze śladem oraz różnych sposobów ich weryfikacji (punkt 4.5) może zostać
wykorzystana z innymi strukturami programowymi zast˛epujacymi
˛
lub uzupełniajacymi
˛
asercje
w połaczeniu
˛
ze śladem wykonania programu.
6.2. System nadzoru transportu
Aplikacja˛ komercyjna˛ działajac
˛ a˛ w środowisku produkcyjnym, dla której zastosowano
oprogramowanie wykrywajace
˛ i weryfikujace
˛ asercje ze śladem opisane w dodatku A.2 w celu
detekcji i lokalizacji bł˛edów, był system nadzoru transportu.
Przeznaczony jest on do
obserwacji przebiegu procedury transportu towarów obejmujacej
˛ akcje takie jak rejestracja
towarów, wysyłka, dojazd, przejazd przez punkty pośrednie, kontrola tranzytu, zgłaszanie
uwag, automatyczne informowanie zainteresowanych stron o przebiegu tranzytu oraz generowanie statystyk i raportów. System działa i jest dost˛epny w trybie ciagłym,
˛
wyłaczaj
˛
ac
˛
142
sytuacje, gdy przeprowadzana jest jego aktualizacja lub wystapiła
˛
awaria krytyczna sprz˛etu
lub oprogramowania.
System jest stworzony w całości w j˛ezyku C. W ramach systemu udost˛epnione sa˛ poprzez
infrastruktur˛e sieciowa˛ 34 serwisy. Określona przez producenta wartość TLOC (liczba linii
kodu źródłowego) dla całości systemu wynosi 198792. Implementacja zawiera 138 plików
źródłowych oraz 41 plików nagłówkowych.
Jako punkty obserwacji wybrano wszystkie
miejsca w systemie, które odkładaja˛ informacje do dziennika działania aplikacji. Zakres
i charakter odkładanych informacji został określony przez producenta systemu. Sa˛ to w wi˛ekszości rejestracje wartości wybranych zmiennych w programie oraz informacje diagnostyczne.
Wiele z wyznaczonych punktów raportuje informacje o wyniku działania wywoływanych
funkcji. Liczba punktów obserwacji wynosi 6185.
System przechowuje dane w zewn˛etrznej bazie danych. Klienci wykorzystuja˛ system
poprzez zewn˛etrzna˛ aplikacj˛e korzystajac
˛ a˛ z usług udost˛epnionych przez serwisy. Aplikacja
zewn˛etrzna nie podlegała obserwacji.
Badane oprogramowanie w trakcie doby, która obejmuje dzień roboczy generuje od
około 220 tysi˛ecy do 310 tysi˛ecy linii informacji diagnostycznych, które odpowiadaja˛ liczbie
wizyt w punktach obserwacji. Jeżeli doba przypada na dzień wolny od pracy liczba linii
informacji diagnostycznych jest wielokrotnie mniejsza i wynosi od około 15 tysi˛ecy do
20 tysi˛ecy. Wygenerowane informacje diagnostyczne były wst˛epnie przetworzone skryptem
w celu przystosowania ich do formatu akceptowanego przez stosowane narz˛edzia z pakietu
FlowGraph. W szczególności przetwarzanie dotyczyło rozdzielenia przeplatajacych
˛
si˛e informacji diagnostycznych z różnych procesów wywołanych przez niezależnych klientów lub
przychodzace
˛ wiadomości. Takie sytuacje były traktowane jako analiza niepowiazanych
˛
ze
soba˛ procesów w systemie.
Do wygenerowania asercji ze śladem użyto informacji diagnostycznych z pełnego tygodnia
działania systemu obejmujacego
˛
pi˛eć dni roboczych i dwa dni wolne od pracy.
czasie nie zaobserwowano oznak wadliwego działania systemu.
W tym
Długość śladu ustalono
arbitralnie na trzy. Wykrywano asercje jedynie dla wartości całkowitoliczbowych badajac
˛
zależność pomi˛edzy wartościa˛ zmiennej a liczba˛ 0. W otrzymanym modelu użyte zostały
5184 różne punkty obserwacji i wykryto 12903 asercje ze śladem. Założono, że wpis do
pliku informacji diagnostycznych zawierajacy
˛ identyfikator punktu w programie jest punktem
obserwacji. Zastosowane zostały jedynie punkty obserwacji wprowadzone przez twórców
omawianego systemu.
Poprzez analiz˛e plików z informacjami diagnostycznymi za pomoca˛ narz˛edzi z pakietu
FlowGraph wygenerowano struktur˛e danych przechowujac
˛ a˛ wykryte asercje ze śladem. Była
ona stosowana do obserwacji systemu jako narz˛edzie pomocnicze przez okres dwóch lat.
W tym czasie w systemie zaobserwowano sześć awarii krytycznych (prowadzacych
˛
do braku
143
realizacji jakichkolwiek usług) oraz dziewi˛etnaście bł˛edów (system zachował si˛e niezgodnie
ze specyfikacja).
˛ Zgłoszenia awarii krytycznych oraz bł˛edów przez klienta były realizowane
niezależnie od stosowania do ich wykrycia omawianej metody. Klient nie miał dost˛epu do
analiz przeprowadzanych przez pakiet FlowGraph.
Podczas przetwarzania informacji diagnostycznych z systemu cz˛esto zdarzały si˛e sytuacje
naruszeń asercji. W zależności od ilości danych diagnostycznych informacje o naruszeniach
pojawiały si˛e średnio co kilkanaście minut. Sytuacje te były jednak ignorowane jeśli nie
powtarzały si˛e one z duża˛ cz˛estotliwościa,˛ określana˛ w zależności od ilości spływajacych
˛
danych diagnostycznych i naruszeń asercji. Zakładano, że pojedyncze naruszenia asercji sa˛
fałszywymi alarmami. Sytuacj˛e uznawano za awaryjna,˛ kiedy wskutek dostarczania informacji
diagnostycznych o kolejno osiaganych
˛
punktach obserwacji wi˛ekszość z nich prowadziła
do naruszenia asercji ze śladem. Decyzja ta była jednak subiektywna i zależała od osoby
obserwujacej
˛ informacje o naruszeniach asercji ze śladem.
Dla pi˛eciu awarii krytycznych oraz czternastu bł˛edów (z ogólnej liczby zgłoszonych
przez klienta) obserwowano tuż przed zgłoszeniem zauważalny przyrost naruszanych asercji
ze śladem. W tym samym okresie zaobserwowano również około sześćdziesi˛eciu sytuacji,
które sugerowały wystapienie
˛
awarii krytycznej lub bł˛edu, jednak po szczegółowej analizie
okazywały si˛e poprawnym zachowaniem systemu. Każdorazowo po wystapieniu
˛
takiej sytuacji
powtórnie przetwarzano informacje diagnostyczne z aktywna˛ opcja˛ aktualizacji struktury
danych w pakiecie FlowGraph w celu zmiany oraz wykrycia nowych asercji ze śladem.
Sytuacje te dotyczyły zazwyczaj rzadko wykorzystywanych funkcji systemu, które nie były
użyte we wst˛epnej fazie wykrywania asercji ze śladem.
Mimo to należy je zaliczyć do
kategorii nieprawidłowych naruszeń asercji. Oznacza to, że około 25% sytuacji awaryjnych
zostało wcześniej zarejestrowanych dzi˛eki monitorowaniu pracy aplikacji (dziewi˛etnaście
potwierdzonych przez klienta przypadków na około osiemdziesiat
˛ alarmów sugerujacych
˛
awari˛e).
W przypadku trzech awarii krytycznych oraz dwunastu bł˛edów punkty obserwacji,
w których naruszane były asercje ze śladem były pośrednio zwiazane
˛
z punktem, gdzie
wyst˛epował znaleziony wskutek analizy informacji diagnostycznych przez programist˛e bład
˛
implementacyjny. Dla dwóch awarii krytycznych przyczyna˛ było nieprawidłowe działanie
komponentów zewn˛etrznych takich jak baza danych lub system operacyjny.
w wi˛ekszości zwiazane
˛
były z obserwacja˛ nieprawidłowego śladu.
Naruszenia
Dla jednej z awarii
krytycznych naruszenia dotyczyły wykrytej asercji i bezpośrednio wskazywały na obszar kodu
źródłowego, w którym programista znalazł bład
˛ implementacyjny.
Każdorazowo, po wprowadzeniu poprawek w systemie udoskonalano struktur˛e danych
wygenerowana˛ przez FlowGraph poprzez przeanalizowanie danych diagnostycznych z aktualizacja˛ struktury danych przechowujacej
˛ asercje ze śladem z dwóch lub trzech dni roboczych.
144
W końcowym etapie w wygenerowanej strukturze danych użyte zostały 5502 różne punkty
obserwacji i wykryto 13891 asercji ze śladem.
Podsumowujac,
˛ zastosowanie asercji ze śladem umożliwiło stosunkowo szybka˛ lokalizacj˛e
bł˛edów implementacyjnych przez programist˛e. W wi˛ekszości przypadków pozwoliło również
na przygotowanie zespołu obsługujacego
˛
system do rejestracji zgłoszenia awarii krytycznej
lub bł˛edu przez klienta. Można uznać, że dla omawianego systemu asercje ze śladem były
przydatnym narz˛edziem dla dodatkowego monitorowania systemu mimo zdarzajacych
˛
si˛e
fałszywych informacji o potencjalnej awarii krytycznej lub bł˛edzie. Nie było możliwości
powtórzenia omawianego eksperymentu dla innych niż założone na poczatku
˛
parametry jak
długość śladu i rodzaje wykrywanych asercji, ze wzgl˛edu na długi okres jego trwania oraz inne
ograniczenia formalne w dost˛epie do informacji diagnostycznych z systemu.
145
7. Podsumowanie
Praca dotyczy zagadnień wykrywania, oceny skuteczności oraz optymalizacji wykorzystania asercji w programach. W kontekście literatury dotyczacej
˛ przedmiotu badań zagadnienia te
zostały omówione w punkcie 1.1. Treść rozdziału drugiego stanowi rozszerzone wprowadzenie
do tematyki rozprawy. Teza oraz cel pracy zostały przedstawione w punkcie 1.2. Poniżej
podsumowano najważniejsze osiagni˛
˛ ecia autora.
Oryginalna metoda selekcji i oceny asercji
Opracowano algorytm selekcji asercji w programie z użyciem metod programowania
liniowego (punkt 3.3) wykorzystujacy
˛ zdefiniowany przez autora zestaw parametrów pozwalajacych
˛
wyrazić mi˛edzy innymi skuteczność i nieskuteczność asercji w detekcji bł˛edów oraz
szereg innych własności takich jak liczba sprawdzeń asercji, koszt statyczny, dynamiczny
oraz zwiazany
˛
z lokalizacja˛ asercji w programie, czas detekcji bł˛edu, zaufanie do asercji oraz
atrybuty i charakterystyki asercji (punkt 3.2). Usystematyzowano różnorodne kryteria zwiazane
˛
z wyborem zestawu asercji oraz zdefiniowano profile zachowania asercji w programach
(punkt 3.2.9) w kontekście reakcji na wprowadzone bł˛edy. Opracowano również metod˛e
weryfikacji oceny wkładu asercji do wykrywania bł˛edów (punkt 3.3.3). W końcowej cz˛eści
rozdziału przedstawiono działanie metody selekcji asercji uwzgl˛edniajac
˛ przebieg kolejnych
obliczeń (punkt 3.3.4).
Wprowadzenie asercji ze śladem
Metoda poprawy jakości asercji wykrywanych w sposób automatyczny poprzez uzależnienie ich od przebiegu wykonania programu została zaprezentowana w rozdziale czwartym.
Wprowadzono w nim poj˛ecie asercji ze śladem (punkt 4.2), zaproponowano i omówiono
algorytm ich wykrywania (punkt 4.4) oraz algorytmy optymalizujace
˛ ich użycie (algorytmy
4.1, 4.2 i 4.3) wraz z przykładem ich użycia (punkt 4.6). Przedstawione zostały również
przykładowe techniki wizualizacji asercji ze śladem (punkt 4.7) i stosowania ich w programach
(punkt 4.5). Omówiono możliwe sposoby rejestracji śladu (punkt 4.1.1).
Opracowanie oryginalnej metody badań eksperymentalnych oraz oprogramowania
wspomagajacego
˛
przeprowadzanie testów
Metodyka prowadzenia badań oraz raport z wykonanych, złożonych eksperymentów
wykorzystujacych
˛
zaproponowane algorytmy, zwiazane
˛
zarówno z metoda˛ selekcji asercji
147
jak i stosowania asercji ze śladem, przedstawione zostały w rozdziale piatym.
˛
Omówione
eksperymenty były ukierunkowane na szerokie spektrum bł˛edów. Symulowano w nich zarówno
bł˛edy programowe (mutacje) jak i sprz˛etowe. W niewielu pracach rozpatrzono ostatnia˛ klasa
bł˛edów [56]. Ogółem we wszystkich przeprowadzonych eksperymentach wykonano kilka
milionów jednostkowych testów badanych aplikacji.
Pierwsza seria eksperymentów (punkt 5.1) miała na celu zbadanie możliwości ograniczenia
liczby asercji w aplikacjach przy zachowaniu dobrego poziomu pokrycia bł˛edów. Stosowano
zróżnicowane strategie selekcji asercji oraz funkcje wartościujace
˛ asercje w celu zbadania
i prezentacji szerokich zastosowań tej metody. W licznych eksperymentach wykorzystano
unikalny system FITS [36, 37, 97] opracowany w Instytucie Informatyki Politechniki Warszawskiej przeznaczony do symulacji bł˛edów w systemie komputerowym oraz badania ich efektów.
Jego odpowiednia konfiguracja umożliwiła integracj˛e z modułami opracowanymi przez autora,
dzi˛eki czemu dane otrzymane na podstawie eksperymentów przeanalizowane zostały w sposób
automatyczny. Opracowana metoda selekcji asercji pozwoliła na ocen˛e zbioru asercji w detekcji
bł˛edów oraz ograniczenie ich liczby przy zachowaniu dobrego poziomu pokrycia bł˛edów.
W drugiej cz˛eści rozdziału (punkt 5.2) omówiono eksperymenty wykorzystujace
˛ asercje
ze śladem. Do przeprowadzenia doświadczeń zastosowano trzy implementacje algorytmów
z rodziny ZIP, zróżnicowana˛ liczb˛e zbiorów uczacych
˛
o różnych długościach stosowanych
danych wejściowych. W raporcie omówiono liczb˛e wykrytych asercji o długościach śladu
od 0 do 8 w odniesieniu do liczby zastosowanych zbiorów uczacych
˛
oraz rozmiaru danych
wejściowych (punkt 5.2.3), przeanalizowano proces wykrywania asercji (punkt 5.2.4) oraz ich
zachowanie w aspekcie nieprawidłowych naruszeń (punkt 5.2.5) i wykrywania bł˛edów b˛eda˛
cych skutkiem zakłócenia działania programu (punkt 5.2.6) zarówno dla wcześniej znanych
zbiorów danych wejściowych jak i nieznanych na etapie nauki. Przeprowadzone eksperymenty
wykazały, iż przy zastosowaniu asercji ze śladem znalezionych w sposób automatyczny
możliwe jest wykrycie nieprawidłowego zachowania aplikacji, które jest skutkiem wystapienia
˛
w niej bł˛edów prowadzacych
˛
do zakłócenia w śladzie wykonania lub wartości zmiennych
programu.
Możliwe obszary zastosowań dla zaproponowanych metod zostały omówione w rozdziale
szóstym. Przedstawiono tam również przypadek użycia, w którym z sukcesem zastosowano
asercje ze śladem do nadzoru działania aplikacji komercyjnej działajacej
˛
w środowisku
produkcyjnym realizujacej
˛ funkcj˛e systemu nadzoru transportu (punkt 6.2).
Opracowane przez autora oprogramowanie, omówione w dodatku do pracy, może zostać
wykorzystanie do przeprowadzenia analogicznych testów z użyciem innych aplikacji. Przeznaczone jest ono do analizy parametrów asercji w programie na podstawie wybranych miar
służacych
˛
do selekcji ich zestawu wzgl˛edem wybranej strategii oraz wykrywania, weryfikacji,
przekształcania oraz zakłócania asercji ze śladem.
148
7.1. Spostrzeżenia i wnioski
Zaprezentowane w pracy metody oraz algorytmy pozwalaja˛ na ograniczenie liczby
stosowanych asercji przy zachowaniu akceptowalnego poziomu wykrywania anomalii oraz
wykrywanie i stosowanie asercji o wi˛ekszej specjalizacji osiagni˛
˛ etej poprzez ich uzależnienie
od przebiegu badanego programu. Zmniejszenie liczby asercji pozwala w szczególności na
ograniczenie przyrostu statycznego i dynamicznego rozmiaru badanych programów wskutek
stosowania asercji oraz minimalizacj˛e czasu przeznaczonego na ich przetwarzanie. Wykrywanie i stosowanie asercji zależnych od przebiegu działania programu umożliwia wykrywanie
wi˛ekszej liczby bł˛edów oraz bardziej szczegółowe określanie okoliczności w jakich doszło do
zakłócenia działania aplikacji. Ta koncepcja wypełnia luk˛e pomi˛edzy klasycznymi asercjami
obliczeniowymi a technikami weryfikujacymi
˛
przepływ sterowania (techniki typu CFC [1, 2,
38, 75, 104]).
Zasadność stosowania przedstawionych metod została potwierdzona w wielu eksperymentach, w których zastosowano różne klasy aplikacji (sterownik, aplikacj˛e obliczeniowa,˛
programy kompresujace).
˛
Dzi˛eki temu możliwe było określenie ich potencjalnej przydatność.
Analogiczne eksperymenty moga˛ zostać wykonane dla innych aplikacji.
Należy zwrócić uwag˛e na problemy zwiazane
˛
z praktycznym zastosowaniem zaproponowanych metod. W przypadku konieczności pełnej integracji przedstawionych metod
z badanym programem konieczna jest ich implementacja w danym środowisku. Z tego powodu
istotnym zagadnieniem sa˛ metody implementacji. Na podstawie przeprowadzonych eksperymentów za najbardziej praktyczna˛ należy uznać realizacj˛e procesu wykrywania i weryfikowania
asercji z użyciem dzienników działania aplikacji. Wymaga ona dostosowania badanej aplikacji
jedynie w aspekcie sposobu przekazywania danych do zewn˛etrznego systemu wykrywajacego
˛
i weryfikujacego
˛
asercje. Nie może być ona jednak zastosowana w każdym z przypadków, dlatego szczególnie istotne jest opracowanie wydajnych i prostych w implementacji algorytmów
weryfikacji asercji w programach.
Przeprowadzone eksperymenty na wybranych programach potwierdziły przydatność zaproponowanych metod. Autor pracy jest świadomy, że moga˛ być one wykorzystane wyłacznie
˛
dla
pewnych klas aplikacji, obejmujacych
˛
w szczególności aplikacje transformacyjne oraz reaktywne, w których nie sa˛ stosowane czynniki losowe. Przy stosowaniu asercji ze śladem najlepsze
wyniki moga˛ być osiagni˛
˛ ete, jeżeli badany program cechuje ograniczony zbiór możliwych
danych wejściowych lub ich ograniczony wpływ na przebieg programu. Właściwości te cechuja˛
głównie systemy wykonujace
˛ w stały sposób określona˛ grup˛e zadań. Dla tego typu aplikacji
osiagano
˛
najlepsze wyniki w stosowaniu asercji ze śladem do detekcji anomalii.
Stosowanie metody optymalizujacej
˛ zestaw asercji może przynieść zamierzone efekty, jeżeli
w trakcie fazy majacej
˛ na celu zbadanie zachowania asercji poddana b˛edzie ona na działanie
różnorodnych bł˛edów.
Przy dużych zbiorach asercji jest to proces bardzo czasochłonny.
149
Niezb˛edne jest wykorzystanie narz˛edzi pozwalajacych
˛
na symulacj˛e szerokiej gamy zakłóceń
w badanych programach. Dzi˛eki temu zastosowany zestaw testów b˛edzie reprezentatywny,
a asercje wybrane na jego podstawie b˛eda˛ pokrywały różnorodne bł˛edy.
W rozprawie potwierdzona została założona teza pracy oraz osiagni˛
˛ eto wyznaczone cele.
7.2. Kierunki dalszych badań
Praca ta może być punktem wyjściowym do dalszych badań nad rozwojem algorytmów
wykrywania różnorodnych własności programów oraz ich wykorzystania. Pomimo zaproponowania pewnych metod pozostaje nadal szereg ważnych i ciekawych zagadnień, których
rozważenie i zbadanie wykraczało poza zakres niniejszej pracy. Sa˛ to zarówno problemy
wymagajace
˛ przeprowadzenia szeregu eksperymentów jak i zagadnienia natury inżynierskiej
zwiazane
˛
z technikami implementacji oprogramowania.
Jednym z wielu kierunków jest rozwój metod umożliwiajacych
˛
wykrywanie różnych
typów asercji, szczególnie wyrażajacych
˛
pewne ogólniejsze cechy programów – zarówno
w kontekście przechowywanych i przetwarzanych przez nie struktur danych, realizowanych
procesów biznesowych jak i innych źródeł bł˛edów, b˛edacych
˛
skutkiem na przykład wadliwie
działajacego
˛
sprz˛etu.
Celowe wydaje si˛e powiazanie
˛
wykrywania asercji z wybranymi
algorytmami stosowanymi w dziedzinie odkrywania wiedzy takimi jak na przykład wykrywanie
reguł asocjacyjnych lub zależności temporalnych. Przedstawione w tej pracy wykrywanie
asercji ze śladem można uznać za podstawowa˛ realizacj˛e asercji zależnej od pewnej reguły
temporalnej. Asercje wykryte w kontekście bardziej zróżnicowanych reguł temporalnych,
uwzgl˛edniajacych
˛
na przykład czas działania aplikacji czy wybranych komponentów systemu
komputerowego, moga˛ okazać si˛e skuteczniejsze w wykrywaniu bł˛edów.
Badania moga˛
również dotyczyć powiazania
˛
metod statycznej analizy programów z opisywana˛ w pracy
metoda˛ bazujac
˛ a˛ jedynie na informacjach uzyskanych podczas jego wykonania. Może to
umożliwić polepszenie jakości otrzymywanych asercji poprzez rozszerzenie klas wykrywanych
przez nie bł˛edów.
Kontynuacja badań przez autora pracy obejmować b˛edzie:
— zbadanie możliwości integracji faz wykrywania asercji oraz wyboru najlepszych z nich
według wybranych strategii,
— zastosowanie i dostosowanie wybranych algorytmów z dziedziny metod odkrywania wiedzy
majace
˛ na celu wydajniejsze znajdowanie zaawansowanych asercji w programach,
— problematyk˛e automatycznego wykrywania asercji na poziomie kodu maszynowego programu (asercje zwiazane
˛
z wartościami przechowywanymi w rejestrach, kolejnościa˛
wykonywanych instrukcji itp.) oraz ich skuteczności w wykrywaniu bł˛edów,
— rozwój narz˛edzi umożliwiajacych
˛
wykrywanie asercji, optymalizacj˛e ich wykorzystania
150
oraz monitorowania badanego programu w celu wykrywania potencjalnych anomalii w jego
zachowaniu wynikajacych
˛
zarówno z bł˛edów oprogramowania jak i sprz˛etowych.
151
Bibliografia
[1] Z. Alkhalifa, V. S. S. Nair. Design of a portable control-flow checking technique. High-Assurance
Systems Engineering Workshop, 1997., Proceedings, strony 120–123, sierpień 1997.
[2] Z. Alkhalifa, V. S. S. Nair, N. Krishnamurthy, J. A. Abraham.
Design and evaluation of
system-level checks for on-line control flow error detection. Parallel and Distributed Systems,
IEEE Transactions on, 10(6):627–641, lipiec 1999.
[3] G. Ammons, R. Bodik, J. R. Larus. Mining specifications. SIGPLAN Not., 37(1):4–16, 2002.
[4] G. Ammons, D. Mandelin, R. Bodik, J. R. Larus. Debugging temporal specifications with concept
analysis. PLDI 2003: Proceedings of the ACM SIGPLAN 2003 conference on Programming
language design and implementation, strony 182–195, New York, NY, USA, 2003. ACM Press.
[5] V. R. Basili. The Role of Experimentation in Software Engineering: Past, Current, and Future.
ICSE, strony 442–449, 1996.
[6] T. Bell. The concept of dynamic analysis. ESEC/FSE-7: Proceedings of the 7th European software engineering conference held jointly with the 7th ACM SIGSOFT international symposium
on Foundations of software engineering, strony 216–234, London, UK, 1999. Springer-Verlag.
[7] M. Bender. Finding loop invariants by static program analysis.
[8] A. Benso, S. Di Carlo, G. Di Natale, P. Prinetto, L. Tagliaferri. Control-flow checking via regular
expressions. Test Symposium, 2001. Proceedings. 10th Asian, strony 299–303, 2001.
[9] A. Benso, S. Di Carlo, G. Di Natale, P. Prinetto, L. Tagliaferri. Software dependability techniques
validated via fault injection experiments. Radiation and Its Effects on Components and Systems,
2001. 6th European Conference on, strony 269–274, wrzesień 2001.
[10] M. Boul, Z. Zilic.
Generating Hardware Assertion Checkers: For Hardware Verification,
Emulation, Post-Fabrication Debugging and On-Line Monitoring. Springer Publishing Company,
Incorporated, 2008.
[11] Y. Brun, M. D. Ernst. Finding latent code errors via machine learning over program executions.
ICSE 2004: Proceedings of the 26th International Conference on Software Engineering, strony
480–490, Edinburgh, Scotland, maj 2004.
[12] L. Burdy, Y. Cheon, D. Cok, M.D. Ernst, J. Kiniry, G. T. Leavens, K. Rustan, M. Leino,
E. Poll. An overview of JML tools and applications. Software Tools for Technology Transfer,
7(3):212–232, czerwiec 2005.
[13] L. Burdy, A. Requet, J.-L. Lanet. Java Applet Correctness: A Developer-Oriented Approach.
K. Araki, S. Gnesi, D. Mandrioli, redaktorzy, FME 2003: Formal Methods: International Symposium of Formal Methods Europe, wolumen 2805 serii LNCS, strony 422–439. Springer-Verlag,
2003.
153
[14] Palo Alto Research Center. The AspectJ Programming Guide, 2002-2003.
[15] P. Chalin, J. R. Kiniry, G. T. Leavens, E. Poll. Beyond Assertions: Advanced Specification
and Verification with JML and ESC/Java2. FMCO 2005: Formal Methods for Components and
Objects, Revised Lectures, wolumen 4111 serii LNCS, strony 342–363. SV, 2006.
[16] F. Chen, N. Tillmann, W. Schulte. Discovering Likely Method Specifications. Raport instytutowy
MSR-TR-2005-146, Microsoft Research, Redmond, WA, USA, październik 2005.
[17] J. W. Chinneck. Practical Optimization: a Gentle Introduction, 2000.
[18] Paweł Cichosz. Systemy uczace
˛ si˛e. Wydawnictwo Naukowo-Techniczne, Warszawa, 2000.
[19] T. H. Cormen, C. E. Leiserson, R. L. Rivest, C. Stein. Introduction to Algorithms. MIT Press,
2001.
[20] C. Csallner, Y. Smaragdakis. DSD-Crasher: A hybrid analysis tool for bug finding. ISSTA 2006:
Proceedings of the International Symposium on Software Testing and Analysis, strony 245–254,
Portland, ME, USA, lipiec 2006.
[21] C. Csallner, Y. Smaragdakis. Dynamically discovering likely interface specifications. ICSE 2006:
Proceedings of the 28th International Conference on Software Engineering, strony 861–864,
Shanghai, China, maj 2006.
[22] M. d’Amorim, C. Pacheco, D. Marinov, T. Xie, M. D. Ernst. An empirical comparison of
automated generation and classification techniques for object-oriented unit testing. ASE 2006:
Proceedings of the 21st Annual International Conference on Automated Software Engineering,
strony 59–68, Tokyo, Japan, wrzesień 2006.
[23] W. B. Daszczuk.
Weryfikacja własności temporalnych w systemach współbieżnych.
Praca
doktorska, Politechnika Warszawska, Wydział Elektroniki i Technik Informacyjnych, Instytut
Informatyki, Warszawa, styczeń 2003.
[24] L. Dean, D. Ernst, C. Smith. Improved simulation of Input/Output automata. Raport instytutowy,
MIT Department of Electrical Engineering and Computer Science, 2001.
[25] T. Denmat, A. Gotlieb, M. Ducassé. Proving or disproving likely invariants with constraint
reasoning. WLPE 2005: 15th Workshop on Logic-based Methods in Programming Environments,
październik 2005.
[26] Daikon Developers. The Daikon Invariant Detector User Manual, czerwiec 2010.
[27] N. Dodoo, L. Lin, M. D. Ernst. Selecting, refining, and evaluating predicates for program analysis.
Raport instytutowy MIT-LCS-TR-914, MIT Laboratory for Computer Science, Cambridge, MA,
lipiec 2003.
[28] S. Elbaum, M. Diep. Profiling deployed software: Assessing strategies and testing opportunities.
IEEE Transactions on Software Engineering, 31(4):312–327, kwiecień 2005.
[29] M. D. Ernst.
Dynamically Discovering Likely Program Invariants.
Ph.D., University of
Washington Department of Computer Science and Engineering, Seattle, Washington, sierpień
2000.
[30] M. D. Ernst, J. Cockrell, W. G. Griswold, D. Notkin.
Dynamically discovering likely
program invariants to support program evolution. IEEE Transactions on Software Engineering,
27(2):99–123, luty 2001.
154
[31] M. D. Ernst, A. Czeisler, W. G. Griswold, D. Notkin. Quickly detecting relevant program
invariants.
ICSE 2000: Proceedings of the 22nd International Conference on Software
Engineering, strony 449–458, Limerick, Ireland, czerwiec 2000.
[32] M. D. Ernst, W. G. Griswold, Y. Kataoka, D. Notkin. Dynamically discovering program invariants involving collections. Raport instytutowy UW-CSE-99-11-02, University of Washington
Department of Computer Science and Engineering, Seattle, WA, listopad 1999.
[33] M. D. Ernst, J. H. Perkins, P. J. Guo, S. McCamant, C. Pacheco, M. S. Tschantz, C. Xiao. The
Daikon system for dynamic detection of likely invariants. Science of Computer Programming,
2006.
[34] H. Foster, L. Foster, D. Lacey, A. Krolnik. Assertion-Based Design. Kluwer Academic Publishers,
Norwell, MA, USA, 2003.
[35] S. J. Garland, N. Lynch. Using i/o automata for developing distributed systems. In Gary
T. Leavens and Murali Sitaraman, editors, Foundations of Component-Based Systems, strony
285–312. Cambridge University Press, 2000.
[36] P. Gawkowski, J. Sosnowski. Analyzing fault effects in fault insertion experiments. On-Line
Testing Workshop, 2001. Proceedings. Seventh International, strony 21–24, 2001.
[37] P. Gawkowski, J. Sosnowski. Using software implemented fault inserter in dependability analysis.
Dependable Computing, 2002. Proceedings. 2002 Pacific Rim International Symposium on,
strony 81–88, grudzień 2002.
[38] O. Goloubeva, M. Rebaudengo, M. Sonza Reorda, M. Violante. Soft-error detection using control
flow assertions. Defect and Fault Tolerance in VLSI Systems, 2003. Proceedings. 18th IEEE
International Symposium on, strony 581–588, listopad 2003.
[39] P. Guerreiro. Simple support for design by contract in C++. Technology of Object-Oriented
Languages and Systems, 2001. TOOLS 39. 39th International Conference and Exhibition on,
strony 24–34, 2001.
[40] P. J. Guo. A scalable mixed-level approach to dynamic analysis of C and C++ programs. Praca
magisterska, MIT Department of Electrical Engineering and Computer Science, Cambridge, MA,
maj 2006.
[41] P. J. Guo, J. H. Perkins, S. McCamant, M. D. Ernst. Dynamic inference of abstract types. ISSTA
2006, Proceedings of the 2006 International Symposium on Software Testing and Analysis, strony
255–265, Portland, ME, USA, lipiec 2006.
[42] N. Gupta, Z. V. Heidepriem. A new structural coverage criterion for dynamic detection of program
invariants. ASE 2003: Proceedings of the 18th Annual International Conference on Automated
Software Engineering, strony 49–58, Montreal, Canada, październik 2003.
[43] Dick Hamlet. When only random testing will do. RT ’06: Proceedings of the 1st international
workshop on Random testing, strony 1–9, New York, NY, USA, 2006. ACM.
[44] S. Hangal, M. S. Lam.
Tracking down software bugs using automatic anomaly detection.
ICSE 2002: Proceedings of the 24th International Conference on Software Engineering, strony
291–301, 2002.
[45] C. A. R. Hoare. An Axiomatic Basis for Computer Programming. Communications of the ACM,
155
12(10):576–583, październik 1969.
[46] M. Humphrey, S.-M. Park, J. Feng, N. Beekwilder, G. Wasson, J. Hogg, B. LaMacchia,
B. Dillaway. Fine-grained access control for gridftp using secpal. GRID ’07: Proceedings of
the 8th IEEE/ACM International Conference on Grid Computing, strony 217–225, Washington,
DC, USA, 2007. IEEE Computer Society.
[47] ISO 19757-3:2006. Information technology – Document Schema Definition Language (DSDL) –
Part 3: Rule-based validation – Schematron. ISO, Geneva, Switzerland.
[48] G. Kanawati, N. Kanawati, J. Abraham. FERRARI: A Flexible Software-Based Fault and Error
Injection System. Computers, IEEE Transactions on, 44(2):248–260, luty 1995.
[49] M. Karaorman, U. Hölzle, J. Bruno. jContractor: A reflective Java library to support design
by contract. In Proceedings of Meta-Level Architectures and Reflection, volume 1616 of LNCS,
strony 175–196, 1999.
[50] Y. Kataoka, M. D. Ernst, W. G. Griswold, D. Notkin. Automated support for program refactoring
using invariants.
ICSM 2001: Proceedings of the International Conference on Software
Maintenance, strony 736–743, Florence, Italy, listopad 2001.
[51] S. Kim, T. Zimmermann, N. Nagappan. Crash Graphs: An Aggregated View of Multiple Crashes
to Improve Crash Triage (Practical Experience Report). Proceedings of the 2011 IEEE/IFIP
International Conference on Dependable Systems and Networks, czerwiec 2011.
[52] J. Kiniry, A. E. Morkan, B. Denby.
Soundness and Completeness Warnings in
ESC/Java2. SAVCBS 2006: Fifth International Workshop on Specification and Verification of
Component-Based Systems, strony 19–24, listopad 2006.
[53] A. A. Krystosik. Formalna weryfikacja oprogramowania reaktywnych systemów wbudowanych.
Praca doktorska, Politechnika Warszawska, Wydział Elektroniki i Technik Informacyjnych,
Instytut Informatyki, Warszawa, luty 2008.
[54] G. T. Leavens, A. L. Baker, C. Ruby. Preliminary Design of JML: A Behavioral Interface
Specification Language for Java. Raport instytutowy, Iowa State University, Department of
Computer Science, styczeń 2006.
[55] G. T. Leavens, Y. Cheon. Design by Contract with JML, sierpień 2006.
[56] M.-L. Li, P. Ramachandran, S. K. Sahoo, S. V. Adve, V. S. Adve, Y. Zhou. Understanding
the Propagation of Hard Errors to Software and Implications for Resilient System Design.
Proceedings of the 13th International Conference on Architectural Support for Programming
Languages and Operating Systems, ASPLOS XIII, strony 265–276, New York, NY, USA, 2008.
ACM.
[57] C. A. Lisboa, C. Grando, A. Moreira, L. Carro. Using software invariants for dynamic detection
of transient errors. 10th Latin American Test Workshop, strony 1–5, Punta del Este, Uruguay,
marzec 2009.
[58] C.-K. Luk, R. Cohn, R. Muth, H. Patil, A. Klauser, G. Lowney, S. Wallace, V. J. Reddi,
K. Hazelwood. Pin: building customized program analysis tools with dynamic instrumentation.
PLDI ’05: Proceedings of the 2005 ACM SIGPLAN conference on Programming language design
and implementation, strony 190–200, New York, NY, USA, 2005. ACM.
156
[59] L. Mariani, M. Pezzè. Behavior capture and test: Automated analysis of component integration.
International Conference on Engineering of Complex Computer Systems, strony 292–301,
Shanghai, China, czerwiec 2005.
[60] S. McCamant, M. D. Ernst. Predicting problems caused by component upgrades. ESEC/FSE
2003: Proceedings of the 10th European Software Engineering Conference and the 11th ACM
SIGSOFT Symposium on the Foundations of Software Engineering, strony 287–296, Helsinki,
Finland, wrzesień 2003.
[61] B. Meyer. Applying design by contract. Computer, 25(10):40–51, październik 1992.
[62] S. H. K. Narayanan, S. W. Son, M. Kandemir, F. Li. Using loop invariants to fight soft errors in
data caches. Asia and South Pacific Design Automation Conference, strony 1317–1320, Shanghai,
China, styczeń 2005.
[63] G. Nascimento, M. Correia. Anomaly-based Intrusion Detection in Software as a Service.
Dependable Systems and Networks Workshops, 0:19–24, 2011.
[64] P. Nazimek. Java Cards i OpenCard Framework. Software Developers Journal, (1), styczeń 2006.
[65] P. Nazimek. Java Modeling Language. Software Developers Journal, (8), sierpień 2006.
[66] P. Nazimek. Daikon – odkrywanie właściwości programów. Software Developers Journal, (9),
wrzesień 2007.
[67] P. Nazimek. ESC/Java2. Software Developers Journal, (4), kwiecień 2007.
[68] P. Nazimek. Wykrywanie, ocena skuteczności i optymalizacja asercji w programach. Zeszyty
Naukowe Wydziału ETI Politechniki Gdańskiej, 16:281–286, 2008.
[69] P. Nazimek. Wykrywanie i zastosowanie asercji ze śladem. Zeszyty Naukowe Wydziału ETI
Politechniki Gdańskiej, 19:379–385, 2010.
[70] P. Nazimek, J. Sosnowski, P. Gawkowski.
Checking fault susceptibility of cryptographic
algorithms. Pomiary, Automatyka, Kontrola, 55(10):827–830, 2009.
[71] P. Nazimek, G. Wojtenko. Karty Java – technologia, bezpieczeństwo, implementacje. VIII
Krajowa Konferencja Zastosowań Kryptografii Enigma, strony 25–54, Warszawa, Polska, maj
2004. Enigma Systemy Ochrony Informacji.
[72] N. Nethercote, J. Seward. Valgrind: a framework for heavyweight dynamic binary instrumentation. SIGPLAN Not., 42(6):89–100, 2007.
[73] J. W. Nimmer, M. D. Ernst. Static verification of dynamically detected program invariants:
Integrating Daikon and ESC/Java. RV 2001: First Workshop on Runtime Verification, Paris,
France, lipiec 2001.
[74] J. W. Nimmer, M. D. Ernst. Automatic generation of program specifications. ISSTA 2002:
Proceedings of the 2002 International Symposium on Software Testing and Analysis, strony
232–242, Rome, Italy, lipiec 2002.
[75] N. Oh, P. P. Shirvani, E. J. McCluskey. Control-flow checking by software signatures. Reliability,
IEEE Transactions on, 51(1):111–122, marzec 2002.
[76] C. Pacheco, M. D. Ernst. Eclat: Automatic generation and classification of test inputs. ECOOP
2005: Object-Oriented Programming, 19th European Conference, strony 504–527, Glasgow,
Scotland, lipiec 2005.
157
[77] K. Pattabiraman, Z. Kalbarczyk, R. K. Iyer. Application-Based Metrics for Strategic Placement
of Detectors. Proceedings of the 11th Pacific Rim International Symposium on Dependable
Computing, strony 75–82, Washington, DC, USA, 2005. IEEE Computer Society.
[78] K. Pattabiraman, G. P. Saggese, D. Chen, Z. Kalbarczyk, R. K. Iyer. Dynamic Derivation of
Application-Specific Error Detectors and their Implementation in Hardware. Proceedings of
the Sixth European Dependable Computing Conference, strony 97–108, Washington, DC, USA,
2006. IEEE Computer Society.
[79] J. H. Perkins, M. D. Ernst. Efficient incremental algorithms for dynamic detection of likely
invariants. FSE 2004: Proceedings of the ACM SIGSOFT 12th Symposium on the Foundations of
Software Engineering, strony 23–32, Newport Beach, CA, USA, listopad 2004.
[80] M. Pistoia, S. Chandra, S. J. Fink, E. Yahav. A survey of static analysis methods for identifying
security vulnerabilities in software systems. IBM System Journal, 46(2):265–288, 2007.
[81] N. Polikarpova. CITADEL User Manual, listopad 2006.
[82] N. Polikarpova, I. Ciupa, B. Meyer. A comparative study of programmer-written and automatically inferred contracts. ISSTA ’09: Proceedings of the eighteenth international symposium on
Software testing and analysis, strony 93–104, New York, NY, USA, 2009. ACM.
[83] L. L. Pullum. Software fault tolerance techniques and implementation. Artech House, Inc.,
Norwood, MA, USA, 2001.
[84] B. Pytlik. Automatic debugging using potential invariants. Honors thesis, Brown University,
Providence, Rhode Island, maj 2003.
[85] B. Pytlik, M. Renieris, S. Krishnamurthi, S. P. Reiss. Automated fault localization using potential
invariants.
AADEBUG 2003: Fifth International Workshop on Automated and Algorithmic
Debugging, strony 273–276, Ghent, Belgium, wrzesień 2003.
[86] C. Rabejac, J.-P. Blanquart, J.-P. Queille. Executable assertions and timed traces for on-line
software error detection. Fault Tolerant Computing, 1996., Proceedings of Annual Symposium
on, strony 138–147, lipiec 1996.
[87] S. K. Rad. Can structural test adequacy criteria be used to predict the quality of generated
invariants? Praca magisterska, University of Antwerp Department of Mathematics and Computer
Science, Antwerp, 2005.
[88] M. K. Ramanathan, A. Grama S. Jagannathan. Static specification inference using predicate
mining.
PLDI ’07: Proceedings of the 2007 ACM SIGPLAN conference on Programming
language design and implementation, strony 123–134, New York, NY, USA, 2007.
[89] B. Randell. Computing Systems Reliability. Cambridge University Press, 1979.
[90] I. Ronen, N. Dor, S. Porat, Y. Dubinsky. Combined static and dynamic analysis for inferring
program dependencies using a pattern language.
CASCON ’06: Proceedings of the 2006
conference of the Center for Advanced Studies on Collaborative research, strona 3, New York,
NY, USA, 2006.
[91] D. S. Rosenblum. A practical approach to programming with assertions. Software Engineering,
IEEE Transactions on, 21(1):19–31, styczeń 1995.
[92] K. Sacha. Inżynieria oprogramowania. Wydawnictwo Naukowe PWN, 2010.
158
[93] S. K. Sahoo, M.-L. Li, P. Ramachandran, S. V. Adve, V. S. Adve, Y. Zhou. Using Likely
Program Invariants to Detect Hardware Errors. Proceedings of the International Conference on
Dependable Systems and Networks, strony 70–79, Anchorage, Alaska, czerwiec 2008.
[94] S. Shoham, E. Yahav, S. Fink, M. Pistoia. Static specification mining using automata-based
abstractions. ISSTA ’07: Proceedings of the 2007 international symposium on Software testing
and analysis, strony 174–184, New York, NY, USA, 2007.
[95] Agitar Software. Getting Started With AgitarOne, listopad 2006.
[96] J. Sosnowski. Testowanie i niezawodność systemów komputerowych. Akademicka Oficyna
Wydawnicza EXIT, 2005.
[97] J. Sosnowski, P. Gawkowski.
Tracing fault effects in system environment.
EUROMICRO
Conference, 1999. Proceedings. 25th, 1:481–486, 1999.
[98] V. Srivatsa. Effective Functional Verification: Principles and Processes. Springer Publishing
Company, Incorporated, 2006.
[99] A. Stachurski, A. P. Wierzbicki. Podstawy optymalizacji. Oficyna Wydawnicza Politechniki
Warszawskiej, 1999.
[100] J. Tantivongsathaporn, D. Stearns.
An Experience With Design by Contract.
Software
Engineering Conference, 2006. APSEC 2006. 13th Asia Pacific, strony 335–341, grudzień 2006.
[101] O. Tarasyuk, A. Gorbenko, V. Kharchenko. Practical aspects of applying the invariant-based
approach to the formal system development and verification.
Dependability of networks,
wolumen 2 serii Monographs of System Dependability, strony 129–141. Oficyna Wydawnicza
Politechniki Wrocławskiej, 2010.
[102] W. F. Tichy. Should Computer Scientists Experiment More? Computer, 31(5):32–40, 1998.
[103] N. Tran, C. Mingins, D. Abramson. Design and implementation of assertions for the common
language infrastructure. IEE Proceedings - Software, 150(5):329–336, 2003.
[104] R. Vemu, J. A. Abraham. CEDA: control-flow error detection through assertions. On-Line Testing
Symposium, 2006. IOLTS 2006. 12th IEEE International, czerwiec 2006.
[105] R. Vemu, J. A. Abraham. Budget-Dependent Control-Flow Error Detection. On-Line Testing
Symposium, 2008. IOLTS 2008. 14th IEEE International, strony 73–78, lipiec 2008.
[106] R. Venkatasubramanian, J. P. Hayes, B. T. Murray. Low-cost on-line fault detection using control
flow assertions. On-Line Testing Symposium, 2003. IOLTS 2003. 9th IEEE, strony 137–143,
lipiec 2003.
[107] J. Voas. Software testability measurement for intelligent assertion placement. Software Quality
Control, 6(4):327–336, 1997.
[108] J. Whaley, M. C. Martin, M. S. Lam.
Automatic extraction of object-oriented component
interfaces. SIGSOFT Softw. Eng. Notes, 27(4):218–228, 2002.
[109] T. Xie, D. Notkin. Checking inside the black box: Regression testing based on value spectra
differences. ICSM 2004: Proceedings of the International Conference on Software Maintenance,
strony 28–37, Chicago, Illinois, wrzesień 2004.
[110] T. Xie, D. Notkin.
Tool-assisted unit test generation and selection based on operational
abstractions. Automated Software Engineering Journal, 2006.
159
[111] J. Yang. Automatically Inferring Temporal Properties. ICSE 2005: Proceedings of the 27th
International Conference on Software Engineering, Saint Louis, Missouri, USA, 2005. IEEE
Computer Society.
[112] J. Yang, D. Evans. Automatically Inferring Temporal Properties for Program Evolution. ISSRE
2004: Proceedings of the 15th International Symposium on Software Reliability Engineering,
strony 340–351, Washington, DC, USA, 2004. IEEE Computer Society.
[113] J. Yang, D. Evans. Dynamically inferring temporal properties. PASTE 2004: Proceedings of the
ACM-SIGPLAN-SIGSOFT workshop on Program analysis for software tools and engineering,
strony 23–28, New York, NY, USA, 2004. ACM Press.
[114] J. Yang, D. Evans. Automatically Discovering Temporal Properties for Program Verification.
Raport instytutowy, Department of Computer Science, University of Virginia, 2005.
[115] J. Yang, D. Evans, D. Bhardwaj, T. Bhat, M. Das. Perracotta: mining temporal API rules from
imperfect traces. ICSE 2006: Proceeding of the 28th international conference on Software
engineering, strony 282–291, New York, NY, USA, 2006. ACM Press.
[116] H. Yuan, T. Xie. Substra: A framework for automatic generation of integration tests. AST 2006:
1st Workshop on Automation of Software Test, strony 64–70, Shanghai, China, maj 2006.
[117] M. V. Zelkowitz, D. R. Wallace. Experimental Models for Validating Technology. Computer,
31(5):23–31, 1998.
A. Zaimplementowane oprogramowanie
Podczas prac badawczych, w ramach niniejszej rozprawy, opracowane zostało oryginalne
oprogramowanie, przeznaczone do analizy parametrów asercji w programie na podstawie
wybranych miar służacych
˛
do selekcji ich zestawu spełniajacego
˛
określone kryteria (rozdział
trzeci) oraz umożliwiajace
˛ wykrywanie, weryfikacj˛e, przekształcanie oraz zakłócanie asercji ze
śladem (rozdział czwarty).
Programy, biblioteki oraz skrypty pomocnicze opisane w poniższym dodatku zostały
wydzielone w dwa pakiety:
— AEM – oprogramowanie przeznaczone do analizy wybranych parametrów asercji i selekcji
ich zestawu dla programów w j˛ezykach C/C++ współpracujace
˛ z systemem wstrzykiwania
bł˛edów FITS [37],
— FlowGraph – narz˛edzia dedykowane zagadnieniom wykrywania oraz wykorzystania asercji ze śladem.
A.1. Pakiet AEM
Pakiet AEM przeznaczony jest do przeprowadzania pełnego procesu analizy wybranych
parametrów asercji. Może on być bezpośrednio zastosowany dla programów stworzonych
w j˛ezykach C/C++ wykonywanych pod kontrola˛ systemów z rodziny Windows. Współpracuje
z aplikacjami, w których obserwowane asercje działaja˛ w ramach jednego watku.
˛
W pakiecie AEM zdefiniowano dwa poj˛ecia: asercji oraz warunku. Asercje sa˛ tożsame ze
struktura˛ programowa˛ realizowana˛ przez makro assert(predykat) w j˛ezyku C/C++. Oznacza
to, że działanie programu zostanie przerwane jeśli zaistnieje sytuacja, w której sprawdzany
predykat b˛edzie niespełniony (naruszenie asercji). Warunki stanowia˛ analogi˛e do struktury
programowej if (!predykat) {...}. Ich naruszenie powoduje wykonanie bloku pod instrukcja˛
warunku, której celem może być podj˛ecie działań naprawczych, maskujacych
˛
lub raportujacych
˛
wykryty przez warunek bład.
˛
Poszczególne składniki pakietu AEM wyszczególniono w tabeli A.1. Ogólna koncepcja
oraz zależności pomi˛edzy elementami pakietu zostały przedstawione na rysunku A.1. Komponenty stworzone w ramach niniejszej pracy zostały wyróżnione drukiem tłustym. Pozostałe
elementy wchodza˛ w skład zewn˛etrznego oprogramowania, które wykorzystano przy tworzeniu
pakietu.
161
aemshm
Program przeznaczony do zarzadzania
˛
wydzielonym obszarem
pami˛eci współdzielonej, w której przechowywane sa˛ dane
badanych asercji i warunków.
aemtool
Program przeznaczony do analizy danych przechowywanych
w wydzielonym obszarze pami˛eci współdzielonej.
biblioteka aem
Biblioteka przeznaczona do integracji oprogramowania
napisanego w j˛ezykach C/C++ z narz˛edziami aemshm
i aemtool w celu umożliwienia pomiarów parametrów asercji
oraz warunków.
aem2stats
Skrypt analizujacy
˛ dane pochodzace
˛ z systemu FITS, które
opisuja˛ przebieg przeprowadzonych eksperymentów.
aem2report
Skrypt generujacy
˛
raport na podstawie przeanalizowanych
wyników eksperymentów przeprowadzonych z użyciem systemu
FITS.
system FITS
Oprogramowanie przeznaczone do zakłócania działania
(wstrzykiwania bł˛edów) aplikacji działajacych
˛
pod kontrola˛
systemu Windows [37].
biblioteka glpka
Biblioteka przeznaczona do rozwiazywania
˛
zadań programowania liniowego.
gnuplotb
Narz˛edzie do tworzenia wykresów.
a
b
http://www.gnu.org/software/glpk/
http://www.gnuplot.info/
Tabela A.1. Komponenty pakietu AEM
162
obszar pamieci
˛
współdzielonej
biblioteka aem
badany program
obszar
pamieci
˛
aemshm
aemtool
TXT
BIN
system FITS
dane
opisujace
˛
przebieg
testów
plik
zawierajacy
˛
obraz obszaru
pamieci
˛
współdzielonej
wykaz wybranych asercji i warunków
biblioteka glpk
TXT
BIN
dane opisujace
˛ przebieg testów
aem2stats
pliki gnuplot
oraz pliki
zawierajace
˛
dane
statystyczne
TXT
aem2report
TXT
PNG
pełny raport
gnuplot
Rysunek A.1. Struktura pakietu AEM
Pakiet AEM przechowuje informacje o badanych asercjach oraz warunkach w wydzielonym
obszarze pami˛eci współdzielonej. W poczatkowej
˛
wersji pakietu rozważane było zastosowanie
pliku dyskowego na potrzeby składowania danych, jednak z uwagi na możliwość niekontrolowanego przerwania badanego programu w trakcie operacji wstrzykiwania bł˛edów plik musiałby być otwierany oraz zamykany przy weryfikacji każdej z asercji lub każdego z warunków.
Takie rozwiazanie
˛
znacznie wydłużałoby czas działania programu.
Z tego powodu, do
przechowywania tych informacji, użyto pami˛eci operacyjnej, która˛ kontroluje aemshm. Ma
ona określona˛ wielkość i struktur˛e ustalana˛ na etapie kompilacji pakietu poprzez zdefiniowanie
maksymalnej liczby obiektów i zwiazanych
˛
z nimi danymi, jakie moga˛ być przechowywane.
W celu przyspieszenia operacji wyszukiwania informacji o danym obiekcie w obszarze pami˛eci
współdzielonej zastosowano heurystyk˛e zakładajac
˛ a˛ jej położenie za ostatnio sprawdzanym
elementem, co zazwyczaj odpowiada kolejności wyst˛epowania asercji i warunków w badanym
programie. Możliwa jest zmiana algorytmu wyszukiwania w przypadku, gdyby zaproponowana
heurystyka była mało wydajna dla badanej aplikacji.
W zależności od etapu przeprowadzanego badania w obszarze pami˛eci współdzielonej
odkładane sa˛ różne rodzaje danych:
— na etapie obserwacji (pomiaru parametrów asercji oraz warunków) obliczany jest koszt
dynamiczny asercji i warunków oraz badane jest ich zachowanie w środowisku bez
zakłóceń; etap ten odpowiada przeprowadzaniu procesu tak zwanego złotego przebiegu
163
(ang. golden run) to jest uruchomienia programu bez wprowadzania zakłóceń w systemie
wstrzykiwania bł˛edów FITS,
— na etapie weryfikacji bez skutków działania zachowywane sa˛ informacje o efekcie
sprawdzenia asercji oraz warunków w odniesieniu do innych tego typu obiektów, które
zdefiniowane sa˛ w badanym programie; dane te dla każdego uruchomienia programu
odkładane sa˛ do pliku i stanowia˛ dane wejściowe dla późniejszych obliczeń.
Narz˛edzie aemtool umożliwia dost˛ep do wydzielonego obszaru pami˛eci współdzielonej
w trakcie przeprowadzania eksperymentu w celu zapami˛etania wyników danego testu lub przygotowania struktur danych dla kolejnych obserwacji. Wykorzystywane jest ono mi˛edzy innymi
przez system FITS. Pozwala także na wygenerowanie oraz rozwiazanie
˛
zadania programowania
liniowego majacego
˛
na celu selekcj˛e odpowiednich asercji i warunków spełniajacych
˛
określone,
narzucone przez użytkownika, założenia.
Badany program jest integrowany ze środowiskiem omawianego pakietu poprzez bibliotek˛e aem. Wprowadza ona definicj˛e makr umożliwiajacych
˛
odkładanie odpowiednich
danych w wydzielonym obszarze pami˛eci współdzielonej przez obserwowane obiekty (na
etapie obserwacji lub weryfikacji bez skutków działania) lub przekazywanie informacji do
systemu FITS o naruszeniu asercji lub warunku przed realizacja˛ ich docelowego efektu (na
przykład przerwania badanego programu). Biblioteka została przygotowana dla programów
w j˛ezykach C/C++, ale możliwe jest stworzenie analogicznego rozwiazania
˛
dla innych j˛ezyków
programowania, bez konieczności ponownej implementacji pozostałych narz˛edzi.
Po przeprowadzeniu eksperymentów zebrane rezultaty moga˛ zostać przeanalizowane przez
skrypty aem2stats oraz aem2report. Ich wynikiem sa˛ analizy statystyczne w formie tekstowej
i graficznej (histogramy wygenerowane z użyciem pakietu gnuplot), które umożliwiaja˛ porównanie wyników otrzymanych na różnych etapach selekcji asercji i warunków.
W dalszej cz˛eści szczegółowo omówiono elementy pakietu AEM nie b˛edace
˛ oprogramowaniem zewn˛etrznym.
A.1.1. Program aemshm
Program aemshm przeznaczony jest do utrzymania obszaru pami˛eci współdzielonej wykorzystywanej jako repozytorium danych przez asercje i warunki badanego programu (poprzez
bibliotek˛e aem) oraz narz˛edzie aemtool. Umożliwia on także przeglad
˛ zawartości pami˛eci
w formie czytelnej dla użytkownika oraz zachowanie obrazu obszaru pami˛eci współdzielonej
w pliku. Pozwala to na późniejsze wykorzystanie zgromadzonych informacji. Aplikacja
została zaimplementowana w j˛ezyku C i wykorzystuje elementy Windows API do zarzadzania
˛
obszarem pami˛eci współdzielonej.
Sposób uruchomienia programu jest nast˛epujacy:
˛
aemshm nazwa pliku
164
gdzie nazwa pliku wskazuje na plik obrazu pami˛eci współdzielonej. Jeżeli plik o wskazanej
nazwie nie istnieje tworzony jest nowy, pusty obszar pami˛eci współdzielonej. Przy zakończeniu
działania programu możliwe jest zapisanie aktualnej zawartości pami˛eci współdzielonej w pliku
o podanej wcześniej nazwie.
Po uruchomieniu na ekranie widoczne jest aktywne okno konsoli. W trakcie działania
programu, poprzez naciśni˛ecie odpowiednich klawiszy, można wywołać akcje, które zostały
szczegółowo opisane w tabeli A.2.
A.1.2. Program aemtool
Sposób uruchomienia programu jest nast˛epujacy:
˛
aemtool [-stats2text nazwa pliku] [-dumpstats nazwa pliku]
[-testnumber liczba | inc] [-exitcode liczba] [-testclear]
[-problem nazwa pliku nazwa problemu nazwa funkcji
specyfikacja funkcji wagi koszt rozmiar liczba]
gdzie kolejne parametry pozwalaja˛ na wykonanie akcji oraz określenie ich parametrów,
które zostały szczegółowo opisane w tabeli A.3.
System FITS korzysta z aplikacji aemtool po każdym wykonanym teście, aby zapami˛etać
jego rezultaty, poprzez przekazanie do aplikacji zarejestrowanego wyniku testu oraz przygotowanie obszaru pami˛eci współdzielonej do kolejnego testu.
Wywołanie opisywanego
narz˛edzia w celu realizacji opisanej akcji jest nast˛epujace:
˛
aemtool -testnumber inc -dumpstats tests.bin -exitcode 1 -testclear
Przykładowy sposób uruchomienia opisywanej aplikacji w celu wybrania do dziesi˛eciu asercji na podstawie danych z pliku tests.bin maksymalizujac
˛ ich wartość skuteczności wzgl˛ednej
i uwzgl˛edniajac
˛ charakterystyk˛e asercja jako pierwsza została naruszona z wagami: 1 dla
testów które zakończyły si˛e zgłoszeniem bł˛edu, wyjatkiem
˛
systemowym lub przekroczeniem
czasu oczekiwania, -1 jeśli test zakończył si˛e poprawnie i z pomini˛eciem testów, gdzie nie
wprowadzono zakłóceń, jest nast˛epujacy:
˛
aemtool -problem tests.bin SAP FSAP I0000000010000000 0 1 -1 1 1 0 0 0 0 0 10
W wyniku uruchomienia powstana˛ dwa pliki tekstowe zawierajace
˛ odpowiednio sformułowanie zadania programowania liniowego dla zadanego problemu oraz jego rozwiazanie.
˛
A.1.3. Biblioteka aem
Biblioteka aem przeznaczona jest do szybkiego dostosowania aplikacji zaimplementowanych w j˛ezykach C/C++ do środowiska pakietu AEM. Definiuje ona szereg makr pozwalajacych
˛
zastosować asercje oraz warunki określajac
˛ ich koszt statyczny. Przed załaczeniem
˛
pliku nagłówkowego aem.h możliwe jest określenie sposobu zachowania biblioteki dla asercji
i warunków w badanym programie poprzez makra sterujace
˛ określone w tabeli A.4.
165
o
Tryb obserwacji wszystkich asercji oraz warunków. Uaktualniane sa˛
parametry asercji oraz warunków (na przykład koszt dynamiczny) oraz
informacja o ewentualnym zadziałaniu danej struktury.
s
Tryb weryfikacji bez skutków działania wszystkich asercji oraz
warunków. Uaktualniane sa˛ dane o ewentualnym zadziałaniu danej
struktury w odniesieniu do innych struktur na przykład: pierwsza
naruszona asercja, asercja naruszona, gdy została naruszona już inna
asercja itp.
h
Tryb weryfikacji wszystkich asercji oraz warunków. W przypadku
naruszenia asercji program jest przerywany.
SHIFT+s
Tryb weryfikacji bez skutków działania asercji oraz warunków,
których naruszenia nie zarejestrowano w trybie obserwacji. Skutki
działania sa˛ analogiczne do komendy wywoływanej klawiszem s
i tożsame z nia˛ jeśli żadna z asercji lub żaden z warunków podczas
obserwacji nie był naruszony. Tryb ten pozwala automatycznie wyeliminować asercje i warunki, które naruszane sa˛ w trakcie poprawnego
działania badanej aplikacji. Jest to przydatne dla asercji i warunków
wykrytych automatycznie.
SHIFT+h Tryb weryfikacji asercji oraz warunków, których naruszenia nie zarejestrowano w trybie obserwacji. Skutki działania sa˛ analogiczne
do komendy wywoływanej klawiszem h i tożsame z nia˛ jeśli żadna
z asercji lub żaden z warunków podczas obserwacji nie był naruszony.
Tryb ten pozwala automatycznie wyeliminować asercje i warunki,
które naruszane sa˛ w trakcie poprawnego działania badanej aplikacji.
Jest to przydatne dla asercji i warunków wykrytych automatycznie.
d
Dezaktywacja wszystkich asercji i warunków. Program wykonywany
jest z pomini˛eciem sprawdzania predykatów wszystkich asercji oraz
warunków.
p
Wydruk na ekranie informacji o zarejestrowanych asercjach i warunkach wraz z ich parametrami w formie czytelnej dla użytkownika.
ESC
Zakończenie działania programu po dodatkowym potwierdzeniu ch˛eci
wykonania tej operacji przez użytkownika. Wykonane zostanie zapisanie zawartości obszaru pami˛eci współdzielonej do pliku obrazu
oraz jej zwolnienie.
Tabela A.2. Klawisze komend w programie aemshm
166
stats2text
Konwersja pliku binarnego nazwa pliku zawierajacego
˛
wyniki
przeprowadzonych testów do czytelnego dla użytkownika formatu
tekstowego na standardowym wyjściu.
testnumber Ustawienie licznika określajacego
˛
numer testu w eksperymencie
na wartość liczba lub jednostkowe zwi˛ekszenie aktualnej wartości
(przełacznik
˛
inc).
exitcode
Ustawienie wyniku przeprowadzonego testu, dla którego zebrano
statystyki na wartość liczba. Komenda wykorzystywana po zakończeniu testu.
dumpstats
Zachowanie aktualnych statystyk przeprowadzonego testu w pliku
binarnym nazwa pliku. Jeżeli plik istnieje statystyki dopisywane sa˛
na jego końcu.
testclear
Usuni˛ecie statystyk ostatniego testu z obszaru pami˛eci
współdzielonej. Komenda wykorzystywana przed wykonaniem
testu.
problem
Sformułowanie i rozwiazanie
˛
zadania programowania liniowego
służacego
˛
znalezieniu najlepszych asercji i warunków według
zadanych kryteriów.
Dane wejściowe zawierajace
˛
wyniki
przeprowadzonych testów pobierane sa˛ z pliku nazwa pliku. Na
ich podstawie, poprzez bibliotek˛e glpk, formułowany jest problem
nazwa problemu z funkcja˛ celu nazwa funkcji. Parametr specyfikacja
funkcji umożliwia określenie funkcji celu w formacie ciagu
˛ znaków
rozpoczynajacego
˛
si˛e od litery S dla skuteczności bezwzgl˛ednej
lub litery I dla skuteczności wzgl˛ednej oraz 16 cyfr 0 lub 1,
które oznaczaja˛ odpowiednio nieuwzgl˛ednienie lub uwzgl˛ednienie
wybranej charakterystyki danego obiektu. Kolejność identyfikatorów charakterystyk jest zgodna z kolejnościa˛ podana˛ w tabeli 3.2.
Na parametr wagi składa si˛e pi˛eć liczb określajacych
˛
wagi dla
wyników testu w kolejności: bład
˛ niewprowadzony, zakończenie
z bł˛edem, zakończenie poprawne, wyjatek
˛
systemowy, przekroczony czas oczekiwania (zgodnie z wynikiem testu w systemie
FITS). Parametry koszt, rozmiar, liczba wyznaczaja˛ dolne i górne
ograniczenie wartości kolejno: całkowitego kosztu dynamicznego,
kosztu statycznego oraz liczby wybranych obiektów dla rozwiazy˛
wanego problemu. Wprowadzenie wartości 0 dla ograniczeń
skutkuje dezaktywacja˛ danego ograniczenia.
Tabela A.3. Polecenia programu aemtool
167
AEM_ENABLE
Biblioteka b˛edzie działać w sposób umożliwiajacy
˛
przeprowadzenie eksperymentów z FITS w środowisku
nieobejmujacym
˛
asercji i warunków obszarem wstrzykiwania
bł˛edów. Tryb ten używany jest w fazie obserwacji i weryfikacji
bez skutków działania. Wywołanie sprawdzenia asercji lub
warunku powoduje zapisanie odpowiednich informacji do
obszaru pami˛eci współdzielonej. Makro to jest domyślnie
zdefiniowane.
AEM_FITS
Biblioteka b˛edzie działać w sposób umożliwiajacy
˛
przeprowadzenie eksperymentów z FITS w środowisku
zakłócania obejmujacym
˛
obszar asercji i warunków. Tryb ten
używany jest podczas eksperymentów weryfikujacych,
˛
kiedy
wybrano już określone asercje i warunki.
AEM_DISABLE Biblioteka b˛edzie wyłaczona.
˛
Oznacza to, że wszystkie asercje
i warunki w programie nie b˛eda˛ używane.
Tabela A.4. Makra sterujace
˛ w bibliotece aem
W bibliotece zdefiniowano również struktur˛e i format danych przechowywanych w obszarze
pami˛eci współdzielonej.
A.1.4. Skrypt aem2stats
Skrypt aem2stats przeznaczony jest do analizy plików wynikowych tworzonych przez
system FITS w celu opracowania statystyk zwiazanych
˛
z naruszeniami asercji oraz warunków
wskutek wstrzykiwanych bł˛edów. Został on zaimplementowany z wykorzystaniem j˛ezyka
skryptowego Perl.
Sposób uruchomienia jest nast˛epujacy:
˛
perl aem2stats.pl < nazwa pliku
gdzie nazwa pliku wskazuje na plik tekstowy generowany przez FITS.
Wynikiem działania programu sa˛ pliki tekstowe zawierajace
˛ analizy statystyczne oraz
skrypty dla aplikacji gnuplot umożliwiajace
˛ ich graficzna˛ wizualizacj˛e dla każdego z eksperymentów przeprowadzonych w systemie FITS.
A.1.5. Skrypt aem2report
Skrypt aem2report automatycznie przetwarza wszystkie pliki wygenerowane przez
aem2stats tworzac
˛ czytelny raport w formie dokumentu HTML. Został on opracowany
w j˛ezyku Perl. Do wygenerowania wykresów wykorzystuje narz˛edzie gnuplot.
˛
perl aem2report.pl
168
Raport utworzony przez aem2report został wykorzystany w niniejszej pracy do opracowania wyników tabelarycznych i graficznych dla eksperymentów zwiazanych
˛
z selekcja˛ asercji
o określonym profilu.
A.2. Pakiet FlowGraph
Pakiet FlowGraph przeznaczony jest do wykrywania, weryfikacji, przekształcania oraz zakłócania asercji ze śladem. Pakiet został w całości opracowany w j˛ezyku Perl. Narz˛edzia
opracowane w pakiecie stanowia˛ baz˛e dla docelowych zastosowań. Możliwe jest ich uzupełnienie o algorytmy wykrywania określonego typu warunków w asercjach ze śladem czy też
dostosowanie do innego formatu analizowanych danych wejściowych. W poczatkowej
˛
formie
pakiet FlowGraph wykorzystany był do przeprowadzenia eksperymentów w ramach niniejszej
rozprawy. Po drobnych modyfikacjach zastosowany został również do obserwacji aplikacji
działajacej
˛ w środowisku produkcyjnym.
Elementy wchodzace
˛ w skład pakietu FlowGraph zostały wyszczególnione w tabeli A.5.
invariant
Skrypt ten jest odpowiedzialny za analiz˛e danych wejściowych (informacji zebranych podczas wykonania programu) w celu wygenerowania, aktualizacji lub weryfikacji asercji ze śladem.
analyze
Skrypt umożliwia statystyczna˛ analiz˛e danych w pliku przechowuja˛
cym asercje ze śladem.
injector
Zadaniem tego skryptu jest symulacja zakłóceń w wykonaniu programu oraz obserwacja zachowania asercji ze śladem.
transform Skrypt zawiera implementacj˛e algorytmów wykonujacych
˛
operacje na
zbiorach asercji ze śladem.
Tabela A.5. Komponenty pakietu FlowGraph
Struktura˛ danych wykorzystywana˛ przez narz˛edzia z pakietu FlowGraph, w której przechowywane sa˛ informacje o asercjach ze śladem, jest digraf zapisywany w formie skompresowanych plików XML. Dla każdej z wykrytych asercji przechowywane sa˛ informacje
dotyczace
˛ liczby uaktualnień na etapie wykrywania oraz liczby sprawdzeń na etapie weryfikacji
umożliwiajace
˛ późniejsze analizy statystyczne otrzymanych wyników.
A.2.1. Skrypt invariant
Skrypt invariant przeznaczony jest do analizy informacji o wykonaniu programu w celu
wykrywania, uaktualniania lub weryfikacji asercji ze śladem wraz z rejestracja˛ danych
statystycznych zwiazanych
˛
z liczba˛ aktualizacji oraz sprawdzeń asercji.
W szablonowej
wersji skryptu zaimplementowano wykrywanie dwóch asercji badajacych
˛
wartość maksymalna˛
169
i minimalna˛ zmiennych liczbowych, których wartość może być rejestrowana w punktach
obserwacji badanego programu.
˛
perl invariant.pl wejście wyjście aktualizacja długość śladu < dane
gdzie kolejne parametry określaja:
˛ plik wejście zawierajacy
˛ asercje ze śladem dla badanego
programu, wykryte we wcześniejszej fazie analizy (podanie nieistniejacego
˛
pliku powoduje
utworzenie pustych struktur danych), plik wyjście, do którego zapisane zostana˛ struktury
danych zawierajacego
˛
asercje ze śladem, tryb działania skryptu (aktualizacja wykrytych asercji
wybierana wartościa˛ 1, weryfikacja wykrytych asercji wybierana wartościa˛ 0) oraz maksymalna
długość obserwowanego śladu dla wykrywanych asercji. Dane do analizy pobierane sa˛ ze
standardowego wejścia programu.
Środowisko działania skryptu invariant zostało przedstawione na rysunku A.2.
Format danych wejściowych składa si˛e z serii pól oddzielonych znakiem |. Pierwsze pole
jest identyfikatorem punktu obserwacji, kolejne pola zawieraja˛ nazw˛e obserwowanej zmiennej
wraz z jej typem i zarejestrowana˛ wartościa.˛ Przykładowy fragment danych opisujacych
˛
przebieg wykonania programu, który może zostać przeanalizowany przez skrypt invariant jest
nast˛epujacy:
˛
org.apache.tools.bzip2.CBZip2OutputStream.runLength|i|int|1
org.apache.tools.bzip2.CBZip2OutputStream.last|i|int|5
badany program
informacje
o wykonaniu
programu
XML
TXT
invariant
XML
wejściowa
struktura
danych
wyjściowa
struktura
danych
Rysunek A.2. Pakiet FlowGraph – narz˛edzie invariant
Możliwe jest również uruchomienie skryptu w taki sposób, aby informacje o przebiegu
programu były analizowane na bieżaco,
˛ poprzez odpowiednie przekierowanie źródła informacji
o wykonaniu badanego programu na standardowe wejście invariant. Naruszenia wykrytych
asercji nie maja˛ wpływu na przebieg działania aplikacji, sa˛ one jedynie raportowane użytkownikowi poprzez wyświetlanie informacji w oknie wyników działania skryptu.
170
A.2.2. Skrypt analyze
Skrypt analyze przeznaczony jest do analizy struktury danych przechowujacej
˛
asercje
ze śladem.
Jego działanie zobrazowane zostało na rysunku A.3.
Dla zadanego pliku
przechowujacego
˛
struktur˛e danych, opisujac
˛ a˛ wykryte asercje ze śladem, skrypt generuje pliki
dla programu gnuplot oraz tabele ze statystykami opisujacymi:
˛
— liczba wykrytych asercji w rozdziale na długość śladu oraz stosunek liczby sprawdzeń
asercji zarówno bez jak i z jej aktualizacja˛ (w formie tekstowej oraz graficznej w postaci
histogramu),
— analizy statystyczne zwiazane
˛
z weryfikacja˛ asercji (sprawdzenia, naruszenia, brak
odpowiedniej asercji do sprawdzenia) w zależności od długości śladu asercji oraz wcześniej
określonego stosunku liczby sprawdzeń asercji zarówno bez jak i z jej aktualizacja˛ na etapie
wykrywania.
wejściowa
struktura
danych
XML
TXT
pliki dla programu
gnuplot
CSV
tabele z danymi
statystycznymi
analyze
Rysunek A.3. Pakiet FlowGraph – narz˛edzie analyze
Skrypt umożliwia generowanie całościowych statystyk na podstawie kilku plików wejściowych.
A.2.3. Skrypt injector
Skrypt injector umożliwia symulowanie zakłóceń w programach poprzez modyfikacj˛e
informacji o przebiegu jego wykonania polegajac
˛ a˛ na:
— zakłóceniu wartości zmiennej w programie polegajace
˛
na losowej inwersji bitów
z określonego zakresu (od najmłodszego do określonego bitu) w losowo wybranej zmiennej;
zmienny zakres umożliwia zróżnicowanie zakresu zmiany wybranej zmiennej (od najmniejszej do najwi˛ekszej),
— zakłóceniu przebiegu wykonania programu poprzez pomini˛ecie losowego punktu obserwacji co przekłada si˛e na zakłócenie w śladzie wykonania programu.
Z uwagi na tryb wprowadzania zakłóceń wszystkie wprowadzane bł˛edy maja˛ charakter
przemijajacy
˛ i ich wpływ obejmuje jedynie pojedynczy punkt w programie. Dodatkowo
zakłócenia przebiegu wykonania programu wstrzykiwane sa˛ z zachowaniem minimalnej
171
liczby odwiedzonych pomi˛edzy nimi punktów obserwacji równej maksymalnej długości przechowywanego śladu, aby wykluczyć możliwość kumulacji efektu wprowadzonych zakłóceń.
Mogłaby ona prowadzić do zafałszowania otrzymanych wyników ponieważ w takiej sytuacji
omawiane narz˛edzie nie jest w stanie wykryć czy zgłoszone naruszenie powstało na skutek
ostatnio wprowadzonego bł˛edu czy też innego, wprowadzonego wcześniej.
Zachowanie
odpowiedniego odst˛epu pomi˛edzy kolejnymi wprowadzonymi zakłóceniami w przebiegu programu zapobiega wystapieniu
˛
bł˛edów wielokrotnych.
informacje
o wykonaniu
programu
badany program
TXT
XML
wejściowa
struktura
danych
TXT
pliki dla programu
gnuplot
CSV
tabele z danymi
statystycznymi
injector
XML
wyjściowa
struktura
danych
Rysunek A.4. Pakiet FlowGraph – narz˛edzie injector
Działanie injector zobrazowano na rysunku A.4.
Sposób uruchomienia skryptu jest
nast˛epujacy:
˛
perl injector.pl wejście wyjście p rodzaj zakłócenia [liczba bitów] < dane
gdzie kolejne parametry określaja:
˛ plik wejście zawierajacy
˛ asercje ze śladem dla badanego
programu, wykryte w fazie analizy, plik wyjście, do którego zapisane zostana˛ struktury
danych zawierajacego
˛
zaktualizowane dane statystyczne, prawdopodobieństwo wprowadzenia
zakłócenia p wyrażone w procentach, rodzaj zakłócenia (var – zakłócenie wartości, trc
– zakłócenie przebiegu wykonania) oraz, opcjonalnie dla trybu var, maksymalny indeks
najstarszego bitu zakłócanej zmiennej, który może zostać zmieniony.
Dane do analizy
pobierane sa˛ ze standardowego wejścia programu.
Wynikiem działania narz˛edzia injector sa˛ pliki tekstowe oraz wykresy z informacjami
o liczbie wykrytych i niewykrytych zakłóceń w zależności od parametrów asercji ze śladem
takich jak długość ich śladu. Dodatkowo struktura danych wyjściowych może zostać przeanalizowana skryptem analyze, co pozwala na wydobycie dodatkowych informacji takich jak liczba
sprawdzeń każdej z asercji ze śladem.
Skrypt injector może zostać rozszerzony o możliwość wprowadzania innego rodzaju
zakłóceń do badanych programów oraz kolekcjonowania dodatkowych danych zwiazanych
˛
przeprowadzanymi symulacjami.
172
A.2.4. Skrypt transform
Narz˛edzie transform, którego działanie przedstawia rysunek A.5, przetwarza ślady asercji
wczytane z pliku zawierajacego
˛
wejściowa˛ struktur˛e danych przy użyciu zaproponowanych
w pracy nast˛epujacych
˛
algorytmów:
— redukcji liczby śladów w zbiorze asercji ze śladem (algorytm 4.1),
— skracania śladów w zbiorze asercji ze śladem (algorytm 4.2),
— redukcji liczby identyfikatorów punktów programu dla zbiorów asercji ze śladem (algorytm 4.3).
wejściowa
struktura
danych
XML
transform
TXT
zredukowana liczba
śladów
TXT
skrócone ślady
TXT
nowe identyfikatory
Rysunek A.5. Pakiet FlowGraph – narz˛edzie transform
Wyniki działania każdego z algorytmów zapisywane sa˛ w oddzielnym zbiorze wyjściowym.
Opisuja˛ one, w sposób czytelny dla użytkownika, zmiany jakie zaszły w analizowanym zbiorze
asercji ze śladem obejmujace:
˛
— wykaz asercji ze śladem po redukcji liczby śladów,
— wykaz asercji ze śladem po skróceniu długości śladów,
— przyporzadkowanie
˛
określajace
˛ nowe identyfikatory punktów obserwacji po redukcji ich
liczby.
173

Wykrywanie, ocena skutecznoĹłci i

Transkrypt

Podobne dokumenty

1 Systemy Odporne na Błędy

Badanie poprawności, cd

Zadanie 11.1. Wiemy, ˙ze stopy zwrotu 3 akcji s a opisywane przez

popularyzatorski opis rezultatów projektu

Graficzna prezentacja wyników

Instytut Historii Uniwersytetu im. Adama Mickiewicza w Poznaniu

Zadanie: LINES Brzydkie odcinki

fragment - Wydawnictwo UMK

Podstawy teorii decyzji

Ajdukiewicz alternatywny: pragmatysta i platonik