A Rational megközelítés az integrációs tesztelés terén

IBM szoftver Elméleti vezető szerep ismertetője 2012. július A Rational megközelítés az integrációs tesztelés terén Korai és folyamatos tesztelés a hibák kordában tartása és a tesztelési hatékonyság optimalizálása érdekében

2 A Rational megközelítés az integrációs tesztelés terén Tartalomjegyzék 2 Bevezetés 3 Fokozatos integráció 3 Tesztvirtualizálás alkalmazása 5 Folyamatos rendszerszintű tesztelés és eszközmegosztás használata 5 A hatékony adatkezelés megtervezése 6 A teljes körű tesztelés költségeinek csökkentése és a GUI elkülönítése 6 Korai tesztelés 7 Hogyan kerülhető el a Nagy bumm? 7 Összegzés Vezetői összefoglaló Az alkalmazások egyre gyorsabb ütemben fejlődnek. Ezek az alkalmazások nem egymástól elszigetelt egységek; összetett és összekapcsolt összetevőrendszerre épülnek, amely eltérő technológiákat, fejlesztőket, telepítési topológiákat és szervezeteket foglal magában. A fejlesztőkkel szemben alapvető elvárás a kiváló minőségű alkalmazások biztosítása, korlátozott tesztelési költségek mellett. Ebben a kihívásokkal teli környezetben az automatizált integrációs tesztelés és a tesztvirtualizálás kombinációja lehetővé teszi a tesztelési csapatok számára, hogy javítsák a szoftverek minőségét és lépést tartsanak a változásokkal. Az ismertető ezen igényekre kínál megoldást az IBM Rational tesztautomatizálási megoldások segítségével történő megelőző jellegű és folyamatos integrációs tesztelés előnyeinek ismertetése révén. Bevezetés Az alkalmazások egyre gyorsabb ütemben fejlődnek. Ezek az alkalmazások nem egymástól elszigetelt egységek; összetett és összekapcsolt szolgáltatásokra épülnek, amely eltérő technológiákat, fejlesztőket, telepítési topológiákat és szervezeteket foglal magában. A fejlesztőkkel szemben alapvető elvárás a kiváló minőségű alkalmazások biztosítása, korlátozott tesztelési költségek mellett. Ebben a kihívásokkal teli környezetben az automatizált integrációs tesztelés és a tesztvirtualizálás kombinációja lehetővé teszi a tesztelési csapatok számára, hogy jobb minőségű termékeket biztosítsanak és lépést tartsanak a változásokkal. A minőségbiztosítási szakemberek számára az egyik legegyszerűbb hatékonysági mutató az észlelt hibák és a felderítetlenül maradt hibák számának aránya. Ugyanakkor a sikert vagy a kudarcot nem egyszerűen a termelési fázisig megmaradó hibák száma határozza meg. A hibák kategorizálása az alapján, hogy melyik fázisban kellett volna azokat megtalálni, hatékonyan rávilágíthat a tesztelés hatékonyságának mértékére. Ha például egy működési hibára a rendszer teljes körű tesztelése során derül fény, akkor a helyreállítási költségek jelentősen meghaladhatják a hiba azonnali, egy korábbi fejlesztési fázisban való megjelenésekor történő kijavításának költségét. A magasabb költségeket kiváltó tényezők többek között a regressziós tesztelés és a felhasznált tesztelési erőforrások mennyiségének növekedése, több valósághű környezet használata és a nagyobb koordinációs követelmény lehetnek. A hibák azonnali észlelése kiemelten fontos az integrációs projektekben és különösen a SOA-projektekben, és nagy kihívást jelent azon tesztmenedzserek számára, akik pénzügyi és ütemezési lehetőségei korlátozottak. A SOA valóban jelentős kihívások elé állítja a tesztelési szakembereket. Az összetett üzleti folyamatok a szolgáltatások együttműködését igénylik. Ez a szükségszerű együttműködés nagy számú permutációhoz vezethet az adatok és a szükséges

