This document describes the TM section of the Go4IT Package2 General Design Document, wich is made of the following sections:

General Design of the Compiler.
General Design of the SA.
General Design of the PA.
General Design of the CH.
General Design of the TM: This document.
General Design of the TM-UI.
General Design of the TL.
General Design of the CD-Gen
General Design of the CD
General Design of the RIPng ATS.

[edit]

Introduction

This document intends to provide a preliminary introduction to the design of the Test Management (hereafter, TM) entity whithin a TTCN-3 test system. This entity is responsible for overall management of the test system which will be described in different documents.

[edit]

Use Cases

This section contains a set of use cases that describe the external behavior of this TM module. A use case is a description of a specific interaction that a user (or another module) may have with this module. Use cases are deceptively simple tools for describing the functionality of the software.

A use case is a simple, straightforward tool that can be used to completely describe all the behavior of a piece of software. It contains a textual description of all the ways that the intended users could work with the software through its interface. Use cases do not describe any internal workings of the software, nor do they explain how that software will be implemented. They simply show how the steps that the user follows to use the software to do his work. All the ways the users interact with the software can be described in this manner.

This section will contain multiple use cases, enough to define all of the interactions the users will have with the module. In the following figure, a general overview of defined use cases and relationships between the different actors (i.e., users) which have been defined in this section is shown.

[edit]

UC-1: Initialization

Summary

Test system initialization. See § 11.1.1 in [1] Part 6.

Rationale

When a user starts the test environment, the test system has to be initialized in order to be able to execute test cases. As well, the TM entity should communicate with the TE in order to select a TTCN-3 module to be executed and therefore transfer the module parameter values of a test case to the TE

Actors

TM-UI, TE

Preconditions

Neither the control part of a module nor a test case is currently being executed

Basic Course of Events

Step1: The user initializes the test system and the test environment using the TM-UI.
Step2: The user selects a TTCN-3 module to be executed.
Step3: The user obtains the list of test cases available in the selected module.

Alternative Paths

In Step2, the user should select a TTCN-3 module. If this is not possible, the TM should inform the TM-UI (no TTCN-3 module is available).
In Step3, if the TM is not able to obtain the list of test cases, the TM should inform the TM-UI that there are no test cases inside the selected module.

Postconditions

The TM has obtained the TTCN-3 module and the list of test cases within this module and can transfer this information to the TM-UI.

[edit]

UC-2: Module parameters request

Summary

The TE requests module parameters from the TM. See § 11.1.2 in [1] Part 6.

Rationale

Once the test system has been initialized and a test component is running, the TE requests module parameters value(s) associated to a test case to the TM which are needed for the execution of its test behaviour (these parameter module values are extracted from the PICS/PIXIT document/s).

Actors

Preconditions

A test component must be running

Basic Course of Events

Step1: The user initializes the test system and the test environment.
Step2: The user selects a TTCN-3 module to be executed.
Step3: The user obtains the list of test cases available in the selected module.
Step4: The TE requests the value(s) of module parameters.
Step5: The TM sends the value(s) for the indicated parameter(s).

Alternative Paths

In step 4, the TE requests the value of module parameters. If the TM can not provide a TTCN-3 value, the distinct null shall be returned.

Postconditions

The TE has obtained the TTCN-3 parameters module values

[edit]

UC-3: Execution of control part

Summary

The TM executes the control part of a TTCN-3 module. See § 11.2.1 in [1] Part 6.

Rationale

When a TTCN-3 module is selected, the control part is first selected to be executed. Then, the control part starts its execution until the execution is terminated by the TE.

Actors

Preconditions

The test system has to be initialized and a TTCN-3 module has to be selected

Basic Course of Events

Step1: The user initializes the test system and the test environment.
Step2: The user selects a TTCN-3 module to be executed.
Step3: The TM selects the control part of the module.
Step4: The control part is started.
Step5: The TE executes the control part until the execution is terminated.

Alternative Paths

