Software Transition Testing Presented By: Varun Phanda 0571164408.

Slides:



Advertisements
Similar presentations
Software Testing and Quality Assurance
Advertisements

White Box and Black Box Testing Tor Stålhane. What is White Box testing White box testing is testing where we use the info available from the code of.
Lab7: Introduction to Arduino
SOFTWARE TESTING. INTRODUCTION  Software Testing is the process of executing a program or system with the intent of finding errors.  It involves any.
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.
Programming Logic and Design Eighth Edition
1 Software Engineering Lecture 11 Software Testing.
Programming Types of Testing.
Introduction to Software Testing Chapter 2.6 Graph Coverage for Use Cases Paul Ammann & Jeff Offutt
MIS 325 PSCJ. 2  Business processes can be quite complex  Process model: any abstract representation of a process  Process-modeling tools provide a.
CS0004: Introduction to Programming Repetition – Do Loops.
Software Engineering Introduction to UML.
Information System Engineering
Introduction to Software Testing Chapter 2.6 Graph Coverage for Use Cases Paul Ammann & Jeff Offutt
CMSC 345, Version 11/07 SD Vick from S. Mitchell Software Testing.
Testing dan Implementasi Sistem materi 4
Application architectures
Testing an individual module
Analysis Modeling Dynamic Modeling. Requirements analysis Results in static and dynamic models – Scenario models: use cases (static), swimlane diagrams.
1 Software Testing and Quality Assurance Lecture 27 – Testing State Transition Diagrams.
Application architectures
Test coverage Tor Stålhane. What is test coverage Let c denote the unit type that is considered – e.g. requirements or statements. We then have C c =
Software Testing Sudipto Ghosh CS 406 Fall 99 November 9, 1999.
White Box vs. Black Box Testing Tor Stålhane. What is White Box testing White box testing is testing where we use the info available from the code of.
CC0002NI – Computer Programming Computer Programming Er. Saroj Sharan Regmi Week 7.
Dynamic Black-Box Testing Part 2
Testing. What is Testing? Definition: exercising a program under controlled conditions and verifying the results Purpose is to detect program defects.
1 Copyright (C) 2008 by Dennis A. Fairclough all rights reserved.
Introduction Telerik Software Academy Software Quality Assurance.
Software Testing The process of operating a system or component under specified conditions, observing and recording the results, and making an evaluation.
Testing -- Part II. Testing The role of testing is to: w Locate errors that can then be fixed to produce a more reliable product w Design tests that systematically.
1 © 2005 course technology University Of Palestine Chapter 6 (cont.) Storyboarding the User’s Experience.
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.
Unit Testing 101 Black Box v. White Box. Definition of V&V Verification - is the product correct Validation - is it the correct product.
CSC 395 – Software Engineering Lecture 28: Classical Analysis -or- Do You Really Want to Do That?
1 Muhammed Al-MulhemVisual Languages - 2 Visual Programming Languages ICS 539 Diagrams ICS Department KFUPM Sept. 1, 2007.
1 Graph Coverage (6). Reading Assignment P. Ammann and J. Offutt “Introduction to Software Testing” ◦ Section
White Box and Black Box Testing
Scenario A scenario is a sequence of steps describing an interaction between a user and a system. Use case is a set of scenarios tied together by a common.
Dynamic Models Sequence Diagrams Collaboration Diagrams Activity Diagrams.
Information Systems Engineering Activity Diagram 1.
Software Quality Assurance and Testing Fazal Rehman Shamil.
The Hashemite University Computer Engineering Department
Systems Analysis & Design
1 Software Testing and Quality Assurance Lecture 17 - Test Analysis & Design Models (Chapter 4, A Practical Guide to Testing Object-Oriented Software)
Synchronous Counter Design
Black Box Unit Testing What is black-box testing? Unit (code, module) seen as a black box No access to the internal or logical structure Determine.
Introduction to Computer Programming using Fortran 77.
General Condition Loop A general condition loop just loops while some condition remains true. Note that the body of the loop should (eventually) change.
4 - Conditional Control Structures CHAPTER 4. Introduction A Program is usually not limited to a linear sequence of instructions. In real life, a programme.
Dynamic White-Box Testing What is code coverage? What are the different types of code coverage? How to derive test cases from control flows?
SOFTWARE TESTING LECTURE 9. OBSERVATIONS ABOUT TESTING “ Testing is the process of executing a program with the intention of finding errors. ” – Myers.
Testing dan Implementasi Sistem materi 4
Paul Ammann & Jeff Offutt
Finite State Machines Dr K R Bond 2009
Chapter 8 – Software Testing
Graph Coverage for Specifications CS 4501 / 6501 Software Testing
CHAPTER 4 Test Design Techniques
UNIT-4 BLACKBOX AND WHITEBOX TESTING
Paul Ammann & Jeff Offutt
MSIS 655 Advanced Business Applications Programming
Programming Fundamentals (750113) Ch1. Problem Solving
CSE 370 – Winter Sequential Logic - 1
Test coverage Tor Stålhane.
Graph Coverage for Specifications CS 4501 / 6501 Software Testing
Test Case Test case Describes an input Description and an expected output Description. Test case ID Section 1: Before execution Section 2: After execution.
Testing techniques and methods
Information Systems Engineering
Test Design Techniques Software Testing: IN3240 / IN4240
UNIT-4 BLACKBOX AND WHITEBOX TESTING
Presentation transcript:

Software Transition Testing Presented By: Varun Phanda

State Transition Diagrams  Used in the systems where the correct behavior of the system depends not only on what’s happening right now, but also on what events have occurred so far.  A system that has some awareness of what has happened in the past has state-dependent behavior.  State transition diagrams and state tables are powerful tools for analyzing and testing such systems. Compiled by Varun Phanda 057 MCA/SEM

The Problem Very Large or Infinite number of Test scenarios + Finite Amount of Time = Impossible to test everything. Compiled by Varun Phanda 057 MCA/SEM

The Solution  Software test techniques exist to reduce the number of tests to be run whilst still providing sufficient coverage of the system under test. Compiled by Varun Phanda 057 MCA/SEM

State Transition Testing  Models each state a system can exist in.  Models each state transition.  Defines for each state transition: Start state Input Output Finish state Compiled by Varun Phanda 057 MCA/SEM

Electronic Switch Example  A simple switch has 2 modes : OFF ON Compiled by Varun Phanda 057 MCA/SEM

TEST STEP 1STEP 2STEP 3 START STATE OFFON INPUT SWITCH ONSWITCH OFF OUTPUT LIGHT ONLIGHT OFFLIGHT ON FINISH STATE ONOFFFAULT Compiled by Varun Phanda 057 MCA/SEM

For each Exercise  Draw a State Transition Diagram Draw the states. Mark the state transitions. Define input and output for each state transition.  Determine the level of coverage  Draw a testing tree.  Define the tests. Compiled by Varun Phanda 057 MCA/SEM

15 Reservation System Example Make a reservation  System provides information including departure and destination cities, dates, and times.  A reservation agent uses that information to make a reservation.  At that point, the Reservation is in the Made state. The system creates and starts a timer.  If this timer expires before the reservation is paid for, the reservation is cancelled by the system. Compiled by Varun Phanda 057 MCA/SEM

16 Reservation System Example giveInfo, is an event that comes into the system from the outside world. The command after the "/" denotes an action of the system; in this case startPayTimer. Compiled by Varun Phanda 057 MCA/SEM

17 Reservation System Example  When money is paid, through initiation of the PayMoney action, the system goes into the “Paid” state.  When the ticket is printed, the system goes into the “Ticketed” State  Upon boarding the plane, the customer gives the boarding pass along with the ticket, which signals that the ticket has been “Used”. Compiled by Varun Phanda 057 MCA/SEM

18 Reservation System Example  If the Reservation is not paid on time, the PayTimer expires and the Reservation is “cancelled” for non- payment.  A reservation may become “cancelled” if the customer wishes to do so. If after payment, a refund needs to be generated. If the customer had the tickets with him, a refund cannot be given unless the printed ticket itself is returned to the agent.  Here we use a notational element—square brackets [] that contain a conditional that can be evaluated either True or False.  This conditional acts as a guard allowing the transition only if the condition is true. Compiled by Varun Phanda 057 MCA/SEM

