Szövegüzenet alapú Internet protokollok

megvalósításainak konformancia-

vizsgálata TTCN-3 használatával

Fényes Gábor (gabor.fenyes@eth.ericsson.se)

Konformancia és Szoftver Teszt Laboratórium

Ericsson Magyarország Kft.

1. Bevezetés

Az Ericsson Magyarország Konformancia és Szoftver Teszt Laborja világelsõként mutatta be TTCN-3 fordító és teszt futtató prototípusát valós teszt szituációkkal. Ezen legújabb, ETSI által kifejlesztett Tree and Tabular Combined Notation verzió célja, hogy még több felhasználót nyerjen a már így is közkedvelt tesztleíró környezet. Több új képesség – mint például a programozási nyelv-szerû felület – lett bevezetve, míg a gyakran használatos régi mûködésmódok megmaradtak. A tapasztalatok szerint TTCN-3-mal valóban egyszerûen készíthetõk mind megfelelõség- és mind terhelhetõség-tesztek bájt szinten kódolt (köztük az IPv6, a DNS, és a Diameter) Internet protokollok megvalósításaira.

Sok mai Internet protokoll azonban nem bájt-kódolt. Azok az IETF protokollok, melyek az RFC 822 általános üzenetformátumát követik, a szabad szemmel végezhetõ dekódolhatóság érdekében szövegüzenet alapúak. Az SMTP, a HTTP, valamint legújabban a SIP emberi olvashatósága bizonyos kérdéseket vet fel implementációik TTCN-3 segítségével végzett tesztelésének egyértelmûsége kapcsán. A felmerülõ nehézségek és dilemmák abszolválása legtöbbször döntés meghozatalát kívánja vagy a rugalmasabb, vagy az automatikusabb tesztelhetõség javára.

Elsõdleges célunk rávilágítani a szövegüzenet alapú protokollok megvalósításainak TTCN-3 alkalmazásával történõ konformancia-tesztelése során tapasztalható tipikus problémákra. A téma megértéséhez elõször röviden áttekintjük a konformancia-vizsgálat gyakorlatát és a TTCN-3 tesztkörnyezetet. Bepillantás jelleggel szerepel továbbá, hogy hogyan írhatók konkrét tesztek a TTCN-3 teszt futtató prototípussal.

2. A szövegüzenet alapú protokollok

Az Internet protokollok fejlõdésének legnagyobb vívmányaként az RFC 822 – és mára már az RFC 2822 [6] – szabvány által definiált általános szövegüzenet formátumot említhetjük. Az ötletet, hogy olvasmányos jellege legyen az üzenet fejlécének, több mai protokoll alkalmazza.

Felépítését tekintve a szövegüzenet legalacsonyabb, atomi szinten karakterekbõl (a bájt kódolt protokoll bitekbõl) áll. Legmagasabb szinten üzenet-fejlécet és testet különböztetünk meg. A fejléc tartalmazza az üzenet átviteléhez szükséges információkat, míg a testben található maga a továbbítandó adat.

Az adatot pusztán önmagában kezeljük, azonban a fejlécet további elemekre bontjuk. A fejléc fejléc-mezõk sorozatából áll, melyek mindegyike egy fejléc-mezõ névbõl, egy azt követõ kettõspontból, majd egy fejléc-mezõ testbõl (s végül a fejléc-mezõt lezáró speciális karakterbõl) épül fel. A test egy üres fejléc-mezõ után kezdõdik. Szemléltetés az 1. ábrán látható.

4. ábra. Általános szövegüzenet felépítés

Az ábrán látható fejléc-mezõ nevek (From, To, stb.) a szövegüzenet alapú protokolloknál mind elég tipikusak. Esetenként a nevek kissé módosulnak, hogy egy-egy protokollt jobban szolgáljanak: a Message-ID a SIP-ben a Call-ID elnevezést kapta [1].

Az emberek szokásai igen eltérõek, amiket egy jó protokoll megpróbál mind lekezelni. Ezért például a fejléc-mezõ nevek nem kisbetû-nagybetû érzékenyek; az átlagfelhasználónak nem tudja elképzelni, hogy mást jelenthet egy „from” és egy „FROM”. Ez a szemlélet látható abban is, ahogy a fejléc mezõ utáni kettõspontot követheti egy vagy több szóköz, tabulátor, legalább szóközzel vagy tabulátorral követett sortörés, ezek kombinációja, de akár egybõl a fejléc-mezõ test is.

