Błąd oprogramowania -Software bug

Usterka oprogramowania to błąd, usterka lub usterka w programie komputerowym lub systemie , która powoduje, że generuje niepoprawny lub nieoczekiwany wynik lub zachowuje się w niezamierzony sposób. Proces znajdowania i naprawiania błędów jest określany mianem „ debugowania ” i często wykorzystuje formalne techniki lub narzędzia do wykrywania błędów, a od lat pięćdziesiątych niektóre systemy komputerowe zostały zaprojektowane tak, aby odstraszać, wykrywać lub automatycznie poprawiać różne błędy komputerowe podczas operacji.

Większość błędów wynika z pomyłek i błędów popełnionych w projekcie programu lub jego kodzie źródłowym lub w komponentach i systemach operacyjnych używanych przez takie programy. Kilka z nich jest spowodowanych przez kompilatory generujące niepoprawny kod. Program, który zawiera wiele błędów i/lub błędów, które poważnie zakłócają jego funkcjonalność, jest uważany za wadliwy (wadliwy). Błędy mogą powodować błędy, które mogą mieć efekt domina . Błędy mogą mieć subtelne skutki lub powodować awarię programu lub zamrażać komputer. Inne błędy kwalifikują się jako błędy bezpieczeństwa i mogą na przykład umożliwiać złośliwemu użytkownikowi ominięcie kontroli dostępu w celu uzyskania nieautoryzowanych uprawnień .

Niektóre błędy oprogramowania zostały powiązane z katastrofami. Błędy w kodzie, które kontrolowały urządzenie do radioterapii Therac-25 , były bezpośrednio odpowiedzialne za zgony pacjentów w latach 80. XX wieku. W 1996 roku prototyp rakiety Ariane 5 Europejskiej Agencji Kosmicznej o wartości 1 miliarda dolarów musiał zostać zniszczony niecałą minutę po wystrzeleniu z powodu błędu w programie komputerowym naprowadzania na pokładzie. W czerwcu 1994 r. helikopter Królewskich Sił Powietrznych Chinook rozbił się w Mull of Kintyre , zabijając 29 osób. Początkowo uznano to za błąd pilota, ale dochodzenie przeprowadzone przez Computer Weekly przekonało dochodzenie Izby Lordów , że mogło to być spowodowane błędem oprogramowania w komputerze sterującym silnikiem samolotu .

W 2002 roku badanie zlecone przez Narodowy Instytut Standardów i Technologii Departamentu Handlu Stanów Zjednoczonych wykazało, że „błędy w oprogramowaniu są tak powszechne i szkodliwe, że kosztują amerykańską gospodarkę około 59 miliardów dolarów rocznie, czyli około 0,6 procent produktu krajowego brutto".

Historia

Środkowoangielskie słowo bugge jest podstawą terminów „ bugbear ” i „ bugaboo ” jako terminów oznaczających potwora.

Termin „bug” opisujący defekty jest częścią żargonu inżynierskiego od lat 70. XIX wieku i poprzedza komputery elektroniczne i oprogramowanie komputerowe; mógł być pierwotnie używany w inżynierii sprzętu do opisywania usterek mechanicznych. Na przykład Thomas Edison napisał następujące słowa w liście do współpracownika w 1878 roku:

Tak było we wszystkich moich wynalazkach. Pierwszym krokiem jest intuicja i przychodzi z wybuchem, potem pojawiają się trudności — to coś ustępuje i [to] wtedy „robaki” — jak nazywa się takie małe błędy i trudności — pokazują się i miesiące intensywnego oglądania, studiowania a praca jest niezbędna, zanim komercyjny sukces lub porażka zostaną z pewnością osiągnięte.

Baffle Ball , pierwsza mechaniczna gra typu pinball , była reklamowana jako „wolna od błędów” w 1931 roku. Problemy ze sprzętem wojskowym podczas II wojny światowej określano jako błędy (lub usterki ). W książce opublikowanej w 1942 r. Louise Dickinson Rich , mówiąc o napędzanej maszynie do cięcia lodu , powiedziała: „Cięcie lodu zostało zawieszone do czasu, aż twórca mógł zostać sprowadzony, aby usunąć robaki z jego ukochanej”.