In step 2, the user selects a TTCN-3 module to be executed. If this does not occur, then the TM module does not have to execute any module.
In step 5, the TE executes the control part until the execution is terminated. Once this occurs, the TE shall to inform the TM module. If there is any problem, the TE must also inform the TM.

Postconditions

The control part of a TTCN-3 module has been executed.

[edit]

UC-4: Test cases execution within control part

Summary

The TM executes test cases within the control part of a TTCN-3 module. See § 11.2.2 in [1] Part 6.

Rationale

When a TTCN-3 module is selected, the control part is first selected to be executed. Test cases included in the control part must be executed according to the statements included in the control part.

Actors

Preconditions

The test system has to be initialized and module has to be selected

Basic Course of Events

Step1: The user initializes the test system and the test environment.
Step2: The user selects a TTCN-3 module to be executed.
Step3: The TM selects the control part of the module.
Step4: The control part is started.
Step5: For each test case included in the control part that has started and terminated, the TE must inform to the TM module.
Step6: The information delivered to the TM, after a test case has been started, must include the test case identifier, the list of parameters of this test case and the duration of the test case.
Step7: The information delivered to the TM, after a test case has been terminated, must include the verdict of the test case and the list of parameters of this test case.
Step8: The TE executes the control part until the execution is terminated.

Alternative Paths

In Step2, the user selects a TTCN-3 module to be executed. If this does not occur, then the TM module does not have to execute any test case.
In step 5 & 6, the TE executes the control part until the execution is terminated. Once this occurs, the TE shall inform to the TM module. If there is any problem, the TE must also inform the TM.

Postconditions

The test cases included in the control part of a module have been executed.

[edit]

UC-5: Direct execution of a test case

Summary

The TM executes a test case directly. These test cases are outside of the control part of a TTCN-3 module. See § 11.2.3 in [1] Part 6.

Rationale

When a TTCN-3 module is selected, containing the test cases to be executed, the user can select a test case to be executed.

Actors

TM-UI, TE

Preconditions

The test system has to be initialized and a module has to be selected

Basic Course of Events

Step1: The user initializes the test system and the test environment.
Step2: The user selects a TTCN-3 module to be executed.
Step3: The TM selects a test case to be executed using the information provided by the TM-UI.
Step4: The TM informs the TE which test case wants to execute.
Step5: The TE informs the TM, when a test case has started including the name of the test case, parameters and associated timers.
Step6: The TE informs the TM, when a test case has terminated including verdict of the test case and parameters.

Alternative Paths

In step 2, the user selects a TTCN-3 module to be executed. If this does not occur, then the TM module has not to execute any test case.
In step 3, the TM selects a test case in the current module with the given parameters. If this test case does not exist, the TE shall inform the TM that an error has occurred.

Postconditions

The selected test case has been executed

[edit]

UC-6: Execution of a test campaign

Summary

The TM executes a test campaign (set of test cases) directly. These test cases are outside of the control part of a TTCN-3 module. See § 11.2.3 in [1] Part 6.

Rationale

When a TTCN-3 module is selected, containing the test cases to be executed, the start of a test campaign can be started.

Actors

TM-UI, TE

Preconditions

The test system has to be initialized and a TTCN-3 module has to be selected.

Basic Course of Events

Step1: The user initializes the test system and the test environment.
Step2: The user selects a TTCN-3 module to be executed.
Step3: The TM selects a test campaign to be executed using the information provided by the TM-UI.
Step4: The TM informs the TE which test cases wants to execute (this information is provided by the TM-UI).
Step5: The TE informs the TM, when a test case has started including the name of the test case, parameters and timers.
Step6: The TE informs the TM, when a test case has terminated including verdict of the test case and parameters.

Alternative Paths

In step 2, the user selects a TTCN-3 module to be executed. If this does not occur, then the TM module does not have to execute any test case.
In step 3, the TM selects a test case in the current module with the given parameters. If this test case does not exist, the TE shall inform to the TM that an error has occurred

Postconditions

The test cases included in the test campaign of a module have been executed.

[edit]

UC-7: Stop a test case

Summary

