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
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.
3
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 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.
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 ö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).
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 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.
Tényleges összetevő Szimulált összetevő
Fokozatos integrációs tesztelés
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
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 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 meglévő integrációs projektekhez adott új projektek megvizsgálják és felhasználják a létező tesztelési eszközöket
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)
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
2. ábra: A tesztelési eszközök újrafelhasználása hozzájárul a folyamatos eszközfejlesztéshez.
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 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. 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.
5
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).
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.
Hagyományos megközelítés
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 „Nagy bumm” Követelménykezelés
Egységte sztelés
Teljes körű rendszertesztelés
Korlátozott felülettesztelés
Teljesítményteszt elés
AZ IBM Rational megközelítés Követelménykez elés
Egységtesztelés
Integrációs tesztelés (Automatikus) A Rational automatizálási megoldás korai és folyamatos tesztelést tesz lehetővé
Teljes körű rendszertesztelé s
Hagyományos tesztelési módszerrel észlelt hibák száma
Teljesítménytesztelés
Minőségkapu
A Rational tesztelési módszerrel észlelt hibák száma
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
3. ábra: A korai és folyamatos tesztelési protokoll segít a teljes körű tesztelés költségeinek csökkentésében.
Javítási költség
A hibák kijavításának költségei
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.
IBM szoftver
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 megfelelt lehetséges tesztesetek százalékos aránya
A megelőző jellegű tesztelés legfontosabb alapszabálya: a Nagy bumm elkerülése.
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.
7
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
