Theory and Practice of Software Testing

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
SOFTWARE TESTING. INTRODUCTION  Software Testing is the process of executing a program or system with the intent of finding errors.  It involves any.
Creator: ACSession No: 13 Slide No: 1Reviewer: SS CSE300Advanced Software EngineeringFebruary 2006 Testing - Techniques CSE300 Advanced Software Engineering.
Chapter 17 Software Testing Techniques
1 “White box” or “glass box” tests “White Box” (or “Glass Box”) Tests.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
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
Chapter 18 Testing Conventional Applications
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
Unit Testing CS 414 – Software Engineering I Don Bagert Rose-Hulman Institute of Technology January 16, 2003.
Software Engineering Lecture 12 Software Testing Techniques 1.
1 Software Testing Techniques CIS 375 Bruce R. Maxim UM-Dearborn.
Software Systems Verification and Validation Laboratory Assignment 3
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
Software Testing Techniques
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
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.
1 Software testing. 2 Testing Objectives Testing is a process of executing a program with the intent of finding an error. A good test case is in that.
Agenda Introduction Overview of White-box testing Basis path testing
1 Chapter : Testing Tactics. 2 Testing Fundamental Software engineer attempts to build software from an abstract concept to a tangible product. Next is.
INTRUDUCTION TO SOFTWARE TESTING TECHNIQUES BY PRADEEP I.
White-box Testing.
1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 14a: Software Testing Techniques Software Engineering: A Practitioner’s Approach, 6/e Chapter.
Software Testing and Reliability Southern Methodist University CSE 7314.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 6/e (McGraw-Hill 2005). Slides copyright 2005 by Roger Pressman.1.
Presented by: Ritesh Jain Date: 16-Jun-05 Software Quality Testing.
1 Program Testing (Lecture 14) Prof. R. Mall Dept. of CSE, IIT, Kharagpur.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.1.
White Box Testing Arun Lakhotia University of Southwestern Louisiana P.O. Box Lafayette, LA 70504, USA
SOFTWARE TESTING. Introduction Software Testing is the process of executing a program or system with the intent of finding errors. It involves any activity.
Chapter : 18 Testing Conventional Applications
White Box Testing by : Andika Bayu H.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.1.
Chapter 23 전통적인 애플리케이션 테스팅 Testing Conventional Applications 임현승 강원대학교 Revised from the slides by Roger S. Pressman and Bruce R. Maxim for the book “Software.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
Software Testing Techniques Presented By Dr. Shazzad Hosain.
1 Lecture 14: Chapter 18 Testing Conventional Applications Slide Set to accompany Software Engineering: A Practitioner’s Approach, 7/e by Roger S. Pressman.
CSC 395 – Software Engineering Lecture 27: White-Box Testing.
SOFTWARE TESTING LECTURE 9. OBSERVATIONS ABOUT TESTING “ Testing is the process of executing a program with the intention of finding errors. ” – Myers.
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.
Software Engineering (CSI 321)
Chapter 17 Software Testing Techniques
Chapter 18 Testing Conventional Applications
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 Engineering (CSI 321)
Loop Testing.
Chapter 18 Testing Conventional Applications
Data Coverage and Code Coverage
Structural testing, Path Testing
White Box Testing.
Chapter 18 Testing Conventional Applications
Chapter 18 Testing Conventional Applications
Chapter 14 Software Testing Techniques
“White box” or “glass box” tests
Chapter 18 Testing Conventional Applications
Control Structure Testing
Chapter 18 Testing Conventional Applications.
Chapter 23 Testing Conventional Applications
Software Testing Techniques
By: Lecturer Raoof Talal
Unit III – Chapter 3 Path Testing.
Presentation transcript:

Theory and Practice of Software Testing Chapter 14 Presman Software Testing Tactics

Testing objectives [MYE79] Testing is a process of executing a program with the goal of finding an error. A good test is one that has a high probability of finding an error

Good Testing Has a high probability of finding an error Is Not redudant Should be “best f breed” Should be neither too simple nor too complex

Testing Techniques Test information flow Test case design White box testing Basis path testing Black box Testing Equivalence Partitioning Boundary Value Analysis

Test Information flow testing Software configuration evaluation errors results Error rate data debug corrections testing Reliability model test configuration Predicted reliability Expected results

White-Box testing Sometime called Glass-box testing A test case design philosophy that uses the control program structure to derive test case Knowledge of the program is used to identify additional test cases