Isaac Asimov użył terminu „bug” w odniesieniu do problemów z robotem w swoim opowiadaniu „ Złap tego królika ”, opublikowanym w 1944 roku.

Strona z dziennika komputera elektromechanicznego Harvard Mark II , przedstawiająca martwą ćmę, która została usunięta z urządzenia.

Terminu „błąd” użyła na swoim koncie Grace Hopper , pionierka komputerów, która ujawniła przyczynę nieprawidłowego działania wczesnego komputera elektromechanicznego. Typowa wersja historii to:

W 1946 roku, po zwolnieniu Hoppera z czynnej służby, wstąpiła na wydział Harvarda w Laboratorium Obliczeniowym, gdzie kontynuowała prace nad Mark II i Mark III . Operatorzy wyśledzili błąd w Mark II do ćmy uwięzionej w przekaźniku, co ukuło termin bug . Ten błąd został starannie usunięty i przyklejony do dziennika. Wychodząc od pierwszego błędu, dziś błędy lub usterki w programie nazywamy błędem .

Hopper nie znalazła błędu, co chętnie przyznała. Data w dzienniku to 9 września 1947 r. Operatorzy, którzy go znaleźli, w tym William „Bill” Burke, późniejszy z Laboratorium Broni Morskiej w Dahlgren w stanie Wirginia , znali termin inżynierski i z rozbawieniem trzymali owada z adnotacją „Pierwszy rzeczywisty przypadek wykrycia błędu”. Hopper uwielbiał opowiadać historię. Ten dziennik, wraz z dołączoną ćmą, jest częścią kolekcji Smithsonian National Museum of American History .

Pokrewny termin „ debug również wydaje się poprzedzać jego użycie w informatyce: etymologia tego słowa w Oxford English Dictionary zawiera poświadczenie z 1945 r. w kontekście silników lotniczych.

Koncepcja, że ​​oprogramowanie może zawierać błędy, wywodzi się z notatek Ady Lovelace z 1843 r. dotyczących silnika analitycznego , w których mówi o możliwości, że „karty” programu dla silnika analitycznego Charlesa Babbage'a mogą być błędne:

... w równym stopniu musiał zostać przeprowadzony proces analizy w celu dostarczenia Silnikowi Analitycznemu niezbędnych danych operacyjnych ; i że tutaj może również leżeć możliwe źródło błędu. Zakładając, że rzeczywisty mechanizm działa bezbłędnie, karty mogą wydawać mu błędne rozkazy.

Raport „Błędy w systemie”

Open Technology Institute, prowadzony przez grupę New America, opublikował w sierpniu 2016 r. raport „Błędy w systemie”, w którym stwierdza, że ​​amerykańscy decydenci powinni dokonać reform, aby pomóc naukowcom w identyfikowaniu i usuwaniu błędów oprogramowania. Raport „podkreśla potrzebę reformy w dziedzinie wykrywania i ujawniania luk w oprogramowaniu”. Jeden z autorów raportu powiedział, że Kongres nie zrobił wystarczająco dużo, aby rozwiązać problem luki w oprogramowaniu cybernetycznym, mimo że Kongres uchwalił szereg ustaw mających na celu zwalczanie większego problemu cyberbezpieczeństwa.

Badacze rządowi, firmy i eksperci ds. cyberbezpieczeństwa to ludzie, którzy zazwyczaj odkrywają wady oprogramowania. Raport wzywa do zreformowania przepisów dotyczących przestępczości komputerowej i praw autorskich.

W raporcie stwierdzono, że ustawa o oszustwach komputerowych i nadużyciach, ustawa Digital Millennium Copyright Act i ustawa o prywatności w komunikacji elektronicznej kryminalizują i nakładają kary cywilne za działania, w które badacze bezpieczeństwa rutynowo angażują się podczas prowadzenia legalnych badań bezpieczeństwa.

Terminologia