3. Konformancia-vizsgálat

A konformancia-tesztelés mai gyakorlatának elméleti hátterét az ISO/IEC 9646 ajánlás ([2]) nyújtja. Egyszerû „fekete doboz” elvrõl van szó. A teszt berendezés elõre definiált üzenetekkel vagy üzenet-kombinációkkal közvetlenül gerjeszti a tesztelendõ (System Under Test (SUT)), belülrõl ismeretlen eszközt.

Minden egyes gerjesztéshez ugyancsak elõre meghatározott helyes reakció tartozik az SUT mûködését meghatározó szabvány alapján. A teszt eszköz tehát végigvizsgál gerjesztés-válasz párokat (mai terminológiával teszteseteket (test case)), és a vizsgálat eredményeibõl állapítja meg, hogy az SUT megfelel-e a kérdéses szabványnak.

Kommunikálni egy adott protokollt megvalósító SUT-vel kizárólag eggyel magasabb és/vagy alacsonyabb OSI rétegként lehet. A teszt berendezés feladata tehát egy ún. felsõ és/vagy alsó tesztelõ szerepet vállalni a 2. ábrának megfelelõen [2].

4. ábra. Az SUT és a teszt berendezés kommunikációja (lokális teszt elrendezés)

Egy teszteset eredménye három féle lehet, melyeket ítéleteknek (verdict) nevezünk. Az 1. táblázat tartalmazza azt, hogy az egyes ítéletek milyen kapott válaszokhoz tartoznak.

7. táblázat. Tesztesetek lehetséges eredményeinek kapott választól való függése

4. A TTCN-3 tesztírás menete

A [2] szabvány legújabb megvalósítása a TTCN hármas verziója, mely programozási nyelv jellegûen is lehetõvé teszi, hogy az OSI hétrétegû modelljére épülõ protokollmegvalósításokra konformancia teszteseteket írjunk. Kiindulva a protokoll üzenet- (Protocol Data Unit (PDU)) formátumának TTCN-3 adatstruktúrával való leírásából, a tesztelõ dolga nem más, mint megadni a tesztelt rendszer felé kiküldendõ üzenetek és az azokra helyes mûködést jelentõ válaszok tartalmát, majd emellett a gerjesztés-válasz elv konkrét lépéseit.

Elõször tekintsük át a leggyakoribb TTCN-3 adattípusokat, amelyekbõl egy PDU TTCN-3 megfelelõje összeállítható (ezeket ismerteti a 2. táblázat). Lehetséges definíciós és hozzárendelés formátumokat a 3. táblázatban láthatunk.

7. táblázat. A legfontosabb TTCN-3 adattípusok képességei

7. táblázat. A különféle TTCN-3 adattípusok használata

A TTCN-3 szabvány ([5]) definiál néhány beépített függvényt melyekkel konverzió végezhetõ bizonyos adattípusok közt. A szerzõk érdekes módon kizárólag az integer-bõl vagy integer-be való átalakításokra gondoltak. Szerencsére a teszt futtató prototípus megvalósít egy char2oct függvényt [4], ami élõ tesztelések során sokszor felbecsülhetetlen értékûnek bizonyul, mert megkíméli a tesztelõt a fejben végzendõ oktális reprezentáció kiszámításában (lásd 3. táblázat).

A típusdefiníció által meghatározható üzenetet sablon (template) használatával konkretizálhatjuk. A kiküldendõ és bejövõ üzenetek sablonjai eltérhetnek egymástól a 4. táblázatban illusztráltak szerint.

7. táblázat. Kimeneti és bemeneti sablon közti különbözõség szemléltetése

Míg az SUT számára csak egy konkrét üzenetet küldhetünk, addig válaszként már üzenetek nagyobb halmazát kell tudnunk elfogadni. Az utóbbi cél megvalósíthatósága végett létezik a TTCN-3 4. táblázatban megfigyelhetõ „csillag” konstrukciója, amely egy sablon-mezõ tetszõleges – akár üres – tartalmát hivatott képviselni.

