Mutant Minimization for Model-Checker Based Test-Case Generation

Similar documents
Test-Case Generation and Coverage Analysis for Nondeterministic Systems Using Model-Checkers

Using Model-Checkers for Mutation-Based Test-Case Generation, Coverage Analysis and Specification Analysis

Experiments on the Test Case Length in Specification Based Test Case Generation

Nondeterministic Testing with Linear Model-Checker Counterexamples (Research Paper)

Specification Centered Testing

Generating MC/DC Adequate Test Sequences Through Model Checking

Lecture 2: Symbolic Model Checking With SAT

Generating minimal fault detecting test suites for Boolean expressions

Error Detection Rate of MC/DC for a Case Study from the Automotive Domain

Mutation of Model Checker Specifications for Test Generation and Evaluation

Monitoring Interfaces for Faults

Discrete Optimization. Lecture Notes 2

COMP 763. Eugene Syriani. Ph.D. Student in the Modelling, Simulation and Design Lab School of Computer Science. McGill University

Leveraging DTrace for runtime verification

Auto-Generating Test Sequences for Web Applications *

A Test Case Generation Algorithm for Real-Time Systems

Fault Class Prioritization in Boolean Expressions

On The Theoretical Foundation for Data Flow Analysis in Workflow Management

PCP and Hardness of Approximation

Combining Complementary Formal Verification Strategies to Improve Performance and Accuracy

Introduction to Software Testing Chapter 5.1 Syntax-based Testing

NP-Hardness. We start by defining types of problem, and then move on to defining the polynomial-time reductions.

Finite State Verification. CSCE Lecture 21-03/28/2017

A Case Study for CTL Model Update

BRANCH COVERAGE BASED TEST CASE PRIORITIZATION

CMPSCI 521/621 Homework 2 Solutions

Integrating White- and Black-Box Techniques for Class-Level Regression Testing

Efficient Synthesis of Production Schedules by Optimization of Timed Automata

Local Two-Level And-Inverter Graph Minimization without Blowup

Java-MOP: A Monitoring Oriented Programming Environment for Java

An Initial Approach to Explaining SLA Inconsistencies

Sliced Path Prefixes: An Effective Method to Enable Refinement Selection

Research Collection. Formal background and algorithms. Other Conference Item. ETH Library. Author(s): Biere, Armin. Publication Date: 2001

3 No-Wait Job Shops with Variable Processing Times

Finite State Verification. CSCE Lecture 14-02/25/2016

Static Safety Analysis of UML Action Semantics for Critical Systems Development

Overview. Discrete Event Systems - Verification of Finite Automata. What can finite automata be used for? What can finite automata be used for?

Part I: Preliminaries 24

Detecting Logical Errors in SQL Queries

Model Checking VHDL with CV

Model-checking with the TimeLine formalism

Formal Analysis and Verification of a Communication Protocol

The SPIN Model Checker

On Code Coverage of Extended FSM Based Test Suites: An Initial Assessment

Model Checkers for Test Case Generation: An Experimental Study

Automatic Synthesis of a Voting Machine Design

What is Mutation Testing? Mutation Testing. Test Case Adequacy. Mutation Testing. Mutant Programs. Example Mutation

Binary Decision Diagrams

T Reactive Systems: Kripke Structures and Automata

Automated Refinement Checking of Asynchronous Processes. Rajeev Alur. University of Pennsylvania

CLAN: A Tool for Contract Analysis and Conflict Discovery

Model-Checking Concurrent Systems. The Model Checker Spin. The Model Checker Spin. Wolfgang Schreiner

Computer Science Technical Report

Deductive Methods, Bounded Model Checking

Incremental Runtime Verification of Probabilistic Systems

Scenario Graphs Applied to Security (Summary Paper)

Framework for replica selection in fault-tolerant distributed systems

Logic Model Checking

ALASKA Antichains for Logic, Automata and Symbolic Kripke structures Analysis

Syntactic Optimizations for PSL Verification

Coverage Criteria for Model-Based Testing using Property Patterns

