TTCN-3 felhasználói konferencia, Peking, 2010

Címkék

Idén Pekingben tartották az éves TTCN-3 felhasználói konferenciát. A TTCN eredeti rövidítése Tree and Tabular Combined Notation, mely a nyelv 3-as verziójának megjelenésével Test and Test Control Notationre változott, ezzel is kifejezve a nyitást az ipar más területei felé.

A TTCN nyelvet az ETSI fejlesztette ki és tartja karban. Eredeti formájában kifejezetten távközlési protokollok konformancia tesztelésére szánták és táblázatos formájával inkább leírónyelv volt, mintsem valódi programnyelv. A helyzet a TTCN-3 megjelenésével változott meg, mely már egy igazi programnyelv jellemzőivel bír. A TTCN-3 ezáltal versenyképessé vált, miközben megőrizte erősségeit, melyek kifejezetten vonzóvá teszik protokoll-tesztelésekhez, ahol a mintaillesztés gyakori.

A hagyományos távközlési világból így lassan kiléphetett más területekre is mint teszt automatizálási framework. Ma már sok más területen is használják, pl. unit, function, system és load teszteléshez. Megjelenése óta több területen is bizonyított már. Az ETSI többek között a következő területeken használja: SIP (VoIP), IPv6, Digital Mobile Radio (DMR), WiMax, 3GPP IMS.

A TTCN-3 nyelv erősségei más nyelvekhez képest:

  • szabványosított nyelv és szintén szabványosított absztrakt tesztkörnyezet
  • erős teszt-automatizálási támogatás
  • kiforrott teszt verdict menedzsment
  • gazdag típuskészlet
  • ASN.1 támogatás
  • XML és CORBA mapping
  • template matching
  • snapshot szemantika esemény queue-kal
  • dinamikusan indítható, párhuzamosan futó tesztkomponensek
  • többféle prezentációs réteg

A konferencia előadásai itt érhetőek el. A TTCN-3-ról bővebb információkat itt lehet találni.

- Süni

Hozzászólások

Ezt csak en nem ertem?

Mar a modell-orientalt fejlesztesrol is kulonvelemenyem van, igy sok ev UML hasznalat utan (nehany idiota komolyan nem erti, hogy abban kulonbozik a program meg a modell, hogy az egyik minden reszletre kiterjedo valosag, a masik meg adott nezopontokat kiemelo modell, es programot akar belole generalni), de tablazatos programnyelv, meg end-to-end modell...

Az, hogy szabvanyositott nyelv, meg kornyezet, ezt azert a C-tol kezdve a Java-n at a C#-ig, sot, a javascript is tudja (ECMA-262, ill. W3C DOM)

Eddig azt hittem, tavkozlesre erlangot meg javascriptet kell hasznalni, mivel ezek aszinkron nyelvek, a CORBA pedig kb. kihalt, ill. modellezni SDL-ben szokas arrafele, en volnek a hulye?

De lehet csak megzavartak a betuszavak, elnezest.

A legfontosabb mondat szerintem nem ment át neked (eredeti formájában kifejezetten távközlési protokollok konformancia tesztelésére szánták). Vagyis ebben nem alkalmazást fejlesztenek, protokollokat tesztelnek. Illetve vannak cégek, ahol azt sem, mert már leszokóban vannak a TTCN-ről :).

Ugy latszik, ujabban divat engem hulyenek nezni errefele, na nem baj.

Ertem en, hogy specifikacios nyelv (ha igy tetszik: tesztnyelv, ugyanis nem teszthez vagy konform, hanem specifikaciohoz), de miert kell ennek ekkora huho, hogy user group szervezodik koreje?

Az end-to-end modelling meg a konferenciaprogrambol van.

A valaszt ott sejtem, hogy miutan a multban egy halom tavkozlesi szabvany szuletett, azokat szerettek volna konformanciatesztelni.

Erre szuletett mint eszkoz a TTCN-2 (ami tablazatos volt), es ez lett frissitve egy igazi programnyelvhez kozelebb allo formaba a TTCN-3-as verzioban. Maga az ETSI (is) nyujt konformancia teszteket, amivel ellenorizhetok a megvalositasok a szabvanyok elleneben.

A konferencia anyagban sokminden van, de ne felejtsd el, hogy ott elsosorban a tapasztaltok megosztasa all a kozeppontban es nem feltetlenul az elmeletileg korrekt megkozelites.