IBM szoftver 3 tesztesetek tekintetében is. A tesztelőknek nem csak üzenetek, üzenetadatok és szolgáltatások közötti interakciók kombinációját kell tesztelniük, hanem végül azt is bizonyítaniuk kell, hogy a megoldás támogatja az üzleti követelményeiket. A SOA-tesztelés mostanáig egyetlen megszokott tesztelési tervet követett: követelménykezelés, funkcionális tesztelés, integrációs tesztelés, teljes körű (E2E) rendszertesztelés, felhasználói elfogadási teszt (UAT), teljesítménytesztelés és működési elfogadási teszt (OAT). Ez a terv rendkívül nagy hangsúlyt fektet a funkcionális és integrációs tesztelésre a különböző alkalmazásokban, rendszerekben és a vállalatban megtalálható szolgáltatások kompatibilitásának, együttműködési képességének, működésének és megfelelő teljesítményének biztosítása érdekében. A SOA és az integrációs tesztelés tesztautomatizálása ma már nem lehetőség, hanem alapvető követelmény. A tesztelési eszközök azonban önmagukban nem elegendők. Megelőző jellegű tesztelési megközelítésre van szükség: olyan stratégiai megközelítésekre, amelyek mérsékelik a rendszermódosítások kockázatát, és jól szervezett, felügyelt módon képesek a minőség bizonyítására. Az IBM Rational tesztautomatizálási megoldások és a megelőző jellegű integrációs tesztelési módszer együttes alkalmazása segíthet a hibák azonnali észlelésében, a korai és folyamatos tesztelések végrehajtásában, valamint a tesztelésre fordított erőfeszítések megtérülésének optimalizálásában. A megelőző jellegű tesztelési megközelítéshez megfelelő integrációs szerkezet szükséges: ez a fokozatos integráció. Ehhez a megközelítéshez azonban speciális eszközök is szükségesek. Az IBM Rational Test Workbench, az IBM Rational Performance Test Server és az IBM Rational Test Virtualization Server olyan hatékony eszközök, amelyek kifejezetten arra készültek, hogy segítséget nyújtsanak a megelőző jellegű tesztelési módszerek megvalósításában. Fokozatos integráció A pontos és egyértelmű követelmények alkalmazása létfontosságú az integrációs tesztelés során. Az üzleti folyamatokat meg kell határozni és összetevőkre kell bontani, hogy a rájuk vonatkozó tesztelési követelmények a szolgáltatás-együttműködés legalacsonyabb szintjén legyenek meghatározhatók. A követelmények teljesülésének nyomkövetése így működési, szolgáltatás-együttműködési, illetve üzletifolyamat-szinten és végül a teljes rendszer szintjén történik. A követelménykezelés ezen megközelítése jelentős mértékű potenciális előnyöket biztosít a költségek szempontjából az SOA- és az integrációs projektek esetében. Ha a részletes követelmények teljes mértékig átláthatók, a projektvezetők és a tesztmenedzserek könnyebben működhetnek együtt és hatékony, felügyelt kiadási ütemtervet készíthetnek. A funkciók és összetevők fokozatos és felügyelt bevonása a tesztelési környezetekbe jelentősen felgyorsítja a hibák elkülönítését. A projekt fokozatos integrációs tervének létrehozása után a tesztelési szakembereknek a következő technikák használatát kell fontolóra venniük a hatékonyabb megelőző jellegű tesztelési eljárás megvalósítása érdekében. Tesztvirtualizálás alkalmazása A tesztvirtualizálás során a valós összetevőt egy virtuális összetevő vagy más néven csonk helyettesíti. Ezek a virtuális összetevők a rendszer valós működésének modellezésére és szimulálására használhatók. A virtuális környezet segít az alkalmazástesztelési függőségek megszüntetésében, illetve a hagyományos tesztelési környezetek beállítási és infrastrukturális költségeinek csökkentésében. A megelőző jellegű tesztelési tervekben a tesztvirtualizálás alkalmazásával virtuális összetevőket lehet elérhetővé tenni a kulcsfontosságú szolgáltatásösszetevők helyett, így sokkal egyszerűbb a különböző helyzetek szimulálása és tesztelése. Egyes iparági szakemberek a szolgáltatásvirtualizáció néven hivatkoznak a hiányzó függőségek emulálási folyamatára. Ezek az emulációk azonban nem kizárólag szolgáltatásalapú megközelítést használhatnak, ezért a tesztvirtualizáció megnevezés pontosabb.

