TGV: theory, principles and algorithms

Abstract

This paper presents the TGV tool allowing the automatic synthesis of conformance test cases from a formal specification of a reactive system. TGV has been developped by Irisa Rennes and Verimag Grenoble, with the support of the Vasy team of Inria Rhônes-Alpes. The paper describes the main elements of the underlying testing theory, based on a model of transitions system which distinguishes inputs, outputs and internal actions, and based on the concept of conformance relation. The principles of the test synthesis process are explained as well as the main algorithms. We then describe the main characteristics of the TGV tool. As a conclusion, we describe some on going works in test synthesis. I. CONFORMANCE TESTINGTesting, in all its variations, is one of the most used validation techniques. In this paper, we focus on conformance testing applied to reactive systems. By reactive system, we mean a software component which reacts to stimuli of its environment. Conformance testing consists in checking that the behavior of a real implementation of a reactive system (IUT for Implementation Under Test) is correct with respect to a specification. The code of the IUT is unknown, and its behavior is only visible by interaction with a tester which controls and observes the IUT through dedicated interfaces (called PCO for Points of Control and Observation). Conformance testing is a type of functional testing of a black box nature. A. Some basic conceptsIn the context of telecommunication protocols, the main concepts of this activity are described in the standard ISO 9646 [1]. Some of them are introduced here.A test case is an elementary test targeted to testing a particular functionality, called test purpose. A test suite is a set of test cases. The basic elements of a test case are interactions through PCO: outputs are stimuli sent in order to control the IUT's input events, inputs are observations of the IUT's output events. Inputs may lead to different verdicts. A Fail verdict denotes a divergence with the expected behaviour and the IUT is rejected. A Pass verdict is returned if the observation is correct and the test purpose is reached. An Inconclusive verdict is returned if a correct behavior is observed, but it is impossible to reach the test purpose. This is due to the fact that, in general, reactive systems cannot be completely controlled by a tester: it may have several outputs to the same input. The tester, specialized hardware, software or human operator, executes test cases. But as test cases are often described with some abstraction level (they are called abstract test cases), they must be translated into executable test cases. B. Formalizing for automationConformance testing is a costly activity which takes an important part in the global cost of a software. For a long time, the scientific community tries to automate the process of deriving test cases. For conformance testing, the reference behaviour is described by the specification which determines the verdicts. Automation thus induces formalizing the ...

Verification of behaviourist multi-agent systems by means of formally guided simulations

“…Such test purposes can, in particular, be represented formally. This approach is used on the TGV tool (Jard and Jéron, 2005), where both test purposes and SUTs are modelled as input-output transition systems (IOTSs). By performing a special synchronized product between them, along with other transformations, one gets another smaller automaton from which test cases can be extracted in order to assess whether the SUT is iococonformant to the specification.…”

“…Our approach is largely inspired by TGV (Jard and Jéron, 2005), which we saw in Section 2.2.2. But we differentiate ourselves fundamentally because our objective is not the generation of test cases, and in particular we are not tied to the ioco conformance relation.…”

“…The simulation purposes developed in this thesis are adapted from the notion of formal test purposes of Jard and Jéron (2005). As we saw in Section 3.4.1, what we reuse here is mainly the idea of employing a transition system to specify the relevant paths in another transition system, which allows the partial exploration of the latter.…”

“…As we saw in Section 3.4.1, what we reuse here is mainly the idea of employing a transition system to specify the relevant paths in another transition system, which allows the partial exploration of the latter. However, whereas Jard and Jéron (2005) are interested in using this partial exploration to generate test cases, a simulation purpose is used to select the simulation paths and check the relevant satisfiability criteria during the exploration itself. It thus provides a way to specify the relevant simulation runs.…”

“…This method is inspired by the use of formal test purposes in TGV (Jard and Jéron, 2005), a model-based software testing approach.…”