Introduction to Software Testing Chapter 8.5 Logic Coverage for FSMs

Slides:



Advertisements
Similar presentations
Introduction to Software Testing Chapter 1 Model-Driven Test Design Paul Ammann & Jeff Offutt
Advertisements

Introduction to Software Testing Chapter 3.3 Logic Coverage from Source Code Paul Ammann & Jeff Offutt.
Introduction to Software Testing Chapter 8.3 Logic Coverage for Source Code Paul Ammann & Jeff Offutt
Introduction to Software Testing Chapter 3.1, 3.2 Logic Coverage Paul Ammann & Jeff Offutt
CITS5501 Software Quality and Testing Logic and Path Coverage From Introduction to Software Testing, 2 nd ed, Ammann & Offutt.
Introduction to Software Testing Chapter 3.1 Logic Coverage Paul Ammann & Jeff Offutt.
Introduction to Software Testing Chapter 5.2 Program-based Grammars Paul Ammann & Jeff Offutt
Introduction to Software Testing Chapter 9.4 Model-Based Grammars Paul Ammann & Jeff Offutt
Introduction to Software Testing Chapter 2.5 Graph Coverage for Specifications Paul Ammann & Jeff Offutt
Introduction to Software Testing Chapter 3.1, 3.2 Logic Coverage Paul Ammann & Jeff Offutt
Introduction to Software Testing Chapters 1-5 Coverage Summary Paul Ammann & Jeff Offutt
Introduction to Software Testing Paul Ammann & Jeff Offutt Updated 24-August 2010.
Introduction to Software Testing Chapter 9.2 Program-based Grammars Paul Ammann & Jeff Offutt
Introduction to Software Testing Chapter 3.1 Logic Coverage Paul Ammann & Jeff Offutt.
Introduction to Software Testing Chapter 3.4 Logic Coverage for Specifications Paul Ammann & Jeff Offutt
Introduction to Software Testing (2nd edition) Chapter 5 Criteria-Based Test Design Paul Ammann & Jeff Offutt
Introduction to Software Testing Chapter 8.5 Logic Coverage for FSMs Paul Ammann & Jeff Offutt
Paul Ammann & Jeff Offutt
Paul Ammann & Jeff Offutt
Introduction to Software Testing Chapter 8.1 Logic Coverage
Paul Ammann & Jeff Offutt
Paul Ammann & Jeff Offutt
Paul Ammann & Jeff Offutt
Paul Ammann & Jeff Offutt
Paul Ammann & Jeff Offutt
Paul Ammann & Jeff Offutt
Paul Ammann & Jeff Offutt
Introduction to Software Testing Chapter 9.2 Program-based Grammars
Paul Ammann & Jeff Offutt
Input Space Partition Testing CS 4501 / 6501 Software Testing
Graph Coverage for Specifications CS 4501 / 6501 Software Testing
Paul Ammann & Jeff Offutt
AS Computer Studies Finite State Machines 2.
Introduction to Software Testing Chapter 3.5 Logic Coverage for FSMs
Introduction to Software Testing Chapter 3.1, 3.2 Logic Coverage
Logic Coverage CS 4501 / 6501 Software Testing
Paul Ammann & Jeff Offutt
Introduction to Software Testing Chapter 2 Model-Driven Test Design
Introduction to Software Testing Chapter 9.2 Program-based Grammars
Paul Ammann & Jeff Offutt
Paul Ammann & Jeff Offutt
Paul Ammann & Jeff Offutt
Paul Ammann & Jeff Offutt
Paul Ammann & Jeff Offutt
Introduction to Software Testing Chapter 5.2 Program-based Grammars
Paul Ammann & Jeff Offutt
Introduction to Software Testing Chapter 3, Sec# 3.5
Moonzoo Kim School of Computing KAIST
Paul Ammann & Jeff Offutt
Introduction to Software Testing Chapter 3.2 Logic Coverage
Paul Ammann & Jeff Offutt
Introduction to Software Testing Chapter 3.5 Logic Coverage for FSMs
Logic Coverage CS 4501 / 6501 Software Testing
ISP Coverage Criteria CS 4501 / 6501 Software Testing
Graph Coverage for Design Elements CS 4501 / 6501 Software Testing
Graph Coverage for Specifications CS 4501 / 6501 Software Testing
Paul Ammann & Jeff Offutt
Paul Ammann & Jeff Offutt
Paul Ammann & Jeff Offutt
Logic Coverage for Source Code CS 4501 / 6501 Software Testing
[Ammann and Offutt, “Introduction to Software Testing,” Ch. 8]
Introduction to Software Testing Chapter 8.1 Logic Coverage
Paul Ammann & Jeff Offutt
Introduction to Software Testing Chapter 8.5 Logic Coverage for FSMs
Paul Ammann & Jeff Offutt
Paul Ammann & Jeff Offutt
Paul Ammann & Jeff Offutt
Introduction to Software Testing Chapter 3.2 Logic Coverage
Introduction to Software Testing Chapter 3.1, 3.2 Logic Coverage
Presentation transcript:

Introduction to Software Testing Chapter 8.5 Logic Coverage for FSMs Paul Ammann & Jeff Offutt http://www.cs.gmu.edu/~offutt/softwaretest/ The animation in these slides turns the example in the non-active version into an active in-class exercise. Let the students try the work, then show the answers here. It really helps to have the FSM in slides 3 visible at all times. I draw it on a board on the side while they’re working on slide 4.

Covering Finite State Machines FSMs are graphs Nodes represent state Edges represent transitions among states Transitions often have logical expressions as guards or triggers As we said : Find a logical expression and cover it Introduction to Software Testing, Edition 2 (Ch 8) © Ammann & Offutt

(applies to all three transitions) Example—Subway Train All Doors Open secondPlatform = right secondPlatform= left ¬ emergencyStop  ¬ overrideOpen  doorsClear  closeDoorPressed (applies to all three transitions) Left Doors Open Right Doors Open It really helps to have the FSM in slides 3 visible at all times. I draw it on a board on the side while they’re working on slide 4. All Doors Closed trainSpeed = 0  platform=left  (location = inStation  (emergencyStop  overrideOpen  location = inTunnel)) trainSpeed = 0  platform=right  (location = inStation  (emergencyStop  overrideOpen  location = inTunnel)) Introduction to Software Testing, Edition 2 (Ch 8) © Ammann & Offutt

Determination of the Predicate trainSpeed = 0  platform=left  (location = inStation  (emergencyStop  overrideOpen  location = inTunnel)) Find the truth assignments that let the all six clauses determine the value of the predicate. That is, solve for PtrainSpeed, then Pplatform=left, etc. By this time, most students should be able to do this quickly, without going through the computations. a  b  (c  (d  e  f)) Introduction to Software Testing, Edition 2 (Ch 8) © Ammann & Offutt

Determination of the Predicate trainSpeed = 0  platform=left  (location = inStation  (emergencyStop  overrideOpen  location = inTunnel)) PtrainSpeed = 0 : platform = left  (location = inStation  (emergencyStop  overrideOpen  location = inTunnel)) Solution for PtrainSpeed … Pplatform = left : trainSpeed = 0  (location = inStation  (emergencyStop  overrideOpen  location = inTunnel)) Solution for Pplatform … Plocation = inStation : trainSpeed = 0  platform = left  (¬ emergencyStop  ¬ overrideOpen  ¬ location = inTunnel) Solution for PinStation … PemergencyStop : trainSpeed = 0  platform = left  (¬ location = inStation  overrideOpen  location = inTunnel) Solution for PemergencyStop … PoverrideOpen : trainSpeed = 0  platform = left  (¬ location = inStation  emergencyStop  location = inTunnel) Solution for PoverrideOpen … Plocation = inTunnel : trainSpeed = 0  platform = left  (¬ location = inStation  emergencyStop  overrideOpen) Solution for Plocation … Introduction to Software Testing, Edition 2 (Ch 8) © Ammann & Offutt

Test Truth Assignments (CACC) trainSpeed = 0  platform=left  (location = inStation  (emergencyStop  overrideOpen  location = inTunnel)) Major Clause Speed=0 platform=left inStation emergStop overrideOpen inTunnel trainSpeed = 0 T t trainSpeed != 0 F platform = left platform != left ¬ inStation emergencyStop ¬ emergStop ¬ overrideOpen ¬ inTunnel One of these must be true Fill in the remaining truth assignments based on the expressions computed for the previous slide Introduction to Software Testing, Edition 2 (Ch 8) © Ammann & Offutt