A METRIC BASED EVALUATION OF TEST CASE PRIORITATION TECHNIQUES- HILL CLIMBING, REACTIVE GRASP AND TABUSEARCH

F-Soft: Software Verification Platform

Parallel Model Checking of ω-automata

Constraint (Logic) Programming

The Resolution Algorithm

Lecture1: Symbolic Model Checking with BDDs. Edmund M. Clarke, Jr. Computer Science Department Carnegie Mellon University Pittsburgh, PA 15213

PRIORITIZE REGRESSION TEST CASES

A Novel Approach for Software Property Validation

Lecture notes on the simplex method September We will present an algorithm to solve linear programs of the form. maximize.

AN ALGORITHM FOR TEST DATA SET REDUCTION FOR WEB APPLICATION TESTING

Propositional Calculus: Boolean Algebra and Simplification. CS 270: Mathematical Foundations of Computer Science Jeremy Johnson

A Toolbox for Counter-Example Analysis and Optimization

Propositional Logic Formal Syntax and Semantics. Computability and Logic

An Eclipse Plug-in for Model Checking

Model checking pushdown systems

Formal Methods for Software Development

ExMAn: A Generic and Customizable Framework for Experimental Mutation Analysis 1

Timo Latvala. January 28, 2004

Semi-Passive Replication in the Presence of Byzantine Faults

Instrumentation of Java Bytecode for Runtime Analysis

Formal Verification of Control Software: A Case Study

System Correctness. EEC 421/521: Software Engineering. System Correctness. The Problem at Hand. A system is correct when it meets its requirements

VALCSP solver : a combination of Multi-Level Dynamic Variable Ordering with Constraint Weighting

Verifying Liveness Properties of ML Programs

Formal Verification: Practical Exercise Model Checking with NuSMV

Action Language Verifier, Extended

Measuring the Effectiveness of Method Test Sequences Derived from Sequencing Constraints

Review of Regression Test Case Selection Techniques

Procedia Computer Science

Suggesting Edits to Explain Failing Traces

Determining Differences between Two Sets of Polygons

Model Checking. Dragana Cvijanovic

Regression Verification - a practical way to verify programs

Semantic Errors in Database Queries

Simulink Design Verifier vs. SPIN a Comparative Case Study

Multi-event IDS Categories. Introduction to Misuse Intrusion Detection Systems (IDS) Formal Specification of Intrusion Signatures and Detection Rules

System safety property-oriented test sequences generating method based on model checking

Generating Tests for Detecting Faults in Feature Models

The Maude LTL Model Checker and Its Implementation

Transcription:

