10. fejezet - Adatbázisok tesztelése

10.1. Adatbázis tesztelés sajátosságai

Az adatbázis rendszer központi eleme a perzisztens adattároláson alapuló szoftver rendszereknek. Az adatok rendszerint egy logikailag egységesnek tekinthető adatbázisban tárolódnak, ahol a perzisztencia mellett számos további szolgáltatást is rendelkezésre áll. Az adatbázisban tárolt adatokat az adatbázis kezelő rendszerek (DBMS) felügyelik, a DBMS vezérli az adatbázishoz történő kapcsolódásokat és adatműveleteket. Az adatbázis rendszer használata a következő előnyöket biztosítja a felhasználók, a kliens alkalmazások számára:

  • persziztencia

  • centralizáltság

  • szabályozott redundancia

  • integritási elemek érvényesítése

  • mezőszintű adatkezelési függetlenség

  • adathozzáférés magas szintű védelme

  • rugalmas séma kialakítás

  • műveleti elemek, eljárások és függvények adatbázis objektumként történő tárolása és végrehajtása

  • a statikus adatok mellett aktív szabályok támogatása

  • hatékony adatkezelést támogató végrehajtó motor alkalmazása

  • konkurens hozzáférések szinkronizált végrehajtása

Mint látható, az adatbázis rendszerek több modult foglalnak magukba, hiszen tartalmaznak adattároló funkciókat, erőforrás menedzselő funkciókat és programkód végrehajtó funkciókat is egy egységben. Emiatt szokás az adatbázisok tesztelését öszetettebb feladatnak tekinteni, mely a már megismert szoftver tesztelési mechanizmusok integrálására épül.

Az adatbázis tesztelése azonban legalább ugyanolyan fontos lépés a szoftverrendszerek fejlesztése során, mint az alkalmazások kódjának tesztelése, hiszen az adatbázis jelenti az alkalmazások információ forrását. Ezen függőség miatt a rossz adatbázis működés kihat az egész alkalmazásra. Mivel a fejlesztés során az alkalmazási kód az adatbázis sémára épül, ezért a séma módosítás költsége nagyságrenddel nagyobb értékű, mint a kód javításának költsége. Egy 1990-es Oracle felmérés szerint az alábbi költségvonzattal bírnak az egyes hibatípusok:

hibás hardver relatív költsége: 15% és relatív gyakorisága: 3%
hibásan működő OS relatív költsége: 15% és relatív gyakorisága: 5%
hibásan működő DBMS relatív költsége: 10% és relatív gyakorisága: 5%
hibás adatbázis séma relatív költsége: 45% és relatív gyakorisága: 15%
hibásan működő alkalmazási program relatív költsége: 15% és relatív gyakorisága: 72%

Az alkalmazás szempontjából alapvető fontosságú tehát, hogy olyan adatbázis valósuljon meg, amely helyesen és hatékonyan működik, s lehetővé teszi a séma rugalmas és biztonságos módosítását. Az adatbázis tesztelés összetettségét jól jellemzi az a tény, hogy ilyenkor nem pusztán az adatbázis saját belső minőségét kell vizsgálni, hanem a rá épülő alkalmazások működését is. Az alkalmazások ugyanis függő kapcsolatban állnak az adatbázissal. Az adatbázis tesztelésénél áttételesen az alkalmazások tesztelését is érintő elemeket is végre kell hajtani.

A fenti igényeknek megfelelően az adatbázisok vonatkozásában többféle teszt végrehajtására is szükség lehet. Az adatbázis tesztelésnek is alapvetően kétféle módja lehet: fekete doboz (black box) vagy átlátszó doboz (clear box) megközelítés. A black box mód esetén nem foglalkozunk az adatbázis belső objektumaival, csak az adatbázisból kinyert adat értékeket vizsgáljuk, azaz azt teszteljük egy megadott kérdésre az elvárt válasz jön-e vagy sem. Ez ugyan egyszerűbb tesztelési eszközöket és ismeretek kíván, viszont rendszerint nagyobb időköltséggel jár és kevesebb belső részlet fedhető le vele. Ennek oka, hogy a tesztesetek nem fedik le a teljes állapotteret, öszetettt bemenő adatok esetén nem tér ki a teszt minden lehetséges esetre. A clear box megközelítésben az adatbázis objektumok kódját is elérjük és azok kódján hajtódnak végre a tesztek. Mivel ekkor az egyes egységek tesztelésénél jelentősen kisebb állapottérrel lehet dolgozni, nagyobb az esélye, hogy lefedettebb lesz a tesztelés is. Ezen módszer viszont az egyes objektumok kódolásnak és működésének alapos ismeretét igényli.

Az adatbázis tesztelés másik megközelítés módja az adatkezelési igények oldaláról modularizálja a tesztelés folyamatát, azaz ekkor az egyes kritériumok teljesülését ellenőrizzük, egy tesztben rendszerint egy szempontra figyelve. E módszer fő előnye, hogy cél specifikus tesztelési eszközök és módszertanok alkalmazhatók és segítségével jóval nagyobb lefedettség érhető el. Az adatbázisoknál az alábbi tesztelési területek különíthetők el:

Adatbázis séma teszt (Schema test)

