Software Testing. 1. Testing is the process of demonstrating that errors are not present.

Similar documents
What is Structural Testing?

Functional Testing (Black Box Testing)

Testing Theory. Agenda - What will you learn today? A Software Life-cycle Model Which part will we talk about today? Theory Lecture Plan

PES INSTITUTE OF TECHNOLOGY- BANGALORE SOUTH CAMPUS

EECS 4313 Software Engineering Testing. Topic 05: Equivalence Class Testing Zhen Ming (Jack) Jiang

PESIT Bangalore South Campus

Darshan Institute of Engineering & Technology for Diploma Studies

SOFTWARE ENGINEERING IT 0301 Semester V B.Nithya,G.Lakshmi Priya Asst Professor SRM University, Kattankulathur

EXERCISES (Software Engineering)

Software Testing Fundamentals. Software Testing Techniques. Information Flow in Testing. Testing Objectives

Computer Science and Software Engineering University of Wisconsin - Platteville 9-Software Testing, Verification and Validation

Software Quality Assurance. David Janzen

Introduction to Software Engineering

SE Notes Mr. D. K. Bhawnani, Lect (CSE) BIT

Software Testing Prof. Rajib Mall Department of Computer Science and Engineering Indian Institute of Technology, Kharagpur

Chapter 3: Dynamic Testing Techniques

CS 4387/5387 SOFTWARE V&V LECTURE 4 BLACK-BOX TESTING

Input Space Partitioning

Darshan Institute of Engineering & Technology Unit : 9

Quality Assurance in Software Development

Difference Between Dates Case Study 2002 M. J. Clancy and M. C. Linn

Modern Methods in Software Engineering. Testing.

Lecture 26: Testing. Software Engineering ITCS 3155 Fall Dr. Jamie Payton

Aerospace Software Engineering

Specification-based test design

MONIKA HEINER.

Subject: PROBLEM SOLVING THROUGH C Time: 3 Hours Max. Marks: 100

MTAT : Software Testing

Topic: Software Verification, Validation and Testing Software Engineering. Faculty of Computing Universiti Teknologi Malaysia

MSc Software Testing MSc Prófun hugbúnaðar

Simulink Verification and Validation

linaye/gl.html

2 Geometry Solutions

Verification and Validation

Overview. State-of-the-Art. Relative cost of error correction. CS 619 Introduction to OO Design and Development. Testing.

Programming Logic and Design Sixth Edition

Question Bank. Unit 1: Perspective on Testing, Examples. Chapter 1 & 2 from Dr. Paul C. Jorgensen

Software technology 7. Testing (2) BSc Course Dr. Katalin Balla

Verification and Validation. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 22 Slide 1

SENIOR KANGAROO MATHEMATICAL CHALLENGE. Friday 2nd December Organised by the United Kingdom Mathematics Trust

Verification and Validation. Assuring that a software system meets a user s needs. Verification vs Validation. The V & V Process

Programming Embedded Systems

Software Testing: A Craftsman s Approach, 4 th Edition. Chapter 16 Software Complexity

Verification Overview Testing Theory and Principles Testing in Practice. Verification. Miaoqing Huang University of Arkansas 1 / 80

Software Engineering (CSC 4350/6350) Rao Casturi

Software Testing. Software Testing

SFWR ENG 3S03: Software Testing

An Introduction to Systematic Software Testing. Robert France CSU

In this Lecture you will Learn: Testing in Software Development Process. What is Software Testing. Static Testing vs.

4B Summary of some Key SW Testing Concepts 1

Equivalence Class Partitioning. Equivalence Partitioning. Definition and Example. Example set of classes

CSCE 747 Software Testing and Quality Assurance

Matrices. Chapter Matrix A Mathematical Definition Matrix Dimensions and Notation

INTRODUCTION TO SOFTWARE ENGINEERING

Testing! Prof. Leon Osterweil! CS 520/620! Spring 2013!

CMPSCI 521/621 Homework 2 Solutions

A Beginner s Guide to Programming Logic, Introductory. Chapter 6 Arrays

Lecture 15 Software Testing

Sequential Search (Searching Supplement: 1-2)

UNIT 1-2 MARKS QUESTIONS WITH ANSWERS

B.Stat / B.Math. Entrance Examination 2017

Software Testing part II (white box) Lecturer: Giuseppe Santucci

Geometry. Oklahoma Math Day INSTRUCTIONS:

It is primarily checking of the code and/or manually reviewing the code or document to find errors This type of testing can be used by the developer

Software Engineering Fall 2015 (CSC 4350/6350) TR. 5:30 pm 7:15 pm. Rao Casturi 11/10/2015

Testing: Test design and testing process

Sample Question Paper. Software Testing (ETIT 414)

Software Engineering Fall 2014

MTAT : Software Testing

Facts About Testing. Cost/benefit. Reveal faults. Bottom-up. Testing takes more than 50% of the total cost of software development

Part I: Preliminaries 24

Software Testing. Software Testing. in the textbook. Chapter 8. Verification and Validation. Verification Techniques

A Theorem of Ramsey- Ramsey s Number

Unit 7 Number System and Bases. 7.1 Number System. 7.2 Binary Numbers. 7.3 Adding and Subtracting Binary Numbers. 7.4 Multiplying Binary Numbers

Introduction. Easy to get started, based on description of the inputs

Part 5. Verification and Validation

Points Addressed in this Lecture. Standard form of Boolean Expressions. Lecture 4: Logic Simplication & Karnaugh Map


Software Testing for Developer Development Testing. Duvan Luong, Ph.D. Operational Excellence Networks

CS6702 GRAPH THEORY AND APPLICATIONS 2 MARKS QUESTIONS AND ANSWERS

Software Verification and Validation. Prof. Lionel Briand Ph.D., IEEE Fellow

Introduction to Software Testing Chapter 4 Input Space Partition Testing

People tell me that testing is

STUDENT OUTLINE. Lesson 8: Structured Programming, Control Structures, if-else Statements, Pseudocode

Exercises Software Development I. 02 Algorithm Testing & Language Description Manual inspection, test plan, grammar, metasyntax notations (BNF, EBNF)

UNIVERSITY OF MUMBAI T.Y.B.Sc. INFORMATION TECHNOLOGY) (Semester V) (Practical) EXAMINATION OCTOBER 2014 SOFTWARE TESTING Seat No. : Max.

FIGURES FOR SOLUTIONS TO SELECTED EXERCISES. V : Introduction to non Euclidean geometry

Software Quality Assurance Dynamic Test

Theme 2 Program Design and Testing

MTAT : Software Testing

PESIT Bangalore South Campus SOLUTION

Software Testing. Minsoo Ryu. Hanyang University. Real-Time Computing and Communications Lab., Hanyang University

Clustering. (Part 2)

Software Engineering Software Testing Techniques

UNIT-4 Black Box & White Box Testing

02157 Functional Programming. Michael R. Ha. Disjoint Unions and Higher-order list functions. Michael R. Hansen

Chapter 9. Software Testing

Functional Specifications Document

Dataflow Testing. Chapter 10!

CSCE 747 Software Testing and Quality Assurance

Transcription:

What is Testing? Software Testing Many people understand many definitions of testing :. Testing is the process of demonstrating that errors are not present.. The purpose of testing is to show that a program performs its intended functions correctly. 3. Testing is the process of establishing confidence that a program does what it is supposed to do. These definitions are incorrect.

A more appropriate definition is: Testing is the process of executing a program with the intent of finding errors. 3

Why should We Test? Although software testing is itself an expensive activity, yet launching of software without testing may lead to cost potentially much higher than that of testing, specially in systems where human safety is involved. In the software life cycle the earlier the errors are discovered and removed, the lower is the cost of their removal. 4

