Błąd (informatyka)
Z Wikipedii
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.
Spis treści |
[edytuj] Etymologia słowa bug
Słowo bug (z ang. pluskwa, owad, robactwo) przeszło prawdopodobnie 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żył Thomas Edison już w 1878.
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
Zobacz więcej w osobnym artykule: Debugowanie.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ł.
Aby ułatwić zgłaszanie błędów testerom i użytkownikom oraz w celu śledzenia stanów błędów przez wszystkich zainteresowanych, powstały liczne systemy śledzenia błędów. Do najpopularniejszych należy Bugzilla (stworzony oryginalnie na potrzeby projektu Mozilla), stosowany również przez fundację MediaWiki do zbierania informacji o błędach w oprogramowaniu Wikipedii i pokrewnych Wiki (patrz: http://bugzilla.wikipedia.org). 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] Typy błędów
Z reguły wyróżnia się dwa główne typy błędów: składniowe oraz logiczne. Błędy składniowe to błędy nie pozwalające na kompilację programu jak na przykład literówka w wywołaniu zmiennej. Są one najczęściej dość łatwe do usunięcia, zazwyczaj wynikają z drobnych pomyłek programisty. Błędy logiczne, to błędy, które nie przerywają kompilacji, lecz powodują niewłaściwe działanie warstwy logicznej - do błędów logicznych zalicza się np. niepoprawne liczenie pozycji gracza (które może być także spowodowane literówką - jak + zamiast -). Ten typ błędów jest wiele trudniejszy do wykrycia i usunięcia, często błąd leży w jednym źle zapisanym znaku, lecz programista musi do tego znaku sam dojść - w przypadku błędu składniowego znak jest wskazywany przez komunikat kompilatora.
[edytuj] Prewencja
W typowych warunkach można się spodziewać, że w każdym nietrywialnym programie będzie sporo błędów. Ich liczba jednak można znacząco ograniczyć. Uważa się, że liczba 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 (C, czy asembler). Stąd lepiej używać języków, które w krótszym tekście zawrą więcej treści.
Liczbę 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. Liczbę 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 liczba błędów może być większa niż liczba 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.
[edytuj] Zobacz też
[edytuj] Linki zewnętrzne
- Jak efektywnie zgłaszać błędy (Simon Tatham)
