Hibakeresési eszközök

DeBugMinden projectben eljön a nemes feladat, hogy a semmiből előbukkanó kisebb-nagyobb mértékben bosszantó vagy éppen elviselhetetlen hibákat kezeljük. Szerencsétlenségünkre egy webalkalmazás építgetése során sokféle eredetű hiba felmerülhet. A hibakeresés sokszor nehézkes és néha nehéz még a hiba forrását is megtalálni.

Mit használunk?

Először is nézzük, hogy mit használunk egy webalkalamzás felépítése során és melyik milyen hibákat képes produkálni.

  • (x)html
  • css
  • javascript

(X)html

Eszközök: Firebug, html szerkesztő, validatorok
Általában az oldalunk szerkezetét megadó html nem sok, illetve többnyire könnyen megtalálható hibát okoz. Ezeknek felderítése is többnyire egyszerű, mert szemmel látható, hogy hol a probléma. Ha mondjuk egy egymásba ágyazott listában (ul li ul li) az egyik elem nem oda kerül ahová kellene, akkor könnyen megtalálhatjuk, a hibát, hogy valószínűleg egy elemet nem jó helyen zártunk le. Ezek felderítésében segíthetnek a validatorok. A validatrokkal óvatosnak kell lenni, mert attól, hogy valami nem valid, korántsem biztos, hogy bármiféle problémát is okoz. Legrosszabb esetben én fogom az oldal forrását bemásolom egy szerkesztőbe és elkezdem kézzel betagolni. Időigényes de biztosan célravezető megoldás.

Ha valami ilyen jellegű problémába ütközünk akkor első körben ki kell kapcsolnunk a css-t, hogy lássuk, hogy valóban html vagy inkább css problémáról van-e szó.

Css

Eszközök: Firebug, google, validatorok
Hát igen, a css már sokkal több meglepetést tartogathat a számunkra. Ennek több oka is van. Az egyik, hogy a különböző böngészők, különböző verziók és különböző platformok sokszor teljesen máshogyan valósítják meg a css specifikációt. Az IE persze élen jár a szabványok figyelmen kívül hagyásában.
A másik ok, hogy css-sel több mindent szabályozunk. Az egyik az oldal felépítése, azaz az egyes blokkok elhelyezése. Mármint egy három oszlopos weblap esetében a három oszlop elhelyezése.

Oké, mit tegyünk ha valami nem stimmel css oldalon? Először is nézzük meg több böngészővel. Firefox, Opera és IE első megközelítésben elég lesz. Ezzel már ki tudjuk szűrni, hogy a hiba mindegyikben előjön-e vagy sem. Ha igen, akkor biztosan mi vagyunk a ludasak, ha nem, akkor a magam résézről abból indulok ki, hogy a Firefox jeleníti meg helyesen, és elkezdem a szóban forgó elem css definícióját módosítgatni míg a többi is benyeli. Itt segítségünkre lehetnek az egyes böngészők css bugjainak leírásai (google) illetve a Firebug. A Firebug segítségével könnyen felfedezhetőek az egyes css anomáliák.

Firebug nélkül néha az is segíthet, hogy adunk egy border: thin solid red; definíciót a gyanús elemünknek és látni fogjuk, hogy az elem ténylegesen mekkora helyet foglal, hol helyezkedik el, stb.

JavaScript

Eszközök: Firebug, google
Ha egyáltalán a webalkalmazásunk használ JavaScriptet akkor már igazán kitárul a kapu a hibák előtt. Mind a xhtml, mind a css egy egy egyszerű leíró nyelv, egyszerű feladatok megoldására egyszerű szintaxissal. A JavaScript azonban egy valódi programozási nyelv annak minden előnyével és hátrányával. Itt is előjönnek a különböző böngésző megvalósítások. Fő eszköz itt is a Firebug. Ennek annyi hiányossága van, hogy nem lehet vele kizárólag IE alatt előforduló hibákat megkeresni.

Primitív hibák megtalálására használhatjuk az alert(); függvényt, bonyolultabbaknál pedig célszerű betenni a Firebug-ba egy breakpoint-ot és megnézni, hogy melyik változó mit mutat.

