Zátěžové testování systému SAP R/3 v SPT TELECOM, a. s.

SPT TELECOM, a. s., patří k největším podnikům v České republice. S tržní kapitalizací ve výši 148 mld. Kč (k 31. 12. 1998) je největší veřejně kotovanou společností ve střední Evropě.

SPT TELECOM, a. s., uskutečňuje náročný program rozvoje a modernizace sítě, který přiblíží kvalitu telekomunikačního sektoru v České republice nejvyšším mezinárodním standardům. Rozsáhlé investice, programy transformace a kontroly nákladů zaměřené na vyšší kvalitu a efektivnost přinesou spolu s rychlým rozvojem nových služeb prospěch zákazníkům, akcionářům, obchodním a dalším partnerům společnosti.

SPT TELECOM, a. s., zřizuje, provozuje a obchoduje v oblasti telekomunikačních služeb, s výjimkou rozhlasových a televizních vysílačů, na celém území České republiky.

Podobně jako jiné velké společnosti i SPT TELECOM stál před rozhodnutím o výběru nejvhodnějšího informačního systému, který by co nejvíce podpořil stávající firemní procesy. K tomuto účelu slouží v současné době podnikový informační systém SAP R/3, který byl nasazen v několika základních oblastech (personalistika, finance a controlling, nákup a logistika).

V průběhu roku 1998 bylo rozhodnuto nasadit tento systém pro všechny typy uživatelů SAPu z řad zaměstnanců SPT TELECOM. Před realizací testu byl počet v systému současně pracujících uživatelů nejvýše 1 100, ale nároky na systém stále rostou. Vzhledem k lepšímu technickému a personálnímu zázemí byla správa systému přesunuta z Prahy do Brna a brněnské pracoviště bylo vybaveno serverem pro provoz aplikace SAP R/3 a databázovým serverem. V souvislosti s těmito změnami bylo rozhodnuto před samotnou migrací a nasazením do rutinního provozu otestovat fungování systému při maximálním možném zatížení, a tím předejít neočekávaným kolizím za skutečného provozu.

Cíl projektu

Test měl prokázat, že navržená konfigurace systému SAP R/3 bude poskytovat potřebný výkon a tím i uspokojivou odezvu pro uživatele, kteří budou se systémem SAP pracovat. Bylo třeba dimenzovat celý výpočetní systém tak, aby byl schopen všechny uživatele obsloužit s dostatečně krátkou dobou odezvy, nezbytnou pro plynulou práci. Záměrem projektu proto bylo otestovat chování systému při současném přístupu až 2 000 uživatelů a zároveň jeho dynamické chování ladit.

Čtenáře může zajímat, proč byla vybrána metoda automatizovaného testu, nikoliv prosté manuální vyzkoušení práce potřebným počtem uživatelů na cvičném systému. Manuální test by při daném zadání, tj. možnost současné uspokojivé práce 2 000 uživatelů, znamenal zinscenovat synchronní činnost právě takového množství uživatelů. Taková akce by byla velmi náročná na organizaci i technické zabezpečení. Prakticky by to znamenalo zajistit účast 2 000 vyškolených uživatelů, kteří by prováděli přesně jednotlivé kroky testu. Každý uživatel by musel mít přístup k systému, tedy vlastní počítač a uživatelský účet. To by jistě bylo náročné i nákladné, pokud by to vůbec bylo realizovatelné. Rozhodující byl zejména fakt potřebné opakovatelnosti za stejných podmínek. To by ale znamenalo znovu organizovat všechny uživatele, což by vedlo k vysokým nákladům na test a nebylo by zaručeno, že test bude opakován vždy za stejných podmínek.

Automatizovaný test naproti tomu vyžaduje poměrně dlouhou fázi analýzy a přípravy, ale po jeho vytvoření umožňuje celou řadu funkcí, kterých při manuálním testu nelze dosáhnout. Skuteční uživatelé jsou nahrazeni virtuálními a jejich činnost je řízena z jednoho místa. Virtuální uživatele je pak možno spouštět dálkově na určených počítačích, rozmístěných kdekoli v rámci sítě, a při testu sbírat údaje jak o jejich chování, tak o chování testovaného systému včetně sítě.

