Newer
Older
# User guides
6.1
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)
[Open and close specification](#uc1-openclose)
- [Textual modelling](#textual-modelling)
[Defining structured test objectives (or test purposes) with the help of TDL-TO.]
- Transforming existing structured test objectives in TDL-TO into TDL test descriptions.
- Transforming existing test descriptions in TDL into TTCN-3 test cases.
- Transforming existing test descriptions in TDL into a target execution language (see clause 9).
- Using existing interface specifications in OpenAPI™ with TDL (see clause 8.2).
- Using existing protocol specifications in ASN.1 with TDL (see clause 8.3).
## Selected TOP user scenarios <a name="selected-top-user-scenarios"></a>
6.2
### 6.2.1 Overview
This clause describes a set of user scenarios that illustrate just how the features of the TOP tools can be used for specific testing tasks.
### 6.2.2 User control of the analysis level <a name="sec-user-control-of-the-analysislevel"></a>
<a name="uc1-openclose"></a>
1. **Usage scenario:** The user saves and re-opens an incomplete TDL specification. The incomplete specification and associated analysis results are maintained.
2. **Usage scenario:** Incompatible assignment of types, e.g. assignment of a boolean value to integer type or exceeding the limit of a restricted list type (collection).
3. **Usage scenario:** The user may set the level of analysis performed by TOP tool when developing the TDL test model.
From the TDL toolbar shown in [Figure TDL toolbar](#figure-TDL-toolbar) the analysis level of the specification can be set.
<figure><a id="figure-TDL-toolbar"></a>
<img src="images/TdlToolbar.png" alt="TDL toolbar">
<figcaption><b>Figure: TDL toolbar</b>
</figcaption>
</figure>
The left "V" button sets the constraint validation to be automatically performed when editing the model. The selection mode is shown by marking the button with a darker
shade when constraint validation is active. The rightmost "V" button causes the model to be analysed for syntactical errors. Errors are shown in the editor and in the problem view.
Alternatively these settings can be controlled from the TDL menu shown in [Figure TDL Menu items](#figure-tdl-menu-items).
<figure><a id="figure-tdl-menu-items"></a>
<img src="images/TdlMenuList.png" alt="TDL Menu items">
<figcaption><b>Figure: TDL Menu items</b>
</figcaption>
</figure>
### Textual modelling
6.2.3
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
1. **Usage scenario:** Refactoring and renaming
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.
Figure 6.2.3-1: Rename dialog box
In case the selected element is local to a single file the rename feature is executed inline without the Rename Element dialog.
<ol start=2>
<li> <b>Usage scenario:</b> Code formatting and syntax highlighting</li>
</ol>
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".
Figure 6.2.3-2: Code formatting settings dialog box
In the code formatting dialog box the preferences for different syntax elements can be set, see Figure 6.2.3-2.
<ol start=3>
<li> <b>Usage scenario:</b> Syntax auto complete</li>
</ol>
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.
Figure 6.2.3-3: Syntax auto complete example
Press "Enter" and the selected text is inserted.
<ol start=4>
<li> <b>Usage scenario:</b> Validation results presentation </li>
</ol>
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.
Figure 6.2.3-4: Syntax error presentation
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.
Figure 6.2.3-5: Constraint error presentation
<ol start=5>
<li> <b>Usage scenario:</b> Templates - usage and definition </li>
</ol>
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.
Figure 6.2.3-6: Templates available in a configuration specification context
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
TDLtx editor.
Figure 6.2.3-7: Template dialog box
### 6.2.4 TDL Wizards and Perspective
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
2. **User scenario:** Reference to predefined model elements
3. **User scenario:** Using predefined skeletons
4. **User scenario:** Importing interface specifications
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.
Figure 6.2.4-1: Wizard selection dialog box
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.
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
Figure 6.2.4-2: Creating a new template TDL project
Select "Next" to open the dialog box for select among parameterized TDL textual project templates.
Figure 6.2.4-3: Create new TDL project with support for OpenAPI
Select template "TDLtx" and press "Next" to get further options to configure the TDL project.
Figure 6.2.4-4: Create new TDL project using the advanced options features
In this dialog box the additional properties of the project may be configured.
If "Advanced" option is set the following options can be selected:
- The name of path of the project files
- The imported packages
- The name of the project package, default is "Main"
### 6.2.5 Graphical modelling
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.
3. **User scenario:** All model elements and features should be editable either directly on the diagram or via property view.
4. **User scenario:** Negative validation results should be indicated graphically and linked to problem reports.
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
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.
Figure 6.2.5-2: Create a new diagram
There are two types of diagrams to create:
- "Generic TDL" diagram used to specify the package structure, test descriptions, configurations and data;
- "TDL Behaviour" diagram that defines the behaviour of a test description.
Select the type of diagram to be created, assign a name to the diagram, and press "Finish" to create the diagram.
NOTE: Initially it is only possible to create a "Generic TDL" diagram as to create a "TDL Behaviour" diagram at least one test description is needed.
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.
Figure 6.2.5-3: Generic TDL diagram editor
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.
### 6.2.6 Importing protocol specifications
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
the external specification is imported to. The naming convention for the TDL file generated is the original file name extended with "-generated" and with extension according
to the importing TDL model type.
1. **Usage scenario:** Importing OpenAPI specifications according to ETSI EG 203 647 [i.32].
For OpenAPI specifications the TOP tools currently supports:
- Importing of data definitions under components/schemas.
- Data mappings to the base OpenAPI definition for traceability.
- Data mappings to the target (Java) data implementation derived from the OpenAPI definitions for executability.
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
## 8.2 Using TDL with OpenAPI™ Specifications *TO BE MODIFIED*
### 8.2.1 Overview
The OpenAPI™ Specification [i.31] (previously known as the Swagger Specification) is a notation for the specification of interfaces for RESTful web services.
In addition to data-related information, OpenAPITM specifications also include paths to identify resources by means of URLs, along with applicable operations,
and corresponding request and response specifications. While these can be used to derive skeletons for structured test objectives and test descriptions as
outlined in ETSI EG 203 647 [i.32], within the present document, the focus is solely on data-related information. Further information and guidelines regarding
the use of OpenAPI™ for specification and testing at ETSI can be found in ETSI EG 203 647 [i.32].
In addition to a set of primitive data types, OpenAPI™ provides means for defining structured data types. The specification is an extension of the JSON schema
[i.33]. Data type schemas may be defined inline or in a schemas object which enables reuse of those definitions. In the present document, only the latter is
considered. Future editions may add guidelines for inline data definitions as well.
The built-in primitive types in OpenAPI™ are mapped to TDL according to the conventions in Table 8.2.1-1. The mapping relies on a TDL library of predefined types and constraints.
As OpenAPI™ specifications may include format specifications for types, a generic constraint (OpenAPIFormat) with corresponding quantifiers may be used to capture this
information in the derived TDL data model. Non-standard formats may be present in an OpenAPITM specification as well. The generic constraint can be used for such formats as well.
Table 8.2.1-1: OpenAPI™ Built-in Type Mapping
OpenAPI™ | Type in TDL | Constraints | Formats and Patterns
---------- | ------------- | ------------ | --------------------
integer | integer | OpenAPIFormat | int32, int64
number | String | OpenAPIFormat | float, double
string | String | OpenAPIFormat | e-mail, password
boolean | Boolean | |
A structured type in OpenAPI™ is either an 'array' with member type declaration ('items' object) or an 'object' with a set of properties ('properties' object). Consequently, the transformation of OpenAPI™ data types into TDL data types involves the following conventions:
- If the data type corresponds to one of the primitive data types within the OpenAPI™ library as indicated in Table 8.2.1-1, the 'Type' is mapped to the corresponding 'SimpleDataType' from Table 8.2.1-1.
- If the data type is an 'object', it is mapped to a 'StructuredDataType' with a 'name' corresponding to the name of the OpenAPI™ data type.
- If the data type is an 'array', it is mapped to a 'CollectionDataType' with a 'name' corresponding to the name of the OpenAPI™ data type. The data type indicated in the 'items' object is mapped to the corresponding 'DataType' as the 'itemType' of the 'CollectionDataType'. If 'minItems' and 'maxItems' are specified for the 'array', the corresponding predefined constraints need to be added to the 'CollectionDataType'.
- Each item in the 'properties' object of the 'object' object is mapped to a 'Member' within the corresponding 'StructuredDataType' with a 'name'
corresponding to the property. If a 'Member' with the same 'name' exists, no action is taken. All 'Members are to be marked as optional, except for
'Member's corresponding to properties which are listed in the 'required' array of the 'object'. The 'dataType' of the 'Member' corresponds to:
- A new 'DataType' corresponding to the 'type' of the property with a 'name' prefixed with the 'name' of the containing 'StructuredDataType'
in case a property is of 'type' 'object'.
- A 'SimpleDataType' corresponding to the 'type' of the property in case the 'SimpleDataType' is one of the predefined 'DataType's within the
OpenAPI™ library as indicated in Table 8.2.1-1.
- Nested 'objects are transformed according to the conventions above.
- If the property contains an 'enum' array, it is mapped to an 'EnumDataType' with a 'name' corresponding to the name of the property. The items contained in the 'enum' array
are mapped to 'SimpleDataInstance's of the 'EnumDataType' that are contained in the 'EnumDataType'.
- Corresponding 'DataElementMapping's are created for the defined data types. 'DataElementMapping's for 'DataType's derived from anonymous (inline) data types are not created.
The 'DataElementMapping's may include target platform mappings in addition to the source mappings to the OpenAPI™ specifications.
### 8.2.2 Examples
As an example consider the OpenAPI™ snippet shown in Figure 8.2.2-1 and the derived TDL data type model snippet showing in Figure 8.2.2-2. Corresponding
'StructuredDataType's are created for both the 'Library' and 'LibraryBook' data types, as well as for the nested anonymous 'object's and 'array's, which
are prefixed with 'Library___' and 'LibraryBook___' accordingly. This would also apply to additional anonymous 'object's and 'array's nested further within
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.
components:
schemas:
LibraryBook:
type: object
properties:
title:
type: string
authors:
type: array
items:
type: string
reviewers:
type: array
items:
type: string
Library:
type: object
properties:
address:
type: string
books:
type: array
items:
$ref: '#/components/schemas/LibraryBook'
Figure 8.2.2-1: OpenAPI™ example including nested anonymous data types
Type LibraryBook (
String title,
LibraryBook___authors authors,
LibraryBook___reviewers reviewers
)
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"
in SOURCE_MAPPING as LibraryBook_SOURCE_MAPPING
Map LibraryBook to "LibraryBook"
in TARGET_MAPPING as LibraryBook_TARGET_MAPPING
Map Library to "#/components/schemas/Library"
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
<ol start=2>
<li> <b>Usage scenario:</b> Importing RESTCONF and YANG specifications.</li>
</ol>
The TOP tools support for importing RESTCONF and YANG data specifications is offered by the conversion of JSON specifications. For YANG data specifications this means
that they have to be converted to JSON specifications.
<ol start=3>
<li> <b>Usage scenario:</b> Importing ASN.1 specifications.</li>
</ol>
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
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 <a name="sec-using-tdl-with-asn-specifications"></a>
8.3
### Overview
8.3.1
ASN.1 (Abstract Syntax Notation One) Recommendation ITU T X.680 [i.34] is a standardized language for the specification of data types and data structures. As the name implies, the specifications are abstract and therefore independent of a specific target platform. The specifications provide the information about the structure and encoding of the data which can be processed by generators or compilers to produce data type implementations for the desired target language and platform, including codecs for encoding and decoding the data for transmission. While TDL is not concerned with the encoding and decoding at the specification level, in many cases the test execution platform needs to include codes for the operationalisation of the tests.
When ASN.1 specifications are imported in TDL, the level of detail may vary from the bare essentials, including the data types only, to including additional constraints, and even encoding information (where applicable). The additional information can be utilised for early validation of the TDL specifications. While it is also possible to specify constant values in ASN.1, these are not covered in the guidelines at present.
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**
------------------- | ----------------| --------------| ------------------------------------------------
**BITSTRING** | BITSTRING | ASN1String | "1101'B", also "Named BITS" \(\) : \[0\|1\]\+'B
**OCTETSTRING** | OCTETSTRING | ASN1String | "A3B2'H", "10010'B": \[A\-F\|0\-9\]\+'H
**BMPString** | BMPString | ASN1String | "": 16 bit Character
**IA5String** | IA5String | ASN1String | "Hallo": 8 bit ASCII
**GeneralString** | GeneralString | ASN1String | : all graphic/character sets, SPACE, DELETE
**GraphicString** | GraphicString | ASN1String | : all graphic sets, SPACE
**NumericString** | NumericString | ASN1String | "34 8": \[0-9, SPACE\]\+
**PrintableString** | PrintableString | ASN1String | "Black, Blue \+ Brown": \[a-z,A-Z,'\(\)\+,\-\.?:/=,SPACE\]
**TeletexString** | TeletexString | ASN1String | : CCITT T.101
**T61String** | T61String | ASN1String | : CCITT T.101
**UniversalString** | UniversalString | ASN1String | : ISO10646
**UTF8String** | UTF8String | ASN1String | : ASCII \+ Control
**VideotexString** | VideotexString | ASN1String | : CCITT T.100, T.101
**VisibleString** and <br> **ISO646String** | VisibleString | ASN1String | : ASCII Printing
**UTCTime** | UTCTime | ASN1DateTime | "991231235959\+0200": <br> YYMMDDhhmm\[ss\]Z
**GeneralizedTime** | GeneralizedTime | ASN1DateTime | "20200425175522\.214\+0200" <br> YYYYMMDDHH\[MM\[SS\[\.fff\]\]\]Z \(ISO 8601 \[i\.38\]\)
**DATE** | Date | ASN1DateTime | "1636\-09\-18": <br> YYYY-MM-DD
**TIME-OF-DAY** | TimeOfDay | ASN1DateTime | "18:30:23": <br>
**DATE-TIME** | DateTime | ASN1DateTime | "2000-11-22T18:30:23": <br> YYYY\-MM\-DDThh:mm:ss
**INTEGER** | Integer | |
**REAL** | String | ASN1Real |
**BOOLEAN** | Boolean | |
**NULL** | Null | |
**OBJECT IDENTIFIER** | ObjectIdentifier | ASN1ObjectIdentifier | id-ssp OBJECT IDENTIFIER ::= { itu-t (0) <br> identified-organization (4) etsi (0) <br> smart-secure-platform (3666) part1 (1) }
**RELATIVE OBJECT IDENTIFIER** | ObjectIdentifier | ASN1ObjectIdentifier | Relative_id_ssp RELATIVE-OID ::= <br> { smart-secure-platform (3666) part1 (1) } |
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
The transformation of ASN.1 data types into TDL data types involves the following conventions:
- If the data type corresponds to one of the predefined 'DataType's within the ASN.1 library as indicated in Table 8.3.1-1, the ASN.1 'Type' is mapped
to the corresponding TDL 'SimpleDataType' from Table 8.3.1-1. For the supported ASN.1 types the following additional restrictions apply:
- NULL type is only used in the scope of a Choice type where if there is no information, the corresponding alternative is activated.
- If the ASN.1 data type is a 'SequenceType', a 'SetType', or a 'ChoiceType', it is mapped to a 'StructuredDataType' with a 'name' corresponding to the name of the ASN.1 data type. In the case of 'ChoiceType', a 'Constraint' with the predefined 'union' 'ConstraintType' is applied to the corresponding 'StructuredDataType', and all 'Members are marked as optional.
If the ASN.1 data type is a 'SequenceOfType' or a 'SetOfType', it is mapped to a 'CollectionDataType' with a 'name' corresponding to the name of the ASN.1 data type. The 'Type' indicated for the 'SequenceOfType' or 'SetOfType' is mapped to the corresponding 'DataType' as the 'itemType' of the 'CollectionDataType'.
- Each 'ComponentType' in the 'ComponentTypeList' of the 'SequenceType', 'SetType', or 'ChoiceType' is mapped to a 'Member' within the corresponding 'StructuredDataType' with a 'name' corresponding to the 'identifier' of the 'ComponentType'. If a 'Member' with the same 'name' exists, no action is taken. The 'dataType' of the 'Member' corresponds to:
- A new 'DataType' corresponding to the 'Type' of the 'ComponentType' with a 'name' prefixed with the 'name' of the containing 'StructuredDataType' in case a 'ComponentType' is directly contained within another 'ComponentType'.
- A 'SimpleDataType' corresponding to the 'Type' of the 'ComponentType' in case the 'SimpleDataType' is one of the predefined 'DataType's within the ASN.1 library as indicated in Table 8.3.1-1.
- Nested 'ComponentType's are transformed according to the conventions above.
- If the ASN.1 data type is an 'EnumeratedType', it is mapped to an 'EnumDataType' with a 'name' corresponding to the name of the ASN.1 data type. The contained 'EnumerationItem's are mapped to 'SimpleDataInstance's of the 'EnumDataType' that are contained in the 'EnumDataType'. There are no guidelines for 'NamedNumber's at present.
- Corresponding 'DataElementMapping's are created for the defined data types. 'DataElementMapping's for 'DataType's derived from anonymous (inline) data types are not created. The 'DataElementMapping's may include target platform mappings in addition to the source mappings to the ASN.1 specifications.
For the following built-in types not mentioned in Table 8.3.1-1, the transformations to TDL types are done as follows:
- UnrestrictedCharacterStringType: Replace the CHARACTER STRING type with its associated type obtained by expanding inner subtyping in the associated type of the CHARACTER STRING type (see clause 44.5 of Recommendation ITU-T X.680 [i.34]) to the corresponding TDL type.
- EmbeddedPDVType: Replace any EMBEDDED PDV type with its associated type obtained by expanding inner subtyping in the associated type of the EMBEDDED PDV type (see clause 36.5 of Recommendation ITU-T X.680 [i.34]) to the corresponding TDL type.
- ExternalType: replace the EXTERNAL type with its associated type obtained by expanding inner subtyping in the associated type of the EXTERNAL type (see clause 37.5 of Recommendation ITU-T X.680 [i.34]) to the corresponding TDL type.
- InstanceOfType: Replace the INSTANCE OF type with its associated type obtained by substituting INSTANCE OF DefinedObjectClass by its associated ASN.1 type (see clause C.7 of Recommendation ITU T X.681 [i.36]) and map all ASN.1 types to their TDL types according to Table 8.3.1-1.
### Examples
8.3.2
For example, as shown in Figure 8.3.2-1 and Figure 8.3.2-2, for the 'NodeDescriptor' and related type definitions taken from [i.35], a corresponding 'StructuredDataType' is created,
including derived 'DataType's for the nested 'aNode' anonymous 'ContentType', as well as the 'aLink', 'aFile', and 'aDirectory' anonymous 'ContentType's nested further within the
'aNode' 'ContentType'. The 'dataType's for the corresponding 'Members are then set accordingly. The 'DataType' for the 'NodeIdentity' type as well as the derived 'DataType' for the
'aNode' 'Member' are assigned a 'Constraint' with the 'union' 'ConstraintType'.
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
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.
This would also apply to additional anonymous 'ContentType's nested further within the 'ContentType's. The 'dataType's for the corresponding 'Members are then set accordingly.
The derived 'DataType' 'Document___number' for the 'number' 'ContentType' of type 'CHOICE' is assigned a 'Constraint' with the 'union' 'ConstraintType'. Default values are not
present in the derived TDL data model, as TDL does not support default values for type definitions. However, a data type implementation in the target platform may include default
values. In TDL it is possible to define a data instance which provides default values which can be overridden when the data instance is used. Finally, source 'DataElementMapping's
are provided.
Library ::= SEQUENCE {
address UTF8String DEFAULT "Sophia-Antipolis, France",
documents SEQUENCE OF Document
}
Document ::= SEQUENCE {
title UTF8String (SIZE(1..128)),
status ENUMERATED {draft, published, historical},
authors SEQUENCE OF UTF8String,
number CHOICE {
es INTEGER,
eg INTEGER,
tr INTEGER
} OPTIONAL,
updated DATE
}
Figure 8.3.2-3: ASN.1 example including nested anonymous data types
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;
Figure 8.3.2-4: Corresponding flattened TDL definitions (excerpt) for Figure 8.3.2-3
### Creating test objectives based on TDL meta-model
6.2.7
1. **User scenario:** Use the core TDL syntax for specifying test objectives.
The TOP tool editors for the standardised textual syntax in ETSI ES 203 119-8 [i.20] support the extended syntax for structured test objectives in ETSI ES 203 119-4 [i.16]. Details on how to use one of the TOP tool textual editors to define structured test objectives are described in **clause 6.7 of the present document**.
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
## Unified Definition of Test Puposes and Test Descriptions<a name="unified-definition-of-test-purposes-and-test-descriptions"></a>
6.7
### Overview
6.7.1
With the standardised textual notation for TDL, a new unified syntax was also introduced to allow specifying test purpose-like test descriptions.
Using this notation, users can start from a more abstract test purpose, and gradually add to the necessary details to reach executable specifications,
all while using the same concepts and constructs, without the need to switch and transform between different notations. To achieve this, users can start
with a template provided by the specialised syntax for 'Test Purpose Description's, which contains the necessary behaviour blocks and compartments, which
reflect the structure of a 'Structured Test Objective'. While the structure is near identical, the contents are specified as TDL 'Behaviour's rather than
TDL-TO 'EventOccurrence's. Thus, only the notation for 'Behaviour's is available and data and configuration definitions need to be available. However,
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
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
actions. In this case, the action descriptions are expressed in plain text. At a later stage, the behaviour can be further refined, for example by using message exchanges,
but without yet defining and using any the data types, as shown in Figure 6.7.1-2. Eventually, when the data types are known and defined, they can be used as subsequent
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
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
further annotations. Using this approach, there is no need for transformations between different notations and different conceptual representations. Is that the same model
elements are used to express the full spectrum between more abstract and more concrete behaviour specifications. The level of detail can be refined over time as further
information becomes available.
<ol start=2>
<li> <b>User scenario:</b> Templates for TO backed by TD, also for constituent parts.</li>
</ol>
The TOP tool textual editors provides context sensitive templates for specification of structured test objectives. Further details on how to use templates are described
in **clause 6.2.3. of the present document**.
<ol id="UC_TemplateLibraryForBasiConfigs" start=3>
<li> <b>User scenario:</b> Template library for basic configurations and types.</li>
</ol>
The extended syntax for structured test objectives allows for more complete test purpose specification requiring, e.g. configuration specification. For these elements the TOP tool editors provide a template library is available from the template collection of the editors.
### Generate TD from TO
6.2.8
Lossless conversion of TDL test objectives to test descriptions is generally not possible due to conceptual differences between the formalisms. Some of the discrepancies may be overcome by annotating source (and target) models with appropriate information.
1. **User scenario:** Means to include predefined annotations with TDL models to help guide the conversion process.
2. **User scenario:** Support for TO to TDL conversion according to element annotations or default (non-functional) mappings for cases where annotations are not provided.
3. **User scenario:** Generated test descriptions contain references to test objectives from which they originate.
As the conversion cannot be completely automated the process on how manual steps can support the transformation are defined in **clause 6.4 of the present document**. The TOP tools currently supports:
- Transforming of inline data descriptions within EventOccurrences into corresponding data types.
- Generation of TestConfigurations based on the EventSequences within the Structured Test Objective.
- 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
6.2.9
An essential use case for TDL is its application in producing test specifications, which requires the conversion of models to printable format such as Microsoft Word:
1. **User scenario:** Export TDL diagrams as images.
2. **User scenario:** Export textual TDL test descriptions to be part of a Word document.
3. **User scenario:** Export test objectives as parts of a Word document.
The TOP tool graphical editors provide a function to export the current diagram as an image in the format of the users choice. The function is available via the "camera" button
shown in Figure 6.2.5-3.
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
6.2.10
1. **User scenario:** Conversion of TDL models to TTCN-3 test suites
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
The TOP tools support generation of TTCN-3 according to ES 203 119-6 [i.18]. To use this feature use the T3 button in the TDL tool bar or the TDL Menu item "Transform TDL model to TTCN-3"
with the model to be transformed open. In **clause 6.6 of the present document** further information on the translation can be found.
## Defining Structured Test Objectives
6.3
### Overview
6.3.1
TDL Structured Test Objective (TDL-TO) may be used in several ways in the test developments process. The process illustrated in this clause is based on the
test development process defined in ETSI EG 203 130 (V1.1.1) [i.21]. The TDL-TO specifies a refinement of a 'TestObjective' and defines a formal description of
a test objective, that may be the basis for a transformation to a TDL test description.
Developing a test specification from a base standard the first step after identifying the requirements to be tested, is to define the test objectives.
The entities and events to check the test objectives may then be specified and finally arguments of events (data values) and timing constraints may be
specified. The context in which the required behaviour executes is defined in the test configuration.
Then the parts of a complete TDL-TO specification are:
- Domain part.
- Data.
- Configuration.
- Test purpose behaviour.
The domain, data, and configuration parts are common to a set of test purpose behaviour descriptions, while each test purpose behaviour is specific
to a single test objective. Test purpose behaviours are typically grouped based on different criteria, e.g. test for normal behaviour and test for
invalid behaviour to form a test suite structure. In TDL-TO this structuring is supported by grouping of test purpose behaviours. To further structure
a TDL-TO specification, the domain, data, configuration and test purpose behaviours may be also separated using the TDL package concept, to support
re-use of basic data definitions and configurations.
### Domain part of TDL-TO
6.3.1
The domain part of a TDL-TO specification defines the PICS elements, entities, and events relevant for a set of TDL TOs.
Domain {
pics:
- NONE
;
entities:
- EPC_PCRF_A
- EPC_PCRF_B
- EPC_PGW_A
- EPC_PGW_B
- EPC_MME_A
- EPC_MME_B
- IMS_HSS_A
- IMS_HSS_B
;
events:
- receives
- sends
- triggers
- detachment
- invokes
- create_session_request
- delete_session_request
- termination_SIP_signalling_session
;
Figure 6.3.1-1: TDL-TO Domain example
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.
Finally, the example shows definition of events that may be referenced in the event occurrence parts of TDL-TO behaviour descriptions.
### Data definitions
6.3.2
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.
Data {
type DiameterMessage;
}
Figure 6.3.2-1: TDL-TO data definition example
Figure 6.3.2-1 illustrates the specification of a single data type.
### Configuration
6.3.3
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.
Configuration {
Interface Type defaultGT accepts DiameterMessage;
Component Type DiameterComp with gate g of type defaultGT;
Test Configuration CF_VxLTE_INT
containing
Tester component EPC_PGW_A of type DiameterComp
Tester component EPC_PCRF_A of type DiameterComp
SUT component IMS_A of type DiameterComp
connection between EPC_PGW_A.g and EPC_PCRF_A.g
;
Test Configuration CF_VxLTE_RMI
containing
Tester component EPC_PCRF_A of type DiameterComp
Tester component EPC_PCRF_B of type DiameterComp
SUT component IMS_A of type DiameterComp
connection between EPC_PCRF_A.g and EPC_PCRF_A.g
;
}
Figure 6.3.3-1: TDL-TO configuration example
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'.
The test configurations also specify the role of involved entities, as tester or SUT component.
### Test purpose behaviour
6.3.4
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.
Package TP_RX {
import all from Sip_Common;
import all from Diameter_Common;
Test Purpose {
TP Id TP_RX_PCSCF_STR_05
//TP_EPC_7002_21 from ETSI TS 103 029 V5.1.1
Test objective "Verify that IUT after reception of 486 response sends an ST-Request at originating leg."
Reference
"ETSI TS 129 214 (V15.6.0) [i.27], clauses 4.4.4"
Config Id CF_VxLTE_INT
PICS Selection NONE
Initial conditions with {
the UE_A entity isAttachedTo the EPC_A and
the UE_A entity isRegisteredTo the IMS_A
}
Expected behaviour
ensure that {
when {
the IMS_P_CSCF_A entity receives a 486_Response_INVITE
from the IMS_S_CSCF_A entity
}
then {
the IMS_P_CSCF_A entity sends the STR containing
Session_Id_AVP;
to the EPC_PCRF_A entity
}
}
}
}
Figure 6.3.4-1: TDL-TO behaviour example
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'.
A test purpose is assigned a unique id often reflecting its association within a test suite structure. In this example indicating in the TP name the
interface 'RX', the component 'PCSCF', and the message 'STR' relevant for this TP.
The TDL-TO test purpose allows a reference to the base standard from where the requirement and test objective is derived. The test objective may can be
defined as an informal text string in the field "Test objective". The condition for the applying the test purpose in a test execution can be specified
in "PICS selection" field. The PICS selection expression may consist of a list of PICS references combined by logical operators.
The test configuration 'CF_VxLTE_INT' referenced in the example specifies the test configuration used in the test behaviour specification part.
The event occurrence sequences of the TDL-TO constitutes the core of the test behaviour part. It is split in three optional parts, the initial condition,
the expected behaviour, and final conditions. The example illustrates an initial part where the 'UE_A' and 'IMS_A' entities are brought into the state required
to check the expected behaviour. The events 'isAttachedTo' and 'isRegisteredTo' may be abstract operations which may often be used in the initial phase
of the TDL TO specification, to allow for further refinements in later phases. In the Expected behaviour part the conditional event occurrence sequences
are specified that is assigned the verdict of the test purpose, explicitly or implicitly as is the case in this example. The event occurrences in the example
illustrates the use of undeclared data instances '486_Response_INVITE' and 'STR', where the latter is further specified to contain the data value
'Session_Id_AVP'. In case the test purpose needs to perform operations after the test objective is achieved, such behaviour may be specified in the final
conditions part.
## Transforming Test Objectives into Test Descriptions
6.4
### Overview
6.4.1
Structured test objectives can be used as a starting point for test descriptions or even for executable test cases. As the abstraction gap between structured
tests objectives and executable test cases is often too large, it is recommended to refine the structured test objectives into test descriptions in a stepwise
manner, where at each step there is a smaller abstraction gap in comparison to the preceding step.
While structured test objectives provide many building blocks for a test description, structured test objectives can abstract away many of the important details