Lecture Notes in Computer Science 3472

424 Axel Belinfante, Lars Frantzen, and Christian Schallhart
• Related Tools: [FGK + 96, Gar98, dVT98, MK99, EW92, Eer94]
• Underlying Theory: [Tre96c, VT01]
• Case Studies: [BFdV + 99, dBRS + 00, dVBF02]
14.2.12 STG
Introduction
STG (Symbolic Test Generator) [CJRZ02] has been developed at IRISA/INRIA
Rennes, France. It is a tool that builds on the ideas on which TGV and TorX are
based, and adds symbolic treatment of variables (data) to these. In TorX and
TGV all variables in the specification are instantiated for all possible values 10 .
In contrast, variables in STG are treated in a symbolic way, leading to symbolic
test suites that still contain free variables, which are then instantiated during
test execution. So, STG supports both generation of symbolic test suites, and
execution of these.
STG is a relatively new tool. The theory underlying it has been published in
2000 [RdBJ00]; the tool was reported first in 2002 [CJRZ02]. STG has been used
to test simple versions of the CEPS (Common Electronic Purse Specification)
and of the 3GPP (Third Generation Partnership Program) smart card. The
results of the CEPS case study are summarized in [CJRZ01]. STG was used to
automatically generate executable test cases, and the test cases were executed on
implementations of the systems, including mutants. Various errors in the source
code of the mutants were detected.
At the time of writing, STG is not publicly available (this may change in the
future).
Test Generation Process
As mentioned in the introduction, STG supports both test generation, and test
execution, where the test cases that are generated and executed are symbolic. It
implements a symbolic form of ioconf [Tre96a] but without quiescence (for an
overview of implementation relations see Section 7.4, page 178).
STG takes as input a specification in the form of an (initialized, discussed
below) Input Output Symbolic Transition System (IOSTS) and a test purpose
and produces from these a symbolic test case. Such a symbolic test case is a
reactive program that covers all behavior of the specification that is targeted by
the test purpose.
For execution, the abstract symbolic test case is translated into a concrete test
program that is to be linked with the implementation. The resulting executable
program is then run for test execution, which can yield three possible results:
Pass, Fail or Inclusive, with their usual meaning.
An IOSTS differs from an LTS in the following way. An IOSTS has specification
parameters and variables. Actions are partitioned into input, output and
10 Except when Promela, or LOTOS with Smile, are used in TorX.