Mivel egy TTCN-3 adatstruktúra független az általa megfeleltethetõ üzenet atomi elrendezésétõl, definiálunk egy Teszt Port nevû egységet a teszt berendezésben, ami a kódolást és a dekódolást megvalósítja [4]. A 2. ábra architektúrája a TTCN-3 teszt futtató prototípussal a 3. ábrára konkretizálódik, ha az SUT történetesen egy szöveges (OSI hetedik rétegbeli) Internet protokollt valósít meg. Az ábra meglehetõsen leegyszerûsített a fõbb ötletek szemléltetése érdekében.

4. ábra. A TTCN-3 teszt futtató prototípus által megvalósított teszt architektúra

TTCN-3 ismertetõnk végeztéül nézzünk meg egy egyszerû tesztesetet. Ez látható a 4. ábrán. Az ábra hiányzó definícióit nem ismételjük meg, a 4. táblázatban találhatjuk meg õket.

4. ábra. Egyszerû TTCN-3 teszteset

A tesztesetek lelke az alternatíva (alt) konstrukció. Ezt láthatjuk a 4. ábrán mûködni, ahogy a teszteset ítélet-hozzárendelését végzi. Különös jelentõséggel bír a receive függvény paraméter nélküli változata, melyhez megadhatjuk, hogy mi történjen egy váratlan üzenet érkezésekor.

5. Szövegüzenetek a TTCN-3 világában

Vizsgálataink során nem térünk ki a bájt-kódolt üzeneteknél is megfigyelhetõ általános tesztelési kérdésekre. Célunk kizárólag a szövegüzenetek sajátos, szöveges tulajdonságaiból adódó hatások elemzése.

A kézzelfoghatóság érdekében a SIP protokollra szorítkozunk. A tárgyalásra kerülõ helyzetek azonban érvényesek akkor is, amikor a többi szövegüzenet alapú protokollok megvalósításait teszteljük.

1. A kisbetû-nagybetû dilemma

Tekintsük a SIP üzenet fejléc-mezõinek neveit. TTCN-3 leképzésre két lehetõségünk van.

Az egyik lehetõség a fejléc-mezõ neveknek enumerated típussal való megfeleltetése. Ez a megoldás kényelmes, könnyen kezelhetõ adatstruktúrát eredményez az üzenetmegfogalmazás szempontjából. Példát az 5. táblázatban láthatunk. Komoly hátránya azonban, hogy nem enged meg tetszõleges formátumú fejléc-mezõ név küldését, hanem csak a Teszt Portban fixen eltárolt módon. Szükség lehet ugyanis olyan tesztsorozatra, mely épp azt teszteli, hogy le tud-e kezelni az SUT bármilyen kisbetû-nagybetû kombinációt.

7. táblázat. A szövegüzenet mezõ egyszerû, de korlátozott TTCN-3 megfelelõje

Átírhatnánk a Teszt Portban az üzenetkódoló részeket, de így egyesével kellene teszteseteket futtatnunk, minden tesztesetnél újabb és újabb Teszt Port verziót használva. Ráadásul ez még mindig nem enged meg teljes flexibilitást, mert így egy üzeneten belül két vagy több ugyanolyan fejléc-mezõ mindegyike csak azonos kisbetû-nagybetû kombinációjú névvel lenne képes kiküldõdni.

A másik leképzési lehetõség áthidalja problémánkat: legyen a fejléc-mezõ nevének típusa egyszerû charstring (6. táblázat). E módon minden teszteseten belül az összes fejléc-mezõ nevének küldési módja külön rögzíthetõ TTCN-3 szinten. A módszer alkalmazása mellett azonban egy kisebb hibalehetõségeket tapasztalunk üzenetfogadás esetén. Minden elfogadható üzenetnél szövegszerûen megadni a helyes fejléc-mezõ értékeket ugyan nem mindig kötelezõ („csillag” konstrukció), ám ha erre mégis szükség van, a Teszt Port esetleges konvencióinak nem betartása és elgépelések valótlan teszteredményeket produkálhatnak.

