A Systematic Approach to Generate Test Cases ... - Semantic Scholar

A Systematic Approach to Generate Test Cases based on Faults Marisa A. S´anchez1 and Miguel A. Felder2 1

Dpto. de Cs. e Ing. de la Computaci´ on Universidad Nacional del Sur, Bah´ıa Blanca [email protected] 2 Pragma Consultores, Buenos Aires [email protected]

Abstract. For the case of the software we use today, the information outside the specification is increasing. For quality assurance purposes, it would be desirable to integrate the analysis of software and hardware components with testing. In this paper, we propose a fault-based approach for generating test cases, thus overcoming the limitations of specification-based approaches that derive from the intrinsic incompleteness of the specification, and from the focus of specifications on correct behaviors, rather than potential faults. We use Fault Tree Analysis to determine how certain undesirable states can occur in a system. The results of the analysis expressed in terms of Duration Calculus are integrated with statechart based specifications. As a result, we obtain a testing model that provides a representation of the way the system behavior can be compromised by failures or abnormal conditions or interactions. In this way we can automatically derive fault-based test cases from this model.

Keywords: Testing, Fault-based Testing, Statechart, Fault Tree Analysis, Duration Calculus

1

Introduction

Software based systems incrementally provide critical services to users. Mobile telephone systems, for example, are used in circumstances in which the malfunctioning may have disastrous consequences. During the last years, software has been incorporated in devices used in daily life, such as audio and television. The diversity of systems in which software is incorporated is increasing. Thus, the software development process has to consider a variety of specification techniques and models, incorporating also techniques from engineering sciences. In particular, the validation and verification processes have to be adapted to these new developments. For example, specification based testing has limitations that derive from the intrinsic incompletness of the specification. Also, there is an implicit objective to verify that the program works correctly. Myers [1] says that

with the aim of demonstrating that a program does not fail, we can unconsciously select data that has a low probability of exposing faults. On the other hand, if the objective is to demonstrate that a program has faults, test data will have a higher probability of revealing them. In specification-based testing we select data for which the desired behavior for the system is defined. As stated by Boris Beizer [2] testing should include both clean and dirty tests. Dirty tests are designed to “break” the software; clean tests are designed to demonstrate that software executes correctly. Specifications only provide clean tests. Furthermore, results of Reliability theory show that partition testing is better than random testing, and this superiority is visible when the definition of partitions considers potential difficulties in design and implementation. This means that specification-based testing is inferior with respect to testing in which the refinement of partitions is more related with fault rates [3—5]. In particular, fault-based testing is more effective to find errors. Testing is fault-based when its motivation is to demonstrate the absence of prespecified faults. Although there are many proposals of fault-based testing [6—11], all are concerned with syntactic errors (e.g., errors in the use of relational or arithmetic operators, incorrect variable references). These types of errors represent only a small portion of possible errors. In real applications, faults depend on a multiplicity of causal factors including technical, human and institutional aspects. This fact motivates our interest to perform a fault-based testing that is not restricted to syntactic errors. Thus our approach extends the scope of traditional fault-based approaches to semantic errors. The main problems that we encounter are the following: 1. For the case of specification-based testing, the number of possible behaviors is bounded by what is described in the specification. If we also consider the information outside the specification, the number of possible behaviors is incremented. Also, given the diversity of information that we have to consider to understand a system, it is not obvious how to define behaviors relevant to testing. 2. We have to deal with specifications provided in different languages, with different levels of granularity and abstraction, and that they consider different views of the system. To address the first point, we propose to characterize possible behaviors and give a priority according to some criteria. We use Fault Tree Analysis to determine how an undesirable state (failure state) can occur in the system [12]. The second point arises because we have to integrate Fault Tree Analysis results with the system specification. We assume we have a specification of the desired behavior for the system using statecharts [13]. In our work, we propose to integrate the results of the analysis expressed in terms of Duration Calculus formulas with statechart based specificacions. We defined some conversion rules of a formula to a statechart. These rules are applied to the syntactic categories of Duration Calculus formulas. As a result, we obtain a testing model that provides a representation of the way the system behavior can be compromised by failures or abnormal conditions or interactions.

