ETSI I-ETS 300 697-1-1998 Integrated Services Digital Network (ISDN) Conformance Testing for the Euro-ISDN Programming Communication Interface (PCI) Part 1 Test Suite Structure and .pdf

《ETSI I-ETS 300 697-1-1998 Integrated Services Digital Network (ISDN) Conformance Testing for the Euro-ISDN Programming Communication Interface (PCI) Part 1 Test Suite Structure and .pdf》由会员分享，可在线阅读，更多相关《ETSI I-ETS 300 697-1-1998 Integrated Services Digital Network (ISDN) Conformance Testing for the Euro-ISDN Programming Communication Interface (PCI) Part 1 Test Suite Structure and .pdf（30页珍藏版）》请在麦多课文档分享上搜索。

1、STD.ETS1 I-ETS 300 b97-1-ENGL 1998 m 3400855 O285607 2T9 m Conformance testing for the Euro-ISDN Programming Communication Interface (PCI); Part 1 : Test Suite Structure and Test Purposes (TSS Conformance testing for the Euro-ISDN Programming Communication Interface (PCI): Part 1: “Test Suite Struct

2、ure and Test Purposes (TSS Part 3: “Test Suite Structure and Test Purposes (TSS Part 4: “Abstract Test Suite (ATS) for the Network Access Facility (NAF)“. Announcement date Date of adoption of this I-ETS: Date of latest announcement of this I-ETS (doa): 6 March 1998 30 June 1998 Introduction LETS 30

3、0 697, Parts 1 to 4 comprises the Test Suite Structure and Test Purposes (TSS - part 2 contains the ATS for the PUF; - part 3 contains the TSS - part 4 contains the ATS for the NAF STD-ETSI I-ETS 300 697-L-ENGL 1998 D 3400855 0285bL2 666 D Page 6 I-ETS 300 697-1: March 1998 Part 1 (TSS Programming C

4、ommunication Interface (PCI) for Euro-ISDN“. ISO/IEC 9646 (1 994): “Information technology - Open Systems Interconnection - Conformance Testing Methodology and Framework“. ISOAEC 8208 (1990): “Information technology; Data communications; X.25 Packet Layer Protocol for Data Terminal Equipment“. ETS 3

5、00 080 (1992): “Integrated Services Digital Network (ISDN); ISDN lower layer protocols for telematic terminals“. ETS 300 102-1 : “Integrated Services Digital network (ISDN); User-network interface layer 3; Specifications for basic call control“. ETS 300 406 (1995): “Methods for Testing and Specifica

6、tion (MTS); Protocol and profile conformance testing specifications; Standardisation methodology“. 3 Abbreviations For the purposes of this I-ETS the following abbreviations apply: AD AOC-D AOC-E ATS BV CA ci CLIR CO DA DDI DI ED ED EU EW IC I cs ISDN I UT IV IXIT NAF NC NCO Administration Plane Adv

7、ice Of Charge During call Advice Of Charge at the End of call Abstract Test Suite Valid behaviour Capability tests Control Plane state i Calling Line Identification Restriction Control Plane Data transfer Direct Dialling In Disconnect ion Exchange Mechanism (DOS) Expedited Data Exchange Mechanism (U

8、nix) Exchange Mechanism (Windows) Incoming Call establishment Implementation Conformance Statement Integrated Services Digital Network Implementation Under Test Invalid behaviour Implementation extra Information for Testing Network Access Facility NAF co-ordination Network Connection Object STDDETSI

9、 I-ETS 300 b97-L-ENGL 1998 3400855 0285bL4 439 D Page 8 I-ETS 300 697-1: March 1998 NCOID NMA NU oc OP PC PCI PCTR PP PUF PU RE TE TMA TP TSS TSS - Control Plane (class 1); - User Plane (ISOIIEC 8208 3, ETS 300 080 4, ITU-T Recommendation T.70, NULL, ETS 300 325 l: Transparent Message Access (TMA).

10、The TPs cio not cover the following parts of ETS 300 325 l: - Exchange Mechanism; - - Administration Plane (classes 2, 3); Control Plane (classes 2, 3, 4, 5, 6). 4.2 Choices for coverage Because of the nature of conformance testing, everything cannot be fully tested. In addition, because of the limi

11、tation on the time required for execution of the test suite, further choices have been made. All messages and all mandatory parameters for the elements of the ETS 300 325 l listed above, are tested. Some of the optional functions are tested, .e. in the Exchange Mechanism. Not all optional parameters

12、 have been tested in all of the messages where they are optional, instead a representative sample has been tested where use of the parameter is most likely to occur, e.g. the Facility parameter which deals with charging information is tested in the CConnectReq message and not in the CAlertReq messag

13、e. In addition, the optional Control Plane parameters are tested in the context of the use of supplementary services, if possible. Also more testing is performed in the PUF to NAF direction than in the direction from NAF to PUF because the behaviour of the PUF at the interface can be observed and as

14、signed final verdicts. All parameters relevant for covered parts of ETS 300 325 l, described in the previous subclause, are tested at least once. STD-ETSI I-ETS 300 697-L-ENGL L778 H 3400855 0285635 375 Page 9 I-ETS 300 697-1: March 1998 4.3 Invalid behaviour coverage Although the behaviour of the P

15、UF on receiving messages which are invalid e.g. mandatory parameter missing, is not specified in ETS 300 325 l, a limited number of tests are included in order to check the operation of the PUF. Because ETS 300 325 l does not specify how the PUF shall react to such messages, the verdicts from these

16、tests may only be INCONCLUSIVE or PASS. This topic is further explained in a later clause. 5 Testability of the PUF The lower interface of the PUF is defined in ETS 300 325 l, .e. it is the interface with a NAF, therefore behaviour at this interface can be both controlled and observed without any di

17、fficulty. Since PUFs are application specific, they may vary a lot in their actual implementation. The upper interface of the PUF is not specified in ETS 300 325 l and is a high level interface, e.g. a human interface. The nature of this interface makes testing of the PUF difficult because of the pr

18、oblems observing and controlling the behaviour of the PUF here. Control Where control of the upper interface is necessary in order to initiate some action, the means of control shall be stated in the IXIT in answer to a specific question. The control shall be by means of an implicit send statement i

19、n the test case. Control shall be necessary when the PUF is the initiator of some action, e.g. to initiate a user connection the IXIT asks: how does the IUT send a U3ConnectReq message in order to initiate an outgoing user connection? Observati on Where observation of the upper interface is necessar

20、y in order to assign a verdict, the behaviour which should be observed is stated in the IXIT in answer to a specific question, e.g. how does the IUT react on receiving a CConnectCnf message in state l? In such a case, behaviour at the lower interface cannot be used to assign the verdict because noth

21、ing observable occurs here (e.g. an internal change of NCO state is not observable). This verdict shall be assigned by the test suite operator. If the observation is not that specified in the IXIT, then the only possible verdict shall be an INCONCLUSIVE verdict, as a FAIL verdict cannot be assigned

22、because the PUF has not failed to meet what is stated in ETS 300 325 l. Although it may not be normal practice to rely on observations at such an upper interface, this was the only way found to test many of the messages of the PUF, in particular when the PUF is receiving incoming messages. Sometimes

23、 where no specific observation at the upper interface can be made the IXIT answer could be “IUT does not react“, this might mean that the IUT has not crashed for example. A simple mechanism shall be provided to de-select all test cases relying on observation at the upper interface where such de-sele

24、ction is deemed necessary. These test cases might be optional conformance requirements. The corresponding TPs are marked by the key word “OP“ (optional). However, in most cases, even if the result of a received message is not immediately observable at the lower interface, it is implicitly tested in

25、TPs which deal with other messages. For example, the result of an ACreateNCOCnf message is implicitly tested in Control and User Plane groups: if the IUT is able to manage these planes, this means that it understood the Network Connection Object IDentifier (NCOID) parameter of the previous ACreateNC

26、OCnf. In the same way, if the capability tests for the User Plane (in PUF co-ordination case), pass in case of an outgoing call, this means that the transition to the active state in the Control Plane succeeded. When a “OP“ TP is in fact covered by a TP concerning another message, this shall be indi

27、cated. This may be used as another criterion to de-select it. 6 PUF basic interconnection tests There is no basic interconnection test group in the TSS. However, a list of basic interconnection tests is provided here. These tests may be executed on the IUT prior to execution of the test suite in ord

28、er to give the IUT implementor confidence that the IUT can perform certain basic tasks. The tests have been chosen to check that the IUT can perform simple tasks on each of the three planes, .e. create a Network Connection Object (NCO), set up a D-channel and transfer data on the B-channel. Some ope

29、rations from the Exchange Mechanism are specifically included and other operations from the Exchange Mechanism are exercised in the other test cases. STD-ETSI I-ETS 300 677-3-ENGL 1998 = 3q008-55 0285636 203 Page 10 I-ETS 300 697-1: March 1998 PCI Message ACreateNCOReq ACreateNCOReq CConnect Rsp CCo

30、nnect Req CCon nect Cnf CDisconnect Req CDisconnect Rsp U3Connectl nd U3Connect Req U3DisconnectReq U3DataReq U3Datalnd U1 DataReq UlDatalnd Test case identifier TP411006 TP411008 TP511103 TP511201 TP5 1 1 204 TP5 1 1301 TP5 1 1305 TP611101 TP611201 TP611302 TP611401 TP611402 TP61141 O TP611411 7 Te

31、st Suite Structure (TSS) 7.1 Presentation The test suite is structured as a tree in accordance with ISO/IEC 9646 2. There are two main reasons for structuring the test suite as a tree. Firstly, so that part of the tree can be selected for testing, e.g. the capability tests and secondly, to be able t

32、o see clearly the type of coverage of the base standard that is provided by the test suite. The first level of the tree is the identifier of the ETS, Euro-ISDN PCI, PUF. The second level represents the major divisions of the ETS, .e. the Exchange Mechanism and the three planes. The third level repre

33、sents the nature of the tests to be performed, capability tests which show a basic capability of the ETS to operate, .e. a message containing mandatory parameters only, valid behaviour tests where some additional features are tested, .e. optional parameters, and invalid behaviour tests where the res

34、ponse of the Implementation Under Test (IUT) to invalid behaviour by the tester is checked. The fourth level represents the class of the messages. The fifth level represents the functionality of the ETS covered by the test and is relevant only to the Control and User Planes. The TSS is now detailed.

35、 For each branch a two/four character identifier is given as a number which shall be used to generate unique identifiers for the TPs. First level: it is the identifier of the ETS. Euro-ISDN PCI PUF (PP) Second level: it represents the major divisions of the ETS, the Exchange Mechanism and the three

36、planes: - - - - Administration Plane (AD) (4); - Control Plane (CO) (5); - User Plane (US) (6). Exchange Mechanism (Windows) (EW) (1) Not covered; Exchange Mechanism (DOS) (ED) (2) Not covered : Exchange Mechanism (Unix) (EU) (3) Not covered; Third level: the nature of the tests to be performed: cap

37、ability tests (CA) (1); - STD-ETSI I-ETS 300 b97-1-ENGL 1998 3400855 0285637 148 Page 11 LETS 300 697-1: March 1998 valid behaviour tests (BV) (2); invalid behaviour tests (IV) (3). Fourth level: the class of the messages. This level is not relevant for the Exchange Mechanism. class 1 (Cl) (1); clas

38、s 2 (C2) (2) Not covered ; class 3 (C3) (3) Not covered ; class 4 (C4) (4) Not covered ; class 5 (C5) (5) Not covered; class 6 (C6) (6) Not covered. Fifth level: a functionality of the standard covered by the class (depending on the class). For Control Plane class 1 : incoming call establishment (IC

39、) (1); outgoing call establishment (OC) (2); disconnection (DI) (3). For the User Plane class 1 : groups about incoming and outgoing calls establishment are duplicated, one for PUF co-ordination and one NAF co-ordination (for more details see clause 8). They have the same digit as identifier, but th

40、e type of co-ordination shall be indicated in brackets, at the end of TP identifiers: incoming call establishment, PUF co-ordination (ICPC) (1 PI); incoming call establishment, NAF co-ordination (ICNC) (1 NI); outgoing call establishment, PUF co-ordination (OCPC) (2 PI); outgoing call establishment,

41、 NAF co-ordination (OCNC) (2 NI); disconnection (DI) (3); data transfer (DA) (4); expedited data (ED) (5); reset (RE) (6). 7.2 Coverage This subclause indicates the number of TPs per level. First level: Euro-ISDN PCI PUF: 99. Second level: - Administration Plane: 31; - Control Plane: 32; User Plane:

42、 36. Third level: capability tests: 51; valid behaviour tests: 42; invalid behaviour tests 6. Fourth level: not relevant for coverage aspects. Fifth level: a functionality of the standard covered by the class (depending on the class). For Control Plane class 1 incoming call establishment: 4; outgoin

43、g call establishment: 17; disconnection: 8. - - STD-ETSI I-ETS 300 b97-1-ENGL 1998 m 3400855 0285618 084 m Page 12 I-ETS 300 697-1: March 1998 For the User Plane class 1 : incoming call establishment: 3; outgoing call establishment: 8; disconnection: 4; data transfer: 13; expedited data: 2; reset: 4

44、. NOTE: There are 22 (OP) TPs. 8 Guidelines used for TP generation 8.1 Writing approach In writing the TPs, a uniform approach has been adopted, in order to facilitate their understanding. Common phrases are used throughout all TPs, depending on two cases: - for the TPs where the IUT is the initiato

45、r, .e. control on the upper interface (e.g. test operator action): ensure that the IUT in c initial state, in order to , . - for the TPs where the IUT is not the initiator, .e. control on the lower interface (message from the NAF): ensure that the IUT in on receiving , . initial state, initial state

46、 := Ci I PU I . (see below for more details) goal := ag. initiate an outgoing call . observable-action1 := observable-action2 := I send action := sends (lower interface observation) react action := reacts as stated in IXIT.pper interface observation) message := message containing parameter with enco

47、ded as EXAMPLE: Ensure that the IUT in state CO, in order to initiate an outgoing call activating the Advice Of Charge at the End of the call (AOC-E) supplementary service, sends a CConnectReq message containing the Facility parameter with a FacilityTag field encoded as chargingend and no FaciiityVa

48、iue field. Remarks about initial state: - whenever it is written that the IUT is in state CX, this in fact means that the NCO connection is in state CX. Since there are state diagrams described for both the Control Plane and the User Plane and the same numbers are used in both diagrams, states of th

49、e Control Plane are prefixed with a C, ag. Control Plane, and states of the User Plane are prefixed with a “U“, e.g. U4. When it is necessary to distinguish PUF co-ordination and NAF co-ordination cases, they are prefixed by “PU“ or “NU“, e.g. PU1 is state 1 where PUF co-ordination is present and NU2 is state 2 where NAF co- ordination is present; Page 13 I-ETS 300 697-1: March 1998 - only the state of the tested plane is mentioned. The state of other relevant planes are implicit. For example, if the initial