Błąd (informatyka)

Z Wikipedii

Masz nowe wiadomości (różnica z poprzednią wersją).

Błąd oprogramowania lub w żargonie informatycznym bug (czytaj bag) - wyrażenie oznaczające 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

Pierwsza komputerowa "pluskwa" usunięta z komputera Mark II

Nazwa pochodzi od angielskiego słowa bug (pluskwa, 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³, do budowy których wykorzystywano przekaźniki oraz wymagające wysokich napięć lampy elektronowe, owady powodowały spięcia, czego następstwem były błędy w wynikach działania maszyny.

Wprowadzenie do użycia wspomnianego terminu przypisywane jest też pani admirał Grace Hopper, choć pewne źródła negują jej udział w poniższej historii. Podczas prowadzonych – według różnych źródeł w 1945 lub 1947 r. – pracach z prymitywnym komputerem Harvard Mark II operator stwierdził jego nieprawidłowe działanie, i po poszukiwaniach przyczyny znalazł pomiędzy gołymi przewodami przekaźnika drobnego insekta (ang. bug) – ćmę, która powodowała spięcie. Owad został usunięty i wklejony do dziennika – fotografia obok. Dziennik obecnie znajduje się w Naval Surface Warfare Center Computer Museum w Dahlgren w stanie Wirginia (USA).

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 błąd 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 błędów. Ich ilość jednak można znacząco ograniczyć. Uważa się, że ilość błędów na wiersz 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 błędów niż w języku niższego poziomu (Java, C, czy asembler).

Ilość błędó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 błędy wykrywa się przez karmienie programu losowymi danymi i sprawdzanie otrzymywanych odpowiedzi. Ponieważ typowe błędy dotyczą wielu danych, wykrywa się w ten sposób większość błędó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 błędu w modelu zachowania programu (jeśli ta sama osoba pisze kod i dowód, ten sam błąd 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ę błędó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. Wiąże się to ze zjawiskiem – stwierdzonym empirycznie i znanym z literatury specjalistycznej – wiązki błędów. Oznacza to, że im więcej odkryto błędów w programie, tym większe jest prawdopodobieństwo istnienia błędów niewykrytych. Jednocześnie wyglądające na zaskakujące stwierdzenie jest bardzo racjonalne – jeśli w programie wykryto dużo lub bardzo dużo błędów, to jest on napisany źle lub bardzo źle, więc łączna ilość błędów może być większa niż ilość wykrytych. W tym kontekście wczesne wykrywanie błędów (czyli złego programowania) pozwala na uniknięcie tego zjawiska.

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