The remainder of the paper is organized as follows. Sections 2 and 3 briefly introduces fault tree analysis and statecharts, respectively. Section 4 is devoted to describe our testing approach. We first describe our conversion rules of Duration Calculus formulas representing fault tree analysis results to statecharts (Section 4.1). We then provide an example (Section 4.2). Section 4.3 describes how to reduce the testing model, and Section 4.4 discusses how to generate test sequences from the testing model. Conclusions are presented in Section 5.

2

Fault Tree Analysis

Fault Tree Analysis is a widely used technique in industrial developments, and allows to describe how individual component failures or subsystems can combine to effect the system behavior. The construction of a fault tree [12] provides a systematic method for analyzing and documenting the potential causes of a system failure. The analyst begins with the failure scenario of interest and decomposes the failure symptom into its possible causes. Each possible cause is then further refined until the basic causes of the failure are understood. A fault tree consists of the undesired top state linked to more basic events by logic gates. Here we only consider and, or gates, as fault trees containing other gates may be expressed in terms of these. Once the tree is constructed, it can be written as a Boolean expression and simplified to show the specific combinations of identified basic events sufficient to cause the undesired top state. The sets of basic events that will cause the root event are regarded as Minimal Cut Sets. The Minimal Cut Set representation of a tree corresponds to an or gate with all the minimal cut sets as descendants. Gas Burner example As an illustration of the use of Fault Tree Analysis, consider the Gas Burner problem given in [14]. The system consists of an on/off valve to feed air, an on/off valve to feed fuel, a flame igniter, a flame detector; an on/off switch to start/stop the operation of the burner. The system has to (i) start it up, maintain it with an ignited flame and to shut it down when requested; and (ii) to deal with abnormal and emergency conditions that may arise during operation. The proposed fault tree for the hazard explosive concentration of fuel present in cell is in Figure 1, there are 20 cut sets which include, for example, {GPL,CAV}, {GPL,FSAV}, {GPL,AVC}, and {CGV,ASF}. 2.1

Fault tree semantics

In [15] fault trees have been given a formal semantics based on a real-time interval logic, the Duration Calculus. The original Duration Calculus was introduced by Zhou Chaochen et al. in [16]. Duration Calculus has been successfully used for requirements specification and design [18, 19]. In Duration Calculus a system is modeled by a number of functions from the time domain R+ to the Boolean domain {0, 1}. These functions are called the state variables of the system. For

Fig. 1. Fault Tree for explosive concentration of fuel present in cell

a state variable (or a Boolean combination of state variables) P , its duration in $ a time interval, written P in Duration Calculus, is the integral of P over the time interval. The semantics of a fault tree is determined by the semantics of the leaves, the edges, and the gates, such that the semantics of intermediate nodes are given by the semantics of the leaves, edges, and gates in the subtrees in which the intermediate nodes are roots. A leaf node is interpreted as a formula that may be the occurrence of a state P , i.e. P ; the occurrence$of a transition to state P , i.e. ¬P ; P ; a threshold of some duration, i.e. P ≤ 8. For example, in Figure 1, the basic event ALB (Air line blocked) is denoted by the formula ¬Blocked ; Blocked . The semantics of intermediate nodes depends on the structure of the subtree. For example, the semantics of an intermediate node connected to nodes B1 , ..., Bn through an and gate is given by the conjunction of the semantics of B1 , ..., Bn .

3

Statecharts

As a specification model we use Statecharts [13]. This formalism is widely used within the software engineering community, and has been adopted by the Unified Modeling Notation (UML) [20]. Statecharts is a hierarchical state machine representation that is typically used to describe reactive systems. Hierarchical state machines extend traditional automata by allowing sub-automata as nodes. Orthogonal products are automata composed from a set of children automata that are interpreted in parallel. Thus, the state space of the orthogonal product is the cross product of each of the children automata. There are three basic types of states in a statechart: or, and and basic states. or states have substates that are related to each other by “exclusive-or”, and and states have orthogonal components that are related by “and”. Basic states are those at the bottom of the state hierarchy. The syntax of an expression labeling a transition in a statechart is e[c]/a, where e is the event that triggers the transition; c is a condition that guards the transition from being taken unless it is true when e occurs; and a is an action that is carried out if and when the transition is taken. All of these are optional. The behavior of a system described in statemate is a set of possible runs, each representing the responses of the system to a sequence of external stimuli generated by its environment [13]. The interested reader is referred to [13, 21] for a detailed description of the semantics. Figure 2 shows statecharts for the Gas Burner example introduced in Section 2. There are statecharts for the Controller, the Flame Detector, the Ignitor, the Air Valve and the Gas Valve components.