White-Box testing Objective is to exercise all program statements (not all path combinations) Every instruction Every decision A set of paths that meets these criteria is said to provide cover or complete cover

White-box testing

Basis Path Testing One of white box testing technique The objective of basis path testing is to derive a logical complexity measure of procedural design and defining a basis set of execution paths Test case derived to exercise the basis set to execute every statement in the program at least one time during testing

Basis Path testing Uses flow graph or program graph that shows nodes representing program decisions and vertex representing the flow of control Statements with conditions are therefore nodes in the flow graph Node is any point in the program where the control either joins, or forks or both Nodes are joined by edges or links

Contoh Program

Predicate Node Node that contain a conditiona Can be compound with logical operator : “and” / “or”

Independent Path (IP) Independent Path is any path through the program that introduces at least one new set processing statement or a new condition

A set of independent path 1-2-10-11-13 1-2-10-12-13 1-2-3-10-11-13 1-2-3-4-5-8-9-2-… 1-2-3-4-5-6-8-9-2-… 1-2-3-4-5-6-7-8-9-2…

Process to deriving Test Cases Map the design or code to the corresponding flow graph Compute the cyclomatic complexity of the resultant flow graph Identify a basis set of independent paths Prepare test cases that will force execution of each path in the basis set

Cyclomatic Complexity : V(G) Metric that provides a quantitative measure of logical complexity of a program Define the number of independent path in the basis set of a program The number of tests cases used to test all control statements equals the cyclomatic complexity

Compute Cyclomatic Complexity V(G) = R V(G)= P +1 V(G) = E –N +2 Where : R is the number of regions of the flow graph P is the number of logical expressions (or predicates node) E is the number of flow graph edges N is the number of flow graph nodes

Path 1 test case Specification of Inputs Value (k) = valid input, where k < i Value (i) = -999 where 2 i 100 Specification of Output (expected results): correct average based on k values and correct totals should be computed Note: This test case must be test as part of path 4, 5, and 6 tests

Path 2 test case Inputs Expected results: Value (1) = -999 Average = -999; other total at initial values

Path 3 test case Inputs Expected results: Attempt to process 101 or more values The first 100 values should be valid Expected results: correct average based on k values and correct totals should be computed

Path 4 test case Inputs Expected results: Value (i) = valid input, i < 100 Value (k) < minimum where k<i Expected results: correct average based on k values and correct totals should be computed

Path 5 test case Inputs Expected results: Value (i) = valid input where i< 100 Value (i)> maximum where k i Expected results: correct average based on n values and correct totals should be computed

Path 6 test case Inputs Expected results: Value (i) = valid input where i< 100 Expected results: correct average based on n values and correct totals should be computed

Main tactics on path selection A sufficient number of paths to achieve coverage Selection of short, functionally sensible paths Minimizing the number of changes from path to path (one decision changing at a time) Favor more but simpler paths over fewer but complicated paths

Effectiveness path testing Approximately between 60-70% of all bugs can be caught in unit testing using basis path testing

Main Limitations of Basis path testing Can not be used to show totally wrong or missing functions Interface errors may not be caught Database errors may not be caught Not all initialization errors are caught by path testing

Graph Metrices A tabular representation of flow graph with link weight addition to provide information about control flow A square matrix whose size ( row & column) is equal to the number of node on flow graph Existing connection ( 1 & 0)

Link Weight Probability an edge will be executed Processing time expended, Memory required, Resources required, during traversal of a link

Control Structure Testing Condition Testing a test case design method that exercise the logical conditions contained in a program module Data Flow Testing a method to select a test path of a program according to the location of definitions and uses of variable in the program Loop Testing a white box testing technique that focuses exclusively on the validity of loop construct

Loop Testing 4 different classes of loop : Simple loop Nested loop Concatenated loop Unstructured loop

Simple Loop test criteria The following set of test can be applied to a simple loop of size max Skip the loop entirely One pass through the loop Two passes through the loop before existing M passes through the loop where M < max max-1, max, max+1 passes through the loop

Nested Loop test criteria Start at the inner loop. Set all other loop to a minimum value Conduct simple loop testing for the innermost loop Work outward, repeat for all loops. Keeping all other outer loops at minimum value & other nested loops to “typical value” Continue until all loops tested

Concatenated Loops If independent loops, use simple loop testing If dependent, treat as nested loops

Unstructured Loops Don’t test - redesign