Mutant Minimization for Model-Checker Based Test-Case Generation Gordon Fraser and Franz Wotawa Institute for Software Technology Graz University of Technology Inffeldgasse 16b/2 A-8010 Graz, Austria {fraser,wotawa}@ist.tugraz.at Abstract Mutation of model-checker specifications is used to generate test-cases automatically. In general, model-checker based techniques are efficient when using small, abstract models, but are limited in their applicability by the performance of the model-checker. Issues that contribute to potentially bad performance are equivalent mutants which result in no test-cases, and the fact that many different mutants lead to identical or subsumed test-cases. Another drawback of such approaches is that the size of resulting test-suites can be rather large, which might require test-suite reduction as an additional post-processing step. In this paper, we describe how the number of mutants can be minimized with special properties, which help to detect equivalent mutants more quickly and to avoid the creation of redundant test-cases. Consequently, the size of created test-suites is reduced. 1. Introduction Specification mutation has been suggested as a method to automatically generate test-cases with modelcheckers [3]. A model-checker can be used to automatically derive traces that illustrate the difference between original and mutated specification. Such traces can be used as testcases. In general, model-checker based test-case generation is very flexible and fully automated, but the applicability is limited by the performance of the model-checker. Although a model-checker is very efficient for smaller models, the state explosion problem quickly leads to performance problems. The research herein is partially conducted within the competence network Softnet Austria (www.soft-net.at) and funded by the Austrian Federal Ministry of Economics (bm:wa), the province of Styria, the Steirische Wirtschaftsfrderungsgesellschaft mbh. (SFG), and the city of Vienna in terms of the center for innovation and technology (ZIT). Abstraction methods and improved model-checking techniques are directions of research that will hopefully lead to improvements with regard to the performance of the testcase generation. Part of the problem, however, is caused by inefficient and redundant calls to the model-checker during the test-case generation process. For example, even though it is possible to detect equivalent mutants using a model-checker, this still requires an explicit call to the model-checker for each mutant and consumes a similar amount of time as the creation of a test-case. Consequently, time is spent on model-checking of mutants that do not contribute to the test-suite. Furthermore, experience has shown that a large number of mutants result in identical or subsumed test-cases. In our experience, test-suites resulting from mutation based approaches are usually far from minimal with regard to the mutation score (i.e., percentage of mutant models that can be distinguished from the original model). A similar observation has been made in coverage oriented testcase generation with model-checkers [9]. With increasing model size the number of mutants and therefore test-cases increases. Consequently, a necessary countermeasure might be test-suite reduction, where a subset of an existing testsuite is heuristically selected, such that a certain coverage criterion is fulfilled with as few test-cases as possible. In this paper, we present a simple approach to reduce the number of calls to the model-checker. The proposed solution represents model mutants using characteristic properties. These are used to identify equivalent mutants and to detect already covered mutants during test-case generation, thus excluding them from the test-case generation. The model-checker NuSMV [5] is used to illustrate the presented ideas. Resulting test-suites are smaller than when using a traditional approach, while the mutation score with regard to those mutants used for test-case generation is not changed. As the size of a test-suite is reduced, the effects on the fault sensitivity are empirically analyzed.

2. Test-Case Generation with Model-Checkers and Mutation A model-checker is a tool that takes as input an automaton-based model of a system and a property specified with temporal logics, and then effectively examines the complete state space of the model in order to determine whether the property holds. Detected violations are illustrated with counterexamples, which in current modelcheckers are implemented as linear sequences of states that begin in an initial state of the model and lead to some state such that the property violation is demonstrated by the sequence or the final state of the sequence. Testing with model-checkers is based on the idea to interpret counterexamples as test-cases. The state of a model is described by a set of variables. Therefore, each state in a counterexample can be interpreted as a valuation of all variables. The values of variables that represent the input the system receives from its environment are used as test data, and the values of output variables that are calculated by the model are used as test oracle. The use of mutation for model-checker based test-case generation was initially proposed by Ammann et al. [3]. As a model-checker takes as input an automaton-based model and a property, the creation of counterexamples can be forced by applying mutation to either of the two inputs. The automaton is not mutated directly; instead, the textual model representation used as input to the model-checker is modified. The resulting mutants are checked against a given specification, and counterexamples illustrate specification violations. A slightly different approach is taken by Ammann and Black [1], who apply mutation to properties that reflect the transition relation of the model. The mutants of the reflected properties are then checked against the model, and counterexamples are used as test-cases. A kind of equivalence check is performed in the state-machine duplication approach by Okun et al. [10], who combine a mutant with its original model and then use the model-checker to search for paths that show how mutants affect output variables. In a related approach, mutation based testing with regard to safety properties is described by Ammann et al. [2]. In this paper, we consider methods that are based on mutation of the model [2, 3, 10]. The model-checker has to encode the state space of each mutant, e.g., using ordered BDDs. The time this takes depends on the model, the chosen model-checker and the techniques it implements. For example, our experience is that the model encoding phase in NuSMV [5] consumes a large part of the overall modelchecking time. Consequently, equivalent mutants consume time for encoding and model-checking, but result in no testcases. Furthermore, mutants often result in identical testcases, or test-cases that are subsumed by other, longer testcases. Such mutants are redundantly checked, because resulting test-cases do not contribute to the overall fault sensitivity of a test-suite. Even after removal of subsumed test-cases, the size of a resulting test-suite is often very large. This can be especially problematic for regression testing, and therefore testsuite reduction [7] is sometimes applied to minimize the test-suite size. Here, time is consumed to create test-cases in the first place, and then more time is consumed trying to heuristically find a proper subset of the resulting test-cases, that is minimal with regard to a given coverage criterion. As a countermeasure to these problems, we propose to use dedicated properties to minimize the number of modelchecker calls, and consequently the performance and testsuite size are improved significantly. 3. Characteristic Properties We use the formal framework for transition systems described by Rayadurgam and Heimdahl [12] in order to discuss the ideas presented in this paper. This framework can be applied to any transition based formalism, including NuSMV models. A system state is uniquely determined by the values of n variables {x 1, x 2,..., x n }. Each variable x i has a domain D i, and consequently the reachable state space of a system is a subset of D = D 1 D 2... D n. The set of initial values for the variables is defined by a logical expression ρ. The valid transitions between states are described by the transition relation, which is a subset of D D. The transition relation is defined separately for each variable using logical conditions. For variable x i, the condition α i,j defines the possible pre-states of the j-th transition, and β i,j is the post-state condition. A simple transition for a variable x i is a conjunction of α i,j, β i,j and a guard condition γ i,j : δ i,j = α i,j β i,j γ i,j. The disjunction of all simple transitions for a variable x i is a complete transition δ i. The transition relation is the conjunction of the complete transitions of all the variables {x 1,..., x n }. Consequently, a basic transition system is defined as follows: Definition 1 (Transition system) A transition system M over variables {x 1...x n } is a tuple M = (D,, ρ), with D = D 1 D 2... D n, = i δ i, and the initial state expression ρ. For each variable x i there is a transition relation δ i, that is the disjunction of several simple transitions δ i,j = α i,j β i,j γ i,j, where α i,j, β i,j, and γ i,j are prestate, post-state, and guard conditions of the j-th simple transition of variable x i. Mutation is applied to the textual representation of a model, for example in the input language of the modelchecker NuSMV. Conceptually, we can think of mutation as changes in a simple transition δ i,j of a variable x i. We

