Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn. 4. Testing

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

SFWR ENG 3S03: Software Testing

Verification Black-box Testing & Testing in the Large

SE 3S03 - Tutorial 10. Helen Brown. Week of Mar 23, 2015

SE 3S03. Zahra Ali. Week of Feb 22, 2016

(See related materials in textbook.) CSE 435: Software Engineering (slides adapted from Ghezzi et al & Stirewalt

An Introduction to Systematic Software Testing. Robert France CSU

Introduction to Dynamic Analysis

Topics in Software Testing

Program Analysis. Program Analysis

Subject Software Testing Structural Testing

Darshan Institute of Engineering & Technology for Diploma Studies

Génie Logiciel Avancé

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

Testing & Continuous Integration. Kenneth M. Anderson University of Colorado, Boulder CSCI 5828 Lecture 20 03/19/2010

Chapter 9. Software Testing

CS 520 Theory and Practice of Software Engineering Fall 2018

3. Logical Values. Boolean Functions; the Type bool; logical and relational operators; shortcut evaluation

Theme 2 Program Design and Testing

Introduction au Génie Logiciel Partie3: Test: Static White-Box Test

Principles of Software Construction: Objects, Design, and Concurrency (Part 2: Designing (Sub )Systems)

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

Aerospace Software Engineering

Assertions & Verification Example Exam Questions

3. Logical Values. Our Goal. Boolean Values in Mathematics. The Type bool in C++

1 Black Box Test Data Generation Techniques

3. Logical Values. Our Goal. Boolean Values in Mathematics. The Type bool in C++

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

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

Lecture 10: Introduction to Correctness

Structural Testing. White Box Testing & Control Flow Analysis

Software Testing. Lecturer: Sebastian Coope Ashton Building, Room G.18

Structural Testing. (c) 2007 Mauro Pezzè & Michal Young Ch 12, slide 1

CHAPTER 5 GENERATING TEST SCENARIOS AND TEST CASES FROM AN EVENT-FLOW MODEL

Assertions & Verification & Example Loop Invariants Example Exam Questions

Using the code to measure test adequacy (and derive test cases) Structural Testing

Lecture 15 Software Testing

Verification and Validation. Verification and validation

Part 5. Verification and Validation

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

Testing Methods: White Box Testing II

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

Coding and Unit Testing! The Coding Phase! Coding vs. Code! Coding! Overall Coding Language Trends!

Discrete Mathematics Lecture 4. Harper Langston New York University

Reasoning About Imperative Programs. COS 441 Slides 10

LECTURE 16. Functional Programming

Testing & Debugging TB-1

MONIKA HEINER.

Testing Process and Methods. CS 490MT/5555, Spring 2017, Yongjie Zheng

A Gentle Introduction to Program Analysis

INTRODUCTION TO SOFTWARE ENGINEERING

CIS 890: Safety Critical Systems

Write perfect C code to solve the three problems below.

Software Testing. Software Testing

10. Software Testing Fundamental Concepts

Advanced Programming Methods. Introduction in program analysis

One of the most important areas where quantifier logic is used is formal specification of computer programs.

Testing: (A Little) Logic Coverage

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

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

White-Box Testing Techniques III

Semantics. There is no single widely acceptable notation or formalism for describing semantics Operational Semantics

Quality Assurance in Software Development

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

2.1 Sets 2.2 Set Operations

C Language Part 1 Digital Computer Concept and Practice Copyright 2012 by Jaejin Lee

Reasoning about programs

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

Last time. Reasoning about programs. Coming up. Project Final Presentations. This Thursday, Nov 30: 4 th in-class exercise

Lecture 18: Structure-based Testing

Software Engineering 2 A practical course in software engineering. Ekkart Kindler

Lectures 20, 21: Axiomatic Semantics

Testing: Coverage and Structural Coverage

4. Logical Values. Our Goal. Boolean Values in Mathematics. The Type bool in C++

Lecture 17: Testing Strategies. Developer Testing

Lecture 1 Contracts : Principles of Imperative Computation (Fall 2018) Frank Pfenning

Material from Recitation 1

[IT6004-SOFTWARE TESTING] UNIT 2

Program Correctness and Efficiency. Chapter 2

Lecture 1 Contracts. 1 A Mysterious Program : Principles of Imperative Computation (Spring 2018) Frank Pfenning

Formal Approach in Software Testing

3.4 Deduction and Evaluation: Tools Conditional-Equational Logic

[Ch 6] Set Theory. 1. Basic Concepts and Definitions. 400 lecture note #4. 1) Basics

The testing process. Component testing. System testing

Introduction II. Sets. Terminology III. Definition. Definition. Definition. Example

No Source Code. EEC 521: Software Engineering. Specification-Based Testing. Advantages

1 Elementary number theory

DATA STRUCTURES AND ALGORITHMS

Know the Well-ordering principle: Any set of positive integers which has at least one element contains a smallest element.

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

Taibah University College of Computer Science & Engineering Course Title: Discrete Mathematics Code: CS 103. Chapter 2. Sets

An Annotated Language

Regular Languages (14 points) Solution: Problem 1 (6 points) Minimize the following automaton M. Show that the resulting DFA is minimal.

AXIOMS OF AN IMPERATIVE LANGUAGE PARTIAL CORRECTNESS WEAK AND STRONG CONDITIONS. THE AXIOM FOR nop

Darshan Institute of Engineering & Technology Unit : 9

Second assignment came out Monday evening. Find defects in Hnefetafl rules written by your classmates. Topic: Code Inspection and Testing

Topology notes. Basic Definitions and Properties.

6. Asymptotics: The Big-O and Other Notations

Black Box Testing. EEC 521: Software Engineering. Specification-Based Testing. No Source Code. Software Testing

CMSC 132: OBJECT-ORIENTED PROGRAMMING II

Transcription:

4.

vs. Model Checking (usually) means checking the correctness of source code Model Checking means verifying the properties of a model given in some formal (not program code) notation Attention: things can overlap! 2

Characteristics Continuity Problem: Small Changes (can) have big effects Context Problem: Environment produces (almost) random effects can only prove the presence of defects never their absence (in contrast to model checking or theorem proving) 3

Example: Continuity Problem procedure binary-search (key: in element; table: in elementtable; found: out Boolean) is begin bottom := table first; top := table last while bottom < top loop if (bottom + top) mod 2 0 then middle := (bottom + top 1) / 2; else middle := (bottom + top) / 2; end if; if key table (middle) then top := middle; else bottom := middle + 1; end if; end loop; found := key = table (middle); end binary-search; 4

Example: Continuity Problem When leaving out the first else-statement the program still works for arbitrary large odd numbers 5

Example: Context Problem if x = 0 then write ( abnormal ) else write ( normal ) end if; x not initialised Effect depends on context (programming language, compiler, operating system) 6

Some basic notations (1/3) Let P be a program, D its input domain, R its range P behaves as a partial function and could be extended to a relation which means P(d) is the result of executing P on input datum d Let OR denote the output requirement on output values of P as given in P s specification For a given d in D, P is said to be correct for d, if P(d) satisfies OR P is correct iff it is correct for all d in D. 7

Some basic notations (2/3) A test case is an element of D. A test set T is a finite set of test cases. P is correct for T if it is correct for all elements in T (T is successful for P). A test set T is called ideal if, whenever P is incorrect, there exists a d in T such that P is incorrect for d. A (test) selection criterion is a finite subset of the power set of D, i.e. it specifies a condition which must be satisfied by a test set. 8

Some basic notations (3/3) A selection criterion C is consistent, if, for any pair of test sets T1 and T2, both satisfying C, T1 is successful if and only if T2 is successful. A selection criterion C is complete, if, whenever P is incorrect, there is an unsuccessful test set that satisfies C. A selection criterion C1 is finer than C2, if, for any P, for every test set T1 satisfying C1, there exists a subset of T1 which satisfies C2. Note that consistency and completeness are undecidable problems 9

White Box vs. Black Box White box testing means full knowledge of the code when defining test cases Black box testing means knowledge of the interface (specification) when defining test cases 10

4.1 White-box testing [C. Ghezzi, M. Jazayeri, D. Mandrioli: Fundamentals of Software Engineering, Prentice- Hall, 1991, pp. 270-278]

Statement Coverage Criterion Select a test set T such that, by executing P for each d in T, each elementary statement of P is executed at least once. Elementary statements are assignments, I/O statements and method calls. 12

Example: Algorithm of Euclid begin end; read (x); read (y); while x y loop if x > y then x := x y; else y := y x; end if; end loop; gcd := x; While loop suggests two test cases where x=y and x y Statement coverage requires a test set where we consider the cases x < y and x > y. 13

Construction of minimal test sets read (x); read (y); if x > 0 then write ( 1 ); else write ( 2 ); end if; if y > 0 then write ( 3 ); else write ( 4 ); end if; A test set {(x=2, y=3), (x=-13, y=51), (x=97,y=-17), (x=-1, y=-1)} provides statement coverage but is not minimal. {(x=-13, y=51), (x=97, y=-17)} would suffice 14

Weakness of statement coverage if x < 0 then x := -x; end if; z := x; Would only require a test where x is negative But it fails to check the virtual else branch: if x < 0 then x := -x; else null; end if; z := x; 15

Edge Coverage Criterion Select a test set T such that, by executing P for each d in T, each edge of P s control flow graph is traversed at least once. 16

Construction of the control flow graph For each elementary statement (an assignment, an I/O statement or a method call, for example) a graph with two nodes and an edge is built, see Figure (a). An edge represents the statement. Nodes represent entry into and exit from statement Labels on statements and edges can be used to make correspondence explicit. (a) 17

Construction of the control flow graph Let S1 and S2 denote two statements, and G1 and G2, denote their corresponding graphs. Then, the graph of Figure (b) is associated with the statement if cond then S1; else S2; end if; The graph of Figure (c) is associated with the statement if cond then S1; end if; (b) (c) G1 G1 G2 18

Construction of the control flow graph Let S1 and S2 denote two statements, and G1 and G2, denote their corresponding graphs. Then, the graph of Figure (d) is associated with the statement while cond loop (d) G1 S1; end loop; The graph of Figure (e) is associated with the statement S1; S2; (e) G1 G2 19

Weakness of edge coverage found := false; if number_of_items 0 then counter := 1; while (not found) and counter < number_of_items loop if table (counter) = desired_element then found := true; end if; counter := counter + 1; end loop; end if; if found then write ( the desired element exists in the table ); else write ( the desired element does not exist in the table ); end if; 20

Weakness of edge coverage Test Cases: A table with no items, i.e., number_of_items = 0 execution of the fragment without any iteration of the loop body. A table with three items, the second being the desired one execution of the loop body twice, the first time without executing the then branch, the second time executing it. Notice that both branches of the final if-then-else statement are executed, so that the edge coverage criterion is fulfilled. The cases provide edge coverage But these test cases miss the problem that the counter can be equal to number_of_items 21

Condition Coverage Criterion Select a test set T such that, by executing P for each element in T, each edge of P s control flow graph is traversed, and all possible values of the constituents of compound boolean conditions are exercised at least once. In the example on slide 20, test cases are needed where all values for both conditions!found and counter < number_of_items are tested. 22

Weakness of condition coverage if x 0 then y :=5; else z := z x; end if; if z > 1 then z:= z / x; else z :=0; end if; x 0 x = 0 y := 5; z := z - x; z > 1 z 1 z := z/x; z := 0; Possible test sets: {(x= 0, z = 1), (x = 1, z = 3)} provides for condition (and edge(!)) coverage but division by zero is possible {(x= 0, z = 1), (x = 1, z = 3), (x = 0, z = 3), (x = 1, z = 1)} 23

Path coverage criterion Select a test set T such that, by executing P for each d in T, all paths leading from the initial to the final node of P s control flow graph are traversed. Paths to provide for Edge Coverage Additional paths to provide for Path Coverage 24

Empirical Guidelines for testing loops 1. Zero times 2. A maximum number of times (does not work for reactive systems which contain infinite loops, see model checking) 3. An average number of times 25

4.2 Black-box testing [I. Sommerville: Software Engineering, Addison-Wesley, 1992, pp. 428-432]

Blackbox based on Equivalence Classes Idea: Classes of correct inputs Classes of incorrect inputs Component Classes of outputs 27

Example Only the interface, preconditions and commentary are known procedure binary-search (key: in element; table: in elementtable; found: out Boolean) Commentary Binary search in an array Preconditions: Last index of table > first index of table. The table is ordered. The first element is at index 0. 28

Possible equivalence classes Preconditions suggest four equivalence classes 1. Inputs conform to pre-conditions and element is in the array 2. Inputs conform to pre-conditions and element is not in the array 3. Inputs do not conform to pre-conditions and element is in the array 4. Inputs do not conform to pre-conditions and element is not in the array Classes 3 and 4 may be combined as the program may return an error message if the preconditions are not met 29

Possible equivalence classes Use of a sorted array suggests three equivalence classes: 1. Array contains one element 2. Array contains even number of elements 3. Array contains odd number of elements ( 1) Boundary values should be tested which suggests two equivalence classes: 1. Element is the first element in the array 2. Element is the last element in the array 30

The combined Equivalence Classes 1. Array of length 1, element in array 2. Array of length 1, element not in array 3. Array of even length, element 1 st element in array 4. Array of even length, element last element in array 5. Array of even length, element is not first or last one 6. Array of even length, element not in array 7. - 10. analogous with array of odd length 11. Precondition does not hold 31

Summary: Equivalence Define Equivalence Classes for all possible test cases based on functional specification Take one test case for each class Consider correct and incorrect inputs Consider boundary values 32

Decision table-based testing Consider the following informal specification for a word processor: The word processor may preset portions of text in three different formats: plain text (p), boldface (b), and italics (i). The following commands may be applied to each portion of text: make text plain (P), make boldface (B), make italics (I), emphasize (E), super-emphasize (SE). Commands are available to dynamically set E to mean either B or I. (We denote such commands as E = B and E = I, respectively.) Similarly, SE can be dynamically set to mean either B (command SE = B), or I (command SE = I), or B and I (command SE = B+I). [C. Ghezzi, M. Jazayeri, D. Mandrioli: Fundamentals of Software Engineering, Prentice-Hall, 1991, pp. 283-287] 33

Decision table for the example P B I Condition alternatives E conditions actions SE E=B E=I SE=B SE=I SE=B&I p b i Example: If super-emphasize is selected and set to B&I the text is printed bold and in italics. Action entries 34

The cause-effect graph technique The following (incomplete) cause-effect graph shows under which circumstances a word is printed bold. B I P E E = B SE E = I SE = B SE = I SE = B+I O R Cause-effect graphs can be built systematically from decision tables: Combine all conditions in each column with an AND node and connect all causes leading to the same action with an OR node, which is connected to the action. A N D A N D O R b i p 35

Graphical representation of constraints among local variables For causes a, b, c and effects x, y the following constraints can be used: a a E b I b c c At most one must be true (E=exclusive) O a b Only one must be true (O=one and only one) c At least one must be true (I=at least one) R a b a implies b (R=requires) x y M x implies not y (M=mask) 36

The cause-effect graph with constraints I O O B I P E E E E = B SE E = I SE = B SE = I SE = B+I O R A N D A N D O R M b i p M 37