4 A Rational megközelítés az integrációs tesztelés terén A tesztvirtualizálás az integrációs tesztelések során használható, rendkívül hatékony eszköz. A tesztvirtualizálás segítségével virtualizált integrációs környezetet hozhat létre a funkcionális vagy teljesítményteszteléshez, ami jelentős előnyöket biztosít az állásidő csökkentése, a költséghatékonyság biztosítása, a korai hibaészlelés és a követelmények egyértelműsítése révén a hardverek és szoftverek fejlesztése és integrációs tesztelése előtt. A tesztvirtualizálási képességek stratégiai alkalmazás esetén a leghatékonyabbak. Az ütemezési problémák például rendkívül rossz hatással lehetnek az integrációs tesztelésre. A gondosan megtervezett kiadási ütemtervekben pedig rengeteg a függőség és a feltételezés. A szolgáltatásvirtualizálást alkalmazó megelőző jellegű tesztelési stratégia segít a függőségek lehető legnagyobb mértékű eltávolításában. Az IBM Rational Test Virtualization Server a szükséges szolgáltatások termelési szintű szimulációját biztosítja. A fejlesztők és a tesztelők egyszerű csonkokat építhetnek, amelyek meghatározott vagy beviteleken alapuló különböző válaszokat adnak vissza, illetve összetett, állapot-nyilvántartó működésű csonkokat is létrehozhatnak. Adattáblákat is használhat paraméteres csonkműködés megadásához, amelyek egy újabb táblázatsor hozzáadásával egyszerűen bővíthetők. A szükséges szolgáltatások teljesítményszimulációjához ugyanígy a fejlesztők és a tesztelők terheléseket hozhatnak létre az alkalmazás- és integrációs szinten az IBM Rational Performance Test Server segítségével. Ennek a funkciónak az a célja, hogy átfogó képet biztosítson az összes alkalmazás-összetevő teljesítményéről és méretezhetőségéről. A virtualizált szolgáltatások gyakorlatilag bármilyen tesztelési célt és tesztvégrehajtási technológiát támogatnak. Amikor az IBM Rational Test Workbench integrációs képességei elindítanak egy tesztet, a program automatikusan elindíthatja a szükséges virtuális szolgáltatásokat, ezzel elősegítve, hogy a feloldatlan rendszerfüggőségek számára előre meghatározott működést biztosítson. A felhasználó határozza meg, hogy melyik csonkot használja a rendszer, így számos különböző szituáció modellezhető a tesztelési forgatókönyvtől függően. A kritikus integrációs pontok felmérése (a módosítás hatókörén belül és kívül egyaránt) segítséget nyújt annak megállapításában, hogy mely szolgáltatások virtualizálására van szükség. A környezet elérhetősége és a szolgáltatások késői biztosítása nagy mértékű kockázatot jelent. A szolgáltatásszimulációt alkalmazó megelőző jellegű tesztelési lefedettség révén rugalmasan alkalmazkodhat az ütemezési krízisekhez, ha jelentkeznek. Az összetevők felépítésekor és szállításakor a virtuális összetevők kicserélhetők, és a tesztelés tovább folytatható (lásd 1. ábra). A folyamatos integrációs ciklusba az egységek prioritás és szabályozás alapján kerülnek be. A még nem felépített egységek szimulálhatók és bevonhatók a tesztelésbe. Fokozatos integrációs tesztelés Tényleges összetevő Szimulált összetevő 1. ábra: A szimuláció virtuális összetevőket biztosít és elősegíti a fokozatos tesztelést Ha a megelőző jellegű tesztelési protokoll részeként virtualizált szolgáltatásokat kíván felhasználni, a projekt kezdetén előnyös lehet egy szimulációs sablon létrehozása parancsfájl formájában. Ez a parancsfájl nagyon gyorsan átalakítható, amint a virtualizált szolgáltatás iránti igény jelentkezik. A műszaki és üzleti kockázatok a hatékony követelménykezelés segítségével történő alapos megismerése elősegítheti a szimulációk prioritásának lehető leghatékonyabb meghatározásában.