Roviden reagalva azokra amit mas meg nem valaszolt meg:

A TTCN nem koveteli meg a model based testinget, pusztan tamogatja azt. A fejlesztese soran szempont volt, de nem alapkovetelmenyrol van szo. Ha viszont hasznalhato az UML a tervezesnel, akkor nagyon sokat segit, hogy a tesztnyelv alapbol tamogatast nyujt a modellhez es abbol kepes teszteket gyartani.

A model based testingnek termeszetesen megvan a maga helye es nem az ultimate solution. Ott is, ahol hasznalhato, altalaban a ganyolas nem kerulheto el, de ennek ellenere a funkcionalitas nagy resze a modellben tarthato, igy az elonyei kiaknazhatoak.

Nagyon rosszul tudtad, tavkozlesre NEM kell Erlangot hasznalni, sot, valojaban az Erlang (bar viszonylag elenk kozossege van), egyaltalan nem egy korszakalkoto nyelv es kornyezet. Az a funkcionalitas illetve kornyezet amit megvalosit, 40 eve valtozatlan formaban letezik, pusztan a megvalosito technologiak valtoztak. Hogy mast ne mondjak, azon ceg berkeiben ahol szuletett sem ez dominal, sot, egy kezemen meg tudom szamolni hany helyen hasznaljak meg.

Az SDL-es modellezest jo ideje felvaltotta az UML, de a lenyeg persze nagyjabol ugyanaz. Viszont ezt a modszert sem hasznaljak altalanosan fejlesztenel, az osszkep kifejezetten sokszinu.

Szavaidbol ("a ganyolas nem elkerulheto", "az osszkep kifejezetten sokszinu") azt veszem ki, hogy a tavkozlesi protokollok fejlesztesenel ugyanaz az agyatlan ganyolas megy, mint a tobbi teruleten - kar erte, volt vagy 50 ev elonyuk, meg jobban megneztek az embereket a felvetelin...

Sz'al akkor ez egy nyelv, amiben teszteseteket lehet leirni?

(40 eve valtozatlan az esemenyvezerelt tervezes, ebben egyetertunk, az osztalyokat is Arisztotelesz talalta ki, csak mondjuk nem volt hozza tooltamogatas annyi)

Mi az amiben tenyleg tobbet tud? Mikhez kepest? Mert egyiket se latom, hogy mas ismert rendszerekben (cucumber, pyunit, junit csalad) ne lehetne megvalositani. Jo, nyilvan a vilag turing-teljes, de sz'al template matchingert nem valtok programnyelvet, mint ahogy CORBA tamogatasert se. A szabvanyossag meg esetleg, de attol fugg, mennyi hasznalhato implementacioja van.