Chociaż użycie terminu „błąd” do opisania błędów oprogramowania jest powszechne, wielu sugeruje, że należy go porzucić. Jednym z argumentów jest to, że słowo „błąd” jest oddzielone od poczucia, że ​​problem spowodował człowiek, a zamiast tego sugeruje, że wada pojawiła się sama, co prowadzi do nacisku na porzucenie terminu „błąd” na rzecz terminów takich jak: "wada", z ograniczonym sukcesem. Od lat 70. Gary Kildall nieco żartobliwie sugerował użycie terminu „pomyłka”.

W inżynierii oprogramowania metamorfizm błędu (z greckiego meta = „zmiana”, morph = „forma”) odnosi się do ewolucji defektu na końcowym etapie wdrażania oprogramowania. Przekształcenie „pomyłki” popełnionej przez analityka na wczesnych etapach cyklu wytwarzania oprogramowania, prowadzące do „defektu” w końcowej fazie cyklu, nazwano „metamorfizmem błędu”.

Różne etapy „pomyłki” w całym cyklu można określić jako „błędy”, „anomalie”, „błędy”, „awarie”, „błędy”, „wyjątki”, „awarie”, „usterki”, „błędy” , „wady”, „incydenty” lub „skutki uboczne”.

Zapobieganie

Błąd wynikający z błędu oprogramowania wyświetlanego na dwóch ekranach na stacji La Croix de Berny we Francji.

Branża oprogramowania włożyła wiele wysiłku w zmniejszenie liczby błędów. Obejmują one:

Błędy typograficzne

Błędy pojawiają się zwykle, gdy programista popełni błąd logiczny . Różne innowacje w stylu programowania i programowaniu defensywnym mają na celu zmniejszenie prawdopodobieństwa wystąpienia tych błędów lub łatwiejsze ich wykrycie. Niektóre literówki, zwłaszcza dotyczące symboli lub operatorów logicznych/matematycznych , pozwalają na nieprawidłowe działanie programu, podczas gdy inne, takie jak brakujący symbol lub błędnie napisana nazwa, mogą uniemożliwić działanie programu. Języki kompilowane mogą ujawnić pewne literówki podczas kompilowania kodu źródłowego.

Metodologie rozwoju

Kilka schematów pomaga w zarządzaniu aktywnością programistów, dzięki czemu powstaje mniej błędów. Inżynieria oprogramowania (która zajmuje się również problemami z projektowaniem oprogramowania) stosuje wiele technik w celu zapobiegania defektom. Na przykład formalne specyfikacje programów określają dokładne zachowanie programów, dzięki czemu można wyeliminować błędy projektowe. Niestety, specyfikacje formalne są niepraktyczne dla czegokolwiek poza najkrótszymi programami, z powodu problemów eksplozji kombinatorycznej i nieokreśloności .

Testowanie jednostkowe polega na napisaniu testu dla każdej funkcji (jednostki), którą program ma wykonać.

W programowaniu opartym na testach testy jednostkowe są pisane przed kodem i kod nie jest uważany za kompletny, dopóki wszystkie testy nie zakończą się pomyślnie.

Zwinne tworzenie oprogramowania wiąże się z częstymi wydaniami oprogramowania ze stosunkowo niewielkimi zmianami. Wady są ujawniane przez opinie użytkowników.

Programowanie open source pozwala każdemu zbadać kod źródłowy. Szkoła myślenia spopularyzowana przez Erica S. Raymonda jako prawo Linusa mówi, że popularne oprogramowanie o otwartym kodzie źródłowym ma większe szanse na to, że będzie zawierało niewiele błędów lub nie ma ich wcale, ponieważ „przy wystarczającej liczbie gałek ocznych wszystkie błędy są płytkie”. To twierdzenie zostało jednak zakwestionowane: specjalista ds. bezpieczeństwa komputerowego Elias Levy napisał, że „łatwo jest ukryć luki w złożonym, mało zrozumiałym i nieudokumentowanym kodzie źródłowym”, ponieważ „nawet jeśli ludzie przeglądają kod, nie oznacza to, że jesteście do tego wykwalifikowani”. Przykładem tego, co się faktycznie wydarzyło, była, przypadkowo, luka 2008 OpenSSL w Debianie .

