• Ei tuloksia

Test Campaign Parameter Editor for a Graphical TTCN-3 Development Environment

N/A
N/A
Info
Lataa
Protected

Academic year: 2022

Jaa "Test Campaign Parameter Editor for a Graphical TTCN-3 Development Environment"

Copied!
29
0
0

Kokoteksti

(1)

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

(2)

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.

(3)

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.

(4)

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

(5)

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

(6)

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

(7)

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.

(8)

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.

(9)

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

(10)

highlighted. Future research directions are also considered. Chapter 5 offers conclusions gained from this project and summarizes the results.

(11)

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.

(12)

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

(13)

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

(14)

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

(15)

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

(16)

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.

(17)

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.

(18)

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

(19)

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

(20)

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.

(21)

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.

(22)

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

(23)

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.

(24)

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

(25)

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.

(26)

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.

(27)

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.

(28)

[10] Gamma, E. and Beck, K. (2004). Contributing to Eclipse – Principles, Patterns, and Plug-Ins. Addison-Wesley, USA.

(29)

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;

}

Viittaukset

LIITTYVÄT TIEDOSTOT

The test suite would consist of three separate applications: one for the developer portal, another for the test tool targeting the sandbox environment and a third one for the test

As mentioned above, the development environment, which was chosen for the project implementation is TestComplete, a popular commercial test automation tool for a wide range

Š Neljä kysymystä käsitteli ajamisen strategista päätöksentekoa eli ajamiseen valmistautumista ja vaaratekijöiden varalta varautumista. Aiheita olivat alko- holin

Niiden avulla on mahdollista toteuttaa esimerkiksi työkaluikkunoita, joita voidaan siirrellä kehysikkunan sisällä.. Tällaisten kelluvien työkaluikkunoiden avulla käyttäjä

In order for the analysis to be as successful as possible, it is important to check the minimum and maximum frequency in the settings: in the editor, these will be the Pitch

For instance, data on the tasks which a language test contains can be analyzed with the Bachman & Palmer (1996) Task Characteristics framework to compare language use on the

Based on these studies, we compose VISQUAL, an instrument for measuring individual user perceptions of visual qualities of graphical user interface elements, which can be used

There is a different kind of tools for automating GUI testing and each tool can provide different kind of ways to approach making the testing more efficient. In this