Who should Do the Testing? o Testing requires the developers to find errors from their software. o It is difficult for software developer to point out errors from own creations. o Many organisations have made a distinction between development and testing phase by making different people responsible for each phase. 5

What should We Test? We should test the program s responses to every possible input. It means, we should test for all valid and invalid inputs. Suppose a program requires two 8 bit integers as inputs. Total possible combinations are 8 x 8. If only one second it required to execute one set of inputs, it may take 8 hours to test all combinations. Practically, inputs are more than two and size is also more than 8 bits. We have also not considered invalid inputs where so many combinations are possible. Hence, complete testing is just not possible, although, we may wish to do so. 6

Fig. : Control flow graph 7

The number of paths in the example of Fig. are 0 4 or 00 trillions. It is computed from 5 0 + 5 9 + 5 8 + + 5 ; where 5 is the number of paths through the loop body. If only 5 minutes are required to test one test path, it may take approximately one billion years to execute every path. 8

Some Terminologies Software Testing Error, Mistake, Bug, Fault and Failure People make errors. A good synonym is mistake. This may be a syntax error or misunderstanding of specifications. Sometimes, there are logical errors. When developers make mistakes while coding, we call these mistakes bugs. A fault is the representation of an error, where representation is the mode of expression, such as narrative text, data flow diagrams, ER diagrams, source code etc. Defect is a good synonym for fault. A failure occurs when a fault executes. A particular fault may cause different failures, depending on how it has been exercised. 9

Test, Test Case and Test Suite Test and Test case terms are used interchangeably. In practice, both are same and are treated as synonyms. Test case describes an input description and an expected output description. Test Case ID Section-I (Before Execution) Purpose : Pre condition: (If any) Inputs: Section-II (After Execution) Execution History: Result: If fails, any possible reason (Optional); Expected Outputs: Post conditions: Written by: Date: Any other observation: Any suggestion: Run by: Date: Fig. : Test case template The set of test cases is called a test suite. Hence any combination of test cases may generate a test suite. 0

Verification and Validation Verification is the process of evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase. Validation is the process of evaluating a system or component during or at the end of development process to determine whether it satisfies the specified requirements. Testing= Verification+Validation

Alpha, Beta and Acceptance Testing The term Acceptance Testing is used when the software is developed for a specific customer. A series of tests are conducted to enable the customer to validate all requirements. These tests are conducted by the end user / customer and may range from adhoc tests to well planned systematic series of tests. The terms alpha and beta testing are used when the software is developed as a product for anonymous customers. Alpha Tests are conducted at the developer s site by some potential customers. These tests are conducted in a controlled environment. Alpha testing may be started when formal testing process is near completion. Beta Tests are conducted by the customers / end users at their sites. Unlike alpha testing, developer is not present here. Beta testing is conducted in a real environment that cannot be controlled by the developer.

Functional Testing Software Testing Input domain Output domain Input test data System under test Output test data Fig. 3: Black box testing 3

Boundary Value Analysis Consider a program with two input variables x and y. These input variables have specified boundaries as: a x b c y d Input domain d y c a b x Fig.4: Input domain for program having two input variables 4

The boundary value analysis test cases for our program with two inputs variables (x and y) that may have any value from 00 to 300 are: (00,00), (00,0), (00,00), (00,), (00,300), (00,00), (0,00), (,00) and (300,00). This input domain is shown in Fig. 8.5. Each dot represent a test case and inner rectangle is the domain of legitimate inputs. Thus, for a program of n variables, boundary value analysis yield 4n + test cases. y 400 300 00 00 Input domain 0 00 00 300 400 x Fig. 5: Input domain of two variables x and y with boundaries [00,300] each 5

Example- 8.I Consider a program for the determination of the nature of roots of a quadratic equation. Its input is a triple of positive integers (say a,b,c) and values may be from interval [0,00]. The program output may have one of the following words. [Not a quadratic equation; Real roots; Imaginary roots; Equal roots] Design the boundary value test cases. 6

Solution Quadratic equation will be of type: ax +bx+c=0 Roots are real if (b -4ac)>0 Roots are imaginary if (b -4ac)<0 Roots are equal if (b -4ac)=0 Equation is not quadratic if a=0 7

The boundary value test cases are : Test Case a b c Expected output 0 Not Quadratic Real Roots 3 Imaginary Roots 4 Imaginary Roots 5 00 Imaginary Roots 6 0 Imaginary Roots 7 Imaginary Roots 8 Imaginary Roots 9 00 Equal Roots 0 0 Real Roots Real Roots Imaginary Roots 3 00 Imaginary Roots 8

Example 8. Consider a program for determining the Previous date. Its input is a triple of day, month and year with the values in the range month day 3 900 year 05 The possible outputs would be Previous date or invalid input date. Design the boundary value test cases. 9

Solution The Previous date program takes a date as input and checks it for validity. If valid, it returns the previous date as its output. With single fault assumption theory, 4n+ test cases can be designed and which are equal to 3. 0

The boundary value test cases are: Software Testing Test Case Month Day Year Expected output 6 5 900 4 June, 900 6 5 90 4 June, 90 3 6 5 96 4 June, 96 4 6 5 04 4 June, 04 5 6 5 05 4 June, 05 6 6 96 3 May, 96 7 6 96 June, 96 8 6 30 96 9 June, 96 9 6 3 96 Invalid date 0 5 96 4 January, 96 5 96 4 February, 96 5 96 4 November, 96 3 5 96 4 December, 96

Example 8.3 Consider a simple program to classify a triangle. Its inputs is a triple of positive integers (say x, y, z) and the date type for input parameters ensures that these will be integers greater than 0 and less than or equal to 00. The program output may be one of the following words: [Scalene; Isosceles; Equilateral; Not a triangle] Design the boundary value test cases.

Solution The boundary value test cases are shown below: Test case x y z Expected Output Isosceles Isosceles 3 Equilateral 4 Isosceles 5 00 Not a triangle 6 Isosceles 7 Isosceles 8 Isosceles 9 00 Not a triangle 0 Isosceles Isosceles Isosceles 3 00 Not a triangle 3

Robustness testing Software Testing It is nothing but the extension of boundary value analysis. Here, we would like to see, what happens when the extreme values are exceeded with a value slightly greater than the maximum, and a value slightly less than minimum. It means, we want to go outside the legitimate boundary of input domain. This extended form of boundary value analysis is called robustness testing and shown in Fig. 6 There are four additional test cases which are outside the legitimate input domain. Hence total test cases in robustness testing are 6n+, where n is the number of input variables. So, 3 test cases are: (00,), (00,00), (00,0), (00,00), (00,), (00,300) (00,30), (,00), (00,00), (0,00), (,00), (300,00), (30,00) 4

y 400 300 00 00 0 00 00 300 400 x Fig. 8.6: Robustness test cases for two variables x and y with range [00,300] each 5

Worst-case testing Software Testing If we reject single fault assumption theory of reliability and may like to see what happens when more than one variable has an extreme value. In electronic circuits analysis, this is called worst case analysis. It is more thorough in the sense that boundary value test cases are a proper subset of worst case test cases. It requires more effort. Worst case testing for a function of n variables generate 5 n test cases as opposed to 4n+ test cases for boundary value analysis. Our two variables example will have 5 =5 test cases and are given in table. 6

Table : Worst cases test inputs for two variables example Test case number x Inputs y Test case number x Inputs y 00 00 4 00 00 0 5 00 300 3 00 00 6 00 4 00 7 0 5 00 300 8 00 6 0 00 9 7 0 0 0 300 8 0 00 300 00 9 0 300 0 0 0 300 3 300 00 00 00 4 300 00 0 5 300 300 3 00 00 -- 7

