Állítsd be Google keresőjét, hogy a találatok között biztos ott legyen az Economx!
A webalkalmazások terjedése, az informatikát felhasználók számának emelkedése, az üzlet mind szorosabb függése az informatikai rendszertől, az alkalmazások és az architektúra egyre bonyolultabb szerkezete mind azt eredményezik, hogy az esetleges hibák következményei akár dollármilliókban mérhetőek. A Reuters egy korábbi felmérése szerint például a Top100 üzleti weboldalon indított 480 online vásárlási kísérletből csak 350 volt sikeres.
A KFKI Számítástechnikai Rt. Egyedi Alkalmazás-Fejlesztési Irodája (KFKI IFI) négy évvel ezelőtt ezért kezdett el foglalkozni az informatikai alkalmazások ellenőrzésére, tesztelésére alkalmas szoftvertechnológia felhasználásával és értékesítésével. Alapos és körültekintő kiválasztási folyamat után a Nasdaqon is jegyzett Mercury Interactive tesztelési megoldását választotta erre a célra. A társaság megoldásai több piackutató cég (IDC, Forrester Research, Newport Group) szerint a tesztrészpiac közel 50 százalékát birtokolják.
A Mercury technológiája két fontos területen segít a kockázatok csökkentésében. Az első, hagyományosnak mondott terület az alkalmazások tesztelése még a bevezetésük előtt, míg a másik az alkalmazások figyelése (monitorozása) az éles alkalmazás során. A legfontosabb tapasztalat, ami az eddigi tesztelési munkák alapján elmondható, az az, hogy nincsenek standard hibák. Ez azt jelenti, hogy nincs olyan mágikus ellenőrzési lista, amit végigkövetve a hibák kevés ráfordítással, jó eséllyel kiküszöbölhetőek lennének, azaz az alapos tesztelés végrehajtása nem megspórolható. Természetesen nemcsak az új alkalmazások fejlesztése, programcsomagok (például SAP-modulok, Oracle Applications, CRM) bevezetése, hanem az alkalmazások és környezetük (architektúra, felhasználószám stb.) változása esetén is szükség van a tesztelésre vagy újratesztelésre.
A tesztelés egyik legnehezebben végrehajtható területe a bevezetés előtti terheléses és a csúcsterheléses teszt. Pedig ennek elhanyagolásával lehet a legnagyobb hibát elkövetni és ennek alapos végrehajtása hozza a legtöbbet a konyhára.
Íme néhány adat a Mercury LoadRunner eszközének 400 ügyfélnél történő alkalmazása alapján. A tesztelt alkalmazások 90 százaléka a tervezett terhelés hatására összeroppant. A terheléses teszt alapján történő javítás, hangolás átlagban több mint ötszörösére növelte az alkalmazás teljesítményét minden hardver- vagy alapszoftver-bővítés nélkül.
A feladatok azonban nem szűnnek meg a bevezetéssel. A webportálok klasszikus példái a folyamatos figyelést igénylő alkalmazásoknak, azonban az egyre népszerűbb alkalmazásszolgáltatók (ASP) is szembesülnek a problémával. Egy üzletileg sikeres ASP-nek, miután kialakította szolgáltatását, tesztelte azt, megállapodott ügyfeleivel a szolgáltatási szintről, már csak egy dolga maradt: a megállapodásnak megfelelően nyújtania kell a szolgáltatást. Az ügyfélre, az ügyfél elégedettségére hosszú távon van szüksége (hogy beruházásai versenyképes díjakon is megtérüljenek).
Ha egy vállalat maga elégíti ki fuvarozási igényeit, gondoskodik a járművei valamilyen szintű ellenőrzéséről és karbantartásáról. A fuvarozó vállalat azonban szigorú saját ellenőrzést és karbantartást alkalmaz (nem az ügyfeleitől várja el, hogy figyelmeztessék az olajfolyásra), azaz a reklamációk gyűjtése és kivizsgálása természetesen nem megfelelő megoldás.
Az alkalmazásszolgáltatás világában a szigorú saját ellenőrzésnek az alkalmazási szintű teljesítményfigyelés felel meg. Természetesen sok ráfordítás spórolható meg azzal, ha a bevezetés előtt befektetett munka eredményét a figyelésre is fel lehet használni. A Mercury Interactive Topaz nevű eszköze éppen ezt ígéri alkalmazóinak. A teszteléskor azonosított kritikus tranzakciókat meghatározott időközönként, ütemezve elindítja a napi felhasználás mellett, majd, mérve a válaszidőket, figyelmeztetést küld a rendszergazdáknak, üzemeltetőknek, ha az eredmény megközelíti az üzemeltetési szintre vonatkozó szerződésben (SLA) meghatározott értékeket. Így időt hagy arra, hogy az üzemeltetők az eredményeket egyes területekre szétbontva (például hálózaton, alkalmazásszerveren, adatbázisszerveren eltöltött idő), elemezve, az adatokban „leásva” meghatározzák a teljesítményromlás okát és beavatkozhatnak, még mielőtt a hiba, az alkalmazás leállása ténylegesen bekövetkezne.
Figyelembe véve a Gartner legutóbbi felmérését, miszerint az alkalmazások összeomlása mintegy 200 milliárd dollárba kerül évente a szolgáltatóknak, amelyben nemcsak a javítás költsége, hanem a felbontott szerződések, elveszett üzletek költsége is benne foglaltatik, nyugodtan kijelenthetjük, hogy a tesztelésre és teljesítményre fordított pénz sokszorosan és hamar megtérül.
Ú. N.