only consider first order mutants, i.e., mutants that differ in a single change from the original model. Definition 2 (Mutant) A mutant M = (D,, ρ) of transition system M = (D,, ρ) differs from M in exactly one simple transition. That is, i, j : δ i,j δ i,j k j : δ i,k = δ i,k l i : δ l = δ l. Besides a formalism for system modeling, modelcheckers use different property specification languages. In this paper, we use the Linear Temporal Logic (LTL) [11]. An LTL formula consists of atomic propositions, Boolean operators and temporal operators. In this paper, we use the operators and : The operator refers to the next state. E.g., a expresses that a has to be true in the next state. is the always operator, stating that a condition has to hold in all states of a trace. In [12], the guard and the post-state condition can refer to the values of variables in the pre- and post-state. For simplicity, we assume that the guard γ i,j refers only to the pre-state, and β i,j only refers to the values of variables in the post-state. Without this assumption, γ i,j or β i,j can refer to the values of variables at two different states in time. A possible solution to this problem is to use shadow variables that track the values from the previous solution, as described by Ammann and Black [1]. A shadow variable for the previous state always has the previous value of the variable it shadows, therefore all variables that refer to the previous state in β i,j can be replaced with their corresponding shadow variables. The same is possible the other way round for γ i,j. The disadvantage of such an approach is, that the state space is increased by the shadow variables. A different solution would be to access variables in the correct context specific to a operator. This, however, requires that the constraints γ i,j and β i,j can be split into two parts γi,j i, γj i,j and βi,j i, βj i,j, respectively, such that: β i,j = βi,j i βj i,j, and γ i,j = γ i i,j γj i,j, respectively. From the definition of a transition system it follows that any M which has the transition δ i,j = α i,j β i,j γ i,j has to satisfy the following property, which expresses that always ( ) when pre-state α i,j and guard condition γ i,j are true, the post-state condition β i,j has to be true in the next state ( ): ψ 1 := ((α i,j γ i,j ) β i,j ) (1) Assume a mutant that contains a simple transition δ i,j = α i,j β i,j γ i,j where the original model takes δ i,j = α i,j β i,j γ i,j ; i.e., one of α i,j, β i,j, or γ i,j syntactically differs from the original model. This mutant satisfies the following property, which states that whenever the modified pre-state and guard condition are true, the modified post-state condition has to be true in the next state: ψ 2 := ((α i,j γ i,j) β i,j) (2) A mutation can have different effects. If the mutation has no effect on the transition system, then the mutant is referred to as equivalent. We define a mutant to be equivalent, if. If this is not the case, then the mutant is inequivalent. If a mutant is inequivalent, this means that at least one of the following cases applies: (1) The mutant model contains behavior that the original model does not allow. (2) The original model contains behavior that the mutant model does not allow. In the first case the mutant does not satisfy ψ 1. In the latter case the original model does not satisfy ψ 2. Note, that this definition of mutant equivalence does not take into account that some behaviors of the mutant might not be observable. Theoretically, a model can contain not only input and output, but also hidden variables. A change might not be observable if only hidden variables are affected by the change, but the change does not propagate to an observable output. We use the language of the model-checker NuSMV in this paper to describe transition systems. Listing 1 is an example of how a transition relation of a variable can be defined in NuSMV. Each entry of the case statement corresponds to a simple transition δ i,j for variable x i. The conditions φ j correspond to the conjunctions of α i,j and γ i,j, and β i,j corresponds to the atomic proposition x i = ξ j, where x i denotes x i in the post-state. There is an ordering on the conditions, therefore strictly speaking, the conditions are to be interpreted as φ 1, φ 1 φ 2, etc., and in the general case as: ( 1 j<k φ j) φ k. ASSIGN next(x i ) := case φ 1 : ξ 1 ; φ 2 : ξ 2 ;... esac; Listing 1. ASSIGN section of an SMV file. The transition relation of a variable x i is given as a set of conditions φ j and next values ξ j. The property ψ 1 can be instantiated for a model M corresponding to Listing 1 and the k-th transition of variable x i as follows: ψ xi,k 1 := ((( φ j ) φ k ) x i = ξ k ) 1 j<k The property ψ 2 can be instantiated similarly. For example, assuming a mutant of Listing 1 that uses φ 2 instead of φ 2, ψ 2 is instantiated as follows: ψ xi,2 2 := (( φ 1 φ 2) x i = ξ 2 )