Test Truth Assignments (CACC) trainSpeed = 0  platform=left  (location = inStation  (emergencyStop  overrideOpen  location = inTunnel)) Major Clause Speed=0 platform=left inStation emergStop overrideOpen inTunnel trainSpeed = 0 T t trainSpeed != 0 F platform = left platform != left f ¬ inStation emergencyStop ¬ emergStop ¬ overrideOpen ¬ inTunnel Major Clause Speed=0 platform=left inStation emergStop overrideOpen inTunnel trainSpeed = 0 T t trainSpeed != 0 platform = left platform != left ¬ inStation emergencyStop ¬ emergStop ¬ overrideOpen ¬ inTunnel One of these must be true One of these must be false Introduction to Software Testing, Edition 2 (Ch 8) © Ammann & Offutt

Problem With a Predicate? trainSpeed=0 platform=left inStation emergencyStop overrideOpen inTunnel t T f ¬ inStation F Do you see a problem here? Think about these two values … The model only has two locations inStation and inTunnel So these cannot both be false! If the train is not in the station (location != inStation), then it must be in a tunnel (location = inTunnel) Possible solutions : Check with the developer for mistakes (do this first) Rewrite the predicate to eliminate dependencies (if possible) Change truth assignment : t t F f f t Introduction to Software Testing, Edition 2 (Ch 8) © Ammann & Offutt

Expected Results Expected outputs are read from the FSM : When the major clause is true, the transition is taken When false, the transition is not taken Expected Results trainSpeed = 0 trainSpeed != 0 platform = left platform != left inStation ¬ inStation emergencyStop ¬ emergencyStop overrideOpen ¬ overrideOpen inTunnel ¬ inTunnel Fill in the expected results Introduction to Software Testing, Edition 2 (Ch 8) © Ammann & Offutt

Expected Results Expected outputs are read from the FSM : When the major clause is true, the transition is taken When false, the transition is not taken Expected Results trainSpeed = 0 Left Doors Open trainSpeed != 0 All Doors Closed platform = left platform != left inStation ¬ inStation emergencyStop ¬ emergencyStop overrideOpen ¬ overrideOpen inTunnel ¬ inTunnel Expected Results trainSpeed = 0 trainSpeed != 0 platform = left platform != left inStation ¬ inStation emergencyStop ¬ emergencyStop overrideOpen ¬ overrideOpen inTunnel ¬ inTunnel Do you notice anything “funny”? If platform !=left, then platform must equal right So the expected output of this test is to go to state “Right Doors Open” What about here? Only a mean teacher would tell the students this is easy. Accidental transitions must be recognized when designing expected results during test automation Introduction to Software Testing, Edition 2 (Ch 8) © Ammann & Offutt

Early Identification is a Win! The process of modeling software artifacts for test design can help us find defects in the artifacts This is a very powerful side-effect of the model-driven test design process Introduction to Software Testing, Edition 2 (Ch 8) © Ammann & Offutt

Complicating Issues Some buttons must be pressed simultaneously to have effect – so timing must be tested Reachability : The tests must reach the state where the transition starts (the prefix) Exit : Some tests must continue executing to an end state Expected output : The expected output is the state that the transition reaches for true values, or same state for false values Accidental transitions : Sometimes a false value for one transition happens to be a true value for another The alternate expected output must be recognized Introduction to Software Testing, Edition 2 (Ch 8) © Ammann & Offutt

Test Automation Issues Mapping problem : The names used in the FSMs may not match the names in the program Examples platform = left requires the train to go to a specific station trainspeed = 0 probably requires the brake to be applied multiple times The solution to this is implementation-specific Sometimes a direct name-to-name mapping can be found Sometimes more complicated actions must be taken to assign the appropriate values Simulation : Directly inserting value assignments into the middle of the program This is an issue of controllability Introduction to Software Testing, Edition 2 (Ch 8) © Ammann & Offutt

Summary FSM Logic Testing FSMs are widely used at all levels of abstraction Many ways to express FSMs Statecharts, tables, Z, decision tables, Petri nets, … Predicates are usually explicitly included on the transitions Guards Actions Often represent safety constraints FSMs are often used in embedded software Introduction to Software Testing, Edition 2 (Ch 8) © Ammann & Offutt