1 / 12

40TD23 Test Purpose Language TPLan

40TD23 Test Purpose Language TPLan. STF276 MTS PDT Berlin 17-18 March 2005. Background. Initiated as a “sub-project” out of Patterns Group Taken on by STF256 for IPv6 Testing framework Further refined in STF276 as a “good idea” for IPv6 Conformance and Interoperability Test Purposes

tavon
Download Presentation

40TD23 Test Purpose Language TPLan

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. 40TD23 Test Purpose LanguageTPLan STF276 MTS PDT Berlin 17-18 March 2005

  2. Background • Initiated as a “sub-project” out of Patterns Group • Taken on by STF256 for IPv6 Testing framework • Further refined in STF276 as a “good idea” for IPv6 Conformance and Interoperability Test Purposes • Used successfully in Framework prototype Interop specifications

  3. Current Status • In use (willingly) for all Interoperability Test Purposes in IPv6 Core test specifications • Yet to be accepted as the method of writing IPv6 Core Conformance Test Purposes • For review by the MTS Patterns Group as one means of identifying and characterizing patterns in Test Purposes

  4. Keywords - I • TSS header keywords • author • date • title • version • TP grouping keywords • end • group • id • objective • TP header keywords • config • id • ref • RQ • summary • TC • TD • TP

  5. Keywords - II • TP body keywords • accepts • after • and • before • containing • discards • ensure • EUT • from • ignores • indicating • IUT • not • or • QE (optionally numbered QE1, QE2 etc.) • receives • rejects • sends • set • state • TESTER • that • then • to • when • with • within

  6. Title : 'My TSS&TP as an example' Version : 1.0.0 Date : 29.11.2004-- could also be written as 29/11/2004 Author : 'ETSI STF276‘ Group 1 'Router (RT)'-- some optional free text can go here Objective 'Test Purposes for Router' Group 1.1 ' Router(RT)/Provide IPv6 Services(PS)' Objective 'Test Purposes for Provide IPv6 Services' ... TPs or more subgroups can go here ... End Group 1.1 ... TPs or more subgroups can go here ... End Group 1 Generic Structure - TSS

  7. Generic Structure – TP Body TP id : TP_COR_0001_03 Summary : 'Pad1 option' RQ Ref : RQ_COR_0001 Config : CF_01 TC Ref : TC_COR_0001_03 ensure that { -- start of TP body with { ... } -- initial conditions when { ... } -- actions described from the -- viewpoint of the IUT or EUT. then { ... } -- IUT or EUT responses and other behaviour } -- end of TP body

  8. TP id: TP_COR_0001_02 Summary : 'Autoconfigure EUT using a unique address' RQ Ref:RQ_COR_0001 Config :CF_01 TD Ref: TD_COR_00001_02 ensure that{ with{EUT'configured with a different address to that which will be used by QE1' } when{EUT'has invoked stateless autoconfiguration'} then{EUT'can address the QE' andQE1'can address the EUT'} } Example – Interoperability

  9. Example - Conformance TP id : TP_COR_0047_01 summary : 'aligning PadN option' RQ ref : RQ_COR_0047 config : CF_01_01 TD ref: TD_COR_00047_01 ensure that { when {IUT receives 'Echo Request from TN1' containing 'Hop-by-Hop Options Header' indicating 'Header Ext Length field ZERO' and receives'PadN option' containing 'Opt Data Len field set to 4' and containing'Option Data aligning the Hop-by-Hop Options Header' 'to a multiple of 8 octets' } then { IUT sends 'Echo Request to TN2' } }

  10. Advantages • Common structure makes patterns "easier" to find • Consistence of approach across the project makes TPs easier to read • Forces TP writer to think about TP in terms of: • Pre-conditions (with) • Stimulus (when) • Response (then) • Code-like structure simplifies parsing (scanning)

  11. Disadvantages • Approach not favoured by expert conformance test writers • Unnecessary discipline required • Always managed without it • Need to explain TPLan syntax to non-test readers • Code-like appearance tempts TP writers to abandon abstract descriptions in favour of detailed concrete test specifications

  12. Issues • No certainty that the list of keywords is complete yet • Placing of "ensure that" is wrong (should be in place of "then") • Syntax cannot be considered stable until more experience gained • Advantages cannot be realized within IPv6 project until all TP writers accept it as a good approach • Does the use of TPLan simplify the identification of patterns? • Will tool-makers see the benefits and implement TPLan in or alongside TTCN-3 tools?

More Related