W informatyce , A bug ( wymawiane w języku francuskim: / b œ g / ) lub bug to wada projektu w programie komputerowym , powodując się awarię .
Nasilenie awarii może wahać się od łagodnego, na przykład powodując błędy wyświetlania moll - w tym przypadku będziemy czasami mówić o „ glitch (ES) ” - do głównych, takich jak systemowej katastrofy, które mogą prowadzić do poważnych wypadków, na przykład. zniszczenie w locie pierwszej rakiety Ariane 5 w 1996 roku .
Błąd może znajdować się w aplikacji , w oprogramowaniu innej firmy używanym przez tę aplikację, a nawet w oprogramowaniu sprzętowym komponentu sprzętowego, jak miało to miejsce w przypadku błędu działu Pentium . Łata jest to oprogramowanie przeznaczone do prawidłowego jeden lub więcej błędów.
Błędy są jedną z przyczyn nieprawidłowego działania urządzeń komputerowych; inne przyczyny nieprawidłowego działania obejmują:
Angielskie słowo błąd należy do żargonu inżynierów sprzętu i reprezentuje problemy, które się w nim pojawiły. Użycie tego terminu do opisania usterek w układach mechanicznych sięga co najmniej lat siedemdziesiątych XIX wieku . Między innymi Thomas Edison użył tego słowa w swoich notatkach.
Termin „błąd” występuje w internetowym słowniku Larousse z definicją: „Błąd projektowy lub produkcyjny programu komputerowego, który objawia się nieprawidłowościami w działaniu komputera. "
W skomputeryzowanym skarbcu języka francuskiego zachowano jedynie słowo „bug” w znaczeniu „pikantna koperta z kasztanów, orzechów bukowych, orzechów laskowych i niektórych nasion roślin strączkowych”.
Witryna FranceTerme , Office québécois de la langue française i Direction de la langue française (Belgia) zalecają termin „błąd”, a także debugowanie, debugowanie i debugger instrumentów pochodnych
Termin ten jest czasami fałszywie przypisywany Grace Hopper . Zanotowała w swoim dzienniku utrzymania, przechowywanym w Smithsonian Institution , opatrzony datą9 września 1947, 15 h 45 , dwa styki przekaźnika spowodowały awarię Harvard Mark II , jednego z pierwszych komputerów elektromechanicznych.
Hopper nie znalazł błędu, jak chętnie przyznała. Operatorzy, którzy później go znaleźli, w tym William „Bill” Burke z Naval Weapons Lab, znali termin inżynieria i byli rozbawieni, opisywali ten błąd z adnotacją „pierwszy znaleziony prawdziwy błąd”.
Był to termin używany przez inżynierów mechaników i elektryków, wyjaśniający trudności napotkane w sprzęcie na długo zanim Grace Hopper usłyszała o tym słowie.
W swojej książce opublikowanej w 1987 roku Frederick Brooks mówi, że obecność błędów w oprogramowaniu nie jest przypadkowa, ale wynika z samej natury oprogramowania, innymi słowy, w oprogramowaniu są błędy, ponieważ są one oprogramowaniem. Powiedział też, że nie ma żadnego panaceum - narzędzie cud - do czynienia z błędami, co nawiązuje do legendy o średniowieczu , że tylko piłka w srebrze , przypominający kolorem księżyca, może odpędzić wilkołaka .
Oprogramowanie jest niewidoczne i niematerialne, jego modyfikacja nie wymaga surowca. Bardzo szybka ewolucja rynku IT generuje duże zapotrzebowanie na zmiany. Wszystkie te czynniki powodują, że zmiany w oprogramowaniu są znacznie częstsze niż w innych produktach, takich jak samochody czy budynki .
Komputery należą do najbardziej złożonych produktów stworzonych przez człowieka i dlatego mają bardzo dużą liczbę stanów . Oprogramowanie jest bardziej złożone niż komputery iw przeciwieństwie do samochodów żadna część nie jest taka sama. Zgodność z wieloma normami charakterystycznymi dla dziedzin bliskich telekomunikacji zwiększa ich złożoność. Oprogramowanie to ponadto niewidoczne produkty, których nie można przedstawić w przestrzeni geometrycznej, a reprezentacje graficzne oprogramowania często składają się z dwóch, a nawet trzech lub czterech diagramów, z których każdy odpowiada innej rzeczywistości.
Błędy mogą spowodować, że oprogramowanie będzie próbowało wykonać operacje, których nie można wykonać ( wyjątki ): dzielenie przez zero, wyszukiwanie nieistniejących informacji. Operacje te - które nigdy nie są wykonywane podczas prawidłowego działania oprogramowania - uruchamiają mechanizm zarówno sprzętowy, jak i programowy, który następnie dezaktywuje wadliwe oprogramowanie, co powoduje awarię komputera lub odmowę usługi .
Watchdog jest autonomicznym urządzeniem elektronicznym wykorzystywane do wykrywania usterek. Ten mechanizm jest często używany w krytycznych systemach i komputerach przemysłowych .
Niebieski ekran śmierci jest mowie potocznej z Microsoft Windows systemów operacyjnych wiadomości likwidacyjnych , który jest wyświetlany, gdy wyjątek jest wykrywany w rdzeniu systemu operacyjnego. Panika Kernel jest wyświetlany komunikat w podobnych warunkach na UNIX operacyjnych systemów .
Wyciek pamięci jest to usterka spowodowana błędem w alokacji pamięci operacji . W przypadku tej usterki ilość pamięci używanej przez wadliwe oprogramowanie będzie stale rosła. Jeśli wadliwe oprogramowanie jest w stanie wykorzystać prawie całą dostępną pamięć, zakłóca działanie innych programów i powoduje ich nieprawidłowe działanie.
Błąd segmentacja jest wadliwe z powodu błędu w operacjach manipulowania wskaźniki lub adresy pamięci . Wadliwe oprogramowanie podejmie próbę odczytania lub zapisania informacji w miejscu ( segmencie ) pamięci, które nie istnieje lub nie jest do tego upoważnione. Mechanizm wykrywania wyjątków powoduje następnie wyłączenie wadliwego oprogramowania.
Całkowitą przepełnienie jest wadliwe z powodu błędu w obliczeniach matematycznych operacji. Wadliwe oprogramowanie podejmie próbę wykonania obliczenia, którego wynik jest większy niż maksymalna dozwolona wartość. Mechanizm wykrywania wyjątków powoduje następnie wyłączenie wadliwego oprogramowania.
Przepełnienia bufora jest wadliwe działanie ze względu na błąd. Oprogramowanie, które musi zapisywać informacje w określonej i ograniczonej lokalizacji pamięci ( pamięć buforowa ), przekracza granice tej lokalizacji, a następnie zapisuje informacje w lokalizacji przeznaczonej do innego użytku, ta nieoczekiwana modyfikacja prowadzi do błędnego wykonania oprogramowania, co może kończy się błędem segmentacji lub przepełnieniem. Jest to powszechna luka w zabezpieczeniach serwera, która jest często wykorzystywana przez hakerów . zobacz Exploit .
Stos przelewowy jest wadliwe w którym wielkość oprogramowanie w realizacji stosu przekracza pojemność buforu , który go zawiera, powodując nieprawidłowe działanie podobne do przepełnienia bufora . Stos wykonawczy to struktura danych przechowywana w pamięci, która zawiera stan automatyzacji oprogramowania (patrz proces (przetwarzanie danych) ), struktura ta jest zapisywana w pamięci buforowej, której rozmiar jest przewymiarowany. Przepełnienie stosu wynika z błędnej sekwencji z powodu błędu.
Sytuacji konkurencyjnej (angielski wyścigu ) jest wadliwe z powodu błędu, który powoduje dwa w jednym automatyzacja oprogramowanie pracuje jednocześnie dają różne wyniki w zależności od wykończenia automatyzacji że przed drugą.
Impasu (angielski deadlock ) jest wtedy, gdy usterka w których kilka automatyzacja spodziewać się nawzajem, to znaczy każdy z nich oczekiwać, że inne rodzaje zanieczyszczeń zasobów, których używa, aby kontynuować. Zasoby pozostają zablokowane podczas oczekiwania, co może blokować inne automatyzmy, a efekt domina blokuje cały system. Mechanizm prewencyjny powoduje anulowanie operacji, gdy czas oczekiwania przekroczy dopuszczalny limit czasu .
Im bardziej złożony kod, tym trudniej jest zlokalizować błąd. Błędy, które zależą od kombinacji nieprzewidzianych i nieprawdopodobnych warunków, są szczególnie trudne do zlokalizowania. W folklorze hackerów istnieją kategorie dziwacznych błędów, których zabawne nazwy wywodzą się od nazwisk wybitnych naukowców zajmujących się fizyką kwantową i matematyką.
Wykonywanie oprogramowania krok po kroku za pomocą debuggera może spowodować Heisenbug po prostu dlatego, że oprogramowanie działa wolniej. Konkurencyjne sytuacje mogą prowadzić do Mandelbuga , w którym zachowanie programu jest inne za każdym razem, gdy jest on wykonywany.
Błędy są wynikiem błędów ludzkich podczas pracy przy specyfikowaniu , projektowaniu , programowaniu i testowaniu oprogramowania i sprzętu komputerowego. Rosnąca złożoność oprogramowania, problemy z komunikacją, brak wyszkolenia inżynierów oraz presja terminów i kosztów podczas prac inżynierskich to czynniki, które mają tendencję do zwiększania liczby błędów.
Testowania oprogramowania jest pierwszym krokiem do zwalczania robaków. Ze względów praktycznych (koszt pracy i terminy) nie jest możliwe przetestowanie oprogramowania we wszystkich warunkach, jakie może spełnić podczas jego użytkowania, a zatem nie jest możliwe przeciwdziałanie wszystkim błędom: oprogramowanie takie jak Microsoft Word ma 850 poleceń i 1600 funkcji łącznie ponad 500 milionów warunków do przetestowania.
Wykorzystanie języków programowania wysokiego poziomu , które ułatwiają pracę inżyniera. Implementacja konwencji pisania to inne techniki zapobiegawcze mające na celu zmniejszenie liczby błędów.
Debugowanie to czynność polegająca na diagnozowaniu i naprawianiu błędów. Podczas debugowania online inżynier uruchamia oprogramowanie krok po kroku i po każdym kroku przeprowadza serię kontroli. Podczas debugowania pośmiertnego inżynier sprawdza oprogramowanie po awarii komputera.
Gdy błąd zostanie wykryty i poprawiony po dystrybucji oprogramowania, dostawca często dostarcza łatkę , czyli zestaw, który zastępuje wadliwe części oprogramowania tymi, które zostały poprawione.
Inżynierowie często używają systemu śledzenia błędów , tj. Oprogramowania bazodanowego, w którym wprowadzane są różne błędy i praca wykonana dla każdego z nich:
Wiele języków programowania zawiera mechanizmy sprawdzania awarii. Instrukcje niezbędne do weryfikacji są automatycznie dodawane do kodu maszynowego lub do kodu bajtowego oprogramowania podczas kompilacji . Instrukcje mogą spowodować automatyczną aktywację debuggera , oprogramowania do diagnozowania błędów.
Przegląd kodu ma na celu poddanie nowo opracowanego kodu źródłowego osobie trzeciej, która ponownie go przeczyta i poszuka defektów.
Testowanie oprogramowania to pierwszy krok w usuwaniu błędów. Polegają na używaniu oprogramowania w jak największej liczbie warunków. Celem testów jest wykrycie różnych problemów:
Testy są powtarzane kilkakrotnie, jako zaawansowane programowanie i poprawki, w celu walidacji poprawek i wykrycia ewentualnych błędów regresja : błąd powstał w wyniku błędnej korekty innego błędu. Testowanie można zautomatyzować za pomocą oprogramowania działającego w imieniu użytkownika. Czasami do testów opracowywane jest drugie oprogramowanie.
Te testy jednostkowe jest użycie Unikalną cechą oprogramowania w celu wykrycia usterki. Te testy integracyjne to za pomocą zestawu funkcji do sterowania spójność całości. Do testów walidacyjnych są do korzystania całe oprogramowanie do oceny jego przydatności jako wymagane przez kupującego.
Testy jednostkowe i integracyjne są zwykle wykonywane przez inżyniera, podczas gdy testy walidacyjne są zwykle wykonywane przez kupującego lub jego przedstawiciela.
Innym środkiem zapobiegawczym mającym na celu uniknięcie błędów jest formalny dowód (lub demonstracja matematyczna) działania programu w sposób ogólny. W przeciwieństwie do testu, który weryfikuje tylko jeden podany przypadek działania, ten dowód ma na celu zapewnienie, że program działa we wszystkich przypadkach, niezależnie od warunków użytkowania. Jednak wszystkie formalne techniki weryfikacji są uciążliwe i złożone. W kategoriach bezwzględnych nie wiemy, jak zweryfikować poprawność działania dowolnego programu we wszystkich przypadkach. Z drugiej strony istnieją metody tworzenia oprogramowania, które podczas tworzenia oprogramowania ustawiają elementy do monitorowania przejścia do każdego kroku pośredniego między specyfikacjami lub specyfikacjami oprogramowania z jednej strony, a programem końcowym z jednej strony. inna ręka. Dzięki tym elementom monitorującym możliwe są wówczas weryfikacje, a także nakładanie i blokowanie ograniczeń zgodności ze specyfikacją.
W dziedzinach, w których błąd spowodowałby śmierć ludzi (na przykład w lotnictwie), stosuje się uciążliwe i złożone metody, aby udowodnić brak błędów w oprogramowaniu podczas jego projektowania. Tak więc, oprogramowanie sterujące dla automatycznej linii metra w Paryżu 14 był pierwotnie produkowany z notacji Z . Jednak do stworzenia ostatecznej wersji użyto metody B. Metoda B jest również uważana za najlepsze narzędzie zapewniające, że program komputerowy spełnia specyfikacje jego zachowania. Rzeczywiście, użycie metody B do stworzenia programu prowadzi również (automatycznie) do matematycznego wykazania zgodności tak utworzonego programu, który z definicji staje się zatem zademonstrowanym twierdzeniem.
Jednak złożoność zastosowania tej metody powoduje na tyle dodatkową pracę, że pojedynczy programista może potrzebować 100 razy więcej czasu na stworzenie programu tą metodą, niż gdyby stworzył ten sam program w tradycyjny sposób. Oznacza to, że stworzenie programu tą metodą kosztuje 100 razy więcej. W rezultacie, pomimo swojej skuteczności, ta metoda jest bardzo rzadko stosowana i istnieje wiele obszarów, w których błędy mogą powodować śmierć ludzi i w których po prostu tworzymy programy pełne błędów., W tradycyjny sposób, a następnie wykonujemy bardzo rygorystyczne testy, aby wyeliminować większość z nich. Dopóki prawdopodobieństwo, że błąd powodujący awarię zabijającą ludzi jest mniejsze niż prawdopodobieństwo, że błąd ludzki wywoła ten sam rodzaj usterki, jest często uznawany za „akceptowalny”. (Dodatkowy koszt stosowania metody B w celu upewnienia się, że nikt nie umrze, jest uważany za niedopuszczalny).
Do debugowania lub znajdowania i naprawiania błędów inżynierowie używają oprogramowania, debuggera , a także systemu śledzenia błędów .
System śledzenia błędów służy do koordynowania prac związanych z debugowaniem, służy do zbierania wszystkich zaobserwowanych usterek, rejestrowania przyczyn i przeprowadzonych działań naprawczych, a tym samym monitorowania postępów w usuwaniu błędów. Przyczyną mogą być błędy, ale także błędy w parametrach konfiguracyjnych lub błędy obsługi. Z systemu śledzenia błędów korzystają użytkownicy wadliwego oprogramowania, a także inżynierowie lub administratorzy systemu .
Debugger umożliwia analizę stanu wykonania programu w danym momencie, wykonywanych operacji, informacji w pamięci, otwartych plików itp. Dzięki debugerowi online można w dowolnym momencie zawiesić działanie oprogramowania, przeanalizować stan, a następnie kontynuować przetwarzanie.
Dzięki debuggerowi post mortem można analizować stan wykonania oprogramowania po awarii. Analiza jest wykonywana na podstawie pliku, który zawiera kopię zawartości pamięci w momencie awarii. Plik o nazwie zrzut rdzenia w systemach operacyjnych Unix .
Wersja oprogramowania to stan oprogramowania w danym dniu, w tym wszystkie poprawki i ulepszenia wprowadzone do tego dnia. O wersji mówi się, że jest alfa lub beta, jeśli odpowiada stanowi oprogramowania przed końcem czasu trwania testów. Taka wersja prawdopodobnie zawiera błędy, które w międzyczasie zostały wykryte i poprawione.
Po naprawieniu jednego lub więcej defektów są one zgrupowane razem w łatce , zestawie zawierającym tylko te składniki oprogramowania, które zostały poprawione. Będzie używany przez każdego, kto jest właścicielem kopii oprogramowania, aby wprowadzić do niego poprawki i dopasować go do określonej wersji.
Niepowodzenie inauguracyjnego lotu rakiety Ariane 5 w 1996 roku było spowodowane defektem urządzeń awioniki rakiety, urządzeń używanych z powodzeniem przez kilka lat na rakiecie Ariane 4 . Podczas startu urządzenie komputerowe, które obliczało pozycję rakiety na podstawie jej przyśpieszenia, nie wspierało przyspieszeń Ariane 5, 5 razy większych niż Ariane 4. Przekroczenie liczby całkowitej spowodowało awarię komputera. Oślepiony autopilot stracił kontrolę nad rakietą, a urządzenie bezpieczeństwa spowodowało jej samozniszczenie kilka sekund po starcie. Jest to jeden z najbardziej kosztownych błędów komputerowych w historii.
W 1962 roku w misji Mariner 1 doszło do podobnego incydentu.
W latach 80. błąd oprogramowania w aparacie do radioterapii sterowanym przez PDP-11 , Therac-25 , miał tragiczne konsekwencje, pacjenci otrzymali ogromne dawki promieniowania i co najmniej pięciu zmarło.
Roku 2000 bug , zwany także Millennium bug : jeden lub więcej błędów w oprogramowaniu, które manipuluje daktyle spowodować ich uszkodzenie, gdy terminy są po 31 grudnia 1999. Jedną z przyczyn jest to, że obliczenia zostały wykonane w terminach tylko w Internecie. Ostatnia dwie cyfry roku.
Potencjalne problemy związane z datą 31 grudnia 1999 roku po raz pierwszy zostały zablokowane przez Boba Berner w 1971 roku wywołały one znaczną mobilizację Inżynieria oprogramowania firmom kilka lat przed upływem terminu i całkowity koszt prac sterowania i kontroli. Konserwacja zapobiegawcza jest szacowany na ponad 600 milionów dolarów.
W 2002 roku system komputerowy w St Mary's Mercy Hospital w Michigan omyłkowo ogłosił śmierć 8500 pacjentów, którzy w rzeczywistości wciąż żyli, wysyłając do ich domów rachunek i oświadczenie o zgonie wraz z zawiadomieniem o śmierci do firmy ubezpieczeniowej i US Social Security. Anulowanie tych zgonów przez różne administracje zajęło kilka tygodni.
Błąd może być:
Specyfikacja może być nieformalna i niejasna (na przykład: „oprogramowanie to edytor tekstu, który nie powoduje błędów w czasie wykonywania”) lub formalna i precyzyjna („sort ( t ) to permutacja t, na przykład sort ( t ) jest uporządkowana dla relacja <»), w tym do momentu uzyskania wzorów matematycznych. Zakładając najbardziej kompletną możliwą specyfikację, błędny program to taki, którego implementacja nie spełnia tej specyfikacji.
Wątpliwe jest, czy istnieją uniwersalne, bezbłędne i automatyczne metody, których trzeba by tylko przestrzegać, aby zdać sobie sprawę, czy program zawiera błędy, czy nie. Odpowiedź brzmi nie. Rzeczywiście, gdyby istniała taka metoda, można by ją zautomatyzować za pomocą komputera, to znaczy za pomocą oprogramowania analitycznego. Ten analizator powinien działać na dowolnych programach, które mają być analizowane i powinien na przykład odpowiedzieć na następujące pytanie: „czy ostateczny stan programu może być stanem błędu w czasie wykonywania, czy też koniecznie jest to stan?” Poprawny (lub inny niż wypowiedzenie) ”. Jednak twierdzenie Rice'a mówi, że na to pytanie nie można odpowiedzieć w nieskończonym systemie państw. Mówiąc bardziej ogólnie, każde pytanie specyfikacyjne odnoszące się do końcowego stanu programu jest nierozstrzygalne , to znaczy, że oprogramowanie lub metoda automatyczna nie mogą na nie odpowiedzieć, z wyjątkiem pytań, na które odpowiedź jest zawsze prawdziwa lub zawsze prawdziwa.
Można by sprzeciwić się temu, że komputery są systemami o skończonych stanach: każdy komputer ma ograniczoną ilość pamięci. Jednak z wyjątkiem bardzo małych systemów, komputery powinny być brane pod uwagę do analizy jako systemy pamięci nieograniczonej. Rzeczywiście, wszystkie techniki analizy wykorzystujące skończoność stanu zmierzają w mniej lub bardziej okrężny lub zoptymalizowany sposób, aby wyliczyć stany systemu. System z n bitami pamięci ma 2 n stanów; w obecnym komputerze osobistym n jest rzędu 238 . Widzimy więc, że każda próba wyliczenia stanów systemu jest skazana na niepowodzenie.
Niemożność uniwersalnego automatycznego wyszukiwania błędów jest zatem podstawowym problemem, a nie ograniczeniem obecnej technologii.
Branża programistyczna dokłada wszelkich starań, aby znaleźć metody zapobiegania błędom programisty prowadzącym do błędów.
Znajdowanie i naprawianie błędów lub debugowanie to główna część programowania oprogramowania. Pionier komputerów, Maurice Vincent Wilkes, opisuje swoje osiągnięcia w latach czterdziestych XX wieku, mówiąc, że większość swojego życia spędziłby na naprawianiu błędów we własnych programach. Ponieważ programy komputerowe stają się coraz bardziej złożone, błędy stają się częstsze i trudniejsze do naprawienia. Czasami programiści poświęcają więcej czasu i wysiłku na znajdowanie i naprawianie błędów niż na pisanie nowego kodu.
Zwykle najtrudniejszą częścią debugowania jest znalezienie części kodu, która spowodowała błąd. Po zlokalizowaniu często jest to łatwe. Istnieją programy zwane debuggerami , które pomagają programistom znajdować błędy. Jednak nawet przy pomocy debuggera znalezienie błędu jest często bardzo trudnym zadaniem.
Zwykle pierwszym krokiem do znalezienia błędu jest znalezienie sposobu na łatwe jego odtworzenie. Po odtworzeniu błędu programista może użyć debugera lub innego narzędzia, aby obserwować wykonywanie programu w jego zwykłym kontekście i prawdopodobnie znaleźć problem. Z drugiej strony odtworzenie błędu nie zawsze jest łatwe. Niektóre są spowodowane przez dane wejściowe do oprogramowania, które mogą być trudne do odtworzenia dla programisty. Inne mogą zniknąć, gdy program zostanie uruchomiony w debugerze ; nazywane są one heisenbugs (żartobliwie odwołując się do zasady nieoznaczoności Heisenberga). Wreszcie, błędy programów równoległych (złożonych z kilku modułów działających jednocześnie, na przykład na kilku procesorach) są często trudne do odtworzenia, jeśli zależą od dokładnego planowania obliczeń na maszynie.
Termin błąd w grach wideo ma przede wszystkim oznaczać błąd w rzekomym przebiegu akcji. Ostateczny wynik błędu nie spowoduje takiego samego dyskomfortu w zależności od jego intensywności. Ręka gracza przebijająca się przez ścianę w FPS nie będzie miała takiej samej uciążliwości, jak niemożność ukończenia głównego zadania w grze RPG .
Istnienie błędów przynosi nie tylko punkty ujemne:
Termin błąd obejmuje inne pojęcia, które są rzadziej używane ze względu na popularność nazwy błąd . Rozsądnie byłoby nazwać niektóre błędy „zapominaniem”, a nie błędem.
Zobacz także kategorię Rozwój oprogramowania