White Box Testing.  Path yang berbeda dalam modul software akan dibentuk oleh pilihan kondisional statement seperti IF-THEN-ELSE atau DO WHILE atau DO.

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

Chapter 14 Software Testing Techniques - Testing fundamentals - White-box testing - Black-box testing - Object-oriented testing methods (Source: Pressman,
1 ECE 453 – CS 447 – SE 465 Software Testing & Quality Assurance Lecture 11 Instructor Paulo Alencar.
SOFTWARE TESTING. INTRODUCTION  Software Testing is the process of executing a program or system with the intent of finding errors.  It involves any.
-- Finishing Design Unit -- Intro to Glass Box Testing ECEN5543 / CSCI 5548 SW Eng of Standalone Programs University of Colorado, Boulder.
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.
Software Testing Sudipto Ghosh CS 406 Fall 99 November 16, 1999.
White Box Testing Techniques Dynamic Testing. White box testing(1) Source code is known and used for test design While executing the test cases, the internal.
Chapter 8: Path Testing Csci 565.
IMSE Week 18 White Box or Structural Testing Reading:Sommerville (4th edition) ch 22 orPressman (4th edition) ch 16.
DAIMI(c) Henrik Bærbak Christensen1 White-box Testing Let us open the box...
Unit Testing CS 414 – Software Engineering I Don Bagert Rose-Hulman Institute of Technology January 16, 2003.
SOFTWARE TESTING WHITE BOX TESTING 1. GLASS BOX/WHITE BOX TESTING 2.
Software Testing and QA Theory and Practice (Chapter 4: Control Flow Testing) © Naik & Tripathy 1 Software Testing and Quality Assurance Theory and Practice.
Path testing Path testing is a “design structural testing” in that it is based on detailed design & the source code of the program to be tested. The methodology.
A Complexity Measure THOMAS J. McCABE Presented by Sarochapol Rattanasopinswat.
Cyclomatic Complexity Dan Fleck Fall 2009 Dan Fleck Fall 2009.
Software Testing Sudipto Ghosh CS 406 Fall 99 November 9, 1999.
Software Systems Verification and Validation Laboratory Assignment 3
CMSC 345 Fall 2000 Unit Testing. The testing process.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 1 Defect testing l Testing programs to establish the presence of system defects.
CS4311 Spring 2011 Unit Testing Dr. Guoqiang Hu Department of Computer Science UTEP.
CS /51 Illinois Institute of Technology CS487 Software Engineering Software Testing Techniques Mr. David A. Lash.
Agenda Introduction Overview of White-box testing Basis path testing
Test Coverage CS-300 Fall 2005 Supreeth Venkataraman.
White-box Testing.
Software Testing and Reliability Southern Methodist University CSE 7314.
1 Program Testing (Lecture 14) Prof. R. Mall Dept. of CSE, IIT, Kharagpur.
BASIS PATH TESTING.
White Box Testing Arun Lakhotia University of Southwestern Louisiana P.O. Box Lafayette, LA 70504, USA
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.
Agent program is the one part(class)of Othello program. How many test cases do you have to test? Reversi [Othello]
White Box Testing by : Andika Bayu H.
1 Test Coverage Coverage can be based on: –source code –object code –model –control flow graph –(extended) finite state machines –data flow graph –requirements.
Cyclomatic Complexity Philippe CHARMAN Last update:
White-Box Testing Techniques I Prepared by Stephen M. Thebaut, Ph.D. University of Florida Software Testing and Verification Lecture 7.
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.
Verification vs. Validation Verification: "Are we building the product right?" The software should conform to its specification.The software should conform.
1 Software Testing. 2 What is Software Testing ? Testing is a verification and validation activity that is performed by executing program code.
White Box Testing. Agenda White-box vs Black-box Program Flow Controls White-box Test Methods Exercises Complexity Q&A.
Testing Integral part of the software development process.
Software TestIng White box testing.
BASIS PATH 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.
Control Flow Testing Handouts
Handouts Software Testing and Quality Assurance Theory and Practice Chapter 4 Control Flow Testing
Cyclomatic complexity
Software Engineering (CSI 321)
Outline of the Chapter Basic Idea Outline of Control Flow Testing
Data Coverage and Code Coverage
When is testing sufficient?
CONTROL FLOW TESTING.
Structural testing, Path Testing
Control Flow based Testing
Types of Testing Visit to more Learning Resources.
White Box Testing.
White-Box Testing.
CHAPTER 4 Test Design Techniques
UNIT-4 BLACKBOX AND WHITEBOX TESTING
Software Testing (Lecture 11-a)
White-Box Testing.
Sudipto Ghosh CS 406 Fall 99 November 16, 1999
White-Box Testing Techniques I
Control Structure Testing
UNIT-4 BLACKBOX AND WHITEBOX TESTING
Unit III – Chapter 3 Path Testing.
Presentation transcript:

White Box Testing

 Path yang berbeda dalam modul software akan dibentuk oleh pilihan kondisional statement seperti IF-THEN-ELSE atau DO WHILE atau DO UNTIL atau REPEAT-UNTIL

 Dikembangkan oleh McCabe (1976) untuk mengukur kompleksitas program atau modul pada waktu yang sama sebagai jumlah maksimum independent path yang dibutuhkan untuk mencapai full line coverage pada program.  Dasar ukuran adalah teori graf dan dihitung berdasarkan kesesuaian ke sifat program yang dicapture oleh program flow graph  Independent path adalah setiap path pada program flow graph sedikitnya satu baris yang tidak dibentuk oleh independent path lain.

20 times A B How many test cases ?

void main (void) { int a, b, c; int min, med, max; if (a>b) { max=a; min=b; } else { max=b; min=a; } if (c>max) {max=c;} else if (c<min) {min=c;} med=a+b+c-min-max; if (max>min+med) {printf("impossible triangle \n");} else if (max==min) {printf("equilateral triangle \n");} else if (max==med || med==min) {printf("isoceles triangle \n");} else if ( max *max == min*min+med*med) {printf("rightangled triangle\n");} else {printf("any triangle\n");} } v(G) = = 8 8 Path = ?? Example : if ( a > b and b > c) then max=a; else max = 100; end if ;

 V(G) = R  V(G) = E – N +2  V(G) = P + 1  Keterangan  V(G) = cyclometic complexity metric  R = jumlah region dalam program flow graph  Setiap area yang melingkungi graph disebut sebuah region  E = Jumlah Edge (garis)  N = Jumlah node  P= Jumlah decision

if... else... v(G)=2 if..... v(G)=2 while... v(G)=

b eg a c fd v(g)=10-7+2=5 This graph has 5 independent paths: C1abcbcg C2abefg C3adfg C4adefg C5abcg All the other paths are derived from the preceding 5 by linear combination example: abcbcbefg=C1+C1+C2-C5-C5

Next, we derive the independent paths: Since V(G) = 4, there are four paths Path 1:1,2,3,6,7,8 Path 2:1,2,3,5,7,8 Path 3:1,2,4,7,8 Path 4:1,2,4,7,2,4…7,8 Finally, we derive test cases to exercise these paths, i.e. choose inputs that lead to traversing the paths

Statement coverage Decision coverage Condition coverage Decision-condition coverage Multiple-condition coverage

 complete path testing is not a realistic goal for a program with loops.

 writing a single test case that traverses path ace.  by setting A=2, B=0, and X=3 at point a,  Every statement would be executed once (actually, X could be assigned any value).

 Unfortunately, this criterion is a rather poor one.  Perhaps the first decision should be an or rather than an and  Perhaps the second decision should have stated X>0  Also, there is a path through the program in which X goes unchanged (the path abd)  the statement coverage criterion is so weak that it generally is useless.

 This criterion states that you must write enough test cases that each decision has a true and a false outcome at least once.  each branch direction must be traversed at least once.  Decision coverage usually can satisfy statement coverage.

 decision coverage requires that each decision have a true and a false outcome, and  that each statement be executed at least once.  has to be modified for programs that contain multiway decisions.  Java programs containing select (case) statements,

 decision coverage can be met by two test cases covering paths  ace and abd or,  alternatively, acd and abe ▪ A = 3, B = 0, X = 3 ▪ A = 2, B = 1, and X = 1.

 stronger criterion than statement coverage,  but it still is rather weak.  there is only a 50 percent chance that we would explore the path where X is not changed (abd)  only if we chose the former alternative ▪ ace and abd

 A criterion that is sometimes stronger than decision coverage is condition coverage.  write enough test cases to ensure that each condition in a decision takes on all possible outcomes at least once.  this does not always lead to the execution of each statement,  an addition to the criterion is that each point of entry to the program or subroutine, as well as ON units, be invoked at least once.

 Figure 4.1 has four conditions: A>1, B=0, A=2, and X>1.  enough test cases are needed to force the situations where A>1, A 0 are present at point a and  where A=2, A<>2, X>1, and X<=1 are present at point b. ▪ 1. A=2, B=0, X=4 ace ▪ 2. A=1, B=1, X=1 abd

 Alternative  1. A=1, B=0, X=3  2. A=2, B=1, X=1  cover all condition outcomes,  but they cover only two of the four decision outcomes.  both of them cover path abe

 requires sufficient test cases that each condition in a decision takes on all possible outcomes at least once,  Each decision takes on all possible outcomes at least once,  and each point of entry is invoked at least once.

 A weakness with decision/condition coverage is that,  although it may appear to exercise all outcomes of all conditions,  it frequently does not because certain conditions mask other conditions.

 Figure 4.2 is the way a compiler would generate machine code  A more thorough test coverage, appears to be the exercising of all possible outcomes of each primitive decision  The two previous decision coverage test cases do not accomplish this; they fail to exercise the false outcome of decision H and the true outcome of decision K.

 This criterion requires that you write sufficient test cases that all possible combinations of condition outcomes in each decision, and all points of entry, are invoked at least once.

 It should be easy to see that a set of test cases satisfying the multiple condition criterion also satisfies  the decision-coverage,  condition coverage,  and decision/condition-coverage criteria.

 These combinations to be tested do not necessarily imply that eight test cases are needed.  In fact, they can be covered by four test cases.  A=2, B=0, X=4 Covers 1, 5  A=2, B=1, X=1 Covers 2, 6  A=1, B=0, X=2 Covers 3, 7  A=1, B=1, X=1 Covers 4, 8

 The fact that there are four test cases and four distinct paths in Figure 4.1 is just coincidence.  In fact, these four test cases do not cover every path;  they miss the path acd.

 In the case of loops, the number of test cases required by the multiple-condition criterion is normally much less than the number of paths.