(A kozhiedelemmel ellentetben a C# is szabvanyos, van 1 db hasznalhato, meg egy felhasznalhato implementacioja)

UML-bol oda-vissza generalni se egy nagy varazslat, egyszer kell megerteni az XMI-t, de ez is inkabb tooltamogatas, semmint nyelvi feature. Brainfuckhoz is lehet UML konvertert irni, mi PHP-hoz irtunk, ez ilyen delutanos projekt szokott lenni.

"Szavaidbol ("a ganyolas nem elkerulheto", "az osszkep kifejezetten sokszinu") azt veszem ki, hogy a tavkozlesi protokollok fejlesztesenel ugyanaz az agyatlan ganyolas megy, mint a tobbi teruleten "

Rosszul vetted ki, en a protokoll megvalositasokrol (lekodolasarol) beszeltem, nem pedig maganak a protokoll fejleszteserol. Az utobbi (elmeletben) kifejezetten szep munka es eleg messze van a ganyolastol.

A gyakorlatban (ami nem csak az ETSI-re jellmezo, hanem az IETF-re is bosegesen) a politika es a cegek erdekei altalaban be szoktak zavarni a szep tiszta kepbe. Az esetek tobbsegeben a szabvanyositas mar az ipar utan kullog, emiatt elkerulhetetlen a politika.

Ha engem kerdezel, szerintem a tavkozlesi protokollok kifejezetten jok voltak az elmult evtizedekben, a mai helyzet viszont (szerintem) kifejezetten rosszabb, miota az IETF szabvanyokat adoptaljak.

A nyelv elonyeirol nehez ugy beszelni, hogy az ember ne fejtse ki 3 oldalon, mert ertelemszeruen nem kis temarol van szo. A felsorolas fedi ezeket, de a hozzaszolasi szal nem igazan jo forum ennek a kifejtesere. Roviden pedig nem sok ertelme van, mert akkor nem tudom vilagosan elmagyarazni/leirni es akkor a feluletes kep alapjan iteled meg.

[szerk]
"egyiket se latom, hogy mas ismert rendszerekben (cucumber, pyunit, junit csalad) ne lehetne megvalositani"

Annyiban igazad van termeszetesen, hogy mind az absztrakcio, a mukodesi szemantika pontos definialasa es az eros nyelvi tamogatas adattipusokhoz es matchinghez, mind-mind megvalosithatoak mas nyelven is (ertsd: mi az, amit NEM lehet megirni egy mai nyelv akarmelyiken?). A hangsuly azon van, hogy mindezeket ez a nyelv immaron tobb evtizede nyujta, mig masok ma sem.

Na, vegre valaki bevallja, hogy a tavkozlesben a szabvanyositas az ipar utan kullog!

BME-n a TMIT bemagoltatja(!) a diakokkal, hogy nem, es utana visszakeri(!) vizsgan. Nem vicc, de a szakertelmuk kb. itt veget is er.

En elolvastam az IMS bibliat, meg dolgoztam GSM-mel. Az utobbi evek maszturbalasai, foleg az IP alapu protokollok szerintem annyira nem sikerultek jol, a GSM es az ISDN viszont meg tenyleg ott volt (bar mar az ISDN-nel is voltak erdekes korok, amikor szolgaltatni akartak bitek tovabbitasa helyett)

A nyelv elonyeirol nyugodtan linkelhetsz egy 3 oldalas dokumentumot, ezt szerintem meg el lehet olvasni :)

Ami szamomra nem derult ki az irasodbol, hogy mi az, amit a NYELV nyujt. Mert amikor azt mondod, hogy CORBA tamogatas, azt nem a nyelv nyujtja, azt egy tool nyujtja, es az ilyesmik kozel se standardek.

Hadd rakjam kontextusba: evekig voltam az XSF - a "GTalk" szabvanyugyi testulete - tagja. Az emberek szolgaltatasokat hasznalnak, oket nem az erdekli, hogy a protokol alul mit tud, hanem hogy a konkret vegberendezes - esetunkben: chatkliens mit tud, es kikkel tudjak ezt a szolgaltatast kihasznalni (pl. videotelefonalhat-e egy bombus-ossal (nem)).

Az XMPP legnagyobb elonye ott volt, hogy majdnem mindenhez volt mar elore megirt lib, azonban hiaba volt nyilt es szabvanyos a protokol, az alapdolgokon kivul altalaban soha senki nem implementalt semmit - igy aztan hiaba volt a kliensed vagy szervered uberfeature-rich, ha ezt a tobbiek nem irtak meg. Manapsag az XSF inkabb a middleware temat erolteti.

(Amire en egyebkent sokkal jobban szeretek mas, erre kitalalt protokollokat, raadasul amiket ok eroltetnek, gyakran mas retegben megoldando feladatok)

Nagyon sok gyartoi protokol volt itt is, egyetlen implementacioval, de a csunyabb inkabb a "miert ne lehessen megcsinalni ezt is?" tipusu oruletek voltak.

Szoval a kerdesem tovabbra is az: mi az amit a NYELV tud? Mi az, amit MINDEN implementacio (nyelv + core lib) tud?

(Azt mondod, standard, akkor tuti nem egyetlen implementacio van, maskulonben felesleges lenne ezt kihangsulyozni)

(pl. a python nyelv tamogatja a hashmapeket (dictionary), de ez a core lib resze. Lehet CORBA-zni is, de ez egy python modul.)

Nem gond ha linkelsz egy 3 oldalas dokumentumot :)

"Azt mondod, standard, akkor tuti nem egyetlen implementacio van"
Tobb nagy gyarto is kinal komplett megoldasokat (forditokat, runtime kornyezetet, tipikusan integralva mas tesztmegoldasokba), vannak egyedi ceges megvalositasok es vannak open source megvalositasok is.

A valosag -termeszetesen- arnyalt, mert egy adott gyarto mindig szabadon dont arrol mit tamogat a szabvanybol es mit nem. A szabvany letet ettol fuggetlenul azt hiszem nem kell magyarazni.