7. táblázat. A szövegüzenet mezõ rugalmas TTCN-3 megfelelõje

2. Bõvített karakterkészletek

Szöveges protokollok elterjedésével elengedhetetlen, hogy az angol ábécén kívüli karakterek használata is megengedhetõ legyen, hisz akár átlag magyar felhasználói szemszögbõl is jobban imponál az a termék, melyben ékezetes üzenetek is küldhetõk. A TTCN-3 charstring adattípusa azonban ennek a kívánalomnak nem felel meg, bõvített (non-ASCII) karakterkészletet csak octetstring-re való leképezéssel vagyunk képesek kezelni. Teszteseteink alapján döntenünk kell, hogy melyik megfeleltetést választjuk egy szöveges mezõnek.

Ha a charstring mellett maradunk, üzenetstruktúránk áttekinthetõbb lesz, és ha tesztelõként nem küldünk ékezetes karaktert, az SUT tesztkörülményektõl függõen valószínûleg nem is fog azokkal válaszolni. Octetstring típust csak abban az esetben kell használnunk, ha az SUT mégis bõvített karakterkészlettel válaszol, vagy ha épp a non-ASCII karakterek támogatottságát teszteljük.

Vegyük észre, hogy bájt-kódolt üzenetek kapcsán a kérdéssel nem szembesülünk, hisz minden információ bájt- vagy annál még alacsonyabb (bit-) szinten kódolt.

3. A láthatatlan elválasztó karakterek

Az egymástól elsõ ránézésre megkülönböztethetetlen karaktereket „lineáris fehér szóközöknek” (linear white space (LWS)) hívjuk. Nevük az írógépek idejébõl ered, amikor fehér papíron egy fehér karakter nem volt látható. Az LWS csoport tagjai az egyszerû szóköz, a tabulátor, valamint a különféle sortörés karakterek, melyek tulajdonképpen egy üzenet elemeit valamilyen módon egymástól elválasztják.

Ha a szövegüzenet TTCN-3 megfelelõjében szerepeltetjük az LWS-eket, akkor nyelvtani gyakoriságuk miatt szinte teljesen áttekinthetetlen tesztjeink alakulnak ki. Pedig értelme van, mert igény merülhet fel, hogy a következõ valós ajánlást teszteljük: a fejléc-mezõ nevet követõ kettõspont elõtt semmilyen LWS, utána pedig csak egyetlen szóköz szerepeljen [1].

A praktikus megoldás az LWS kihagyása a TTCN-3 adatstruktúrából. Ilyen esetben a Teszt Portra hagyatkozunk az esetleges LWS-ek kifelé formázásában, illetve a bejövõ üzenetekbõl való kiszûrésében.

4. Amikor teljes furcsaság érkezik

Képzeljük el, hogy a SIP SUT-t lecseréljük egy egészen más protokollt megvalósító SUT-re. SIP tesztjeinket így indítva jó esetben semmit sem reagál az új SUT, azaz a tesztesetek az idõzítõk leteltével „eldönthetetlen” ítéletet kapnak.

Elõfordul azonban, hogy az SUT a saját protokollját alkalmazva küld valamilyen választ (tipikusan azt, hogy „nem értem”). Ekkor képtelenek vagyunk érdemlegesen feltölteni TTCN-3 SIP adatstruktúránkat egy más protokoll üzenetébõl.

A problémára [3] ad kézenfekvõ megoldást. Definiálunk a PDU típus mellé egy ún. „nyers” (Raw) típust, mely egy közönséges charstring vagy octetstring. Minden nem SIP szerint értelmezhetõ üzenetet egyszerûen Raw-ként kezelünk. Eredményképp a teszteset alternatíva konstrukciójából az argumentum nélküli receive fog érvényesülni, azaz a teszteset sikertelen ítéletben részesül.

Ha most újra SIP implementációt veszünk SUT-nek láthatjuk, hogy egy szintaktikailag helytelenül kommunikáló SIP SUT üzenetei is teljesen idegen protokollnak tûnnek egy teszteset számára. Éppen ezért kell felkészülnünk erre az esetre is, hogy a megfelelõséget szintaktikai hiba miatt utasíthassuk vissza.

