Embed Size (px)
Citation preview
Lappeenranta University of Technology
Faculty of Technology Management
Department of Information Technology
Bachelor of Science thesis
Arne Pajunen
Test Campaign Parameter Editor for
a Graphical TTCN-3 Development Environment
This work will be examined by D.Sc. (Tech) Erja Mustonen-Ollila
ii
TIIVISTELMÄ
Lappeenrannan teknillinen yliopisto
Teknillistaloudellinen tiedekunta
Tietotekniikan osasto
Arne Pajunen
Test Campaign Parameter Editor for a Graphical TTCN-3 Development Environment
Kandidaatintyö
2009
29 sivua, 7 kuvaa, 0 taulukkoa ja 1 liitettä.
Tarkastajat: D.Sc. (Tech) Erja Mustonen-Ollila
Hakusanat: TTCN-3, OpenTTCN IDE, testiparametri, konformanssitestaus.
Tässä kandidaatintyössä esitetään suunnitelma graafisesta parametrieditorista Testing and
Test Control Notation 3 (TTCN-3) testiaineistoille. Tämä projekti tehtiin OpenTTCN IDE
ympäristössä, joka on Eclipse alustan päälle rakennettu TTCN-3
ohjelmistokehitysympäristö.
Työssä esitetty suunnitelma toimii lisäämällä testien laukaisukonfiguraatioihin uuden
välilehden parametrieditointia varten. Tämä välilehti näyttää listan testiaineistossa olevista
parametreista ja siitä voi avata editointi-ikkunan eri tyyppisille parametreille. Jokaiselle
TTCN-3:n primitiiviselle tyypille on oma editointiruutu joka tarjoaa työkaluja
helpottamaan tämän tyypin mukaisten arvojen muokkausta.
iii
ABSTRACT
Lappeenranta University of Technology
Faculty of Technology Management
Department of Information Technology
Arne Pajunen
Test Campaign Parameter Editor for a Graphical TTCN-3 Development Environment
Bachelor of Science Thesis
2009
29 pages, 7 figures, 0 tables and 1 appendix.
Examiners: D.Sc. (Tech) Erja Mustonen-Ollila
Keywords: TTCN-3, OpenTTCN IDE, Test Parameter, Conformance Testing.
This paper presents the design for a graphical parameter editor for Testing and Test
Control Notation 3 (TTCN-3) test suites. This work was done in the context of OpenTTCN
IDE, a TTCN-3 development environment built on top of the Eclipse platform.
The design presented relies on an additional parameter editing tab added to the launch
configurations for test campaigns. This parameter editing tab shows the list of editable
parameters and allows opening editing components for the different parameters. Each
TTCN-3 primitive type will have a specific editing component providing tools to ease
modification of values of that type.
iv
OPENING WORDS
I would like to thank the examiner and supervisor of this work D.Sc. (Tech) Erja
Mustonen-Ollila for her assistance and motivation in the making of this thesis.
Arne Pajunen
10. December 2009
1
TABLE OF CONTENTS
1. INTRODUCTION ............................................................................................................. 3
1.1. Background ................................................................................................................. 4
1.2. Objectives and limitations .......................................................................................... 5
1.3. Structure of the study .................................................................................................. 5
2. RESEARCH APPROACH ................................................................................................ 7
2.1. Technology background ............................................................................................. 7
2.2. Test parameterization .................................................................................................. 9
2.3. Survey of pertinent literature ...................................................................................... 9
2.4. Research problem ..................................................................................................... 10
2.4.1. Current state of the system ................................................................................. 11
2.4.2. Desired state ....................................................................................................... 12
3. PROPOSED DESIGN ..................................................................................................... 13
3.1. Design stages ............................................................................................................ 13
3.2. The Design ................................................................................................................ 14
3.2.1. The Parameter editor .......................................................................................... 15
3.2.2. Editor for integer base type ................................................................................ 17
3.2.3. Editor for universal charstring base type ........................................................... 18
3.2.4. Editor for unsupported base types ..................................................................... 18
3.3. Summary ................................................................................................................... 19
4. DISCUSSION .................................................................................................................. 20
5. CONCLUSIONS ............................................................................................................. 22
6. REFERENCES ................................................................................................................ 23
Appendix A. Example of OpenTTCN Tester parameter file. .............................................. 25
2
SYMBOLS
3G 3rd
Generation, a Mobile telecommunications standard
API Application Programming Interface
Eclipse Eclipse is an open-source integrated development environment
EPL Eclipse Public License
ETSI European Telecommunications Standards Institute
GUI Graphical User Interface
HCI Human-Computer Interactions
IDE Integrated Development Environment
ISO International Organization for Standardization
LTE Long Term Evolution, a Mobile telecommunications standard
OpenTTCN IDE OpenTTCN IDE is a development and execution environment for
TTCN-3 test suites based on the Eclipse platform
RCP Rich Client Platform
TCI-TM Test Control Interface – Test Management
TCI-CD Test Control Interface – Coding / Decoding
TRI-SA TTCN-3 Runtime Interface – SUT Adaptor
Trex Trex is an open-source development environment for TTCN-3 test
suites based on the Eclipse platform
TTCN-3 Testing and Test Control Notation 3
WiMAX Worldwide Interoperability for Microwave Access
3
1. INTRODUCTION
This is a Bachelor of Science study on a graphical test campaign parameter editor for a
Testing and Test Control Notation 3 (TTCN-3) development environment. This work is a
design-oriented research project, that is, a constructive research project [1], and has been
made as an internal project at OpenTTCN Oy. The primary research method used in this
study is literature survey.
TTCN-3 is a test specification language standardized by the European
Telecommunications Standards Institute (ETSI). Its primary field of application is black
box conformance testing of telecommunication protocols such as those found in cellular
network base stations.
Conformance testing means verification that a system complies with a specified standard.
Conformance testing is usually performed to certify a system as standards compliant. Some
of the most well-known fields of application for TTCN-3 are in the domain of protocol
conformance. Some example domains are testing of 3rd
Generation (3G) mobile network
base stations and Long Term Evolution (LTE) base stations and handsets. Another field of
applications is wireless network base stations such as Worldwide Interoperability for
Microwave Access (WiMAX). It can be applied to black box testing in other domains as
well.
The objective of this study is the design of a graphical parameter editor for test campaign
parameters. The framework for the design is OpenTTCN IDE, a graphical TTCN-3 test
script development application built atop the Eclipse platform. Eclipse is an open-source
integrated development environment. It can also be used as a platform for building
development environments for new languages. The test compilation and execution
components are based on OpenTTCN Tester for TTCN-3, which is used for building test
systems based on TTCN-3 for specific application domains.
4
1.1. Background
Test suite parameterization is the definition of important options for a specific execution of
the test campaign. In the context of TTCN-3 this is called module parameterization. An
automated test system would want to support different device configurations, such as
different transport mediums or optional features, as well as different hardware
configurations. Without test parameterization this would require different test suites, which
are usually certified. This would create unreasonable monetary overhead for specification
of test suites and make it difficult to standardize them, which is why the TTCN-3 standard
defines test suite parameters.
The TTCN-3 standard defines the use of test parameters, but it leaves the provisioning of
the test parameter up to the implementation. Traditionally these parameters have been
stored in some kind of file format in the test management application and then provided to
the executable test campaign via a standardized Test Control Interface – Test Management
(TCI-TM) Application Programming Interface (API).
In the OpenTTCN Tester for TTCN-3 application module parameters can also be defined
in a file similar in format to TTCN-3 test script and associated directly with a testing
session.
The problem for new users of TTCN-3 or even experienced users getting familiar with a
new test suite is the large amount of test parameters test suites define. A modern test suite
can contain dozens of parameters, which are defined in the TTCN-3 test script. These
parameters can have varying types, such as integer, record or enumeration. A record type is
a structured type similar to the struct type in C-language.
Without a graphical editor for parameters, a user new to a test suite would have to dig
through the TTCN-3 source code to find what parameters there are and which values are
acceptable for each parameter. A graphical parameter editor can do this work for the user,
gathering information about available parameters from the test suite and what are
acceptable values for them and displaying this information in an easy to digest form with a
graphical user interface.
5
1.2. Objectives and limitations
The objective of this study is to design an easy to use test suite parameter editor for the
OpenTTCN IDE development environment. This study will survey existing practice in
defining test parameters and existing works on usability applicable to the project.
The intent is to make a graphical user interface that can present the parameter information
in a fashion suitable for human consumption and modification. The editor will show a list
of possible parameters for a compiled test suite and the user can edit them directly. Editing
of integer values in hex, octal or binary formats would be allowed via a custom editor.
Enumeration parameters can show the acceptable list of enumeration values as well as their
documentation. Complex types such as records could be shown as a tree structure with the
individual elements editable with the editor components suitable for them.
The actual implementation work is left outside the scope of this paper due to scheduling
constraints. The exact interface with the compiled test repository and the physical storage
format are also left outside the scope of this paper, it is simply assumed the required
information can be obtained in some fashion from the other parts of the system. To have
some basis for the editor, the kind of information required will be explained.
The result of this study will be a thesis detailing the findings of the literature survey and
the design of the parameter editor. Some internal documentation for OpenTTCN Oy use
has also been produced and commented upon in the thesis, but as mentioned these will
primarily be outside the scope of this work.
1.3. Structure of the study
Chapter 2 goes through a survey of existing literature on the topics of TTCN-3, test
parameters and ease of use issues in GUIs. The research problem is also explained in
further detail. Chapter 3 explains the method of solution and the design I chose as the
solution. In Chapter 4 the merits of the solution are discussed and problem areas
6
highlighted. Future research directions are also considered. Chapter 5 offers conclusions
gained from this project and summarizes the results.
7
2. RESEARCH APPROACH
This chapter details the necessary background information for the research problem and
technology involved, as well as explains the approach taken for using this information to
solve the problem. A survey of information gleaned from literature is also included.
2.1. Technology background
The primary technology this work is focused on is OpenTTCN IDE, a graphical TTCN-3
test script development application built atop the Eclipse platform. First I will explain what
Eclipse is before proceeding into more detail with OpenTTCN IDE and TTCN-3.
Eclipse is an open-source integrated development environment licensed under the Eclipse
Public License (EPL). It was originally developed to be a modular multiplatform
development environment for Java. Original development work was performed by IBM,
but it has since then been moved under the control of Eclipse Foundation. Eclipse has been
developed with a high focus on ease of use and speed despite being written in Java. It can
also be used as a platform for building development environments for new languages as
well as completely different applications through the Rich Client Platform (RCP). Since its
conception Eclipse has been extended to support development in a plethora of languages,
including C/C++, Python and PHP among others.
OpenTTCN Oy has been developing a proprietary TTCN-3 development plug-in for
Eclipse, released as the OpenTTCN IDE product. OpenTTCN IDE extends the Eclipse
platform to support development of TTCN-3 test scripts. Figure 1 shows an example of
what the IDE looks like. OpenTTCN IDE also includes a test management component for
executing test cases and several features to assist in debugging and ease of use are in the
plans.
8
Figure 1. OpenTTCN IDE main view
The test compilation and execution components are based on OpenTTCN Tester for
TTCN-3. It is a product used for building test systems based on TTCN-3 for specific
application domains and Systems Under Test (SUT). Roughly speaking OpenTTCN Tester
consists of a compiler for TTCN-2, TTCN-3 and ASN.1, a runtime environment for
executing the compiled byte code and a set of Software Development Kits (SDK) for
development of adapters, codecs and test management applications using a set of APIs
standardized in the TTCN-3 family of standards.
The TTCN-3 family of standards specifies the syntax and semantics of the TTCN-3 script,
as well as defines standard APIs for test control (TTCN-3 Control Interface - Test
Management – TCI-TM), transfer encoding (TTCN-3 Control Interface - Coding/Decoding
– TCI-CD) and SUT connectivity (TTCN-3 Runtime Interface - SUT Adaptor – TRI-SA).
9
Various other interfaces are also defined in the standards which that are not explained in
detail here. Readers interested in more detail should refer to the TTCN-3 family of
standards. [2]
2.2. Test parameterization
Test suite parameterization is the definition of important options for a specific execution of
the test suite, often referred to as the test campaign. In the context of TTCN-3 this setting
of options is called module parameterization. An automated test system would want to
support different device configurations, such as different transport mediums or optional
features, as well as different hardware configurations. Without test parameterization this
would require different test suites for each configuration. Standard test suites are usually
certified, and without parameterization this could create prohibitive monetary overhead for
specification of test suites and make it difficult to standardize them. This is why the
TTCN-3 standard defines test suite parameters.
2.3. Survey of pertinent literature
An important field for this study is Human-Computer Interactions (HCI). Papers detailing
the TTCN-3 language also contain useful background on the language as well as test suite
parameterization.
Ease of use is an important topic for this study. When a system is easy to use, it has good
usability. Usability is defined by Part 11 of the ISO 9241 standard as “the extent to which a
product can be used by specified users to achieve specified goals with effectiveness,
efficiency and satisfaction in a specified context of use” [3]. The kind of users who must
be able to use the product must therefore be specified to have a context for usability.
User interface design is a topic that has been examined quite a lot in literature. It is a part
of the field of study called Human-Computer Interactions. The Eclipse platform has its
10
own User Interface Guidelines [4] produced by the eclipse community. The Eclipse project
has also put together a shortlist of the most important and easy to apply user interface
guidelines [5]. These guidelines raise an important design choice for this study: whether to
use a view or editor component to implement the parameter editor.
User interface design has much the same process as traditional software development with
some peculiarities. The most important steps of the design lifecycle are gathering
requirements and construction of use cases [6]. Usability should also be evaluated on real
users.
The TTCN-3 language is specified in a collection of ETSI standards [2]. There are
introductory studies about the language that also explain test suite parameterization [7].
Code quality improvements including automatic module parameterization in the context of
a graphical development environment called Trex are reviewed in [8] and [9].
Recommendations for developing in the Eclipse environment were reviewed as part of this
study [10].
2.4. Research problem
The research question posed in this study is to design an easy to use test suite parameter
editor for the OpenTTCN IDE development environment. This will be accomplished
through basic design practices, as well as by surveying existing practice in defining test
parameters and existing works on usability applicable to the project.
The intent is to make a graphical user interface that can present the parameter information
in a fashion suitable for human consumption and modification. This can be accomplished
by providing suitable tools for editing values of the parameters. The editor will show a list
of possible parameters for a compiled test suite and the user can edit them directly. Editing
of integer values in hex, octal or binary formats would be allowed via a custom editor.
Enumeration parameters can show the acceptable list of enumeration values as well as their
11
documentation. Complex types such as records can be shown as a tree structure with the
individual elements editable with the editor components suitable for them.
2.4.1. Current state of the system
In its current form, OpenTTCN IDE test execution specifies parameters by compiling a file
with a “.par” extension. The format of this file is similar to TTCN-3 source code, with
variable definitions prefixed by modulepar keyword specifying parameter values. An
example of a complete parameter file can be seen in Appendix A. Writing this file requires
the user to look up where the types for the parameters are defined and what kind of values
they accept.
Example of a parameter file specifying the value for an enumeration type parameter
PAR_enum_parameter can be seen in Figure 2. To know the possible values for the
parameter the user would have to look up the file where CustomEnumType is defined and
see which values the enumeration can accept. For a user new to OpenTTCN IDE and new
to TTCN-3 this could prove a daunting task.
module parameters {
import from DemoModule { type CustomEnumType; }
modulepar DemoModule.CustomEnumType PAR_enum_parameter := SELECTED_VALUE;
}
Figure 2. Example of module parameters
12
2.4.2. Desired state
OpenTTCN IDE should be easier for new users to use when the design produced in this
study is implemented. Possible test parameters for a compiled test suite should be gathered
and shown in a graphical editor and the values for these parameters should be editable with
standard user interface components such as combo boxes and lists. The system should
support some level of format conversions, for example integer values could be presented as
binary, hex or octal notation depending on the needs of the domain being tested.
First off the users for whom the system should be easy to use need to be defined. It is
assumed in this study that the users are familiar to some extent with their own domain or
specialty. Users should also possess a passing understanding of what TTCN-3 is. The user
should not however be required to have any explicit knowledge of the TTCN-3
programming language for specifying values of parameters with simple types as long as
they are familiar with the domain for which the test suite is written. For the case of
complex values some understanding of TTCN-3 may be required, but the user interface
should provide assistance to keep the required knowledge to a minimum.
Two distinct user groups need to be addressed for ease of use. First time users new to
OpenTTCN and TTCN-3 testing require aid in getting the test suite running, even if with
default values. Professional users require assistance in the editing of parameter values,
such as through format conversions and gathering of possible enumeration values.
13
3. PROPOSED DESIGN
The design is made to work with the current software architecture of OpenTTCN IDE. The
parameter editor is an extension to one of the Eclipse plug-ins making up OpenTTCN IDE.
It supports the automatic provisioning of parameters for test campaigns and different
configurations inside the same session.
3.1. Design stages
First a brainstorming session was held to gather ideas and possibilities for the parameter
editor within the in-house developer team. The ideas from the developer team were then
used to make a few proposed solutions via user interface mock-ups. One of the presented
mock-ups can be seen in Figure 3. These were then presented to the team for feedback and
the best design (with improvements) was chosen as the one to develop further. Feedback
from real users was also considered during the making of the design.
14
Figure 3. A user interface mock-up that was not chosen for the design.
3.2. The Design
Test campaigns are configured in the OpenTTCN IDE as test campaign launch
configurations. In the original state of the system the parameter values were defined as part
of the compiled test script, but while making this study it was found it would be more
intuitive if the parameters were specified as part of the test campaign launch configuration.
This allows desirable uses such as having different configurations of the same compiled
test suite representing different test system setups with different parameters and also
intuitively solves the problem of selecting which parameters to use for a launch
configuration: the ones saved in that configuration.
15
Choosing the approach of extending the launch configuration bypassed the question of
whether to use an Eclipse editor or view for parameter editing, since neither would be used
and a custom component developed instead. The final design uses a tabular list editor
showing the parameters and their values. Values can be edited in place or double-clicked to
open an editor view for that specific type.
This kind of editor requires some information about the compiled test suite. The list of
parameters is obviously required. Also required is their type information. User defined
types are checked from the test suite repository to find the primitive type they are derived
from, their base type. This allows limiting the editing components required to the primitive
types defined in TTCN-3. Knowing the default value is also required.
This chapter shows the final design for the user interface of the parameter editor. Also
shown are designs for the editing components for some of the base types in TTCN-3.
Shown are the editing components for integer, universal charstring and an editor for types
which do not yet have direct support.
The unsupported type editor is a simple code editor that shows the TTCN-3 code for the
value assigned to the parameter. This allows the editor to be usable right from the start
with the same functionality that the old method of specifying parameters would have had,
so the editor components can be developed iteratively. This kind of modular design suits
very well to the Eclipse environment.
3.2.1. The Parameter editor
The parameter editor tab in a launch configuration shows a view of the possible parameters
in a compiled test suite. You can see an artist’s view of the user interface in Figure 4. The
name of the parameter and the current value is displayed. In addition the type of the
parameter should also be displayed.
At first the values are populated with default values from the compiled test suite, but after
the user makes changes these are saved in the launch configuration. The changed values
should be indicated to the user in some manner and the user should be able to restore them
16
to their default values. The values are validated when the user presses Apply or closes the
dialog to make sure invalid values are not saved.
For compatibility with old storage formats it should be possible to load a parameter file
and have the values in the parameter editor populated from that. This allows the user to
easily migrate from the previous way of defining parameters, in case they were already
using it. Saving should also be allowed to permit the user to export his parameter
definitions to the disk and possibly save them in version control.
Figure 4. The parameter editor for a launch configuration.
The view in Figure 4 could also be presented as a hierarchical tree structure, to group
parameters according to the module and group they are defined in. This would provide
additional context about the meaning of each parameter.
17
3.2.2. Editor for integer base type
The editor for values of integer base type supports editing integer values. Integer values
can be specified as decimal values, but the TTCN-3 language also supports other integer
types closer to the values needed in practical protocols. One example is the hexstring type
which specifies a string comprised of hex digits. Another example would be the octetstring
type which consists of pairs of hex digits forming which represent data bytes. It is also
common in real-world test suites to specify integer values through conversion function,
such as int2hex(42) which specifies the integer value 42, but converts this to a hexstring
type. The editor should naturally understand such notations.
The graphical editor should understand all these formats and display them in a uniform
editor reminiscent of a “hex editor”, a program which allows editing of data in various
formats. Figure 5 shows the editing component design for the integer editor, showing the
hexstring base type parameter pIntValue being edited. The value of the parameter in this
image is 2A which is also shown converted to the other common number formats: hex,
octal, binary and decimal.
Figure 5. The parameter editor for a value with integer base type.
18
3.2.3. Editor for universal charstring base type
String parameters are a bit rarer occurrence in real world test suites, but might be used for
specifying information understandable to the user or for example address data. Figure 6
shows the editing component for string data.
Character strings and encodings always go hand in hand, so the user must specify the
encoding the text is written in. TTCN-3 supports two types of string literals, the first of
which charstring is for ISO-8859-1 encoded text. ISO-8859-1 is more familiarly known as
the ASCII character set. The other string format is universal charstring for UTF-8 encoded
text.
There exists a large number of character encodings in the world and the editing component
should support the user entering text in whatever location in the world they desire. This can
be accomplished by specifying the encoding to the editor so the software can perform
appropriate conversions when saving the text.
Figure 6. The parameter editor for a value with a string type (universal charstring).
3.2.4. Editor for unsupported base types
There are some types in the TTCN-3 language which are more complex to build an editor
for. Examples include the types record, union and anytype. These types are structured
types and as such the editors are difficult to write. Indeed, as the name dictates, the anytype
can accept a value of any type defined in the test suite. The editor implementation for these
19
types is a level of complexity harder than the other primitive types and it might be
desirable to delay implementing full support for these types in a later version.
To address the issue of complex types, it was chosen to implement a generic unsupported
type editor which simply shows the TTCN-3 source code form of the value of the
parameter. The editor for a record type is illustrated in Figure 7.
The choice to include this editor type is in conflict with the desire for ease of use in that its
use requires knowledge of TTCN-3 code, however it was decided that since the other
simpler types are far more common as parameter values it is reasonable to include the
possibility of delaying the more complex editing components to a later version. The
parameter editor will bring significant added value even with a small set of primitive type
editors that are common in test suite parameters. This modular structure of the editor also
allows fast prototyping during implementation by first implementing the unsupported type
editor and then extending with editors for other types.
Figure 7. The parameter editor for a value with an unsupported base type.
3.3. Summary
The design presented here has explained the central ideas for the solution chosen. Further
iterative refinement is sure to happen during the implementation of this design at a later
date, but the implementation stage is outside the scope of this thesis. Overall, the author
feels the design is successful and has potential to achieve the set design goals: Ease of use
for new users and professionals alike and applicability to the existing architecture.
20
4. DISCUSSION
Overall, the author feels the design presented in this paper is successful and has the
potential to achieve the set design goals: Ease of use for new users and professionals alike
and applicability to the existing architecture. The implementation of the design will
continue after this paper as internal work at OpenTTCN Oy.
The design is made to work with the current software architecture of OpenTTCN IDE. It is
an extension to existing plug-ins on the Eclipse platform. It is also moderately easily
implementable and features a backwards compatibility layer to previous methods of
defining test parameters via the unsupported type editing component.
Usability issues were given much consideration in the design. As literature suggested
monitoring and interviewing real users [6], this method was applied during the making of
the design. This was accomplished by including the professional TTCN-3 developers
working at OpenTTCN Oy into the design process. By reviewing with users of the tool
how the editing should be done provided necessary feedback during each iteration of the
user interface design.
The parameter editor was implemented as an Eclipse plug-in extension that works in tight
integration with the OpenTTCN IDE product. The original launch configuration
framework was extended to support the automatic provisioning of parameters for test
campaigns and different configurations inside the same session.
There are some future directions raised during this design that needs considering. One is
the possibility of adding an extension API to the parameter editing framework for user
defined types and domain specific types. Some test suites contain parameters that define
some important domain specific information in a format which is not the best for human
editor.
An example of a domain specific type could be a test suite for an Internet-based
application that defines host IP addresses as integer values. Humans are more used to
editing the IP addresses in dotted decimal notation. An extension API would allow
development of a modular extension to the parameter editor for this specific test suite that
21
would display an editor with tools more suitable for editing IP addresses. The editor
component could also encode and decode the integer IP address to dotted decimal form for
easier editing.
One thing not considered here is also inline documentation. Many test suites contain
standardized comment tags such as T3Doc [2] explaining the purpose and possible values
for parameters. A valuable addition to the parameter editor would be to provide these
comments inside the parameter editor so the user does not need to guess the meaning of
parameters or look up the comments in the source code.
22
5. CONCLUSIONS
This paper has presented the design for a graphical parameter editor for TTCN-3 test suites.
This work was done in the context of OpenTTCN IDE, a TTCN-3 development
environment built on top of the Eclipse platform.
The primary design goal was that the parameter editor should simplify the setting of test
parameters both for first time users as well as provide advanced tools for experienced
TTCN-3 users and domain experts. The secondary goal was that the design should be
easily implementable in the context of the OpenTTCN IDE architecture. The author feels
the presented design accomplishes both said goals.
The design presented relies on an additional parameter editing tab added to the launch
configurations for test campaigns. This parameter editing tab shows the list of editable
parameters and allows opening editing components for the different parameters. Each
TTCN-3 primitive type will have a specific editing component providing tools to ease
modification of values of that type. Additionally the design was made modular in that
unsupported types can be edited with a generic editing component, allowing rapid
prototyping during implementation of the design.
Future additions to the design could be the inclusion of an extension framework allowing
inclusion of user-made domain specific editing components that would open when editing
values of that type in the parameter editor. Another future addition would be automatic
showing of inline documentation comments for parameters inside the editing components.
23
6. REFERENCES
[1] Järvinen, P. (2004). On Research Methods. Opinpaja, Tampere.
[2] ETSI (2007). ETSI Standard (ES) 201 873 V3.2.1: The Testing and Test Control
Notation version 3; Parts 1–8, 10. European Telecommunications Standards
Institute (ETSI), Sophia-Antipolis, France, also published as ITU-T
Recommendation Series Z.140.
[3] ISO/IEC (1998). 9241-11 Ergonomic requirements for office work with visual
display terminals (VDT)s - Part 11 Guidance on usability, ISO/IEC 9241-11:
1998 (E).
[4] Eclipse User Interface Guidelines (2009).
URL: http://wiki.eclipse.org/User_Interface_Guidelines (retrieved on 7 Oct
2009).
[5] Eclipse User Interface Checklist (2009).
URL: http://wiki.eclipse.org/UI_Checklist (retrieved on 7 Oct 2009).
[6] Stone, D., Jarrett, C., Woodroffe, M. and Minocha, S. (2005). User Interface
Design and Evaluation. Elsevier, San Francisco.
[7] Grabowski, J., Hogrefe, D., Rethy, G., Schieferdecker, I., Wiles, A. and Willcock,
C. (2003). An introduction to the testing and test control notation (TTCN-3).
Computer Networks, Vol. 42, Issue 3, pp. 375-403.
[8] Zeiss, B., Neukirchen, H., Grabowski, J., Evans, D. and Baker, P. (2006).
Refactoring and Metrics for TTCN-3 Test Suites. System Analysis and Modeling:
Language Profiles. Vol. 4320/2006, pp. 148-165.
[9] Neukirchen, H., Zeiss, B., Grabowski, J., Baker, P. and Evans, D. (2008).
Quality Assurance for TTCN-3 Test Specifications. Software Testing,
Verification & Reliability, Vol. 18, Issue 2, pp. 71-97.
24
[10] Gamma, E. and Beck, K. (2004). Contributing to Eclipse – Principles, Patterns,
and Plug-Ins. Addison-Wesley, USA.
25
Appendix A. Example of OpenTTCN Tester parameter file.
module parameters
{
import from OpenTTCN3_DemoTypes { type str_type, ParamUnionType; }
modulepar
{
charstring PX_VAL_1 := "Supplied value of parameter #1.";
charstring PX_VAL_2 := "Supplied value of parameter #2.";
charstring PX_VAL_3 := "Supplied value of parameter #3.";
}
modulepar OpenTTCN3_DemoTypes.str_type PX_VAL_4b := "Supplied value of
parameter #4b.";
modulepar charstring EC_VAL_1 := "Supplied value of external constant
#1.";
modulepar charstring EC_VAL_2 := "Supplied value of external constant
#2.";
modulepar OpenTTCN3_DemoTypes.str_type PXC_1 := "lock";
modulepar charstring PXC_2 := "lock2";
modulepar
{
integer PX_PORT_ARRAY_SIZE_BASE := 10;
ParamUnionType PX_VAL_5 := { pil := { 2, 4, 7 } };
}
modulepar
{
// Module parameters of TTCN-2 module (test suite).
integer TSPAR_Inactivity := 10;
boolean TSPAR_IUT_implicit_send := true;
boolean TSPAR_PCO_forwarding := false;
integer TSPAR_Response := 3;
}
modulepar integer PX_par_omit := omit;
modulepar integer PX_par_zero := 0;
}