IBM szoftver 5 Folyamatos rendszerszintű tesztelés és eszközmegosztás használata A Rational Test Workbench használatának egyik nagy előnye, hogy segítségével gyorsan és egyszerűen hajthat végre teszteket. Az egyszerűség azt jelenti, hogy teljes regressziós ciklusokat futtathat az új vagy virtuális összetevők bevezetésekor. Ez azonnali visszacsatolást biztosít a fejlesztő csapat számára, akik ugyanazokat a parancsfájlokat futtathatják, replikálhatják és megoldhatják a problémákat, mindezt minimális erőfeszítéssel (lásd a 2. ábrát). Ez a helyreállítás helyett az innovációra helyezi a hangsúlyt. Az eszközök arra ösztönzik a fejlesztőket és a tesztelési csapatokat, hogy az integrációs tesztek és virtuális szolgáltatások megosztásával együttműködjenek a teljes szoftverfejlesztési életciklus (SDLC) során. Az üzleti elemzők és az integrációs szakemberek határozzák meg az üzleti folyamatokat, illetve az integrációs pontokat A hatékony adatkezelés megtervezése A szükséges tesztelési lefedettség támogatásához és a szállított megoldás iránti bizalom kialakításához reprezentatív és megfelelő adatok szükségesek. Az adatokkal kapcsolatos szempontokat már a követelményösszeállítási fázisban figyelembe kell venni, és be kell építeni a tesztelések létrehozásába és végrehajtásába egyaránt. Az idő- és pénzbeli korlátok miatt általában ekvivalencia particionálásra és határérték-analízisre van szükség a projekthez elengedhetetlenül szükséges adatok azonosítása érdekében. A tesztadatok kezelése rendkívül fontos tevékenység, ezért elvégzését gyakran külön szakemberre bízzák. A tesztparancsfájloknak adatközpontúnak kell lenniük, a Rational Test Workbench pedig különböző fájlforrásokat képes bemenetként kezelni az adatok a különböző felületekre való átviteléhez. Mivel a tesztelés folyamatos, érdemes fontolóra venni a tisztító parancsfájlok használatát; ezek a parancsfájlok képesek alapállapotba visszaállítani a rendszereket, és biztosítják azt is, hogy az adatok szükség esetén újrafelhasználhatók legyenek. A meglévő integrációs projektekhez adott új projektek megvizsgálják és felhasználják a létező tesztelési eszközöket A fejlesztők az IBM Rational Test Workbench segítségével kezdik el a tesztelést, és a működést szimulációval tesztelik A virtuális szolgáltatások szintén adatközpontúak lehetnek a tesztkörnyezet követelményeitől függően. Gyakori követelmény a teszteléshez használt adatkészlet és a virtuális szolgáltatásokat támogató adatkészlet közötti konzisztencia. Az éles üzem megkezdése utáni támogatás a meglévő tesztelési eszközöket alkalmazza a problémák és hibák megoldására A teljes körű tesztelés magában foglalja a szimuláció útján korábban elkülönített GUI felületeket is Az integrációs tesztelés a fejlesztők által létrehozott eszközöket használja, és a teszteket folyamatos rendszerszintű integrációval finomítja (szükség esetén szimuláció alkalmazásával) 2. ábra: A tesztelési eszközök újrafelhasználása hozzájárul a folyamatos eszközfejlesztéshez. Adattervek készítésekor ne feledje, hogy a virtualizált szolgáltatások megkönnyíthetik a megfelelő adatok összegyűjtését. Az IBM Optim Test Data Management megoldás például automatikusan kinyeri a termelési környezetből a megfelelő adathalmazokat, szükség szerint titkosítja és magánjellegűvé teszi, illetve átalakítja azokat különböző tesztelési célokra. Az egyik legfontosabb cél gyakran a megfelelő adatbázisok feltöltése a tesztelési környezetekben. Azonban az automatikus parancsfájlok és a virtuális szolgáltatások a termelési adatok alternatív mintáit használhatják fel, fenntartva a teszteléseket alátámasztó adatok és a szimulált szolgáltatások által adott válaszok közötti konzisztenciát. A virtualizált szolgáltatásokkal számos esetben az adatkezelés egyszerűbb, a tesztelések újbóli futtatása pedig költséghatékonyabb lehet.