Obsługa języka programowania

Języki programowania zawierają funkcje pomagające zapobiegać błędom, takie jak statyczne systemy typów , ograniczone przestrzenie nazw i programowanie modułowe . Na przykład, gdy programista pisze (pseudokod) LET REAL_VALUE PI = "THREE AND A BIT", chociaż może to być poprawne składniowo, kod nie przechodzi sprawdzenia typu . Języki kompilowane wychwytują to bez konieczności uruchamiania programu. Języki interpretowane wychwytują takie błędy w czasie wykonywania. Niektóre języki celowo wykluczają funkcje, które łatwo prowadzą do błędów, kosztem niższej wydajności: ogólna zasada jest taka, że ​​prawie zawsze lepiej jest pisać prostszy, wolniejszy kod niż nieodgadniony kod, który działa nieco szybciej, zwłaszcza biorąc pod uwagę, że koszty utrzymania są znaczne . Na przykład język programowania Java nie obsługuje arytmetyki wskaźników ; implementacje niektórych języków, takich jak Pascal i języki skryptowe, często mają sprawdzanie granic czasu wykonywania tablic, przynajmniej w kompilacji debugowania.

Analiza kodu

Narzędzia do analizy kodu pomagają programistom, sprawdzając tekst programu poza możliwościami kompilatora, aby wykryć potencjalne problemy. Chociaż ogólnie problem znajdowania wszystkich błędów programistycznych podanych w specyfikacji nie jest rozwiązany (patrz problem zatrzymania ), narzędzia te wykorzystują fakt, że programiści często popełniają pewne rodzaje prostych błędów podczas pisania oprogramowania.

Oprzyrządowanie

Narzędzia do monitorowania wydajności oprogramowania w trakcie jego działania, w szczególności w celu znalezienia problemów, takich jak wąskie gardła , lub zapewnienia poprawności działania, mogą być bezpośrednio osadzone w kodzie (być może tak proste, jak stwierdzenie PRINT "I AM HERE") lub dostarczone jako narzędzia. Często zaskoczeniem jest odkrycie, gdzie większość czasu zajmuje fragment kodu, a to usunięcie założeń może spowodować przepisanie kodu.

Testowanie

Testerzy oprogramowania to osoby, których głównym zadaniem jest znajdowanie błędów lub pisanie kodu wspierającego testowanie. W przypadku niektórych projektów więcej zasobów można przeznaczyć na testowanie niż na rozwój programu.

Pomiary podczas testowania mogą zapewnić oszacowanie liczby prawdopodobnych pozostałych błędów; staje się to tym bardziej niezawodne, im dłużej produkt jest testowany i rozwijany.

Debugowanie

Typowa historia błędów ( dane projektu GNU Classpath ). Nowy błąd zgłoszony przez użytkownika jest niepotwierdzony. Po odtworzeniu przez programistę jest to potwierdzony błąd. Potwierdzone błędy są później naprawiane . Błędy należące do innych kategorii (niepowtarzalne, nie zostaną naprawione itp.) są zazwyczaj w mniejszości

Znajdowanie i naprawianie błędów lub debugowanie to główna część programowania komputerowego . Maurice Wilkes , wczesny pionier informatyki, pod koniec lat czterdziestych zdał sobie sprawę, że większą część życia spędziłby na szukaniu błędów we własnych programach.

Zwykle najtrudniejszą częścią debugowania jest znalezienie błędu. Po znalezieniu, poprawienie go jest zwykle stosunkowo łatwe. Programy znane jako debuggery pomagają programistom lokalizować błędy, wykonując kod wiersz po wierszu, obserwując wartości zmiennych i inne funkcje służące do obserwowania zachowania programu. Bez debugera można dodać kod, dzięki któremu komunikaty lub wartości mogą być zapisywane w konsoli lub w oknie lub pliku dziennika w celu śledzenia wykonywania programu lub wyświetlania wartości.

