This tutorial is intended to guide you through some of the features of Autolink. There are some aspects of Autolink which are not covered by this tutorial. For a complete description of all Autolink facilities, please see Using Autolink.
To be able to follow the tutorial, some experience of the SDT Validator is needed. Therefore you should have read and practised Tutorial: The SDT Validator. You also need to have basic knowledge of ITEX.
The example protocol used in this tutorial is the inres system, the same as the one used in the TTCN Link tutorial.
The purpose of this tutorial is to make you familiar with Autolink. The tutorial is split into three parts. You are strongly recommended to read the tutorial sequentially as each exercise is founded on the previous one.
In the first exercise, you will start by creating a simple MSC. Based on this MSC, you will generate a TTCN test case and save it in a test suite. You will also learn how to manipulate constraints.
In the second session, you will develop a structured MSC. Once again a TTCN test case is generated, but this time by a direct MSC into TTCN translation. Additionally, so-called translation rules are introduced as a simple example for an Autolink configuration.
In the third part, you will use the Power Walk algorithm to create a large number of MSC test cases automatically. You will also learn how to save and load generated test cases in Autolink. This facility will allow you to compute test cases separately and distribute test generation over several computers (provided that you have more than one license).
It is assumed that you know how to generate an SDT Validator. In addition, you should be familiar with the basic functionality of the SDT Validator, the MSC Editor and ITEX. You may also find it useful to have knowledge of MSC diagrams.
Autolink assists you in the automatic generation of TTCN test suites based on an SDL specification. In a simple approach, a TTCN test suite is generated in three steps:
Constraints can be added, modified and deleted between any of the above steps.
In order to use Autolink, an SDT Validator application has to be generated and started. In this exercise, you will use the inres system, which is found in $telelogic/sdt/examples/inres.
"Inres" is short for Initiator-Responder. The inres system is an example of a simplified communication protocol intended to give a secure transfer of information over an unsafe communication medium. It provides a one-way, connection-oriented communication service that uses sequence numbers and retransmission to ensure that messages sent to the initiator side, are correctly received at the responder side.
|
Note: In order to generate a validator application that behaves as stated in the exercises, you should copy all files of the |
You also have to create two directories where MSC test steps and test cases will be stored.
TC (used for test cases) and TS (used for test steps). inres system in the Organizer. inres validator and open it in the Validator UI.First, you should define the location of the test cases and test steps directories which you have created prior to opening the validator:
TC directory. TS directory by first clicking the Current button and then double-clicking the TS directory.
|
Note: The directory settings can be saved when you leave the validator. |
You should also set up proper test value definitions for the inres system:
integer. integer. 55 as the new test value in the Value field.The first step in the test case generation process is the choice of a path. A path describes a trace through the SDL system. This trace consists of internal and external events. External events are signals sent to or from the environment.
Autolink uses system level MSCs to abstract from a path by only considering the external events. System level MSCs consist of exactly one instance axis for the SDL system and one or more instance axes for the system environment. Figure 71 shows the MSC which you are going to create in this exercise.
Example1 in the Test case name field. Example1.mpr in the MSC test cases directory. You have now created your first MSC test case (see Figure 71). You may start the MSC Editor and take a look at it.
|
Note: You can create as many MSC test cases as you like, provided that they share the same root node. |
|
|
It is possible to get a list of all MSC test cases (and test steps) which are currently defined:
MSC test cases: Example1.mpr No MSC test steps found in directory '/home/tutorial/inres/TS/'.
In the next step, an internal test case representation has to be created which is based on the MSC test case defined above.
Example1.mpr.Autolink state space options are set. Define-Scheduling All Define-Transition Symbol-Sequence Define-Symbol-Time Zero Define-Priorities 2 1 3 2 2 Define-Channel-Queue ISAP1 On Define-Channel-Queue MSAP2 On Define-Max-Input-Port-Length 10 Current state is reset to root. MSC `Example1' loaded. ** Test case generation statistics ** No of reports: 1. MSCVerification : 1 report Generated states: 1614. Truncated paths: 0. Unique system states: 605. Size of hash table: 8000000 (1000000 bytes) No of bits set in hash table: 1210 Collision risk: 0 % Max depth: 48 Current depth: -1 Min state size: 432 Max state size: 580 Exploration started at: Tue Feb 16 22:42:08 1999 Exploration ended at: Tue Feb 16 22:42:08 1999 Exploration time: 000 h, 00 m, 00 s Constraints are checked for naming conflicts... Constraint 'cExample1' is renamed to 'cExample1_001'. Constraint 'cExample1' is renamed to 'cExample1_002'. Constraint 'cExample1' is renamed to and merged with 'cExample1_002'. Constraint 'cExample1' is renamed to and merged with 'cExample1_001'. Constraint 'cExample1' is renamed to 'cExample1_003'. Constraint 'cExample1' is renamed to 'cExample1_004'. Constraint 'cExample1' is renamed to 'cExample1_005'. Constraint 'cExample1' is renamed to 'cExample1_006'. Constraint 'cExample1' is renamed to 'cExample1_007'. Constraint 'cExample1' is renamed to 'cExample1_008'. Constraint 'cExample1' is renamed to 'cExample1_009'. Constraint 'cExample1' is renamed to 'cExample1_010'. Constraints with identical signal definitions are merged automatically... ... done. State space options are restored.
You have now generated your first test case. This test case is kept in memory. You will save it in a TTCN test suite soon.
It is possible to get a list of all test cases which have been generated so far.
Example1
You might also want to take a look at the internal test case representation before you create the TTCN test suite.
Example1.Example1 0 P: ISAP1 ! ICONreq - cExample1_010 1 P: MSAP2 ? MDATind - cExample1_009 2 P: MSAP2 ! MDATreq - cExample1_008 3 P: ISAP1 ? ICONconf - cExample1_007 4 P: ISAP1 ! IDATreq - cExample1_006 5 P: ISAP1 ! IDISreq - cExample1_005 6 P: MSAP2 ? MDATind - cExample1_004 7 P: MSAP2 ! MDATreq - cExample1_003 8 P: ISAP1 ? IDISind - cExample1_001 9 P: MSAP2 ? MDATind - cExample1_002 8 P: MSAP2 ? MDATind - cExample1_002 9 P: ISAP1 ? IDISind - cExample1_001
During test case generation, a number of constraints have been created. These constraints are also stored in memory and can be manipulated in several ways.
First of all, it is possible to print the list of all constraints:
cExample1_001 :
IDISind { }
cExample1_002 :
MDATind { mSDUType1 { id DR, num one, data 55 } }
cExample1_003 :
MDATreq { mSDUType1 { id AK, num one, data 55 } }
cExample1_004 :
MDATind { mSDUType1 { id DT, num one, data 55 } }
cExample1_005 :
IDISreq { }
cExample1_006 :
IDATreq { iSDUType1 55 }
cExample1_007 :
ICONconf { }
cExample1_008 :
MDATreq { mSDUType1 { id CC, num zero, data 55 } }
cExample1_009 :
MDATind { mSDUType1 { id CR, num zero, data 0 } }
cExample1_010 :
ICONreq { }
As you can see, 10 constraints have been created during test generation.Next, you can add a new constraint:
RequestCon in the Constraint name field. ICONreq.Constraints are checked for naming conflicts...Of course, there is no naming conflict, since there does not exist another constraint with the same name.
You might want to assign a more reasonable name to constraint cExample1_007 containing the signal ICONconf:
cExample1_007. ConfirmCon in the New constraint name field.Constraint cExample1_006 contains a signal parameter (value 55). You can define this signal parameter to be a parameter of the constraint.
cExample1_006. 1 for the first signal parameter. Data in the Formal parameter field. 0 in order to finish parameterization.The constraints cExample1_002 and cExample1_004 only differ in the first signal parameter (which is a struct). Therefore, you might want to merge them.
cExample1_002 as the first constraint. cExample1_004 as the second constraint. ProtDataUnit in the Formal parameter name field.To see the effect of all your operations, you can list the constraints again:
ConfirmCon :
ICONconf { }
RequestCon :
ICONreq { }
cExample1_001 :
IDISind { }
cExample1_003 :
MDATreq { mSDUType1 { id AK, num one, data 55 } }
cExample1_004(ProtDataUnit) :
MDATind { mSDUType1 ProtDataUnit }
cExample1_005 :
IDISreq { }
cExample1_006(Data) :
IDATreq { iSDUType1 Data }
cExample1_008 :
MDATreq { mSDUType1 { id CC, num zero, data 55 } }
cExample1_009 :
MDATind { mSDUType1 { id CR, num zero, data 0 } }
cExample1_010 :
ICONreq { }
In the test case, all references to the constraints have been updated appropriately:
Example1.Example1
0 P: ISAP1 ! ICONreq - cExample1_010
1 P: MSAP2 ? MDATind - cExample1_009
2 P: MSAP2 ! MDATreq - cExample1_008
3 P: ISAP1 ? ICONconf - ConfirmCon
4 P: ISAP1 ! IDATreq - cExample1_006(55)
5 P: ISAP1 ! IDISreq - cExample1_005
6 P: MSAP2 ? MDATind - cExample1_004
({ id DT, num one, data 55 })
7 P: MSAP2 ! MDATreq - cExample1_003
8 P: ISAP1 ? IDISind - cExample1_001
9 P: MSAP2 ? MDATind - cExample1_004
({ id DR, num one, data 55 })
8 P: MSAP2 ? MDATind - cExample1_004
({ id DR, num one, data 55 })
9 P: ISAP1 ? IDISind - cExample1_001
Since all constraints are deleted if they are no longer referred to by any generated test case or if you leave the Validator, they can be saved in a file:
Example1.con in the File field.A constraint can be removed:
cExample1_003.Error clearing constraint 'cExample1_003'.The constraint is currently used in a test case. RequestCon.In a final step, all generated test cases can be saved in a TTCN test suite. In this tutorial there is only one test case, but it is also possible to put several test cases into one test suite.
inres in the Test suite name field.inres.mp in the File field. inres.mp. You can exit the Validator now:
Yes.Up to now, you have created a TTCN test suite. This test suite is stored in MP format (machine processable), which is somewhat hard to read. Therefore you have to convert the test suite to GR (graphical notation) before you include it in the Organizer and open it in ITEX.
inres.mp as the source MP file. inres.itex is created in the destination directory. inres.itex in the Files section. If necessary change the file filter to *.itex.The TTCN test suite you have created so far contains information in three parts: the declarations part, the constraints part and the dynamic part.
In Windows, the test suite overview part will be generated automatically for example when you open one of the overview tables or before you print the test suite. After that, it will be kept updated.
On UNIX, you have to generate and update the overview explicitly:
If you have left SDT or the Validator UI temporarily, perform the following steps:
inres system in the Organizer. inres validator again.If you have not quit the inres validator, bring the application to its initial state now:
For a better understanding, a test case can be structured into different test steps. Typically, a test case consists of three parts:
In this section, you will create a test case with a preamble, a test body and a postamble. This test case will be identical to the one developed in Exercise 1: Basic Concepts except for its structural information.
You can define structured MSC test cases in a similar way as you did in Exercise 1: Basic Concepts.
Preamble in the Test step name field. Preamble.mpr in the MSC test steps directory.The preamble which you have just created is shown in Figure 73.
You should also create the body of the MSC test case:
define-root current in the input line to set the current root.Root of behaviour tree set to current system state Example2 in the Test case name field. Example2.mpr in the MSC test cases directory.Now you have defined the body of the test case. See Figure 72.
Figure 72 : The MSC Example2 -- test body
|
|
Finally, you create the postamble of the MSC.
define-root current in the input line to set the root.Root of behaviour tree set to current system state
Postamble in the Test step name field. Postamble.mpr in the MSC test steps directory.You have now created the postamble of the test case, see Figure 73.
Figure 73 : Preamble and Postamble MSCs
|
|
|
Before you can use MSC Example2 to generate a TTCN test case, you have to insert two global MSC references for the preamble and the postamble. To do this:
Example2.mpr stored in directory TC. Preamble and Postamble (without the file extension .mpr) as reference names.
|
|
Example2.msc.In the previous steps, you have changed the root of the behavior tree to the beginning of the postamble. Even though it is not necessary for a direct translation, you should better reset it before continuing.
Define-Root Original at the command line.You can list all MSC test cases and test steps currently stored on disk:
MSC test cases: Example1.mpr Example2.msc Example2.mpr MSC test steps: Postamble.mpr Preamble.mpr
It is also possible to remove test cases and test steps from disk. Since you do not need the temporary MSC Example2.mpr any more, you can delete it:
Example2.mpr. Yes.Autolink allows to define a configuration which guides the naming and parameterization of constraints, the introduction of test suite parameters and constants and the grouping of test cases and test steps into a hierarchy of test groups. An Autolink configuration consists of a set of rules which have to be written by the user.
In this tutorial you will not learn how to write configuration rules. Instead you will use a pre-defined configuration that covers some aspects of an Autolink configuration. For a detailed descriptions of configuration rules and corresponding examples see Translation Rules and Test Suite Structure Rules.
In a first step you have to create a new command file which contains the Autolink configuration:
config.com.# -------------------------------
# Autolink configuration file
# for the inres protocol
# -------------------------------
Define-Autolink-Configuration
TRANSLATE "ICONreq"
CONSTRAINT NAME "Connection_Request"
END
TRANSLATE "ICONconf"
CONSTRAINT NAME "Connection_Confirmation"
END
TRANSLATE "IDATreq"
CONSTRAINT NAME "Data_Request"
PARS $1="Data"
TESTSUITE PARS $1="DataValue"
END
TRANSLATE "IDISreq"
CONSTRAINT NAME "Disconnection_Request"
END
TRANSLATE "IDISind"
CONSTRAINT NAME "Disconnection_Indication"
END
TRANSLATE "MDATind" | "MDATreq"
IF $1 == "{ id CC, *, * }" THEN
CONSTRAINT NAME "Medium_Connection_Confirmation"
END
IF $1 == "{ id AK, *, * }" THEN
CONSTRAINT NAME "Medium_Acknowledge"
END
CONSTRAINT NAME "c_" + $0
END
End
Next, you have to load this configuration into the Validator:
config.com in the Files section.If an error message is displayed, you have probably made a spelling mistake in the command file. In this case, correct your file and try to reload the configuration.
In Generating the Test Case, you have learned how to generate an internal test case representation based on an MSC. For that purpose, a state space exploration has been started.
However, in some cases it is not possible to simulate the MSC, e.g. if the internal processes of the SDL system are not fully specified. In these cases, you have to translate an MSC test case directly into an internal test case representation (without performing a state space exploration).
Even though it should be possible to simulate the MSC Example2.msc, you will apply a direct translation in this exercise:
Example2.msc.Current state is reset to root. MSC 'Example2' loaded. Constraints are checked for naming conflicts... Constraint 'c_MDATind' is renamed to 'c_MDATind_001'. Constraint 'c_MDATind' is renamed to 'c_MDATind_002'. Constraint 'c_MDATind' is renamed to 'c_MDATind_003'. Constraints with identical signal definitions are merged automatically... ... done.
Take a look at the internal test case representation to see the difference with respect to test case Example1:
Example2.Example2 0 P: IN Preamble 1 P: ISAP1 ! ICONreq - Connection_Request 2 P: MSAP2 ? MDATind - c_MDATind_003 3 P: MSAP2 ! MDATreq - Medium_Connection_Confirmation 4 P: ISAP1 ? ICONconf - Connection_Confirmation 5 P: OUT Preamble 6 P: ISAP1 ! IDATreq - Data_Request(DataValue) 7 P: MSAP2 ? MDATind - c_MDATind_002 8 P: MSAP2 ! MDATreq - Medium_Acknowledge 9 P: IN Postamble 10 P: ISAP1 ! IDISreq - Disconnection_Request 11 P: ISAP1 ? IDISind - Disconnection_Indication 12 P: MSAP2 ? MDATind - c_MDATind_001 13 P: OUT Postamble 11 P: MSAP2 ? MDATind - c_MDATind_001 12 P: ISAP1 ? IDISind - Disconnection_Indication 13 P: OUT PostambleAlso take a look at the constraints to see what the translation rules in your configuration file have affected:
Connection_Confirmation :
ICONconf { }
Connection_Request :
ICONreq { }
Data_Request(Data) :
IDATreq { iSDUType1 Data }
Disconnection_Indication :
IDISind { }
Disconnection_Request :
IDISreq { }
Medium_Acknowledge :
MDATreq { mSDUType1 { id AK, num one, data 55 } }
Medium_Connection_Confirmation :
MDATreq { mSDUType1 { id CC, num zero, data 55 } }
c_MDATind_001 :
MDATind { mSDUType1 { id DR, num one, data 55 } }
c_MDATind_002 :
MDATind { mSDUType1 { id DT, num one, data 55 } }
c_MDATind_003 :
MDATind { mSDUType1 { id CR, num zero, data 0 } }
When a TTCN test suite is created, test steps can be stored in different formats. By default, test steps are put into the test step library. However, you might want to save them locally, i.e. attached to their test cases:
Local.Now, you are ready to save the test suite:
inres2_local in the Test suite name field. inres2_local.mp in the File field. inres2local.mp.You may want to save the test suite in different formats. To do this:
Global or Inline.It is possible to merge the new TTCN test case (with its constraints) with an existing test suite.
inres test suite you created in the first part of this tutorial is opened in ITEX. This test suite contains test case Example1. inres2_local.mp. inres2_local.mp file will now be merged into the old test suite.There are more possibilities to merge test cases: Autolink also provides commands to combine separately generated test cases within the Validator. For a detailed description see Computing Test Cases.
If you have left SDT or the Validator UI temporarily, perform the following steps:
inres system in the Organizer. inres validator again.If you have not quit the inres validator, bring the application to its initial state now:
In the previous exercises, you had to specify your MSC test cases manually. Creating test cases by hand gives you full control over what is tested.
However, you might not be interested in defining tests for particular aspects of your SDL system. Instead, you only wish to create a large number of test cases randomly which cover most symbols of the SDL system.
In this case, you can use the Power Walk algorithm provided by Autolink to generate test cases automatically.
In the first step, a number of PowerWalk reports have to be computed:
Starting Power Walk... Reports and symbol coverage table cleared. Successful walk #1. States: 97. Reports: 2. Coverage: 64.47 %. Time: 000:00:01. Successful walk #2. States: 365. Reports: 5. Coverage: 68.42 %. Time: 000:00:02. Successful walk #3. States: 572. Reports: 6. Coverage: 76.32 %. Time: 000:00:04. Successful walk #4. States: 1046. Reports: 7. Coverage: 80.26 %. Time: 000:00:08. Successful walk #5. States: 1537. Reports: 8. Coverage: 85.53 %. Time: 000:00:12. States: 2000. Reports: 8. Coverage: 85.53 %. Time: 000:00:15. Predefined number of failed walks reached ---> Abort.
The number of reports generated by the Validator may vary, since to a certain extent, Power Walk is based on a random search. Do not worry if you get different results, as you can a still perform the following steps.
The output above states that five reports have been generated. When traversing their corresponding paths, a total symbol coverage of 85.53 percent is reached. The Power Walk command stopped when it failed to create another report which increases coverage.
Since Autolink requires MSC test cases as input, you have to convert the PowerWalk reports into MSCs:
PowerWalk in order to save all PowerWalk reports.MSC test case is saved in file '/home/tutorial/inres/TC/PowerWalk_00001.mpr'. MSC test case is saved in file '/home/tutorial/inres/TC/PowerWalk_00002.mpr'. MSC test case is saved in file '/home/tutorial/inres/TC/PowerWalk_00003.mpr'. MSC test case is saved in file '/home/tutorial/inres/TC/PowerWalk_00004.mpr'. MSC test case is saved in file '/home/tutorial/inres/TC/PowerWalk_00005.mpr'.
In the previous exercises you have learned how to generate internal test case representations from MSCs. If you want more than one test case, you can either compute all test cases in the test cases directory at once -- by a single command -- or compute one test case after another.
For large SDL systems, test generation may take some time. In this case, it is advantageous not to compute all test cases in a single validator session. Instead, each test case (or a small number of test cases) should be computed separately, preferably in parallel on different machines.
To enable distributed test generation, Autolink allows to store internal test case representations on disk. After all test cases have been computed, their internal representations can be reloaded from disk and saved in a single test suite. While loading the test cases, Autolink checks them for consistency and merges identical constraints.
PowerWalk00001.mpr. PowerWalk_00001. TC directory by double-clicking. PowerWalk_00001.gen in the File field.Repeat steps 1 to 11 for all other PowerWalk test cases.
Once you have created all test cases and saved them in files, you can combine them and create a test suite.
PowerWalk_00001.gen in the Files section. Power in the Test suite name field. power.mp the File field. power.mp.In order to take a look at the TTCN test suite, you have to convert the MP file into TTCN-GR just the same way you did in the first and second example above.
You should have learned how to create structured system level MSCs, and how to generate TTCN test cases from those MSCs. Especially you have become acquainted with two ways of producing TTCN test cases: Test generation by state space search and test generation by a direct translation. While doing this, you have discovered many of the commands in the Autolink menus of the Validator. In addition, you should also know how to view the test suite in ITEX, how to generate the test suite overview and how to merge new test cases and constraints into an existing test suite in ITEX.