A tesztelés magas absztrakciós szintről történő dinamikus konfigurálásának támogatása a TTCN-3 egyik nagy előnye. Ennek megfelelően az absztrakt kommunikációt végrehajtó alapegységtől kezdve bemutatásra kerülnek a tesztelés egy-egy dinamikusan viselkedő egységét megtestesítő komponensek, az ezeken futó testcase-ek, illetve az időzítésben szerepet játszó timerek, végezetül pedig a dinamikus összeköttetésekről is szó lesz.
Portok
A portok a tesztelés folyamán az egyes identitások közötti kommunikáció eszközei. Alapvetően két típusú portot is támogat a rendszer, egyik az üzenet alapú aszinkron, másik pedig a távoli eljáráshívás koncepciójával működő szinkron port.
A portok full duplex csatornákat definiálnak, üzenet alapú kommunikáció esetén a kiküldendő üzenet bufferezés nélkül azonnal bekerül a fogadó fél FIFO listájába, ahonnan a fogadó által aszinkron módon kerül feldolgozásra.
Port típust az alábbi formában lehet létrehozni:
type port <típusnév> (message|procedure)
{
in <bejövő típusok>
out <kimenő típusok>
inout <be- és kimenő típusok>
}
Teszt komponensek
A tesztkonfiguráció építőelemeinek szerepét a tesztkomponensek töltik be, ezek hajtják végre a teszteket. Tesztkomponensek három különböző szerepet tölthetnek be: Main Test Component (MTC), Test System Interface (system) valamint Parallel Test Component (PTC). Mindhárom szerepben a komponensek portokkal kapcsolódnak egymáshoz, ez a kommunikáció egyetlen formája.
Minden tesztkonfigurációban pontosan egy MTC illetve system komponens van jelen, ezek a teszt indításakor automatikusan jönnek létre, és a teszt központi rendszerét valamint a külvilágot szimbolizálják egy jól meghatározott komponens típus alapján. A tesztelés során használt PTC-k számára nincs megkötés, bármikor szükség szerint létrehozhatóak vagy törölhetőek.
Minden komponens rendelkezik egy belső, verdicttype típusú változóval. Ezen változó értékének módosításával befolyásolhatjuk a teszt kimenetelét. A változó értékét a getverdict() függvénnyel kérhetjük le, valamint a setverdict() függvénnyel módosíthatjuk. A módosításra az alábbi megkötés érvényes: none > pass > inconc > fail > error, azaz amennyiben a beépített verdict már inconc értékű, úgy abból semmiképpen nem lehet pass, ellenben fail vagy error értékre még módosítható.
Komponens típusokat az alábbi módon lehet definiálni:
type component <azonosító>
[extends <komponens azonosító lista>]
{
<változó és konstansdefiníciók>
<portdefiníciók>
}
Komponensek egyfajta származtatására is van lehetősé, ezt az extend kulcsszó segítségével definiálhatjuk. Ciklikus származási lánc és névütközés nem megengedett, fordítás idejű hibához vezet.
Portok és komponensek kapcsolódása
Komponensek összekapcsolása
A tesztkomponensek portjai összekapcsolhatóak más komponensekkel, vagy a tesztelt rendszer interfészével. Két teszt komponens összekapcsolására a connect kulcsszót használhatjuk, míg a teszt rendszerrel történő összekapcsolás esetén a map kulcsszót kell használni. A connect művelet összekapcsolja az egyik komponens portját, a másik komponens portjával, úgy, hogy az egyik in oldalét a másik out oldalához kapcsolja, és fordítva. A map művelet ezzek szemben egyszerű névfordításnak tekinthető, amely megmondja hogyan lehet a kommunikációs streamekre hivatkozni. Mindkét kapcsolódás esetén az összekapcsolandó portok azonosítására az összekapcsolandó komponense referenciáját, és az összekapcsolandó portok nevei szolgálnak. Az mtc a Main Test Componentet jelöli, a system a tesztelendő rendszer interfészét, a self pedig a komponenst saját magát – ezek mint használhatóak a portok összekötésére. A connect, és a map használata előtt az összekapcsolni kívánt komponenseket létre kell hozni (create), és a komponens referenciájunknak ismertnek kell lenni, akárcsak a portok neveinek. Mindkét művelet esetében megengedett a többszörös kapcsolódás, viszont nincs átjárhatóság a két művelet közt, azaz ha connect-el csatlakozik egy port, akkor nem lehet map-elni, és fordítva.
A portok összekapcsolásának mindkét esetben konzisztensnek kell lennie, azaz:
- Feltételezzük, hogy:
- PORT1 és PORT1 összekapcsolandó portok,
- inlist-PORT1 definiálja a PORT1 bemenő üzeneteit vagy eljárásait,
- outlist-PORT1 definiálja a PORT1 kimenő üzeneteit vagy eljárásait,
- inlist-PORT2 definiálja a PORT2 bemenő üzeneteit vagy eljárásait,
- outlist-PORT2 definiálja a PORT2 kimenő üzeneteit vagy eljárásait
- A connect művelet csak akkor engedélyezett ha,
- outlist-PORT1 ⊆ inlist-PORT2 és outlist-PORT2 ⊆ inlist-PORT1
- A map művelet csak akkor engedélyezett (feltéve, hogy PORT2 a test rendszer interfésze), ha:
- outlist-PORT1 ⊆ outlist-PORT2 és inlist-PORT2 ⊆ inlist-PORT1
- Semmilyen más esetben nem engedélyezett az összekapcsolás
- Mivel a TTCN3 dinamikus konfigurációs és címeket használ, ezért a fenti esetek nem ellenőrízhetőek minden esetben fordítási időben. Minden olyan esetben amikor az ellenőrzés nem végezhető el fordítás időben, ellenőrizni kell futásidőben, és testcase hibát kell eredményeznie, amennyiben a fenti feltételek nem teljesülnek.
Komponensek szétkapcsolása
A korábban felépített kapcsolatok bontására a disconnet és az unmap műveletek használhatóak. A disconnet a korábban összekapcsolt komponensek portjai közti kapcsolatot bontja, míg az unmap a test rendszer interfésze, és a komponens portja közti kapcsolatot bontja. Mindkét művelet bármely komponensből hívható, amennyiben ismert az összekapcsolt komponensek referenciája, és a portok nevei. Ezen műveleteknek csak akkor van hatásuk, ha korábban a connect, illetve map műveletet végrehajtottuk az adott komponensek adott portján. Az all port kulcsszó használatával egy komponens összes portjának kapcsolata bontható.
Timerek
Tesztelés során fontos szerepet kap az időzítés kérdése, főleg válaszidő-kritériummal rendelkező rendszerek esetén. Időmérésre a TTCN-3 a timer típust szolgáltatja.
A timer másodpercekben méri az időt, timerek egymástól függetlenek és egyszerű változóként kezeletőek. Létrehozásukkor kezdeti időintervallum értéket kaphatnak, ekkor a paraméter nélküli start() függvény segítségével indíthatjuk őket. Lehetőség van továbbá a start függvény használatára float típusú paraméterrel, ekkor a paraméter a másodpercek számát jelöli.
Timer aktuális állapotát a running függvénnyel, aktuális értékét pedig a read függvénnyel kaphatjuk meg. Timer leállítása a stop függvénnyel történik. Timer blokkoló utasítása a timeout, ez a vezérlést a timer lejártáig blokkolja.
timer T800 := 2.3; T800.start;
timer T1000; T1000.start(1.0);
if(T800.running) {T800.stop;}
T1000.timeout;
Testcase-ek
A testcase fogalma egy speciális függvényt takar, amely mindig a Main Test Component-en fut. Függvényekhez hasonlóan természetesen a testcase is paraméterezhető, modulok control részében az execute() függvény segítségével lehet elindítani. Testcase futásának eredménye minden esetben egy verdicttype típusú érték, mely az MTC illetve az esetleg indított PTC-k beépített verdict-jéből kerül automatikusan meghatározásra a legrosszabb verdict alapján.
Testcase definíció során kötelező megadni az MTC típusát (runs on), illetve opcionálisan megadható a tesztelni kívánt rendszert reprezentáló komponens típusa is (system). Amennyiben ez nincs megadva úgy az MTC típusa lesz a system komponens típusa is.
Testcase az alábbi módon definiálható:
testcase <azonosító> ([formális paraméterlista])
runs on <komponens típus>
[system <komponens típus>]
{
<lokális definíciók és program utasítások>
}
Dinamikus tesztkonfigurálás
TTCN-3-ban a tesztek konfigurálása dinamikus módon történik, azaz a tesztkonfigurációnak minden egyet testcase elején végre kell hajtódnia.
A portok összeköttetése dinamikus, ezek bármikor módosíthatóak illetve törölhetőek csakúgy mint a párhuzamosan indított PTC-k is. PTC megszüntetése esetén a portjaihoz rendelt kapcsolatok automatikusan feloldódnak, ugyanakkor nem összekötött porton türténő üzenetküldés dinamikus futási idejű hibát eredményez (dynamic testcase error).
Tesztrendszeren belüli, komponensek közötti kommunikációra használt portok összekötését a connect() eljárás valósítja meg, míg a tesztrendszer és a tesztelés alatt álló rendszert reprezentáló kommunikációs portokat a map() eljárás kapcsolja össze. Portokat a disconnect() valamint az unmap() eljárással kapcsolhatunk szét.
PTC kreáláshoz a <komponens típus>.create illetve <komponens típus>.create alive függvények használhatóak. Mindkettő mapaméterezhető egyedi azonosítóval (párhuzamos komponens neve) valamint a komponens futtatásának helyére vonatkozó információval (IP-cím, hosztnév, esetleg konfigurációban definiált csoport neve).
var CompType compRef := CompType.create(„CompName”,”192.168.0.1”);
var CompType compRef := CompType.create(„CompName”,”hostgroup6”);
A komponens referencia start függvénye paraméterül egy függvényt kap amely csak in típusú paraméterekkel rendelkezhet, nincs visszatérési értéke és a definíciójában szereplő runs on megfelel a komponens referencia típusának. A create utasítással létrehozott komponens referenciák csak egyszer indíthatóak el, az alive típusúak azonban számtalanszor újrahasználhatóak. Alive típusú komponensen végrehajtott stop utasítás megállítja a komponens futását, de annak belső állapotát megőrzi, míg a kill parancs felszabadít minden erőforrást. Nem alive típusú komponens esetén a stop és a kill parancs hatása megegyezik.
Párhuzamos komponensek állapotát a running illetve alive függvényekkel kérdezhetjük le. Normális PTC esetén a running akkor jelez true értéket ha a komponenst elindítottuk és még nem lett leállítva, az alive pedig akkor, ha a komponenst létrehoztuk és még nem állítottuk le. Alive komponens esetén a running művelet eredménye azonos a normál komponens esetének eredményével, az alive függvény azonban akkor tér vissza true értékkel, ha a komponensen még nem volt kill függvényhívás.
A done függvény blokkol, amíg a komponens futó állapotban van, a killed függvény pedig blokkol amíg az adott komponens él (egyszerű komponensre nem lett meghívva a stop vagy kill, alive komponensre a kill).