A módszer egyszersmind megoldás a bármilyen módon rendhagyó gerjesztések teljes körû problematikájára is, hisz egy Raw üzenet a lehetõ legkisebb (atomi) elemekbõl áll, amikbõl bármilyen üzenet megkonstruálható és küldhetõ, akár egy teljesen más protokollé is. Sajnos egy üzenet betûnkénti megkomponálása meglehetõsen idõigényes és hibalehetõségekben gazdag vállalkozás.

Megemlítjük, hogy bájt-kódolt üzenetek nem lehetnek értelmetlenek ilyen szempontból azért, mert ezekben a PDU-kban az egyes bájtok pozíciója elõre definiált, szemben a szövegüzenetbeliekéivel. Bájt-kódolt esetben tehát a Teszt Port pozíció alapján dönt tartalomról, ami korlátozza a hibalehetõségek számát, és azok TTCN-3 megfeleltetését könnyen kezelhetõvé teszi.

5. A nehézségek feloldása

Ahhoz, hogy a fejezetben felvázolt kételyeinket eloszlassuk, szét kell választanunk a szintaxis- és a funkcionalitás-megfelelõség tesztcélokat két csoportba. A két csoport tesztesetei külön-külön már a saját céljuknak leginkább megfelelõ adatstruktúrát (és annak megfelelõen Teszt Portot) képesek használni.

Eredményként mind a tesztírás és mind a tesztmegértés szempontjából egyszerûbb tesztsorozatokhoz jutunk. A javaslat konkrétumait a 7. táblázatból olvashatjuk ki.

7. táblázat. A szövegüzenetek kényes szintaktikai elemeinek teszteset-függõ TTCN-3 adattípus megfeleltetései

6. Összefoglalás

A TTCN hármas verziója egy meglehetõsen új ajánlás. Használatával végzett tesztelések nagy része még a tapasztalatszerzés stádiumában van. Eddigi tapasztalatok szerint a szövegüzenet alapú Internet protokollok megvalósításainak konformancia-tesztelése igen sajátos kérdésekbe ütközik.

Láthattuk, hogy a szövegüzenetek legcélszerûbb formátumellenõrzésre képes TTCN-3 leképzése megnehezíti a funkcionális tesztelést. A funkcionális tesztekre kiélezett adatstruktúra pedig nem használható bizonyos szintaxisbeli konformancia-vizsgálatra.

Megoldásként a probléma két részre választását javasoljuk. Az egyikben kizárólag szintaxist, a másikban kizárólag funkcionalitást tesztelünk. Voltaképp azt is mondhatjuk, hogy két külön protokoll implementációját kezeljük az egyes részekkel – az egyikben számít a pontos szintaktika, a másikban mellõzzük a finomságokat.

Bízunk benne, hogy vizsgálataink gördülékenyebbé teszik a szövegüzenet alapú Internet protokollok megvalósításainak konformancia-tesztelését. Különösen a jövõ ilyen protokolljaira (pl. SIP) gondolunk, hiszen implementációikra még egyáltalán nem léteznek tesztek, amik a felvázolt problémák leküzdésével már könnyûszerrel létrehozhatók TTCN-3 használatával.

7. Irodalom

1. Handley, M., Schulzrinne, H., Schooler, E. M., Rosenberg, J. SIP: Session Initiation Protocol. IETF DRAFT RFC 2543 bis-05, 2001. október.

2. Information technology – Open systems interconnection – Conformance testing methodology and framework – Part 1: General concepts. ISO/IEC 9646-1, 1994. december.

3. Session Initiation Protocol (SIP) Conformance Test Specifications – Part 3: Abstract Test Suite (ATS) specification. ETSI DTS-TIPHON-06020-3 v0.0.1, 2001. szeptember.

4. Szabó, J. Z. User Documentation for the TTCN-3 Test Executor Prototype. 2001. december.

5. Methods for Testing and Specification (MTS): The Tree and Tabular Combined Notation version 3 – Part 1: TTCN-3 Core Language. ETSI ES 201 873-1 v1.1.2, 2001. június.

6. Resnick, P. (szerk.) Internet Message Format. IETF RFC 2822, 2001. április.