1. 1 Structuring Test Purposes for Pattern Matching Some first thoughts from STF256 Steve Randall TC-MTS, Sophia Antipolis 23-25 March 2004 38TD11ETSI/MTS(04)#38 Sophia Antipolis23-24 March 2004

2. 13-Feb-14TC-MTS#38 23-25 March 2004 038TD11 2 Background Patterns Group identified need for TP structure STF256 preparing ground for IPv6 testing project. Includes: TTCN-3 Library Guidance on methods and style Useful to write TPs in a structured way even if patterns support not available at start of project Short study carried out within STF256

3. 13-Feb-14TC-MTS#38 23-25 March 2004 038TD11 3 TP Format Consideration given to graphical and textual forms GFT/MSC an obvious choice but lacks flexibility to express TP fully Textual pseudo-code has defined structure and flexibility Case studies of existing ISDN and HiperAccess TPs showed that textual approach could work Initial response from experienced testers ranges from not unfavourable to enthusiastic

4. 13-Feb-14TC-MTS#38 23-25 March 2004 038TD11 4 First thoughts on Keywords Case studies identified the following candidates as keywords: acceptscontainingensure thatenters ignoresindicatingon receiptrejects remainssendsthenvalid viawhenwithwithout List is very provisional and will change as project progresses

5. 13-Feb-14TC-MTS#38 23-25 March 2004 038TD11 5 Examples (1a) Original TP: L3U_U00_V_005 subclause 5.2.3.1 Ensure that the IUT in the Null call state U00, on receipt of a valid SETUP message (delivered via the point-to-point data link) with the Channel identification information element indicating a B-channel and indicating in the preferred/exclusive bit "indicated channel is preferred", when no B-channel is available, sends a RELEASE COMPLETE message with a Cause information element indicating the cause value 34 "no circuit/channel available" and remains in the Null call state.

6. 13-Feb-14TC-MTS#38 23-25 March 2004 038TD11 6 Examples (1b) Structured TP: TPID L3U_U00_V_005 base standard ETS 300 403-1 subclause 5.2.3.1 PICS ETS 300 403-3 status mandatory (---) ensure that { when { the IUT is in the Null call state U00 and a valid SETUP message is received via the point-to-point data link with { the Channel identification information element indicating a B-channel and the preferred/exclusive bit indicating "indicated channel is preferred" and no B-channel is available } then { IUT sends a RELEASE COMPLETE message with { a Cause information element indicating cause value 34_ ("no circuit/channel available") } and remains in the Null call state } } }

7. 13-Feb-14TC-MTS#38 23-25 March 2004 038TD11 7 Examples (2a) TP IDSS Reference clause 7.2.4.4; Table 270 Selection criteria Test purpose The IUT has transmitted a valid Auth Info message followed by a valid Auth Request message. It has then received a valid Auth Reply message with a T_AuthGrace and T_AKlifetime values different than the default values in Table 270. The IUT is now authorized. Check that the IUT: For re-authorization, transmits a valid Auth Request message more than (T_AKlifetime – T_AuthGrace) seconds after receiving the Auth Reply but less than T_AKlifetime seconds after receiving the same Auth Reply.

8. 13-Feb-14TC-MTS#38 23-25 March 2004 038TD11 8 Examples (2b) TPID base standard subclause 7.2.4.4; Table 270 PICS status (---) ensure that { when { Negotiate Basic Capabilities is complete and a valid Auth Info message is sent by the IUT and a valid Auth Request message is sent by the IUT and a valid Auth Reply message is received by the IUT with {T_AuthGrace and T_AKLifetime set to non-default values_(Table 270) } } then { IUT sends a valid Auth Request message after (T_AKlifetime – T_authGrace) seconds but before T_AKlifetime seconds }}

9. 13-Feb-14TC-MTS#38 23-25 March 2004 038TD11 9 Examples (2c) TPID base standard subclause 7.2.4.4; Table 270 PICS status (---) ensure that { when { Negotiate Basic Capabilities is complete and IUT is authorized } then { IUT sends a valid Auth Request message after (T_AKlifetime – T_authGrace) seconds but before T_AKlifetime seconds }}

10. 13-Feb-14TC-MTS#38 23-25 March 2004 038TD11 10 Disclaimers! It is important to consider the following when reviewing this proposal: 1.this is at a very, very early stage and has not been discussed widely 2.the list of key words and phrases is sure to grow as more TPs are analyzed 3.the notation is not meant to be a specification language. It is only intended to provide structure (and thus, pattern) to a TP 4.there is neither syntax nor semantics specified (yet) except what can be implied from the examples

11. 13-Feb-14TC-MTS#38 23-25 March 2004 038TD11 11 Next Steps Extend the scope of analysis to a broader range of existing TPs, particularly IPv6, in order to finalize the list of keywords and basic structure Work closely with Patterns Group to ensure the notation meets their requirements Formalize the notation in BNF Discuss possibility of implementation with tool suppliers Start using it!