CS 217 Software Verification and Validation Week 7, Summer 2014 Instructor: Dong Si

Slides:



Advertisements
Similar presentations
Lecture 2: testing Book: Chapter 9 What is testing? Testing is not showing that there are no errors in the program. Testing cannot show that the program.
Advertisements

Formal Methods and Testing Goal: software reliability Use software engineering methodologies to develop the code. Use formal methods during code development.
Marking Schema question1: 40 marks question2: 40 marks question3: 20 marks total: 100 marks.
SOFTWARE TESTING. INTRODUCTION  Software Testing is the process of executing a program or system with the intent of finding errors.  It involves any.
Annoucements  Next labs 9 and 10 are paired for everyone. So don’t miss the lab.  There is a review session for the quiz on Monday, November 4, at 8:00.
Black box testing  Black box tests focus on the input/output behavior of the component  Black-box tests do not deal with the internal aspects of the.
Nov R McFadyen1 A Traditional Software Development Process Unit test Integration test System test Detailed design Architectural design Analysis.
Software Testing and Quality Assurance
Testing an individual module
SOFTWARE TESTING WHITE BOX TESTING 1. GLASS BOX/WHITE BOX TESTING 2.
1 Software Testing Techniques CIS 375 Bruce R. Maxim UM-Dearborn.
1 Joe Meehean. 2 Testing is the process of executing a program with the intent of finding errors. -Glenford Myers.
Testing techniques, example
Product Quality?.
Software Testing Sudipto Ghosh CS 406 Fall 99 November 9, 1999.
Verification and Validation (Part 2) John Morris Computer Science/ Electrical and Computer Engineering 28-Aug-151 A hard day’s work ensuring that some.
System/Software Testing
Let us start from the V-Model Verification Phases Requirements analysis System Design Architecture Design Module Design Coding Validation phases Unit.
CS 217 Software Verification and Validation Week 6, Summer 2014 Instructor: Dong Si
CMSC 345 Fall 2000 Unit Testing. The testing process.
CS 217 Software Verification and Validation Week 9, Summer 2014 Instructor: Dong Si
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 1 Defect testing l Testing programs to establish the presence of system defects.
© Andrew IrelandSoftware Design F28SD2 Software Design (F28SD2): Life-Cycle Perspective - Part 2 Andrew Ireland School of Mathematical & Computer Sciences.
Overview of Software Testing 07/12/2013 WISTPC 2013 Peter Clarke.
Course Outline Traditional Static Program Analysis –Theory –Classic analysis and applications Points-to analysis, CHA, RTA –The Soot analysis framework.
CS4311 Spring 2011 Unit Testing Dr. Guoqiang Hu Department of Computer Science UTEP.
CS 217 Software Verification and Validation Week 3, Summer 2014 Instructor: Dong Si
CS /51 Illinois Institute of Technology CS487 Software Engineering Software Testing Techniques Mr. David A. Lash.
Software Testing The process of operating a system or component under specified conditions, observing and recording the results, and making an evaluation.
Agenda Introduction Overview of White-box testing Basis path testing
Black-Box Testing Techniques I
1 Software Testing. 2 Path Testing 3 Structural Testing Also known as glass box, structural, clear box and white box testing. A software testing technique.
Testing Testing Techniques to Design Tests. Testing:Example Problem: Find a mode and its frequency given an ordered list (array) of with one or more integer.
Black Box Testing Techniques Chapter 7. Black Box Testing Techniques Prepared by: Kris C. Calpotura, CoE, MSME, MIT  Introduction Introduction  Equivalence.
Test Coverage CS-300 Fall 2005 Supreeth Venkataraman.
Unit Testing 101 Black Box v. White Box. Definition of V&V Verification - is the product correct Validation - is it the correct product.
Black-box Testing.
INTRUDUCTION TO SOFTWARE TESTING TECHNIQUES BY PRADEEP I.
Software Testing Input Space Partition Testing. 2 Input Space Coverage Four Structures for Modeling Software Graphs Logic Input Space Syntax Use cases.
1 Program Testing (Lecture 14) Prof. R. Mall Dept. of CSE, IIT, Kharagpur.
Test Case Designing UNIT - 2. Topics Test Requirement Analysis (example) Test Case Designing (sample discussion) Test Data Preparation (example) Test.
CS451 Lecture 10: Software Testing Yugi Lee STB #555 (816)
Theory and Practice of Software Testing
SOFTWARE TESTING. Introduction Software Testing is the process of executing a program or system with the intent of finding errors. It involves any activity.
White-Box Testing Techniques I Prepared by Stephen M. Thebaut, Ph.D. University of Florida Software Testing and Verification Lecture 7.
SOFTWARE TESTING. SOFTWARE Software is not the collection of programs but also all associated documentation and configuration data which is need to make.
White-Box Testing Statement coverage Branch coverage Path coverage
SOFTWARE TESTING LECTURE 9. OBSERVATIONS ABOUT TESTING “ Testing is the process of executing a program with the intention of finding errors. ” – Myers.
White-Box Testing Techniques. Definition of White-Box Testing Testing based on analysis of internal logic (design, code, etc.). (But expected results.
Software Testing. SE, Testing, Hans van Vliet, © Nasty question  Suppose you are being asked to lead the team to test the software that controls.
1 Software Testing. 2 What is Software Testing ? Testing is a verification and validation activity that is performed by executing program code.
Testing Integral part of the software development process.
Software TestIng White box testing.
Software Testing.
White-Box Testing Pfleeger, S. Software Engineering Theory and Practice 2nd Edition. Prentice Hall, Ghezzi, C. et al., Fundamentals of Software Engineering.
Software Testing.
Software Engineering (CSI 321)
White-Box Testing Techniques
Types of Testing Visit to more Learning Resources.
CHAPTER 4 Test Design Techniques
UNIT-4 BLACKBOX AND WHITEBOX TESTING
Software Testing (Lecture 11-a)
Cause and Effect Graphing
White-Box Testing Techniques III
Test Case Test case Describes an input Description and an expected output Description. Test case ID Section 1: Before execution Section 2: After execution.
White-Box Testing Techniques I
Whitebox Testing.
Whitebox Testing.
UNIT-4 BLACKBOX AND WHITEBOX TESTING
Unit III – Chapter 3 Path Testing.
Presentation transcript:

CS 217 Software Verification and Validation Week 7, Summer 2014 Instructor: Dong Si

REVIEW OF BB-testing

Black-box Testing 1. Input Space Partitioning 2. Boundary Value Analysis 3

Example 1: compare two numbers – p50 of week3 n Function ‘Compare (x, y)’ n Inputs: Two numbers – x and y n Outputs: A larger number between x and y 4 Compare (x, y) = z (x, y) z

– p51 of week3 5 Equivalence Classes: { (x, y) | x < y } { (x, y) | x > y } { (x, y) | x = y } { input other than a pair of numbers, “as&%dfget^$(&w” } Valid inputs Invalid inputs

6 Valid (x, y) Input Space x = y x < y x > y Three test cases: (1, 2) (8, 8) (100, 30) Plus one test cases: (^&%*) --- ERROR – p52 of week3

Example 2: Loan application - p53 of week3 7 Customer Name Account number Loan amount requested Term of loan Monthly repayment Term: Repayment: Interest rate: Total paid back: 6 digits, 1st non-zero $500 to $ to 30 years Minimum $ chars. Choosing (or defining) partitions seems easy, but is easy to get wrong…

8 Customer name Number of characters: invalidvalidinvalid 1 Valid characters: Any other A-Z a-z -’ space

9 Loan amount invalidvalidinvalid 499

Black-box Testing 1. Input Space Partitioning 2. Boundary Value Analysis 10

Example 3 - Bonus n Consider a program IsAnOddNumber(x) which output “Yes” or “No” to the user to tell if the input integer x is a odd number or not. If you are planning to classify all possible user inputs into two classes - valid and invalid inputs 1) How do you partition the valid input space (the integer number space)? 2) Can you give an example of invalid test data? 11