4

Construction of the testing model

This section is devoted to describe the overall testing framework. Given a Fault Tree, we should calculate the set of basic events (cut sets) that can conduct to the failure state. For each cut set we construct a testing model (using statecharts and the rules explained in Sections 4.1 and 4.2). Using this statechart based model, we automatically derive test cases (4.4). 4.1

Duration Calculus formulas that represent a cut set

Conversion to Statecharts A fault tree describes the events that contribute to an undesirable system behavior, and also what components participate and which responsibilities do they have. For example, in the tree depicted in Figure 1, the subtree rooted with node “Failure of controller to open valve” refers to the software component Controller. The subtree rooted “Air line blocked” refers to the hardware component Air Line. The other portions of this tree refer to the Air Valve, Air Supply, Gas Valve, and Gas Pipe. The desired behavior for some of these components is specified by the software designer using statecharts (see Figure 2).

Fig. 2. Specification Statecharts for the Gas Burner

In Section 2, we described how fault trees are interpreted as temporal formulas. Thus, we can interpret each cut set as a Duration Calculus formula. Remember that a cut set is defined as the set of basic events that contribute to a system failure if they occur simultaneously. The basic events are represented by the tree leaves. For example, for the cut set {CAV, GP L} (“Controller sets valve to be closed” and “Gas piping leak”) we provide the following Duration Calculus formula: def

c1 = AirOn ; FailureAirOn ∧ NotLeaking ; Leaking The event CAV associated with the Controller denotes (a) the occurrence of action AirOn that controls the opening of the Air Valve, and (b) the software failure FailureAirOn for this action. The event GPL associated with component Gas Pipe denotes the occurrence of a transition to state Leaking. In general, given a cut set that contains n basic events: CSi = {e1 , e2 , ..., en } the formula that describes it has the form:

def

csi = f1 ∧ f2 ∧ ... ∧ fn where each fi represents the basic event ei , for 1 ≤ i ≤ n, and it refers to a single component. That is, we should include each fi in the statechart of the appropriate component. In general, the contents of fault tree leaves depend much on the application. The main features of the formulas that describe cut sets are: — The components of a formula fi refer to a single system component. — A formula denotes: • External events (that may or may not be present in the statechart) using state variables, e.g. heatReq . • Internal events (actions present in the statechart) using state variables, e.g. AirOn . • States using state variables (that may or may not be present in the statechart), e.g. Burning . • State transitions using the chop operator. For example, a transition from state A to B is described by A ; B . • Event sequences, e.g. heatReq ; F lameOn . • State transitions describing a trigger event, e.g. Idle ; heatReq ; Igniting . • Conditions using predicates. Predicates should not relate state variables that denote states or events in the statechart. 4.2

Conversion rules

In the following, we present the conversion rules of a formula to a statechart. The rules are applied to the syntactic categories of Duration Calculus formulas. Creation rule: If a statechart for the component of interest does not exist, create a root state including the entities (states and transitions) that result after the analysis of the current formula. Replacement rule 1: Given a formula δ that denotes a conjunction of events and/or states δ1 ∧ δ2 ∧ ... ∧ δn , replace formula δ1 ∧ δ2 ∧ ... ∧ δn with δ1 ∧ δ2 ∧ ... ∧ δn , and analyze this formula. Replacement rule 2: Given a formula δ1 ; (δ2 ∧ δ3 ) where δ1 , δ2 and δ3 are formulas, apply the following formula scheme: |= δ1 ; (δ2 ∧ δ3 ) ⇒ δ1 ; δ2 ∧ δ1 ; δ3 . Replacement rule 3: Given a formula (δ1 ∧ δ2 ); δ3 where δ1 , δ2 and δ3 are formulas, apply the following formula scheme: |= (δ1 ∧ δ2 ); δ3 ⇒ δ1 ; δ3 ∧ δ2 ; δ3 . Replacement rule 4: Given a formula ♦δ where δ is a formula, replace it with ( > 0 ∨ = 0); δ; ( > 0 ∨ = 0). Conjunction rule: Given a formula δ1 ∧ δ2 ∧ ... ∧ δn analyze each δi separately. Rule I1: Given δ1 (interval composed of a single subinterval): (a) If δ1 denotes a state present in the statechart, do nothing.