Ideally, we want a property ψ for M which identifies an inequivalent mutant simply if M does not satisfy ψ: M = ψ M M (3) If M is equivalent to M, then M = ψ 2. If M = ψ 2, then we know that M and M are inequivalent. This corresponds to the left-to-right implication in equation 3. The right-to-left implication is not fulfilled by ψ 2, because a mutant can be inequivalent although M = ψ 2. This is the case if the mutated simple transition simply restricts the set of possible transitions. Therefore, the right-to-left implication in equation 3 requires another property to cover all cases: ψ 3 := ((α i,j γ i,j (α i,j γ i,j)) β i,j) (4) The property ψ 3 covers those cases where the mutant removes possible transitions from the model. For our example NuSMV mutant, this can be instantiated as follows: ψ xi,2 3 := (( φ 1 φ 2 φ 2) x i ξ 2 ) Definition 3 (Characteristic Property) The characteristic property ψ of mutant M = (D,, ρ) of transition system M = (D,, ρ) is ψ := ψ 2 ψ 3, with ψ 2 and ψ 3 given in equations 2 and 4, respectively. The characteristic property ψ of a mutant is the conjunction of ψ 2 and ψ 3. A mutant is inequivalent, iff M = ψ, which means that ψ fulfills equation 3. The idea of characteristic properties is similar to the reflected properties described by Ammann and Black [1]. However, not all equivalent or killed mutants can be represented or detected with reflected properties. The conditions of a case statement are unfolded with a process the authors call expoundment, similarly like in the NuSMV instantiation of ψ 1, ψ 2, and ψ 3. Therefore, reflection together with expoundment results in properties similar to ψ 2. As described above, this is not sufficient to identify all possible inequivalent mutants. 4. Using Characteristic Properties to Optimize Test-Case Generation Eliminating Equivalent Mutants: Model-checkers can be used to perform equivalence checks in order to detect equivalent mutants. For example, the state-machine duplication method presented by Okun et al. [10] combines a model and a mutant, and then queries the model-checker whether there exists a path such that the outputs of the model and the mutant differ when using the same inputs. The overall time consumed by this equivalence check can be reduced by using characteristic properties (Definition 3). For each mutant, a characteristic property is created. Then, the original model is checked against these properties. This improves the performance because (1) the model encoding phase only has to be done once and (2) the state space is smaller because the model is not modified. For example, using the method of Okun et al. [10], the state space is twice the size of that of the normal model. The performance can be further improved because it is sufficient to detect that a model does not satisfy the property, but counterexamples are not necessary. For example, when using the symbolic model-checker NuSMV, counterexample calculation, which takes considerable time, can be deactivated. If counterexamples are created, this process can be considered as an improvement of [1] that results in more test-cases. As noted earlier, an inequivalent mutant might not be observably different. When using characteristic properties to detect equivalent mutants this is acceptable: Only characteristic properties of really equivalent mutants are satisfied by a model, while there is a small chance that an identified inequivalent mutant is in fact equivalent. The worst case is that not as many mutants are excluded from the test-case generation as might be possible. Detecting Killed Mutants: Even if a mutant is not equivalent to the original model, it might still be unnecessary to use it for test-case generation. Often, different mutants result in identical test-cases. On the one hand, this can be because mutants cannot only be equivalent to the original model but also amongst themselves. On the other hand, different mutants can also lead to identical test-cases, and as our experience shows often do so. Another related performance drawback is caused by similar test-cases, where one is a prefix of another and can therefore be omitted. Test-suites also tend to get rather large, which might require test-suite reduction as a post-processing step. There are approaches of how to eliminate redundant test-cases for a complete test-suite (e.g., winnowing [1]), but ideally it should be avoided to call the model-checker on mutants unnecessarily, before creating redundant test-cases. The characteristic properties introduced in the previous section can be used to solve these problem. A test-case kills a mutant, if it can distinguish between the original model and the mutant. According to our definition of inequivalent mutants, a test-case can distinguish between original model and mutant only if it covers a modified transition. Consequently, a test-case that kills a mutant is also inconsistent with the characteristic property of that mutant. The time consumed by the test-case generation can be reduced by monitoring characteristic properties. Each time a test-case is created it is determined which characteristic properties are violated. A violated characteristic property shows that the mutant is already killed, and the mutant and its characteristic property can be removed. Note that this method relies on our definition of equivalence. If a mutant