The TM stops a test case directly during the test case execution. See § 11.4.1 in [1] Part 6.

Rationale

When a test case is running, a user may want to stop the test case execution. Once the TM has received information about a started test case, a stop of this test case can be requested.

Actors

TE, TM-UI

Preconditions

The test system has to be initialized and a module has to be selected. Also, a test case has to be running.

Basic Course of Events

Step1: The user initializes the test system and the test environment.
Step2: The user selects a TTCN-3 module to be executed.
Step3: The TM selects a test case to be executed.
Step4: The TM informs the TE which test case wants to execute.
Step5: The TE informs the TM, when a test case has started including the name of the test case, parameters and timers.
Step6: The TM informs the TE that wants to stop the test case being executed.

Alternative Paths

In step 2, the user selects a TTCN-3 module to be executed. If this does not occur, then the TM module has not to execute any test case.
In step 3, the TM selects a test case in the current module with the given parameters. If this test case does not exist, the TE must inform the TM that an error has occurred.
In step 6, the TM informs to the TE that it wants to stop the test case being executed. If the TE is not executing a test case, the operation must be ignored

Postconditions

The test case selected and being running has been stopped.

[edit]

UC-8: Stop a test case after error

Summary

The TM must handle errors during the execution of a test case. See § 11.4.4 in [1] Part 6.

Rationale

When a test case is running, an error may occur during the execution of a test case. Once the TM has received this information, the TM must terminate the execution of that test case and inform the TM-UI

Actors

TM-UI, TE

Preconditions

The test system has to be initialized and a module has to be selected. Also, a test case has to be running

Basic Course of Events

Step1: The user initializes the test system and the test environment.
Step2: The user selects a TTCN-3 module to be executed.
Step3: The TM selects a test case to be executed.
Step4: The TM informs the TE which test case it wants to execute.
Step5: The TE informs the TM, when an error has occurred.
Step6: The TM stops the execution of the test case.
Step7: The TE informs the TM that the test case has been terminated due to an error.
Step8: The TM must inform the TM-UI.

Alternative Paths

In step 2, the user selects a TTCN-3 module to be executed. If this does not occur, then the TM module does not have to execute any test case.
In step 3, the TM selects a test case in the current module with the given parameters. If this test case does not exist, the TE must inform to the TM that a error has occurred.
In step 6, the TM informs to the TE that wants to stop the test case being executed. If the TE is not executing a test case, the operation must be ignored

Postconditions

The test case selected and being running has been stopped.

[edit]

UC-9: Stop control part

Summary

The TM stops a control part during the control part execution. See § 11.4.2.

Rationale

A control part can be stopped in between starting the control and its termination. If the control part receives a stop control request while a test case is being executed, the test case currently being executed shall be stopped.

Actors

Preconditions

The test system has to be initialized and a module has to be selected. Also, a test case has to be running within a control part.

Basic Course of Events

Step1: The user initializes the test system and the test environment.
Step2:The user selects a TTCN-3 module to be executed.
Step3:The TM selects and executes the control part whithin the selected module.
Step4:The TE starts to execute test cases within the control part.
Step5:The TM informs the TE that it wants to stop the control part currently being executed.
Step6:The test cases currently being executed are stopped.
Step7:Once the control part has stopped, the TE informs to the TM that the control part of the selected module has just terminated execution.

Alternative Paths

In step 2, the user selects a TTCN-3 module to be executed. If this does not occur, then the TM module does not have to execute any test case.
In step 5, the TM informs the TE that it wants to stop the control part being executed, If the TE is not executing the control part, the operation must be ignored.

Postconditions

The control part selected and the test case being running have been stopped.

[edit]

UC-10: Termination of control after error

Summary

The TM stops a control part when an error has been detected during the execution. See § 11.4.3 in [1] Part 6.

Rationale

A control part must be stopped when an error during its execution is detected. The TM must handle an error during the execution of a control part when no test case is being executed.

Actors

Preconditions

The test system has to be initialized and a module has to be selected. Also, a control part has to be running.

Basic Course of Events

