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.

Slides:



Advertisements
Similar presentations
Software Testing Techniques
Advertisements

Chapter 14 Software Testing Techniques - Testing fundamentals - White-box testing - Black-box testing - Object-oriented testing methods (Source: Pressman,
Software Testing Technique. Introduction Software Testing is the process of executing a program or system with the intent of finding errors. It involves.
Chapter 14 Testing Tactics
Chapter 6 Path Testing Software Testing
Unit Testing CS 4311 Hans Van Vliet, Software Engineering, Principles and Practice, 3rd edition, John Wiley & Sons, Chapter 13.
CYCLOMATIC COMPLEXITY 1. Invented by Thomas McCabe (1974) to measure the complexity of a program ’ s conditional logic Cyclomatic complexity of graph.
SOFTWARE TESTING. INTRODUCTION  Software Testing is the process of executing a program or system with the intent of finding errors.  It involves any.
White Box Testing and Symbolic Execution Written by Michael Beder.
Chapter 8: Path Testing Csci 565.
BASIS PATH TESTING ● By Tom McCabe ● McCabe, T., "A Software Complexity Measure," IEEE Trans. Software Engineering, vol. SE-2, December 1976, pp
Testing an individual module
SOFTWARE TESTING WHITE BOX TESTING 1. GLASS BOX/WHITE BOX TESTING 2.
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.
Software Testing Sudipto Ghosh CS 406 Fall 99 November 9, 1999.
Software Systems Verification and Validation Laboratory Assignment 3
System/Software Testing
CMSC 345 Fall 2000 Unit Testing. The testing process.
White-Box Testing Eshcar Hillel Michael Beder. White Box Testing 2 Tutorial Outline What is White Box Testing? Flow Graph and Coverage Types Symbolic.
Path Testing + Coverage Chapter 9 Assigned reading from Binder.
CS4311 Spring 2011 Unit Testing Dr. Guoqiang Hu Department of Computer Science UTEP.
Agenda Introduction Overview of White-box testing Basis path testing
INTRUDUCTION TO SOFTWARE TESTING TECHNIQUES BY PRADEEP I.
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 IS4500 Copyright © 2012 by The Cathris Group and Martin J. Schedlbauer. All Rights Reserved. Do Not Duplicate or Distribute Without Written.
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]
Dynamic Testing.
White Box Testing by : Andika Bayu H.
White-Box Testing Techniques I Prepared by Stephen M. Thebaut, Ph.D. University of Florida Software Testing and Verification Lecture 7.
Dynamic White-Box Testing What is code coverage? What are the different types of code coverage? How to derive test cases from control flows?
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.
CS223: Software Engineering Lecture 26: Software Testing.
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.
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
Software Engineering (CSI 321)
Outline of the Chapter Basic Idea Outline of Control Flow Testing
Data Coverage and Code Coverage
CONTROL FLOW TESTING.
Structural testing, Path Testing
White-Box Testing Techniques
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)
Chapter 14 Software Testing Techniques
“White box” or “glass box” tests
White-Box Testing Techniques I
Control Structure Testing
White-Box Testing.
Whitebox Testing.
UNIT-4 BLACKBOX AND WHITEBOX TESTING
Unit III – Chapter 3 Path Testing.
Presentation transcript:

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 processing of test object (source code), as well as output is analyzed (PoO is inside test object) PoC can be located inside the test object Also known as code-based or structural testing techniques Can be applied at component and integration testing

White Box Testing Techniques(2) Poc and/or PoO “inside” the test object Test Output data PoC PoO Test input data Test object

White box testing(3) The generic idea is to execute every path of the code at least once –Flow-oriented test cases are identified –Program logic is analyzed and executed –Expected results should be determined using requirements or specification, not source code

White box testing(4) The basic test case design techniques are: –Statement coverage –Branch coverage

Statement Coverage(1) A set of paths - that every node lies on at least one path Focuses on each statement Steps taken –Translate source code to CFG –Determine the paths –Determine the test cases

Statement Coverage(2) a b c d e f gi h k Path: a,b,f,g,h,d,e Choose test case that fulfills the path

Statement Coverage(3) Test completion criteria –Statement coverage = (number of executed statement/total number of statement) * 100% Value of the technique –Unreachable code can be detected –Statement for empty ELSE is irrelevant

Branch Coverage(1) A set of paths - that every edge lies on at least one path Focus on edges Consider the execution of decisions Result of decision determines which statement is executed next Testing should make sure every decision is executed with both TRUE and FALSE outcomes In IF-statement All possible CASE or SWITCH statement Loops (execute loop body, bypass loop body, return to beginning of loop)

Branch Coverage(2) a b c d e f gi h k Paths: 1)a,b,c,d 2)a,b,f,g,i,g,h,d,e 3)a,k,e In addition to statement coverage can result in complete coverage. Choose test cases that fulfill the paths

Branch Coverage(3) Test completion criteria –branch coverage = (number of executed branch/total number of branches) * 100% Value of the technique –Requires more test cases than statement coverage –Can detect missing statements in empty branches –100% branch coverage guarantees 100% statement coverage

Linearly independent path The execution of set of linearly independent paths An independent path must move along at least one edge that has not been traversed before the path is defined Steps taken –Draw a corresponding CFG –Calculate cyclomatic complexity –Determine a basis set of linearly independent paths –Prepare test cases that will force execution of each path in the basis set.

Test of conditions(1) If a decision is based on several conditions connected by logical operators, then the complexity of the condition should be considered in the test Branch condition testing –The goal is that each atomic (partial) condition in the test shall adopt the values of TRUE and FALSE –An atomic part of a condition is a condition that has no logical operator, but at the most includes relational symbols

Test of conditions(2) Branch condition testing (example) –Supposed a composed condition is: x > 3 OR y < 5 –Consists of two atomic partial conditions (x > 3; y < 5) –Goal: every atomic part is evaluated once for each of the logical values –The test data x=6 and y=8 result in logical value TRUE for first atomic part and FALSE for the second atomic part; the logical value for complete condition is TRUE –The test data x=2 and y=3 result in logical value FALSE for first atomic part and TRUE for the second atomic part; the logical value for complete condition is TRUE

Test of conditions(3) Branch condition combination testing (multiple-condition coverage) –Requires that all TRUE-FALSE combinations of the atomic partial conditions be exercised at least once –All variations should be built, if possible –Example from previous slide –Four possible combinations of test cases x=6(T), y=3(F), x>3 OR y<5 (T) x=6(T), y=8(F), x>3 OR y<5 (T) x=2(F), y=3(T), x>3 OR y<5 (T) x=2(F), y=8(F), x>3 OR y<5 (F)