IBM
Contents Index Previous Next



Using Autolink


The generation of a TTCN test suite with Autolink proceeds in several steps.

Figure 251 : Test suite generation with Autolink

You start by specifying an SDL system, see Specifying the SDL System and Performing Other Preparations. Based on this SDL specification, you generate an SDL Explorer application which includes Autolink.

Next, you define MSC test cases, see Defining MSC Test Cases, which describe the purpose of the test cases of your test suite. They are stored on disk as system level MSCs, that is, MSCs with only one instance axis for the SDL system and one or more instance axis for the environment. Test cases may contain test steps which are stored as separate system level MSCs on disk.

You may also want to define an Autolink configuration, see Defining an Autolink Configuration, in order to guide the naming and parameterization of constraints. Autolink can also be configured to store test cases into a hierarchy of test groups.

The next step is to generate test cases, see Translating MSCs into Test Cases. This can be done either by a state space exploration of the SDL system or by directly translating system level MSCs into test cases. In any case, the result is an internal representation for each test case. At the same time, a list of constraints is generated. These constraints can be renamed and merged, see Modifying Constraints. You can also add new constraints manually.

Finally, you generate a TTCN test suite, see Generating a TTCN Test Suite, based on the test case representations and the list of constraints. The test suite is stored on disk in TTCN-MP format. On UNIX, you can import this file in the TTCN Suite; in Windows, you can simply open it in the TTCN Suite. On both platforms, you can convert the TTCN-MP file to the graphical TTCN format in the Organizer.

On the following pages, the steps will be described in more detail.

Specifying the SDL System and Performing Other Preparations

Before you start the SDL Explorer, directories must be created where you will store test case and test step representations. If there are no appropriate directories:

Specifying the SDL System

You have to specify an SDL system in order to create an SDL Explorer. At minimum, you must specify all channels to the environment of your system and all signals sent via these channels. With such a minimal specification, you can use Autolink to translate MSCs directly into TTCN by using the Translate-MSC-Into-Test-Case command. The advantages and disadvantages of using this command are described in Translating MSCs into Test Cases.

Generating and Starting an SDL Explorer

When you have specified the SDL system, you can generate and start the Explorer. How to do this is described in Generating and Starting an SDL Explorer.

Specifying Directories

Before you start defining test cases and test steps, you have to specify where they are to be saved:

  1. In the Explorer, select Autolink: Test Cases Directory from the Options2 menu.
  2. In the dialog that will be displayed, select the test case directory that you previously created and click OK.
  3. Select Autolink: Test Steps Directory from the Options2 menu.
  4. In the dialog that will be displayed, select the test step directory that you previously created and click OK.

When you later leave the Explorer, you can save these values.

Defining MSC Test Cases

In Autolink, an MSC test case is derived from a path. A path is a sequence of events that have to be performed in order to go from a start state to an end state. There are two ways to define MSC test cases:

  1. Interactive simulation and manual specification
  2. Automatic computation by Autolink (see Defining MSC Test Cases Automatically - Coverage Based Test Generation)

Defining MSC Test Cases Interactively

The creation of MSC test cases by interactive simulation proceeds in several steps:

  1. Specify the start state of the test case.
    If this state is identical to the root of the behavior tree, nothing has to be done. Otherwise, you must navigate to the desired state, for example by using the Navigator, selecting a previously defined report or verifying an MSC. Then you set the root to the current state with the Define-Root Current command.

Note:

Autolink always considers the current root of the behavior tree to be the start state of a path.

Also note that when a test case is generated, the root has to be the same as it was at the moment of the test case definition. You have to keep track of the start state with Print-Path and Goto-Path, for example if you want to leave the Explorer temporarily.

  1. Navigate through the system to the desired end state.
  2. Select MSC: Save Test Case from the Autolink1 menu.

An MSC test case consists of one instance axis for the SDL system and a separate instance axis for each channel to/from the environment. In TTCN terms, the single SDL system instance represents the System Under Test (SUT). The environment instances represent the Points of Control and Observation (PCO); PCOs are the interface between the test system and the SUT.

The system level MSC that will be saved contains the observable events of the path between the start and the end state. Observable events represent the external interaction that takes place between the SDL system and its environment. (During conformance testing, external interaction takes place between the implementation and the test system.)

Figure 252 shows an MSC test case.

Figure 252 : An MSC test case

Incorporating Test Steps in Test Cases

Typically, test cases are structured logically into several parts, for example a preamble, a test body and a postamble. These parts are called test steps. You may incorporate test steps in a test case by using MSC references.

Figure 253 shows an MSC with two MSC references. Each of the referenced MSCs represents a separate test step; they are called Preamble and Postamble.

Figure 253 : An MSC with a preamble and a postamble

Test steps are stored with the same file extension as test cases (.mpr). They are created in analogy to test cases with Save-MSC-Test-Step.

If you want to create a test case with a preamble and a postamble, several steps are necessary:

  1. Make sure that you have specified the directories for test cases and test steps as described in Specifying Directories.
  2. Set the root of the state space to the start state of the test case by using the command Define-Root Current.
  3. Navigate to the end of the path of the preamble.
  4. Use Save-MSC-Test-Step to save the preamble.
  5. Set the root of the state space to the current state by using the command Define-Root Current.
  6. Navigate to the end of the path of the test body.
  7. Use Save-MSC-Test-Case to save the test case/test body.
  8. Set the root of the space to the current state.
  9. Navigate to the end state of the test case.
  10. Use Save-MSC-Test-Step to save the postamble.
  11. Add two MSC references manually to the MSC test case with the MSC Editor.

Alternatively, you may create a single MSC test case and split the file into preamble, test body and postamble afterwards.

Test steps may refer to other test steps, but not to test cases. During test case generation, Autolink keeps track of the nested structure of test cases and test steps.

Note:

When Autolink generates test cases (see Generate-Test-Case and Translate-MSC-Into-Test-Case), the semantics of MSC references and MSC reference expressions are different from the semantics given in the ITU-T Recommendation Z.120!

Autolink requires that a test step is completely evaluated before the next test step starts, i.e. it synchronizes among references, whereas Z.120 considers MSC references as macros which do not have to be evaluated as a unit.

With regard to Figure 253, this means that all signals of the test body in mi_inres2 have to be evaluated before the postamble starts.

Using Timers

Autolink supports test suite timers. There are three types of timers which are commonly needed in test sequences:

  1. A global timer is specified to guarantee that test cases end even if they are blocked during execution due to an error. By default, Autolink generates a global timer T_Global automatically and starts it at the beginning of each test case. At the end of each test sequence, T_Global is cancelled. The automatic generation of timers can be enabled and disabled with the Define-Global-Timer command.
  2. A delaying timer is used to delay the sending of a signal from the tester to the SUT. This may be done for several reasons; for example, the sending is delayed on purpose to specify an invalid behavior of the environment.
  3. A guarding timer is used to check that the SUT sends a signal within a predefined amount of time.