Step1: The user initializes the test system and the test environment.
Step2: The user selects a TTCN-3 module to be executed.
Step3: The TM selects and executes the control part whithin the selected module.
Step4: During the execution, an error is detected and the TE has to inform the TM.
Step5: The TM informs the TE that must stop the execution of the control part.
Step6: Once the control part has stopped, the TE informs to the TM that the control part of the selected module has just terminated execution.

Alternative Paths

In step 2, the user selects a TTCN-3 module to be executed. If this does not occur, then the TM does not have to execute any test case.
In step 5, the TM informs the TE that it wants to stop the control part being executed, If the TE is not executing the control part, the operation must be ignored.

Postconditions

The control part selected and being running has been stopped

[edit]

UC-11: Interact with the test execution

Summary

Interacting with the test execution (control part , test case or test campaign) by giving the runtime parameters using TM-UI.

Rationale

Test execution (control part or test case or test campaign) may need some runtime parameters. Therefore, TM must interact with the test user.

Actors

TM-UI, TE

Preconditions

A test execution (control part or test case or test campaign) is already running.

Basic Course of Events

Step1: TE gives needed runtime parameter command and corresponding information to TM.
Step2: TM informs TM-UI about this information.
Step3: TM-UI displays this information and wait inputs from the test user.
Step4: Test user inputs required information.
Step5: TM-UI transfers user’s input to TM.
Step6: TM transfers to TE.

Alternative Paths

None

Postconditions

TE receives required runtime parameters.

[edit]

UC-12: Configuration

Summary

Test user can configure the test system using TM-UI

Rationale

Some parts of the test system may be configured by test user through TM-UI.

Actors

TM-UI. TE

Preconditions

UC-1 has been done.

Basic Course of Events

Step1: Test user introduces configure command in TM-UI.
Step2: TM-UI informs TM to perform this configuration.
Step3: TM finishes configuration and informs TM-UI.

Alternative Paths

In step 2, if the configuration command does not exist, then TM shall return an error message to TM-UI.

Postconditions

The configuration has been done

[edit]

Functional Requirements

Functional requirements define the internal workings of the software: that is, the calculations, technical details, data manipulation and processing, and other specific functionality that shows how the use cases are to be satisfied. The name, summary and rationale of each functional requirement are used in the same way as those of the use cases. The behaviour that is to be implemented is described in plain English in the “Requirements” section. Most requirements are only relevant to a small number of use cases—these ones should be listed by name and number in the “References” section. (Some requirements are not associated with use cases.) The core of the requirement is the description of the required behavior. It is very important to make this clear and readable. This behavior may come from organizational or business rules, or it may be discovered through elicitation sessions with users, stakeholders, and other experts within the organization. Many requirements will be uncovered during the use case development. When this happens, the requirements analyst should create a placeholder requirement with a name and summary, and research the details later, to be filled in when they are better known.

[edit]

FR-1: TCI compliant

Summary

The TM module has to be TCI compliant (See [1]).

Rationale

All JRA2 (See [2] )development must be TTCN-3 standards compliant.

Requirements

The TM module must be compliant with the ETSI standard (TCI).

References

See [1].

[edit]

FR-2: Initialization of test environment

Summary

The initialization process of the test environment has to check that the different elements are correctly configured and the parameters provided by TM-UI are valid.

Rationale

If there is any problem with one element of the test environment or any parameter is not valid, it has to be detected in the initialization process.

Requirements

The initialization process of the test environment has to check that the different elements are correctly configured and the parameters provided by TM-UI are valid:

The network interfaces of the test system and SUT are OK and properly configured.
The SUT is reachable in the appropriated links.
The different elements are set to the initial state.

References

TCI Implementor routine: tciRootModule, tciGetModuleParameters and tciGetTestCases
UC-1

[edit]

FR-3: Multiple test cases selection (test campaign)

Summary

Multiple test cases selection must be possible, using different criteria (ie., a test campaign selection is possible).

Rationale

There will be a lot of test cases, and the possibility of simultaneous test cases selection by different criteria is needed.

Requirements

