This chapter gives an introduction to ITEX and its functionality. It also includes a list of file types supported by ITEX.
When you have read this chapter and want to get more familiar with ITEX, you should read and practice Tutorial: The Basics of ITEX on UNIX.
If you want to know more about what is new in this release of ITEX, you should read News in Telelogic Tau 3.5.
|
Note: UNIX version This is the UNIX version of the chapter. The Windows version is Introduction to ITEX in Windows. |
ITEX is an abbreviation for Interactive TTCN Editor and eXecutor. ITEX is a family of tools for the development, specification and compilation of executable tests for the TTCN language. You can find more information about the ITEX tools in The ITEX Toolset.
With ITEX and TTCN, tests are specified in a way that is independent of implementation software and hardware, that is, the tests are only based on the system to be tested and not on the system performing the test. This has encouraged standards organizations to use the technology. Test suites for various standards, supplied by standardization authorities such as ETSI, can therefore be used by all manufacturers and users of that standard. The test suites are created in a graphical editor environment and checked for syntactic and semantic errors by means of a TTCN analyzer.
One of the ITEX tools is ITEX Access. It is a general tool for developing translators, code generators for different languages, automatic encoders and decoders, interpreters, reporters and analysis tools for TTCN test specifications.
In order to ease the production of an ETS (Executable Test Suite), Telelogic has developed ITEX Cadvanced, a code generator that generates C code from any Abstract Test Suite (ATS) written in TTCN. ITEX Cadvanced produces code for both concurrent and non-concurrent TTCN as well as a limited subset of ASN.1 (see C Code Generator for further details on the restrictions that apply). To complete the production of an ETS, the generated code must be adapted to the specific target environment.
The generated C code forms an ETS together with the Generic Compiler Interpreter (GCI) Interface. The GCI Interface standardizes the communication between a TTCN component supplied by a vendor and other test system components supplied by the customer, thus forming a Means Of Testing (MOT). GCI is a minimal interface for the adaptation of the generated code to a specific target environment. It makes ETS adaptation easy.
Telelogic Tau consists of ORCA1, SDT and ITEX. ITEX is an integrated set of tools used for creating, editing and maintaining TTCN documents. The ITEX tools and functionality will be described below. For more information about ORCA and SDT, see Introduction to ORCA and SDT.
You start ITEX by adding and opening TTCN documents in the Organizer. The Organizer is the main window in Telelogic Tau. It integrates and co-ordinates the individual tools as required. Several tools may be used simultaneously through the Organizer. For instance, one part of a design may be analyzed at the same time as another is edited.
The Organizer features a graphical view of all the diagrams and documents you are working with, making them an integrated part of the development process. This may include TTCN documents, SDL hierarchies, Messages Sequence Charts, Object Model diagrams, State Charts, Highlevel MSCs and text documents. The view may be freely organized according to your preference.
You can view and edit the contents of a TTCN test suite in the Browser and the Table Editor. The Browser gives information about the overall structure while the Table Editor is used for editing the contents of the TTCN tables.
The Browser presents the view of the overall structure of a test suite. You can manipulate the test suite by adding and deleting items. It is also possible to control the amount of information displayed in the Browser by collapsing and expanding the test suite.
Several Browsers, displaying different test suites, can be opened at the same time. You may also find it useful to create a sub Browser, in which you can select to display only a part of the test suite.
When you double-click a table that is included in a test suite, it will be opened in the Table Editor. In the Table Editor you can edit the standardized TTCN-GR tables, including the concurrent TTCN tables.
You can edit the declarations, constraints and dynamic tables manually in the Table Editor, and the menu choice Replace allows searching for and replacing of test strings. There are also other ways for editing which reduces the manual work and the risk of typing-errors: you can use the Data Dictionary, the SDT TTCN Link and the Autolink.
The test suite overview tables can be generated by the menu choice Generate SO.
An alternative to manually writing behaviour lines is to use the Data Dictionary. The Data Dictionary is included in the Table Editor, and by using it you can select system components -- for example PCOs, types, constraints and timers -- that are already declared, to build behaviour statements.
SDT TTCN Link is similar in use and appearance to the Data Dictionary. The difference is that with SDT TTCN Link, you generate TTCN declarations and interactively build behaviour tables based on an SDL specification. This ensures consistency between the test suite and the specification.
Autolink supports the automatic generation of declarations, constraints and dynamic behaviour tables in a TTCN test suite. The test generation is based on an SDL specification and a number of MSC diagrams. You may create these MSCs manually in the MSC Editor or automatically in the SDT Simulator or Validator. The output from Autolink is a test suite in MP file format which can be imported into ITEX and refined subsequently.
In general, it is easier to describe test cases by MSCs than to specify them in TTCN directly. Moreover, Autolink provides a number of facilities to control the format and enhance the readability of a generated test suite.
To complete the test suite, you have to generate the test suite overview tables, that is, the test suite structure, test case index and default index tables. The page numbers of the tables referenced in the index tables will also be calculated. No selection is required when you generate the overview and you can do it both from the Browser and the Table Editor.
You may search for all occurrences of a specified string and replace them with another. You can do this in the Table Editor, if you only want to replace strings within that table, as well as in the Browser, where the replacement works on a all the tables selected in the test suite.
The following operations can be performed on the entire test suite or selected parts of it:
You can create a selection in the Browser by specifying various predicates. They could be name or content patterns, cross reference predicates, type information or analysis results. The selections may later be used for presenting status information on the items selected. It is also possible to create sub Browsers from selections.
It is possible to produce a configurable textual report -- status information as analysis status or modification date -- on a test suite. The output may also be used for further processing in an awk script or Microsoft Excel.
You may compare two TTCN documents. This is often useful when you want to resolve conflicts before merging one of the documents into the other. When you want to compare two documents, you make selections in one test suite. These are then compared with the other test suite -- the destination test suite. Any similarities found will be logged and reported.
You can merge an entire TTCN document or selected parts of it into another TTCN document. This only works if there is no conflict, that is, no object in the source test suite has the same name as an object in the destination test suite.
It is also possible to merge the contents of an MP file into a TTCN document.
You can search for and display named tables. No selection is required and you can to it both from the Browser and the Table Editor.
The Analyzer performs a complete syntax check on TTCN and ASN.1 (as used in TTCN), as well as a number of static semantic checks, focusing on the existence and uniqueness of identifiers and the way they are being used.
When the Analyzer is started from a Browser, it will analyze selected items in the test suite. When the Analyzer is started from a Table Editor it will only analyze that table.
If any tables are found to be erroneous after analysis, the names of those tables will be displayed in the log. An easy way to find and open an erroneous table is to select the name of the table in the log and then select Find Table from the Tools menu in the Browser or the Table Editor.
The C Code Generator translates TTCN to ANSI-C. The C Code Generator reduces the time for code generation as well as the volume of the generated code. Automatically generated code is also free from the potential errors of manual coding. The generated code is independent of the target operative system and protocol. In order to be executable, the generated C code must be linked to a library containing the pertinent OS functions.
The Generic Compiler Interpreter interface (GCI) is an interface for the adaptation of the generated code to a specific target environment. The GCI interface focuses on what an abstract test suite needs in order to execute in terms of functionality, and on what is needed to integrate TTCN with a larger system.
The Simulator allows execution of a TTCN test suite in a host environment. The system under test consists of a simulated SDL system. When the ITEX Simulator is connected with the SDT Simulator, the combined system is simulated. The test cases are executed one by one or in batch. After the execution, the test coverage information can be visualized by the SDT Coverage Viewer.
ITEX Access makes the internal data structures representing the test suite, available for application programs. It can be seen as a platform for writing applications related to an abstract test suite, for example code generators, interpreters, report tools and analysis tools.
Access provides a default mechanism for accessing the information, but gives you total freedom to override this for one better fitted to your needs.
The TTCN language supports two notations that are equivalent: TTCN-GR -- the graphical notation -- and TTCN-MP -- the textual notation.
TTCN-GR is the format used when you edit a test suite in ITEX. ITEX prints a TTCN document in the TTCN-GR format according to ISO/IEC 9646-3.
When you print, configurable headers and footers, double or single sided printing and partial prints are supported. The output format is PostScript, which also makes it possible to print the test suite to a file.
It is possible to export TTCN documents to TTCN-MP format. Selected items in the Browser -- a single table or sets of tables -- may also be exported to TTCN-MP format. The test suite that is to be exported, does not have to be correct, analyzed or complete.
It is also possible to import a document in TTCN-MP format. There is a high tolerance for errors and any error correction can be done in ITEX, after analysis, rather than in the original MP file.
ITEX supports a number of different file types with various suffixes:
The working structure and table files are the internal ITEX files and will be created temporarily. ITEX checkpoints automatically to these files during editing but the main data base files and the working files are updated only on save.
UNIX commands such as mv, cp, rm etc. can be used on these files (but use with caution!).
When a TTCN document is opened, a lock file for the working files (which has the additional suffix -lock) is automatically created. This means that no other user can access these working files.
To avoid a problem in NFS with unreliable file locking, ITEX 3.X is by default configured to only use normal lock file semantics. This implies that if the lock file associated with a TTCN document file exists, ITEX will refuse to open it.
The resource itex*fcntl:true and the corresponding switch -fcntl enables the use of explicit file locking compatible with ITEX 2.0 in addition to the normal lock file semantics. This also removes a possible (but unlikely) race condition.
Entire ITEX data bases may be transferred between storage areas. This is useful in order to preserve information that is lost in the TTCN-MP format. Use the usual UNIX commands to achieve this.