Example - 8.4 Consider the program for the determination of nature of roots of a quadratic equation as explained in example 8.. Design the Robust test case and worst test cases for this program. 8

Solution Robust test cases are 6n+. Hence, in 3 variable input cases total number of test cases are 9 as given on next slide: 9

Test case a b c Expected Output - Invalid input` 0 Not quadratic equation 3 Real roots 4 Imaginary roots 5 Imaginary roots 6 00 Imaginary roots 7 0 Invalid input 8 - Invalid input 9 0 Imaginary roots 0 Imaginary roots Imaginary roots 00 Equal roots 3 0 Invalid input 4 - Invalid input 5 0 Real roots 6 Real roots 7 Imaginary roots 8 00 Imaginary roots 9 0 Invalid input 30

In case of worst test case total test cases are 5 n. Hence, 5 test cases will be generated in worst test cases. The worst test cases are given below: Test Case a b c Expected output 0 0 0 Not Quadratic 0 0 Not Quadratic 3 0 0 Not Quadratic 4 0 0 Not Quadratic 5 0 0 00 Not Quadratic 6 0 0 Not Quadratic 7 0 Not Quadratic 8 0 Not Quadratic 9 0 Not Quadratic 0 0 00 Not Quadratic 0 0 Not Quadratic 0 Not Quadratic 3 0 Not Quadratic 4 0 Not Quadratic 3

Test Case A b c Expected output 5 0 00 Not Quadratic 6 0 0 Not Quadratic 7 0 Not Quadratic 8 0 Not Quadratic 9 0 Not Quadratic 0 0 00 Not Quadratic 0 00 0 Not Quadratic 0 00 Not Quadratic 3 0 00 Not Quadratic 4 0 00 Not Quadratic 5 0 00 00 Not Quadratic 6 0 0 Equal Roots 7 0 Imaginary 8 0 Imaginary 9 0 Imaginary 30 0 00 Imaginary 3 0 Real Roots 3

Test Case A b C Expected output 3 Imaginary 33 Imaginary 34 Imaginary 35 00 Imaginary 36 0 Real Roots 37 Real Roots 38 Real Roots 39 Real Roots 40 00 Real Roots 4 0 Real Roots 4 Real Roots 43 Real Roots 44` Real Roots 45 00 Real Roots 46 00 0 Real Roots 47 00 Real Roots 48 00 Real Roots 33

Test Case A b C Expected output 49 00 Real Roots 00 00 Real Roots 5 0 0 Equal Roots 5 0 Imaginary 53 0 Imaginary 54 0 Imaginary 55 0 00 Imaginary 56 0 Real Roots 57 Imaginary 58 Imaginary 59 Imaginary 60 00 Imaginary 6 0 Real Roots 6 Real Roots 63 Imaginary 64 Imaginary 65 00 Imaginary 34

Test Case A b C Expected output 66 0 Real Roots 67 Real Roots 68 Imaginary 69 Imaginary 70 00 Imaginary 7 00 0 Real Roots 7 00 Real Roots 73 00 Equal Roots 74 00 Imaginary 75 00 00 Imaginary 76 0 0 Equal Roots 77 0 Imaginary 78 0 Imaginary 79 0 Imaginary 80 0 00 Imaginary 8 0 Real Roots 8 Imaginary 35

Test Case A b C Expected output 83 Imaginary 84 Imaginary 85 00 Imaginary 86 0 Real Roots 87 Real Roots 88 Imaginary 89 Imaginary 90 00 Imaginary 9 0 Real Roots 9 Real Roots 93 Imaginary Roots 94 Imaginary 95 00 Imaginary 96 00 0 Real Roots 97 00 Real Roots 98 00 Imaginary 00 Imaginary 00 00 00 Imaginary 36

Test Case A b C Expected output 0 00 0 0 Equal Roots 0 00 0 Imaginary 03 00 0 Imaginary 04 00 0 Imaginary 05 00 0 00 Imaginary 06 00 0 Real Roots 07 00 Imaginary 08 00 Imaginary 09 00 Imaginary 0 00 00 Imaginary 00 0 Real Roots 00 Real Roots 3 00 Imaginary 4 00 Imaginary 5 00 00 Imaginary 6 00 0 Real Roots 7 00 Real Roots 8 00 Imaginary 37

Test Case A b C Expected output 9 00 Imaginary 0 00 00 Imaginary 00 00 0 Real Roots 00 00 Real Roots 3 00 00 Imaginary 4 00 00 Imaginary 5 00 00 00 Imaginary 38

Example 8.5 Consider the program for the determination of previous date in a calendar as explained in example 8.. Design the robust and worst test cases for this program. 39

Solution Robust test cases are 6n+. Hence total 9 robust test cases are designed and are given on next slide. 40

Test case Month Day Year Expected Output 6 5 8 Invalid date (outside range) 6 5 900 4 June, 900 3 6 5 90 4 June, 90 4 6 5 96 4 June, 96 5 6 5 04 4 June, 04 6 6 5 05 4 June, 05 7 6 5 06 Invalid date (outside range) 8 6 0 96 Invalid date 9 6 96 3 May, 96 0 6 96 June, 96 6 30 96 9 June, 96 6 3 96 Invalid date 3 4 6 0 3 5 96 96 Invalid date Invalid date 5 5 96 4 January, 96 6 7 5 5 96 96 4 February, 96 4 November, 96 8 5 96 4 December, 96 9 3 5 96 Invalid date 4

In case of worst test case total test cases are 5 n. Hence, 5 test cases will be generated in worst test cases. The worst test cases are given below: Test Case Month Day Year Expected output 900 3 December, 8 90 3 December, 900 3 96 3 December, 96 4 04 3 December, 03 5 05 3 December, 04 6 900 January, 900 7 90 January, 90 8 96 January, 96 9 04 January, 04 0 05 January, 05 5 900 4 January, 900 5 90 4 January, 90 3 5 96 4 January, 96 4 5 04 4 January, 04 4

Test Case A b c Expected output 5 5 05 4 January, 05 6 30 900 9 January, 900 7 30 90 9 January, 90 8 30 96 9 January, 96 9 30 04 9 January, 04 0 30 05 9 January, 05 3 900 30 January, 900 3 90 30 January, 90 3 3 96 30 January, 96 4 3 04 30 January, 04 5 3 05 30 January, 05 6 900 3 January, 900 7 90 3 January, 90 8 96 3 January, 96 9 04 3 January, 04 30 05 3 January, 05 3 900 February, 900 43

Test Case Month Day Year Expected output 3 90 February, 90 33 96 February, 96 34 04 February, 04 35 05 February, 05 36 5 900 4 February, 900 37 5 90 4 February, 90 38 5 96 4 February, 96 39 5 04 4 February, 04 40 5 05 4 February, 05 4 30 900 Invalid date 4 30 90 Invalid date 43 30 96 Invalid date 44 30 04 Invalid date 45 30 05 Invalid date 46 3 900 Invalid date 47 3 90 Invalid date 48 3 96 Invalid date 44

Test Case Month Day Year Expected output 49 3 04 Invalid date 3 05 Invalid date 5 6 900 3 May, 900 5 6 90 3 May, 90 53 6 96 3 May, 96 54 6 04 3 May, 04 55 6 05 3 May, 05 56 6 900 June, 900 57 6 90 June, 90 58 6 96 June, 96 59 6 04 June, 04 60 6 05 June, 05 6 6 5 900 4 June, 900 6 6 5 90 4 June, 90 63 6 5 96 4 June, 96 64 6 5 04 4 June, 04 65 6 5 05 4 June, 05 45