Example 3 - Bonus n If your software manager asks the program MUST ONLY take input real number x as: -100<x<100 1) How do you partition all possible user inputs into two classes - valid and invalid inputs now? 2) If the software manager further asks you to do some Boundary Value Analysis, then what do you plan to do for the BVA analysis? 12

Example 4 - Bonus n Consider a program Absolute(x) which calculate the absolute value of a input real number x. If you are planning to classify all possible user inputs into two classes - valid and invalid inputs 1) How do you partition the valid input space (the real number space)? 2) Can you give an example of invalid test data? 13

Example 4 - Bonus n If your software manager asks the program MUST ONLY take input real number x within the range of: -321<x<-123, 123<x<321 1) How do you partition all possible user inputs into two classes - valid and invalid inputs now? 2) If the software manager further asks you to do some Boundary Value Analysis, then what do you plan to do for the BVA analysis? 14

Today’s topic WHITE-BOX TESTING

Styles of Testing n Testing traditionally can be conducted in two styles n Black-Box testing Try to choose "smart" tests based on the requirements, without looking at the code. n White-Box testing Try to choose "smart" tests based on the structure of the code, with minimal reference to the requirements. 16

Definition of White-Box Testing n Testing based on analysis of internal logic (design, code, etc.). (But expected results still come from requirements.) n Use different techniques to check every visible path of the source code to minimize errors. n It is the ability to know which line of the code is being executed and being able to identify what the correct output should be. 17

