|
DebugowanieDebugowanie (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. EtymologiaPopularyzację 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. Proces debugowaniaChociaż każdy błąd wymaga indywidualnego podejścia, debugowanie można zazwyczaj podzielić na kilka etapów:
Reprodukcja błęduOdkrycia 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. Wyizolowanie źródła błęduKolejnym 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]. Identyfikacja przyczyny awariiOdnalezienie 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. Usunięcie defektuUstalenie ź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 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. Weryfikacja powodzenia naprawyProces 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. NarzędziaCentralnym 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. DebuggerDebugger umożliwia:
Instrukcja printMimo 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: Tego typu rozwiązania stosuje się głównie, gdy program nie posiada systemu logowania o swoim stanie (np. poprzez flagę lub zmienną środowiskową). InneNarzę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. Przypisy
Bibliografia
Linki zewnętrzneKontrola autorytatywna (termin informatyczny): Information related to Debugowanie |
Portal di Ensiklopedia Dunia