19 State Transition Diagram of the Reservation System Compiled by Varun Phanda 057 MCA/SEM

20 State-Transition Tables  State-transition tables consist of four columns: Current State Event Action Next State.  Build the state-transition table. Compiled by Varun Phanda 057 MCA/SEM

21Compiled by Varun Phanda 057 MCA/SEM

22Compiled by Varun Phanda 057 MCA/SEM

23Compiled by Varun Phanda 057 MCA/SEM

24Compiled by Varun Phanda 057 MCA/SEM

25 State-Transition Tables (Cont.)  The advantage of a state-transition table is that it lists all possible state-transition combinations, not just the valid ones.  When testing critical and high-risk systems, testing every state-transition pair may be required, including those that are not valid.  Creating a state-transition table often unearths combinations that were not identified, documented, or dealt with in the requirements. It is highly beneficial to discover these defects before coding begins. Compiled by Varun Phanda 057 MCA/SEM

26 State-Transition Tables (Cont.)  Using a state-transition table can help detect defects in implementation that enable invalid paths from one state to another.  The disadvantage of such tables is that they become very large very quickly as the number of states and events increases.  In addition, the tables are generally sparse; that is, most of the cells are empty. Compiled by Varun Phanda 057 MCA/SEM

27 Creating Test Cases 1.Create a set of test cases such that all states are "visited" at least once under test. The set of three test cases shown meets this requirement. Generally this is a weak level of test coverage. Compiled by Varun Phanda 057 MCA/SEM

28 A set of test cases that "visit" each state Compiled by Varun Phanda 057 MCA/SEM

29 Creating Test Cases (Cont.) 2. Create a set of test cases such that all paths are executed at least once under test.  While this level is the most preferred because of its level of coverage, it may not be feasible.  If the state-transition diagram has loops, then the number of possible paths may be infinite. For example, given a system with two states, A and B, where A transitions to B and B transitions to A. A few of the possible paths are:  A → B  A → B → A  A → B → A → B → A → B  A → B → A → B → A → B → A ...  and so on forever. Compiled by Varun Phanda 057 MCA/SEM

30 2. Create a set of test cases such that all paths are executed at least once under test (Cont.)  Testing of loops such as this can be important if they may result in accumulating computational errors or resource loss (locks without corresponding releases, memory leaks, etc.). Compiled by Varun Phanda 057 MCA/SEM

31 Creating Test Cases (Cont.) 3.Create a set of test cases such that all transitions are exercised at least once under test. This level of testing provides a good level of coverage without generating large numbers of tests. This level is generally the one recommended. Compiled by Varun Phanda 057 MCA/SEM

32 A set of test cases that trigger all transitions at least once Compiled by Varun Phanda 057 MCA/SEM

33 A set of test cases that trigger all transitions at least once (Cont.)  Test cases can also be read directly from the state- transition table. The gray rows in the following table show all the valid transitions. Compiled by Varun Phanda 057 MCA/SEM

34Compiled by Varun Phanda 057 MCA/SEM

35Compiled by Varun Phanda 057 MCA/SEM

36Compiled by Varun Phanda 057 MCA/SEM

37 State-Transition Testing (Cont.)  In addition, depending on the system risk, you may want to create test cases for some or all of the invalid state/event pairs to make sure the system has not implemented invalid paths. Compiled by Varun Phanda 057 MCA/SEM

Conclusions  State transition testing is one of the many useful techniques available.  A finite number of tests can be defined from an infinite number of test scenarios and a level of coverage can still be achieved.  These diagrams then can be used to direct our testing efforts by identifying the states, events, and transitions that should be tested.  State-Transition diagrams are not applicable when the system has no state or does not need to respond to real-time events from outside of the system Compiled by Varun Phanda 057 MCA/SEM

Examples  Computer System  ATM  Can also be used to test workflow / dataflow Order processing Payroll program that reads an employee's time record, computes pay, subtracts deductions, saves the record, prints a pay check, and repeats the process. Compiled by Varun Phanda 057 MCA/SEM

THANK YOU