Delaying and guarding timers have to be specified manually on the environment instances in test case MSCs. As an example, the MSC in Figure 254 contains a guarding timer T_Guard on instance ISAP1 and a delaying timer T_Wait on instance MSAP2.

T_Guard is set prior to sending a signal to the SUT and reset after the corresponding response from the SUT. If message ICONconf is received in time, test execution proceeds normally. Otherwise, a timeout of T_Guard will be caught in the Default Dynamic Behavior description and lead to a fail verdict.

The setting of timer T_Wait is followed immediately by a timeout event, causing the tester to delay the sending of message MDATreq.

.

Note:

Test suite timers are part of the environment of the SUT. Correspondingly, there is no explicit relation between these timers and any timers which might be used within the system. Autolink simply translates timer set events on environment instances into TTCN START operations, timer reset events into TTCN CANCEL operations and timeout events into TTCN TIMEOUT events. However, timer events on any MSC instance belonging to the SUT are not translated into TTCN statements.

Figure 254 : Test case MSC with guarding and delaying timer

Autolink creates timer declarations automatically from the information which it finds in the test case MSCs. From the MSC in Figure 254, Autolink generates a declaration for timer T_Guard with the default duration set to 10 and ms as unit. Correspondingly, the default duration for T_Wait is set to the test suite parameter PIX_Wait and its unit is set to ms as well. Autolink also generates a declaration for PIX_Wait.

This implicit declaration mechanism is convenient if the test suite consists of only one test case. If there are more test cases using timers, declaration conflicts may arise since timers are declared globally for the test suite. In order to solve this problem, Autolink provides the Define-Timer-Declaration command to explicitly declare test suite timers. Explicit timer declarations can not be modified by implicit declarations. It is therefore recommended to define all timer declarations explicate before test case computation starts. In that case, only the timer name must be provided for timer set events in the test case MSCs. The duration is optional (Autolink uses the duration value if it is not empty and different from the default duration specified in the declaration). Finally, the unit can be omitted from the test case MSCs if an explicit declaration exists.

The use of test suite timers and their declaration is explained in more detail in Test Suite Timers. With respect to timers, the TTCN output generated by Autolink depends on the test architecture. This is also discussed in Test Suite Timers.

Defining Multiple Test Cases by HMSC Diagrams

HMSC diagrams can be used to illustrate the relationship between various test cases. For example, even though test cases normally have different test purposes, they might share the same preamble and postamble. This commonness can be graphically expressed by the use of an HMSC diagram such as the one in Figure 255.

Note:

HMSCs are not supported by Generate-Test-Case but only by Translate-MSC-Into-Test-Case.

Figure 255 : Three test cases described by one HMSC diagram

When the HMSC Test is taken as input, Autolink will create three test cases which consist of the test steps Preamble/Valid/Postamble, Preamble/Invalid/Postamble and Preamble/Inopportune/Postamble.

The general interpretation of HMSCs can be described by a simple rule: Autolink generates a separate test case for each possible path through an HMSC. Of course, HMSCs may have more than one node with several outgoing edges, resulting in a potentially large number of test cases.

Note:

Autolink does not translate loops directly into equivalent constructs in TTCN. Instead it handles loops by unrolling. Therefore, you should not introduce loops in HMSC diagrams.

