összes videóa hét videói

Ocean Sky

összes képa hét képei

Csillagok

eseménynaptár

hírlevél

alapító

Hiba a Mátrixban

Bizonyos dolgokban könnyű meglátni a hibát. Egy hibásan épített út hamar tele lesz kátyúkkal, egy hibásan elkészített torta csúnyán néz ki, egy hibásan készített könyvből kiesnek az oldalak. De vajon mennyire alaposak a programozók? Hogyan veszik észre a hibákat a programjukban? S ha nem veszik észre, akkor milyen problémákat okozhat? Elvesztett műholdak, felrobbant rakéták, lefagyott portálok – mindezek egy-egy egyszerű programhiba miatt.

A Mátrix című film világában az ismétlődő jelenetek a programhibát jelentik. Ezzel Neo a Mátrix első részében legelőször akkor szembesül, amikor a lépcsőházban lát egy nyávogó macskát, majd pár pillanattal később ugyanott van a macska és ugyanúgy nyávog. Ez egy fantasztikus film. Mi a valóságban másképpen találkozunk a programhibákkal. Lefagyott alkalmazások, kifagyott operációs rendszerek, kék képernyők - ezek a leggyakoribb jelek egy Windows-jellegű környezetben. A következmények különbözőek lehetnek: síró tekintetek, amiért elveszett a már több órája írt dokumentum teljes tartalma; dühös mozdulatok, mert kedvenc játékunk megint kidobott; a tehetetlenség érzése, mert eltűnt a már fél órája írt fórumhozzászólásunk. Az, hogy egy-egy weboldal „kidob" a bejelentkezés után, miközben a fórumra vagy az üzenőfalra írunk egy-egy hosszabb hozzászólást, az programtervezési hiba. Az, hogy kifagy a felvi.hu portál a felsőoktatási felvételi jelentkezési határidő napján, szintén programtervezési hiba. Jelen cikkben azonban a programozási hibákra fogunk koncentrálni.

Hiba hiba hátán

Egy egyszerű „Hello világ" típusú program csak pár sorból áll, de egy nagyon nagy program kódja rengeteg különböző fájlból épül fel, bennük különböző függvényekkel, változókkal, objektumokkal és még sok más finomsággal. Nem szeretnék nagyon belemenni a részletekbe, de a fő lépései a programozásnak az alábbiak: tervezés, programozás, tesztelés, hibajavítás. Ha kész a programkód, akkor abból elő kell állítani egy olyan verziót, amit futtatni lehet - ezt a folyamatot hívják fordításnak, ugyanis a programozó által használt nyelvből egy olyan verzió készül, amelyet a programozó már nem tud megérteni, ellenben a számítógépes keretrendszerünk már futtatni tudja. Ennek az eredménye lehet egy futtatható exe fájl, vagy egy Java-alkalmazás, vagy egy weboldal. (Maga a teljes folyamat ennél néhány lépéssel bonyolultabb, de ebbe most ne menjünk bele.) Egy-egy nagyobb programot már elég nehéz átlátni, ráadásul a programozó is ember, és sok hibát vét, miközben írja a programját. A hibák egy részét ő maga is észreveszi, azonban sok hiba benne marad a programban.

A ló meghal, a madarak kirepülnek

A hibáknak nagyon leegyszerűsítve három nagy típusa van. Az első csoportba olyan hibák tartoznak, amelyek miatt nem lehet a programot elindítani. Egyértelmű, hogy ilyenek nem maradhatnak benn a programban, ezt maga a programozó is észreveszi és javítja (mármint normális esetben). A második csoportba olyan hibák tartoznak, amelyek nem akadályozzák meg a program futását, de a program nem azt csinálja, amit elvárunk tőle. Ezek között lehetnek bosszantó hibák (pl. a CD-író programunk ahelyett, hogy írna a CD-re, elkezdi lejátszani a tartalmát) és veszélyes hibák is (a kormányt balra forgatjuk, de a kocsi jobbra kanyarodik). Ezek a hibák csak akkor derülnek ki, ha valakik részletesen végignézik, hogy a program tényleg úgy és olyan módon működik, ahogy az elvárható tőle. Ha egy kisebb programot készítünk, akkor a tesztelést elvégezhetjük egy-két óra alatt, de ha egy nagy rendszert alkottunk meg, akkor a tesztelés hónapokig(!) is eltarthat. Nem véletlen, hogy egyrészt sok cég keres programtesztelőket, másrészt sok cég szeretné, ha lennének különböző automatizált tesztelési programjai. A harmadik csoportba pedig olyan hibák tartoznak, amelyek visszaélésekre adhatnak lehetőséget egy-egy rosszindulatú támadónak. Régen rengeteg weboldal szenvedett ilyen jellegű hibával - ezeket a hibákat kihasználva egy-egy speciális bejegyzést írva az adott weboldal vendégkönyvébe az egész weboldalt haza lehetett vágni.

Amikor fáradt a tesztelő

Az első csoportba tartozó hibákat kijavítja a programozó, a harmadik csoportba tartozó hibákat próbáljuk minimalizálni, de a második csoportban lévők csak akkor derülnek ki, ha az összes funkciót végigtesztelik a programban. Ez rengeteg időt és pénzt jelent, és hatalmas problémát, ha nem végzik el rendesen. 1996. június 4-én ezt első kézből tapasztalhatta meg a Francia Űrügynökség, amikor az Ariane-5 hordozórakéta a felbocsátás után 37 másodperccel felrobbant, 370 millió dolláros vesztességet okozva. A robbanás oka egy egyszerű programozói hiba volt: szakzsargonban szólva egy 64 bites számot a számítógép egy 16 bites számmá próbált meg átalakítani. Mit jelent? Képzeljük el, hogy egy nagy számot akarunk kiírni egy számológép kijelzőjére, amelyen azonban nem fér ki ez a nagy szám, és a számológép nem egy „hiba" üzenetet ír ki, hanem egy véletlenszerű számot jelenít meg. Nos, valami hasonló történt itt is, és egy olyan számot kapott a központi számítógép, amelyet nem lett volna szabad megkapnia. Nem volt mit tennie, felrobbantotta a rakétát, 370 millió dolláros kárt okozva. Soha senki nem tesztelte le rendesen az irányítószoftvert.

De nem csak az európai programozók feledkeznek meg a tesztelésről. A NASA Mars Climate Orbiter nevű űrszondája 1999-ben csapódott be a bolygóba. A tervek szerint 140,5-150 km között kellett volna Mars körüli pályára állni, ehelyett 57 km-es magasságban állt csak neki a manőverhez. Az űrszonda szoftverének egyik rendszere ugyanis az SI mértékegységrendszert használta (metrikus métrékrendszer), a másik rendszere pedig a brit/amerikai mértékegységrendszert (imperial mértékrendszer). Ez egy „apróbb" problémát jelentett az űrszondának, és több mint 300 millió dolláros vesztességet a NASA-nak. A megfelelő tesztelés ebben az esetben is elmaradt.

Programozzatok óvatosan!

Oszd meg: