110 likes | 260 Views
TPLan A Notation for Specifying Test Purposes. Anthony Wiles, ETSI Steve Randall, PQM Consultants. Why define a Test Purpose Notation?. Consistency Test purposes within a project can have a consistent “look & feel” Framework
E N D
TPLanA Notation for Specifying Test Purposes Anthony Wiles, ETSI Steve Randall, PQM Consultants
Why define a Test Purpose Notation? • Consistency • Test purposes within a project can have a consistent “look & feel” • Framework • TPs generally all written at the same level of detail dictated by the notation • New TP writers can be quickly and easily assimilated into a project • Patterns • Patterns of behaviour can by identified at an early design stage • Repeated patterns are easier to identify if a common notation is used
Requirements for a TP Notation • Must-Haves • Syntactical framework • Structure (Preconditions/Stimulus/Response) • Easy-to-understand keywords • Tool support for syntax checking • Nice-to-Haves • Extensibility • Context-sensitive editing • Tool support for test case stub generation • Must-Not-Haves • Restrictions on users’ ability to express themselves • Unnecessary rules on structure and format
What is TPLan • Notation not a language • “A textual means of representing ideas” • NOT “An artificial language that can be used to control the behaviour of a machine” • Born into communications testing • Initially part of ETSI’s IPv6 test specification project • Developed by communications testing specialists • Minimal keyword set • Revised notation aimed at testing generally • Most communications-specific keywords removed • Extensible into other testing areas • User able to define keywords, entities, events, values, units and conditions • User able to define syntactical context for new keywords
TPLan keywords TSS header: TSS title author date version Cross-ref: xref Definitions: def condition context entity event value units word TP grouping: group end objective TP header: TP id summary config ref role RQ TC TD TP body: ensure that with when then Test entity: IUT TESTER "Glue": a an as in is no of the Logical: and not or Actions: receives sends Data related: containing indicating Direction: from to Time & order: after before ordered within Condition: state
A Basic Structure • TSS Header • TPs • TP Header • TP Body with { . . } ensure that { when { . . } then { . . } {
User-defined extensions • Enables the user to extend the notation by adding: • Entities • Events • Conditions • Values • Units • Keywords • Syntactical context
Example TP TP id : TP_COR_1097_01 Summary : 'EUT processes a packet with its size equals to its link MTU' RQ ref : RQ_001_1097 Config : CF_COR_11 TD ref : TD_COR_1097_01 with{QE1configured'with a unique global unicast address' andEUTconfigured'with a unique global unicast address' andEUT'having a link MTU smaller than the link MTU of QE1' } ensure that { when{EUTreceives apacket'with its size equal to link MTU of EUT'containingQE1as the source_address and containing EUTas the destination_address and containing arequest_for_response} then{EUTsends a valid responsetoQE1} }
Pros and Cons of TPLan • Pros • Provides a structure and framework for developing TPs • Is extensible to suit user’s environment and needs • Is reasonably readable in “English” • Simplifies search and identification of behaviour patterns at a fairly abstract level • Standardized • Cons • Requires discipline within a project to ensure flexibility is not abused • The use of curly braces within the notation can be distracting • It is easy to view it as a programming language which can be “hacked”
Why is it not “Mainstream”? • MTS and the TPLan authors have not done enough to promote the use of the notation • Its extensibility has not been sold to other standardization and testing environments • Its conceptual simplicity masks the fact that TP writing requires skill • Some good examples exist of poor TPLan • It is easy to write rubbish in TPLan! • TPLan is associated solely with Test Purposes and so has a limited market
Possible Extensions to TPLan • Extend the range of the notation beyond TPs to include requirements and assertions • Allow the def context statement to include generic words such as <entity> or <event> • Example:def context {<entity> receives a <event> } • Enable the association of behaviour (semantics) with keywords or groups of keywords.