All test cases need to have unique names. With regard to the HMSC Test in Figure 255, the resulting test cases will be named Test_Valid, Test_Invalid and Test_Inopportune. Whenever there is a branch in the HMSC, the name of the succeeding MSC reference is postfixed to the name of the top-level MSC (separated by `_').

Describing Indeterministic Behaviour by Inline and Reference Expressions

Sometimes, a system under test may not behave deterministically. For example, there may be unpredictable failures. A tester should be able to handle such situations. By the use of inline expressions and MSC reference expressions, it is possible to describe test cases where the tester reacts flexibly depending on the system behaviour.

If some of your test cases only differ slightly at some point in the test case, you may also use inline and reference expressions to describe different behaviour of the tester. In that case, Autolink generates separate test cases.

Autolink supports the following operators in MSC expressions:

Note:

Autolink does not support the parallel (par) and substitution (subst) operator within inline and reference expressions.

Figure 256 : Test case with exception handling

Of course, the usage of the different operators is not restricted to the applications described above. On the other hand, not all MSCs containing inline or reference expressions may describe sensible test cases.

Synchronization among MSC expressions

As mentioned before, Autolink synchronizes at the beginning and the end of MSC references. This modification of the semantics given in the MSC standard is motivated by the ability to consider separate MSCs as different test steps. If we cannot guarantee that all events in one MSC are evaluated before the next MSC is entered, we cannot draw a line between two subsequent test steps.

MSC reference expressions are a generalization of plain MSC references. Autolink generates distinct TTCN test steps for each of the MSCs involved in the expression. For that reason, it makes sense to synchronize at MSC references, too.

When it comes to inline expressions it is not really necessary to synchronize at their beginning and their end. However, for consistency Autolink synchronize at inline expressions, as well.

There are situations where synchronization among inline expressions is preferable, whereas in other cases the TTCN output and Autolink's error messages may be confusing.

In Figure 257, two examples are given. For MSC Sync1, Autolink will generate a test case where either ReceiveB or ReceiveC is anticipated before the test execution proceeds with SendD. If Autolink did not synchronize at the end of the alternative expression, SendD would be sent before ReceiveB (please note that Autolink prioritizes send events). Moreover, since both alternatives are combined in a single behaviour tree, SendD would erroneously become an alternative to ReceiveC!

Unfortunately, there are also cases where synchronization results in unexpected TTCN test cases. For the second MSC in Figure 257, Autolink will try to generate the following event tree:

Env1 ! SendA
  Env2 ? OptReceiveB
    Env1 ! SendC
      Env2 ? ReceiveD
  Env1 ! SendC
    Env2 ? ReceiveD

Of course, Autolink detects that there is a conflict among the two alternatives OptReceiveB and SendC and will print a warning.

Whenever Autolink issues a warning, you should carefully inspect your MSC test case definition. For example, when MSC Sync2 is interpreted as a test case, it is unclear how long a tester shall wait until it outputs SendC. On the other hand, if OptReceiveB is not logically caused by SendA or may received at any time, a possible solution would be to move SendC above the optional expression. In this case, no conflict arises.

Figure 257 : Synchronization among inline expression

Synchronizing Test Events with Conditions

The messages in MSCs are only partially ordered. If a test generation tool would generate all possible test sequences, then send events could appear as alternatives to receive events in TTCN test cases, making them indeterministic. To solve this problem, three solutions are possible:

  1. Events received by the tester are prioritized over events sent to the SUT.
  2. Events sent to the SUT are prioritized over events received by the tester.
  3. All messages in the MSC are evaluated from top to bottom. In that case, only one sequence of test events is generated.

The first alternative may lead to deadlocks and therefore it is not supported by Autolink. Alternative three may be selected with the Define-Autolink-Generation-Mode command.

By default, Autolink uses the second alternative and prioritizes events which are sent from the test system to the SUT over events which are received by the tester from the SUT.

Figure 258 : Synchronization example 1

However, there are situations where this "send immediately" strategy leads to incorrect test cases. Consider the following small example: A calls B, B accepts the call, then C tries to call B and gets a busy signal. A corresponding MSC test purpose description would look similar to the one in Figure 258. What test sequence will Autolink generate? First, the tester will send Request(B) to the SUT through PCO A. Next, Request(B) will be sent to the SUT through PCO C, since this is the next send event on any of the tester instances.

Figure 259 : Synchronization example 2

Most likely, this is not what you have anticipated intuitively; the tester should send the second Request(B) only after it has received Confirmation through PCO A. This is where explicit synchronization with conditions comes in. Figure 259 contains the same MSC as Figure 258, with a global condition added between the reception of Confirmation at PCO A and the sending of Request(B) through PCO C. If the Autolink synchronization option is turned on (with Define-Condition-Check), then events below the condition can only be executed if all events above the condition have been executed as well. The condition effectively becomes a synchronization point. In the example, the sending of Request(B) through C will be delayed until Confirmation has been received at PCO A. The name in the condition is required by the ITU Recommendation Z.120, however it is only considered as a comment and does not have any semantics.

.

Note:

The condition check option also applies to the MSC verification function of the Explorer.

Listing and Clearing Test Cases and Test Steps

Note:

Autolink distinguishes between the MSC test case name (which is the name of the system level MSC) and the name of the file on disk that contains the MSC test case. Usually, these names are identical except for the file extension.

When accessing the test cases and the test steps directory, Autolink always refers to the file names, meaning that you also have to specify the file extension (either .mpr or .msc)

Defining MSC Test Cases Automatically - Coverage Based Test Generation

One common method to generate a test suite is to select a number of test cases which, taken together, obtain a high coverage of the SDL specification. Ideally, this coverage should be 100%. In that case, every SDL symbol in the specification is executed at least once during test generation.

Autolink provides a special state space exploration technique, called Tree Walk, which is optimized for finding paths through the state space of the SDL specification that result in a high SDL symbol coverage. Tree Walk combines the advantages of both the depth-first and breadth-first search strategy - it is able to visit states located deep in the reachability graph and to find a short path to a particular state at the same time.

The execution of Tree Walk is controlled by two options:

  1. The maximum computation time (specified in minutes)
  2. The targeted coverage (specified in percent)

When Tree Walk is used, it generates a report for each sequence of transitions in the state space that increases the number of visited SDL symbols. These reports can be converted into system level MSCs with the command Save-Reports-as-MSC-Test-Cases.

Defining an Autolink Configuration

Autolink offers a special language for defining rules for the naming and parameterization of constraints, the introduction of test suite parameters and constants, and the distribution of test cases and test steps into test groups.

While it is possible to define an Autolink configuration on the fly at the Explorer command prompt, it is better to write a command file which includes the configuration.

See also:

Computing Test Cases

Once you have defined a set of MSC test cases, you can compute internal test case representations for each MSC test case.

Either a single test case or a set of test cases in the current test cases directory may be generated at the same time, depending on the parameter of Generate-Test-Case. If an already generated test case is regenerated, its former internal representation and its corresponding constraint definitions are replaced.

Note:

If the SDL specification is not detailed enough in the sense that it does not model the signal flow in a given MSC, the generation of the test case fails. MSCs which cannot be verified can still be converted into test cases with the Translate-MSC-Into-Test-Case command, which is described in Translating MSCs into Test Cases.

Inline expressions, MSC reference expressions and HMSC diagrams are not supported by Generate-Test-Case. (However, you can use these structural concepts for Translate-MSC-Into-Test-Case.) If you want to generate test cases based on HMSCs, you have to transform your HMSC diagrams into basic MSCs first. You can do this by verifying the HMSCs and saving all MSC Verification reports as MSC test cases (command Save-Reports-as-MSC-Test-Cases).

With complex systems, test generation may take a while. To avoid time-consuming test generation failures, you should verify all MSCs first.

Listing and Clearing Generated Test Cases

Displaying and Saving the Internal Representation

This makes it possible to distribute the generation of a set of test cases to several computers. When all test cases have been generated and saved in individual files, they can be reloaded on a single machine and saved as a complete test suite.

State Space Exploration Parameters

There are several parameters which influence the state space exploration:

Test Case Generation Messages

After the generation of a test case, some warnings or error messages may be displayed:

Translating MSCs into Test Cases

If an SDL system is not fully specified, some or all MSCs may not be converted into test cases if you use the Generate-Test-Case command. Instead, you can use the Translate-MSC-Into-Test-Case command to translate MSCs directly into the same internal test case format which is used for test cases generated by state space exploration. Therefore, you can use all commands related to listing, displaying, removing, saving and loading of test cases (introduced in Computing Test Cases) with directly translated test cases as well.

Furthermore, all rules for constraint naming (see Translation Rules) and test grouping (see Test Suite Structure Rules) apply to translated test cases, too.

Note:

Since the translation of MSCs into test cases does not perform a state space exploration, there is no guarantee that the MSCs and hence the test cases describe valid traces of the specification or the implementation, respectively. Instead, the validity of the test cases has to be assured by the developer. Furthermore, no inconclusive events can be computed during MSC translation. Therefore, the resulting test cases return a fail verdict for any deviation from the behavior described in the MSC.

Either a set of test cases in the current test cases directory or just a single one may be translated at the same time, depending on the parameter of Translate-MSC-Into-Test-Case. If an already translated test case is retranslated, its former internal representation and its constraint definitions are replaced.

Two different algorithms are available for MSC translation: With the Define-Autolink-Generation-Mode command, you can choose the semantics used to interpret MSCs during translation. By default, Autolink uses the standard semantics of MSC. If the generation mode is set to "total ordering", then the sequence of input and output events in the MSC is determined straight from top to bottom. If there are two events on different environment instances, Autolink evaluates the event which is closest to the top of the MSC first.

Note:

For test generation with state space exploration (using the Generate-Test-Case command), total ordering is not supported.

MSC into TTCN Translation Messages

After the generation of a test case, some warnings or error messages may be displayed:

Modifying Constraints

It is highly recommended that you specify constraints naming and parameterization rules in an Autolink configuration file. Otherwise, a generic name of the form <Test case name>_<three digit number> is assigned to each constraint during test case generation. However in the latter case, you will probably find it useful to modify the constraints generated by Autolink.

Note:

If you rename a constraint or merge two constraints, the internal test case descriptions are updated, too. The links between the events in the test cases and their corresponding constraints remain consistent.

Generating a TTCN Test Suite

Note:

A test step that is used in several places may lead to trees with different inconclusive events or different verdicts. In this case, they will be given new, unique names.

Preliminary Pass Verdicts

Test cases that are structured into preamble, test body and postamble will automatically be assigned preliminary pass verdicts at the end of the test body. However, test cases can contain an arbitrary number of MSC references (and hence test steps). Therefore, preliminary pass verdicts will be assigned to all events that are directly followed by the last top-level MSC reference in the test case. The preliminary pass verdicts will only be assigned if no event follows the last MSC reference. The event to which a preliminary pass verdict is assigned may appear within the test body as well as within a test step.

Test Suite Generation Messages

During the saving of a test suite, some warnings or error messages may be displayed:

Translation Rules

In Modifying Constraints, you have learned how to change constraints. However, assigning sensible names to automatically generated constraints is a tedious task. Especially if you have to refine the SDL specification and then to repeat the test generation process, there is a lot of manual work. Moreover, the number of generated constraints may become very large if you do not use constraint parameterization.

In order to address these problems and some additional issues, you can specify so-called translation rules. These rules control the look of a test suite with regard to the following items:

  1. Naming of constraints
  2. Parameterization of constraints
  3. Replacement of signal parameter values by wildcards in a constraint declaration table
  4. Introduction and naming of test suite parameters and test suite constants

Translation rules build one integral part of an Autolink configuration (see also Test Suite Structure Rules). Before you start the test generation, you can develop an Autolink configuration file that contains a Define-Autolink-Configuration command. The set of translation rules which tell Autolink how to construct constraints and treat parameters for particular signals, are provided as a kind of long parameter to this command.

For some examples, see Examples of Translation Rules. More information can be found in Defining an Autolink Configuration and Syntax and Semantics of the Autolink Configuration.

Examples of Translation Rules

A typical translation rule may look like this:

Example 274

TRANSLATE MDATind
  CONSTRAINT NAME "C_" + $0
             PARS $1="Type"
END

Example 274 explains how signal MDATind is translated into an suitable TTCN constraint. The rule above states that the name of a constraint for signal MDATind consists of the concatenation of text "C_" and the "nullth" parameter - which is the name of the signal itself. Therefore, signal MDATind is translated into a constraint called C_MDATind.

Additionally, the first parameter of the signal (referred to by $1) becomes a parameter of the constraint. The name of the formal parameter is Type. It is printed both in the Constraint Name line and the Constraint Value section of the constraint declaration table. The actual parameter of the constraint is printed in the dynamic behavior table of each test case that uses this constraint.

A constraint declaration table for signal MDATind is shown in Figure 260.

Figure 260 : A constraint declaration with a formal parameter

It is also possible to define a single translation rule for more than one signal. This is especially useful if similar signals exist which can be treated in the same way.

Example 275

TRANSLATE MDATind | MDATreq
  CONSTRAINT NAME "C_" + $0
             PARS $1="Type"
END

If either MDATind or MDATreq is identical to the signal for which a constraint is to be created during test generation, the rule in Example 275 is applied. The value of $0 depends on the name of the actual signal investigated at run-time. Since the first signal parameter is always to be replaced by the formal parameter Type, the rule is only valid if each of the alternative signals, i.e. MDATind, and MDATreq, has at least one parameter. When parsing an Autolink configuration, all translation rules are checked automatically for validity.

Constraint names may not only be based on texts and signal names. They can also depend on signal parameters. In a translation rule, a signal parameter is referred to by its number, prefixed with a dollar character ($). (Note that Autolink only supports parameters on the top level - it is not possible to refer to a component of a nested parameter.)

In some cases, it is not desirable to use the value of a signal parameter directly as part of a constraint name. For example, a protocol engineer might encode complicated signal information with abbreviations or numbers. But for the TTCN output, parameter values should be mapped onto more meaningful expressions.

Therefore, you may define functions which take an arbitrary number of parameters and map them onto text. In Example 276, the value of the first parameter of signal MDATind is passed to function PDUType. Depending on the concrete parameter value, which occurs during test case generation, the function returns a text. This text forms the second part of the constraint name.

Example 276

TRANSLATE MDATind
  CONSTRAINT NAME "Medium_" + PDUType($1)
END

FUNCTION PDUType
    $1 == "CR"  : "Ind_Connection_Request"
  | $1 == "AK"  : "Ind_Acknowledge"
  | $1 == "DR"  : "Ind_Disconnection_Request"
  | TRUE        : "Indication"
END

Note:

In a translation rule, $i refers to the i-th parameter of the signal for which a constraint is created. However in a function, $i denotes the i-th parameter which was passed to the function.

You may define complex rules whose evaluation is guarded by conditions. This is illustrated in Example 277.

Example 277

TRANSLATE "MDATind"
  IF $1 == "CR" THEN
    CONSTRAINT NAME "Medium_Connection_Request"
  END
  IF $1 == "AK" AND $2 == "zero" THEN
    CONSTRAINT NAME "Medium_Acknowledge_Zero"
  END
  CONSTRAINT NAME "Medium_Indication"
             PARS $1="Type"
END

Conditional translations can be defined by IF-statements. Only if the condition(s) following the IF keyword is/are satisfied, the constraint is built according to the subsequent specification. A translation rule can contain several IF-clauses. The first clause which condition is satisfied (or which does not have an IF statement at all) is chosen for translation.

In the example above, signal MDATind is translated into a constraint called Medium_Connection_Request if the first signal parameter equals CR, and to a constraint called Medium_Acknowledge if the first two signal parameters equal AK and zero respectively. If neither condition is satisfied, the unconditioned section is evaluated. In this case, a constraint with name Medium_Indication and formal parameter Type is created. Note that the parameter definition is not taken into account if any of the former IF-conditions is satisfied!

Sometimes, it is useful to indicate that a specific signal parameter is irrelevant. For example, assume that if the first parameter of signal MDATind is CR, the values of the second and third parameter can be ignored. Hence, you can replace them by wildcards in a constraint table. In Example 278, a MATCH statement is added that tells Autolink to replace the values of the signal parameters 2 and 3 by asterisks. The resulting constraint table is displayed in Figure 261.

Example 278

TRANSLATE "MDATind"
  IF $1 == "CR" THEN
    CONSTRAINT NAME "Medium_Connection_Request"
               MATCH $2="*", $3="*"
  END
  CONSTRAINT NAME "Medium_Indication"
             PARS $1="Type"
END

Note:

The application of TTCN matching mechanisms is only valid for receive events. Hence, you are not allowed to apply the MATCH statement to signals that become send events in TTCN.

Figure 261 : A constraint table with TTCN matching expressions

Translation rules also allow to introduce test suite parameters and constants. Test suite constants are useful if a concrete parameter value does not give any clues about its meaning and hence should be replaced globally by a more meaningful name. Test suite parameters should be introduced if signal parameter values are implementation dependent. By defining a test suite constant/parameter, a concrete signal parameter value in a constraint table is replaced by a symbolic constant. The assignment of concrete values to symbolic test suite constants/parameters is made in additional TTCN tables which are created automatically by Autolink.

Example 279 illustrates the use of test suite parameters and constants. If the condition is satisfied, the second signal parameter is replaced globally by SeqNo in the TTCN test suite. The third signal parameter is replaced by a test suite parameter called DataValue. This parameter refers to PICS/PIXIT proforma entry PICS_Data.

If signal MDATreq has not been used for data transfer, the value of the first signal parameter is replaced by a test suite constant which name is based on the concrete signal parameter value. A constraint table and an according constant table for this case is shown in Figure 262 and Figure 263.

Example 279

TRANSLATE "MDATreq"
  IF $1 == "DT" THEN
    CONSTRAINT NAME   "Medium_Req_Data_Transfer"
    TESTSUITE  CONSTS $2="SeqNo"
               PARS   $3="DataValue" / "PICS_Data"
  END
  CONSTRAINT NAME   "Medium_Req_" + PDUType($1)
             MATCH  $3="*"
  TESTSUITE  CONSTS $1=PDUType($1)
END

FUNCTION PDUType
  $1 == "CC" : "ConConf"
| $1 == "AK" : "Acknowledge"
| $1 == "DR" : "DisconRequest"
| $1 == "DT" : "DataTransfer"
| $1 == "CR" : "ConRequest"
END

Figure 262 : A constraint table with a test suite constant

Figure 263 : A TTCN table for test suite constant declarations

An Autolink configuration typically consists of a large number of translation rules which are evaluated from top to bottom. If a constraint cannot be constructed based on the given rules, a generic name will be assigned to the constraint, in the same way as when no translation rules are defined.

Test Suite Structure Rules

In TTCN, test cases can be combined in test groups. Each test group aims at testing the system under test for one particular aspect. Test groups again can be part of other higher level test groups, resulting in a hierarchy of test groups.

Test steps can be put into test groups as well. In the following, test cases and test steps will not be distinguished, as test structure rules apply to both.

When you start designing a test suite, you should have a clear notion of what the structure of the test suite will be. In fact, for successful test suite development, it is important to first determine what should be tested and how the tests can be classified, before individual test cases are specified.

If you use Autolink for test generation, the test cases are described by MSCs. Ideally, the names of the MSCs should give information about the structure of the resulting test suite. Because of this, you may specify rules for the automatic placing of test cases in different test groups, depending on the names of the corresponding MSCs. These test suite structure rules prevent you from repeating a lot of manual work if you regenerate the test suite due to a modification of the underlying SDL specification. Moreover, test suite structure rules (TSS rules) also save you a lot of work if you create a test suite only once, since a single rule can be applied to several test cases. As will be shown in the example below, one rule may be enough to describe the structure of a complete test suite.

Test suite structure rules are part of an Autolink configuration. Before the test generation starts, you can write an Autolink configuration file which contains a Define-Autolink-Configuration command. The TSS rules are provided as a kind of long parameter to this command.

For details on the Autolink configuration commands see Defining an Autolink Configuration. A precise description of the Autolink configuration language is given in Syntax and Semantics of the Autolink Configuration.

Examples of Test Suite Structure Rules

In the following, it is assumed that you want to create a test suite in which test cases can be classified according to three different criteria. On the top level, tests can be distinguished by whether they are related to mandatory or optional capabilities. On the next level, tests may focus on particular protocol phases, for example connection establishment, data transfer and disconnection. Finally, valid, invalid or inopportune behavior may be displayed. A resulting test suite should have the following structure:

Mandatory
  Connection
    Valid
    Invalid
    Inopportune
  DataTransfer
    Valid
    ...
  Disconnection
    ...
Optional
    ...

It is further assumed that having this structure in mind, you have created MSC test cases with the following names:

V_Con_Man_01
V_Dis_Man_01
IV_Data_Man_01
IO_Data_Opt_01
IO_Data_Opt_02

MSC test cases that belong to the same test group are numbered sequentially.

Now, a simple TSS rule for the scenario above may look like this:

Example 280

PLACE V_Con_Man_01
  IN    "Mandatory" / "Connection" / "Valid"
END

Example 280 states that test case V_Con_Man_01 is intended to be placed in the test group Valid. Since this test group is placed in another test group (Connection), you have to specify the complete path, composed of all groups in hierarchical order. The names of the test groups are separated by a slash (`/') in analogy to the notation of test group references in the TTCN standard.

If you want to place several test cases in the same test group, you can use the alternative operator (`|') in the header of a TSS rule:

Example 281

PLACE IO_Data_Opt_01 | IO_Data_Opt_02
  IN    "Optional" / "DataTransfer" / "Inopportune"
END

Example 281 places both IO_Data_Opt_01 and IO_Data_Opt_02 in test group Optional/DataTransfer/Inopportune.

Rules like the one shown in Example 280 and Example 281 can be applied to MSC test cases with arbitrary names. In the best case, you have to write one TSS rule for each test group.

However, there is a direct relation between the MSC names and the test groups. For example, the two characters IO at the beginning of an MSC name indicate that the corresponding test case has to be placed in a test group called Inopportune. Using this information, the number of TSS rules can be further reduced as explained below.

You are allowed to use patterns in the header of a test suite structure rule. The following characters have a special meaning when used in the header:

Note:

Patterns can also be used in a similar way in the header of translation rules. This is useful if signals with similar names are to be treated equally.

Now consider the following complex rule and its auxiliary functions:

Example 282

PLACE "*" + "_" + "*" + "_" + "???" + "_" + "*"
  IN    OptMan( @5 ) / Phase( @3 ) / Behavior( @1 )
END

FUNCTION OptMan
  $1 == "Opt" : "Optional"
| $1 == "Man" : "Manual"
END

FUNCTION Phase
  $1 == "Con"  : "Connection"
| $1 == "Data" : "DataTransfer"
| $1 == "Dis"  : "Disconnection"
END

FUNCTION Behavior
  $1 == "V"  : "Valid"
| $1 == "IV" : "Invalid"
| $1 == "IO" : "Inopportune"
END

With the rule in Example 282, all test cases can be placed in their appropriate test groups.

When a test suite structure rule is evaluated, it is first checked whether one of the terms following the keyword PLACE (which are separated by `|') equals the name of the investigated test case. In the rule above, there is only one term consisting of 7 parts, called atoms. These atoms are concatenated by the `+' operator.

While Autolink simply has to compare strings in Example 280 and Example 281, it has to find out whether a concrete test case name matches the pattern in Example 282. If the test case name matches the pattern, the atoms in the header of the TSS rule are instantiated.

If, for example, the rule is applied to test case IO_Data_Opt_01 at run-time, the first atom (originally `*') is set to "IO". The value of the third atom becomes "Data", the value of the fifth atom becomes "Opt" and the value of the seventh atom becomes "01". The second, fourth and sixth atom remain unchanged as they do not contain any special characters.

In order to refer to the value of an atom in the rule header, you can use the "at" operator (`@'). For example, "@5" refers to the value of the fifth atom.

Additionally, you may define functions which map parameters onto texts. In Example 282, "@5" is passed to function OptMan. Depending on the concrete parameter value which is passed at run-time, the function returns either the text "Optional" or "Manual" (or an error message if the first function parameter is neither "Opt" nor "Man").

An Autolink configuration typically consists of a number of TSS rules which are evaluated from top to bottom. If a test case or a test step cannot be placed in a test group based on the given rules, Autolink places it on top-level and prints an error message. In this case, you can modify your rules, reload them and apply the Save-Test-Suite command again.

Defining ASP and PDU Types

When Autolink produces a TTCN test suite it creates several tables in the declarations part. These tables store information about sorts, ASN.1 data types and signal definitions used in the SDL system. By default, Autolink applies the following rules:

  1. SDL sort definitions are mapped onto ASN.1 type definitions.
  2. ASN.1 data types defined externally in an ASN.1 module are listed as ASN.1 type definitions by reference in TTCN.
  3. SDL signal definitions become ASN.1 ASP type definitions. As a consequence, if a signal is used in a test case, its corresponding TTCN constraint is stored in an ASN.1 ASP constraint table.

Very often, this mapping is too strict. For example, during test execution a tester may exchange both Abstract Service Primitives (ASPs) and Protocol Data Units (PDUs) with the system under test. If you want to store constraints as ASN.1 PDU constraints, you may use Define-TTCN-Signal-Mapping with parameter PDU. However, in this case all signals are considered to be PDUs. Moreover, this command does not apply to SDL sorts and ASN.1 data types.

In order to specify the correct for each different type of information, Autolink provides two commands in its configuration language. These commands start with either the keyword ASP-TYPES or PDU-TYPES. You can use them to declare single signals and sorts as ASPs and PDUs.

Example 283

ASP-TYPES
  "ICONreq" , "ICONconf", "IDATreq"
END

PDU-TYPES
  "pdu*"
END

In Example 282, three SDL signals, namely ICONreq, ICONconf and IDATreq are specified as ASPs. The second rule states that all signals and sorts whose name starts with "pdu" shall be considered to be PDUs. If constraints with corresponding types are used, they are stored as PDU constraints as well.

Stripping signal definitions

When it comes to the automatic generation of TTCN test suites, one of the drawbacks of SDL is that any data which is exchanged between a system and its environment has to be encapsulated in signals. Especially, if your SDL specification makes use of ASN.1 data types, this restriction imposes a redundant embedding. On the other hand, the concept of signals does not exist in TTCN. Instead, common data values can be sent and received directly. For that reason, Autolink allows to strip signals.

Consider a signal type defined as MDATreq( PDUType ). If a signal of this type is used in a test case, say MDATreq( { CC } ), then Autolink will generate a constraint of type MDATreq. However, what you may want to generate is a constraint of type PDUType, i.e. the signal should be stripped from its parameter.

Example 284

STRIP-SIGNALS
  "MDATreq"
END

PDU-TYPES
  "PDUType"
END

Example 284 presents a short Autolink configuration statement that tells Autolink to unwrap the signal parameter when generating constraints that are related to signal MDATreq in the SDL specification.

Please note that signal stripping can only be applied to signals that have exactly one parameter! Moreover, the embedded parameter must be declared either as PDU or as ASP. If these conditions do not hold, Autolink refuses to strip the signal and issues a warning. If a signal can be stripped successfully, no declaration is generated for it in the TTCN declaration part, since it is not used in the constraints part.

Syntax and Semantics of the Autolink Configuration

Autolink Configuration

The definition of an Autolink configuration is started with the keyword Define-Autolink-Configuration and is terminated with End. It consists of an arbitrary sequence of five different kinds of statements: Translation rules, test suite structure rules, ASP/PDU type rules, signal stripping rules and functions.

Example 285 : Syntax of Autolink configuration

<Start>                ::= "Define-Autolink-Configuration"
                           <Configuration>
                           "End"
<Configuration>        ::= { <TransRule> | <TSStructureRule> |
                             <ASPTypesRule> | <PDUTypesRule> |
                             <StripSignalsRule> | <Function> }*

Note:

If you want to define both translation rules and test suite structure rules, you have to place them in the same configuration definition.

Rules and functions can be arbitrarily mixed in a configuration. There is no need to place rules on top of a file, nor do you have to write forward declarations for functions.

Note:

Autolink analyzes translation rules and test suite structure rules in the order they have been defined. As a consequence, the order of the definitions is crucial if several rules can be applied.

Translation Rules

Translation rules are evaluated whenever a constraint is created during test case generation.

A translation rule starts with the specification of the names of the signals to which it shall apply (denoted by <AlternativeListOfTerms>).

Example 286 : Syntax of translation rules

<TransRule>            ::= "TRANSLATE"
                           [ "SIGNAL" ] <AlternativeListOfTerms>
                             <TransRuleIf>* [ <TransRuleNoIf> ]
                            "END"
<TransRuleIf>          ::= "IF" <Conditions> "THEN" 
                           <TransRuleNoIf> "END"
<TransRuleNoIf>        ::= { "CONSTRAINT" <TransRuleConstraint> |
                             "TESTSUITE" <TransRuleTestSuite> }*
<TransRuleConstraint>  ::= { "NAME" <Term> |
                             "PARS" <ParameterList1> |
                             "MATCH" <ParameterList1> }*
<TransRuleTestSuite>   ::= { "CONSTS" <ParameterList1> |
                             "PARS" <ParameterList2> }*
<ParameterList1>       ::= <Parameter1> { "," <Parameter1> }*
<Parameter1>           ::= "$" <Number> [ "=" <Term> ]
<ParameterList2>       ::= <Parameter2> { "," <Parameter2> }*
<Parameter2>           ::= "$" <Number> [ "=" <Term> ] 
                                        [ "/" <Term> ]

As sketched in the example section, translations can be made dependent on one or more conditions. Hence, the body of a translation rule may consist of one or more statements embedded by IF ... THEN ... END constructs. The first group of statements whose preceding conditions are satisfied (or which do not have an IF statement at all) is evaluated. All subsequent definitions are ignored. If no conditions hold for a given signal, Autolink looks for another translation rule which fits the signal.

There are two groups of directives starting with either the keyword CONSTRAINT or TESTSUITE.

In the CONSTRAINT part you can specify the name (keyword NAME) and the formal parameters of a constraint (keyword PARS) for one or more given signals. Additionally, you can tell Autolink to replace signal parameter values by a TTCN matching mechanism (keyword MATCH). Please note that Autolink does not perform any checks concerning matching mechanisms at run-time. It simply handles it as a textual replacement.

In the TESTSUITE part, you can specify that parameter values of a signal are replaced by test suite parameters and constants. The declaration of constants is preceded by the keyword CONSTS, test suite parameter are introduced with PARS.

It is possible to declare a constraint parameter and a test suite constant/parameter for the same signal parameter. However, Autolink ensures that a signal parameter is not mapped onto a test suite constant and parameter at the same time.

There exist several default values that are used when an optional parameter is not specified:

If there are name clashes, test suite constants and parameters are treated similar to constraints and test steps. That means, if there are two constants with the same name but different values, they are distinguished by a sequence number.

Test Suite Structure Rules

Test suite structure rules are similar to translation rules. They share most of the basic concepts, for example terms, functions and conditions. However, while translation rules are applied during test case generation, TSS rules are evaluated when you save a test suite with the Save-Test-Suite command.

A test suite structure rule starts with the specification of the names of the test cases to which it shall apply (denoted by <AlternativeListOfTerms>).

Conditions can be used in the same way as in translation rules: The first IN statement whose preceding conditions are satisfied (or which is not embedded in an IF ... THEN ... END statement at all), is taken into account. All subsequent statements are ignored. If no conditions hold for a given test case/step, Autolink looks for another TSS rule that fits the test case/step.

Example 287 : Syntax of test suite structure rules

<TSStructureRule>        ::= "PLACE" <AlternativeListOfTerms>
                             <TSStructureRuleIf>* 
                             [ <TSStructureRuleNoIf> ] 
                             "END"
<TSStructureRuleIf>      ::= "IF" <Conditions> "THEN"
                             <TSStructureRuleNoIf> "END"
<TSStructureRuleNoIf>    ::= "IN" <Term> { "/" <Term> }*

Declaring ASP and PDU Types

The rules to declare ASP and PDU types are evaluated when a TTCN test suite is saved on disk with the Save-Test-Suite command. Please note that each of the rules can only be defined once in an Autolink configuration. However, this is no restriction as you can specify an arbitrary number of signals and sorts in both rules.

Example 288 : Syntax for declaring ASP and PDU types

<ASPTypesRule>      ::= "ASP-TYPES" <SequentialListOfTerms> "END"
<PDUTypesRule>      ::= "PDU-TYPES" <SequentialListOfTerms> "END"

Stripping Signals

Rules for stripping signals are evaluated closely coupled with the rules above for declaring ASP and PDU types. Autolink only strips a signal if its only parameter is declared as ASP or PDU. Autolink only accepts one stripping rule in a configuration.

Example 289 : Syntax for stripping signals

<StripSignalsRule> ::= "STRIP-SIGNALS" <SequentialListOfTerms> 
                       "END"

Functions

Functions are identified uniquely by their names. If there are two functions with exactly the same name, the one defined first is always evaluated.

Functions are visible globally, that is, they can be called by any constraint or test suite structure rule and other functions. References to functions are resolved at run-time. If there is a call to an unknown function, the text "FunctionXXXNotFound" is returned.

Example 290 : Syntax of functions

<Function> ::= "FUNCTION" <Identifier> <Mappings> "END"
<Mappings> ::= <Mapping> { "|" <Mapping> }*
<Mapping>  ::= <Conditions> ":" <Term>

A function body consists of a number of mapping rules separated by `|'. Mapping rules specify the possible return values of a function. A mapping is performed if its corresponding condition(s) hold. Mappings are evaluated from top to bottom. If the conditions of all mappings fail, a function returns the text "NoConditionHoldsInFunctionXXX".

Function parameters can be accessed in the same way as signal parameters in a translation rule. For example, $2 refers to the second parameter. In the context of functions, the reference $0 denotes the name of the function. Since parameters do not have a name, but are referred to by their position instead, there is no need to declare them in the function header. If you try to access a parameter that has not been passed to the function, the missing parameter is replaced by the text "ParOutOfRange".

Note:

In conditions, the existence of a particular parameter can be checked. For example, condition
$4 == "ParOutOfRange"
checks if four parameters have been passed to the function.

Basic Expressions

The only data type defined in the Autolink configuration language is text. Whether you refer to a signal parameter or call a function, the result of the operation is always a text.

Example 291 : Syntax of basic expressions

<Term>                   ::= <Atom> { "+" <Atom> }*

<Atom>                   ::= "$" <Number> | "@" <Number> |

                             <Text> | <Identifier> | 

	                              <FunctionCall>

<FunctionCall>           ::= <Identifier>

                             "(" <SequentialListOfTerms> ")"

<SequentialListOfTerms>  ::= <Term> { "," <Term> }*

<AlternativeListOfTerms> ::= <Term> { "|" <Term> }*

<Conditions>             ::= <Condition> { "AND" <Condition> }*

<Condition>              ::= <Term> { "==" | "!=" } <Term> | 

                             "TRUE"


Texts are constructed by atoms and terms. A single atom can be one of the following expressions, depending on the context in which the atom is used:

Since an atom always evaluates to a text and a term is a concatenation of single atoms, you are allowed to use term expressions for the specification of:

Note:

The text obtained by referring to a signal parameter is identical to the output of the signal parameter value in ASN.1 format.

A condition checks whether two texts are equal (==) or unequal (!=). There is also a special condition TRUE that always evaluates to true.

Conditions can be combined by AND. Only if all conditions in a conjunction hold, the expression as a whole is true.

There is no OR operator for combination of conditions. However, due to the consecutive evaluation of rules (from top to bottom), this is not a restriction. For example, in a function body, simply place both OR-operands in two subsequent mappings.

Concurrent TTCN

In the 1996 version of ISO IS 9646-3, TTCN has been extended with mechanisms to specify test suites for distributed test systems. These extensions are known as concurrent TTCN. This section explains what will happen when you save your test suite in the concurrent TTCN format.

Declarations

In a distributed test environment, the test system is composed of a set of Parallel Test Components (PTC) which each handle one or more PCOs. The test system also includes one Main Test Component (MTC) which starts the PTCs and computes the final test verdict. The MTC may or may not control PCOs. The main and parallel test components exchange Coordination Messages (CM) through Coordination Points (CP).

The collection of a number of test components and their connection through coordination points is called a test configuration. A test suite may contain more than one test configuration, and each test case has to be associated with a specific test configuration individually.

Coordination messages and corresponding constraints have to be declared similar to messages exchanged with the system under test, but in separate tables.

Dynamic behavior description

In concurrent TTCN, the Test Case Dynamic Behaviour table only describes the behavior of the main test component. The behavior of parallel test components is stored in Test Step Dynamic Behaviour tables. Obviously, the behavior tables of every test component contain only events observed at the PCOs and CPs attached to that test component.

Parallel test components are dynamically created by the main test component. This is done by the inclusion of CREATE statements in the test case behavior description. Similarly, the DONE event can be used in the test case description to check the termination of parallel test components. The final test case verdict is computed by the MTC from the verdicts returned implicitly by all PTCs before their termination.

Synchronization of test components

With concurrent TTCN, synchronization among test components becomes a necessity. Each test component only gets a partial view of the system under test and has no inherent knowledge of the state of the other test components. Therefore, the correct order of test events can only be established through the use of coordination messages. Consider the example shown in Synchronizing Test Events with Conditions. If there are separate test components to control A, B and C, then C definitely has to wait for a coordination message before sending its Request(B) message to the SUT. If it does not, the test verdict entirely depends on the relative transmission time of the messages and the order of their handling by the SUT.

The Autolink implementation of concurrent TTCN

Autolink generates concurrent TTCN specific information only during the saving of a test suite. Therefore, it does not matter if concurrent TTCN is enabled during the generation or translation of test cases. You may generate your test cases, save the test suite in non-concurrent form, then turn on concurrence and save the test suite again.

Figure 264 : Test configuration for the inres system

Declarations

Autolink supports one kind of test architecture. From this generic architecture and the SDL specification of the system, a concrete test architecture is derived. The following declarations are generated automatically:

Figure 264 shows the test configuration which is generated for the inres System. In addition, the following declarations are generated:

CM, Proceed_Indication and Ready_Indication are used for coordination messages between the main and parallel test components. These messages are generated automatically (see Synchronization below).

Note:

The test architecture and resulting default test configuration can not be changed within Autolink. The coordination message and corresponding constraints are not changeable neither.

Figure 265 : Sample test case description for a main test component

Dynamic behavior description

Autolink splits the internal test case description into separate trees for every test component. The Test Case Dynamic Behaviour table describes the behavior of the main test component; its name is equal to the name of the original MSC test description. Since the MTC does not control any PCOs, it only contains CREATE statements for every PTC at the beginning and a DONE event at the end. It may also contain attached synchronization test steps in between. Figure 265 shows a sample test case description. The (PASS) verdict on line 1 initializes the result variable R. At the end of the test case, R contains the final test verdict.

Each parallel test component gets a Test Step Dynamic Behaviour table of its own. The name of the test step is Test case name + _ + Test component name.

Synchronization

Coordination messages are automatically generated by Autolink wherever a condition appears in the MSC test description. As a consequence of the test architecture used by Autolink, synchronization is done via the main test component. Here is a description of the algorithm:

  1. For each MSC environment instance connected to a condition: Send a coordination message CM with constraint Ready_Indication to the MTC.
  2. For each MSC environment instance connected to a condition which has a send event immediately following the condition: Receive a coordination message CM with constraint Proceed_Indication from the MTC.

Figure 266 : Synchronization test step for a main test component

From the viewpoint of a parallel test component, this means that whenever it reaches a synchronization point, it sends a Ready_Indication message to the MTC. If the event immediately following the synchronization point is a send event, then the PTC first waits for a Proceed_Indication message, which it receives from the MTC. All coordination events are directly included in the dynamic behavior description of the PTC.

When it reaches a synchronization point, the main test component waits for Ready_Indication messages from every PTC involved in the synchronization. Afterwards, it sends Proceed_Indication messages to all PTCs which are about to send a message to the system under test. Since the reception of coordination messages from different PTCs can create a lot of alternative paths, all synchronization events for the MTC are put into test steps. Figure 266 shows an example of a synchronization test step for an MTC.

Note:

Coordination messages can not be specified manually in the MSC test description. There are two reasons for this: First, the Explorer and Autolink can not handle messages drawn between environment instances. Second, all instances in the MSC have to relate to a channel in the SDL specification. Since the main test component has no connection with the system under test, it is not possible to add an MTC instance to the MSC.

Caveats

In order to streamline test suites and enhance their readability, Autolink automatically merges test steps which contain identical behavior descriptions. Furthermore, empty test steps are removed.

If your MSC test descriptions contain MSC references and concurrent TTCN is used to save the test suite, then the test step streamlining of Autolink may lead to unexpected results: For example, test steps for parallel test components may be renamed unexpectedly. Within test case and test step behavior descriptions, expected attachments of test steps may be missing. Nevertheless, these test suites are still correct and correspond to the original test descriptions.

Test Suite Timers

In this section, details regarding the declaration and use of test suite timers in test case MSCs is discussed.

Timer declarations

As explained in Using Timers, the recommended method for using test suite timers with Autolink is to explicitly declare all timers which appear in the test suite with Define-Timer-Declaration before test generation is started. Nevertheless, it is possible to have a mixture of implicit and explicit declaration. Below, the rules are listed which Autolink applies when creating or updating timer declarations. In any case, the syntactical correctness of the timer name is not checked.

Creation of a new explicit timer declaration

Note:

The only possibility to specify an empty duration field on purpose is to use an invalid string, e.g. a digit followed by a character.

Creation of a new implicit timer declaration

Note:

It is the responsibility of the test designer to make sure that either an explicit timer declaration exists or that an implicit declaration is correct. Autolink does not guarantee that a test suite which contains implicit timer declarations passes a TTCN syntax check.

Update of an explicit declaration with an explicit one

An existing explicit declaration can not be updated. A warning is displayed and the new declaration is ignored.

The only way to remove existing timer declarations is to use the Reset command.

Update of an explicit declaration with an implicit one

An existing explicit declaration can not be updated. However, Autolink checks if the unit of the implicit declaration matches the unit of the existing explicit declaration. If it does not match, a warning is displayed.

Update of an implicit declaration with an explicit one

Autolink checks if the unit of the new declaration is valid. If it is not, the existing implicit declaration is kept. If the unit is valid, the implicit declaration is replaced by the explicit one.

Update of an implicit declaration with an implicit one

Timer pitfalls

Timers in a test suite are declared globally. During test execution, each participating test component receives a complete set of timers which it can use independently. With respect to the readability of a test suite, the number of timer declarations should be minimized. This can be accomplished by declaring a minimal set of timers and reusing them in different test case MSCs.

If concurrent TTCN is enabled, identically named timers may also be used on different instances in the same MSC, because in the resulting TTCN test case, each MSC instance is handled by a different test component. However, if such an MSC is used in a non-concurrent context, then Autolink may produce unexpected test sequences and care should be taken.

Timer optimization

If concurrent TTCN output is enabled with Define-Concurrent-TTCN, then the dynamic behavior descriptions are optimized with regard to the placement of timer operations. If a timer START operation is followed immediately by a send event, then the START operation is placed on the same line as the send event. Correspondingly, if a timer CANCEL operation follows a receive event, then the CANCEL is moved up to the line with the receive event. As an example, if the test sequence according to the test case MSC is

START T1
  A ! someSignal
    A ? anotherSignal
      CANCEL T1

then Autolink optimizes this and generates the following test sequence:

A ! someSignal  START T1
  A ? anotherSignal  CANCEL T1


http://www.ibm.com/rational
Contents Index Previous Next