Criteria for generating specification-based tests

Abstract

This paper presents general criteria for generating test inputs from state-based s p eci cations. Software testing can only be formalized and quanti ed w h e n a solid basis for test generation can be d e n e d. Formal speci cations of complex systems represent a signicant opportunity for testing because they precisely describe what functions the software i s s u p p osed t o p r ovide in a form that can easily be manipulated. These techniques provide coverage criteria that are b ased o n the speci cations, and are made up of several parts, including test pre xes that contain inputs necessary to put the software into the appropriate state for the test values. The test generation process includes several steps for transforming speci cations to tests. Empirical results from a comparative case study application of these criteria are p r esented.

Testing with model checkers: a survey

“…If this is Transition α β γ 1 velocity = stop velocity = slow accelerate ∧ ¬brake 2 velocity = slow velocity = fast accelerate ∧ ¬brake 3 velocity = fast velocity = slow ¬accelerate ∧ ¬brake 4 velocity = slow velocity = stop ¬accelerate ∧ ¬brake 5 T rue velocity = stop brake 6 velocity = fast velocity = fast accelerate ∧ ¬brake 7 velocity = stop velocity = stop ¬accelerate ∧ ¬brake not an observable transition, then an additional postamble sequence is necessary. The transition coverage criterion described by Offutt et al [50] is basically identical to the simple transition coverage criterion. Simple Guard Coverage is similar to decision coverage in code based testing.…”

“…Finally, Transition Pair Coverage is another related coverage criterion given in [50] that is also useful in the transition system context. In contrast to (simple) transition it requires that all feasible pairs of transitions are covered.…”

“…Condition Coverage [50] requires that for each condition (clause) in a predicate there is a test case where the condition evaluates to true, and a test case where the condition evaluates to false. This criterion corresponds to the clause coverage criterion [49] for logical expressions, and can also be applied to guard conditions.…”

“…Full Predicate Coverage [50] requires that each clause in each predicate is tested independently. In contrast to the previously discussed clause wise coverage criteria, the values of minor clauses may change as long as the value of the predicate is still determined by the considered clause.…”

Experimental evaluation of the tolerance for control‐flow test criteria

“…• Full Predicate Coverage (FPC): Every statement in the program has been executed at least once, and each condition in a decision has taken all possible outcomes where the value of the decision is directly correlated with the value of a condition [19]. This means that the test-set must include test-cases such that the value of the decision is different when the condition changes.…”