Jednak nawet przy pomocy debuggera lokalizowanie błędów jest sztuką. Często zdarza się, że błąd w jednej sekcji programu powoduje awarie w zupełnie innej sekcji, co czyni go szczególnie trudnym do śledzenia (na przykład błąd w procedurze renderowania grafiki powodujący niepowodzenie procedury we/wy pliku ) , w pozornie niepowiązanej części systemu.

Czasami błąd nie jest odosobnioną wadą, ale stanowi błąd w myśleniu lub planowaniu ze strony programisty. Takie błędy logiczne wymagają przeglądu lub przepisania części programu. W ramach przeglądu kodu , przechodzenie przez kod i wyobrażanie sobie lub transkrypcję procesu wykonywania często może znaleźć błędy bez odtworzenia błędu jako takiego.

Bardziej typowo, pierwszym krokiem w zlokalizowaniu błędu jest jego niezawodne odtworzenie. Gdy błąd zostanie odtworzony, programista może użyć debugera lub innego narzędzia podczas odtwarzania błędu, aby znaleźć punkt, w którym program zbłądził.

Niektóre błędy są ujawniane przez dane wejściowe, których odtworzenie może być trudne dla programisty. Jedną z przyczyn śmierci maszyny radiacyjnej Therac-25 był błąd (w szczególności sytuacja wyścigu ), który pojawił się tylko wtedy, gdy operator maszyny bardzo szybko wszedł w plan leczenia; zajęło to kilka dni praktyki, aby móc to zrobić, więc błąd nie pojawił się podczas testów lub gdy producent próbował go powielić. Inne błędy mogą przestać występować za każdym razem, gdy konfiguracja jest rozszerzona, aby pomóc znaleźć błąd, na przykład uruchamianie programu z debuggerem; są to tak zwane heisenbugs (nazwane żartobliwie od zasady nieoznaczoności Heisenberga ).

Od lat 90., szczególnie po katastrofie Ariane 5 Flight 501 , wzrosło zainteresowanie automatycznymi pomocami w debugowaniu, takimi jak statyczna analiza kodu poprzez interpretację abstrakcyjną .

Niektóre klasy błędów nie mają nic wspólnego z kodem. Wadliwa dokumentacja lub sprzęt mogą prowadzić do problemów w korzystaniu z systemu, nawet jeśli kod jest zgodny z dokumentacją. W niektórych przypadkach zmiany w kodzie eliminują problem, mimo że kod nie jest już zgodny z dokumentacją. Systemy wbudowane często omijają błędy sprzętowe, ponieważ stworzenie nowej wersji ROM -u jest znacznie tańsze niż regeneracja sprzętu, zwłaszcza jeśli są to produkty towarowe .

Benchmark błędów

Aby ułatwić powtarzalne badania nad testowaniem i debugowaniem, badacze korzystają z wyselekcjonowanych testów porównawczych błędów:

  • benchmark Siemensa
  • ManyBugs jest testem porównawczym 185 błędów C w dziewięciu programach o otwartym kodzie źródłowym.
  • Defects4J to benchmark 341 błędów Java z 5 projektów open-source. Zawiera odpowiednie łatki, które obejmują różne rodzaje łat.
  • BEARS jest punktem odniesienia dla niepowodzeń kompilacji ciągłej integracji, koncentrując się na niepowodzeniach testów. Został stworzony przez monitorowanie kompilacji z projektów open-source na Travis CI .

Zarządzanie błędami

Zarządzanie błędami obejmuje proces dokumentowania, kategoryzacji, przypisywania, odtwarzania, poprawiania i zwalniania poprawionego kodu. Proponowane zmiany w oprogramowaniu — błędy, prośby o ulepszenia, a nawet całe wydania — są często śledzone i zarządzane za pomocą systemów śledzenia błędów lub systemów śledzenia problemów . Dodawane elementy można nazwać defektami, biletami, problemami lub, zgodnie z paradygmatem zwinnego rozwoju , opowieściami i eposami. Kategorie mogą być obiektywne, subiektywne lub mogą być kombinacją, na przykład numer wersji , obszar oprogramowania, ważność i priorytet, a także rodzaj problemu, na przykład prośba o dodanie funkcji lub błąd.

