Automated support for deriving test requirements from UML statecharts

Abstract

Many statechart-based testing strategies result in specifying a set of paths to be executed through a (flattened) statechart. These techniques can usually be easily automated so that the tester does not have to go through the tedious procedure of deriving paths manually to comply with a coverage criterion. The next step is then to take each test path individually and derive test requirements leading to fully specified test cases. This requires that we determine the system state required for each event/transition that is part of the path to be tested and the input parameter values for all events and actions associated with the transitions. We propose here a methodology towards the automation of this procedure, which is based on a careful normalization and analysis of operation contracts and transition guards written with the Object Constraint Language (OCL). It is illustrated by one case study that exemplifies the steps of our methodology and provides a first evaluation of its applicability.

Test Case Generation Based on State and Activity Models.

“…They also provide an algorithm which generates a test suite for a given state chart model. Ali et al [4] [14] have considered interactions among objects in their work, though their focus is again on class-level testing. Their work produces a test case specification consisting of a feasible sequence of transitions.…”

“…Activity diagrams are also used for gray-box testing and checking consistency between code and design nearer to the code. The presence of loop and concurrent activities in the activity diagram results in path explosion Among all UML models, statechart diagrams have perhaps received the most attention from researchers for generation of test cases [8,10,14,9,22,28]. Most of the reported work [22,28] addresses class-level testing.…”

“…In contrast with the work in [16,8,14], the faults such as state initialization faults, object's state-activity dependency faults and operational faults in one use case can be covered by SAD. But in [16,8,14], they have not discussed or given attention towards these faults.…”

“…But in [16,8,14], they have not discussed or given attention towards these faults. if an object's state initialization fault occurs, then it is imperative to assume faults in its operations and therefore there is no need to apply test cases corresponding to the operation.…”

“…UML can be used to describe different aspects of a system including static, dynamic and use case views of a system. Of late, test case generation from UML statechart diagrams [8,10,14,9,22,7,28] and activity diagrams [3,16,5,25] has received considerable attention from researchers.…”