6 A Rational megközelítés az integrációs tesztelés terén A teljes körű tesztelés költségeinek csökkentése és a GUI elkülönítése Mivel az integrációs tesztelés fokozatosan történik, a teljes körű tesztelés jelentősége csökken. Ha a megelőző jellegű tesztelési megközelítést alkalmazza, várhatóan sokkal kevesebb időt kell a költséges teljes körű tesztelésekre fordítania, mivel a funkcionális, integrációs és üzletifolyamat-szintű tesztek többször is futnak, mire a tesztelési környezetben a teljes körűen működő rendszer létrejön. A fokozatos és folyamatos tesztelés elhárítja az integrált megoldás kockázatainak nagy részét (lásd a 3. ábrát). Hagyományos megközelítés Követelménykezelés Egységte sztelés Korlátozott felülettesztelés AZ IBM Rational megközelítés Követelménykez elés Egységtesztelés A Nagy bumm Teljes körű rendszertesztelés Teljesítményteszt elés A tesztvégrehajtás megfelelő ütemének fenntartása érdekében el kell különíteni a GUI-összetevőket azokban a környezetekben, ahol virtualizált szolgáltatásokhoz csatlakoznak. A GUI-összetevők ezután időszakosan bevezethetők, ellenőrizhetők és visszavonhatók a projekt életciklusa folyamán; a formális bevezetésüket csak az összes többi integrációs tesztelés elvégzése után kell elvégezni. A Rational Test Workbench ezen tesztek automatizálásában is segíthet. Az alkalmazás több elkülönített rétegében történő automatizálás, illetve a GUI-tesztek sokkal kiszámíthatóbb végrehajtási környezete együttesen a kizárólag GUI-alapú tesztelés hagyományos kihívásainak enyhítését eredményezi. Korai tesztelés A szoftverfejlesztési ciklus korábbi pontján történő hatékonyabb tesztelés érdekében a fenti szempontok mindegyikét figyelembe kell venni. Széles körben elismert az a tény, hogy a tesztelési és hibajavítási költségek sokkal magasabbak, ha a javításra az integráció késői fázisaiban kerül sor (lásd 4. ábra). A Rational automatizálási megoldás korai és folyamatos tesztelést tesz lehetővé Integrációs tesztelés (Automatikus) Teljesítménytesztelés Teljes körű rendszertesztelé s Minőségkapu Hagyományos tesztelési módszerrel észlelt hibák száma A Rational tesztelési módszerrel észlelt hibák száma A hibák kijavításának költségei 3. ábra: A korai és folyamatos tesztelési protokoll segít a teljes körű tesztelés költségeinek csökkentésében. A teljes körű tesztelés elsődleges célja az E2E folyamatok különböző GUI-felületeken való futtatása. A Rational Test Workbench segítségével automatikus tesztelést valósíthat meg, amely a szolgáltatásszinten történik és kikerüli a GUI felületet. Tapasztalatunk szerint ez a tesztelési módszer gyorsabban hozható létre és hajtható végre, valamint hosszú távon sokkal erőteljesebb, mint a GUI-alapú automatizált parancsfájlok használata. Hibák száma Kódolás Egységtesztelés Integrációs tesztelés 4. ábra: A korai és folyamatos tesztelés révén csökkentheti a költségeket. Javítási költség

