Bug

From Helionica

Bug - w żargonie informatycznym, wyrażenie oznaczajace pewien błąd, usterkę – niepożądane, powtarzające się przy zajściu określonych czynników działanie programu, wynikające z błędu człowieka na jednym z etapów tworzenia oprogramowania, zwykle na etapie projektowania lub tworzenia kodu źródłowego.

[edytuj]

Nazwa

Nazwa pochodzi od angielskiego słowa bug (owad, robactwo). Prawdopodobnie przeszła do żargonu programistycznego z żargonu inżynierów telekomunikacji, którzy o szumach w sygnale żartowali, że "owady się zalęgły w urządzeniu". Wiadomo też, że słowa bug w kontekście usterki używał Thomas Edison.

Inna historia dotycząca nazewnictwa: w pierwszych maszynach komputerowych o wielkości mierzonej w m³, których stosowano do przełączania stanów przekaźniki a potem wymagające wysokich napięć lampy elektronowe, owady powodowały spięcia, czego następstwem były błędy w wynikach działania maszyny.

Słowo bug jest często tłumaczone w tym kontekście jako pluskwa, oznaczającym obecnie – podobnie jak w angielskim źródłosłowie – również podsłuch lub podgląd elektroniczny (mikrofon, kamera).

Pluskwy, czyli błędy programistyczne są obiektem wielu spośród tzw. praw Murphy'ego, m.in. głęboko słusznego "w każdym programie (dłuższym niż 100 linijek) jest jeszcze jeden błąd".

[edytuj]

Diagnoza i usuwanie

Bug jako nazwa błędu programistycznego występuje w nazwach programów pomagających usuwać błedy, tzw. debugerów, czy też "odpluskwiaczy". Programy te pozwalają śledzić wartości określonych zmiennych i rejestrów wykorzystywanych w programie do momentu wystąpienia błędu celem znalezienia dokładnego miejsca w kodzie źródłowym, które należy zmienić, by bug się nie pojawiał.

Środowisko otwartego oprogramowania wykształciło złożone systemy zbierania informacji o istniejących usterkach i niedogodnościach w programach. Do najpopularniejszych należy Bugzilla (podobieństwo do nazwy Mozilla nieprzypadkowe), stosowany również przez fundację MediaWiki do zbierania informacji o błędach w oprogramowaniu Wikipedii i pokrewnych Wiki (patrz: tu). W systemie Bugzilla błąd może zgłosić każdy, przez określenie warunków, w jakich się pojawia. Zgłoszenie jest następnie przydzielane określonemu programiście, a system zawiera aktualne informacje o postępach w naprawianiu usterki.

[edytuj]

Prewencja

W typowych warunkach można się spodziewać, że w każdym nietrywialnym programie będzie sporo bugów.

Ich ilość jednak można znacząco ograniczyć. Uważa się, że ilość bugów na linijkę kodu jest w przybliżeniu niezależna od języka, czyli program o tej samej funkcjonalności napisany w języku wyższego poziomu (np. Perl czy Python) będzie miał mniej bugów niż w języku niższego poziomu (Java, C, czy asembler).

Ilość bugów można też ograniczyć przez pisanie testów. Testy te powinny być w miarę możliwości zautomatyzowane – komputer potrafi przeprowadzić o kilka rzędów wielkości więcej testów na godzinę niż człowiek. Ilość bugów można redukować przez ręczne audyty kodu, jawne opisanie założeń jakie przyjmuje kod (np. co do typów danych wejściowych, czy spodziewanego sposobu użycia), unikanie trudnych w analizie konstrukcji (jak słynne goto, czy ewaluacja kodu w trakcie wykonania), czy przez używanie narzędzi wykrywających podejrzane fragmenty kodu (lint, ostrzeżenia kompilatora).

Czasem bugi wykrywa się przez karmienie programu losowymi danymi i sprawdzanie otrzymywanych odpowiedzi. Ponieważ typowe bugi dotyczą wielu danych, wykrywa się w ten sposób większość bugów.

Bardzo rzadko prowadzi się dowody matematyczne programów. Nie dają one jednak w praktyce pewności, ponieważ nie ma gwarancji, że nie było buga w modelu zachowania programu (jeśli ta sama osoba pisze kod i dowód, ten sam bug mógł się pojawić w obu), ani też, że stosowany przez nas model matematyczny odpowiada rzeczywistości (np. kompilator czy nawet sam procesor może wprowadzić optymalizacje, które psują "poprawny" kod).

Ponieważ testowanie dużych czynności jest trudną operacją, zwykle testuje się osobno podzespoły programu, oraz program w całości (zakładając przy tym, że podzespoły działają poprawnie). Może to oczywiście przeoczyć pewną klasę bugów.

Często, np. w przypadku programów sieciowych, operujących bezpośrednio na sprzęcie czy wymagających interakcji z wieloma użytkownikami, trudno jest testować program w naturalnym środowisku, i konieczne jest testowanie w środowisku sztucznym, za pomocą emulatorów sprzętu, sieci czy sztucznego karmienia programu wydarzeniami udającymi użytkowników ("wpisano X w pole Y", "kliknięto na przycisk" itd.).

Testy pisze się zwykle w późnej fazie rozwoju oprogramowania. W metodologii extreme programming testy pisze się zanim rozpocznie się pisanie danej części oprogramowania, co ma zmniejszyć liczbę błędów.

Do tworzenia testów i zarządzania nimi istnieje wiele systemów, tzw. testing frameworks, takich jak XUnit.

Zobacz też: