1 / 11

Structuring Test Purposes for Pattern Matching

38TD11 ETSI/MTS(04)#38 Sophia Antipolis 23-24 March 2004. Structuring Test Purposes for Pattern Matching. Some first thoughts from STF256 Steve Randall TC-MTS, Sophia Antipolis 23-25 March 2004. Background. Patterns Group identified need for TP structure

fontaine-callum
Download Presentation

Structuring Test Purposes for Pattern Matching

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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 TC-MTS#38 23-25 March 2004038TD11

  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 unfavourableto enthusiastic TC-MTS#38 23-25 March 2004038TD11

  4. First thoughts on Keywords • Case studies identified the following candidates as keywords: accepts containing ensure that enters ignores indicating on receipt rejects remains sends then valid via when with without • List is very provisional and will change as project progresses TC-MTS#38 23-25 March 2004038TD11

  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. TC-MTS#38 23-25 March 2004038TD11

  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") } andremains in the Null call state } } } TC-MTS#38 23-25 March 2004038TD11

  7. Examples (2a) TC-MTS#38 23-25 March 2004038TD11

  8. Examples (2b) TPID base standard subclause7.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 }} TC-MTS#38 23-25 March 2004038TD11

  9. Examples (2c) TPID base standard subclause7.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 }} TC-MTS#38 23-25 March 2004038TD11

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

  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! TC-MTS#38 23-25 March 2004038TD11

More Related