Debugowanie (zang. debugging) – proces systematycznego redukowania liczbybłędów woprogramowaniu bądźsystemie mikroprocesorowym, który zazwyczaj polega na kontrolowanym wykonaniuprogramu pod nadzoremdebuggera.
Osobny artykuł:Błąd (informatyka).Popularyzację słowabug (zang. robak, insekt), rozumianego jako błąd, przypisuje się zazwyczaj admirałGrace Hopper. Podczas prac nad komputerem Mark II naUniwersytecie Harvarda jej współpracownicy znaleźli ćmę, która zaplątała się wprzekaź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 1878Thomas Edison, który w jednym ze swoich listów określił słowembugs usterki techniczne.
Chociaż każdy błąd wymaga indywidualnego podejścia, debugowanie można zazwyczaj podzielić na kilka etapów:
Odkrycia błędu może dokonać zarównoprogramista podczas rutynowychtestó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ładnedane 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 oraztestowanie 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 pomocywyszukiwania 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 jestzaciemniony, sprawdzaasercje orazloguje najważniejsze zdarzenia i działania. Wykonanie programu można nadzorować przy pomocydebuggera, który umożliwiawstrzymywanie wykonaniaprocesu oraz obserwację i modyfikację jego stanu. Ponadto, środowisko uruchomienia można wzbogacić obiblioteki, które dokonują ściślejszejkontroli dostępu dopamięci oraz śledzą jejalokację, 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) firmySun Microsystems przyznała, że brak metodyclone() winterfejsieCloneable jest niedopatrzeniem, ale zdecydowała nie zmieniać wadliwego typu, aby uniknąć problemów zkompilacją 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 zBell 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 miejscachkodu ź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ę ewentualnetesty 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 zbezpieczeń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:
Osobny artykuł:Debugger.Mimo istnienia wyrafinowacych narzędzi, takich jak debugger, programiści, w zależności od typu oprogramowania, mogą także korzystać zinstrukcji print dodawanej w kodzie programu w celu:
Tego typu rozwiązania stosuje się głównie, gdy program nie posiada systemu logowania o swoim stanie (np. poprzezflagę lubzmienną ś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ą lokalizowaniewycieków pamięci.