Relating Counterexamples to Test Cases in CTL Model Checking Specifications

Transcription

1 Relating Counterexamples to Test Cases in CTL Model Checking Specifications ABSTRACT Duminda Wijesekera Department of Information and Software Engineering, MS 4A4 George Mason University Fairfax, VA , U.S.A Paul Ammann Department of Information and Software Engineering, MS 4A4 George Mason University Fairfax, VA , U.S.A Counterexamples produced by model checkers are frequently exploited for the purpose of testing. Counterexamples and test cases are generally treated as essentially the same thing, while in fact they can differ significantly. For example, it might take more than one test case to cover a given counterexample, because not all property violations can be illustrated with linear counterexamples. This paper presents a formal relationship between counterexamples and test cases in the context of the Computation Tree Logic (CTL), the logic of the popular model checker SMV. Given a test requirement as a CTL formula, we define what it means for a set of test cases to cover a counterexample associated with that requirement. This result can not only be used in the generation of a test set that satisfies a given test coverage criterion, but also in the determination of whether an extant test set satisfies the criterion. Our results can guide the production of counterexamples in model checkers explicitly intended to support testing. This work has been supported in part by the National Institute of Standards and Technology, by a George Mason University Graduate Research Assistant grant, by the National Science Foundation under grants CCR and CCS , by the Austrian Federal Ministry of Economics and Labour, and the competence network Softnet Austria ( Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. A-MOST 07 July 9, 2007, London, UK Copyright 2007 ACM /00/ $5.00. Lingya Sun Department of Information and Software Engineering, MS 4A4 George Mason University Fairfax, VA , U.S.A Gordon Fraser fraser@ist.tugraz.at Institute for Software Technology Graz University of Technology Inffeldgasse 16b/2 A-8010 Graz, Austria Categories and Subject Descriptors D.2.5 [Testing and Debugging]: Testing tools; D.2.4 [Program Verification]: Model checking General Terms Theory, Measurement Keywords Formal methods, model checking, counterexamples, state machines, software testing, test coverage criteria 1. INTRODUCTION Popular model checkers, e.g., SMV and SPIN, produce explicit counterexamples for properties that do not hold in a given model. This feedback directs the analyst s attention to precisely that part of a model where the property fails to hold. Model checkers typically present counterexamples as path information that explains how to reach an offending state from some initial state. Counterexamples can be interpreted as test cases. There are several efforts in the testing community that use a model checker to generate test sets that satisfy a variety of specification based test coverage criteria [1 5, 13, 14, 19, 21, 22]. There are related approaches to decide whether an extant test set satisfies some given test coverage criterion [1,3,21]. All of these efforts assume that a counterexample and a test case are essentially the same thing. This, however, is not necessarily the case. There are many types of properties where violation cannot be demonstrated with a linear counterexample, but only with more complex structures. When creating test cases with a model checker, test requirements are expressed as properties. Consequently, such properties can also require nonlinear counterexamples. For example, even though the test requirements of the modified condition/decision coverage criterion [6] (MC/DC) can be expressed as CTL [8] properties, linear counterexamples are not sufficient to create according test cases, because

2 MC/DC requires pairs of related test cases. In the example of MC/DC there are several approaches of how to work around this problem. For example, weaker versions of the criterion are defined [21], or the model is altered so that linear counterexamples can be used [20]. Rather than taking such an approach that depends on the used criterion, we revisit the idea of how to relate test cases to counterexamples. In general, we would like to get as many test cases from a counterexample as are demanded by the underlying test criterion. The contribution of this paper is to explain the relationship between test cases and counterexamples in the context of the Computation Tree Logic [8] (CTL), the temporal logic used in the model checker SMV [15]. The results of this paper serve as a more solid foundation for efforts to generate test cases with model checkers. Furthermore, the paper suggests how the model checking community can better serve the needs of the testing community. In detail, the contributions of the paper are as follows: The notion of evidence graphs is introduced, which are finite parts of computational trees that show why a temporal formula holds. The concept of evidence graphs is analyzed with regard to soundness, (non)linearity and finiteness. We define what it means for a set of test cases to cover an evidence graph, and how to derive test cases for a given evidence graph. To illustrate the concepts, several well-known coverage criteria are defined using CTL, and the resulting evidence graphs are shown. Finally, recognition whether an extant test set satisfies a test criterion is discussed. This paper is organized as follows: First, Section 2 recalls the necessary preliminaries, then Section 3 introduces evidence graphs. Section 4 shows how evidence graphs are used for test case generation. The evaluation of extant test suites with regard to coverage criteria and evidence graphs is discussed in Section 5. Finally, the paper is concluded with a discussion in Section PRELIMINARIES This section describes the necessary preliminaries of computation tree logic (CTL) and Kripke structures, which are used to define the semantics of CTL, and are the common modeling formalism used in the context of model checking. Definition 1 (Kripke Structure). Given a set AP of atomic propositions, a Kripke structure M over AP is a quadruple M = (S, S 0, R, L), where: S is a finite set of states. S 0 S is the set of initial states. R S S is a total transition relation. That is, for every s S there is a s S such that (s, s ) R. L : S 2 AP is the labeling function that maps each state to a set of atomic propositions that hold in this state. Definition 2 (Path). A path π in a Kripke structure (S, S 0, R, L) is a sequence π 0, π 1,..., π n of states such that 0 i < n : (π i, π i+1) R. We use the notation π i for the i th state of π. The temporal logic CTL was introduced by Clarke and Emerson in [8]. It can be viewed as a subset of CTL*, introduced by Emerson and Halpern [12]. CTL* formulas consist of atomic propositions, logical operators, temporal operators (F, G, U, R, X ) and path quantifiers (A, E). CTL is the subset of CTL* obtained by requiring that each temporal operator is immediately preceded by a path quantifier. Consequently, the syntax of CTL can be defined as follows: Definition 3 (CTL Syntax). The BNF definition of CTL formulas is given below, where p AP: := p AX AF AG A 1 U 2 A 1 R 2 EX EF EG E 1 U 2 E 1 R 2 As all temporal operators are preceded by a path quantifier, the semantics of CTL can be expressed by satisfaction relations for state formulas. M, s = denotes a state formula that is satisfied in state s of Kripke structure M. The set of paths that start in state s is denoted as Paths(s). Definition 4 (CTL Semantics). Satisfaction of CTL formulas by a state s S of a Kripke Structure M = (S, S 0, R, L) is inductively defined as follows, where p AP: M, s = p iff p L(s) s S M, s = iff (M, s = ) M, s = 1 2 iff (M, s = 1 ) (M, s = 2) M, s = 1 2 iff (M, s = 1 ) (M, s = 2) M, s = AX iff π Paths(s) : M, π 1 = M, s = AF iff π Paths(s) : i : M, π i = M, s = AG iff π Paths(s) : i : M, π i = M, s = A 1 U 2 iff π Paths(s) : i : j < i : M, π j = 1 j i : M, π j = 2 M, s = A 1 R 2 iff π Paths(s) : i : j < i : M, π j = 1 M, π i = 2 M, s = EX iff π Paths(s) : M, π 1 = M, s = EF iff π Paths(s) : i : M, π i = M, s = EG iff π Paths(s) : i : M, π i = M, s = E 1 U 2 iff π Paths(s) : i : j < i : M, π j = 1 j i : M, π j = 2 M, s = E 1 R 2 iff π Paths(s) : i : j < i : M, π j = 1 M, π i = 2 We restate the definition of a negation normal form, and why every CTL formula can be expressed in negation normal form. The negation normal form will be needed for subsequent definitions. Definition 5 (Negation Normal Form). A CTL formula in which the temporal operators do not appear within the scope of a negation is said to be in negation normal form (NNF).

3 The following lemma is a well known result. Lemma 1 (NNF Exists). Every CTL formula is provably equivalent to a CTL formula in negation normal form. Proof: In the appendix, since the authors are unaware of a published proof. 3. COUNTEREXAMPLES, WITNESSES AND EVIDENCE GRAPHS The model checking problem [10, p. 35] is to find the set of states that satisfy a given formula in a given Kripke structure. That is, given a formula and a Kripke structure M = (S, S 0, R, L), the objective is to determine the set S = {s S : M, s = }. If the initial state set S 0 is included in this set, then the Kripke structure satisfies the formula. If a state that violates is found, then a model-checker usually returns a counterexample. Current model-checkers return linear traces as counterexamples. In the case of LTL [18] model-checking, such a trace is a path that violates the formula, and in the case of CTL the trace leads from the initial state to the state that violates. Strictly speaking, a state formula is violated in a state. Consequently, we define counterexamples and witnesses as follows: Definition 6 (Counterexamples and Witnesses). Let M = (S, S 0, R, L) be a Kripke structure and a CTL formula. A state s S is said to be: A counterexample for in M if M, s =. A witness for in M if M, s =. According to Definition 6, s S is a counterexample for a formula if and only if state s is a witness for. Thus, a solution to the model checking problem for the formula in M finds all witnesses for in M and a solution to the model checking problem for in M finds all counterexamples for in M. By definition, any solution to the model checking problem for / only finds the set of states in which is true or false, but without demonstrating any evidence for the claim. Current model-checkers calculate single linear counterexamples as evidence. In explicit model checking, the search path that leads to a violating state is returned as a counterexample. In symbolic model checking, special algorithms are applied to construct linear traces from the initial state to the violating state [9]. In general, only certain restricted subsets of temporal logics such as ACTL det or LIN always result in linear counterexamples [7]. When using full CTL, linear counterexamples are not always sufficient as evidence for property violation or satisfaction. We define the evidence as the collection of all paths that support the validity of a given formula. For example, consider the formula = EF p, where p AP is an atomic proposition. Suppose that holds in some states of the Kripke structure M. Then, the witness set to EF p in M is S = {s S : M, s = EF p}, according to Definition 6. The evidence of is the collection of paths π = π 0,... π n such that π 0 S and M, π n = p. These paths provide all information necessary to support the validity of the given formula (in this case EF p). Our notion of an evidence graph is defined to formally capture the states and accessibility relations among these states necessary to substantiate the evidence for a state in a Kripke structure to be a witness to a CTL formula. A Kripke structure can be interpreted as a rooted directed graph G M = (S, R). The vertices of this graph are labeled by L. Informally, an evidence graph is a subgraph of G M that contains all information necessary as evidence for a given property. For example, if the formula is of the form ψ = AG AX, then the evidence graph is the subgraph G of G M consisting of all paths of length two starting from every state in S ψ = {s S : M, s = AG AX }. Note that M, π 1 = for any path π where π 0 S ψ. For two graphs G 1 = (S 1, R 1) and G 2 = (S 2, R 2) we use G 1 G 2 as a shorthand for S 1 S 2 R 1 R 2. The set of paths that start in state s denoted as Paths(s) always refers to the paths of the Kripke structure M. Definition 7 (Evidence Graph). The evidence graph of a CTL formula given in negation normal form and Kripke structure M = (S, S 0, R, L) is a rooted directed graph G = (S, R ), where S S, R R, and vertices are labeled by L. The root node of the evidence graph is referred to as the head (notation Head(G)). The set of all evidence graphs for in M is denoted as EVD(, M). G is inductively defined on the structure of : 1. For any CTL formula without temporal operators, EVD(, M) is the collection of single state subgraphs obtained from the set of states {s S : M, s = } of M. For any such single state subgraph G EVD(, M) we define the head of G, Head(G) to be the only state in G. 2. An evidence graph G of the formula 1 2, where 1 or 2 contains logical operators, satisfies the following properties: M, Head(G) = 1 2. Head(G) = Head(t) = Head(t ) for evidence graphs t EVD( 1, M) and t EVD( 2, M). t, t G. 3. An evidence graph G of the formula 1 2, where 1 or 2 contains logical operators, satisfies the following properties: M, Head(G) = 1 2. Head(G) = Head(t) for evidence graph t EVD( 1, M) or t EVD( 2, M). t G. 4. An evidence graph G of the formula AX satisfies the M, Head(G) = AX. For all paths π = π 0, π 1 Paths(Head(G)) of length 2: π 1 = Head(t) for some evidence graph t G, and t EVD(, M). 5. An evidence graph G of the formula AF satisfies the

4 M, Head(G) = AF. All paths π = π 0,..., π n Paths(Head(G)) satisfy the π G. There is a state π i on π such that π i = Head(t i) for some evidence graph t i EVD(, M), where t G. 6. An evidence graph G of the formula AG satisfies the M, Head(G) = AG. All paths π Paths(Head(G)) satisfy the following properties: π G. Every state state π i of π is Head(t i) for some t i EVD(, M) and t i G. 7. An evidence graph G of the formula A 1 U 2 satisfies the M, Head(G) = A 1 U 2. π Paths(Head(G)) : π G. There is a state π j on π satisfying the following properties: For all i < j, π i is Head(t i) for some t i EVD( 1, M) with t i G. For all i j, π i is Head(t i) for some t i EVD( 2, M) with t i G. 8. An evidence graph G of the formula A 1 R 2 satisfies the M, Head(G) = A 1 R 2. π Paths(Head(G)) : π G. In addition, one of the following conditions must hold: There is a state π j on π such that for all i < j π i is Head(t i) for some t i EVD( 1, M) and t i G, and for all i j, π i is Head(t i) for some t i EVD( 2, M) and t G, or For all states π i, π i = Head(t i) for some evidence graph t i EVD( 2, M) with t i G. 9. An evidence graph G of the formula EX satisfies the M, Head(G) = EX. There is a path π = π 0, π 1 Paths(Head(G)), such that π 1 = Head(t) for some evidence graph t G, and t EVD(, M). In addition π G. 10. An evidence graph G of the formula EF satisfies the M, Head(G) = EF. There is a path π Paths(Head(G)) and state π i on π, such that π i is Head(t) for some evidence graph t EVD(, M), and t G. In addition π G. 11. An evidence graph G of the formula EG satisfies the M, Head(G) = EG. There is a path π Paths(Head(G)) such that π G. Every state state π i of π is Head(t i) for some t i EVD(, M) with t i G. 12. An evidence graph G of the formula E 1 U 2 satisfies the M, Head(G) = E 1 U 2. There is a path π Paths(Head(G)), π G, and a state π j on π satisfying the For all i < j, π i is Head(t i) for some t i EVD( 1, M) with t i G. For all i j, π i is Head(t i) for some t i EVD( 2, M) with t i G. 13. An evidence graph G of the formula E 1 R 2 satisfies the M, Head(G) = E 1 R 2. There is a path π Paths(Head(G)), π G, where one of the following conditions holds: There is a state π j on π such that (1) For all i < j, π i is Head(t i) for some t i EVD( 1, M) and t i G, and (2) For all i j π i is Head(t) for some t EVD( 2, M) with t G, or For all states π i, π i = Head(t i) for some evidence graph t i EVD( 2, M) with t i G. Figure 1 shows example evidence graphs for all basic CTL operators. In the graphs, filled vertices denote states of interest, for example, where 1 or 2 hold, and white vertices are arbitrary states, where the propositions of interest do not hold. The following theorem shows that every witness to a CTL formula is at the head of an evidence graph, and vice-versa. Therefore, in order to find a counterexample to a CTL formula, we need to convert to its negation normal form and find an evidence graph for the negation normal form of. Theorem 1. A CTL formula is satisfiable in a state s S of the Kripke structure M = (S, S 0, R, L) if and only if there is an evidence graph t EVD(, M) such that s = Head(t).

5 2, , 1 2, 1 AX AF AG A 1 U 2 A 1 R 2 2 2, EX EF EG E 1 U 2 E 1 R 2 Figure 1: Evidence graphs for CTL connectives. Proof: See the Appendix. According to Theorem 1, if there is a counterexample to a CTL formula, then the evidence graph of (i.e., any graph G EVD(, M)) provides the evidence supporting the failure of. Test cases are usually finite and linear, while there is no guarantee that evidence graphs are either linear or finite. In order to relate evidence graphs and counterexamples we now address these two issues. 3.1 Non-linearity of Evidence Graphs Although evidence graphs can be linear, it is not always possible to obtain linear evidence graphs. For example, consider the formula (EX ) (EX ). Any state s in a Kripke structure M that satisfies (EX ) (EX ) must have two states s 1 and s 2 such that the following conditions hold: (s, s 1) R and (s, s 2) R. M, s 1 = and M, s 2 =, so that M, s = (EX ) (EX ). s 1 and s 2 cannot be the same state as M, s 1 = and M, s 2 =. Figure 2 shows the evidence graph of (EX ) (EX ). Similarly, AF may result in branching as shown in Figure 3. Because any evidence graph of a simple formula such as (EX ) (EX ) is non-linear, there is no hope of describing counterexamples solely as linear paths. Instead we seek to relate counterexamples with paths that provide coverage. Figure 2: Evidence graph for (EX ) (EX ). The following theorem states sufficient, but not necessary conditions for an evidence graph to be linear. Theorem 2 (Linear Evidence Graphs). If a negation normal form of a CTL formula has no,a or G then it has a linear evidence graph. Figure 3: A non-linear evidence graph for AF. Proof: See the Appendix. 3.2 Finiteness of Paths in Evidence Graphs The second issue that we address is of the finiteness of paths that we submit as evidence of witnesses. We use the following Lemma 2 (which is an adaptation of a Lemma from Clarke et al. [10]) to address this issue. Lemma 2. Suppose π is a path in a Kripke structure M and a CTL formula satisfying the condition that M, π i = for any state π i on π. Then, there are finite paths α and β such that π is α : β ω. Proof: See the Appendix. Note that β can be an empty sequence. When presenting an evidence graph for a formula, we can eliminate potentially infinite paths by curtailing them after the first cycle. Therefore, using the above Lemma, we can obtain the following theorem. Theorem 3 (Every infinite path ends in a loop). Every evidence graph G EVD(, M) of a CTL formula contains an evidence graph G for the same formula such that: (1) Head(G) = Head(G ), and (2) every path in Head(G ) is the concatenation of two parts, a finite branch, and a finite cycle - in that order. Proof: See the Appendix. Therefore, every evidence graph can be curtailed to one that has only finitely long paths or infinite paths that are the

6 concatenation of a finite part and a finite cycle. This kind of infinite paths is for example considered by Tan et al [16], who also discuss the curtailing. Hence, given a CTL formula any counterexample to that formula in any given Kripke structure can and must be given by an evidence graph that has paths that end up in cycles. With these basic facts in place, we move to relating test cases to counterexamples. 4. RELATING TEST COVERAGE TO COV- ERING EVIDENCE GRAPHS This section considers the issue of test coverage. A test coverage criterion is a rule that, when applied to a suitable artifact, generates a set of test requirements. A test requirement states a property demanded of one or more test cases. In this work, we assume that test requirements are expressed in CTL. This is a common method to create test cases with a model checker (e.g., [14,21]). It is common to formulate CTL properties in a negated way, such that checking a model against a test requirement results in a counterexample that can be used to cover the requirement. For example, test requirements might require that all states or transitions of a model are covered. This would result in a CTL property for each state or transition, respectively, stating that the state or transition is not reached. This idea of test case generation basically also applies to evidence graphs. Every counterexample to a CTL formula can be witnessed by the evidence graph of the negation normal form of its negation. Any set of paths covering an evidence graph of satisfies the test requirement. Definition 8 (Coverage of Evidence Graphs:). A set of paths Π is said to cover the evidence graph G of the CTL formula, if the following conditions are satisfied: 1. π 0 = Head(G ) for all paths π Π. 2. G Π. Here, Π denotes the graph obtained by combining the paths in Π. Consequently, the following steps are taken in order to generate a test suite (i.e., set of test cases) satisfying a given coverage criterion: 1. A set of test requirements is generated in CTL. 2. For each test requirement, the negation normal form of the negation is model checked, resulting in an evidence graph. 3. For each test requirement, a set of test cases that covers an according evidence graph is created. 4. The test-cases possibly need a prefix that leads from the initial state to the head of the evidence graph. Such a prefix can be calculated using traditional counterexample generation techniques. 4.1 MC/DC Coverage We now illustrate this approach using the well known test coverage criterion modified condition/decision coverage [6] (MC/DC), which is popular in safety relevant environments. A test suite satisfies MC/DC if it guarantees that: Every entry and exit point of a program has been invoked at least once. Every condition in a decision in the program has taken on all possible outcomes at least once. Each condition has been shown to independently affect the decision. The final requirement is problematic for model checker based testing. In order to show that each condition independently affects the decision, the values of all other conditions are fixed, and the considered condition is varied. Consequently, each condition requires a pair of test cases, but traditionally there is no way to create pairs of counterexamples with a model checker. Rayadurgam and Heimdahl [21] define a weaker variant of MC/DC (clause-wise guard coverage). A different approach is taken in [20], where the model is altered so that one linear counterexample can be split into two test cases. It is possible to create pairs of test cases for MC/DC using evidence graphs. Suppose that a decision C depends on propositions {a 1,..., a n}. MC/DC seeks only those variations of parameters {a 1,..., a n} that alter the truth value of C. Let A i = {b 1,..., b n} be a valuation of the propositions in C such that C is true if a i = b i for all a i in C. Assume a further valuation Āi, such that C is false, where for all j i the j-th value in A i equals the j-th value in Āi, and bi in A i is replaced with b i in Āi. To show that a proposition a i independently affects a decision C it is necessary to create a pair of test-cases, such that in one test-case C evaluates to true using A i and in the other to false using Āi; that is, all values in Ai except bi are identical in both test-cases. Assuming a valid A i, such that there is an according Ā i, the first case is achieved with 1 = EF (C( V j i aj = b j) a i = b i), and the second case is achieved with 2 = EF ( C ( V j i aj = bj) (ai = bi)). Here, the values b i are those contained in A i. Consequently, a pair of testcases that shows that a proposition independently affect the decision C is represented by the evidence graph of 1 2: EF (C (^ a j = b j) a i = b i) j i EF ( C (^ a j = b j) a i b i) j i Not all possible variations of A i can lead to MC/DC pairs. A naive solution to finding a suitable A i is to simply create all 2 n possible variations of the n elements in A i, and then create a disjunction of ( 1 2) for each version A i. A more sophisticated approach is to use Boolean constraint satisfaction to determine those A i where a i really determines the value of C, and then combining only these A i in a disjunction. In order to illustrate this, consider an example where the decision C is given as C := x (y z). When considering the proposition x in this example, there are three different valid variations of A i such that MC/DC pairs of test cases for x in C are generated. MC/DC for x can be stated as

7 x y z x y z x y z x y z x y z x y z Figure 4: Three different possible evidence graphs for MC/DC with regard to x in C = x (y z). follows: EF (C x y z) EF ( C x y z) EF (C x y z) EF ( C x y z) EF (C x y z) EF ( C x y z) Figure 4 illustrates evidence graphs resulting from this example. Any of these evidence graphs provides a pair of test cases that cover x in C according to MC/DC. In order to create a complete test suite, similar test requirements have to be formulated for all propositions in all decisions. 4.2 Using Evidence Graphs to Test Dangerous Traces As a further example of test requirements that benefit from evidence graphs, we discuss a coverage criterion introduced by Ammann et al. [3], which encompasses the idea of scenarios where a dangerous action is either inevitable or possible as of the next state or at some point in the future. Test requirements are defined in order to create dangerous traces with regard to safety properties. A trace is dangerous to a safety property, if it can lead to a property violation on a mutant model. The approach taken by Ammann et al. is to combine a model M and a mutant M, such that transitions from both versions of the model can be taken. A special variable original (which we will abbreviate as orig) indicates whether the taken transition originates from M or M. Different types of dangerous traces are distinguished: A trace is AX dangerous, if the additional transitions allowed by the mutant M violate a property P in all next states. A trace is EX dangerous, if there exists an additional transition allowed by the mutant M which violates a property P in the next state. A trace is AF dangerous, if it can be extended with the next state from M and other transitions from the combined model so that in all futures there is a violation of P. A trace is EF dangerous, if it can be extended with the next state from M and other transitions from the combined model so that in some futures there is a violation of P. For each dangerous trace there are two versions: a failing and a passing test. In a failing test, the dangerous trace is extended with transitions from M, so that P is violated. In a passing test, the dangerous trace is extended with a single transition from M. For example, test requirements for AX dangerous traces for property P are defined in [3] as follows. A test requirement for a failing test is: EF (orig EX ( orig) AX ( orig P)) The following test requirement results in a passing test: EF (orig EX (orig) EX ( orig) AX ( orig P)) The test requirement for the passing test relies on the implementation of the model checker to pick the correct trace such that transitions from M are chosen. However, also transitions from M would result in valid counterexamples to the property, while not representing a valid passing test case. Dangerous traces can benefit from the use of evidence graphs. The following property is sufficient to create an evidence graph that consists of both, a passing test and a failing test: (orig AX ( orig P)) AX (orig P)) A resulting evidence graph is depicted in Figure 5. orig orig P orig P Figure 5: An AX dangerous evidence graph for property P. Similar properties can be defined for the other types of dangerous traces: AF dangerous traces: (orig EX (orig) AX ( orig AF ( P))) EX dangerous traces: (orig EX (orig) EX ( orig P)) EF dangerous traces (see Figure 6): (orig EX (orig) EX ( orig EF ( P))) orig orig orig P Figure 6: An EF dangerous evidence graph for property P.