Klíčové pro přípravu automatizovaného testu je co nejvěrněji požadovanou zátěž definovat. Proto vlastnímu testu musí předcházet poměrně dlouhá a náročná příprava chování virtuálních uživatelů, a to ve spolupráci s odborníky na používání testovaného systému, tzn. se znalci aplikace, obchodních procesů, struktury uživatelů a používaných dat i se specialisty IT. Je třeba identifikovat důležité transakce, které se v reálném provozu provádějí nejčastěji a současně musí fungovat i v podmínkách velmi zatíženého systému, a pak transakce, které samy o sobě velkou zátěž vyvolávají. Současně je třeba mít na paměti, že takovýchto transakcí je nutno vybrat co nejméně, aby byl test vůbec proveditelný. Velké množství transakcí totiž prodražuje přípravné práce a tím i celý test.

Původní požadavek realizovat test před prvním spuštěním základních modulů SAP R/3 se po vyhodnocení zkušeností z obdobných projektů konaných v zahraničí ukázal jako nereálný, protože příprava takovéhoto testu je poměrně časově náročná i nákladná. Proto bylo dohodnuto, že test bude realizován pro nově připravovanou konfiguraci systému SAP R/3 v Brně, která byla instalována v souladu s prováděnou restrukturalizací infrastruktury.

Zajištění realizace

Projekt testování byl realizován v průběhu března až června 1999 týmem složeným z pracovníků společností KOMIX, spol. s r.o. a SPT TELECOM, a.s., s podporou konzultantů firmy Cresta Testing Ltd. (Velká Británie).

K testování byl využit LoadRunner, nástroj pro zátěžové testování společnosti Mercury Interactive, která je celosvětově nejvýznamnější firmou na trhu testování podnikových aplikací a aplikací klient/server.

Průběh projektu

V úvodní analytické fázi projektu bylo nutné odhalit nejvíce zatěžovaná místa systému a zároveň dobu maximálního zatížení s cílem provést simulaci co nejpřesněji tak, aby se co nejvíce přiblížila reálnému provozu. Byl vybrán reprezentativní vzorek uživatelských transakcí a vhodná doba zátěže. Po nasnímání uživatelských transakcí a přípravě vstupních dat byl vytvořen scénář testu s několika skupinami virtuálních uživatelů.

Následoval vlastní test, jenž spočíval v postupném spouštění jednotlivých skupin virtuálních uživatelů za účelem zjištění maximálního počtu uživatelů, které je systém schopen bezpečně obsloužit. Skupiny uživatelů byly simulovány na různých místech sítě, připojeny v různých městech republiky. Celý test byl řízen z jednoho pracoviště v Praze, respektive v Brně při jeho opakování. Za podmínek průběžně zvyšované zátěže byly monitorovány reakce celého informačního systému tvořeného aplikací SAP R/3, databází a počítačovou sítí.

Veličiny naměřené v průběhu testu byly užitečné pro vyladění SAP R/3 i databázového serveru. Tímto způsobem lze na základě výsledků měření zátěže sítě odhalit její slabá místa a provést úpravy. Test byl několikrát opakován, mezi jednotlivými běhy byla prováděna rekonfigurace SAP R/3 a databáze pro dosažení vyššího počtu současně pracujících uživatelů. Konečným výsledkem bylo ověření spolehlivé funkčnosti systému při zátěži žádoucím počtem 2 000 uživatelů. Testovaný systém byl úspěšně převeden do stavu rutinního provozu a spolehlivě plní požadované funkce.

Získané zkušenosti ukazují, že realizace zátěžového testu automatizovanými prostředky je velmi efektivní, protože vynaložená práce se zúročí při mnohonásobném opakování testu, tj. při ladění informačního systému. Použití tohoto typu testů je účelné při nasazování nových systémů po jejich akceptaci z pohledu funkcionality, při očekávaném nárůstu počtu uživatelů nebo koncentraci aplikací, při slučování databází apod. Tedy v případech, kdy je třeba se ujistit o dostatečném výkonu nově nasazované nebo upravované aplikace.