Test Case Month Day Year Expected output 66 6 30 900 9 June, 900 67 6 30 90 9 June, 90 68 6 30 96 9 June, 96 69 6 30 04 9 June, 04 70 6 30 05 9 June, 05 7 6 3 900 Invalid date 7 6 3 90 Invalid date 73 6 3 96 Invalid date 74 6 3 04 Invalid date 75 76 6 3 05 900 Invalid date 3 October, 900 77 90 3 October, 90 78 96 3 October, 96 79 04 3 October, 04 80 05 3 October, 05 8 900 November, 900 8 90 November, 90 46

Test Case Month Day Year Expected output 83 96 November, 96 84 04 November, 04 85 05 November, 05 86 5 900 4 November, 900 87 5 90 4 November, 90 88 5 96 4 November, 96 89 5 04 4 November, 04 90 5 05 4 November, 05 9 30 900 9 November, 900 9 30 90 9 November, 90 93 30 96 9 November, 96 94 30 04 9 November, 04 95 30 05 9 November, 05 96 3 900 Invalid date 97 3 90 Invalid date 98 3 96 Invalid date 3 04 Invalid date 00 3 05 Invalid date 47

Test Case Month Day Year Expected output 0 900 30 November, 900 0 90 30 November, 90 03 96 30 November, 96 04 04 30 November, 04 05 05 30 November, 05 06 900 December, 900 07 90 December, 90 08 96 December, 96 09 04 December, 04 0 05 December, 05 5 900 4 December, 900 5 90 4 December, 90 3 5 96 4 December, 96 4 5 04 4 December, 04 5 5 05 4 December, 05 6 30 900 9 December, 900 7 30 90 9 December, 90 8 30 96 9 December, 96 48

Test Case Month Day Year Expected output 9 30 04 9 December, 04 0 30 05 9 December, 05 3 900 30 December, 900 3 90 30 December, 90 3 3 96 30 December, 96 4 3 04 30 December, 04 5 3 05 30 December, 05 49

Example 8.6 Consider the triangle problem as given in example 8.3. Generate robust and worst test cases for this problem.

Solution Robust test cases are given on next slide. 5

` x y z Expected Output 0 Invalid input` Isosceles 3 Isosceles 4 Equilateral 5 Isosceles 6 00 Not a triangle 7 0 Invalid input 8 0 Invalid input 9 Isosceles 0 Isosceles Isosceles 00 Not a triangle 3 0 Invalid input 4 0 Invalid input 5 Isosceles 6 Isosceles 7 Isosceles 8 00 Not a triangle 9 00 Invalid input 5

Worst test cases are 5 and are given below: Test Case x y z Expected output Equilateral Not a triangle 3 Not a triangle 4 Not a triangle 5 00 Not a triangle 6 Not a triangle 7 Isosceles 8 9 Not a triangle Not a triangle 0 00 Not a triangle Not a triangle Not a triangle 3 Isosceles 4 Not a triangle 53

Test Case A b c Expected output 5 00 Not a triangle 6 Not a triangle 7 Not a triangle 8 Not a triangle 9 Isosceles 0 00 Not a triangle 00 Not a triangle 00 Not a triangle 3 00 Not a triangle 4 00 Not a triangle 5 00 00 Isosceles 6 Not a triangle 7 Isosceles 8 Not a triangle 9 Not a triangle 30 00 Not a triangle 3 Isosceles 54

Test Case A b C Expected output 3 Equilateral 33 Not a triangle 34 Not a triangle 35 00 Not a triangle 36 Not a triangle 37 Not a triangle 38 Isosceles 39 Not a triangle 40 00 Not a triangle 4 Not a triangle 4 Not a triangle 43 Not a triangle 44 Isosceles 45 00 Scalene 46 00 Not a triangle 47 00 Not a triangle 48 00 Not a triangle 55

Test Case A b C Expected output 49 00 Scalene 00 Isosceles 5 00 Not a triangle 5 Not a triangle 53 Isosceles 54 Not a triangle 55 Not a triangle 56 00 Not a triangle 57 Not a triangle 58 Isosceles 59 Not a triangle 60 Not a triangle 6 00 Isosceles 6 Isosceles 63 Equilateral 64 Isosceles 65 Not a triangle 56

Test Case A B C Expected output 66 Not a triangle 67 Not a triangle 68 Isosceles 69 Isosceles 70 00 Scalene 7 00 Not a triangle 7 00 Not a triangle 73 00 Not a triangle 74 00 Scalene 75 00 00 Isosceles 76 Not a triangle 77 Not a triangle 78 Not a triangle 79 Isosceles 80 00 Not a triangle 8 Not a triangle 8 Not a triangle 57

Test Case A b C Expected output 83 Not a triangle 84 Isosceles 85 00 Scalene 86 Not a triangle 87 Not a triangle 88 Isosceles 89 Isosceles 90 00 Scalene 9 Isosceles 9 Isosceles 93 Isosceles 94 Equilateral 95 00 Isosceles 96 00 Not a triangle 97 00 Scalene 98 00 Scalene 00 Isosceles 00 00 00 Isosceles 58

Test Case A b C Expected output 0 00 Not a triangle 0 00 Not a triangle 03 00 Not a triangle 04 00 Not a triangle 05 00 00 Isosceles 06 00 Not a triangle 07 00 Not a triangle 08 00 Not a triangle 09 00 Scalene 0 00 00 Isosceles 00 Not a triangle 00 Not a triangle 3 00 Not a triangle 4 00 Scalene 5 00 00 Isosceles 6 00 Not a triangle 7 00 Scalene 8 00 Scalene 59

Test Case A b C Expected output 9 00 Isosceles 0 00 00 Isosceles 00 00 Isosceles 00 00 Isosceles 3 00 00 Isosceles 4 00 00 Isosceles 5 00 00 00 Equilateral 60

Equivalence Class Testing Software Testing In this method, input domain of a program is partitioned into a finite number of equivalence classes such that one can reasonably assume, but not be absolutely sure, that the test of a representative value of each class is equivalent to a test of any other value. Two steps are required to implementing this method:. The equivalence classes are identified by taking each input condition and partitioning it into valid and invalid classes. For example, if an input condition specifies a range of values from to 9, we identify one valid equivalence class [<item<9]; and two invalid equivalence classes [item<] and [item>9].. Generate the test cases using the equivalence classes identified in the previous step. This is performed by writing test cases covering all the valid equivalence classes. Then a test case is written for each invalid equivalence class so that no test contains more than one invalid class. This is to ensure that no two invalid classes mask each other. 6

Invalid input Valid inputs System under test Outputs Input domain Output domain Fig. 7: Equivalence partitioning Most of the time, equivalence class testing defines classes of the input domain. However, equivalence classes should also be defined for output domain. Hence, we should design equivalence classes based on input and output domain. 6

Example 8.7 Consider the program for the determination of nature of roots of a quadratic equation as explained in example 8.. Identify the equivalence class test cases for output and input domains. 63