is only internally inequivalent but the difference is not observable, then it might be excluded from test-case generation although there is no test-case that propagates the effect of the mutation to an observable output. We believe that in scenarios where this is not acceptable, no test-suite minimization at all can be applied. In the worst case, m mutants result in m unique testcases, and no test-case kills more than one mutant. Then, m 1 properties have to be analyzed after the first test-case, m 2 after the second, etc. Consequently, there is an upper bound of m (m + 1)/2 such analyses. In order to achieve a performance improvement, monitoring m (m + 1)/2 properties has to be faster than model-checking m mutants. There are different techniques that can be used for the monitoring. For example, test-cases can be formulated as verifiable models and then model-checked against the characteristic properties. Such a process is used for coverage analysis with model-checkers. Test-cases are represented as models by adding a special state counter variable and by setting all other variables depending only on the value of this state counter [1]. A different approach avoiding the use of a model-checker is taken by rewriting techniques used in property monitoring in the field of runtime verification. We propose to use LTL rewriting, which is an efficient method to monitor LTL formulas. For example, the method described by Havelund and Rosu [8] can be adapted to apply to characteristic properties. It defines a set of simple rewriting rules that are based on the states of an execution trace. An LTL formula is rewritten with every state of a trace, and if it results in a contradiction, then a property violation is detected. Such an approach is faster than model-checking; e.g., Havelund and Rosu claim their implementation is capable of 3 million rewritings per second. In [6] we used such a rewriting approach in the context of coverage based test-case generation with model-checkers. Optimized Test-Case Generation: The normal approach to test-case generation with model-checkers and mutation is to create a set of mutants, and then call the model-checker on the mutants with either requirement or dedicated properties. Figure 1 extends this scheme by creating characteristic properties together with the mutant models. The characteristic properties can be used to eliminate equivalent mutants before starting the test-case generation, or before starting a new model-checker call on the mutant. Counterexamples are not only stored as test-cases but also applied to the characteristic properties with rewriting techniques. Any characteristic property that is not satisfied by a counterexample represents a killed mutant, therefore the corresponding mutant does not need to be included in the test-case generation. As model-checking the mutants is generally slower than monitoring properties, this procedure will improve the performance for all but very small models. Less mutants are model-checked because redundant test-cases are avoided. At the same time, the size of resulting test-suites is reduced. The mutation score with regard to the mutants used for testcase generation is not changed. The order in which mutants are selected for test-case generation has an influence on the number of necessary testcases, as different test-cases kill different sets of mutants. As shown in [9], the minimal test-suite problem is NP-hard. Therefore, creation of an minimal test-suite is not feasible. In practice, random selection of mutants works very well. Heuristic selection might be considered in future research. The performed minimization is related to the test-suite reduction problem [7], where a suitable subset of given testsuite is computed. Consequently, the drawbacks of testsuite reduction also apply to this approach: While maximal mutation score with regard to the mutants used for test-case generation is still achieved, every avoided test-case might reduce the overall fault sensitivity. Model Test specification mutation Char. properties Mutants remove redundant or equivalent mutants monitor properties check model Counterexamples Figure 1. Optimized test-case generation. 5. Empirical Results To evaluate the described ideas, a simple prototype implementation was applied to a manually created model of a windscreen wiper controller, provided by Magna Steyr. NuSMV reports a total of 2 44.8727 states, 93 BDD variables and 174762 BDD nodes after model encoding. All experiments were conducted on a PC with Intel Core Duo T2400 processor and 1GB RAM. As an example test-case generation method we used the state-machine duplication approach described by Okun et al. [10] described earlier, as it does not depend on requirement properties. The following mutation operators were used (see [4] for details): STA, SNO, MCO, LRO, RRO. Table 1 lists the results with regard to test-suite size and creation time for regular test-case generation (Normal) and when applying the optimizations described in the previous section (Optimized). The test-suite size is given as the number of unique test-cases. In average, 62% of all test-cases created with the normal approach are redundant, but only 9% in the case of the optimized version. Table 2 shows the effects on the test-suite quality. The mutation score is measured using a set of 4038 model mutants (including equivalent mutants and also different mu-

Table 1. Results of the test-case generation. Operator Mutants Normal Optimized Size Time Size Time STA 768 343 29m48s 70 9m33s SNO 630 331 20m3s 41 5m51s MCO 274 202 10m26s 82 5m56s LRO 584 305 43m40s 80 12m15s RRO 510 178 14m16s 38 9m20s Table 2. Coverage and mutation scores. Operator Normal Optimized Transition Score Transition Score STA 100% 80.26% 100% 65.13% SNO 100% 79.47% 100% 60.92% MCO 100% 87.64% 96.34% 70.23% LRO 96.34% 87.64% 91.46% 61.29% RRO 96.34% 72.76% 79.27% 54.58% tants than those used for test-case generation). While the mutation score with regard to the mutation operator used for test-case generation is not adversely affected, the evaluation on the complete set of mutants shows the decrease of fault sensitivity. The coverage values for simple transition coverage [12] are similar. This result is in accordance with results from test-suite minimization research (e.g., [13]). 6. Conclusions In this paper, we have considered the sources of bad performance in test-case generation using model-checkers and mutation, and proposed a solution that avoids some of the identified problems. The idea is to represent model mutants as characteristic properties, which can then be used to identify equivalent mutants more quickly, and to avoid creation of redundant test-cases. In addition to the improvement of the test-case generation performance, the resulting test-suites are minimized while still achieving the highest possible model based mutation scores. This reduction in the test-suite size is often important when test-case execution is costly. Traditionally, it is done using heuristic approaches as a post-processing step. A further optimization of the test-suite size is conceivable by fully exploiting the information produced by the rewriting. Currently, rewriting is only used to detect when a property is not satisfied. If a formula is changed but not shown to be false, this suggests that the considered test-case affects the property and thus the mutant, but does not yet kill the mutant. It is likely that the test-case can be extended with a short sequence, rather than requiring a new, possibly longer test-case. The consequence would be, that the number of redundant test-cases would be further decreased. References [1] P. Ammann and P. E. Black. A Specification-Based Coverage Metric to Evaluate Test Sets. In HASE 99: The 4th IEEE International Symposium on High-Assurance Systems Engineering, pages 239 248, Washington, DC, USA, 1999. IEEE Computer Society. [2] P. Ammann, W. Ding, and D. Xu. Using a Model Checker to Test Safety Properties. In Proceedings of the 7th International Conference on Engineering of Complex Computer Systems, pages 212 221, 2001. [3] P. E. Ammann, P. E. Black, and W. Majurski. Using Model Checking to Generate Tests from Specifications. In Second IEEE International Conference on Formal Engineering Methods (ICFEM 98), pages 46 54, 1998. [4] P. E. Black, V. Okun, and Y. Yesha. Mutation operators for specifications. In ASE 00: Proceedings of the 15th IEEE International Conference on Automated Software Engineering, page 81. IEEE Computer Society, 2000. [5] A. Cimatti, E. M. Clarke, F. Giunchiglia, and M. Roveri. NUSMV: A New Symbolic Model Verifier. In CAV 99: Proceedings of the 11th International Conference on Computer Aided Verification, pages 495 499, London, UK, 1999. Springer-Verlag. [6] G. Fraser and F. Wotawa. Using LTL rewriting to improve the performance of model-checker based test-case generation. In Proceedings of the Third Workshop on Advances in Model Based Testing (A-MOST 2007), 2007. To appear. [7] M. J. Harrold, R. Gupta, and M. L. Soffa. A methodology for controlling the size of a test suite. ACM Trans. Softw. Eng. Methodol., 2(3):270 285, 1993. [8] K. Havelund and G. Rosu. Monitoring programs using rewriting. In ASE 01: Proceedings of the 16th IEEE international conference on Automated software engineering, page 135. IEEE Computer Society, 2001. [9] H. S. Hong, S. D. Cha, I. Lee, O. Sokolsky, and H. Ural. Data flow testing as model checking. In ICSE 03: Proceedings of the 25th International Conference on Software Engineering, pages 232 242. IEEE Computer Society, 2003. [10] V. Okun, P. E. Black, and Y. Yesha. Testing with Model Checker: Insuring Fault Visibility. In N. E. Mastorakis and P. Ekel, editors, Proceedings of 2002 WSEAS International Conference on System Science, Applied Mathematics & Computer Science, and Power Engineering Systems, pages 1351 1356, 2003. [11] A. Pnueli. The temporal logic of programs. In 18th Annual Symposium on Foundations of Computer Science, 31 October-2 November, Providence, Rhode Island, USA, pages 46 57. IEEE, 1977. [12] S. Rayadurgam and M. P. E. Heimdahl. Coverage Based Test-Case Generation Using Model Checkers. In Proceedings of the 8th Annual IEEE International Conference and Workshop on the Engineering of Computer Based Systems (ECBS 2001), pages 83 91. IEEE Computer Society, 2001. [13] G. Rothermel, M. J. Harrold, J. Ostrin, and C. Hong. An empirical study of the effects of minimization on the fault detection capabilities of test suites. In ICSM 98: Proceedings of the International Conference on Software Maintenance, page 34. IEEE Computer Society, 1998.