A séma ellenőrzésének fő célja kideríteni, hogy a sémában minden igényelt információelem benne van-e és az egyes elemek egyértelműen azonosíthatók-e. A sématervezése során hibát okoz, ha kimaradnak egyes adatelemek vagy egy adatelemet többféle értelmezésben is felhasználnak. A séma változását követően szokás tesztelni, hogy nem kerültek-e ki véletlenül olyan elemek, melyekre még élnek a hivatkozások az alkalmazásokban.

Funkcionalitási teszt (Feature test)

A funkcionalitás tesztnél elsősorban az adatbázisban tárolt eljárások, aktív elemek viselkedését tesztelik. Ennek során ellenőrizni kell, hogy a minden üzleti funkcióhoz létezik-e aktív elem és a meghívott modulok a helyes eredményt adják-e és nem okoznak-e nem tervezett mellékhatásokat. A funkcionalitási teszt mechanizmusa áll legközelebb a hagyományos programozási nyelvek tesztelési módszertanához, hiszen itt is kódegységeket kell tesztelni.

Adatintegritási teszt (Integrity test)

Az adatok integritási tesztjében ellenőrizni kell, hogy a megadott integritási feltételek megfelelnek-e az üzleti modellben megadott szabályoknak és ezen szabályok valóban érvényesülnek-e., Adatbázis szinten az integritási elemek közé tartoznak a PRMARY KEY feltételek, az egyed hivatkozási szabályok, a NOT NULL , UNIQUE és CHECK megkötések valamint a DEFAULT opciók.

Védelmi teszt (Security test)

A védelmi teszt során vizsgálni kell, hogy az egyes adatokhoz való hozzáférés megfelel-e az üzleti szabályoknak és az adatbázisban definiált védelmi elemek megfelelően működnek-e.

Terhelési teszt (Load test)

A terhelési teszt során ellenőrzésre kerül, hogy az adatbázis tervezett architektúrája teljesíteni tudja-e a terhelésre vonatkozó elvárásokat. A terhelési teszt során a megadott adatmennyiség betöltését, mentését ellenőrzik, illetve megnézik a megadott számú konkurrens kérés feldolgozása az elvárt válaszidőn belül lefut-e.

Hatékonysági teszt (Query cost test)

A teljesítmény teszt célja a válaszidők ellenőrzése a fontosabb és gyakoribb lekérdezések esetén. Mivel a lekérdezési hatékonyság javítása, a művelet optimalizálás összetett adatbázis módosításokat igényelhet.

A tesztelés egy további osztályozási alternatívája a tipikus adatbázis fejlesztési és karbantartási műveletekhez kötődő tevékenységek szerinti csoportosítás. Az adatbázis életében többször is előfordulhat, hogy olyan változások következnek be, melyek az adatbázis újbóli tesztelést igényli. A fontosabb tevékenység csoportok:

Új információ elem tesztelése

Az egyik leggyakoribb tesztelési feladat az új információ elemek beviteléhez illetve a létező információ elemek átrendezéséhez kapcsolódik. Mivel az adatbázis egy hosszabb időre szóló adatstruktúrát jelent, használata során az üzleti modell nagy valószínűséggel megváltozik. A változás jelentheti új igények megjelenését, igények módosulását és megszűnését. Mindegyik esetben az adatbázis séma is megváltozik. A séma módosulásakor a tesztek az új, módosult elemre vonatkozó teszteket jelentenek. Ezen egyedi tesztek kidolgozása az egyszerűbb feladatok közé tartozik, hiszen lokalizáltabb a vizsgálandó terület, jól körülhatárolható ez érintett adatelemek köre.

Regressziós teszt változás után

A regressziós teszt a korábban már ellenőrzött tesztek ismételt lefuttatását jelenti. Mivel egy adatbázis elem változása kihathat a többi adatbázis elemre, ezért a módosítás után célszerű ellenőrizni, hogy nem okozott-e sérülést a módosítás a korábban már működő funkciók tekintetében.

Telepítlési teszt

A sémába vagy a funkcionalitási listába kerülő új elemeknél ellenőrizni kell, hogy azok megfelelnek-e a tervekben szereplő előírásoknak, követelményeknek. A telepítési tesztelés során új tesztelemek kerülnek kipróbálásra.

Új fizikai elem tesztelése

Az adatbázis fejlesztés optimalizálási, új architektúra kialakítási fázisaiban a logikai réteg nem változik, de alatta új fizikai réteg kerül kialakításra. A fizikai rétegben a megváltozott szerkezet megváltozott teljesítményt fog mutatni, ezen tesztek célja az elvárt teljesítmény mutatók ellenőrzése.

Az adatbázisok tesztelése fontos feladat, mégis kevésbé terjedt el a gyakorlatban, ritkábban fordul elő, mint a hagyományos program tesztelés. Ennek számos oka van, melyek közül kiemelhetők az alábbi tényezők:

  • hiányzó szakmai ismeretek a teszteléssel kapcsolatban az adatbáziskezelő szakembereknél

  • nagyobb költségvonzat

  • kevesebb támogató eszköz áll rendelkezésre

A minőségi szoftverfejlesztés igénye valószínűleg magával hozza a tesztelés szerepének nagyobb elismerését az adatbázis világban is. A következő fejezetekben a tesztelés orientált adatbázis fejlesztés alapelveit mutatjuk be.