Solution Output domain equivalence class test cases can be identified as follows: O ={<a,b,c>:not a quadratic equation if a = 0} O ={<a,b,c>:real roots if (b -4ac)>0} O ={<a,b,c>:imaginary roots if (b -4ac)<0} O ={<a,b,c>:equal roots if (b -4ac)=0}` The number of test cases can be derived form above relations and shown below: Test case a b c Expected output 0 Not a quadratic equation Real roots 3 Imaginary roots 4 00 Equal roots 64

We may have another set of test cases based on input domain. I = {a: a = 0} I = {a: a < 0} I 3 = {a: a 00} I 4 = {a: a > 00} I 5 = {b: 0 b 00} I 6 = {b: b < 0} I 7 = {b: b > 00} I 8 = {c: 0 c 00} I 9 = {c: c < 0} I 0 ={c: c > 00} 65

Test Case a b c Expected output 0 Not a quadratic equation - Invalid input 3 Imaginary Roots 4 0 invalid input 5 Imaginary Roots 6 - invalid input 7 0 invalid input 8 Imaginary Roots 9 - invalid input 0 0 invalid input Here test cases 5 and 8 are redundant test cases. If we choose any value other than nominal, we may not have redundant test cases. Hence total test cases are 0+4=4 for this problem. 66

Example 8.8 Consider the program for determining the previous date in a calendar as explained in example 8.3. Identify the equivalence class test cases for output & input domains. 67

Solution Output domain equivalence class are: O ={<D,M,Y>: Previous date if all are valid inputs} O ={<D,M,Y>: Invalid date if any input makes the date invalid} Test case M D Y Expected output 6 5 96 4 June, 96 6 3 96 Invalid date 68

We may have another set of test cases which are based on input domain. I ={month: m } I ={month: m < } I 3 ={month: m > } I 4 ={day: D 3} I 5 ={day: D < } I 6 ={day: D > 3} I 7 ={year: 900 Y 05} I 8 ={year: Y < 900} I 9 ={year: Y > 05} 69

Inputs domain test cases are : Test Case M D Y Expected output 6 5 96 4 June, 96-5 96 Invalid input 3 3 5 96 invalid input 4 6 5 96 4 June, 96 5 6-96 invalid input 6 6 3 96 invalid input 7 6 5 96 4 June, 96 8 6 5 8 invalid input (Value out of range) 9 6 5 06 invalid input (Value out of range) 70

Example 8.9 Consider the triangle problem specified in a example 8.3. Identify the equivalence class test cases for output and input domain. 7

Solution Output domain equivalence classes are: O ={<x,y,z>: Equilateral triangle with sides x,y,z} O ={<x,y,z>: Isosceles triangle with sides x,y,z} O ={<x,y,z>: Scalene triangle with sides x,y,z} O ={<x,y,z>: Not a triangle with sides x,y,z} The test cases are: Test case x y z Expected Output Equilateral Isosceles 3 00 Scalene 4 00 Not a triangle 7

Input domain based classes are: I ={x: x < } I ={x: x > 00} I 3 ={x: x 00} I 4 ={y: y < } I 5 ={y: y > 00} I 6 ={y: y 00} I 7 ={z: z < } I 8 ={z: z > 00} I 9 ={z: z 00} 73

Some inputs domain test cases can be obtained using the relationship amongst x,y and z. I 0 ={< x,y,z >: x = y = z} I ={< x,y,z >: x = y, x z} I ={< x,y,z >: x = z, x y} I 3 ={< x,y,z >: y = z, x y} I 4 ={< x,y,z >: x y, x z, y z} I 5 ={< x,y,z >: x = y + z} I 6 ={< x,y,z >: x > y +z} I 7 ={< x,y,z >: y = x +z} I 8 ={< x,y,z >: y > x + z} I 9 ={< x,y,z >: z = x + y} I 0 ={< x,y,z >: z > x +y} 74

Test cases derived from input domain are: Test case x y z Expected Output 0 Invalid input 0 Invalid input 3 Equilateral 4 0 Invalid input 5 0 Invalid input 6 Equilateral 7 0 Invalid input 8 0 Invalid input 9 Equilateral 0 60 60 60 Equilateral 60 Isosceles 60 Isosceles 3 60 Isosceles 75

Test case x y z Expected Output 4 00 Scalene 5 00 Not a triangle 6 00 5 Not a triangle 7 00 Not a triangle 8 00 5 Not a triangle 9 00 Not a triangle 0 5 00 Not a triangle 76

Decision Table Based Testing Condition Stub Entry True False C True False True False C C 3 True False True False True False --- Action a Stub a a 3 a 4 Table : Decision table terminology 77

Test case design C :x,y,z are sides of a triangle? N Y C :x = y? -- Y N C 3 :x = z? C 4 :y = z? a : Not a triangle a : Scalene -- -- Y N Y N Y N Y N Y N Y N a 3 : Isosceles a 4 : Equilateral a 5 : Impossible Table 3: Decision table for triangle problem 78

Conditions C : x < y + z? F T T T T T T T T T T C : y < x + z? -- F T T T T T T T T T C 3 : z < x + y? -- -- F T T T T T T T T C 4 : x = y? -- -- -- T T T T F F F F C 5 : x = z? -- -- -- T T F F T T F F C 6 : y = z? -- -- -- T F T F T F T F a : Not a triangle a : Scalene a 3 : Isosceles a 4 : Equilateral a 5 : Impossible Table 4: Modified decision table 79

Example 8.0 Consider the triangle program specified in example 8.3. Identify the test cases using the decision table of Table 4. 80

Solution There are eleven functional test cases, three to fail triangle property, three impossible cases, one each to get equilateral, scalene triangle cases, and three to get on isosceles triangle. The test cases are given in Table 5. Test case x y z Expected Output 4 Not a triangle 4 Not a triangle 3 4 Not a triangle 4 5 5 5 Equilateral 5??? Impossible 6??? Impossible 7 3 Isosceles 8??? Impossible 9 3 Isosceles 0 3 Isosceles 3 4 5 Scalene Test cases of triangle problem using decision table 8

Example 8. Consider a program for the determination of Previous date. Its input is a triple of day, month and year with the values in the range month day 3 900 year 05 The possible outputs are Previous date and Invalid date. Design the test cases using decision table based testing. 8

Solution The input domain can be divided into following classes: I = {M : month has 30 days} I = {M : month has 3 days except March, August and January} I 3 = {M 3 : month is March} I 4 = {M 4 : month is August} I 5 = {M 5 : month is January} I 6 = {M 6 : month is February} I 7 = {D : day = } I 8 = {D : day 8} I 9 = {D 3 : day = 9} I 0 ={D 4 : day = 30} I ={D 5 : day = 3} I ={Y : year is a leap year} I 3 ={Y : year is a common year} 83

The decision table is given below: Software Testing Sr.No. 3 4 5 6 7 8 9 0 3 4 5 C : Months in M M M M M M M M M M M M M M M C : days in D D D D D 3 D 3 D 4 D 4 D 5 D 5 D D D D D 3 C 3 : year in Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y a : Impossible a : Decrement day a 3 : Reset day to 3 a 4 : Reset day to 30 a 5 : Reset day to 9 a 6 : Reset day to 8 a 7 : decrement month a 8 : Reset month to December a 9 : Decrement year 84

Sr.No. 6 7 8 9 0 3 4 5 6 7 8 9 30 C : Months in M M M M M M 3 M 3 M 3 M 3 M 3 M 3 M 3 M 3 M 3 M 3 C : days in D 3 D 4 D 4 D 5 D 5 D D D D D 3 D 3 D 4 D 4 D 5 D 5 C 3 : year in Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y a : Impossible a : Decrement day a 3 : Reset day to 3 a 4 : Reset day to 30 a 5 : Reset day to 9 a 6 : Reset day to 8 a 7 : decrement month a 8 : Reset month to December a 9 : Decrement year 85

Sr.No. 3 3 33 34 35 36 37 38 39 40 4 4 43 44 45 C : Months in M 4 M 4 M 4 M 4 M 4 M 4 M 4 M 4 M 4 M 4 M 5 M 5 M 5 M 5 M 5 C : days in D D D D D 3 D 3 D 4 D 4 D 5 D 5 D D D D D 3 C 3 : year in Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y a : Impossible a : Decrement day a 3 : Reset day to 3 a 4 : Reset day to 30 a 5 : Reset day to 9 a 6 : Reset day to 8 a 7 : decrement month a 8 : Reset month to December a 9 : Decrement year 86

Sr.No. 46 47 48 49 5 5 53 54 55 56 57 58 59 60 C : Months in M 5 M 5 M 5 M 5 M 5 M 6 M 6 M 6 M 6 M 6 M 6 M 6 M 6 M 6 M 6 C : days in D 3 D 4 D 4 D 5 D 5 D D D D D 3 D 3 D 4 D 4 D 5 D 5 C 3 : year in Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y a : Impossible a : Decrement day a 3 : Reset day to 3 a 4 : Reset day to 30 a 5 : Reset day to 9 a 6 : Reset day to 8 a 7 : decrement month a 8 : Reset month to December a 9 : Decrement year 87

Test case Month Day Year Expected output June 964 3 May, 964 June 96 3 May, 96 3 June 5 964 4 June, 964 4 June 5 96 4 June, 96 5 June 9 964 8 June, 964 6 June 9 96 8 June, 96 7 June 30 964 9 June, 964 8 June 30 96 9 June, 96 9 June 3 964 Impossible 0 June 3 96 Impossible May 964 30 April, 964 May 96 30 April, 96 3 May 5 964 4 May, 964 4 May 5 96 4 May, 96 5 May 9 964 8 May, 964 88

Test case Month Day Year Expected output 6 May 9 96 8 May, 96 7 May 30 964 9 May, 964 8 May 30 96 9 May, 96 9 May 3 964 30 May, 964 0 May 3 96 30 May, 96 March 964 9 February, 964 March 96 8 February, 96 3 March 5 964 4 March, 964 4 March 5 96 4 March, 96 5 March 9 964 8 March, 964 6 March 9 96 8 March, 96 7 March 30 964 9 March, 964 8 March 30 96 9 March, 96 9 March 3 964 30 March, 964 30 March 3 96 30 March, 96 89

Test case Month Day Year Expected output 3 August 964 3 July, 96 3 August 96 3 July, 964 33 August 5 964 4 August, 964 34 August 5 96 4 August, 96 35 August 9 964 8 August, 964 36 August 9 96 8 August, 96 37 August 30 964 9 August, 964 38 August 30 96 9 August, 96 39 August 3 964 30 August, 964 40 August 3 96 30 August, 96 4 January 964 3 December, 964 4 January 96 3 December, 96 43 January 5 964 4 January, 964 44 January 5 96 4 January, 96 45 January 9 964 8 January, 964 90

Test case Month Day Year Expected output 46 January 9 96 8 January, 96 47 January 30 964 9 January, 964 48 January 30 96 9 January, 96 49 January 3 964 30 January, 964 January 3 96 30 January, 96 5 February 964 3 January, 964 5 February 96 3 January, 96 53 February 5 964 4 February, 964 54 February 5 96 4 February, 96 55 February 9 964 8 February, 964 56 February 9 96 Impossible 57 February 30 964 Impossible 58 February 30 96 Impossible 59 February 3 964 Impossible 60 February 3 96 Impossible 9

Cause Effect Graphing Technique Consider single input conditions Software Testing do not explore combinations of input circumstances Steps. Causes & effects in the specifications are identified. A cause is a distinct input condition or an equivalence class of input conditions. An effect is an output condition or a system transformation.. The semantic content of the specification is analysed and transformed into a boolean graph linking the causes & effects. 3. Constraints are imposed 4. graph limited entry decision table Each column in the table represent a test case. 5. The columns in the decision table are converted into test cases. 9

The basic notation for the graph is shown in fig. 8 Fig.8. 8 : Basic cause effect graph symbols 93

Myers explained this effectively with following example. The characters in column must be an A or B. The character in column must be a digit. In this situation, the file update is made. If the character in column is incorrect, message x is issued. If the character in column is not a digit, message y is issued. The causes are c : character in column is A c : character in column is B c 3 : character in column is a digit and the effects are e : update made e : message x is issued e 3 : message y is issued 94

Fig. 9: Sample cause effect graph 95

The E constraint states that it must always be true that at most one of c or c can be (c or c cannot be simultaneously). The I constraint states that at least one of c, c and c 3 must always be (c, c and c 3 cannot be 0 simultaneously). The O constraint states that one, and only one, of c and c must be. The constraint R states that, for c to be, c must be (i.e. it is impossible for c to be and c to be 0), 96

Fig. 0: Constraint symbols 97

Fig. : Symbol for masks constraint 98

Fig. : Sample cause effect graph with exclusive constraint

Example 8. Consider the triangle problem specified in the example 8.3. Draw the Cause effect graph and identify the test cases. 00

Solution The causes are c : side x is less than sum of sides y and z c : side y is less than sum of sides x and y c 3 : side z is less than sum of sides x and y c 4 : side x is equal to side y c 5 : side x is equal to side z c 6 : side y is equal to side z and effects are e : Not a triangle e : Scalene triangle e 3 : Isosceles triangle e 4 : Equilateral triangle e 5 : Impossible stage 0

The cause effect graph is shown in fig. 3 and decision table is shown in table 6. The test cases for this problem are available in Table 5. Conditions C : x < y + z? 0 C : y < x + z? C 3 : z < x + y? C 4 : x = y? C 5 : x = z? C 6 : y = z? e : Not a triangle e : Scalene e 3 : Isosceles e 4 : Equilateral e 5 : Impossible 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Table 6: Decision table 0

Fig. 3: Cause effect graph of triangle problem 03

Structural Testing A complementary approach to functional testing is called structural / white box testing. It permits us to examine the internal structure of the program. Path Testing Path testing is the name given to a group of test techniques based on judiciously selecting a set of test paths through the program. If the set of paths is properly chosen, then it means that we have achieved some measure of test thoroughness. This type of testing involves:. generating a set of paths that will cover every branch in the program.. finding a set of test cases that will execute every path in the set of program paths. 04

Flow Graph The control flow of a program can be analysed using a graphical representation known as flow graph. The flow graph is a directed graph in which nodes are either entire statements or fragments of a statement, and edges represents flow of control. Fig. 4: The basic construct of the flow graph 05

06

07

08

09

Fig. 5: Program for previous date problem 0

Fig. 6: Flow graph of previous date problem

DD Path Graph Table 7: Mapping of flow graph nodes and DD path nodes Flow graph nodes to 9 0 3,4 5,6,7 8 9 0 3 DD Path graph corresponding node n n n 3 n 4 n 5 n 6 n 7 n 8 n 9 n 0 n n Remarks There is a sequential flow from node to 9 Decision node, if true go to 3 else go to 44 Decision node, if true go to else go to 9 Decision node, if true go to 3 else go to 5 Sequential nodes and are combined to form new node n 5 Sequential nodes Edges from node 4 to 7 are terminated here Decision node, if true go to 0 else go to 37 Intermediate node with one input edge and one output edge Decision node, if true go to else go to 7 Intermediate node Decision node, if true go to 4 else go to 6 Cont.

Flow graph nodes 4,5 6 7 8,9 30 3,3 33,34,35 36 37 38,39 40,4,4 43 DD Path graph corresponding node n 3 n 4 n 5 n 6 n 7 n 8 n 9 n 0 n n n 3 n 4 Remarks Sequential nodes Two edges from node 5 & 3 are terminated here Two edges from node 6 & are terminated here. Also a decision node Sequential nodes Decision node, if true go to 3 else go to 33 Sequential nodes Sequential nodes Three edge from node 9,3 and 35 are terminated here Decision node, if true go to 38 else go to 40 Sequential nodes Sequential nodes Three edge from node 36,39 and 4 are terminated here Cont. 3

Flow graph nodes 44 45 46 47,48,49, 5 5 53 54 55 56,57 58 59 DD Path graph corresponding node n 5 n 6 n 7 n 8 n 9 n 30 n 3 n 3 n 33 n 34 n 35 n 36 Decision node, if true go to 45 else go to 8. Three edges from 8,43 & 0 are also terminated here. Decision node, if true go to 46 else go to 77 Decision node, if true go to 47 else go to 5 Sequential nodes Remarks Decision node, if true go to 5 else go to 68 Intermediate node with one input edge & one output ege Decision node, if true go to 54 else go to 59 Intermediate node Decision node, if true go to 56 else go to 58 Sequential nodes Two edge from node 57 and 55 are terminated here Decision node, if true go to 60 else go to 63. Two edge from nodes 58 and 53 are terminated. Cont. 4

Flow graph nodes 60,6,6 63,64,65,66 67 68 69,70,7 7,73,74,75 76 77,78,79 80 8 8,83,84 85 86,87 DD Path graph corresponding node n 37 n 38 n 39 n 40 n 4 n 4 n 43 n 44 n 45 n 46 n 47 n 48 n 49 Remarks Sequential nodes Sequential nodes Two edge from node 6 and 66 are terminated here Decision node, if true go to 69 else go to 7 Sequential nodes Sequential nodes Four edges from nodes, 67, 7 and 75 are terminated here. Sequential nodes Two edges from nodes 76 & 79 are terminated here Intermediate node Sequential nodes Two edges from nodes 8 and 84 are terminated here Sequential nodes with exit node 5

Fig. 7: DD path graph of previous date problem 6

Fig. 8: Independent paths of previous date problem 7

Example 8.3 Consider the problem for the determination of the nature of roots of a quadratic equation. Its input a triple of positive integers (say a,b,c) and value may be from interval [0,00]. The program is given in fig. 9. The output may have one of the following words: [Not a quadratic equation; real roots; Imaginary roots; Equal roots] Draw the flow graph and DD path graph. Also find independent paths from the DD Path graph. 8

Cont. 9

Fig. 9: Code of quadratic equation problem 0

Solution Software Testing Fig. 9 (a) : Program flow graph

Fig. 9 (b) : DD Path graph

The mapping table for DD path graph is: Flow graph nodes to 0 3 4,5 6 7 8 9 0, 3,4,5 DD Path graph corresponding node A B C D E F G H I J K L Remarks Sequential nodes Decision node Intermediate node Decision node Sequential node Two edges are combined here Two edges are combined and decision node Intermediate node Decision node Sequential node Decision node Sequential node Cont. 3

Flow graph nodes 6,7,8,9 30 3 3,33 34,35,36 37 38,39 DD Path graph corresponding node M N O P Q R S Remarks Sequential nodes Three edges are combined Decision node Sequential node Sequential node Three edges are combined here Sequential nodes with exit node Independent paths are: (i) ABGOQRS (iii) ABCDFGOQRS (v) ABGHIJNRS (vi) ABGHIKMNRS (ii) ABGOPRS (iv) ABCDEFGOPRS (vi) ABGHIKLNRS 4

Example 8.4 Consider a program given in Fig.8.0 for the classification of a triangle. Its input is a triple of positive integers (say a,b,c) from the interval [,00]. The output may be [Scalene, Isosceles, Equilateral, Not a triangle]. Draw the flow graph & DD Path graph. Also find the independent paths from the DD Path graph. 5

6

Fig. 0 : Code of triangle classification problem 7

Solution : Flow graph of triangle problem is: Fig.8. 0 (a): Program flow graph 8

The mapping table for DD path graph is: Flow graph nodes TO 9 0, 3 4 5, 6, 7 8 9 0, 3, 4 5, 6, 7 DD Path graph corresponding node A B C D E F G H I J K L Remarks Sequential nodes Decision node Decision node Sequential nodes Two edges are joined here Sequential nodes Decision nodes plus joining of two edges Decision node Sequential nodes Decision node Sequential nodes Sequential nodes Cont. 9

Flow graph nodes 8 9 30, 3 DD Path graph corresponding node M N O Three edges are combined here Decision node Sequential nodes Remarks 3, 33, 34 35 36, 37 P Q R Sequential nodes Three edges are combined here Sequential nodes with exit node Fig. 0 (b): DD Path graph 30

DD Path graph is given in Fig. 0 (b) Independent paths are: (i) ABFGNPQR (ii) ABFGNOQR (iii) ABCEGNPQR (iv) ABCDEGNOQR (v) ABFGHIMQR (vi) ABFGHJKMQR (vii)abfghjmqr Fig. 0 (b): DD Path graph 3

Cyclomatic Complexity Software Testing McCabe s cyclomatic metric V(G) = e n + P. For example, a flow graph shown in in Fig. with entry node a and exit node f. Fig. : Flow graph 3

The value of cyclomatic complexity can be calculated as : V(G) = 9 6 + = 5 Here e = 9, n = 6 and P = There will be five independent paths for the flow graph illustrated in Fig.. Path : a c f Path : a b e f Path 3 : a d c f Path 4 : a b e a c f or a b e a b e f Path 5 : a b e b e f 33

Several properties of cyclomatic complexity are stated below:. V(G). V (G) is the maximum number of independent paths in graph G. 3. Inserting & deleting functional statements to G does not affect V(G). 4. G has only one path if and only if V(G)=. 5. Inserting a new row in G increases V(G) by unity. 6. V(G) depends only on the decision structure of G. 34

The role of P in the complexity calculation V(G)=e-n+P is required to be understood correctly. We define a flow graph with unique entry and exit nodes, all nodes reachable from the entry, and exit reachable from all nodes. This definition would result in all flow graphs having only one connected component. One could, however, imagine a main program M and two called subroutines A and B having a flow graph shown in Fig.. Fig. 35

Let us denote the total graph above with 3 connected components as V ( M A B) = e n + P = 3-3+*3 = 6 This method with P can be used to calculate the complexity of a collection of programs, particularly a hierarchical nest of subroutines. 36

V ( M A B) = V ( M ) + V ( A) + V ( B) = Notice that. In general, the complexity of a collection C of flow graphs with K connected components is equal to the summation of their complexities. To see this let C i, I K denote the k distinct connected component, and let e i and n i be the number of edges and nodes in the ith-connected component. Then 6 V ( C) k = e n + p = ei ni + K k i= i= = k i= ( e i n i + ) = k i= V ( C i ) 37

Two alternate methods are available for the complexity calculations.. Cyclomatic complexity V(G) of a flow graph G is equal to the number of predicate (decision) nodes plus one. V(G)= + Where is the number of predicate nodes contained in the flow graph G.. Cyclomatic complexity is equal to the number of regions of the flow graph. 38

Example 8.5 Software Testing Consider a flow graph given in Fig. 3 and calculate the cyclomatic complexity by all three methods. Fig. 3 39

Solution Cyclomatic complexity can be calculated by any of the three methods.. V(G) = e n + P = 3 0 + = 5. V(G) = π + = 4 + = 5 3. V(G) = number of regions = 5 Therefore, complexity value of a flow graph in Fig. 3 is 5. 40

Example 8.6 Consider the previous date program with DD path graph given in Fig. 7. Find cyclomatic complexity. 4

Solution Number of edges (e) = 65 Number of nodes (n) =49 (i) V(G) = e n + P = 65 49 + = 8 (ii) V(G) = π + = 7 + = 8 (iii) V(G) = Number of regions = 8 The cyclomatic complexity is 8. 4

Example 8.7 Consider the quadratic equation problem given in example 8.3 with its DD Path graph. Find the cyclomatic complexity: 43

Solution Number of nodes (n) = 9 Number of edges (e) = 4 (i) V(G) = e n + P = 4 9 + = 7 (ii) V(G) = π + = 6 + = 7 (iii)v(g) = Number of regions = 7 Hence cyclomatic complexity is 7 meaning thereby, seven independent paths in the DD Path graph. 44

Example 8.8 Consider the classification of triangle problem given in example 8.4. Find the cyclomatic complexity. 45

Solution Number of edges (e) = 3 Number of nodes (n) =8 (i) V(G) = e n + P = 3 8 + = 7 (ii) V(G) = π + = 6 + = 7 (iii)v(g) = Number of regions = 7 The cyclomatic complexity is 7. Hence, there are seven independent paths as given in example 8.4. 46

Graph Matrices A graph matrix is a square matrix with one row and one column for every node in the graph. The size of the matrix (i.e., the number of rows and columns) is equal to the number of nodes in the flow graph. Some examples of graphs and associated matrices are shown in fig. 4. Fig. 4 (a): Flow graph and graph matrices 47

Fig. 4 (b): Flow graph and graph matrices 48

Fig. 4 (c): Flow graph and graph matrices 49

Fig. 5 : Connection matrix of flow graph shown in Fig. 4 (c)

The square matrix represent that there are two path ab and cd from node to node. 5

Example 8.9 Consider the flow graph shown in the Fig. 6 and draw the graph & connection matrices. Find out cyclomatic complexity and two / three link paths from a node to any other node. Fig. 6 : Flow graph 5

Solution The graph & connection matrices are given below : To find two link paths, we have to generate a square of graph matrix [A] and for three link paths, a cube of matrix [A] is required. 53

54

Data Flow Testing Data flow testing is another from of structural testing. It has nothing to do with data flow diagrams. i. Statements where variables receive values. ii. Statements where these values are used or referenced. As we know, variables are defined and referenced throughout the program. We may have few define/ reference anomalies: i. A variable is defined but not used/ referenced. ii. iii. A variable is used but never defined. A variable is defined twice before it is used. 55

Definitions The definitions refer to a program P that has a program graph G(P) and a set of program variables V. The G(P) has a single entry node and a single exit node. The set of all paths in P is PATHS(P) (i) Defining Node: Node n ϵ G(P) is a defining node of the variable v ϵ V, written as DEF (v, n), if the value of the variable v is defined at the statement fragment corresponding to node n. (ii) Usage Node: Node n ϵ G(P) is a usage node of the variable v ϵ V, written as USE (v, n), if the value of the variable v is used at statement fragment corresponding to node n. A usage node USE (v, n) is a predicate use (denote as p) if statement n is a predicate statement otherwise USE (v, n) is a computation use (denoted as c). 56

(iii) Definition use: A definition use path with respect to a variable v (denoted du-path) is a path in PATHS(P) such that, for some v ϵ V, there are define and usage nodes DEF(v, m) and USE(v, n) such that m and n are initial and final nodes of the path. (iv) Definition clear : A definition clear path with respect to a variable v (denoted dc-path) is a definition use path in PATHS(P) with initial and final nodes DEF (v, m) and USE (v, n), such that no other node in the path is a defining node of v. The du-paths and dc-paths describe the flow of data across source statements from points at which the values are defined to points at which the values are used. The du-paths that are not definition clear are potential trouble spots. 57

Hence, our objective is to find all du-paths and then identity those du-paths which are not dc-paths. The steps are given in Fig. 7. We may like to generate specific test cases for du-paths that are not dc-paths. Fig. 7 : Steps for data flow testing 58

Example 8.0 Consider the program of the determination of the nature of roots of a quadratic equation. Its input is a triple of positive integers (say a,b,c) and values for each of these may be from interval [0,00]. The program is given in Fig. 9. The output may have one of the option given below: (i) Not a quadratic program (ii) real roots (iii) imaginary roots (iv) equal roots (v) invalid inputs Find all du-paths and identify those du-paths that are definition clear. 59

Solution Step I: The program flow graph is given in Fig. 9 (a). The variables used in the program are a,b,c,d, validinput, D. Step II: DD Path graph is given in Fig. 9(b). The cyclomatic complexity of this graph is 7 indicating there are seven independent paths. Step III: Define/use nodes for all variables are given below: Variable a b c d D Validinput Defined at node 6 8 0 8 3, 7 3,, 4 Used at node,3,8,0,4,7,8,8,0,4,8,8 9,,3,7 4,8 7,3 60

Step IV: The du-paths are identified and are named by their beginning and ending nodes using Fig. 9 (a). Variable a b Path (beginning, end) nodes 6, 6, 3 6, 8 6, 0 6, 4 6, 7 6, 8 8, 8, 8 8, 0 8, 4 8, 8 Definition clear? Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes 6

Variable c d D validinput Path (beginning, end) nodes 0, 0, 8 8, 9 8, 8, 3 8, 7 3, 4 3, 8 7, 4 7, 8 3, 7 3, 3, 7, 3 4, 7 4, 3 Definition clear? Yes Yes Yes Yes Yes Yes Yes Path not possible Path not possible Yes no no no no yes yes 6

Example 8. Consider the program given in Fig. 0 for the classification of a triangle. Its input is a triple of positive integers (say a,b,c) from the interval [,00]. The output may be: [Scalene, Isosceles, Equilateral, Not a triangle, Invalid inputs]. Find all du-paths and identify those du-paths that are definition clear. 63

Solution Step I: The program flow graph is given in Fig. 0 (a). The variables used in the program are a,b,c, valid input. Step II: DD Path graph is given in Fig. 0(b). The cyclomatic complexity of this graph is 7 and thus, there are 7 independent paths. Step III: Define/use nodes for all variables are given below: Variable a b c valid input Defined at node 6 7 9 3, 3, 6 Used at node 0,, 9, 0,, 9, 0,, 9, 8, 9 64

Step IV: The du-paths are identified and are named by their beginning and ending nodes using Fig. 0 (a). Variable a Path (beginning, end) nodes 5, 0 5, 5, 9 5, Definition clear? Yes Yes Yes Yes b 7, 0 7, 7, 9 7, Yes Yes Yes Yes 65

Variable c valid input Path (beginning, end) nodes 9, 0 9, 9, 9 9, 3, 8 3, 9, 8, 9 6, 8 6, 9 Definition clear? Yes Yes Yes Yes no no no no Yes Yes Hence total du-paths are 8 out of which four paths are not definition clear 66

Mutation Testing Mutation testing is a fault based technique that is similar to fault seeding, except that mutations to program statements are made in order to determine properties about test cases. it is basically a fault simulation technique. Multiple copies of a program are made, and each copy is altered; this altered copy is called a mutant. Mutants are executed with test data to determine whether the test data are capable of detecting the change between the original program and the mutated program. A mutant that is detected by a test case is termed killed and the goal of mutation procedure is to find a set of test cases that are able to kill groups of mutant programs. 67

When we mutate code there needs to be a way of measuring the degree to which the code has been modified. For example, if the original expression is x+ and the mutant for that expression is x+, that is a lesser change to the original code than a mutant such as (c*), where both the operand and the operator are changed. We may have a ranking scheme, where a first order mutant is a single change to an expression, a second order mutant is a mutation to a first order mutant, and so on. High order mutants becomes intractable and thus in practice only low order mutants are used. One difficulty associated with whether mutants will be killed is the problem of reaching the location; if a mutant is not executed, it cannot be killed. Special test cases are to be designed to reach a mutant. For example, suppose, we have the code. Read (a,b,c); If(a>b) and (b=c) then x:=a*b*c; (make mutants; m, m, m 3.) 68