Przegląd błędów przegląda błędy i decyduje, czy i kiedy je naprawić. Decyzja jest podejmowana na podstawie priorytetu błędu i takich czynników, jak harmonogramy projektów. Selekcja nie ma na celu zbadania przyczyny błędów, ale raczej koszt ich naprawy. Segregacja odbywa się regularnie i przechodzi przez błędy, które zostały otwarte lub ponownie otwarte od poprzedniego spotkania. Uczestnikami procesu selekcji są zazwyczaj kierownik projektu, kierownik rozwoju, kierownik testów, kierownik kompilacji i eksperci techniczni.

Surowość

Istotność to intensywność wpływu błędu na działanie systemu. Może to mieć wpływ na utratę danych, straty finansowe, utratę dobrej woli i zmarnowany wysiłek. Poziomy dotkliwości nie są ustandaryzowane. Oddziaływania różnią się w zależności od branży. Awaria gry wideo ma zupełnie inny wpływ niż awaria przeglądarki internetowej lub systemu monitorowania w czasie rzeczywistym. Na przykład poziomy ważności błędu mogą być następujące: „awaria lub zawieszenie”, „brak obejścia” (co oznacza, że ​​klient nie może wykonać danego zadania), „ma obejście” (co oznacza, że ​​użytkownik może nadal wykonać zadanie), „wizualny defekt” (na przykład brakujący obraz lub przesunięty przycisk lub element formularza) lub „błąd dokumentacji”. Niektórzy wydawcy oprogramowania używają bardziej kwalifikowanych poziomów ważności, takich jak „krytyczny”, „wysoki”, „niski”, „blokujący” lub „trywialny”. Ważność błędu może być osobną kategorią względem jego priorytetu do naprawy, a obie mogą być określane ilościowo i zarządzane oddzielnie.

Priorytet

Kontroluje priorytety , w których błąd pojawia się na liście planowanych zmian. O priorytecie decyduje każdy producent oprogramowania. Priorytety mogą być numeryczne, na przykład od 1 do 5, lub nazwane, na przykład „krytyczny”, „wysoki”, „niski” lub „odroczony”. Te skale ocen mogą być podobne lub nawet identyczne z ocenami istotności , ale są oceniane jako połączenie wagi błędu z szacowanym wysiłkiem naprawczym; błąd o niskiej wadze, ale łatwy do naprawienia, może otrzymać wyższy priorytet niż błąd o średniej wadze, który wymaga nadmiernego wysiłku, aby go naprawić. Oceny priorytetów mogą być dostosowane do wersji produktu, na przykład priorytet „krytyczny” wskazujący wszystkie błędy, które należy naprawić przed kolejną wersją oprogramowania.

Wersje oprogramowania

Powszechną praktyką jest wydawanie oprogramowania ze znanymi błędami o niskim priorytecie. Błędy o odpowiednio wysokim priorytecie mogą gwarantować specjalne wydanie części kodu zawierającej tylko moduły z tymi poprawkami. Są to tak zwane łaty . Większość wydań zawiera mieszankę zmian w zachowaniu i wiele poprawek błędów. Wersje, które kładą nacisk na poprawki błędów, są nazywane wydaniami konserwacyjnymi , aby odróżnić je od głównych wydań, które kładą nacisk na dodatki lub zmiany funkcji.

Powody, dla których wydawca oprogramowania decyduje się nie łatać lub nawet nie naprawiać konkretnego błędu, obejmują:

  • Należy dotrzymać terminu, a zasoby są niewystarczające, aby naprawić wszystkie błędy w terminie.
  • Błąd został już naprawiony w nadchodzącym wydaniu i nie ma wysokiego priorytetu.
  • Zmiany wymagane do naprawienia błędu są zbyt kosztowne lub wpływają na zbyt wiele innych komponentów, co wymaga poważnych działań testowych.
  • Można podejrzewać lub wiadomo, że niektórzy użytkownicy polegają na istniejącym błędnym zachowaniu; proponowana poprawka może wprowadzić przełomową zmianę .
  • Problem tkwi w obszarze, który będzie przestarzały w nadchodzącym wydaniu; naprawianie tego nie jest konieczne.
  • "To nie jest błąd, to jest funkcja". Powstało nieporozumienie między oczekiwanym a postrzeganym zachowaniem lub nieudokumentowaną cechą .