(b) If δ1 denotes a state that does not exist in the statechart, add a new state labeled S. Human intervention is necessary to determine if the new state is orthogonal or not with respect to the states in the statechart. If the new state is not orthogonal, we add transitions from the existing states to this new state. The definition of these transitions depend absolutely on the problem. If the new state represents an initial state, designate it as such. (c) If δ1 denotes an event present in the statechart, add δ1 to the List of External Events3 . (d) If δ1 denotes an event that does not exist in the statechart, add δ1 to the List of External Events. Also, add a new state orthogonal to the existing ones. The new state is composed of two substates which are the source and target states of a new transition whose trigger event is δ1 . (e) If δ1 denotes an action present in the statechart, do nothing. (f) If δ1 denotes an action that does not exist in the statechart, there is an error since this action represents a functionality not considered in the specification statechart. Rule I2: Given δ1 ; δ2 (interval composed of two subintervals): (a) If δ1 , δ2 denote states (not orthogonal), there is a state transition: (i) and none of the states are present in the statechart, create a new state S, include two substates δ1 and δ2 , and add a transition from δ1 to δ2 . Label this transition with the appropriate trigger event or a condition true to mean that the transition is always taken. If δ1 also represents an initial state, then designate it as such. Human intervention is necessary to determine if the new state S is orthogonal or not with respect to the states present in the statechart. (ii) and at least one of the states is present in the statechart, then, add the absent state, and a transition from the substate represented in the first subinterval, to the substate represented by the second subinterval. This transition is labeled with the appropriate trigger event or a condition true to mean that the transition is always taken. (b) If δ1 , δ2 denote orthogonal states, there is a state transition: (i) and none of these states are present in the statechart, create a new state S, include two orthogonal substates S1 and S2 . In S1 include two substates δ1 and δ1I , add a transition from δ1 to δ1I . Label this transition with action exitδ1 = true. In S2 include two substates δ2I and δ2 , add a transition from δ2I to δ2 . Label this transition with condition exitδ1 = true. Therefore, we synchronize the end of the duration of state δ1 with the start of δ2 . Human intervention is necessary to determine if the new state S is orthogonal or not with respect to the states present in the statechart (see Figure 3). (ii) and δ1 does not exist in the statechart, then, include an orthogonal state S1 with two substates δ1 and δ1I , add a transition from δ1 to δ1I . 3

The external stimuli generated by the environment are recorded in a List of External Events (see Section 3)

Label this transition with action exitδ1 = true. For all transitions whose target state is δ2 , add condition exitδ1 = true. Therefore, we synchronize the end of the duration of state δ1 with the begin of state δ2 . (iii) and δ2 is not present in the statechart, then, for all transitions whose source state is δ1 , add action exitδ1 = true in the label. Add an orthogonal state S2 with two substates δ2I and δ2 , and add a transition from δ2I two δ2 labeled with condition exitδ1 = true.

