Software Testing and QA Theory and Practice (Chapter 10: Test Generation from FSM Models) © Naik & Tripathy 1 Software Testing and Quality Assurance Theory.

Slides:



Advertisements
Similar presentations
Automata Theory Part 1: Introduction & NFA November 2002.
Advertisements

Construction process lasts until coding and testing is completed consists of design and implementation reasons for this phase –analysis model is not sufficiently.
Giving a formal meaning to “Specialization” In these note we try to give a formal meaning to specifications, implementations, their comparisons. We define.
Grey Box testing Tor Stålhane. What is Grey Box testing Grey Box testing is testing done with limited knowledge of the internal of the system. Grey Box.
Alternative Approach to Systems Analysis Structured analysis
Software Testing and QA Theory and Practice (Chapter 2: Theory of Program Testing) © Naik & Tripathy 1 Software Testing and Quality Assurance Theory and.
Chapter 22 Object-Oriented Systems Analysis and Design and UML Systems Analysis and Design Kendall and Kendall Fifth Edition.
Winter 2007SEG2101 Chapter 41 Chapter 4 SDL – Structure and Behavior.
Introduction To System Analysis and Design
Software Testing and Quality Assurance
Component-Level Design
Department of CIS University of Pennsylvania 1/31/2001 Specification-based Protocol Testing Hyoung Seok Hong Oleg Sokolsky CSE 642.
25/06/2015Marius Mikucionis, AAU SSE1/22 Principles and Methods of Testing Finite State Machines – A Survey David Lee, Senior Member, IEEE and Mihalis.
Modeling the Processes and Logic
Handouts Software Testing and Quality Assurance Theory and Practice Chapter 5 Data Flow Testing
Software Testing and QA Theory and Practice (Chapter 15: Software Reliability) © Naik & Tripathy 1 Software Testing and Quality Assurance Theory and Practice.
Software Testing and QA Theory and Practice (Chapter 6: Domain Testing) © Naik & Tripathy 1 Software Testing and Quality Assurance Theory and Practice.
Software Testing and QA Theory and Practice (Chapter 4: Control Flow Testing) © Naik & Tripathy 1 Software Testing and Quality Assurance Theory and Practice.
Handouts Software Testing and Quality Assurance Theory and Practice Chapter 11 System Test Design
Protocol Analysis/Testing Based on Sidhu et al in IEEE TSE 89 and TN 93 Figures from the papers.
Handouts Software Testing and Quality Assurance Theory and Practice Chapter 9 Functional Testing
Introduction To System Analysis and design
Chapter 10 Architectural Design
Why Analysis Process Refer to earlier chapters Models what the system will do makes it easier for understanding no environment considered (hence, system.
Zvi Kohavi and Niraj K. Jha 1 Capabilities, Minimization, and Transformation of Sequential Machines.
Presented By Dr. Shazzad Hosain Asst. Prof., EECS, NSU
From requirements to specification Specification is a refinement of requirements Can be included together as Software Requirements Specifications (SRS)
1. Validating Wireless Protocol Conformance Test Cases Amresh Nandan Paresh Jain June 2004.
Introduction To System Analysis and Design
SOFTWARE DESIGN (SWD) Instructor: Dr. Hany H. Ammar
SOFTWARE DESIGN.
Low-Level Detailed Design SAD (Soft Arch Design) Mid-level Detailed Design Low-Level Detailed Design Design Finalization Design Document.
Ch. 2. Specification and Modeling 2.1 Requirements Describe requirements and approaches for specifying and modeling embedded systems. Specification for.
Grey Box testing Tor Stålhane. What is Grey Box testing Grey Box testing is testing done with limited knowledge of the internal of the system. Grey Box.
Sommerville 2004,Mejia-Alvarez 2009Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
UHD::3320::CH121 DESIGN PHASE Chapter 12. UHD::3320::CH122 Design Phase Two Aspects –Actions which operate on data –Data on which actions operate Two.
7 Systems Analysis and Design in a Changing World, Fifth Edition.
By, Venkateswara Reddy. Tallapu Reddy. 1.Introduction. 2.What is X-Machine Testing..?? 3.Methods of X-Machine Testing. 4.Variants of X- Machine. 5.Stream.
Fall 2004EE 3563 Digital Systems Design EE 3563 VHSIC Hardware Description Language  Required Reading: –These Slides –VHDL Tutorial  Very High Speed.
1 Introduction to Software Testing. Reading Assignment P. Ammann and J. Offutt “Introduction to Software Testing” ◦ Chapter 1 2.
SOFTWARE DESIGN. INTRODUCTION There are 3 distinct types of activities in design 1.External design 2.Architectural design 3.Detailed design Architectural.
Object-Oriented Modeling: Static Models. Object-Oriented Modeling Model the system as interacting objects Model the system as interacting objects Match.
Automatic Testing of Neighbor Discovery Protocol Based on FSM and TTCN Zhiliang Wang, Xia Yin, Haibin Wang, Jianping Wu Department of Computer Science.
Systems Analysis and Design in a Changing World, Fourth Edition
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
OPERATING SYSTEMS CS 3530 Summer 2014 Systems and Models Chapter 03.
Requirement Analysis SOFTWARE ENGINEERING. What are Requirements? Expression of desired behavior Deals with objects or entities, the states they can be.
1 Specification A broad term that means definition Used at different stages of software development for different purposes Generally, a statement of agreement.
1 CEN 4020 Software Engineering PPT4: Requirement analysis.
1 © 2011 Professor W. Eric Wong, The University of Texas at Dallas Requirements-based Test Generation for Functional Testing W. Eric Wong Department of.
7 Systems Analysis – ITEC 3155 The Object Oriented Approach – Use Cases.
McGraw-Hill/Irwin Copyright © 2006 by The McGraw-Hill Companies, Inc. All rights reserved. Chapter 5 Modeling the Processes and Logic.
Introduction to Software Testing (2nd edition) Chapter 5 Criteria-Based Test Design Paul Ammann & Jeff Offutt
Topic 4: Distributed Objects Dr. Ayman Srour Faculty of Applied Engineering and Urban Planning University of Palestine.
From requirements to specification Specification is a refinement of requirements Can be included together as Software Requirements Specifications (SRS)
Software Testing and QA Theory and Practice (Chapter 5: Data Flow Testing) © Naik & Tripathy 1 Software Testing and Quality Assurance Theory and Practice.
Systems Analysis and Design in a Changing World, Fourth Edition
OPERATING SYSTEMS CS 3502 Fall 2017
An Overview of Requirements Engineering Tools and Methodologies*
Chapter 5 System modeling
Course Outcomes of Object Oriented Modeling Design (17630,C604)
Handouts Software Testing and Quality Assurance Theory and Practice Chapter 4 Control Flow Testing
Input Space Partition Testing CS 4501 / 6501 Software Testing
Graph Coverage for Specifications CS 4501 / 6501 Software Testing
Outline of the Chapter Basic Idea Outline of Control Flow Testing
Graph Coverage for Specifications CS 4501 / 6501 Software Testing
Chapter 22 Object-Oriented Systems Analysis and Design and UML
Chapter 6: Architectural Design
Software Testing and QA Theory and Practice (Chapter 5: Data Flow Testing) © Naik & Tripathy 1 Software Testing and Quality Assurance Theory and Practice.
Presentation transcript:

Software Testing and QA Theory and Practice (Chapter 10: Test Generation from FSM Models) © Naik & Tripathy 1 Software Testing and Quality Assurance Theory and Practice Chapter 10 Test Generation from FSM Models

Software Testing and QA Theory and Practice (Chapter 10: Test Generation from FSM Models) © Naik & Tripathy 2 Outline of the Chapter State-oriented Model Points of Control and Observation Finite-state Machine (FSM) Test Generation from an FSM Transition Tour Method Testing with State Verification Unique Input/Output Sequence Distinguishing Sequence Characterizing Sequence Test Architectures Testing and Test Control Notation 3 (TTCN-3) Extended Finite-state Machines Test Generation from EFSM Models Additional Coverage Criteria for System Testing Summary

Software Testing and QA Theory and Practice (Chapter 10: Test Generation from FSM Models) © Naik & Tripathy 3 State-oriented Model Software systems –State-oriented (Examples: Operating Systems) –Stateless (Example: compiler) State-oriented system: two parts –Control portion –Data portion Figure 10.1: Spectrum of software systems.

Software Testing and QA Theory and Practice (Chapter 10: Test Generation from FSM Models) © Naik & Tripathy 4 State-oriented Model The control portion of a system is often modeled as an FSM. Figure 10.4: FSM model of a dual-boot laptop computer. Figure 10.5: The interactions between a system and its environment are modeled as an FSM.

Software Testing and QA Theory and Practice (Chapter 10: Test Generation from FSM Models) © Naik & Tripathy 5 Points of Control and Observation A PCO is a point of interaction between a system and it users. Figure 10.6: PCOs on a telephone Table 10.1: PCOs for testing a telephone PBX. PCOIN/OUT HookIN KeypadIN RingerOUT SpeakerOUT MouthpieceIN

Software Testing and QA Theory and Practice (Chapter 10: Test Generation from FSM Models) © Naik & Tripathy 6 Points of Control and Observation Figure 5.7: FSM model of a private branch exchange (PBX)

Software Testing and QA Theory and Practice (Chapter 10: Test Generation from FSM Models) © Naik & Tripathy 7 Finite-state Machine (FSM) A finite-state machine M =, where S is a set of states. I is a set of inputs. O is a set of outputs. s0 is the initial state. δ: S x I  S (next state function) λ: S x I  O (output function) Figure 10.8: FSM model of a private branch exchange (PBX).

Software Testing and QA Theory and Practice (Chapter 10: Test Generation from FSM Models) © Naik & Tripathy 8 Test Generation from an FSM Let M be the FSM model of a system and I M be its implementation. An important testing task is to confirm if I M behaves like M. Conformance testing: Ensure by means of testing that I M conforms to its spec. M. A general procedure for conformance testing –Derive sequences of state-transitions from M. Turn each state-transition into a test sequence. Test I M with a test sequence to observe whether or not I M possesses the corresponding transition sequence. –The conformance of I M with M can be verified by choosing enough state- transition sequences.

Software Testing and QA Theory and Practice (Chapter 10: Test Generation from FSM Models) © Naik & Tripathy 9 Transition Tour (TT) Method TT: It is a sequence of state-transitions from the initial state to the final state. Example: From Figure 10.8, Figure 10.9: Interaction of a test sequence with an SUT. Ideas in turning a TT into a test case. –The input/output in a test case are derives from a TT. –Unexpected inputs must be processed. –Indefinite waits must be avoided. Figure 10.10: Derived test case from the transition tour.

Software Testing and QA Theory and Practice (Chapter 10: Test Generation from FSM Models) © Naik & Tripathy 10 Transition Tour (TT) Method Coverage metrics for FSM based testing –State coverage Choose enough number of TTs to be able to cover each state at least once. –You can choose 3 TTs to cover all the states, but just 11 of the transitions. –Transition coverage Choose enough number of TTs to be able to cover each state-transition at least once.

Software Testing and QA Theory and Practice (Chapter 10: Test Generation from FSM Models) © Naik & Tripathy 11 Testing with State Verification Two functions associated with a state- transition –Output function: Easy to verify in the TT method. –Next-state function: Ignored in the TT method (drawback of the TT method). Figure 10.11: Conceptual model of a test case with state verification. State verification with –Unique Input/Output (UIO) sequences –Distinguishing sequences –Characterizing sequences

Software Testing and QA Theory and Practice (Chapter 10: Test Generation from FSM Models) © Naik & Tripathy 12 Unique Input/Output Sequence Let X be an input sequence applied in a state s, and Y be the corresponding output sequence. X/Y is a UIO sequence for s if no other state produces output sequence Y in response to input X. Thus, X/Y is unique to s. Four assumptions about an FSM –Completely specified –Deterministic –Reduced –Strongly connected

Software Testing and QA Theory and Practice (Chapter 10: Test Generation from FSM Models) © Naik & Tripathy 13 Unique Input/Output Sequence Figure 10.12: Finite-state machine G1. Table 10.7: UIO sequences of minimal lengths obtained from Figure Figure 10.14: Identification of UIO sequences on the UIO tree of Figure (Fig is similar to Fig ).

Software Testing and QA Theory and Practice (Chapter 10: Test Generation from FSM Models) © Naik & Tripathy 14 Distinguishing Sequence Let X be an input sequence. X is a distinguishing sequence for an FSM, if each state produces a unique (i.e. different) output sequence in response to X. Four assumptions about an FSM –Completely specified –Deterministic –Reduced –Strongly connected

Software Testing and QA Theory and Practice (Chapter 10: Test Generation from FSM Models) © Naik & Tripathy 15 Distinguishing Sequence Figure 10.15: Finite-state machine G2. Figure 10.16: Distinguishing sequence tree for G2 in Figure Table 10.9: Output of FSM G2 in response to input sequence 11 in different states.

Software Testing and QA Theory and Practice (Chapter 10: Test Generation from FSM Models) © Naik & Tripathy 16 Characterizing Sequence Some FSMs do not have a D-sequence. –State verification is still possible. –Use characterizing sets. Characterizing Sets (CS) – A CS for a state s is a set of input sequences such that, when each sequence is applied to the FSM in s, the set of output sequences is unique. –Thus s is uniquely identified. Figure 10.17: An FSM that does not possess a distinguishing sequence. Figure 10.18: DS-tree for FSM (Figure 10.17).

Software Testing and QA Theory and Practice (Chapter 10: Test Generation from FSM Models) © Naik & Tripathy 17 Characterizing Sequence Figure 10.10: Output sequences generated by the FSM of Figure as a response to W1. Figure 10.11: Output sequences generated by the FSM of Figure as a response to W2.

Software Testing and QA Theory and Practice (Chapter 10: Test Generation from FSM Models) © Naik & Tripathy 18 Characterizing Sequence Figure 10.12: Test sequences for the state transition (D, A, a/x) of the FSM in Fig

Software Testing and QA Theory and Practice (Chapter 10: Test Generation from FSM Models) © Naik & Tripathy 19 Test Architectures A test architecture is a certain configuration of –an Implementation Under Test (IUT) –one or more test entities, –one or two PCOs, and –a communication service provide. Common test architectures –Local Architecture –Distributed Architecture –Coordinated Architecture –Remote Architecture Figure 10.19: Abstraction of an (N)-Entity in the OSI reference architecture

Software Testing and QA Theory and Practice (Chapter 10: Test Generation from FSM Models) © Naik & Tripathy 20 Test Architectures Local Architecture Figure 10.22: Local architecture. Distributed Architecture Figure 10.23: Distributed architecture.

Software Testing and QA Theory and Practice (Chapter 10: Test Generation from FSM Models) © Naik & Tripathy 21 Test Architectures Coordinated Architecture Figure 10.24: Coordinated architecture. Remote Architecture Figure 10.25: Remote architecture.

Software Testing and QA Theory and Practice (Chapter 10: Test Generation from FSM Models) © Naik & Tripathy 22 Testing and Test Control Notation 3 (TTCN-3) TTCN-3 –A language for specifying test cases. –Predecessors were TTCN-1 and TTCN-2 (Tree and Tabular Combined Notation) –Standardized by ETSI (European Telecom. Standards Institute) Core features of TTCN-3 –Module –Data types –Templates –Ports –Components –Test Cases

Software Testing and QA Theory and Practice (Chapter 10: Test Generation from FSM Models) © Naik & Tripathy 23 Testing and Test Control Notation 3 (TTCN-3) Module Figure 10.26: The structure of a module in TTCN-3.

Software Testing and QA Theory and Practice (Chapter 10: Test Generation from FSM Models) © Naik & Tripathy 24 Testing and Test Control Notation 3 (TTCN-3) Types, subtypes, and messages Figure 10.27: Definitions of two subtypes. Figure 10.28: A parameterized template for constructing a message to be sent. Figure 10.29: A parameterized template for constructing a message to be sent.

Software Testing and QA Theory and Practice (Chapter 10: Test Generation from FSM Models) © Naik & Tripathy 25 Testing and Test Control Notation 3 (TTCN-3) Ports Figure 10.30: Testing an application called SFC calculator (a) and a port between the tester and the SFC calculator (b).

Software Testing and QA Theory and Practice (Chapter 10: Test Generation from FSM Models) © Naik & Tripathy 26 Testing and Test Control Notation 3 (TTCN-3) Ports and components Figure 10.31: Defining a port type. Figure 10.32: Associating a port with a component.

Software Testing and QA Theory and Practice (Chapter 10: Test Generation from FSM Models) © Naik & Tripathy 27 Testing and Test Control Notation 3 (TTCN-3) Ports and components Figure 10.33: A test case for testing the square root function calculator.

Software Testing and QA Theory and Practice (Chapter 10: Test Generation from FSM Models) © Naik & Tripathy 28 Testing and Test Control Notation 3 (TTCN-3) Test case execution Figure 10.34: Executing a test case.

Software Testing and QA Theory and Practice (Chapter 10: Test Generation from FSM Models) © Naik & Tripathy 29 Extended Finite-state Machines Two conceptual components of a software system are –Flow of control –Manipulation of data Manipulate local variables. Start and stop timers. Create instances of processes. Compare values and make control-flow decisions. Access databases. There is a need for modeling a software system as an EFSM. We consider the Specification and Description Languages (SDL). –The basic concepts in SDL are as follows: System Behavior Data Communication

Software Testing and QA Theory and Practice (Chapter 10: Test Generation from FSM Models) © Naik & Tripathy 30 Extended Finite-state Machines Figure 10.35: Comparison of state-transitions of an FSM and an EFSM.

Software Testing and QA Theory and Practice (Chapter 10: Test Generation from FSM Models) © Naik & Tripathy 31 Test Generation from EFSM Models Let E be an EFSM and P E be a program implementing E. Goal: Test that P E behaves as E. Basic idea –Phase 1: Identify a set of state-transition sequences such that each sequence of state-transitions represents a common use sequence. –Phase 2: Design a test case from each state-transition sequence. Phase 1 –Pay attention to the following. Perform tests to ensure that the system under test (SUT) produces expected sequences of outcomes in response to input sequences. Perform tests to ensure that the system under test takes the right actions when a timeout occurs. Perform tests to ensure that the system under test has appropriately implemented other task blocks, such as resource allocation, database accesses, etc. –Coverage criteria: state coverage and transition coverage.

Software Testing and QA Theory and Practice (Chapter 10: Test Generation from FSM Models) © Naik & Tripathy 32 Test Generation from EFSM Models Phase 2 –Transform the inputs and outputs in a transition tour into outputs and inputs, respectively. –Augment the above core test behavior with “otherwise” events to be able to handle exception events. –Augment the above test behavior with timers.

Software Testing and QA Theory and Practice (Chapter 10: Test Generation from FSM Models) © Naik & Tripathy 33 Test Generation from EFSM Models Figure 10.36: Controlled access to a door.

Software Testing and QA Theory and Practice (Chapter 10: Test Generation from FSM Models) © Naik & Tripathy 34 Test Generation from EFSM Models Figure 10.37: SDL/GR door control system.

Software Testing and QA Theory and Practice (Chapter 10: Test Generation from FSM Models) © Naik & Tripathy 35 Test Generation from EFSM Models Figure 10.38: Door control behavior specification (1 of 2). Figure 10.39: Door control behavior specification (2 of 2).

Software Testing and QA Theory and Practice (Chapter 10: Test Generation from FSM Models) © Naik & Tripathy 36 Test Generation from EFSM Models GETDIGIT  … GETDIGIT  … GETDIGIT  … DOOROPEN  GETDIGIT. Figure 10.40: A transition tour from the door control system of Figs and Figure 10.41: Testing the door control system.

Software Testing and QA Theory and Practice (Chapter 10: Test Generation from FSM Models) © Naik & Tripathy 37 Test Generation from EFSM Models Figure 10.42: Output and input behavior obtained from the transition tour of Fig

Software Testing and QA Theory and Practice (Chapter 10: Test Generation from FSM Models) © Naik & Tripathy 38 Test Generation from EFSM Models Figure 10.43: Test behavior obtained by refining the “if” part in Fig

Software Testing and QA Theory and Practice (Chapter 10: Test Generation from FSM Models) © Naik & Tripathy 39 Test Generation from EFSM Models Figure 10.44: Test behavior that can receive unexpected events. This is derived from Fig

Software Testing and QA Theory and Practice (Chapter 10: Test Generation from FSM Models) © Naik & Tripathy 40 Test Generation from EFSM Models Figure 10.45: The core behavior (partial) of a test case for testing the door control system. This is derived from Fig (See the book for the complete test case.)

Software Testing and QA Theory and Practice (Chapter 10: Test Generation from FSM Models) © Naik & Tripathy 41 Additional Coverage Criteria for System Testing PCO coverage –Select test cases such that the SUT receives an event at each input PCO and produces an event at each output PCO. Sequence of events at PCOs –Select test cases such that common sequences of inputs and outputs occur at the PCOs. Events occurring in different contexts –An event generated at a PCO may have different meanings at different times. Inopportune events –Inopportune events are normal events which occur at an inappropriate time.

Software Testing and QA Theory and Practice (Chapter 10: Test Generation from FSM Models) © Naik & Tripathy 42 Summary Software systems –Stateless –State-oriented Control portion is modeled by an FSM or an EFSM. Testing FSM based systems –Transition tour method –State verification method State verification techniques –Distinguishing sequence –UIO sequence –Characterizing sequence Coverage metrics –State coverage –State-transition coverage Test architectures –Local –Distributes –Coordinated –Remote TTCN-3 –Data types –Modules –Ports –Templates Testing EFSM based systems –Identify transition sequences –Turn each sequence into a test case Input/output  Output/input “Otherwise” events Timers –Coverage metrics PCO coverage Sequences of events at each PCO Events occurring in different contexts Inopportune events