Rodzaje

W projektach rozwoju oprogramowania „błąd” lub „usterka” można wprowadzić na dowolnym etapie. Błędy powstają w wyniku przeoczeń lub nieporozumień popełnionych przez zespół programistów podczas specyfikacji, projektowania, kodowania, wprowadzania danych lub dokumentacji. Na przykład, stosunkowo prosty program do alfabetyzacji listy słów, projekt może nie uwzględniać, co powinno się stać, gdy słowo zawiera myślnik . Lub podczas konwertowania abstrakcyjnego projektu na kod, koder może nieumyślnie utworzyć błąd jeden po drugim i nie posortować ostatniego słowa na liście. Błędy mogą być tak proste, jak błąd w pisowni: „<”, gdzie „>” był przeznaczony.

Inną kategorią błędów jest sytuacja wyścigu, która może wystąpić, gdy programy mają wiele komponentów działających jednocześnie. Jeśli komponenty wchodzą w interakcję w innej kolejności niż zamierzał programista, mogą one ze sobą kolidować i uniemożliwiać programowi wykonanie swoich zadań. Błędy te mogą być trudne do wykrycia lub przewidzenia, ponieważ mogą nie pojawiać się podczas każdego wykonywania programu.

Błędy koncepcyjne to niezrozumienie przez programistę, co oprogramowanie musi zrobić. Powstałe oprogramowanie może działać zgodnie ze zrozumieniem programisty, ale nie tak, jak jest to naprawdę potrzebne. Inne rodzaje:

Arytmetyka

Logika

Składnia

  • Użycie niewłaściwego operatora, na przykład wykonywanie przypisania zamiast testu równości . Na przykład, w niektórych językach x=5 ustawi wartość x na 5, podczas gdy x==5 sprawdzi, czy x wynosi obecnie 5, czy jakaś inna liczba. Interpretowane języki pozwalają na niepowodzenie takiego kodu. Języki kompilowane mogą wykryć takie błędy przed rozpoczęciem testowania.

Ratunek

Wielowątkowość

Interfejs

  • Nieprawidłowe użycie interfejsu API.
  • Nieprawidłowa implementacja protokołu.
  • Nieprawidłowa obsługa sprzętu.
  • Błędne założenia konkretnej platformy.
  • Niekompatybilne systemy. Nowy interfejs API lub protokół komunikacyjny może wydawać się działać, gdy dwa systemy używają różnych wersji, ale mogą wystąpić błędy, gdy funkcja lub funkcja zaimplementowana w jednej wersji zostanie zmieniona lub jej brakuje w innej. W systemach produkcyjnych, które muszą działać w sposób ciągły, wyłączenie całego systemu w celu przeprowadzenia ważnej aktualizacji może nie być możliwe, na przykład w branży telekomunikacyjnej lub w Internecie. W takim przypadku mniejsze segmenty dużego systemu są aktualizowane indywidualnie, aby zminimalizować zakłócenia w dużej sieci. Jednak niektóre sekcje mogą zostać przeoczone i nie zostać zaktualizowane, co może powodować błędy kompatybilności, które mogą być trudne do znalezienia i naprawy.
  • Nieprawidłowe adnotacje w kodzie

Praca zespołowa

  • Niepropagowane aktualizacje; np. programista zmienia "myAdd", ale zapomina zmienić "mySubtract", który używa tego samego algorytmu. Błędy te łagodzi filozofia „ Nie powtarzaj się ”.
  • Komentarze nieaktualne lub niepoprawne: wielu programistów zakłada, że ​​komentarze dokładnie opisują kod.
  • Różnice między dokumentacją a produktem.

Implikacje