8 5. EVALUATION OF EXTANT TEST SETS In prior work [2], model checkers were suggested for the analysis of extant test suites in addition to generation of test cases. Existing test cases were analyzed by turning each test case into a separate, constrained state machine that followed the transitions in the test case one for one and allowed no other behavior. Model checking each of these machines against the entire set of test requirements and taking the union of the satisfied requirements cumulatively yields the test coverage for the original test set. This is an important task from a practical perspective, since test sets can arise from many different activities and typically represent a significant investment of resources. For example, a developer may want to analyze use cases built during the requirements phase for test coverage with respect to some criterion. Representing each test case as a model and checking it against test requirements does not work if multiple test cases are needed for a single test requirement; only one test case can be analyzed at a time. The solution is to build a single machine that includes all of the test cases. That is, we prune the original state machine so that only those states visited and those transitions followed by some test case in the extant test set are allowed. Model checking this pruned state machine identifies those test requirements that are not satisfiable on the pruned machine, but are satisfiable on the original machine. It is exactly these test requirements that, although feasible, are not covered by the extant test set. In this way, model checking can answer the coverage question. This can be formally characterized as the following adequacy requirement. Definition 9 (Structure Induced by Test Cases). Given a Kripke structure M = (S, S 0, R, L) and a set of test cases Π, we say that M Π = (S Π, S 0,Π, R Π, L Π) is the Kripke structure induced by the set of test cases Π, such that: S Π S, such that s S Π : π Π : π =..., s,... R Π R and R Π S Π S Π L Π L and L Π : S Π 2 AP For example, assume a set of test requirements F, given as CTL formulas. We say that a test set Π consisting of paths of a Kripke model M provides adequate coverage for the test requirements F, if for each CTL formula F, there is a state s S Π such that M Π, s =. Consequently, the following result holds: Theorem 4 (Adequacy). A test set Π consisting of paths of a Kripke model M provides adequate coverage for test requirements F for each CTL formula F if and only for each F there is an evidence graph G EVD(, M) such that ( S G F ) (SΠ, RΠ). Notice that according to Theorem 1 a formula is valid if and only if it has an evidence graph. Hence model checking in the reduced structure M Π is equivalent to searching for an evidence graph. 6. CONCLUSIONS In this paper, we have discussed why a one to one relationship between test cases and counterexamples is not satisfactory with respect to some test criteria. The issue is that the temporal formulas needed to directly express the test requirements associated with some criteria result in counterexamples that require multiple traces for adequate coverage. We provided the notion of an evidence graph for a temporal formula, as well as mappings from traces, i.e., test cases, to evidence graphs. It turns out that the operators, A and G are responsible for cases where multiple traces are needed. We show that finitely many finite traces can cover any evidence graph. We also describe how to embed test cases in a finite state model so that extant test sets can be evaluated for satisfaction of a given test criterion. These results not only serve the testing community with a more solid foundation for generating test sets with model checkers, but they also suggest to the model checking community how counterexample generators could be made more useful. In the context of counterexample creation, the issue that not all property violations can be illustrated with linear traces has recently received increased attention. For example, Clarke et al. [11] describe an algorithm to derive tree-like counterexamples for ACTL formulas (CTL formulas that only contain the A path quantifier). For this subset, a tree-like counterexample can be interpreted as an evidence graph together with a path leading from an initial state to the head of the graph. Meolic et al. [17] take a different approach and derive counterexample or witness automata for a fragment of action computation tree logic. 7. REFERENCES [1] A. Abdurazik, P. Ammann, W. Ding, and J. Offutt. Evaluation of three specification-based coverage testing criteria. In Proceedings ICECCS 2000: 6th IEEE International Conference on Engineering of Complex Computer Systems, pages , Tokyo, Japan, September [2] P. Ammann and P. E. Black. A Specification-Based Coverage Metric to Evaluate Test Sets. In Proceedings of the 4th IEEE International Symposium on High-Assurance Systems Engineering (HASE 99), pages , Washington, DC, USA, IEEE Computer Society. [3] 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 (ICECCS 2001), pages , Skovde, Sweden, IEEE. [4] P. E. Ammann, P. E. Black, and W. Majurski. Using Model Checking to Generate Tests from Specifications. In Proceedings of the Second IEEE International Conference on Formal Engineering Methods (ICFEM 98), pages IEEE Computer Society, [5] J. Callahan, F. Schneider, and S. Easterbrook. Automated Software Testing Using Model-Checking. In Proceedings 1996 SPIN Workshop, August Also WVU Technical Report NASA-IVV [6] J. J. Chilenski and S. P. Miller. Applicability of modified condition/decision coverage to software testing. Software Engineering Journal, pages , September [7] E. Clarke and H. Veith. Counterexamples revisited: Principles, algorithms, applications. In Verification: Theory and Practice, volume 2772 of Lecture Notes in Computer Science, pages , 2004.