IBM szoftver 7 Hogyan kerülhető el a Nagy bumm? A hagyományos Nagy bumm tesztelési módszer esetében az összes integrációs pont az E2E tesztelés elvégzésekor találkozik. Ezen tesztelési módszer használata esetén egy adott küszöb túllépése után számos további teszteset futtatására nyílik lehetőség. Az esetek számának megemelkedése miatt hirtelen visszaesés következik be a teszten megfelelt esetek arányában (lásd az 5. ábrát). A megelőző jellegű tesztelés legfontosabb alapszabálya: a Nagy bumm elkerülése. A megfelelt lehetséges tesztesetek százalékos aránya Fokozatos integrációs tesztelés az IBM Rational Test Workbench h ál á l Hagyományos megközelítés A Nagy bumm Idő 5. ábra: A korai és folyamatos tesztelés segít a hagyományos integrációs tesztelés során jelentkező Nagy bumm jelenség elkerülésében. Ez azt jelenti, hogy a Nagy bumm jellegű tesztelés esetében a projekt kockázatainak nagy része a fejlesztési ciklus végére tolódik, amikor az összes összetevő elérhetővé válik. Ezt a folyamatot meg kell fordítani az integrációs kockázat korai és folyamatos megszüntetésével. A megelőző jellegű tesztelési megközelítés elősegíti az alkalmazás szervezett és felügyelt fokozatos integrációját, és segít a tesztelési költségek szabályozásában. Összegzés A fokozatos integrációs teszteléssel csökkentheti a teljes körű tesztelési költségeket. A megelőző jellegű terv alkalmazása elengedhetetlen: A tesztvirtualizálás stratégiai alkalmazásával eltávolíthatja a kritikus függőségeket és csökkentheti az állásidőt. A rendszerszintű eszközmegosztással felgyorsíthatja a hibajavítási folyamatot. A tesztadatok kezelése megelőző jellegű megközelítést igényel. Érdemes megfontolni a grafikus felhasználói felület tesztelésének különválasztását. Ez felgyorsíthatja a tesztelés végrehajtását? A korai szakaszban való teszteléssel maximális hatékonyság érhető el. Rendkívül fontos a Nagy bumm elkerülése. Az alkalmazások és az előállított termékek egyre összetettebbek, és a rendszerek, folyamatok, illetve az infrastruktúra között minden korábbinál erősebb kapcsolatok és függőségek találhatók. Ennek következtében az alkalmazások integrációs tesztelése (különösen a SOA-tesztelés) folyamatosan új kihívásokat támaszt a tesztelő szakemberekkel szemben. A meglévő szolgáltatásokkal való együttműködésre kifejlesztett új alkalmazások esetében gyakran állhat elő az a helyzet, hogy a változás által érintett területen nem áll rendelkezésre felhasználói felület. Ilyen esetekben szükséges tesztelés jellege a fehér doboz tesztelés (a belső rendszerek tesztelése) és a fekete doboz tesztelés (a működés tesztelése) közé esik. Az effajta projektek technikai jellegéből adódóan az összetevőket és felületeket a fejlesztők gyakran a saját maguk által létrehozott programokkal és csonkokkal tesztelik. Ez olyan helyzetet eredményezhet, amelyben a fejlesztők határozzák meg a saját sikerességük feltételeit, ami pedig ronthatja a projekt általános minőségét. Előfordulhat továbbá, hogy a tesztelések és a csonkok nem érhetők el vagy meghatározott tesztelési célokra, alkalmazásokra, illetve csapatokra korlátozódnak.

