Lecture 12 - Software Testing Techniques & Software Testing Strategies Software Testing Fundmentals Software Testing Fundmentals Test Case Design Test

  • View
    222

  • Download
    1

Embed Size (px)

Text of Lecture 12 - Software Testing Techniques & Software Testing Strategies Software Testing Fundmentals...

  • Slide 1

Lecture 12 - Software Testing Techniques & Software Testing Strategies Software Testing Fundmentals Software Testing Fundmentals Test Case Design Test Case Design White-Box Testing White-Box Testing Black-Box Testing Black-Box Testing Testing for Specialized Environments, Architectures, and Applications Testing for Specialized Environments, Architectures, and Applications A Strategic Approach to Software Testing A Strategic Approach to Software Testing Strategic Issues Strategic Issues Unit Testing Unit Testing Integration Testing Integration Testing Validation Testing Validation Testing System Testing System Testing The Art of Debugging The Art of Debugging Slide 2 Overview The importance of software testing to software quality can not be overemphasized. Once source code has been generated, software must be tested to allow errors to be identified and removed before delivery to the customer. While it is not possible to remove every error in a large software package, the software engineer goal is to remove as many as possible early in the software development cycle. It is important to remember that testing can only find errors, it cannot prove that a program is bug free. Two basic test techniques involve testing module input/output (black-box) and exercising internal logic of software components (white-box). Formal technical reviews by themselves can not find allow software defects, test data must also be used. For large software projects, separate test teams may be used to develop and execute the set of test cases used in testing. Testing must be planned and designed. The SEPA web site contains the template for a generic test plan. The importance of software testing to software quality can not be overemphasized. Once source code has been generated, software must be tested to allow errors to be identified and removed before delivery to the customer. While it is not possible to remove every error in a large software package, the software engineer goal is to remove as many as possible early in the software development cycle. It is important to remember that testing can only find errors, it cannot prove that a program is bug free. Two basic test techniques involve testing module input/output (black-box) and exercising internal logic of software components (white-box). Formal technical reviews by themselves can not find allow software defects, test data must also be used. For large software projects, separate test teams may be used to develop and execute the set of test cases used in testing. Testing must be planned and designed. The SEPA web site contains the template for a generic test plan. Slide 3 Software Testing Objectives Testing is the process of executing a program with the intent of finding errors. Testing is the process of executing a program with the intent of finding errors. A good test case is one with a high probability of finding an as-yet undiscovered error. A good test case is one with a high probability of finding an as-yet undiscovered error. A successful test is one that discovers an as-yet- undiscovered error. A successful test is one that discovers an as-yet- undiscovered error. Slide 4 Software Testing Principles All tests should be traceable to customer requirements. All tests should be traceable to customer requirements. Tests should be planned long before testing begins. Tests should be planned long before testing begins. The Pareto principle (80% of all errors will likely be found in 20% of the code) applies to software testing. The Pareto principle (80% of all errors will likely be found in 20% of the code) applies to software testing. Testing should begin in the small and progress to the large. Testing should begin in the small and progress to the large. Exhaustive testing is not possible. Exhaustive testing is not possible. To be most effective, testing should be conducted by an independent third party. To be most effective, testing should be conducted by an independent third party. Slide 5 Software Testability Checklist Operability (the better it works the more efficiently it can be tested) Operability (the better it works the more efficiently it can be tested) Observabilty (what you see is what you test) Observabilty (what you see is what you test) Controllability (the better software can be controlled the more testing can be automated and optimized) Controllability (the better software can be controlled the more testing can be automated and optimized) Slide 6 Decomposability (by controlling the scope of testing, the more quickly problems can be isolated and retested intelligently) Decomposability (by controlling the scope of testing, the more quickly problems can be isolated and retested intelligently) Simplicity (the less there is to test, the more quickly we can test) Simplicity (the less there is to test, the more quickly we can test) Stability (the fewer the changes, the fewer the disruptions to testing) Stability (the fewer the changes, the fewer the disruptions to testing) Understandability (the more information known, the smarter the testing) Understandability (the more information known, the smarter the testing) Slide 7 Good Test Attributes A good test has a high probability of finding an error. A good test has a high probability of finding an error. A good test is not redundant. A good test is not redundant. A good test should be best of breed. A good test should be best of breed. A good test should not be too simple or too complex. A good test should not be too simple or too complex. Slide 8 Test Case Design "Bugs lurk in corners and congregate at boundaries..." Boris Beizer OBJECTIVE CRITERIA CONSTRAINT to uncover errors in a complete manner with a minimum of effort and time Slide 9 Exhaustive Testing loop < 20 X There are 10 possible paths! If we execute one test per millisecond, it would take 3,170 years to test this program!! 14 Slide 10 Selective Testing loop < 20 X Selected path Slide 11 Software Testing Methods Strategies white-box methods black-box methods Slide 12 Test Case Design Strategies Black-box or behavioral testing (knowing the specified function a product is to perform and demonstrating correct operation based solely on its specification without regard for its internal logic) Black-box or behavioral testing (knowing the specified function a product is to perform and demonstrating correct operation based solely on its specification without regard for its internal logic) White-box or glass-box testing (knowing the internal workings of a product, tests are performed to check the workings of all insdependent logic paths) White-box or glass-box testing (knowing the internal workings of a product, tests are performed to check the workings of all insdependent logic paths) Slide 13 White-Box Testing... our goal is to ensure that all statements and conditions have been executed at least once... Slide 14 Why Cover? logic errors and incorrect assumptions are inversely proportional to a path's execution probability we often believe that a path is not that a path is not likely to be executed; in fact, reality is often counter intuitive typographical errors are random; it's likely that untested paths will contain some Slide 15 Basis Path Testing White-box technique usually based on the program flow graph White-box technique usually based on the program flow graph The cyclomatic complexity of the program computed from its flow graph using the formula V(G) = E -N + 2 or by counting the conditional statements in the PDL representation and adding 1 : V(G) = P+1, or number of enclosed areas + 1 The cyclomatic complexity of the program computed from its flow graph using the formula V(G) = E -N + 2 or by counting the conditional statements in the PDL representation and adding 1 : V(G) = P+1, or number of enclosed areas + 1 Determine the basis set of linearly independent paths (the cardinality of this set id the program cyclomatic complexity) Determine the basis set of linearly independent paths (the cardinality of this set id the program cyclomatic complexity) Prepare test cases that will force the execution of each path in the basis set. Prepare test cases that will force the execution of each path in the basis set. Slide 16 First, we compute the cyclomatic Complexity, or number of enclosed areas + 1, In this case, V(G) = 4 Slide 17 Cyclomatic Complexity A number of industry studies have indicated that the higher V(G), the higher the probability or errors. V(G) modules modules in this range are more error prone Slide 18 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. 1 2 3 4 56 7 8 Slide 19 Basis Path Testing Notes you don't need a flow chart, but the picture will help when you trace program paths count each simple logical test, compound tests count as 2 or more basis path testing should be applied to critical modules Slide 20 Control Structure Testing White-box techniques focusing on control structures present in the software White-box techniques focusing on control structures present in the software Condition testing (e.g. branch testing) focuses on testing each decision statement in a software module, it is important to ensure coverage of all logical combinations of data that may be processed by the module (a truth table may be helpful) Condition testing (e.g. branch testing) focuses on testing each decision statement in a software module, it is important to ensure coverage of all logical combinations of data that may be processed by the module (a truth table may be helpful) Slide 21 Data flow testing selects test paths based according to the locations of variable definitions and uses in the program (e.g. definition use chains) Data flow testing selects test paths based according to the locations of variable definitions and uses in the program (e