9 [8] E. M. Clarke and E. A. Emerson. Design and synthesis of synchronization skeletons using branching-time temporal logic. In Logic of Programs, Workshop, pages 52 71, London, UK, Springer-Verlag. [9] E. M. Clarke, O. Grumberg, K. L. McMillan, and X. Zhao. Efficient generation of counterexamples and witnesses in symbolic model checking. In Proceedings of the 32st Conference on Design Automation (DAC), pages ACM Press, [10] E. M. Clarke, O. Grumberg, and D. A. Peled. Model Checking. MIT Press, Cambridge, MA., 1 edition, rd printing. [11] E. M. Clarke, S. Jha, Y. Lu, and H. Veith. Tree-like counterexamples in model checking. In LICS 02: Proceedings of the 17th Annual IEEE Symposium on Logic in Computer Science, pages 19 29, Washington, DC, USA, IEEE Computer Society. [12] E. A. Emerson and J. Y. Halpern. Decision procedures and expressiveness in the temporal logic of branching time. In STOC 82: Proceedings of the fourteenth annual ACM symposium on Theory of computing, pages , New York, USA, ACM Press. [13] A. Engels, L. Feijs, and S. Mauw. Test generation for intelligent networks using model checking. In E. Brinksma, editor, Proceedings of the Third International Workshop on Tools and Algorithms for the Construction and Analysis of Systems. (TACAS 97), volume 1217 of Lecture Notes in Computer Science, Enschede, the Netherlands, April Springer-Verlag. [14] A. Gargantini and C. Heitmeyer. Using Model Checking to Generate Tests From Requirements Specifications. In ESEC/FSE 99: 7th European Software Engineering Conference, Held Jointly with the 7th ACM SIGSOFT Symposium on the Foundations of Software Engineering, volume 1687, pages Springer, September [15] K.L. McMillan. The SMV system. Technical Report CMU-CS , Carnegie-Mellon University, [16] I. L. Li Tan, Oleg Sokolsky. Specification-based testing with linear temporal logic. In Proceedings of IEEE International Conference on Information Reuse and Integration (IRI 04), pages , [17] R. Meolic, A. Fantechi, and S. Gnesi. Witness and counterexample automata for actl. In Formal Techniques for Networked and Distributed Systems - FORTE 2004, volume 3235 of Lecture Notes in Computer Science, pages , [18] 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 IEEE, [19] C. Ramakrishnan and R. Sekar. Model-based vulnerability analysis of computer systems. In Proceedings of the 2nd International Workshop on Verification, Model Checking and Abstract Interpretation, September [20] S. Rayadurgam and M. P. Heimdahl. Generating MC/DC Adequate Test Sequences Through Model Checking. In Proceedings of the 28th Annual NASA Goddard Software Engineering Workshop, pages 91 96, [21] 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, Washington, DC, April IEEE Computer Society. [22] R. W. Ritchey and P. Ammann. Using model checking to analyze network vulnerabilities. In Proceedings of the 2000 IEEE Symposium on Security and Privacy (Oakland 2000), pages , May APPENDIX A. APPENDIX: PROOFS OF THEOREMS Proof of Lemma 1 The following identities can be used to push the negation ( ) inside the scope of temporal operators of any given CTL formula: EX AX EF AG EG F AF EU 2 A( R 2) ER 2 A( U 2) AX EX AF EG AG F EF AU 2 E( 2U ( 2)) EG 2 AR 2 E( U 2) The truth of the above equivalences is shown in Clarke et al. [10]. These taken together with the distributivity of negation ( ) over conjunction ( ) and disjunction ( ) can be used to recursively show that every CTL formula is equivalent to one in negation normal form. Proof of Theorem 1 This proof is an inductive argument based on the syntax of the negation normal form of the formula. Due to the repetitive nature of the proof, we only provide one case. Suppose the given formula is EF, and there is a state s S of the Kripke Structure M = (S, S 0, R, L) where M, s, = EF. Then there is a path π S satisfying the following properties. 1. s is π There is some state π i on π such that M, π i =. Therefore by the inductive assumption, there is an evidence graph G EVD(, M) where π i is Head(G ). Hence, the following graph G now is an evidence graph for EF. 1. The states of G are the states of G and the states on π. 2. The accessibility relation of is the restriction of R to the states of G. 3. The head of G (i.e. Head(G)) is s.

10 Conversely, suppose that there is an evidence graph G EF EVD(EF, M) such that s is Head(G EF ). Then, by definition, M, s, = EF. Proof Sketch of Theorem 2 This proof is a consequence of Definition 7. Notice that in the recursive procedure for constructing an evidence graph, a branching is possible only when there is room for Head(G) to be connected to more than one other state. These are for the connectives, AF, AG and EG. Proof Sketch of Lemma 2 The proof of this lemma is contained in the proof of Lemma 1, page 36 of Clarke et al. [10]. It is based on the fact that there are finitely many strongly connected components (in the sense of graphs) of states, and the last such component the path goes into, does not come out of it and hence constitute β. The finite path α is the path from state π i to the beginning state on β. Proof Sketch of Theorem 3 The essence of this proof uses Lemma 2, where any search for an infinite path π on which a formula must be true can be curtailed to α; β where both α and β are finite, β = β 0,... β n satisfies β 0 = β n (i.e. β is a cycle). This curtailing of repetitive cycles can be done in case of the recursive steps for EG, EU, ER, AG, AU and AR in the construction of evidence graph.