Elengedhetetlen a fejlesztők és a tesztelők számára egy új tesztelési stratégia alkalmazása, amely segítségével sikeresen kezelhetik a változásokat, és hosszú távon is megbízható minőséget biztosíthatnak. Ehhez a tesztelési csoport részéről a szokásosnál nagyobb műszaki szakértelemre lehet szükség. A tesztelés általánosan elfogadott szabályait azonban nem szabad teljes mértékben elvetni egy kizárólag műszaki megközelítés alkalmazása érdekében. A tesztelés általános szabályai a hibák lehető legkorábbi azonosítására és kijavítására vonatkozóan egyre fontosabbá válnak a projektek növekvő összetettsége, valamint az egyre nagyobb mértékű változások következtében. További információ Az IBM Rational tesztautomatizálási megoldásokkal kapcsolatos további információkért vegye fel a kapcsolatot az IBM üzletkötőjével vagy az IBM valamelyik üzleti partnerével, illetve látogasson el a következő webhelyre: ibm.com/software/rational/offerings/quality. Lásd még: IBM Rational Test Workbench ibm.com/software/rational/products/rtw IBM Rational Performance Test Server ibm.com/software/rational/products/rpts IBM Rational Test Virtualization Server ibm.com/software/rational/products/rtvs Az IBM Global Financing segítséget nyújt az üzleti igényeinek megfelelő legköltséghatékonyabb és stratégiailag legelőnyösebb szoftverképességek beszerzésében. Partnerként működünk együtt a hitelképes ügyfelekkel, hogy olyan finanszírozási megoldást állítsunk össze, amely megfelel üzleti és fejlesztési céljainak, hatékony pénzgazdálkodást tesz lehetővé, és kedvezőbb teljes tulajdonlási költséget biztosít. Az IBM Global Financing segítségével megteremtheti az informatikai befektetések forrásait és fellendítheti üzleti teljesítményét. További információért látogasson el a következő webhelyre: ibm.com/financing Copyright IBM Corporation 2012 IBM Corporation Software Group Route 100 Somers, NY 10589 Készült az Amerikai Egyesült Államokban 2012. július Az IBM, az IBM embléma, a Rational, az Optim és az ibm.com az International Business Machines Corp. bejegyzett védjegye a világ számos országában. Az egyéb termék- és szolgáltatásnevek az IBM vagy más vállalatok védjegyei lehetnek. Az IBM védjegyeinek aktuális listája az interneten, a Copyright and trademark information weboldalon, a következő címen érhető el: ibm.com/legal/copytrade.shtml A jelen dokumentum a kiadvány első kiadásának idején aktuális állapotot tükrözi, és az IBM bármikor módosíthatja. Nem minden ajánlat érhető el mindegyik országban, ahol az IBM jelen van. A jelen dokumentumban megadott teljesítményadatok csak meghatározott üzemeltetési feltételek esetén érvényesek. A tényleges eredmények ettől eltérhetnek. A felhasználó felelőssége a más termékek és programok IBM termékekkel és programokkal való működésének értékelése és ellenőrzése. A JELEN DOKUMENTUMBAN SZEREPLŐ INFORMÁCIÓKAT AZ IBM JELEN ÁLLAPOTUKBAN BIZTOSÍTJA, KIFEJEZETT VAGY HALLGATÓLAGOS JÓTÁLLÁSI KÖTELEZETTSÉG NÉLKÜL, BELEÉRTVE AZ ÉRTÉKESÍTHETŐSÉGRE, ADOTT CÉLRA VALÓ ALKALMASSÁGRA VONATKOZÓ HALLGATÓLAGOS JÓTÁLLÁST VAGY FELTÉTELEKET, VALAMINT A JOGSÉRTÉS-MENTESSÉGRE VONATKOZÓ JÓTÁLLÁST. Az IBM termékekre azon szerződésben foglalt feltételeknek megfelelő jótállás vonatkozik, amely szerződés keretében biztosítottak. Kérjük, hasznosítsa újra! RAW14304-USEN-00