Model Based Testing with Labelled Transition Systems

Abstract

Abstract. Model based testing is one of the promising technologies to meet the challenges imposed on software testing. In model based testing an implementation under test is tested for compliance with a model that describes the required behaviour of the implementation. This tutorial chapter describes a model based testing theory where models are expressed as labelled transition systems, and compliance is defined with the 'ioco' implementation relation. The ioco-testing theory, on the one hand, provides a sound and well-defined foundation for labelled transition system testing, having its roots in the theoretical area of testing equivalences and refusal testing. On the other hand, it has proved to be a practical basis for several model based test generation tools and applications. Definitions, underlying assumptions, an algorithm, properties, and several examples of the ioco-testing theory are discussed, involving specifications, implementations, tests, the ioco implementation relation and some of its variants, a test generation algorithm, and the soundness and exhaustiveness of this algorithm.

Specification and Testing of E-Commerce Agents Described by Using UIOLTSs

“…The first one is close to the classical ioco implementation relation [5] where an implementation I is correct with respect to a specification S if the output actions executed by I after a sequence of actions is performed are a subset of the ones that can be executed by S. Intuitively, this means that the implementation does not invent actions that the specification did not contemplate. The formal definition of our first implementation relation was presented in [3].…”

Wirelessly lockpicking a smart card reader

“…In order to find these problems, it is good practice to incorporate some form of formal verification in the development and implementation of security products, see for instance [FL12]. Also, systematic and automated model checking techniques proposed in [Tre08] can help to detect and avoid implementation weaknesses like the privilege escalation in iClass. Alternatively, formalizing the whole design in a theorem prover [Bla01], [JWS11] may reveal additional weaknesses.…”

Monadic Sequence Testing and Explicit Test-Refinements

“…The following notions are known in the literature: -inclusion conformance [18]: all traces in SPEC must be possible in SUT, -deadlock conformance [10]: for all traces t ∈ Traces(SPEC) and b / ∈ In(t), b must be refused by SUT, and -input/output conformance (IOCO) [25]: for all traces t ∈ Traces(SPEC) and all ι ∈ In(t), the observed output of the SUT must be in Out(t, ι).…”