TDL and TOP can be used in different ways. Depending on the specific goals, different parts of TDL and TOP may be relevant for a given usage scenario. For different starting points and end goals, the following common use cases may come into question:
-[Selected TOP user scenarios](UserScenarios#selected-top-user-scenarios)
-[User control of the analysis level](#sec-user-control-of-the-analysislevel)
-[Using TDL with ASN.1 Specifications](#sec-using-tdl-with-asn-specifications)
-[Unified Definition of Test Puposes and Test Descriptions](#unified-definition-of-test-purposes-and-test-descriptions)
-[Selected TOP user scenarios](UserScenarios.md#selected-top-user-scenarios)
[Open and close specification](#uc1-openclose)
-[User control of the analysis level](UserScenarios.md#sec-user-control-of-the-analysislevel)
@@ -90,9 +89,12 @@ Alternatively these settings can be controlled from the TDL menu shown in [Figur
Reuse of existing TDL specification for which a slight modification is needed to use it in a context. E.g. a package containing TDL type definitions or configuration declarations may be re-used in a specific test specification context. To increase the readability the TDL TOP tool refactoring features may be used.
To use the rename feature, select an instance of an element and from the options when right-click on the mouse select option "Rename Element" (alternatively use key shortcut Alt + Shift + R). Type in the new element name in the dialog box.
In case the selected element is local to a single file the rename feature is executed inline without the Rename Element dialog.
...
...
@@ -103,9 +105,11 @@ In case the selected element is local to a single file the rename feature is exe
The syntax coloring can be set from the "Syntax Coloring" dialog box: Open the "Window" menu and select "Preferences". Select the TDL tool used, ("TDLan2", "TDLtx", or "TDLtxi"), expand the subitems and select "Syntax Coloring".
In the code formatting dialog box the preferences for different syntax elements can be set, see Figure 6.2.3-2.
...
...
@@ -115,9 +119,12 @@ In the code formatting dialog box the preferences for different syntax elements
To use the syntax auto complete feature type in an initial part of a keyword or model element, press "Ctrl + Space", and the syntax auto complete options available in the context are displayed.
<imgsrc="images/SyntaxAutoCompletion.png"alt="Syntax auto complete">
<figcaptionstyle="text-align:center; font-weight:bold">Figure 6.2.3-3: Syntax auto complete example</figcaption>
</figure>
Press "Enter" and the selected text is inserted.
...
...
@@ -127,17 +134,23 @@ Press "Enter" and the selected text is inserted.
The TOP tools support syntax check for the textual and graphical notations defined in the TDL standard. Syntax errors are indicated in the Problems view as well as in the editor as shown in Figure 6.2.3-4.
The TOP tool offers semantic constraints check of a TDL specification. When this check is to be performed can be controlled from the TDL tool bar or the TDL menu item list.
Either the check is performed when the "Validate TDL model" is selected or the check is performed automatically when the TDL model is updated, if the "Automatically validate
TDL model" is selected. In Figure 6.2.3-5 an example of a semantics check is illustrated.
For each of the notations supported by the TOP tools the specific editor provides templates available in the context of the cursor position. The templates available at a given
cursor position are shown when "Ctrl + Space" are pressed. When a template is selected pressing "Enter" inserts the template and allows for parameters to be modified.
An example of templates available in the context of a configuration specification is shown in Figure 6.2.3-6.
<imgsrc="images/TemplatesInContext.png"alt="Templates available in a configuration specification context">
<figcaptionstyle="text-align:center; font-weight:bold">Figure 6.2.3-6: Templates available in a configuration specification context</figcaption>
</figure>
The user may define additional templates for the different editors available in the TOP tool. The template editor is accessed via the "Window" menu item, option "Preferences".
From the Preferences dialog box the specific TOP editor can be selected and user-defined templates be created. Figure 6.2.3-7 illustrates a list of templates defined for the
### 6.2.4 TDL Wizards and Perspective <a name="sec-tdl-wizards-and-perspective"></a>
Wizards provide support to create functional TDL project either with textual or graphical models according to user choice:
1.**User scenario:** Create new TDL project
...
...
@@ -170,32 +189,41 @@ Wizards provide support to create functional TDL project either with textual or
In order to create a new TDL specification:- Select from File menu item New and in the submenu select "Project". In the dialog box "Select a wizard", select the wanted
TDL project, e.g. TDLtx for a textual TDL specification.
Press "Next" and in the dialog box specify a name of the project to be create. If the default location is not to be used, uncheck the "Use default location" and specify
the location of the project.
Figure 6.2.4-2: Creating a new template TDL project
1.**User scenario:** The TOP tool should provide ways to manage diagrams of model elements (create, delete, rename, open).
2.**User scenario:** Visual representation of all model elements should be implemented according to specification.
...
...
@@ -214,18 +242,24 @@ If "Advanced" option is set the following options can be selected:
To define a TDL model using the graphical editor of the TOP tools, select menu "File" and in the menu select "New "and in the sub-menu list select "TDL project" or
use shortcut "Alt-Shift-N". The dialog box shown in Figure 6.2.5-1 appears and a project name can be specified.
Figure 6.2.5-1: Create a new TDL project using the graphical editor
<imgsrc="images/TDLgrNewProj.png"alt="Create new TDL graphical project">
<figcaptionstyle="text-align:center; font-weight:bold">Figure 6.2.5-1: Create a new TDL project using the graphical editor</figcaption>
</figure>
When the "Finish" button is selected the project is created. In the "Project Explorer " select the project, press the right mouse button, and select option
"Create Representation" and the dialog box shown in Figure 6.2.5-2 allow to create a new diagram.
<imgsrc="images/TDLgrNewRepresentation.png"alt="Create new TDL graphical diagram">
<figcaptionstyle="text-align:center; font-weight:bold">Figure 6.2.5-2: Create a new diagram</figcaption>
</figure>
There are two types of diagrams to create:
...
...
@@ -239,15 +273,18 @@ NOTE: Initially it is only possible to create a "Generic TDL" diagram as to crea
The editors for the two types of diagrams provides access to all graphical elements of the TDL language. The textual parameters can be edited either directly in the graphical
element or in the Properties View of a selected element. In Figure 6.2.5-3 the editor for "Generic TDL " diagrams is shown.
Both diagram editors have a pane with all the elements that can be used in the diagram. From the top tool bar a number of general edit functions are available, e.g. select
all elements, show and hide elements. Also from the top tool bar the export diagram as an image file is available. The "Properties" view of the editor allows to define the
textual parameters of a selected graphical element.
The TOP tools support importing external data specifications to TDL data representations with mapping information to the original data specifications. All importers for the
external use the "Translate Input to TDL Model" from the "TDL" menu or alternatively the >T> icon on the TDL tool bar. The generated TDL file depends on the type of project
...
...
@@ -262,7 +299,7 @@ For OpenAPI specifications the TOP tools currently supports:
- Data mappings to the target (Java) data implementation derived from the OpenAPI definitions for executability.
## 8.2 Using TDL with OpenAPI™ Specifications *TO BE MODIFIED*
#### 8.2 Using TDL with OpenAPI™ Specifications <a name="sec-using-tdl-with-openapi-specifications"></a>
### 8.2.1 Overview
...
...
@@ -283,17 +320,26 @@ information in the derived TDL data model. Non-standard formats may be present i
@@ -330,7 +376,9 @@ As an example consider the OpenAPI™ snippet shown in Figure 8.2.2-1 and the de
the 'object's. The 'dataType's for the corresponding 'Member's are then set accordingly. Finally, both source and target (for Java in this example)
'DataElementMapping's are provided.
<figure>
<code>
components:
schemas:
LibraryBook:
...
...
@@ -355,10 +403,14 @@ As an example consider the OpenAPI™ snippet shown in Figure 8.2.2-1 and the de
type: array
items:
$ref: '#/components/schemas/LibraryBook'
Figure 8.2.2-1: OpenAPI™ example including nested anonymous data types
</code>
<figcaptionstyle="text-align:center"><b>Figure 8.2.2-1: OpenAPI™ example including nested anonymous data types</b></figcaption>
</figure>
<figure>
<code>
Type LibraryBook (
String title,
LibraryBook___authors authors,
...
...
@@ -366,13 +418,13 @@ Figure 8.2.2-1: OpenAPI™ example including nested anonymous data types
)
Collection LibraryBook___authors of String
Collection LibraryBook___reviewers of String
Type Library (
String address,
Library___books books
)
Collection Library___books of LibraryBook
Use "mapping_conventions.yaml" as SOURCE_MAPPING
Use "generated/java" as TARGET_MAPPING
Map LibraryBook to "#/components/schemas/LibraryBook"
...
...
@@ -383,8 +435,9 @@ Figure 8.2.2-1: OpenAPI™ example including nested anonymous data types
in SOURCE_MAPPING as Library_SOURCE_MAPPING
Map Library to "Library"
in TARGET_MAPPING as Library_TARGET_MAPPING
Figure 8.2.2-2: Corresponding flattened TDL definitions for Figure 8.2.2-1
</code>
<figcaptionstyle="text-align:center"><b>Figure 8.2.2-2: Corresponding flattened TDL definitions for Figure 8.2.2-1</b></figcaption>
</figure>
...
...
@@ -403,7 +456,7 @@ that they have to be converted to JSON specifications.
ASN.1 data specifications can be converted to a TDL data model. Further details on how to use TDL with ASN.1 data specifications are defined in
**clause 8.3 of the present document**.
## Using TDL with ASN.1 Specifications <aname="sec-using-tdl-with-asn-specifications"></a>
#### Using TDL with ASN.1 Specifications <aname="sec-using-tdl-with-asn-specifications"></a>
8.3
...
...
@@ -417,36 +470,90 @@ When ASN.1 specifications are imported in TDL, the level of detail may vary from
ASN.1 includes a set of built-in types, some of which are mapped to TDL according to the conventions in Table 8.3.1-1. The mapping relies on a TDL library of predefined types and constraints. The generic constraints (ASN1String, ASN1DateTime, ASN1Real, ASN1ObjectIdentifier) may be used to provide additional patterns for the contents of data instances of the corresponding data types to facilitate validation. Alternatively, a tool may implement implicit validation based on the underlying types.
Table 8.3.1-1: ASN.1 Built-in Type Mapping
**ASN.1 Type** | **Type in TDL** | **Constraints** | **Examples and Patterns**
The transformation of ASN.1 data types into TDL data types involves the following conventions:
...
...
@@ -492,71 +599,81 @@ including derived 'DataType's for the nested 'aNode' anonymous 'ContentType', as
'aNode' 'Member' are assigned a 'Constraint' with the 'union' 'ConstraintType'.
<figure>
<code>
NodeDescriptor ::= SEQUENCE
{
aNodeName NodeName, -- Node name
aShortName UUID, -- Short node name
aNode CHOICE
{
aLink SEQUENCE
{
aLinkedFileIdentity NodeIdentity, -- Identity of the linked SSP file
aLinkedFileSize FileSize -- Size of the linked SSP file
},
aFile SEQUENCE
{
aFileSize FileSize -- Size of the SSP file
},
aDirectory SEQUENCE
{
}
},
aMetaData SEQUENCE OF MetaDatum OPTIONAL, -- Optional meta data
aACL SET OF AccessControl OPTIONAL -- Access Control List attribute
}
/* Node identity */
NodeName ::= UTF8String (SIZE(1..16)) -- node name encoded in UTF-8
NodeReference ::= SEQUENCE (SIZE(1..6)) OF NodeName -- pathname and node name
NodeIdentity ::= CHOICE
{
aShortName UUID, -- UUID of file reference using absolute pathname
aNodeReference NodeReference -- Node reference
}
Figure 8.3.2-1: ASN.1 example including nested anonymous data types (excerpt from [i.35])
Type NodeDescriptor (
aNodeName of type NodeName,
aShortName of type UUID ,
aNode of type NodeDescriptor___aNode ,
optional aMetaData of type NodeDescriptor___aMetaData ,
optional aACL of type NodeDescriptor___aACL
);
Type NodeDescriptor___aNode { union } (
aLink of type NodeDescriptor___aNode___aLink,
aFile of type NodeDescriptor___aNode___aFile ,
aDirectory of type NodeDescriptor___aNode___aDirectory
);
Collection NodeDescriptor___aMetaData of type MetaDatum;
Collection NodeDescriptor___aACL of type AccessControl;
Type NodeIdentity { union } (
aShortName of type UUID,
aNodeReference of type NodeReference
);
Collection NodeReference of type NodeName;
Type NodeDescriptor___aNode___aLink (
aLinkedFileIdentity of type NodeIdentity,
aLinkedFileSize of type FileSize
);
Type NodeDescriptor___aNode___aFile (
aFileSize of type FileSize
);
Figure 8.3.2-2: Corresponding TDL definitions (excerpt) for Figure 8.3.2-1
{
aNodeName NodeName, -- Node name
aShortName UUID, -- Short node name
aNode CHOICE
{
aLink SEQUENCE
{
aLinkedFileIdentity NodeIdentity, -- Identity of the linked SSP file
aLinkedFileSize FileSize -- Size of the linked SSP file
},
aFile SEQUENCE
{
aFileSize FileSize -- Size of the SSP file
},
aDirectory SEQUENCE
{
}
},
aMetaData SEQUENCE OF MetaDatum OPTIONAL, -- Optional meta data
aACL SET OF AccessControl OPTIONAL -- Access Control List attribute
}
/* Node identity */
NodeName ::= UTF8String (SIZE(1..16)) -- node name encoded in UTF-8
NodeReference ::= SEQUENCE (SIZE(1..6)) OF NodeName -- pathname and node name
NodeIdentity ::= CHOICE
{
aShortName UUID, -- UUID of file reference using absolute pathname
aNodeReference NodeReference -- Node reference
}
</code>
<figcaptionstyle="text-align:center"><b>Figure 8.3.2-1: ASN.1 example including nested anonymous data types (excerpt from [i.35])</b></figcaption>
</figure>
<figure>
<code>
Type NodeDescriptor (
aNodeName of type NodeName,
aShortName of type UUID ,
aNode of type NodeDescriptor___aNode ,
optional aMetaData of type NodeDescriptor___aMetaData ,
optional aACL of type NodeDescriptor___aACL
);
Type NodeDescriptor___aNode { union } (
aLink of type NodeDescriptor___aNode___aLink,
aFile of type NodeDescriptor___aNode___aFile ,
aDirectory of type NodeDescriptor___aNode___aDirectory
);
Collection NodeDescriptor___aMetaData of type MetaDatum;
Collection NodeDescriptor___aACL of type AccessControl;
Type NodeIdentity { union } (
aShortName of type UUID,
aNodeReference of type NodeReference
);
Collection NodeReference of type NodeName;
Type NodeDescriptor___aNode___aLink (
aLinkedFileIdentity of type NodeIdentity,
aLinkedFileSize of type FileSize
);
Type NodeDescriptor___aNode___aFile (
aFileSize of type FileSize
);
</code>
<figcaptionstyle="text-align:center"><b>Figure 8.3.2-2: Corresponding TDL definitions (excerpt) for Figure 8.3.2-1</b></figcaption>
</figure>
As an example consider the ASN.1 snippet shown in Figure 8.3.2-3 and the derived TDL data type model snippet showing in Figure 8.3.2-4. Corresponding 'StructuredDataType's are
created for both the 'Library' and 'Document' data types, as well as for the nested anonymous 'ContentType's, which are prefixed with 'Library___' and 'Document___' accordingly.
...
...
@@ -567,61 +684,68 @@ values. In TDL it is possible to define a data instance which provides default v
<figcaptionstyle="text-align:center"><b>Figure 8.3.2-3: ASN.1 example including nested anonymous data types</b></figcaption>
</figure>
<figure>
<code>
Type Library (
address of type UTF8String,
documents of type Library___documents
);
Type Document (
title of type UTF8String,
status of type Document___status ,
authors of type Document___authors ,
optional number of type Document___number ,
updated of type Date
);
Collection Library___documents of type Document;
Collection Document___authors of type UTF8String;
Type Document___number { union } (
es of type Integer,
eg of type Integer ,
tr of type Integer
);
Enumerated Document___status {
Document___status draft;
Document___status published;
Document___status historical;
}
Use "example-1-library.asn" as SOURCE_MAPPING;
Map Library to "Library" in SOURCE_MAPPING as Library_MAPPING;
Map Document to "Document" in SOURCE_MAPPING as Document_MAPPING;
</code>
<figcaptionstyle="text-align:center"><b>Figure 8.3.2-4: Corresponding flattened TDL definitions (excerpt) for Figure 8.3.2-3</b></figcaption>
</figure>
#### Using TDL with YANG Specifications <a name="sec-using-tdl-with-yang-specifications"></a>
*TBD*
### Creating test objectives based on TDL meta-model <a name="sec-creating-test-objectives-based-on-tdl-meta-model"></a>
6.2.7
...
...
@@ -631,7 +755,7 @@ The TOP tool editors for the standardised textual syntax in ETSI ES 203 119-8 [i
## Unified Definition of Test Puposes and Test Descriptions<a name="unified-definition-of-test-purposes-and-test-descriptions"></a>
#### Unified Definition of Test Puposes and Test Descriptions<a name="unified-definition-of-test-purposes-and-test-descriptions"></a>
6.7
...
...
@@ -648,58 +772,74 @@ TDL-TO 'EventOccurrence's. Thus, only the notation for 'Behaviour's is available
the configuration and behaviour specifications can be simplified at first, e.g. by using 'Inline Action's which can be refined into more specific
'Behaviour's such as 'Message's over time.
Objective TO_MOVE_OBJECT_UNIFIED {
Description: "Move object to destination with unified test purpose description."
}
Test Purpose Description TP_MOVE_OBJECT_UNIFIED {
Objective: TO_MOVE_OBJECT_UNIFIED
Configuration: basic
Expected behaviour
ensure that {
when {
perform action: "the Controller sends the starting position"
} then {
perform action: "the Object moves to the requested position"
}
}
}
Figure 6.7.1-1: Unified definition of test purposes and test descriptions
Test Purpose Description TP_MOVE_OBJECT_UNIFIED {
Objective: TO_MOVE_OBJECT_UNIFIED
Configuration: basic
Expected behaviour
ensure that {
when {
perform action: "the Controller sends the starting position"
controller::wifi sends "x=21, y=21" to object::wifi
} then {
perform action: "the Object moves to the requested position"
controller::wifi receives "x=21, y=21" from object::wifi
}
}
}
Figure 6.7.1-2: Unified definition of test purposes and test descriptions with refinements
Test Purpose Description TP_MOVE_OBJECT_UNIFIED {
Objective: TO_MOVE_OBJECT_UNIFIED
Configuration: basic
Expected behaviour
ensure that {
when {
perform action: "the Controller sends the starting position"
controller::wifi sends position (x = 21, y = 21) to object::wifi
} then {
perform action: "the Object moves to the requested position"
controller::wifi receives position (x = 21, y = 21) from object::wifi
}
}
}
Figure 6.7.1-3: Unified definition of test purposes and test descriptions with further refinements
<figure>
<code>
Objective TO_MOVE_OBJECT_UNIFIED {
Description: "Move object to destination with unified test purpose description."
}
Test Purpose Description TP_MOVE_OBJECT_UNIFIED {
Objective: TO_MOVE_OBJECT_UNIFIED
Configuration: basic
Expected behaviour
ensure that {
when {
perform action: "the Controller sends the starting position"
} then {
perform action: "the Object moves to the requested position"
}
}
}
</code>
<figcaptionstyle="text-align:center"><b>Figure 6.7.1-1: Unified definition of test purposes and test descriptions</b></figcaption>
</figure>
<figure>
<code>
Test Purpose Description TP_MOVE_OBJECT_UNIFIED {
Objective: TO_MOVE_OBJECT_UNIFIED
Configuration: basic
Expected behaviour
ensure that {
when {
perform action: "the Controller sends the starting position"
controller::wifi sends "x=21, y=21" to object::wifi
} then {
perform action: "the Object moves to the requested position"
controller::wifi receives "x=21, y=21" from object::wifi
}
}
}
</code>
<figcaptionstyle="text-align:center"><b>Figure 6.7.1-2: Unified definition of test purposes and test descriptions with refinements</b></figcaption>
</figure>
<figure>
<code>
Test Purpose Description TP_MOVE_OBJECT_UNIFIED {
Objective: TO_MOVE_OBJECT_UNIFIED
Configuration: basic
Expected behaviour
ensure that {
when {
perform action: "the Controller sends the starting position"
controller::wifi sends position (x = 21, y = 21) to object::wifi
} then {
perform action: "the Object moves to the requested position"
controller::wifi receives position (x = 21, y = 21) from object::wifi
}
}
}
</code>
<figcaptionstyle="text-align:center"><b>Figure 6.7.1-3: Unified definition of test purposes and test descriptions with further refinements</b></figcaption>
</figure>
As shown in Figure 6.7.1-1, the test objective is specified separately and referenced within the test purpose description. The test purpose description itself references a
test confederation and has the familiar expected behaviour pattern with the when and then blocks. For simplicity, stimulus and response can be initially specified as inline
...
...
@@ -708,24 +848,28 @@ but without yet defining and using any the data types, as shown in Figure 6.7.1-
refinement of the behaviour, as shown in Figure 6.7.1-3. Finally, they might even be defined as parameters, as the test purpose description gradually includes sufficient
detail to become executable.
Objective: TO_MOVE_OBJECT_UNIFIED
Test Description TP_MOVE_OBJECT_UNIFIED uses basic {
@Expected behaviour
{
@when
{
perform action : "the Controller sends the starting position"
controller::wifi sends position ( x = 21, y = 21 ) to object::wifi
}
@then
{
perform action : "the Object moves to the requested position"
object::wifi sends position ( x = 21, y = 21 ) to controller::wifi
}
}
}
Figure 6.7.1-4: Representation of Figure 6.7.1-3 using the generic test description syntax
<figure>
<code>
Objective: TO_MOVE_OBJECT_UNIFIED
Test Description TP_MOVE_OBJECT_UNIFIED uses basic {
@Expected behaviour
{
@when
{
perform action : "the Controller sends the starting position"
controller::wifi sends position ( x = 21, y = 21 ) to object::wifi
}
@then
{
perform action : "the Object moves to the requested position"
object::wifi sends position ( x = 21, y = 21 ) to controller::wifi
}
}
}
</code>
<figcaptionstyle="text-align:center"><b>Figure 6.7.1-4: Representation of Figure 6.7.1-3 using the generic test description syntax</b></figcaption>
</figure>
As the unified notation is simply using annotated blocks with specialised syntax, the same structure can also be expressed by using the generic syntax for test descriptions,
as shown in Figure 6.7.1-4. As the test purpose gradually becomes more detailed and more formalised, the annotated blocks could also eventually be dropped or extended with
...
...
@@ -756,7 +900,7 @@ The extended syntax for structured test objectives allows for more complete test
### Generate TD from TO
### Generate TD from TO <a name="sec-generate-td-from-to"></a>
6.2.8
...
...
@@ -775,7 +919,7 @@ As the conversion cannot be completely automated the process on how manual steps
- Generation of TestDescription skeletons based on the EventSequences within the Structured Test Objective with references to it.
- Importing of the base package and imported packages.
### Export to Word
### Export to Word <a name="sec-export-to-word"></a>
6.2.9
...
...
@@ -793,7 +937,7 @@ Textual TDL code can be copied from the TDL editors.
The TOP tools provides a TDL-TO converter for Test Objectives to the Word table format. The TDL-TO converter supports both Structured Test Objectives defined in the example syntax and new the standardised notation. Template files allow to define the layout of the generated Word document. In **clause 5.3.3 in the present document** more information on the TDL-TO converter is defined.
### Conversion to TTCN-3
### Conversion to TTCN-3 <a name="sec-conversion-to-tttn3"></a>
6.2.10
...
...
@@ -804,7 +948,7 @@ with the model to be transformed open. In **clause 6.6 of the present document**
## Defining Structured Test Objectives
## Defining Structured Test Objectives <a name="sec-defining-structured-test-objectives"></a>
6.3
...
...
@@ -839,6 +983,10 @@ re-use of basic data definitions and configurations.
The domain part of a TDL-TO specification defines the PICS elements, entities, and events relevant for a set of TDL TOs.
<figure>
<code>
Domain {
pics:
- NONE
...
...
@@ -863,8 +1011,10 @@ The domain part of a TDL-TO specification defines the PICS elements, entities, a
In Figure 6.3.1-1 an example of a domain specification is shown. The example illustrates the definition of a single PICS value. The example also contains
the definition of a list of entities that can be referenced in test configuration definitions and in event occurrences in the behaviour part.
...
...
@@ -877,11 +1027,16 @@ Finally, the example shows definition of events that may be referenced in the ev
In TDL-TO data may be used in the behaviour part without explicit declaration. However, in the data part of the TDLTO definition structured data types
and structured data values may be specified.
<figure>
<code>
Data {
type DiameterMessage;
}
Figure 6.3.2-1: TDL-TO data definition example
</code>
<figcaptionstyle="text-align:center"><b>Figure 6.3.2-1: TDL-TO data definition example</b></figcaption>
</figure>
Figure 6.3.2-1 illustrates the specification of a single data type.
...
...
@@ -892,6 +1047,10 @@ Figure 6.3.2-1 illustrates the specification of a single data type.
The configurations part of the TDL-TO specification defines by reference the context in which a TDL-TO is to be executed. The Configuration part
may contain any number of test configuration as needed for the TDL-TOs to which it may be associated.
<figure>
<code>
Configuration {
Interface Type defaultGT accepts DiameterMessage;
Component Type DiameterComp with gate g of type defaultGT;
...
...
@@ -912,8 +1071,10 @@ may contain any number of test configuration as needed for the TDL-TOs to which
The configuration part in Figure 6.3.3-1 shows the definition of two test configurations "CF_VxLTE_INT" and "CF_VxLTE_RMI". Both test configurations are
based on the same component type "DiameterComp" and gate type "defaultGT". The 'defaultGT' is specified to accept instances of the datatype 'DiameterMessage'.
...
...
@@ -926,6 +1087,9 @@ The test configurations also specify the role of involved entities, as tester or
The test behaviour defines the behaviour of a TDL-TO to check a single test objective in terms of a sequence of event occurrences in a referenced test
configuration and with data values and timing constraints.
<figure>
<code>
Package TP_RX {
import all from Sip_Common;
import all from Diameter_Common;
...
...
@@ -961,8 +1125,10 @@ configuration and with data values and timing constraints.
A test purpose behaviour example is shown in Figure 6.2.4-1. The test purpose behaviour references the other parts of a TDL-TO, that is the domain,
data and configuration part, that in this example are all imported from the two packages 'SIP_Common' and 'Diameter_Common'.
...
...
@@ -1020,6 +1186,9 @@ illustrates the definition of 'DataType's and 'DataInstance's in TDL-TO. The cor
in Figure 6.4.2-2. Apart from minor syntactical differences, the underlying model structures are the same. In fact, the TOP tools enable cross referencing between
both notations so that data definitions in TDL can be reused in TDL-TO and vice-versa.
<figure>
<code>
Package data {
Data {
type float;
...
...
@@ -1029,9 +1198,14 @@ both notations so that data definitions in TDL can be reused in TDL-TO and vice-
position startingPosition containing x indicating value -21;
}
}
Figure 6.4.2-1: Predefined data example in TDL-TO
</code>
<figcaptionstyle="text-align:center"><b>Figure 6.4.2-1: Predefined data example in TDL-TO</b></figcaption>
</figure>
<figure>
<code>
Package data {
Type float ;
Type position ( x of type float , y of type float ) ;
...
...
@@ -1039,8 +1213,10 @@ Figure 6.4.2-1: Predefined data example in TDL-TO
float -21 ;
position startingPosition ( x = -21 ) ;
}
</code>
<figcaptionstyle="text-align:center"><b>Figure 6.4.2-2: Corresponding data in TDL</b></figcaption>
</figure>
Figure 6.4.2-2: Corresponding data in TDL
TDL-TO permits the use of 'LiteralValue's as a flexible way for specifying the arguments of 'EventOccurrenceSpecification's. This can be useful, especially
at an early stage, where the data structures and contents are not fixed yet. 'LiteralValue's may contain descriptions of the structure and contents of the
...
...
@@ -1057,6 +1233,7 @@ as well. If a 'StructuredDataInstance' is used only once, it is also possible to
<figure>
<code>
when {
the Controller entity sends the start position containing
x indicating value 22,
...
...
@@ -1072,6 +1249,7 @@ as well. If a 'StructuredDataInstance' is used only once, it is also possible to
<figure>
<code>
Package inferred_data {
Type inferred_simple ;
Type inferred_position ( x of type inferred_simple, y of type inferred_simple) ;
...
...
@@ -1102,6 +1280,7 @@ cross referencing between both notations so that definitions related to 'TestCon
<figure>
<code>
Package base_configuration {
import all from data;
Configuration {
...
...
@@ -1121,6 +1300,7 @@ cross referencing between both notations so that definitions related to 'TestCon
<figure>
<code>
Package base_configuration {
Import all from data ;
Gate Type wireless accepts position ;
...
...
@@ -1153,6 +1333,7 @@ merged where applicable to avoid unnecessary duplication.
<figure>
<code>
Package inferred_configuration {
Import all from data
Gate Type inferred_gate_type accepts inferred_position ;
...
...
@@ -1191,6 +1372,7 @@ It is recommended to make opposite entities explicit whenever possible. The seco
<figure>
<code>
Test Purpose {
TP Id TP_MOVE_OBJECT_LITERAL
Test objective "Move object to destination with literal values."
...
...
@@ -1213,6 +1395,7 @@ It is recommended to make opposite entities explicit whenever possible. The seco
<figure>
<code>
Action move_to (position of type inferred_position);
Test Description TD_MOVE_OBJECT_LITERAL uses configuration inferred_move_object {
Controller.inferred_gate sends inferred_start_position to Object.inferred_gate;
...
...
@@ -1229,6 +1412,7 @@ data is specified inline. Since the 'DataInstance' is used twice in this case, i
<figure>
<code>
Action move_to (position of type inferred_position);
Test Description TD_MOVE_OBJECT_LITERAL_INLINE uses configuration inferred_move_object {
Controller.inferred_gate sends new inferred_position (x = 22, y = 21) to Object.inferred_gate;
...
...
@@ -1277,6 +1461,7 @@ the 'dataType's for the corresponding 'Member's in the derived 'SUBSCRIBE_messag
<figure>
<code>
the IUT entity receives a SUBSCRIBE message containing
payload containing
filterLength corresponding to TOPIC_FILTER_LEN_SEC_CVE_01,
...
...
@@ -1289,6 +1474,7 @@ the 'dataType's for the corresponding 'Member's in the derived 'SUBSCRIBE_messag
<figure>
<code>
Data {
UTF8String TOPIC_FILTER_SEC_CVE_01; // topic filter used in TP_MQTT_BROKER_SEC_CVE_001
Int16 TOPIC_FILTER_LEN_SEC_CVE_01; // corresponds to lengthof(TOPIC_FILTER_SEC_CVE_01) + 1
...
...
@@ -1299,6 +1485,7 @@ the 'dataType's for the corresponding 'Member's in the derived 'SUBSCRIBE_messag
<figure>
<code>
Type SUBSCRIBE_message (
payload of type SUBSCRIBE_message_payload
) ;
...
...
@@ -1350,7 +1537,7 @@ is specified for the 'StructuredTestObjective'. The derivation of the 'TestConfi
## Defining Test Descriptions
## Defining Test Descriptions <a name="sec-defining-test-descriptions"></a>
6.5
...
...
@@ -1395,6 +1582,10 @@ has been gaining some popularity, TDL provides more sophisticated facilities bot
'TestDescription' can be invoked multiple times with different data instances as shown in the example in Figure 6.5.3-2. In the 'TC_MOVE_AROUND' 'TestDescription',
the 'TC_MOVE_TO' 'TestDescription is invoked four times to describe a test sequence where the 'Object' needs to move to four positions.
<figure>
<code>
Test Description TC_MOVE_TO (target_position of type inferred_position)
uses configuration inferred_move_object {
Controller.inferred_gate sends parameter target_position to Object.inferred_gate;
...
...
@@ -1408,8 +1599,9 @@ the 'TC_MOVE_TO' 'TestDescription is invoked four times to describe a test seque
Figure 6.5.3-2: Test behaviour reuse in TDL using test description references
</code>
<figcaptionstyle="text-align:center"><b>Figure 6.5.3-2: Test behaviour reuse in TDL using test description references</b></figcaption>
</figure>
## Transforming Test Descriptions into TTCN-3 Test Cases
...
...
@@ -1435,8 +1627,11 @@ mapping within the TOP provides automated translation for the essential parts ne
To illustrate the mapping of the data-related elements, consider the example in Figure 6.6.2-1. It illustrates different data definitions and data uses. The corresponding
equivalents in TTCN-3 are shown in Figure 6.6.2-2. The mappings for data are pretty straightforward in this example. Although the use of data mappings is recommended,
in which case the respective mapping targets are used instead, it is also possible to generate basic data definitions in case no data mappings are present.
Annotations can be used to override assumptions.
Annotations
<figure>
<code>
//data types
Type SESSIONS (id1 of type Integer, id2 of type Integer);
Type MSG (ses of type SESSIONS, content of type String);
...
...
@@ -1456,9 +1651,14 @@ Annotations can be used to override assumptions.
variable v2 of type MSG;
gate g of type gt;
}
</code>
<figcaptionstyle="text-align:center"><b>Figure 6.6.2-1: Test data example in TDL</b></figcaption>
</figure>
Figure 6.6.2-1: Test data example in TDL
<figure>
<code>
//data types
type record SESSIONS {
integer id1,
...
...
@@ -1484,8 +1684,9 @@ Figure 6.6.2-1: Test data example in TDL
var template MSG v2;
port gt g;
}
Figure 6.6.2-2: Test data equivalents for Figure 6.6.2-1 in TTCN-3
</code>
<figcaptionstyle="text-align:center"><b>Figure 6.6.2-2: Test data equivalents for Figure 6.6.2-1 in TTCN-3</b></figcaption>
</figure>
### Configuration
...
...
@@ -1499,6 +1700,9 @@ upfront and remains static. TDL also provides a holistic view where the SUT can
illustrates a minimal test configuration in TDL. The corresponding mapping in TTCN-3 is illustrated in Figure 6.6.3-2. A unified system interface needs to be inferred
in case there are multiple SUT components. The steps for instantiating and mapping/connecting the components are encapsulated in a function.
<figure>
<code>
Gate Type defaultGT accepts
ACK, PDU, PDCCH, C_RNTI, CONFIGURATION ;
...
...
@@ -1511,9 +1715,15 @@ in case there are multiple SUT components. The steps for instantiating and mappi
create SUT UE of type defaultCT ;
connect UE.g to SS.g ;
}
</code>
<figcaptionstyle="text-align:center"><b>Figure 6.6.3-1: Test configuration example in TDL</b></figcaption>
@@ -1540,8 +1750,10 @@ Figure 6.6.3-1: Test configuration example in TDL
TESTER_SS := defaultCT.create;
map (TESTER_SS:g_to_map,system:g_to_map);
}
</code>
<figcaptionstyle="text-align:center"><b>Figure 6.6.3-2: Test configuration related equivalents for Figure 6.6.3-1 in TTCN-3</b></figcaption>
</figure>
Figure 6.6.3-2: Test configuration related equivalents for Figure 6.6.3-1 in TTCN-3
### Behaviour
...
...
@@ -1556,6 +1768,9 @@ of altsteps to handle deviations from the specified behaviour as well as quiesce
test system's point of view is translated to a function as illustrated in Figure 6.6.4-3. Finally, in Figure 6.6.4-4 a test case is defined which takes care of activating
the default behaviour, instantiating the test configuration, as well as starting the actual test behaviour.
<figure>
<code>
Test Description Implementation TD_7_1_3_1
uses configuration defaultTC {
...
...
@@ -1579,9 +1794,14 @@ the default behaviour, instantiating the test configuration, as well as starting
test objectives : TP2 ;
}
}
</code>
<figcaptionstyle="text-align:center"><b>Figure 6.6.4-1: Test behaviour example in TDL</b></figcaption>