Ilość i rodzaj uszkodzeń, jakie może spowodować błąd oprogramowania, w naturalny sposób wpływa na podejmowanie decyzji, procesy i politykę dotyczącą jakości oprogramowania. W zastosowaniach takich jak lot kosmiczny lub bezpieczeństwo samochodowe , ponieważ wady oprogramowania mogą powodować obrażenia, a nawet śmierć, takie oprogramowanie będzie podlegać o wiele dokładniejszej kontroli i kontroli jakości niż na przykład witryna zakupów online. W aplikacjach takich jak bankowość, w których wady oprogramowania mogą potencjalnie spowodować poważne szkody finansowe dla banku lub jego klientów, kontrola jakości jest również ważniejsza niż, powiedzmy, aplikacja do edycji zdjęć. Centrum Technologii Software Assurance NASA zdołało zredukować liczbę błędów do mniej niż 0,1 na 1000 linii kodu ( SLOC ), ale nie uznano tego za wykonalne w przypadku projektów w świecie biznesu.

Według badania NASA „ Flight Software Complexity ”, „wyjątkowo dobry proces tworzenia oprogramowania może ograniczyć defekty do zaledwie 1 defektu na 10 000 linii kodu”.

Oprócz szkód spowodowanych przez błędy, niektóre z ich kosztów wynikają z wysiłku zainwestowanego w ich naprawę. W 1978 roku Lientz i al. pokazały, że mediana projektów inwestuje 17% prac rozwojowych w naprawę błędów. W badaniach w 2020 r. na repozytoriach GitHub wykazano, że mediana wynosi 20%.

Znane błędy

Szereg błędów oprogramowania stało się dobrze znanych, zwykle ze względu na ich powagę: przykłady obejmują różne katastrofy samolotów kosmicznych i wojskowych. Prawdopodobnie najbardziej znanym błędem jest problem roku 2000 , znany również jako błąd Y2K, w którym obawiano się, że światowy załamanie gospodarcze nastąpi na początku 2000 roku, ponieważ komputery myślały, że był rok 1900. (W końcu , nie wystąpiły żadne poważne problemy.) Zakłócenie w handlu akcjami w 2012 r. dotyczyło jednej takiej niezgodności między starym i nowym interfejsem API.

W kulturze popularnej

  • Zarówno w powieści 2001: Odyseja kosmiczna z 1968 r., jak i w odpowiadającym jej filmie 2001: Odyseja kosmiczna z 1968 r. komputer pokładowy statku kosmicznego HAL 9000 usiłuje zabić wszystkich członków jego załogi. W kolejnej powieści z 1982 roku, 2010: Odyssey Two , i towarzyszącym jej filmie z 1984 roku, 2010 , ujawniono, że działanie to zostało spowodowane przez zaprogramowanie komputera na dwa sprzeczne cele: pełne ujawnienie wszystkich informacji i zachowanie prawdziwy cel tajemnicy lotu przed załogą; konflikt ten spowodował, że HAL stał się paranoidalny i ostatecznie zabójczy.
  • W angielskiej wersji piosenki Nena 1983 99 Luftballons (99 Red Balloons) w wyniku „błędów w oprogramowaniu” uwolnienie grupy 99 czerwonych balonów jest mylone z wystrzeleniem wrogiej rakiety jądrowej, co wymaga równoważnej reakcji na wystrzelenie , w wyniku katastrofy.
  • W amerykańskiej komedii Office Space z 1999 roku trzech pracowników próbuje wykorzystać zaangażowanie swojej firmy w naprawę błędu komputerowego Y2K, infekując system komputerowy firmy wirusem, który wysyła zaokrąglone grosze na osobne konto bankowe. Plan przynosi odwrotny skutek, ponieważ sam wirus ma swój własny błąd, który przedwcześnie wysyła duże kwoty pieniędzy na konto.
  • Powieść z 2004 roku The Bug , autorstwa Ellen Ullman , opowiada o próbie znalezienia przez programistę nieuchwytnego błędu w aplikacji bazodanowej.
  • Kanadyjski film Control Alt Delete z 2008 roku opowiada o programiście komputerowym pod koniec 1999 roku, który usiłował naprawić błędy w swojej firmie związane z problemem z 2000 roku.

Zobacz też

Bibliografia

Zewnętrzne linki