Fig. 3. Conversion of {δ1 Q; {δ2 Q (Rule I2 (b)(i))

(c) If δ1 denotes a state, and δ2 denotes an event or an action, we need a state labeled with δ1 and a transition labeled δ2 and source state δ1 : (i) if both are present in the statechart, do nothing (if the specification does not match exactly with the previous description, e.g. the specification includes another intermediate state, it may be the case that it has another description level). (ii) if they do not exist in the statechart, add a state labeled δ1 according to Rule I1 (b); add a transition with label δ2 whose source state is δ1 ; and add a target state (see Figure 4).

Fig. 4. Conversion of {StateQ; {EventQ (Rule I2 (c)(ii))

(d) If δ1 denotes an event or an action, and δ2 denotes a state, we need a transition labeled δ1 and whose target state is δ2 : (i) if both exist in the statechart, do nothing (if the specification does not match exactly with the previous description, e.g. the specification includes another intermediate state, it may be the case that it has another description level).

(ii) if they do not exist in the statechart, add a new state S according to Rule I1 (b), include a substate δ2 , add a transition labeled δ1 , and whose target state is δ2 , and add a source state for the transition. (e) If δ1 , δ2 denote events, there is an event sequence. To preserve the sequence order during conversion, add δ1 as a precondition for δ2 and apply Rules I1 (c) and (d). (f) If δ1 denotes a subinterval duration, e.g. it is of the form op n, where op ∈ {, =} and n is a real number, add δ1 as a pre-condition of δ2 and apply Rule I1. This means that the ocurrence of the event or state denoted by δ2 should satisfy the relation indicated by δ1 . Rule I3: Given δ1 ; δ2 ; δ3 (interval composed of three subintervals): (a) If δ1 , δ3 denote states, and δ2 denote an event, there is a state transition with δ2 as trigger event. If δ2 denotes an action, it is an action performed during the transition. (i) If the states and the event are present in the statechart, do nothing. (ii) If they do not exist in the statechart, add two states labeled δ1 and δ3 , respectively, and a transition between them labeled δ2 . (b) Otherwise, analyze subintervals δ1 ; δ2 and δ2 ; δ3 using Rule I2. Rule In: Given δ1 ; δ2 ; ...; δn (interval composed of n subintervals), start analysis with i = 1: — If it is possible to apply Rule I3 (a) in δi ; δi+1 ; δi+2 • Apply Rule I3 (a) • Continue the analysis with subintervals δi+2 ; ...; δn — otherwise • Apply Rule I2 for subintervals δi ; δi+1 • Continue the analysis with subintervals δi+1 ; ...; δn — For all δi , δj that denote events, i < j, add δi as a precondition for δj . In general, fault trees do not use the not gate, because the inclusion of inversion may lead to non-coherent fault trees, which complicates analysis. In a non-coherent fault tree, the system can transition from the failure state to an operational state when an additional component failure occurs [22]. Considering that it is not common to use the not gate, we do not include rules for formulas with negation. In the case of formulas that include predicates, we suggest to rewrite, if possible, the predicates in terms of event occurrences or state transitions. This simplifies the conversion to statecharts. A predicate should be included as a condition for some transition. However, we do not include a general rule of conversion since each predicate requires a particular analysis. Gas burner example As an example, given the cut set {CAV, GP L} consider the basic event CAV related with the Controller, and which is described with the formula AirOn ; F ailureAirOn . There is a statechart for the Controller, so there is no need to create one. First, we apply Rule I2 (e) and the event AirOn becomes a precondition for FailureAirOn, then, we should analyze each

Fig. 5. System model based on cut set {CAV, GP L}

subinterval separately. AirOn refers to an action (open Air Valve) and it is present in the statechart, therefore, according with Rule I1 (c), we do nothing. FailureAirOn refers to a software failure to perform action AirOn and it is an event that is not present in the statechart. Apply Rule I1 (d) that indicates how to describe this event. We apply Rule I2(a)(i) to convert formula N otLeaking ; Leaking that describes the basic event GPL. Finally, we obtain the statechart of Figure 5 as a system model with respect to cut set {CAV, GP L}. In order to obtain a testing model based on this scenario, we do not need to include the whole product of the proposed statechart. We calculate a slice using the slicing technique described in next section. 4.3

Model reduction

In [23] we describe how to reduce a statechart using slicing techniques. We propose a slicing algorithm for statecharts based on a marking of an abstract syntax tree, and thus we define a formal grammar to describe correct syntax for statecharts. Given a statechart we construct an abstract syntax tree. This tree will serve as an input for the slicing algorithm. The slicing algorithm is

Fig. 6. Slice based on cut set { CAV, GPL }

performed by a traversal of the syntax tree, that begins at the node of interest, and then traverses and marks the branches that represent sequences that should be included in the slice. In this work, we are interested in calculating a slice that includes all states and transitions present in a given cut set. For this purpose, during the analysis of a formula that describes a cut set, we perform the marking of the statechart. We mark all states created, or referred to in a formula. Additionally, we mark all target states of all transitions created, modified or referred to in the formula. Finally, we apply the slicing algorithm based on the marking and we obtain a statechart that includes the portions that contribute to reach the scenario depicted by a cut set. As an example, consider the statechart based on cut set {CAV,GPL} (see Figure 5). We mark states Igniting and S2 because they are the target states of transitions t2 and t10 , respectively. We also mark states N otLeaking and Leaking. The resulting slice is shown in Figure 6. 4.4

Test sequence definition

In [24] the authors describe how to generate test cases based on Unified Modeling Language (UML) state diagrams [20]. These diagrams are based on Statecharts. We consider their approach we generate test cases for statecharts. The basic idea is to transform the state diagrams in Extended Finite State Machines (EFSM). The hierarchical and concurrent structure of states is

Fig. 7. Example of EFSM

flattened and broadcast communication are eliminated in the resulting EFSMs. Control flow is identified in terms of the paths in the EFSMs. As an example, consider the statechart of Figure 6. We define the EFSM depicted in Figure 7, and using a state coverage criteria we obtain the test sequences included in Table 1. The sets of related events (second column of the table) correspond to the List of External Events that should be reproduced to exercise the test cases. Note that FailureAirOn represents a software failure. The events that can contribute to a failure state, may be hardware faults, software faults, or any other condition. In order to reproduce possible execution sequences based on this model, we need to generate or simulate each of these events. If the event refers to a software component, we can test the component to gain confidence on its quality. Voas results [25] suggest that we can do even more to increase our confidence on software quality. We can consider a component without knowledge if a particular does exist. For this reason, we propose to inject software faults to reproduce the sequence. In this way, we can quantify the effect of probable hidden errors. In this example, we need to inject a fault in the Controller software component.

Table 1. Test cases Paths

Related events

(C3, t12), (C3, t22), (C4, t112), (C2, t104) {noHeatReq, heatReq, pipeLeak, F ailureAirOn} (C3, t101), (C5, t23), (C6, t113) {F ailureAirOn, heatReq, pipeLeak} (C3, t101), (C5, t114), (C7, t24) {F ailureAirOn, pipeLeak, heatReq} (C3, t111), (C1, t21), (C2, t104) {pipeLeak, heatReq, F ailureAirOn}

5

Conclusions

This work presents a fault-based approach for generating test cases, that extends previous results on fault-based test case generation by including semantic errors. In Section 1, we mentioned that there are many fault-based testing approaches (e.g. [6—11]). These approaches arise as an answer to the decidability problems derived from the objective of traditional testing to prove program correctness [26]. However, these approaches consider errors of syntactic nature. In real applications, faults depend on a multiplicity of causal factors. For the best of our knowledge, this is the first approach that considers combinations of faults. We use Fault Tree Analysis to determine how an undesirable state can occur in the system. The results of this analysis expressed in terms of Duration Calculus are integrated with the system specified behavior to determine how we can reproduce such behaviors. If the Fault Tree Analysis is complete, then our testing approach assures that all conditions that enable a fault situation will show up as test cases. The combination of Fault Tree Analysis and statecharts, poses another problem, such as the integration of heterogeneous specifications. We directed our efforts towards developing an approach that requires as little human intervention as possible. Most of the tasks involved, i.e. the conversion of Duration Calculus formulas to statecharts, the slicing and the generation of test sequences can be automated. Much of the ongoing work is directed at developing tool support. One of the main problems of testing is the definition of an oracle. An oracle is a means to determine acceptable or correct behaviors of a program. In most testing proposals, the existence of an oracle is assumed, what is rather difficult to satisfy in practice since its creation is expensive and sometimes provides incorrect results. In our approach, since we do not aim to prove correctness, we do not need an oracle. Our objective is to demonstrate the absence of prespecified faults, then we need to observe the variables that define a fault state (whose definition is included in the root of the fault tree).

References 1. G. Myers. El Arte de Probar el Software. Librer´ıa El Ateneo Editorial, Buenos Aires, 1983. Spanish translation.

2. Boris Beizer. Black-Box Testing. Techniques for Functional Testing of Software and Systems. John Wiley Sons, Inc., 1995. 3. R. Hamlet and R. Taylor. Partition testing does not inspire confidence. IEEE Transactions on Software Engineering, 16, December 1990. 4. Dick Hamlet. Are We Testing for True Reliability? IEEE Software, 9(4):21—27, July 1992. 5. Richard G. Hamlet. Foundations of software testing: Dependability theory. In Foundations of Software Engineering, pages 128—139, 1994. 6. E.J. Weyuker and T.J. Ostrand. Theories of program testing and the application of revealing subdomains. IEEE Transactions on Software Engineering, 6(3), May 1980. 7. L.J. White and E.I. Cohen. A Domain Strategy for Computer Program Testing. IEEE Transactions on Software Engineering, 6(3), May 1980. 8. K.A. Foster. Error sensitive Test Cases Analysis (ESTCA). IEEE Transactions on Software Engineering, 6(3), May 1980. 9. R.N. Taylor and L.J. Osterweil. Anomaly Detection in Concurrent Software by Static Data Flow Analysis. IEEE Transactions on Software Engineering, 6(3), May 1980. 10. Larry J. Morell. A Theory of Fault-Based Testing. IEEE Transactions on Software Engineering, 16(8):844—857, August 1990. 11. Debra J. Richardson and Margaret C. Thompson. An Analysis of Test Data Selection Criteria Using the RELAY Model of Fault Detection. IEEE Transactions on Software Engineering, 19(6), June 1993. 12. Fault Tree Handbook. Nureg-0492, U.S. Nuclear Regulatory Commission, Washington, D.C., Jan. 1981. 13. D. Harel. Statecharts: A visual formalism for complex systems. Science of Computer Prgramming, 8:231—274, 1987. 14. K. Lano, P. Kan, and A. Sanchez. Linking Hazard Analysis to Formal Specification and Design in B. In Wolfgang Ehrenberger, editor, Lecture Notes in Computer Science 1516, Computer Safety, Reliability and Security, 17th International Conference, SAFECOMP98, Heidelberg, Germany, October 1998, pages 345—358. Springer, 1998. 15. K. M. Hansen, A. P. Ravn, and V. Stavridou. From Safety Analysis to Software Requirements. IEEE Transactions on Software Engineering, 24(7), July 1998. 16. Chaochen Zhou, C.A.R. Hoare, and Anders P. Ravn. A Calculus of Durations. Information Proc. Letters, 40(5):269—276, Dec. 1991. 17. Zhou Chaochen and Li Xiaoshan. A Classical Mind. Essays in Honour of C.A.R. Hoare, chapter A Mean Value Calculus of Durations, pages 431—451. Prentice-Hall, 1994. 18. A. P. Ravn, H. Rischel, and K. M. Hansen. Specifying and Verifying Requirements of Real-Time Systems. IEEE Transactions on Software Engineering, 19(1), January 1993. 19. E. R. Olderog, A. P. Ravn, and J. U. Skakkebaek. Formal Methods in Real-Time Systems. Trends in Software Engineering, chapter Refining Systems Requirements to Program Specifications. John Wiley and Sons, 1996. 20. G. Booch, J. Rumbauch, and I. Jacobson. The Unified Modeling Language. User Guide. Object Technology Series. Addison Wesley Longman, Reading, MA, USA, 1998. 21. A. Pnueli and M. Shalev. What is in a step: On the semantics of statecharts. In Proceedings of the Symposium on Theoretical Aspects of Computer Software, volume 526, pages 244—264. Springer-Verlag, 1991.

22. Joanne Bechta Dugan and Stacy A. Doyle. Incorporating imperfect coverage into a BDD solution of a combinatorial model. Journal of Automatic Control Production Systems, special issue on Binary Decision Diagrams for Reliability Analysis, 30(8):1073—1086, 1996. 23. Marisa A. Sanchez and Miguel A. Felder. Slicing of Statecharts. In George Fernandez and Claudia Pons, editors, 30 JAIIO, Argentine Symposium on Software Engineering Proceedings, Buenos Aires, pages 177—190, 2001. 24. Y. Kim, H. Hong, D. Bae, and S. Cha. Test cases generation from UML state diagrams, 1999. 25. J. Voas and K. Miller. Software Testability: The New Verification. IEEE Software, 12(3), May 1995. 26. J.B. Goodenough and S.L. Gerhart. Toward a theory of test data selection. IEEE Transactions on Software Engineering, 1, June 1975.