A megfelelőség vizsgálat (conformance test) arra szolgál, hogy egy berendezés, vagy annak valamely része (pl. egy interfésze) (IUT - implementation Under Test) a vonatkozó előírásoknak (szabványoknak) megfelel-e?
A megfelelőség vizsgálat a vizsgálati hierarchiában a fejlesztői teszteket követi, azaz akkor kerül végrehajtásra, amikor a termék prototípusa elkészül.
| Annak érdekében, hogy a különböző hálózati elemeket gyártók cégek
termékeiből működő hálózatokat lehessen építeni, szabványos protokollokra (kommunikációs szabályrendszerekre) van szükség.
Innen ered az, hogy a megfelelőség vizsgálatok nagy része protokoll vizsgálat.
Rögtön ezután merül fel az igény arra, hogy ellenőrizni tudjuk,
hogy egy termék valóban hibátlanul megvalósít-e egy adott protokollt. Sajnos az a tény, hogy két berendezés sikeresen vizsgázott a megfelelőség vizsgálaton (azaz megfelelő megvalósítás), még nem feltétlenül jelenti azt, hogy egymással képes hibátlanul együttműködni, bár kétségtelenül határozottan növeli ennek az esélyét. A probléma legtöbb esetben abból adódik, hogy a szabványok is tartalmazhatnak nem egyértelmű részeket, annál is inkább, hiszen a legtöbbjük valamilyen természetes nyelven (általában angolul) van leírva. A helyzetet tovább bonyolítja, hogy néha több, egymással megegyezni képtelen gyártó különböző megoldásait emelik szabvánnyá, melyek azonban egymással nem összegeztethetőek. Két vagy több berendezés együttes működését vizsgálja az együttműködési vizsgálat (inter-operability test).
|
A megfelelőség vizsgálat egy műszeres (dinamikus) vizsgálat, melyet a hatályos európai megfelelőségértékelési szabályoknak megfelelően - a termék fejlesztője elvégezhet a saját laboratóriumában, vagy elvégeztetheti ezt egy e vizsgálatokra felkészült (akkreditált) vizsgálólaboratóriumban (pl. TVL) is.
| Legfontosabb jellemzői a következők: egyrészt az OSI rétegmodellre épít, másrészt az egyes megvalósításokat "fekete doboznak" tek inti, azaz nem foglalkozik a belső felépítésükkel, csupán a külvilág felé való viselkedésükkel. |
A nyílt rendszerek összekapcsolására szolgáló ISO OSI modell alapján felépített berendezések és azok interfészeinek megfelelőség vizsgálati eljárását az ISO 9646 szabványban rögzítették azaz a szabvány szerinti vizsgálat is szabványosított.
Az ISO 9646 szabvány:
A korszerű berendezés és interfész szabványoknak integráns része a PICS proforma (űrlap). Példa: ATM: ATM UNI 3.1 PICS
Az ISO 9646 a követelményeket a következő osztályokba sorolja:
A PICS informálja a vizsgálót arról, hogy a prototípus készítője mely követelményeket valósította meg a szabványból, vagyis ez a dokumentum a megvalósított opciók és képességek listája. A PICS adatai a vizsgálat számos fázisában kerülnek felhasználásra:
A PIXIT (Protocol Implementation Extra Information for Testing - implementáció vizsgálatára vonatkozó extra információk)
dokumentum tartalmazza az implementáció azon adatait és vizsgálati utasításait, amelyek a dinamikus vizsgálat elvégzéséhez szükségesek.
A korszerű berendezés és interfész szabványoknak integráns része a PIXIT proforma (űrlap). Példa: ATM: ATM UNI 3.1 PIXIT (Annex A)
Az absztrakt szó ebben az esetben azt jelenti, hogy a készlet megvalósítás független, azaz csak elvont utasításokat tartalmaz) mint például "adatcsomag küldése egy adott portra".
|
Egy konkrét példa az ATM UNI 3.1 ATS-ből. A PCO_A!CELL_NR tesztlépést TTCN formában leíró sor egy CELL_NR ATM cella kiküldését írja le a teszter PCO_A portjára (! a küldés jele). Itt még nem mondjuk meg, hogy milyen típusú ez a cella és hol van a port? |
A vizsgálati (teszt) sorozat (készlet) a következő ábrán bemutatott módon hierarchikusan épül fel:
Vizsgálati (teszt) sorozat (készlet) - Test Suite:
Minden vizsgálati sorozatnak önálló célja van, egy meghatározott protokoll-funkció helyes működését hivatott ellenőrizni. Az egyszerűbb követhetőség kedvéért ezek vizsgálati csoportokba vannak strukturálva tetszőleges rétegződési szintszá mmal. Egy vizsgálati sorozaton belül vizsgálati események különböztethetők meg. Ezek a tesztelési művelet alapelemei, egyetlen protokoll adatelem küldését ill. vételét foglalják magukba. A vizsgálati események bármilyen mélységig vizsgálati lé pések formájában modularizálhatók.
A fentieken kívül az ATS sok esetben tartalmaz még további információkat elsősorban az implementálást megkönnyítendő. Ilyenek például a PICS-beli és a PIXIT-beli állítások viszonya a céloknak megfelelő vizsgálati sorozatok kiválasztási mechanizmusával, továbbá egyes időzítési szempontok is ide sorolhatók.
Az ATS szabványos leíró nyelve a TTCN. Maga az ATS közvetlenül nem hajtható végre, a teszteléshez szükség van tehát az ATS átkonvertálására egy olyan formába, amely a teszter által lefuttatható. Ezt a formát hívjuk végrehajtható vizsgálati készletnek (ETS - Executable Test Suite). Az ATS->ETS konverzió lépései:
| Ha rendelkezünk az adott teszterhez TTCN fordítóval, akkor
amennyiben sok időnk van, nem is magyon akarunk tesztelni vagy növelni
szeretnénk ősz hajszálaink számát magunk is elvégezhetjük a fordítást. Gyorsabban célhoz érünk azonban, ha megvesszük a teszterhez a gyártó által fordított tesztkészletet, melyhez a gyártó menüket is ad a tesztek kiválasztásához és paraméterezéséhez. Egy ilyen integrált tesztprogram a fentiek mellett lehetővé teszi a futtatás követését (monitorozás) és a teszt végén elkészíti a vizsgálati jelentéseket is. |
Egy vizsgálati eset lefuttatása esetén a következő eredmények születhetnek:
Az absztrakt vizsgálati készletek megírásának egyik lehetséges, az ISO 9646-os szabvány által kidolgozott nyelve a TTCN (Tree and Tabular Combined Notation - Fa és táblázat kombinált jelölésrendszer). E nyelvben egy tesztkészlet (tesztprogram) teszt eseteit (eljárások) és a hozzá tartozó deklarációs részt is táblázatokba szervezve írják le. A táblázatokat ezután egy (teszt)fába szervezik. A teszt futtatásakor a fa ágain végighaladva, a teszt elvégezhető.
A nyelv kidolgozása az alábbi szempontok figyelembevételével történt:
|
A TTCN kétféle formátummal rendelkezik:
|
Egy TTCN-ben megírt szabványos tesztkészlet négy jól elkülöníthető részre (táblázat osztályra) tagolódik:
ezek a függelékben kerülnek részletes bemutatásra.
Példa egy teszt eset TTCN-ben való leírására:|
Test Case Dynamic Behaviour |
|||||
|
Test Case Name: VER_VPGroup: General/ Purpose: Verify, that the IUT supports point-to-point VP connectivity. Default: Comments: Requires a VP connection. Ref. 3.1, 1.5/PICS 3.3.1 |
|||||
|
Nr |
Label |
Behaviour Description |
Constraints Ref |
Verdict |
Comments |
|
1 2 3 4 5 6 7 |
LB1 |
PCO_A!CELL_NR START T_Test PCO_B?CELL_NR PCO_B?CELL GOTO LB1 ?TIMEOUT T_Test PCO_B?OTHERWISE |
CELL_SQ(...)
CELL_SQ(...) CELL_UNASSIGN. |
P
F F |
|
|
Detailed Comments : Selection Ref: VP_SERV |
|||||
A példa az [1] a TTCN leírás negyedik, "dinamikus" részéből való. A nyelvvel való ismerkedést egyébként is itt érdemes kezdeni, mert ez hordozza a legtöbb információt. Nézzük tehát, mi látszik a fenti részből:
Ez utóbbit a következőképpen kell értelmezni:
A. Függelék: A TTCN részletesebben
A különböző protokoll szabványok implementációi sokféleképpen lehetnek beágyazva a rendszer egészébe, így ezek különböző vizsgálati módszereket igényelnek. Ezen okból kifolyólag az ISO 9646-2-es szabvány a vizsgálati módszerek egy halmazát definiálja, amelyek mindegyike magába foglal egy teszt-konfigurációt, PCO-típusokat (Point of Control and Observation – vezérlés és vizsgálat pontja), és vizsgálat koordinációs lehetőségeket.
Ez a halmaz lefedi a lehetséges protokoll implementáció / vizsgált rendszer (SUT – System Under Test) párokat, a feladat ezek közül a helyes módszer kiválasztása. Az absztrakt vizsgálati módszert (Abstarct Test Method, ATM) a következő szempontok határ ozzák meg :
Az OSI által szabványosított megfelelőség vizsgálati koncepciók az ismert hétrétegű referenciamodellre épülnek. A különböző absztrakt vizsgálati módszereket az különbözteti meg egymástól, hogy az IUT mely pontján lehet azt vezérelni, illetve vizsgálni, azaz hová helyezhető(k) el a PCO(k). A szabvány értelmében a PCO-k úgy tekintendők, mint két várakozási sor. Az egyik a IUT felé küldendő események sora, a másik pedig az onnan vett események sora. Ezen vezérlő, és vizsgáló események kombinációja határoz za meg az IUT-nek a vizsgáló által észlelt működését. A szabvány alapvetően két vizsgálati környezet sémáját vázolja fel:
A mérés jellegéből következően (egyszerre egy kapcsoló vizsgálata) az előbbi sémát használjuk. Ennek lehetséges három módszerét röviden, illetve a gyakorlat során használt negyediket hosszabban ismertetem az alábbiakban. Ehhez előbb röviden értelmezzük a szükséges fogalmakat:
PDU : Protocol Data Unit, protokoll adatelem
ASP: Abstract Service Primitiv, a PCO-kon használt absztrakt szolgálati primitívek.
UT: Upper Tester, mely az IUT által nyújtott szolgálatokat a felső protokoll réteg határ felől közelítő vizsgáló
LT: Lower Tester, mely az IUT alsó rétegek felé tanúsított viselkedését ellenőrzi.
TCP: Test Coordination Procedure, vizsgálat koordinációs módszerek, melyek az összehangolt vizsgálatot biztosítják.
TMP: Test Management Protocol (vizsgálat menedzselési protokoll), mely tulajdonképp egy szabványosított TCP.
Tehát először a három, általunk jelenleg nem használt vizsgálati módszerről ejtsünk röviden szót:
Lokális vizsgálati módszer: Itt van a legnagyobb lehetőség az IUT közvetlen megfigyelésére, ehhez azonban laboratóriumi körülmények szükségesek, melyek a gyakorlati életben azonban igen nehezen megvalósíthatók. Ebben az esetben a PCO-kat mind az alsó, és a felső szolgálati határoknál meg tudjuk figyelni. Az UT a vizsgált rendszerben van, a TCP-k teljes egészükben a vizsgálóban vannak megvalósítva.
Elosztott vizsgálati módszer: Ez a módszer sokban hasonló az előzőhöz, a lényeges különbségek a következők: Az UT átkerült a SUT-ba, amely egyben koordinációs eljárások alkalmazását is megkívánja (TCP). Az UT megvalósítása történhet emberi közre működés által, vagy szoftverből. E módszer hátránya, hogy közvetlen beavatkozás szükséges a vizsgált rendszerbe, azaz a SUT-be.
Koordinált vizsgálati módszer: Ez a módszer megoldást nyújt abban az esetben, ha az IUT felső szolgálati rétegéhez nem lehet hozzáférni. A koordinációs módszereket szabványosított formában (TMP) valósítják meg, az UT ekkor egy konkrét implementá ciója a TMP-nek az adott SUT-n belül. Az ATS-t éppen ezért ki kell egészíteni olyan vizsgálati sorozatokkal, melyek ellenőrzik, hogy az UT alkalmas implementációja-e a TMP specifikációnak.
A távoli vizsgálati módszer:
A módszer modellje a következő ábrán látható:
A távoli vizsgálati módszernél hiányzik az UT, annak feladatait részben a vizsgálat alatt álló rendszer (SUT) átvállalhatja. A konformancia követelményeket leíró absztrakt vizsgálati készletben csupán a vizsgálat koordinációs módszereinek a megkívánt hatása kerül rögzítésre: erre utalnak a szaggatott vonalak az UT, és TCP körül. Az alsó vizsgálónak (LT) lehetőség szerint meg kell próbálnia végrehajtani a TCP eljárásokat a PIXIT-ben leírt információk szerint, amire viszont a lehetőségek kétségkívül kor látozottak az UT hiánya miatt. A vizsgálati sorozatban rögzíteni kell az alsó vizsgáló által észlelhető ASP-k, és PDU-k formájában a vizsgált rendszer (SUT) megkívánt működését.
Ennek a módszernek a legkisebb a hibafelismerő képessége, de jelen esetben csak ezt lehet megvalósítani, mert nincs lehetőség a rendszerbe való közvetlen beavatkozásra. Ez a legtöbb esetben igaz, így ez a legelterjedtebb absztrakt vizsgálati módszer.
Egy adott rendszer megfelelőségének eldöntésében utolsó lépésként a tesztlabor a vizsgálati eredményeket a Rendszer megfelelőség vizsgálati jegyzőkönyvben (SCTR - System Conformance Test Report), és egy vagy több Protokoll megfelelőség vizsgálati jegyz őkönyvben (PCTR - Protocol Conformance Test Report) foglalja össze. A PCTR az egyes vizsgálati sorozatok eredményeit tartalmazza hivatkozva a megfelelőség vizsgálati dokumentumokra (PICS, PIXIT). Ezt a típusú jegyzőkönyvet minden az IUT-ben implementált, és tesztelt protokollra elkészítik. Az SCTR a vizsgálat során meghozott ítéletek (siker, hiba, vagy nem eldönthető) összefoglalása, melyek az adott SUT megfelelőségét értékelik.
A vizsgálati jelentések szerkezetét is szabvány (ISO/IEC 9646) írja elő. Egy komplett vizsgálati jelentés (jegyzőkönyv) struktúrált, több részből (kötet) áll:
| Név | Jel | Leírás | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| System Conformance Test Report - Rendszer megfelelőségi jegyzőkönyv - (Egyezőség vizsgálati jegyzőkönyv) | SCTR |
A vizsgálatok áttekintő, összefoglaló jegyzőkönyve. Az SCTR tartalmaz információkat magáról az SCTR-ről, a vizsgáló laborról, a kliensről, a SUT-ról. Ezeken kívül lefekteti a pótlólagos, a műszaki tartalom, és a jogi kötelezettség szempontjából fontos korlátozásokat. A dokumentum második része tartalmazza a vizsgálat, és annak eredményeinek összefoglalását, az utóbbit csak összefoglaló jelleggel. Az SCTR-nek két részletezése van: CTPI, PCTR | ||||||||||||
| Client Test Preparation Information - Ügyfélcsomag | CTPI |
A vizsgálatot megrendelő által a vizsgálathoz adott adatok, információk jegyzőkönyve
A CTPI három melléklettel rendelkezik:
| ||||||||||||
| Protocol Conformance Test Report - Protokoll megfelelőségi jegyzőkönyv - (Protokoll egyezőség-vizsgálati jegyzőkönyv) | PCTR |
Az elvégzett vizsgálatok jegyzőkönyve OSI rétegenként.
Ezt a vizsgáló tölti ki, a kiválasztott tesztsorozatokkal elvégzett vizsgálatok alapján. A PCTR három melléklettel rendelkezik:
|