Még mindig nem találom

Első lépésként azt kell feltérképezni, hogy mi is okozza a hibát. Ez rendkívül egyszerűnek hangzik, de sokszor nem is annyira egyszerű megtalálni. Aztán jön a favágó módszer. Fogja az ember a szóban forgó filet és teljesen lecsupaszítjuk. Ha mondjuk css problémánk van akkor szépen kitörlünk belőle mindent. Aztán fogjuk soronként / definíciónként és kezdjük visszapakolni a fileba. Ha szerencsénk van egyszer csak kiugrik a hiba. Ez jó, mert legalább megtaláltuk, hogy mi okozza a hibát. Nekiláthatunk megoldani.

Ha nincs szerencsénk akkor két különböző dolog, mondjuk a css és a javascript, együttes változtatása szükséges a hiba felderítéséhez. Ezek már keményebb diók, itt már mindenféleképpen célszerű valami debuggert használni.

4 thoughts on “Hibakeresési eszközök

  1. Két dolgot ajánlanék még figyelmetekbe:

    Mivel a generált html-ek sorai a legritkább esetben vannak helyesen behúzva, így nehéz megtalálni, ha valamelyik elem rossz helyen van lezárva. Az áttekintést nagyban növelheti ez a html kódszépítő:
    http://tools.arantius.com/tabifier

    Néha a request és response headerekben lehet az ok, amiért az oldal nem úgy néz ki, ahogy (főleg kódolásoknál). Ilyenkor jön jól a fiddler:
    http://www.fiddlertool.com/fiddler/
    vagy csak ff alá a liveHttpHeaders

    hajrá! 🙂

  2. A Firebug szerintem is az egyik legjobb FF kiegészítés a fejlesztők számára (ami a kliens odlalt illeti). Úgy látom, a szerver oldali hibakeresés kimaradt a cikkből, webalkalmazás-fejlesztés során bőven akad ott is hibalehetőség:)

    Mi a cégnél mostanában RSpec-et használunk. BDD szerint megírjuk a teszteket (minden model-re,controller-re,stb) és csak akkor mehet ki az aktuális változat élesbe, ha minden teszt hibátlanul átmegy.
    http://rspec.rubyforge.org/

    Te mit használsz az alkalmazás működésének tesztelésére?

  3. Ferenc: teljesen jogos az észrevétel, de az külön egy (vagy több) bejegyzés lenne. Külön biztonsági szempontból, bővíthetőség, újrahasznosíthatóság és ezer más szempontból.

    Ha szorosan a kimenetre koncentrálok, akkor a szerver oldal html kódot állít elő, szóval ha hibás ott a html részben jelenik meg.

    Kisebb projectek esetében a magam részéről ráeresztem a feleségem (aki abszolút nem ért hozzá), ő szűri ki a user experience hibákat. Érdekes tapasztalat szokott lenni. Aztán meg megpróbálok betörni magamhoz pár alapvető biztonsági teszttel (js beoltás, meg ilyenek). A hibák többnyire úgyis kiugrálnak használat közben.

    Nagyobb project esetében jobb ha egy (sok) külön ember tesztel.

  4. Várom a cikksorozatot.

    A szerver oldal nem csak html kiemenet előállítását jelenti (főleg, ha webalkalmazásokról beszélünk). Egy-egy funkció megvalósítása, művelet elvégzése nincs feltétlenül hatással a megjelenítésre. (pl.: számítások pontosak-e, figyelembe veszik a szükséges kritériumokat, vagy például létre jönnek azok az objektumok futás időben,amiket várunk vagy sem)

    A hibák tényleg előjönnek használat közben (pl.: nincs egy adott objektum -> nem jelenik meg a kimeneten), de nem biztos, hogy észre vesszük őket (pl.: több, komplex feltétel alapján számított kedvezméynes ár).

    Na, a lényeg, hogy ha az ember rászánja az időt a tesztelésre, nagyon sok szívástól kímélheti meg magát.

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöljük.