3. fejezet - Statikus tesztelési technikák

A statikus tesztelési technikák a szoftver forrás kódját vizsgálják fordítási időben. Ide tartozik a dokumentáció felülvizsgálata is. A statikus tesztelés párja a dinamikus tesztelés, amely a szoftvert futásidőben teszteli.

A statikus tesztelési technikáknak két fajtája van:

  1. felülvizsgálat és

  2. statikus elemzés.

A felülvizsgálat a kód, illetve a dokumentáció, vagy ezek együttes manuális átnézését jelenti. Ide tartozik például a páros programozás. A statikus elemzés a kód, illetve a dokumentáció automatikus vizsgálatát jelenti, ahol a statikus elemzést végző segédeszköz megvizsgálja a kódot (illetve a dokumentációt), hogy bizonyos szabályoknak megfelel-e. Ide tartozik például a helyesírás ellenőrzés.

A statikus technikával más típusú hibák találhatóak meg könnyen, mint a dinamikus tesztelési technikákkal. Statikus technikákkal könnyen megtalálhatóak azok a kód sorok, ahol null referencián keresztül akarunk metódust hívni. Ugyanezt elérni dinamikus teszteléssel nagyon költséges, hiszen 100%-os kód lefedettség kell hozzá. Ugyanakkor dinamikus teszteléssel könnyen észrevehető, hogy ha rossz képlet alapján számítjuk pl. az árengedményt. Ugyanezt statikusan nehéz észrevenni, hacsak nincs egy szemfüles vezető programozónk, aki átlátja az üzleti oldalt is.

A statikus tesztelési technikák előnye, hogy nagyon korán alkalmazhatóak, már akkor is, amikor még nincs is futtatható verzió. Így hamarabb lehet velük hibákat találni és így gazdaságosabb a hibajavítás.

3.1. Felülvizsgálat

A felülvizsgálat azt jelenti, hogy manuálisan átnézzük a forráskódot és fejben futtatjuk vagy egyszerűen csak gyanús részeket keresünk benne. Ezzel szemben áll a statikus elemzés, ahol szoftverekkel nézetjük át automatikusan a forráskódot. A felülvizsgálat fehérdobozos teszt, mivel kell hozzá a forráskód. A felülvizsgálat lehet informális, pl. páros programozás, de akár nagyon formális is, amikor a folyamatot jól dokumentáljuk, illetve a két szélsőség közti átmenetek.

Ezeket a hibákat könnyebb felülvizsgálattal megtalálni, mint más technikákkal:

  1. szabványoktól / kódolási szabályoktól való eltérések,

  2. követelményekkel kapcsolatos hibák, pl. nincs minden funkcionális követelményhez funkció,

  3. tervezési hibák, pl. az adatbázis nincs harmadik normál-formában,

  4. karbantarthatóság hiánya, pl. nincs biztonsági mentés és visszaállítás funkció,

  5. hibás interfész-specifikációk, pl. dokumentálatlan feltételezések.

A felülvizsgálat legismertebb típusai:

  1. informális felülvizsgálat (csoporton belüli),

  2. átvizsgálás (házon belüli),

  3. technikai felülvizsgálat (külsős szakérő bevonásával rövid idejű),

  4. inspekció (külsős szakérő bevonásával hosszú idejű).

3.1.1. Informális felülvizsgálat

Sok szoftvercégnél elfogadott megoldás, hogy egy tapasztalt programozó átnézi (review) a kezdők kódját. A kezdők a kritikából rengeteg tapasztalatot szerezhetnek. A kockázatosnak ítélt részeket (pl. amire gyakran kerül a vezérlés, vagy kevésbé ismert megoldást alkalmaz) több tapasztalt programozó is átnézheti. Ennek hatékonysága függ az átnézők rátermettségétől. Ez talán a leginformálisabb megoldás.

Ehhez hasonló a páros programozás (pair programming) is. Ekkor két programozó ír egy kódot, pontosabban az egyik írja, a másik figyeli. Ha a figyelő hibát lát vagy nem érti a kódot, akkor azonnal szól. A két programozó folyamatosan megbeszéli, hogy hogyan érdemes megoldani az adott problémát.

A kódszépítés (refactoring) egy másik módja a felülvizsgálatnak. Ilyenkor a már letesztelt, működő kódot lehet szépíteni, ami esetleg lassú, rugalmatlan, vagy egyszerűen csak csúnya. A kódszépítés előfeltétele, hogy legyen sok unit-teszt. A szépítés során nem szabad megváltoztatni a kód funkcionalitását, de a szerkezet, pl. egy metódus törzse, szabadon változtatható. A szépítés után minden unit-tesztet le kell futtatni, nem csak a megváltozott kódhoz tartozókat, hogy lássuk, a változások okoztak-e hibát. A kódszépítést a szerző és egy tapasztalt programozó végzi közösen.

Az informális felülvizsgálat legfőbb jellemzői:

  1. informális, a fejlesztő csapaton belüli felülvizsgálat,

  2. kezdeményezheti a szerző vagy egy tapasztaltabb fejlesztő, ritkán a menedzsment,

  3. hatékonysága függ az átnéző személyétől, minél tapasztaltabb, annál több hibát vehet észre,

  4. célja a korai költséghatékony hiba felderítés.

3.1.2. Átvizsgálás

Ez már kicsit formálisabb módja a felülvizsgálatnak. Általában a módszertan előírja, hogy az elkészült kisebb-nagyobb modulokat ismertetni kell a csapat többi tagjával, a többi csapattal. Célja, hogy a mások is átlássák az általunk írt kódrészletet (ez csökkenti a kárt, amit egy programozó elvesztése okozhat, lásd kockázat menedzsment), kritikai megjegyzéseikkel segítsék a kód minőségének javítását. Aszerint, hogy hány embernek mutatjuk be az elkészült modult, ezekről beszélhetünk:

  1. váll feletti átnézés (over-the-shoulder review),

  2. forráskód átnézés (code review),

  3. kód átvétel (code acceptance review)

  4. körbeküldés (pass-around),

  5. csoportos átnézés (team review),

  6. felület átnézés (interface review),

  7. kód prezentálás (code presentation).

Váll feletti átnézés (over-the-shoulder review): Az egyik programozó egy ideje nézi saját forráskódját, de nem találja a hibát. Valamelyik kollégáját megkéri, hogy segítsen. Mialatt elmagyarázza a problémát, általában rá is jön a megoldásra. Ha mégsem, akkor a kollégának lehet egy jó ötlete, hogy mi okozhatja a hibát. Általában ennyi elég is a hiba megtalálásához. Ha nem, jöhet a forráskód átnézés.

Forráskód átnézés (code review): A kód írója megkér egy tapasztalt programozót, hogy segítsen megtalálni egy nehezen megtalálható hibát. Együtt nyomkövetik a programot, miközben a szerző magyarázza, mit miért csinált. Ellenőrzik, hogy a kód megfelel-e a specifikációnak. Ezt addig fojtatják, amíg meg nem találják a hibát.

Kód átvétel (code acceptance review): Az elkészült nagyobb modulokat, pl. osztályokat, a vezető fejlesztő vagy egy tapasztalt programozó átnézi, hogy van-e benne hiba, nem érthető, nem dokumentált rész. A modul fejlesztői elmagyarázzák mit és miért csináltak. A vezető fejlesztő elmondja, hogyan lehet ezt jobban, szebben csinálni. Ha hibát talál (ez gyakran logikai hiba), akkor arra rámutat, vázolja a javítást.

Körbeküldés (pass-around): A kód szerzője körbeküldi az általa írt kódrészletet, ami akár egy egész modul is lehet. A címzettek véleményezik a kódot, például megírják, melyik részét érdemes tesztelni. A körbeküldés általában megelőzi a kód felvételét a verziókövető rendszerbe. Általában csak akkor használják, ha egy kódrészlet kritikus fontosságú, pl. egy sokak által használt interfész. Az intenzív kommunikációt előíró módszertanokra (pl. Scrum) nem jellemző.

Csoportos átnézés (team review): A csoportos átnézés a körbeküldést helyettesíti. Itt is egy érzékeny kódrészletet néznek át többen, de interaktívan. A kódot a szerző prezentálja, sorról sorra magyarázza. Általában elvárás, hogy ha valaki valamit nem ért, azonnal szóljon. A prezentáció végén a vezető programozó elmondja, szerinte mit lehetett volna jobban csinálni. Ehhez is gyakran hozzászólnak a többiek. Több módszertan (pl. extrém programozás) limitálja ezen alkalmak időhosszát fél vagy egy órában.

Felület átnézés (interface review): Hasonló a csoportos átnézéshez, de itt általában több embernek mutatjuk be azt az interfészt, amelyen keresztül a csoportunk fejlesztése lesz elérhető. Ez azért fontos, hogy az egyes csoportok egyeztetni tudják elvárásaikat egymás felé. Ezeket rögzítik és az integrációs teszt során felhasználják.

Kód prezentálás (code presentation): Hasonló a csoportos átnézéshez, de az érdekes kódot nem a csoporton belül, hanem a cégen belül mutatjuk be. Akkor gyakori, ha több telephelyen fejlesztik ugyanazt a szoftvert. Nem feltétlenül az egész cég vesz részt benne, lehet, hogy csak három ember, de könnyen előfordulhat, hogy ezek más-más kontinensen vannak. A kód prezentálás célja lehet egy hiba bemutatása, amit egy másik csapat talált és megkéri a kód tulajdonosát, hogy javítsa. Másik gyakori cél a csúcs fejlesztők összehozása, hogy a keretrendszer továbbfejlesztését megbeszéljék.

Az átvizsgálás legfőbb jellemzői:

  1. a moderátor maga a szerző, lehet jegyzőkönyvvezető is, de az nem a szerző,

  2. a résztvevők a cég alkalmazottai, külső szakértők nem jellemzőek,

  3. lehet informális és formális is, ha formális, akkor van pl. jegyzőkönyv,

  4. általában a módszertan írja elő vagy a menedzsment kezdeményezi,

  5. a szerzők jól felkészülnek, pl. szemléltető ábrákat készítenek, a többi résztvevő átnézi a kapcsolódó dokumentációt,

  6. célja az elkészült modulok ismertetése, megértések, azokban hibakeresés.

3.1.3. Technikai felülvizsgálat

Technikai felülvizsgálatra általában akkor kerül sor, ha a szoftver teljesítményével nem vagyunk elégedettek. Azt általában könnyű megtalálni a felhasználói visszajelzések és úgynevezett profiler programok segítségével, hogy mi az a szűk keresztmetszet (angolul: bottleneck), ami a lassúságot okozza. Ugyanakkor az nagyon nehéz kérdés, hogyan oldjuk fel ezeket a szűk keresztmetszeteket. Ha lenne egyszerű megoldás, akkor a programozók eleve azt használták volna, tehát ez általában a szoftver cég alkalmazottainak tudását meghaladó probléma.

Ilyenkor külső szakértőket szoktak felkérni, hogy segítsenek. Leggyakrabban egy-egy lekérdezés bizonyul túl lassúnak. Ilyenkor egy index hozzáadás a táblához nagyságrendekkel gyorsítja a lekérdezést. A kérdés már csak az, mit indexeljünk és hogyan. A külsős szakértők átnézik a megoldásunkat és javaslatokat adnak.

Mivel ez a fajta tanácsadás nagyon drága, ezért ez egy jól dokumentált folyamat. A szoftvercég leírja, hogy mi a probléma. Mind a cég alkalmazottai, mind a szakértők felkészülnek, átnézik a dokumentációkat. A megbeszélést általában egy moderátor vezeti, aki jegyzőkönyvet is ír. A moderátor nem lehet a program írója. A résztvevők megbeszélik, hogy mi a probléma gyökere. A szakértők több megoldási javaslatot is adnak. Kiválasztanak egy megoldást. Ezt vagy a szerző, vagy a szakértők implementálják.

A technikai vizsgálat másik típusa, amikor külső szakértők azt ellenőrzik, hogy a szoftver vagy a dokumentációja megfelel-e az előírt szabványoknak. Az ellenőrzést nem a megrendelő, hanem a szoftver cég vagy a szabvány hitelesítését végző szervezet kezdeményezi. Pl. az emberi életre is veszélyes (life-critical) rendszerek dokumentációjára az IEC61508 szabvány vonatkozik. Ennek betartása a cég érdeke, mert ha kiderül, hogy nem tartja be a szabványt, akkor a termékeit akár ki is vonhatják a piacról.

Akkor is ehhez a technikához fordulnak, ha a szoftverben van egy hiba, amit nagyon nehéz reprodukálni, és a szoftver cég saját alkalmazottai nem tudják megtalálni (megtalálhatatlan hiba). Ez többszálú vagy elosztott rendszereknél fordul általában elő egy holtpont (deadlock) vagy kiéheztetés (starvation) formájában, de lehet ez egy memóriaszivárgás (memory lake) is. Ilyenkor a szakértő megmutatja, hogyan kell azt a statikus elemző szoftvert használni, pl. egy holtpont keresőt (deadlock checker), ami megtalálja a hibás részt. Az így feltárt hibát általában már a cég szakemberei is javítani tudják.

A technikai felülvizsgálat legfőbb jellemzői:

  1. a szoftver cég kezdeményezi, ha külső szakértők bevonására van szüksége,

  2. moderátor vezeti (nem a szerző), jegyzőkönyvet vezet,

  1. inkább formális, mint informális,

  2. a találkozó előtt a résztvevők felkészülnek,

  3. opcionálisan ellenőrző lista használata, amit a felek előre elfogadnak,

  4. célja a megtalálhatatlan hibák felderítése, vagy a szoftver lassúságát okozó szűk keresztmetszetek megszüntetés, vagy szabványok ellenőrzése.

3.1.4. Inspekció

Ez a legformálisabb felülvizsgálat. Ezt is akkor használjuk, ha külső szakértő bevonására van szükségünk. A technikai felülvizsgálattól az különbözteti meg, hogy a szoftver cég és a szakértőt adó cég részletesebb szerződést köt, amely magában foglalja:

  1. a megoldandó feladat leírását,

  2. azt a célfeltételt, ami a probléma megoldásával el kell érni,

  3. a célfeltételben használt metrikák leírását,

  4. az inspekciós jelentés formáját.

Míg a technikai átnézésnél gyakran csak annyit kérünk a szakértőktől, hogy legyen sokkal gyorsabb egy lekérdezés, az inspekció esetén leírjuk pontosan, hogy milyen gyors legyen.

Az inspekció szó abból jön, hogy a probléma megoldásához általában nem elég csak a szoftver egy részét átvizsgálni, hanem az egész forráskódot adatbázissal együtt inspekció alá kell vonni. Inspekciót alkalmazunk akkor is, ha egy régi (esetleg már nem támogatott programozási nyelven íródott) kódot akarunk szépíteni / átírni, hogy ismét rugalmasan lehessen bővíteni.

Az inspektornak nagy tekintélyű szakembernek kell lennie, mert az általa javasolt változtatások általában nagyon fájóak, nehezen kivitelezhetőek. Ha nincs meg a bizalom, hogy ezekkel a változtatásokkal el lehet érni a célt, akkor a fejlesztő csapat ellenállásán elbukhat a kezdeményezés.

Az inspektort általában egy-két hónapig is a fejlesztők rendelkezésére áll szemben a technikai felülvizsgálattal, amikor a szakértők gyorsan, akár néhány óra alatt megoldják a problémát. Ezért ugyanannak a szakértőnek a napidíja általában kisebb inspekció esetén, mint technikai felülvizsgálat esetén.

Az inspekció lehet rövid távú is (egy-két hetes), ha a szakértőre nincs szükség a probléma megoldásához, csak a feltárásához. Ekkor a szakértő egy inspekciós jelentést ír, amely leírja, hogyan kell megoldani a problémát. Ehhez általában csatolni kell egy példa programot is, egy úgynevezett PoC-kot (Proof of Concept), amely alapján a cég saját fejlesztői is képesek megoldani a problémát. A PoC-oknak demonstrálnia kell, hogy a kívánt metrika értékek elérhetőek a segítségével.

Az inspekció legfőbb jellemzői:

  1. a szoftvercég kezdeményezi, ha hosszabb távon van szüksége külső szakértőre,

  2. részletes szerződés szabályozza, ami a problémát, a célfeltételt és célban szereplő metrikákat is leírja,

  3. opcionálisan PoC-ok (Proof of Concept) készítése,

  4. inspekciós jelentés készítése,

  5. célja teljesítmény fokozás a szakértő által kiválóan ismert technológia segítségével vagy elavult kód frissítése.