Debugowanie

Debugowanie (z ang. debugging) – proces systematycznego redukowania liczby błędów w oprogramowaniu bądź systemie mikroprocesorowym, który zazwyczaj polega na kontrolowanym wykonaniu programu pod nadzorem debuggera.

 Osobny artykuł: Błąd (informatyka).

Popularyzację słowa bug (z ang. robak, insekt), rozumianego jako błąd, przypisuje się zazwyczaj admirał Grace Hopper. Podczas prac nad komputerem Mark II na Uniwersytecie Harvarda jej współpracownicy znaleźli ćmę, która zaplątała się w przekaźnik, utrudniając działanie urządzenia. Admirał Hopper nazwała usunięcie martwego owada debugowaniem, czyli odrobaczeniem. Pojęciem tym posłużył się jednak już w roku 1878 Thomas Edison, który w jednym ze swoich listów określił słowem bugs usterki techniczne.

Chociaż każdy błąd wymaga indywidualnego podejścia, debugowanie można zazwyczaj podzielić na kilka etapów:

1. Reprodukcja błędu
2. Wyizolowanie źródła błędu
3. Identyfikacja przyczyny awarii
4. Usunięcie defektu
5. Weryfikacja powodzenia naprawy

Odkrycia błędu może dokonać zarówno programista podczas rutynowych testów tworzonej funkcjonalności jak również tester bądź użytkownik. Po zgłoszeniu, błąd powinien zostać odtworzony na maszynie programisty, aby można było potwierdzić istnienie usterki. Zdarza się bowiem, że użytkownicy zgłaszają błędy dotyczące zamierzonego działania programu^[1] bądź podają informacje niewystarczające do zaobserwowania defektu, jak np. niekompletny scenariusz interakcji, niedokładne dane wejściowe lub niepełne środowisko wykonania. Niemożność odtworzenia problemu znacznie utrudnia programiście dotarcie do jego przyczyny. Odnalezienie źródła błędu może w takiej sytuacji wymagać nadzorowania wykonania zdalnego procesu bądź analizy informacji pośrednich (np. zrzutu pamięci lub śladu wykonania). Brak możliwości reprodukcji problemu utrudnia również weryfikację powodzenia naprawy oraz testowanie nawrotów błędu w kolejnych wersjach programu.

Kolejnym etapem debugowania jest eliminacja wszystkich tych czynników, które nie przyczyniają się bezpośrednio do powstania błędu. Dotyczy to zarówno zbędnych kroków scenariusza interakcji, jak i ilości danych wejściowych, których nadmiar może utrudnić dotarcie do źródła problemu. Eliminacja niepotrzebnych czynników ułatwia śledzenie duplikatów i jest tak bardzo istotna dla postępu pracy w dojrzałych systemach, że niektóre zespoły nakłaniają testerów do upraszczania już znalezionych błędów zamiast zgłaszania nowych^[2].

W przypadku istnienia metody samoczynnego wykonania programu i określenia wyniku jego uruchomienia, krok ten można w dużej mierze zautomatyzować. Dokonuje się tego przy pomocy wyszukiwania binarnego, ograniczając ilość danych tak długo, aż odjęcie żadnego z najmniejszych elementów wejścia nie spowoduje błędu wykonania^[3].

Odnalezienie przyczyny awarii odbywa się zazwyczaj poprzez obserwację stanu programu podczas jego kontrolowanego uruchomienia. Do śledzenia wykorzystuje się zwykle specjalnie przygotowaną wersję programu. W przeciwieństwie do wersji udostępnianej klientom, debugowany program nie jest zaciemniony, sprawdza asercje oraz loguje najważniejsze zdarzenia i działania. Wykonanie programu można nadzorować przy pomocy debuggera, który umożliwia wstrzymywanie wykonania procesu oraz obserwację i modyfikację jego stanu. Ponadto, środowisko uruchomienia można wzbogacić o biblioteki, które dokonują ściślejszej kontroli dostępu do pamięci oraz śledzą jej alokację, aby wychwycić problemy, zanim pociągną za sobą kolejne.

Ustalenie źródła błędu nie musi kończyć się usunięciem jego objawów lub przyczyn. Na przykład, komisja kontroli technicznej (ang. Technical Review Committee) firmy Sun Microsystems przyznała, że brak metody clone() w interfejsie Cloneable jest niedopatrzeniem, ale zdecydowała nie zmieniać wadliwego typu, aby uniknąć problemów z kompilacją istniejących programów (pomimo ich niepoprawności)^[4].

W systemach, nad którymi pracują duże zespoły, niezwykle istotne jest, aby zdawać sobie sprawę ze wszystkich konsekwencji, jakie wprowadzona zmiana może mieć dla pozostałych części systemu. Badania nad rozwojem oprogramowania dla central telefonicznych 5ESS, prowadzone przez naukowców z Bell Labs, wykazały, że poprawianie usterek znacznie częściej niż inne rodzaje aktywności wprowadza nowe błędy^[5].

Ponieważ wadliwy fragment systemu może na skutek duplikacji występować w innych miejscach kodu źródłowego, należy również upewnić się, że korekta została zaaplikowana do wszystkich jego kopii.

Proces debugowania kończy się sprawdzeniem, czy oryginalny scenariusz interakcji nie powoduje błędnego zachowania systemu. Ponadto, wymagane może być dokładniejsze zbadanie systemu w celu upewnienia się, czy naprawa nie wprowadziła innych, niechcianych efektów ubocznych. Następnie wykonuje się ewentualne testy regresji celem wykluczenia możliwości przywrócenia starszych błędów.

Uruchomienie pełnego zestawu testów dużego systemu może zabrać wiele czasu. W przypadku błędów związanych z bezpieczeństwem niektóre firmy decydują się na udostępnienie nie w pełni przetestowanej nowej wersji swojego systemu, aby jak najszybciej zapobiec ewentualnym skutkom wykorzystania danej luki przez osoby niepowołane.

Centralnym punktem procesu debugowania programu jest obserwacja jego wykonania w celu lokalizacji źródła usterki. Zadanie to ułatwiają narzędzia do dynamicznej analizy programu.

Debugger umożliwia:

• wykonywanie programu w trybie pracy krokowej lub z zastawianiem tzw. pułapek (ang. breakpoints);
• podglądanie i ewentualną zmianę zawartości rejestrów, pamięci itd.

 Osobny artykuł: Debugger.

Mimo istnienia wyrafinowacych narzędzi, takich jak debugger, programiści, w zależności od typu oprogramowania, mogą także korzystać z instrukcji print dodawanej w kodzie programu w celu:

• sprawdzenia czy dana linia została wywołana,
• wyświetlenia zawartości zmiennej lub stałej.

Tego typu rozwiązania stosuje się głównie, gdy program nie posiada systemu logowania o swoim stanie (np. poprzez flagę lub zmienną środowiskową).

Narzędzia śledzące alokację pamięci (np. Valgrind) ułatwiają odnajdywanie fragmentów programu odwołujących się do zwolnionych i niezaalokowanych obszarów pamięci jak również umożliwiają lokalizowanie wycieków pamięci.

• Andreas Zeller: Why Programs Fail: A Guide to Systematic Debugging. Morgan Kaufmann, 2005. ISBN 1-55860-866-4. Brak numerów stron w książce

• Mozilla BugAThone