Melyebben a nyelv torteneterol:
http://www.itu.int/ITU-T/studygroups/com17/ttcn.html

Altalanos attekintes:
http://www.ttcn-3.org/doc/ETSI_TTCN3_Tutorial.ppt

Betekintes a nyelvbe magaba:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.59.1521&rep=re…

A fenti pdf leiras a template-ekkel kicsit szukszavuan banik, igy annyit fuznek meg hozza, hogy a template-ek strukturaba szervezhetok, egymasbol szarmaztathatoak, parameterezhetoek.

A mas nyelvi tamogatast ugy ertem, hogy mas nyelvu elemek (pl ASN.1, XML, stb) kozvetlenul, transzparens mappingen keresztul elerhetoek a TTCN nyelvbol. Nem toolokrol van szo, hanem elvi szintu mappingrol, amit nyelvi szinten tudsz hasznalni (vegso soron persze a TTCN compiler gondoskodik a megvalositasrol).

Ha ennel melyebben is erdekel, akkor mar magat a szabvanyt javaslom.

"Na, vegre valaki bevallja, hogy a tavkozlesben a szabvanyositas az ipar utan kullog!"

Ezt kicsit finomitanam, mert ebben a formaban felrevezeto. Ahogy en latom, tavkozlesben a szabvanyositas boven megelozi az implementaciokat es a nagy cegek mind aktivan reszt vesznek a munkaban. Ertelemszeruen van politikai es uzleti nyomas, de olyan foku utolag szabvanyositasrol beszelni, mint ami mondjuk az IETF eseteben van, azert eros tulzas.

"tavkozlesben a szabvanyositas boven megelozi az implementaciokat"

3GPP szabványokba a SIP-es dolgok sok éves késéssel kerültek be. Ráadásul ha egy RFC véletlenül egész jól sikerült, azt a 3GPP vagy az ITU-T nem feltétlenül helyesen veszi át. Ilyen pl. a SIP-es hívás tartás (call hold).

"olyan foku utolag szabvanyositasrol beszelni, mint ami mondjuk az IETF eseteben van, azert eros tulzas"

Az AMR kodek nem valami bonyolult dolog, de sok 3GPP release-en keresztül kerültek be újabb és újabb változtatások, megkötések. Technikailag jók a változtatások (GSM-hez konvergálás, módok kombinációinak és negotiation-jének korlátozásai), de jól látszik, hogy a 3GPP szabványokat is sok helyen a piacra dobott implementációk tapasztalatai formálják át. Magyarán nem hiszem, hogy a 3GPP és az IETF megfontoltsága közt nagy különbség volna.

Aztán persze politikai okokból olyan dolgok kerülnek be 3GPP szabványokba, amik még nincsenek kitalálva. Pl. az RTP ECN nem véletlenül IETF draft még, de a 3GPP doksik már javában tartalmazzák.

Mindenki próbálja a saját implementációja és szabadalma felé terelni a szabványosítást, és ez bizony meglátszik.

"BME-n a TMIT bemagoltatja(!) a diakokkal, hogy nem, es utana visszakeri(!) vizsgan."

Éppen ezért nem szokták informatika területén nézni idehaza, hogy ki honnan jött, mert nincs egyetlen kiemelkedő intézmény sem az országban. A diákok a szakmát a hálóról és egymástól tanulják el. Így az intézményektől az egyetlen elvárás az ipar részéről az lehet, hogy valamiféle szűrőt képezzenek. De ezt sem látják el valami fényesen egyrészt pénzügyi okokból (több diák több pénz), másrészt mert értelmesen szűrni csak értelmes szűrővel lehetne.

Ez poénnak jó. De a fájó dolog az, hogy a "hagyományos" egyetemi oktatás igenis képes lépést tartani a jelennel, viszont ami nálunk folyik, az messze lemaradt a "hagyományos" egyetemi oktatástól. Nézzük csak meg, hány RFC jön az egyetemi szférából, és hány magyar közülük.

Éppen ennek orvoslására jött létre a "kutatóegyetem" státusz. A kontraszelekció és tunyulás visszafordítására tett felülről jövő érdekes kísérlet. Én azért azt mondom, hogy alulról, az egyes emberekből kéne jönnie az igazi változásoknak. (Egy Agile fanboy mit is mondhatna.)