Loading AI tools
Błąd oprogramowania lub w żargonie informatycznym bug (czytaj bag ⓘ) – usterka programu komputerowego powodująca jego nieprawidłowe działanie, wynikająca z błędu człowieka na jednym z etapów tworzenia oprogramowania, zwykle podczas tworzenia kodu źródłowego, lecz niekiedy także na etapie projektowania.
Słowo bug (z ang. pluskwa, owad, robactwo) przeszło prawdopodobnie do żargonu programistycznego z żargonu inżynierów telekomunikacji, którzy żartowali na temat szumów w sygnale, mówiąc, że „owady zalęgły się w urządzeniu”. Wiadomo też, że słowa bug w kontekście usterki użył Thomas Edison już w 1878[1].
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 prac prowadzonych 9 września 1947 r.[2] z komputerem Harvard Mark II stwierdzono jego nieprawidłowe działanie, a po poszukiwaniach przyczyny operatorzy, m.in. William „Bill” Burke znaleźli w przekaźniku 70. panelu F ćmę (ang. moth), która powodowała spięcie. Owad został usunięty i wklejony do dziennika z wpisem o ćmie przypisywanym Grace Hopper – fotografia obok. Dziennik do 1991 roku znajdował się w Naval Surface Warfare Center Computer Museum w Dahlgren w stanie Wirginia (USA), a obecnie w The Smithsonian Institute National Museum of American History. Opis fotografii tego dziennika podaje błędny rok wpisu – 1945, inne źródła wskazują na rok 1947, co potwierdza fakt, iż komputer Mark II został uruchomiony w lipcu tego roku.
Słowo bug jest często tłumaczone w tym kontekście jako pluskwa. Pluskwa oznacza obecnie również podsłuch lub podgląd elektroniczny (mikrofon, kamera) lub analogicznie backdoor celowo zaimplementowany w oprogramowaniu z inicjatywy programisty lub na zlecenie.
Błędy programistyczne są przedmiotem wielu spośród tzw. praw Murphy’ego, m.in. prawo nieskończoności Lubarskiego „w każdym programie (dłuższym niż 100 linijek) jest jeszcze jeden błąd”[3].
Bug jako określenie błędu programistycznego występuje w nazwach programów pomagających usuwać błędy, 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, co z kolei pozwala znaleźć dokładne miejsce w kodzie źródłowym, w którym należy dokonać poprawek.
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 jednych z nich należy Bugzilla (stworzony pierwotnie na potrzeby projektu Mozilla), do listopada 2014 r.[4] stosowana przez fundację Wikimedia do zbierania informacji o błędach w oprogramowaniu Wikipedii i pokrewnych Wiki (została zastąpiona przez Phabricatora). W systemie Bugzilla każdy może zgłosić błąd, podając przy tym okoliczności, w jakich on występuje. Zgłoszenie to jest następnie przydzielane określonemu programiście, a aktualne informacje o postępach w naprawianiu usterki są udostępniane w systemie.
Z reguły wyróżnia się trzy główne typy błędów:
- Błędy składniowe – nie pozwalają na kompilację programu, jak np. literówka w nazwie zmiennej lub wywołaniu funkcji. Są one wykrywane przez kompilator i najczęściej dość łatwe do usunięcia. Zazwyczaj wynikają z drobnych pomyłek programisty.
- Błędy semantyczne (znaczeniowe) – część błędów semantycznych można wychwycić już w momencie kompilacji, np. próbę odczytania wartości niezainicjowanej zmiennej, lecz inne mogą ujawnić się dopiero w trakcie wykonywania.
- Błędy logiczne – nie przerywają kompilacji, lecz powodują niewłaściwe działanie warstwy logicznej jak np. niepoprawne wyznaczanie pozycji gracza (które także może być spowodowane literówką – jak np. wpisanie znaku „+” zamiast „-”). Ten typ błędów jest znacznie trudniejszy do wykrycia i usunięcia; często błąd tkwi 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).
W typowych warunkach można się spodziewać, że w każdym nietrywialnym programie będą błędy. Liczbę błędów można też ograniczyć przeprowadzając testy programu. 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.
Do metod zmniejszania liczby błędów można zaliczyć:
- umiejętne zastosowanie paradygmatów programowania strukturalnego, proceduralnego i obiektowego,
- pisanie w sposób czytelny, hierarchiczne formatowanie kodu źródłowego
- unikanie skrótów programistycznych w rodzaju
++i*=*c--;[5] - stosowanie zrozumiałych identyfikatorów, nawet kosztem ich większej długości
- stosowanie komentarzy w miejscach, których zrozumienie kodu nie jest natychmiastowe
- współtworzenie programu i jego dokumentacji
- opisywanie (w komentarzach i dokumentacji) założeń przyjętych podczas pisania danego fragmentu kodu (np. co do typów danych wejściowych, czy spodziewanego sposobu użycia)
- unikanie trudnych w analizie konstrukcji (jak instrukcja skoku, czy ewaluacja kodu w trakcie wykonania)
- używanie narzędzi wykrywających podejrzane fragmenty kodu (np. lint), włączenie ostrzeżeń kompilatora o napotkaniu konstrukcji będących częstym źródłem błędów (np.
if(a=b)...zamiastif(a==b)...) - ręczne audyty kodu
Czasem błędy wykrywa się przez wprowadzanie do programu losowych danych i sprawdzanie otrzymywanych odpowiedzi. Ponieważ typowe błędy dotyczą wielu danych, wykrywa się w ten sposób większość błędów.
Bardzo rzadko przeprowadza się dowody matematyczne programów. Nawet one nie dają jednak gwarancji poprawnego działania programu, ponieważ nie jest pewne, że model zachowania programu jest bezbłędny (jeśli ta sama osoba pisała kod i dowód, to ten sam błąd mógł się pojawić w obu), ani też, że zastosowany 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żna przez to przeoczyć pewną klasę błędów.
Często trudno jest testować program w naturalnym środowisku (np. w przypadku programów sieciowych, operujących bezpośrednio na sprzęcie czy wymagających interakcji z wieloma użytkownikami) i dlatego konieczne jest testowanie w środowisku sztucznym – za pomocą emulatorów sprzętu, sieci czy sztucznego generowania zdarzeń symulujących działania użytkowników („wpisano X w pole Y”, „kliknięto przycisk Z” itp.).
Testy pisane są zwykle w późnej fazie rozwoju oprogramowania. W metodologii zwanej „programowaniem ekstremalnym” 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. To zaskakujące stwierdzenie można wyjaśnić w następujący sposób: jeśli w programie wykryto dużo lub bardzo dużo błędów, to jest on prawdopodobnie źle napisany, zatem łą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.
Wikiwand in your browser!
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.
