Számítógépes hiba)
A számítástechnika , a hiba ( ejtsd francia: / b œ g / ) vagy a hiba egy tervezési hiba, egy számítógépes program okozza a meghibásodást .
A meghibásodás súlyossága az enyhe, például kisebb kijelzőhibákat okozhat - ebben az esetben néha " hibáról " beszélünk - egészen a súlyosig, például egy rendszer összeomlásáig , amely például súlyos balesetekhez vezethet. az első Ariane 5 rakéta repülés közbeni megsemmisítése 1996-ban .
A hiba megtalálható egy alkalmazásban , az alkalmazás által használt harmadik féltől származó szoftverben, vagy akár egy hardver-alkatrész firmware-jében is , mint a Pentium részleg hibája esetén . A javítás egy szoftver, amely egy vagy több hiba kijavítására szolgál.
Leírás
A hibák a számítógépes eszközök hibás működésének egyik oka; a meghibásodás egyéb okai a következők:
- Hibák kezelése, számítógépes vírusok - rosszindulatú programok, amelyek a készüléken lévő szoftvereket befolyásolják. Ugyanakkor a hardver kapacitásának túllépése - teljes memória, teljes hálózat, elfoglalt processzor -, valamint az kompatibilitás hiánya , a számítógépes hardver meghibásodása, a konfigurációs paraméterek helytelen értéke és a külső hatások (hőmérsékleti és mágneses mezők ).
- A hiba összeomlást okozhat , vagyis a szoftver váratlan leállítását vagy akár jelentős információvesztést, vagy szélsőséges esetben valódi katasztrófát okozhat (lásd az Ariane 5 rakéta 501. járatának robbanását ). A biztonsági rés egy kisebb hiba, amely nem okoz meghibásodást a mindennapi használat során, de lehetővé teszi egy rosszindulatú felhasználó vagy rosszindulatú program számára, hogy engedély nélküli műveleteket hajtson végre egy kihasználásból .
- A kritikus rendszer olyan számítástechnikai eszköz, amelynek meghibásodása veszélyeztetheti az emberek és az ökoszisztémák egészségét és életét, jelentős anyagi kárt okozhat, vagy visszahat a gazdasági és politikai stabilitásra.
Terminológia
Az angol bug szó a hardvermérnökök szakzsargonjába tartozik, és a benne felmerülő problémákat képviseli. A kifejezés a mechanikai rendszerek hibáinak leírására legalább az 1870-es évek elé nyúlik vissza . A jegyzetekben többek között Thomas Edison használta a szót.
A „hiba” kifejezésre a Larousse online szótárban a következő definícióval hivatkozunk: „Számítógépes program tervezési vagy gyártási hibája, amely a számítógép működési rendellenességeiben nyilvánul meg. "
A francia nyelvű számítógépes kincstár csak a "bug" szót tartja "gesztenye, mogyoró, mogyoró és bizonyos hüvelyes magok fűszeres borítékában".
A FranceTerme webhely , az Office québécois de la langue française és a Direction de la langue française (Belgium) ajánlja a "bug" kifejezést, valamint a derivatívák debug, debug és debugger
A kifejezést néha hamisan Grace Hoppernek tulajdonítják . A Smithsonian Intézetben vezetett karbantartási naplójában kelt1947. szeptember 9, 15 óra 45 perc , egy relé két érintkezõje okozta a Harvard Mark II , az elsõ elektromechanikus számítógépek egyikének meghibásodását .
Hopper nem találta a hibát, ahogy készségesen beismerte. A később megtalált üzemeltetők, köztük William "Bill" Burke, a Tengerészeti Fegyverlaboratórium ismerte a mérnöki kifejezést és szórakoztatták őket, és megtartották a hibát az "első igazi hibát találtak" felirattal.
Ezt a kifejezést gépész- és villamosmérnökök használták, elmagyarázva a berendezésekben tapasztalt nehézségeket, jóval azelőtt, hogy Grace Hopper hallott volna erről a szóról.
Okoz
Frederick Brooks 1987-ben megjelent könyvében azt mondja, hogy a hibák a szoftverekben nem véletlenek, hanem a szoftver természetéből fakadnak, más szóval a szoftverekben vannak hibák, mert azok szoftverek. Azt is mondta, hogy van nincs csodaszer - egy csoda eszköz - foglalkozó hibákat, így utalva a legenda a középkorban , hogy csak a labdát az ezüst , emlékeztet a színe a Hold, akkor kivédjék a vérfarkas .
A szoftver láthatatlan és immateriális termék, módosításához nem szükséges nyersanyag. Az informatikai piac nagyon gyors fejlődése erős igényt támaszt a változások iránt. Mindezek a tényezők sokkal gyakoribbá teszik a szoftveres változásokat, mint más termékekben, például az autóban vagy az épületekben .
A számítógépek a legösszetettebb termékek közé tartoznak, amelyeket az ember gyártott, ezért nagyon sok állapotuk van . A szoftver összetettebb, mint a számítógép, és az autóval ellentétben egyetlen alkatrész sem egyforma. A telekommunikációhoz közeli területekre jellemző számos szabvány betartása növeli azok komplexitását. A szoftver ráadásul láthatatlan termék, amely nem ábrázolható geometriai térben, a szoftver grafikus ábrázolása gyakran két, akár három vagy négy diagramot tartalmaz, amelyek mindegyike más-más valóságnak felel meg.
Következmények
Hibák
A hibák miatt a szoftver megkísérli olyan műveletek végrehajtását, amelyek nem hajthatók végre ( kivételek ): nulla osztás, nem létező információk keresése. Ezek a műveletek - amelyeket soha nem használnak a szoftver megfelelő működése során - mind a hardver, mind a szoftver mechanizmusát elindítják, amely aztán kikapcsolja a hibás szoftvert, ami számítógépes összeomlást vagy szolgáltatásmegtagadást okoz .
Az őrzőkutya egy autonóm elektronikus eszköz, amely a meghibásodások észlelésére szolgál. Ezt a mechanizmust gyakran alkalmazzák kritikus rendszereknél és ipari számítástechnikánál .
A halál kék képernyője a Microsoft Windows operációs rendszerek leállítási üzenetének köznyelve , amely akkor jelenik meg, ha az operációs rendszer magjában kivételt észlel. A Kernel pánik az az üzenet, amely hasonló körülmények között jelenik meg a UNIX operációs rendszereken .
Gyakori meghibásodások
A memóriaszivárgás olyan hiba, amelyet a memóriaelosztási műveletek hibája okoz . Ezzel a meghibásodással a meghibásodott szoftver által használt memória mennyisége folyamatosan növekszik. Ha a hibás szoftvernek sikerül felhasználnia a rendelkezésre álló memória szinte egészét, akkor ez zavarja a többi szoftver előrehaladását és meghibásodást okoz.
A szegmentálási hiba meghibásodás a mutatók vagy memória címek kezelésével kapcsolatos műveletek hibája miatt . A hibás szoftver megpróbál információkat olvasni vagy írni olyan memóriahelyekre ( szegmensekre ), amelyek nem léteznek, vagy amelyek erre nem engedélyezettek. A kivétel felismerési mechanizmusa ekkor a hibás szoftvert megszünteti.
Az egész szám túlcsordulás hibát jelent a matematikai számítási műveletek hibája miatt. A hibás szoftver megpróbál olyan számítást végrehajtani, amelynek eredménye nagyobb, mint a maximálisan engedélyezett érték. A kivétel felismerési mechanizmusa ekkor a hibás szoftvert megszünteti.
A puffer túlcsordulás hibát okoz a hiba miatt. Az a szoftver, amelynek információkat kell írnia egy meghatározott és korlátozott memóriahelyre ( puffermemória ), túllépi a hely határait, majd információkat ír egy másik felhasználásra szánt helyre, ez a váratlan módosítás a szoftver hibás végrehajtásához vezet, amely szegmentálási hibával vagy túlcsordulással zárul. Ez egy általános szerver biztonsági rés , amelyet a hackerek gyakran kihasználnak . lásd Exploit .
A verem túlcsordulás olyan meghibásodás, amelyben a szoftver végrehajtási veremének mérete meghaladja az azt tartalmazó puffer kapacitását , ami a puffer túlcsordulásához hasonló hibákat okoz . A végrehajtási verem a memóriában tárolt adatstruktúra , amely tartalmazza a szoftver automatizmusok állapotát (lásd: folyamat (adatfeldolgozás) ), ezt a struktúrát egy túlméretezett puffermemória rögzíti. A verem túlcsordulása egy hibát követő hibás szekvenciából származik.
A versenyhelyzet (angol versenyhelyzet ) egy hiba miatt bekövetkező meghibásodás, amelynek következtében az egyik kettő szoftver-automatika egyszerre működik, és a másik előtt befejeződő automatizálásnak megfelelően különböző eredményeket ad.
A holtpont (angol holtpont ), amikor a meghibásodás, amelyben számos automatizálási számítunk egymásra, azaz mindketten várják az egyéb kiadások, a források használ a folytatáshoz. Az erőforrások zárva maradnak a várakozások során, ami blokkolhat más automatizmusokat, dominóhatással pedig az egész rendszert. Egy megelőzési mechanizmus a művelet törlését okozza, ha a várakozási idő meghaladja a megengedett időtúllépést .
A hacker folklórban
Minél összetettebb a kód, annál nehezebb megtalálni a hibát. Az előre nem látható és valószínűtlen körülmények kombinációjától függő hibákat különösen nehéz felkutatni. A hacker folklórban vannak olyan furcsa hibák kategóriái, amelyek humoros nevei a kvantumfizika és a matematika kiemelkedő tudósainak nevéből származnak.
- Heisenbug: ( Heisenberg bizonytalansági elvéből kiindulva ) egy hiba, amely eltűnik vagy megváltozik, amikor megpróbálja elszigetelni.
- Mandelbug: ( Mandelbrot beállítja ) olyan hiba, amelynek okai annyira homályosak és összetettek, hogy az eredmény kaotikus és nem determinisztikus viselkedés.
- Schrödinbug: ( Schrödinger macskájától ) egy hiba, amely csak akkor jelentkezik, ha valaki elolvassa a forráskódot, kicsit vagy szokatlan módon használja a programot, és megállapítja, hogy soha nem kellett volna működnie.
- Bohr-hiba: Megismételhető hiba, amely akkor ismétlődik, ha egy adott - még ismeretlen - feltétel is teljesül.
A szoftver lépésről lépésre történő végrehajtása hibakeresővel csak azért okozhatja a Heisenbug programot, mert a szoftver lassabban fut. A versenyhelyzetek pedig Mandelbughoz vezethetnek , ahol a program viselkedése minden egyes végrehajtáskor más és más.
Életciklus
Leírás
A hibák a számítógépes szoftverek és hardverek meghatározásának , tervezésének , programozásának és tesztelésének során elkövetett emberi hibák következményei . A szoftverek növekvő összetettsége, a kommunikációs problémák, a mérnökök képzetének hiánya, valamint a mérnöki munka során jelentkező határidők és költségek nyomása olyan tényezők, amelyek növelik a hibák számát.
A szoftver tesztelése az első lépés a hibák elhárítására. Gyakorlati okokból (a munka költségei és a határidők) nem lehet tesztelni egy szoftvert minden olyan feltétel mellett, amelynek a használata során eleget tudna tenni, és ezért nem lehet minden hibát elhárítani: a Microsoft Word-hez hasonló szoftverek 850 parancsot és 1600 funkciót tartalmaznak , összesen több mint 500 millió tesztelési feltételhez.
Magas szintű programozási nyelvek használata , amelyek megkönnyítik a mérnök munkáját. Az írási konvenciók megvalósítása más megelőző módszer, amelynek célja a hibák számának csökkentése.
A hibakeresés a hibák diagnosztizálása és kijavítása. Az online hibakeresés során a mérnök lépésről lépésre futtatja a szoftvert, és minden lépés után egy sor ellenőrzést hajt végre. A halál utáni hibakeresés során a mérnök számítógépes összeomlást követően megvizsgálja a szoftvert.
Amikor a hibát a szoftver terjesztése után észlelik és kijavítják, a szállító gyakran biztosít egy javítást , vagyis egy készletet, amely a szoftver hibás részeit kicseréli a javítottakkal.
Hibakövető rendszer
A mérnökök gyakran használnak hibakereső rendszert , azaz adatbázis-szoftvert , amelybe beírják a különféle hibákat, valamint az egyes munkákat:
- az a személy (fejlesztő, tesztelő, felhasználó ...), aki lát valamit, ami számára rendellenesnek tűnik, kitölti az űrlapot, aki létrehoz egy bejegyzést az adatbázisban, és számot rendel hozzá;
- majd egy szakértő elemzést végez, és megnézi, hogy valóban hiba vagy hiba-e (például nem egyértelmű kézikönyv, vagy rosszul képzett felhasználó);
- ha lehetséges a javítás (lehet javítás a kódban, valamint a kézikönyvben hozzáadandó pontosság, javítandó specifikáció, javítandó fordítás ...), akkor úgy döntenek, hogy helyesbítenek-e vagy sem, és milyen prioritással. Az elvégzendő munkát általában valakihez rendelik;
- akkor a kijelölt személy foglalkozik a problémával, és jelzi, hogy a probléma megoldódott;
- általában szükséges egy harmadik személy (tesztelő, más fejlesztő, felhasználó ...) megerősítése;
- ha minden jól megy, a probléma megszűnik. Ellenkező esetben a probléma újra megnyílik, és a ciklus újra kezdődik.
Megelőző intézkedések
Számos programozási nyelv tartalmaz mechanizmusokat az üzemzavarok ellenőrzésére. Az utasítások szükséges ellenőrzések automatikusan hozzáadódik a gépi kód vagy a bájtkódot a szoftver alatt összeállítása . Az utasítások a hibakereső , a hibadiagnosztikai szoftver automatikus aktiválását okozhatják .
A kód felülvizsgálatának célja az újonnan kifejlesztett forráskód alávetése egy harmadik személynek, aki újra elolvassa és megkeresi a hibákat.
A szoftver tesztelése az első lépés a hibák kezelésében. Ezek abból állnak, hogy a szoftvert a lehető legtöbb körülmények között használják. A tesztek célja a különböző problémák felderítése:
- a szoftver nem azt teszi, amit kellene;
- a szoftver olyasmit csinál, amit nem kellene;
- a szoftver olyat tesz, amit nem kérnek tőle;
- a szoftver nem azt csinálja, amit kellene (pl. túl lassan).
A teszteket többször megismételjük, mint a fejlett programozást és a javításokat a javítások érvényesítése és az esetleges hibák regressziójának felderítése érdekében : hiba egy másik hiba téves kijavításának eredményeként következett be. A tesztelés automatizálható a felhasználó nevében működő szoftverrel. Előfordul, hogy egy második szoftvert fejlesztenek ki a tesztekhez.
Az egységtesztek célja a szoftver egyedi funkciójának használata a meghibásodások észlelésére. Az integrációs tesztek tartalmazzák a függvények használatát az egész koherenciájának ellenőrzésére. Az ellenőrző teszteknek az egész szoftvert fel kell használniuk a vásárló által megkövetelt alkalmasság felmérésére.
Az egység- és az integrációs teszteket általában a mérnök végzi, míg az érvényesítési teszteket általában a vevő vagy képviselője.
A hibák megelőzésének másik megelőző intézkedése a program működésének formális bizonyítása (vagy matematikai bemutatása), általános módon. Ellentétben azzal a vizsgálattal, amely csak egy adott működési esetet igazol, ez a bizonyíték arra törekszik, hogy a program minden esetben működjön, függetlenül a felhasználás körülményeitől. De minden hivatalos ellenőrzési technika nehézkes és összetett. Abszolút értelemben nem tudjuk, hogyan ellenőrizzük minden esetben a programok megfelelő működését. Másrészt léteznek olyan szoftveralkotási módszerek, amelyek a szoftver létrehozása során elemeket állítanak fel az egyes közbenső lépésekhez való átjutás megfigyelésére egyrészt a szoftver specifikációi vagy specifikációi, másrészt a végső program között. a másik kéz. Ezeknek a megfigyelő elemeknek köszönhetően az ellenőrzések lehetségesek, és a specifikációnak való megfelelés korlátozásai előírhatók és zárolhatók.
Azokon a területeken, ahol egy hiba emberi halált okozna (például a repülésben), nehézkes és összetett módszerekkel igazolják a szoftver hibáinak hiányát a tervezés során. Így eredetileg a párizsi 14-es metró automatikus vezérlőszoftvere Z jelöléssel készült . A végleges változat elkészítéséhez azonban a B módszert alkalmazták. A B-módszert is a legjobb eszköznek tekintik annak biztosítására, hogy egy számítógépes program megfeleljen viselkedésének specifikációinak. Valójában a B módszer használata a program létrehozásához (automatikusan) arra is vezet, hogy matematikailag demonstrálja az így létrehozott program megfelelőségét, ami tehát definíció szerint bizonyított tételgé válik.
A módszer alkalmazásának bonyolultsága azonban olyan többletmunkát okoz, hogy egyetlen programozónak 100-szor hosszabb időre lehet szüksége egy program létrehozásához ezzel a módszerrel, mintha ugyanezt a programot hozta volna létre a hagyományos módon. Ez akkor azt jelenti, hogy százszor többe kerül a program létrehozása ezzel a módszerrel. Ennek eredményeként, a hatékonyság ellenére, ezt a módszert csak nagyon ritkán alkalmazzák, és sok olyan területen van, ahol a hibák emberi halált okozhatnak, és ahol csak hibákkal teli programokat hozunk létre, hagyományos módon, majd nagyon szigorú teszteket végezünk megszünteti annak nagy részét. Amíg a hiba valószínűsége, hogy az embereket megölő meghibásodás létrejön, alacsonyabb, mint annak valószínűsége, hogy az emberi tévedés ugyanolyan meghibásodást okoz, addig ezt gyakran "elfogadhatónak" tekintik. (És elfogadhatatlannak minősül a B. módszer alkalmazásának annak biztosítása, hogy senki ne haljon meg).
Hibakeresés
A mérnökök hibakereséshez , hibák felkutatásához és kijavításához szoftvereket, a hibakeresőt , valamint hibakövető rendszert használnak .
A hibakereső rendszert a hibakeresési munka koordinálására használják, az összes megfigyelt meghibásodás összegyűjtésére, az okok és a végrehajtott korrekciós műveletek rögzítésére és így a javítások előrehaladásának figyelemmel kísérésére szolgál. Az okok lehetnek hibák, de a konfigurációs paraméterek hibái vagy a kezelési hibák is. A hibakövető rendszert a hibás szoftver felhasználói, valamint mérnökök vagy rendszergazdák használják .
A hibakereső lehetővé teszi egy szoftver futtatási állapotának elemzését egy adott pillanatban, a folyamatban lévő műveleteket, a memóriában lévő információkat, a megnyitott fájlokat stb. Egy internetes debugger , akkor lehetséges, hogy függessze fel az olyan szoftver bármikor, elemzi az állam, majd tovább feldolgozásra.
A post mortem hibakeresővel elemezni lehet a szoftver futtatásának állapotát összeomlás után. Az elemzés egy fájl alapján történik, amely tartalmazza a memória tartalmának másolatát az összeomláskor. Core dump nevű fájl a Unix operációs rendszereken .
A korrekció után
A szoftververzió a szoftver állapota egy adott napon, beleértve az összes javítást és fejlesztést, amelyeket az adott dátumig végrehajtottak. Alfa vagy béta verzióról van szó, ha megfelel a szoftver állapotának a tesztek időtartama előtt. Egy ilyen verzió valószínűleg hibákat tartalmaz, amelyeket időközben észleltek és kijavítottak.
Miután egy vagy több hibát kijavítottak, azokat egy javításba csoportosítják , egy olyan készletbe, amely csak a javított szoftver-összetevőket tartalmazza. Bárki használhatja, aki a szoftver egy példányával rendelkezik, hogy javításokat hajtson végre rajta, és hozzáigazítsa egy adott verzióhoz.
Néhány híres hiba
Az asztronautikában
Az Ariane 5 rakéta 1996-os kezdeti repülésének meghibásodását a rakéta repüléstechnikai eszközeinek, az Ariane 4 rakétán évek óta sikeresen használt eszközöknek a hibája okozta . A felszállás során az a számítógépes eszköz, amely a rakéta helyzetét a gyorsulása alapján számította ki, nem támogatta az Ariane 5 gyorsulásait, ötször erősebbek, mint az Ariane 4 sebességei. Egy egész szám túllövése okozta a számítógép összeomlását. Vakon az autopilóta elvesztette az irányítást a rakéta felett, és egy biztonsági eszköz miatt néhány másodperccel a felszállás után önpusztított. Ez a történelem egyik legdrágább számítógépes hibája.
1962-ben a Mariner 1 misszió hasonló eseményt élt át.
Orvosi területen
Az 1980-as években a PDP-11 vezérelt sugárterápiás gép , a Therac-25 szoftverhibájának tragikus következményei voltak, a betegek hatalmas dózisú sugárzást kaptak, és legalább öten meghaltak.
2000. évi hiba
A 2000- bogár , más néven a millennium bug : egy vagy több hibát a szoftver, amely manipulálja dátumokat üzemzavart okozhat, ha a dátumok után 1999. december 31 Ennek egyik oka az, hogy a számításokat végeztünk a dátumokat. Csak az utolsó az év két számjegye .
A potenciális problémákra, amelyek az időpont december 31. és 1999 első hárították Bob Berner 1971-ben Ők váltott ki jelentős mobilizálását szoftverfejlesztés vállalatok egy néhány évvel a határidő előtt, és a teljes költség az ellenőrzés és ellenőrzési munkát. Megelőző karbantartás van becslések szerint meghaladja a 600 millió dollárt.
2002-ben a michigani Szent Mária Irgalmas Kórház számítógépes rendszere tévesen 8500, valójában még életben lévő beteg halálát jelentette be, otthonaiknak számlát és halálos nyilatkozatot küldve, valamint bejelentést. Haláluktól a biztosítótársaságig és Amerikai társadalombiztosítás. Hetekbe telt, mire ezeket a halálokat a különféle adminisztrációkkal törölték.
Formális megközelítés: formális módszerek
A hiba lehet:
- a rendszer specifikációjának (azaz annak a meghatározásának a meghatározása, amelyet a rendszernek el kell végeznie) elmulasztása ;
- váratlan viselkedés, amelyre nem terjed ki a specifikáció (például két ellentmondásos cselekvés előre nem látható esete, amelyekkel egyszerre kell foglalkozni, a 2000. évi hiba esete ).
A specifikáció lehet informális és homályos (például: "a szoftver egy szövegszerkesztő, amely nem okoz futásidejű hibákat"), vagy formális és pontos ("a sort ( t ) a t permutációja, például a sort ( t ) a kapcsolat <»), beleértve a matematikai képletek megszerzésének pontját is. A lehető legteljesebb specifikációt feltételezve egy hibás program az, amelynek megvalósítása nem felel meg ennek a specifikációnak.
Kérdéses, hogy léteznek-e univerzális, hibátlan és automatikus módszerek, amelyeket csak követni kellene, hogy rájöjjön, egy program hibás-e vagy sem. A válasz nem. Valóban, ha létezne ilyen módszer, akkor számítógéppel, azaz elemző szoftverrel lehetne automatizálni. Ennek az elemzőnek működnie kell minden elemzendő programon, és válaszolnia kell például a következő kérdésre: "Lehet-e a program végső állapota hibás állapot futás közben, vagy szükségszerűen állapot?" Helyes (vagy nem felmondás) ”. Rice tétele azonban azt mondja, hogy erre a kérdésre nem lehet végtelen államrendszerben választ adni. Általánosságban elmondható, hogy a program végső állapotával kapcsolatos bármely specifikációs kérdés eldönthetetlen , vagyis hogy egy szoftver vagy egy automatikus módszer nem válaszolhat rá, kivéve azokat a kérdéseket, amelyekre a válasz mindig igaz vagy mindig hamis.
Lehet kifogásolni, hogy a számítógépek véges állapotú rendszerek: minden számítógépnek véges memóriája van. A nagyon kicsi rendszerek kivételével azonban a számítógépeket korlátlan memóriarendszerként kell elemezni. Valójában az állapot végességét alkalmazó elemzési technikák többé-kevésbé körforgalomban vagy optimalizált módon a rendszer állapotainak felsorolására törekszenek. Az n memóriabitű rendszernek 2 n állapota van; egy jelenlegi személyi számítógépen n értéke 238 . Ezért láthatjuk, hogy minden kísérlet a rendszer állapotainak felsorolására kudarcra van ítélve.
A hibák általános univerzális automatikus keresésének lehetetlensége ezért alapvető probléma, és nem korlátozza a jelenlegi technológiát.
Hogyan lehet megszabadulni tőle?
A szoftverfejlesztő ipar nagy erőfeszítéseket keres a hibákhoz vezető programozói hibák megelőzésére szolgáló módszerek megtalálásában.
- "A legbiztonságosabb kódsor a világon az, amelyet nem írsz!" »: Keresse az egyszerűséget és egyszerűsítést, következetességet, a kód vagy a bevált könyvtárak újrafelhasználását, majd dolgozzon ki kódolási szabályokat és egyértelmű névadási házirendet.
- Programozási szabályok . Az írási stílus egységességét előírjuk (csökkenti az esetleges zavart a többi fejlesztő számára) és a részletes dokumentáció megírását. A programok megírásához általában formalizált folyamatot kell követni, egymást követő és dokumentált lépésekben.
- Programozási technikák . A hiba néha inkonzisztenciákat okozhat a futó program belső adataiban. Programokat lehet írni, hogy ellenőrizzék a belső adatok konzisztenciáját a végrehajtás során. Ha problémát talál, a szoftver azonnal leállhat, így a hiba megtalálható és kijavítható, vagy csak figyelmezteti a felhasználót, próbálja kijavítani az ellentmondást, és futtassa tovább. Ezenkívül meg lehet tiltani vagy legalább szigorúan szabályozni a programozási nyelv vagy a rendszer finom kezelésének funkcióit.
- Fejlesztési módszertanok . Számos módszer létezik a programozók tevékenységének kezelésére a hibák kockázatának minimalizálása érdekében. Ezen technikák közül több a szoftverfejlesztés szakterületén belül található .
- A programozási nyelvek támogatása . A nyelvek tartalmazhatnak olyan funkciókat, amelyek kivételes kezelésként segítik a programozókat a hibák kezelésében . Ezenkívül számos újabb nyelv szándékosan kizárta azokat a speciális funkciókat, amelyek hibához vezethetnek. Például a Java és a Perl nyelvek nem biztosítanak alacsony szintű hozzáférést a mutatókhoz , ez megakadályozza, hogy egy program véletlenül hozzáférjen a memória egy területéhez.
- A teszt . A szoftvert különféle konfigurációkban tesztelik, beleértve a bonyolult és "extrém" konfigurációkat is. Megpróbáljuk lefedni a szoftver összes funkcióját, vagy minden kódrészét, vagy a kód összes útját (ez utóbbi kritérium általában nem teljesíthető). A teszt azonban nem minden esetben nyújt biztosítékot a szoftver megfelelő működésére vonatkozóan, mert csak korlátozott számú rendszerkonfigurációt, felhasználói bemenetet vagy a külvilágot vesz figyelembe ...
- A formális módszerek . Itt a kérdés a szoftver megfelelő működésének matematikai értelemben vett bizonyítékának elérése. A módszer többé-kevésbé automatizálást tud biztosítani: a bizonyítási asszisztensek segítenek a felhasználónak matematikai bizonyíték megfogalmazásában és ellenőrzésében; a modellellenőrzés és az absztrakt értelmezéssel végzett statikus elemzés automatikus; vannak köztes fokozatok. Ilyen például a B módszer , amelyet a párizsi metró 14. vonalához ( Meteor ) használnak .
Megkeresése és kijavítani a hibákat, vagy hibakeresés , az egyik legfontosabb része a szoftver programozás . Maurice Vincent Wilkes, a számítógéppiac úttörője leírja 1940-es éveiben elért eredményeit, mondván, hogy élete hátralévő részének hibáinak javítása a saját programjaiban fog telni. Ahogy a számítógépes programok egyre bonyolultabbá válnak, a hibák egyre gyakoribbá és nehezebben javíthatóvá válnak. Néha a programozók több időt és erőfeszítést fordítanak a hibák felkutatására és javítására, mint új kód írása.
Általában a hibakeresés legnehezebb része a kód hibát okozó részének megtalálása. Miután megtalálta, annak kijavítása gyakran könnyű. Programok úgynevezett debuggers létezik, hogy segítsen megtalálni a hibákat programozók. A hiba megtalálása azonban még egy hibakereső segítségével is nagyon nehéz feladat.
A hiba felkutatásának első lépése általában az, hogy megtalálja a módját annak egyszerű reprodukálására. Miután a hiba reprodukálódott, a programozó a hibakeresővel vagy más eszközzel megfigyelheti a program végrehajtását a szokásos kontextusában, és esetleg megtalálhatja a problémát. Másrészt nem mindig könnyű reprodukálni a hibát. Némelyiket a szoftver bevitele okozza, amelyet a programozó nehezen tud reprodukálni. Mások eltűnhetnek, amikor a program egy hibakeresőben elindul ; ezeket nevezzük heisenbugoknak (tréfásan Heisenberg bizonytalansági elvére utalva ). Végül a párhuzamos programok hibáit (amelyek több, egyidejűleg futó modulból állnak, például több processzoron) gyakran nehéz megismételni, ha azok a gép számításainak pontos ütemezésétől függenek.
Humor és a hibákhoz kapcsolódó híres idézetek
- „Ez nem hiba, hanem dokumentálatlan funkció! ( Ez nem hiba, hanem dokumentálatlan funkció ). "
- „ Minden nem triviális programnak van legalább egy hibája . "
- „A tévedés emberi, de egy igazi katasztrófához számítógépre van szükség. "
- „Ha a szoftvernek nincs több hibája, általában elavult. "
Videojátékokban
A bug kifejezés a videojátékokban elsődlegesen hibát jelent a cselekvés feltételezett menetében. A hiba végeredménye nem okoz ugyanolyan kényelmetlenséget, annak intenzitásától függően. Egy FPS-ben falat áttörő játékos keze nem lesz ugyanolyan kellemetlenség, mint képtelenség teljesíteni egy szerepjáték fő küldetését .
A hibák megléte nemcsak negatív pontokat hoz:
- a bizonyított hibák kutatása és kijavítása gyakran lehetővé teszi más, eddig ismeretlen hibák kijavítását és / vagy a forráskód optimalizálását , ami nagyon előnyös a játékos (javított játékmenet) és a fejlesztő számára (a játék rendszeres technikai támogatása a hírnév garanciája);
- a hibákat is tartalmazó játék kivételes népszerűsége gyakran egy nagyon termékeny közösség kezdeményezője, amely képes ezeket a hibákat különböző eszközökkel kijavítani. Ennek a jelenségnek a legszimbolikusabb játéka minden bizonnyal a Fallout 2 ;
- egyes hibák hasznosak lehetnek többé-kevésbé rossz szándékú játékosok számára. A hálózaton (az interneten vagy a helyi hálózaton) játszható játékokban a kihasználható hibák kettősek: vagy a fair play megsemmisítésének forrása (különösen az első személyű lövöldözőknél ), vagy pedig látványos játékot tesznek lehetővé. előre léphet, és például a tény hasonló lehet a csaláshoz;
- a Speedrun versenyeken néhány hiba nagyon nyereséges ahhoz, hogy a játékot vagy a sorozatokat a lehető leggyorsabban befejezzük.
- A Goat Simulator játékot fejlesztői "hibákkal telinek" tartják, csak azokat a játékokat törölték el, amelyek hozzájárultak a népszerűségéhez.
A bug kifejezés magában foglalja a bug név népszerűsége miatt kevésbé használt fogalmakat is . Bölcs dolog lenne néhány hibát inkább "elfelejteni", nem pedig hibával nevezni.
Megjegyzések és hivatkozások
Megjegyzések
- kiejtés európai francia nyelven, fonemikusan átírva, az API szabvány szerint .
- Ajánlott Franciaország által Általános küldöttség a francia nyelv és a nyelvek Franciaország (DGLFLF), Kanadában és Belgiumban. Lásd a terminológia szakaszt .
- processzor korai verzióit érintő hiba.
- A kezdete a cselekmény a film Brazíliában egy illusztráció e anekdota: egy rovar okoz rövidzárlat egy gép, átalakítja a név Tuttle be Buttle ; itt a hiba frissíti a bürokrácia túlzásait.
- kevésbé elterjedt helyesírások a hibakeresés , a hibakeresés vagy akár a hibakeresés is .
- Lásd a dokumentáció nélküli tulajdonság ( cikk ) cikkét, a kifejezés eredetére vonatkozó feltételezéseket.
Hivatkozások
- Edison Puskáshoz, 1878. november 13Edison-dokumentumok, Edison Nemzeti Laboratórium, US National Park Service, West Orange, NJ, idézett (in) Thomas Hughes , American Genesis: A Century of Invention and Technological Enthusias, 1870-1970 , New York, Penguin Books,1990, 529 p. ( ISBN 978-0-14-009741-2 , OCLC 20318685 ) , p. 75.
- " bug " , Larousse szótár (hozzáférés : 2017. január 31. ) .
- A „hiba” lexikográfiai és etimológiai meghatározása a számítógépes francia nyelvű kincstárban , a Nemzeti Szöveges és Lexikai Források Központjának honlapján
- Commission for the Enrichment of the French Language , " bogue " , FranceTerme , Kulturális Minisztérium (hozzáférés : 2017. január 31. ) .
- " bug " , Le Grand Dictionnaire terminologique , Office québécois de la langue française (hozzáférés : 2020. október 26. ) .
- Direction de la langue française, " Bogue " , a franca.cfwb.be webhelyen (megtekintve : 2020. október 26. ) .
- " Log Book With Computer Bug " , az Amerikai Történeti Múzeumban (hozzáférés : 2017. március 10. ) .
- „ bug ” , a catb.org címen (elérhető : 2017. március 10. ) .
- "BYTE.com" (2008. január 6-i verzió az Internetes Archívumban ) ,2008. január 6.
- (in) "Az első hiba" (2008. január 6-i verzió az Internet Archívumban ) , a BYTE.com oldalon ,1994. április.
- Laurence Gardner, A gyűrű urainak királysága: a grál keresésének mítoszai és varázsa ,2012, 383 p. ( ISBN 978-2-84454-195-6 ).
- (en) ÉNy Heap et al. , Informatika és társadalom: olvasó , London Thousand Oaks, Kalifornia, Sage Publications az Open University-vel közösen,1995, 436 p. ( ISBN 978-0-8039-7981-9 , OCLC 32666928 , online előadás ).
- (in) Guy Hart-Davis, Mastering Microsoft VBA , Hoboken, NJ, Wiley,2005, 2 nd ed. , 707 p. ( ISBN 978-1-4294-6784-1 és 978-0-471-79064-8 , OCLC 124065945 , online olvasható ).
- (en) Andreas Zeller , Miért sikertelenek a programok: Útmutató a szisztematikus hibakereséshez , Amszterdam / Boston, Morgan Kaufmann,2009( ISBN 978-0-12-374515-6 , online olvasás ).
- (a) Jon Shemitz , .NET 2.0 Delphi programozók , Apress,2006, 544 p. ( ISBN 978-1-59059-386-8 , online olvasás ).
- Debasis Pradhan : „ A 10 legfontosabb ok, amiért vannak hibák / hibák a szoftverben! » (Hozzáférés : 2019. június 11. )
- „ Szoftverhiba anatómiája - Buggin 'My Life Away ", a blogs.msdn.microsoft.com címen (hozzáférés : 2019. június 11. )
- (in) " Alapvető szoftver-tesztelési koncepciók " .
- Lásd: A B módszer megvalósítása .
- " 29 számítógépes hiba katasztrofális következményekkel " , a Rocket Project-en ,2016. december 5(megtekintve : 2019. június 11. )
- Simson Garfinkel , „A történelem legrosszabb szoftverhibái ”, vezetékes ,2005. november 8( ISSN 1059-1028 , online olvasás , hozzáférés : 2019. június 11. )
- http://sunnyday.mit.edu/papers/therac.pdf
- Baura, Gail D. , Mérnöki etika: ipari perspektíva , Elsevier Academic Press,2006( ISBN 0-08-045802-5 , 9780080458021 és 012088531X , OCLC 76822524 , online olvasás )
- (in) " Hozzáférés ára millennium bug " a Stanford ,98. június 5.
- (in) " Kórház feléledő" Dead "Betegek " on Baselinemag
Lásd is
Bibliográfia
- Jean-Louis Boulanger , A B módszer megvalósítása: A Meteor biztonsági szoftver hivatalos fejlesztése ,2013( online olvasás )
Kapcsolódó cikkek
- Glitch ésExploit
- 2000. évi hiba , ami inkább tervezési hiba volt, mint programozási hiba.
- 2038-as hiba, hasonlóan a 2000-es hibához, és megzavarhatja a 32 bites számítógépeket és az összes ezzel a rendszergenerációval kapcsolatos szoftver- vagy fájlformátumot.
- A halál kék képernyője
- Rendszer hiba
- Abend
- Szoftverfejlesztés
- Hibakereső
- A Therac-25 sugárterápiás gép legalább hat balesetet szenvedett egy hiba miatt.
- Murphy törvénye
- Automatikus hibakeresés
- Hibakövető rendszer
Lásd még a kategóriát Szoftverfejlesztés