Characters of WB testing n Exploits the structure, control or data flow of programs in order to design test cases. n Typically performed during coding. n Allows to test parts of the program, since you know the structure. (with black ‐ box is not possible) n Allows to cover systematically every part of the program. 18

WB Testing Techniques n Logic coverage: (learned in previous classes)  Statement coverage  Branch coverage  Condition coverage  … n Dataflow based testing / Path coverage: all program paths have been traversed at least once 19

Pseudo code & Control/Dataflow Graphs 20 “nodes” “edges” Input output Absolute (x) { IF (x>=0) THEN y = x; ELSE IF (x<0) THEN y = -x; Output y; } x IF (x>=0)ELSE IF (x<0) y = x; y = -x; y

Can you draw a graph? 21 Absolute (x) { IF (x>0) THEN y = x; ELSE IF (x==0) THEN y = x; ELSE IF (x<0) THEN y = -x; Output y; }

Example 22 Fun (x, y) { z = 0; IF ((x>z) OR (y>z)) THEN z = 2; ELSE z = 3; Output z; } Test cases: 1.Fun (0, 0) 2.Fun (2, 0) 3.Fun (0, 2) 4.Fun (2, 2) 5.Fun (8, 9)

Control/Dataflow of the example 23 Fun (x, y) { z = 1; IF ((x>z) OR (y>z)) THEN z = 2; ELSE z = 3; Output z; } Input x, y z = 1; IF ((x>z) OR (y>z)) z = 2; ELSE z = 3; Output z; Test cases: 1.Fun (0, 0) 2.Fun (2, 0) 3.Fun (0, 2) 4.Fun (2, 2) 5.Fun (8, 9)

Statement coverage n Has each statement in the program been executed? 24 √ √ √

Branch coverage n Has each branch of each control structure been executed? n For example, given an if statement, have both the T and F branches been executed? n Another way of saying this is, has every edge in the Control/Dataflow graph been executed? 25

Condition coverage n Has each Boolean sub-expression evaluated both to true (T) and false (F) ? 26 Test cases: 1.Fun (0, 0) 2.Fun (2, 0) 3.Fun (0, 2) 4.Fun (2, 2) 5.Fun (8, 9) X>1 Y>1 T, F ? Fun (x, y) { z = 1; IF ((x>z) OR (y>z)) THEN z = 2; ELSE z = 3; Output z; }

Exercise n Consider a program ‘Compare’ which compare the value between two numbers. The inputs are two real numbers x and y, the program outputs the larger number between x and y. 27 Compare (x, y) { IF (x>y) THEN z = x; ELSE IF (x==y) THEN z = x; ELSE IF (x<y) THEN z = y; Output z; }

Exercise - Control/Data Flow Graphs n I have provided you the Pseudo code, n Can you draw a Control/Dataflow Graphs? n Try it! This is a bonus question with +5 points towards to FINAL!! 28

Exercise - Statement Coverage n Statement Coverage requires that each statement will have been executed at least once. What is the minimum number of test cases required to achieve statement coverage for the program Compare (x, y) ? 29

Exercise - Branch Coverage n Branch Coverage requires that each branch will have been traversed at least once. What is the minimum number of test cases required to achieve branch coverage for the program Compare (x, y) ? 30

Condition Coverage n Condition Coverage requires that each condition (sub-expression) will have been True at least once and False at least once. n What is the relationship between Branch and Condition Coverage?

Condition / branch coverage IF ( AND ) THEN … ELSE … 32 X>0 Y>0 T F T, F ?

Condition Coverage example – Combination ! IF A or B THEN s1; ELSE s2; ABBranch test 1TFtrue test 2FFfalse test 3TTtrue test 4FTtrue Combinations of condition values: TT, TF, FT, FF

Dataflow based testing -> Path coverage n All program paths have been traversed at least once. 34 Two paths ! Input x, y z = 1; IF ((x>z) OR (y>z)) z = 2; ELSE z = 3; Output z;

Path coverage - Example 1 35 if a then s1 else if b then s2 else if c then s3 else s4 end_if_then_else # Paths: ___ # Branches: ___

WB Testing Techniques n Logic coverage: (learned in previous class)  Statement coverage  Branch coverage  Condition coverage  … n Dataflow based testing / Path coverage: all program paths have been traversed at least once 36

Coming Up Next week… Lab 2: White-box Testing n Preparation:  Go over the slides of WB testing  Understand “Code coverage” & “Data flow / Path”