1 / 11

TPLan A Notation for Specifying Test Purposes

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

bruis
Télécharger la présentation

TPLan A Notation for Specifying Test Purposes

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. TPLanA Notation for Specifying Test Purposes Anthony Wiles, ETSI Steve Randall, PQM Consultants

  2. 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

  3. 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

  4. 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

  5. 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

  6. A Basic Structure • TSS Header • TPs • TP Header • TP Body with { . . } ensure that { when { . . } then { . . } {

  7. User-defined extensions • Enables the user to extend the notation by adding: • Entities • Events • Conditions • Values • Units • Keywords • Syntactical context

  8. 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} }

  9. 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”

  10. 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

  11. 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.

More Related