Metoda wyszukująca niedopracowane miejsca w kodzie przez analize statyczną.

Arkadiusz Piwowarski

Motto: Programista jeśli coś pisze, to robi to w jakimś celu. Bezużyteczny kod przeczy tej idei i najpewniej jest błędny.

Problem, dotychczas uważany za drobny błąd kosmetyczny, w rzeczywistości często towarzyszy błędom poważnym i mogą dać namiar na ich wystąpienia. Statystycznie 45%-100% trafień. Przykładowo:

• zawsze fałszywy warunek może sygnalizować błąd w jego zdefinionwaniu,
• zmienna sekcji krytycznej użyta bez ochrony dostępu, może wskazywać na pomyłkę. Analogicznie użycie blokad, które niczego nie chronią, odnosi się w drugą stronę.
• zmienna, na którą tylko jest przypisywana wartość, a nigdy nie jest odczytywana, może wskazywać na zgubione przekazanie wyniku;

Sprawdzenia, dające mierzalne efekty:

1. Kod nie dający efektu (np: x = x; x/x; x&x.).

   System	Poważne błędy	Drobne błędy	Nieuzasadnine podejrzenia
   Linux 2.4.5-ac8	7	6	3
   OpenBSD 3.2	2	6	8
   PostgreSQL	0	0	0

   
   
   • Przykład z życia (kawałek kodu linuksa):
     da.s_node=sa.s_node
da.s_net=da.s_net

   • inny przklad:
     p[i]=p[i]++;
     - złamanie wymogów ANSI C, efekt zależy od kompilatora!
   • jeszcze inny:
     v += 0;
2. Przypisania na zmienne, które nigdy nie są odczytane lub przypisanie ponowne na zmienna, zanim zostanie odczytana.

   System	Poważne błędy	Drobne błędy	Nieuzasadnine podejrzenia
   Linux 2.4.5-ac8	129	26	1840
   OpenBSD 3.2	63	36	117
   PostgreSQL	37	10	0

   
   
3. Nieosiągalny kod.

   System	Poważne błędy	Drobne błędy	Nieuzasadnine podejrzenia
   Linux 2.4.5-ac8	66		26
   OpenBSD 3.2	11		4
   PostgreSQL	0		0

   
   
4. Zawsze spełnione/niespełnione wyrażenia warunkowe.

   System	Poważne błędy	Drobne błędy	Nieuzasadnine podejrzenia
   Linux 2.4.5-ac8	49	52	169
   OpenBSD 3.2	64	33	316
   PostgreSQL	0	0	0

   
   

Przy tworzeniu automatu sprawdzającego trzeba wziąść pod uwagę aspekty, przyczyniające się do wielu nieprawidłowych podejrzeń:

• Ponowne przypisanie przed odczytem czasami daje fałszywe podejrzenia, np. dla PostgreSQL lub Oracle przy wywołaniu funkcji, gdzie przypisanie jest wymuszone.
• Przy defensywnym programowaniu często korzysta się z przypisaniamia pewnej bezpiecznej wartości za wczasu.
• Makra.

Testowanie modelu aplikacji

• Nastawione na błędy subtelne
• Ogólna zasada działania
• Wymóg budowy modelu otoczenia sprawdzanego programu. Problem czynnika ludzkiego.
• Da się zautomatyzować na podstawie kodu aplikacji (bez tworzenia abstrakcyjnego modelu programu), ale są problemy ze zautomatyzowaniem symulacji środowiska.
• Dynamiczne generowanie grafu stanów. Dodanie spamiętywania stanów już sprawdzonych znacznie przyśpiesza proces.

Błędy w kodzie a praca zespołowa.

• Problem przekazania informacji
• Problem propagacji błędu
• Problem pogranicza systemów

Systemy monitorujące