The different criteria to be implemented to provide test cases selection will be:

It will be able to select all test cases related to a functionality.
A list of test cases must be selected individually.
A list of test cases selected choosing the initial test case identifier and the final test case identifier of a correlative series.

References

TCI Implementor routine: tciGetTestCases
UC-3, UC-4, UC-5, UC-6

[edit]

FR-4: State of a test environment after stop a test case

Summary

The state of the test environment has to be restored after stopping a test case.

Rationale

It will be very common to try the execution of a new test case after stopping a test case being running.

Requirements

The state of the test environment after stopping a test case has to be the one that was before the beginning of the test case, that is, the initial state of the test environment, so allowing the execution of a new test case without any additional operation.

References

TCI Implementor routine: tciTestCaseTerminated
UC-7, UC-8

[edit]

FR-5: State of test environment after stop a control part

Summary

The state of the test environment has to be restored after stopping a control part.

Rationale

It will be very common to try the execution of a new control part after stopping the control part being running.

Requirements

The state of the test environment after stopping a control part has to be the one that was before the beginning of the control part, so allowing the execution of a new control part without any additional operation.

References

TCI Implementor routine: tciControlTerminated
UC-9, UC-10

[edit]

FR-6: Execution of different instances of TM at the same time

Summary

Only one instance of TM must be running in the same test system.

Rationale

To allow the execution of several instances of TM simultaneously in the same test system is not a requirement

Requirements

If there is an instance of TM running and the user tries to run another one, TM has to send a message to TM-UI informing the user that there is already an instance of TM running.

References

TCI Implementor routine: tciStartTestCase, tciStartControl
UC-3, UC-4, UC-5, UC-6

[edit]

FR-7: Execution of different test cases at the same time

Summary

The execution of more than one test case at the same time will not be allowed.

Rationale

To allow the execution of several test cases simultaneously is not a requirement. Test cases should be executed sequentially.

Requirements

If there is an test case being running and the user tries to run another one, TM shall send a message to TM-UI informing the user that there is already a test case running.

References

TCI Implementor routine: tciStartTestCase
UC-3, UC-4, UC-5, UC-6

[edit]

FR-8: Repeated stop test case orders

Summary

Only the first stop order will be treated and considered.

Rationale

Other stop orders do not have to be treated and considered until the test case being running has been stopped completely.

Requirements

If the TM-UI sends to TM more than one order to stop the running test case, only the first order will be treated and considered. Other ones shall be ignored.

References

TCI Implementor routine: tciStopTestCase
UC-5, UC-6, UC-7, UC-8

[edit]

FR-9: Repeated stop control part orders

Summary

Only the first stop order for a control part will be treated and considered.

Rationale

Other stop orders do not have to be treated and considered until control part being running has been stopped completely.

Requirements

If the TM-UI sends to TM more than one order to stop the running control part, only the first order shall be treated. The others ones will be ignored.

References

TCI Implementor routine: tciStopControl
UC-5, UC-6, UC-7, UC-8

[edit]

Nonfunctional Requirements

Nonfunctional requirements impose constraints on the design or implementation (such as performance requirements, quality standards or design constraints).

Users have implicit expectations about how well the software will work. These characteristics include how easy the software is to use, how quickly it executes, how reliable it is, and how well it behaves when unexpected conditions arise. The nonfunctional requirements define these aspects about the system. (The nonfunctional requirements are sometimes referred to as “non-behavioral requirements” or “software quality attributes”.)

The nonfunctional requirements should be defined as precisely as possible. Often, this is done by quantifying them. Where possible, the nonfunctional requirements should provide specific measurements which the software must meet. The maximum number of seconds it must take to perform a task, the maximum size of a database on disk, the number of hours per day a system must be available, and the number of concurrent users supported are examples of requirements that the software must implement but do not change its behavior.

[edit]

NF-1: Documentation

Summary

Detailed description of developed software

Rationale

Documentation is a communicable material needed to describe the structure and components implemented. It also includes the programmer manual.

Correct, up to date, and complete documentation should help bo reach a good quality for:

Maintainability (TM can be modified at the lowest possible cost)
Reliability (ability of the TM to perform and maintain its functionality in routine and also in different unexpected circumstances)
Extensibility (adding new functionalities to the TM without affecting the functionalities already implemented)

Requirements

The documentation will consist of:

Software architecture of TM following the developer´s guide.
Dependency with other parties (using a relationship or flow diagrams).
Flow diagrams for each TCI routine implemented (or functions using TCI routines)

The documentation will be divided into component parts and for each one the following documentation will be provided:

Component description.
Reference to the specification (this document).
Component peculiarities.
Component documentation.
API documented in detail: parameters return value and behavioral description.
Configuration and installation guidelines.
Component distribution.

Source code must be documented according to the rules established to edit Java code (i.e., javadocs). See also developer’s guide [7].

References

This document.

[edit]

NF-2: Platform Compatibility

Summary

Platform requirements to execute TM

Rationale

TM subsystem is part of test system that it will be compiled and linked jointly in order to get the executable entity.

All of them must be according to the same platform requirement.

Requirements

Operating System; linux 2.6.
Compiler: gcc 3.4.
Additional compiler features: POSIX library.

References

See [3].

[edit]

NF-3: Independency of TE

Summary

The TM must be independent of TE .

Rationale

The TM must handle new TEs as result of adding new test cases or modifying the existing ones. That is, the TM must be able to handle and control any kind of test cases produced as result of adding new test cases,

Requirements

The TM module must be developed taking into account that the TEs available to be run is going to evolve, adding new test cases or modifying the existing ones. Therefore, the TM must avoid any dependency on TE, allowing the execution of new test cases without modifying the code.

References

TBC

[edit]

NF-4: Storage of TM configuration parameters

Summary

The configuration parameters of TM will be stored in a text file

Rationale

There are not many parameters and a text file is a very easy means to be used by users to store and modify it.

Requirements

A text file with .INI style will be used to store the configuration parameters of TM:

[Section 1]
Parameter1=Value1
Parameter2=Value2
[Section 2]
Parameter3=Value3
Parameter4=Value4

Some of these parameters are: type of the SUT (host or router), MAC of the SUT, IP addresses of interfaces linked to different networks, hostname, timers, etc.

References

TBC

[edit]

NF-5: PC requirements

Summary

Minimum requirements for a PC (if it is used as test system platform) to be able to execute TM module and the rest of test environment.

Rationale

This is a essential information for the user in order to deploy the test environment.

Requirements

The minimum requirements for a PC to be able to execute TM module and the rest of test environment will be:

Processor speed: 600 MHz
RAM memory: 256 MB
Free disk space: 1 GB

References

TBC

[edit]

NF-6: Dependency on other parties

Summary

Dependency of TM with the other software elements conforming the test system

Rationale

TM interworks with other software entities to be clearly identified.

Requirements

The dependencies must be clearly identified.

References

This document.

[edit]

Technical Documentation: General Design of the TM

Contents

Introduction

Use Cases

UC-1: Initialization

UC-2: Module parameters request

UC-3: Execution of control part

UC-4: Test cases execution within control part

UC-5: Direct execution of a test case

UC-6: Execution of a test campaign

UC-7: Stop a test case

UC-8: Stop a test case after error

UC-9: Stop control part

UC-10: Termination of control after error

UC-11: Interact with the test execution

UC-12: Configuration

Functional Requirements

FR-1: TCI compliant

FR-2: Initialization of test environment

FR-3: Multiple test cases selection (test campaign)

FR-4: State of a test environment after stop a test case

FR-5: State of test environment after stop a control part

FR-6: Execution of different instances of TM at the same time

FR-7: Execution of different test cases at the same time

FR-8: Repeated stop test case orders

FR-9: Repeated stop control part orders

Nonfunctional Requirements

NF-1: Documentation

NF-2: Platform Compatibility

NF-3: Independency of TE

NF-4: Storage of TM configuration parameters

NF-5: PC requirements

NF-6: Dependency on other parties

See Also