1 / 25

INTRUDUCTION TO SOFTWARE TESTING TECHNIQUES

INTRUDUCTION TO SOFTWARE TESTING TECHNIQUES. BY PRADEEP I. TESTING THE SOFTWARE. What is it? Who does it? When is it done? How is it done?. What is software?. It is Instructions when executed provide desired function and performance

rosskelly
Download Presentation

INTRUDUCTION TO SOFTWARE TESTING TECHNIQUES

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. INTRUDUCTION TO SOFTWARE TESTINGTECHNIQUES BY PRADEEP I

  2. TESTING THE SOFTWARE What is it? Who does it? When is it done? How is it done?

  3. What is software? It is • Instructions when executed provide desired function and performance • Data structures that enable the programs to adequately manipulate information and • Documents that describe the operation and use of the programs

  4. What is testing? • Testing is a process of executing a program with the intention of finding an error • A good test case is one that has a high probability of finding an as-yet-undiscovered error • A successful test is one that uncovers an as-yet-undiscovered error

  5. Who does it? • During early stages of testing, software engineer performs all tests. • As the testing process progresses testing specialists will get involved.

  6. When is it performed? • Testing does not start at the end of software process. • It is performed throughout the software process. • Test case design and test planning can begin as soon as requirement analysis is completed.

  7. How is it performed? It is performed in two perspectives. 1. Internal program logic is exercised using white box testing. 2. Software requirements are exercised using black box testing.

  8. White box testing • Guarantees that all independent paths within a module have been exercised at least once. • Exercises all logical decisions on their true and false sides • execute all loops at their boundaries and within their operational bounds. • Exercise internal data structures to ensure their validity.

  9. Basis path testing 1. Using the design or code as foundation, draw a corresponding flow graph. 2. Determine the cyclomatic complexity of the resultant flow graph. The cyclomatic complexity V(G) is provides an upper bound for the number of tests required to ensure that all statements have been executed at least once. It is V(G) = 6 regions V(G) = 17 edges - 13 nodes = 6 V(G) = 5 predicate nodes + 1= 6

  10. 3. Determine a basis set of linearly independent paths. The value of V(G) provides the number of linearly independent paths through the program control structure. Path 1: 1-2-10-11-13 Path 2: 1-2-10-12-13 Path 3: 1-2-3-10-11-13 Path 4: 1-2-3-4-5-8-9-2-…. Path 5: 1-2-3-4-5-6-8-9-2-…. Path 6: 1-2-3-4-5-6-7-8-9-2-….

  11. 4. Prepare test cases that will force execution of each path in the basis set. Data should be chosen so that conditions at the predicate nodes are appropriately set as each path is tested. Path 1 test case: value[k] = valid input, where k< i for 2  i 100 value[i] = -999 where 2  i 100 Expected results: correct average based on k values and proper totals. Note: path 1 can not be tested stand alone. It must be tested as part of path 4,5 and 6.

  12. Path 2 test case: value[1] = -999 Expected results: average = -999, other totals at initial values. Path 3 test case: Attempt to process 101 or more values. First 100 values should be valid. Expected results: correct average based on 100 inputs and proper totals.

  13. Path 4 test case: value[i] = valid input where i < 100 value[k] < minimum where k < I Expected results: correct average based on k values and proper totals. Path 5 test case: value[i] = valid input where i < 100 value[k] > maximum where k < i Expected results: Correct average based on k values and proper totals.

  14. Path 6 test case: value[i] = valid input where i < 100 Expected results: Correct average based on given values and proper totals. 5. Each test case is executed and compared to expected results.

  15. PRECEDURE average; * This procedure computes the average of 100 or fewer numbers that lie between bounding values ; it also computes the sum and the total number valid. INTERFACE RETURNS average, total.input, total.valid; INTERFACE ACCEPTS value, minimum, maximum; TYPE value[1:100] IS SCALAR ARRAY; TYPE average, total.input, total.valid, minimum, maximum, sum IS SCALAR; TYPE i IS INTEGER; Contd...

  16. i = 1; total.input = total.valid = sum = 0; DO WHILE value[i] <> -999 AND total.input < 100 increment total.input by 1; IF value[i] >= minimum AND value[i] <= maximum THEN increment total.valid by 1; sum = sum + value[i]; ELSE skip; ENDIF increment i by 1; ENDDO IF total.valid > 0 THEN average = sum / total.valid; ELSE average = -999; ENDIF END average 2 3 1 6 4 5 7 8 9 10 11 12 13

  17. Flow graph for procedure average 1 No. of nodes = 13 No. of edges = 17 No. of regions = 6 No. of predicate nodes = 5 2 R1 3 4 10 R6 R5 5 R2 12 11 6 R3 13 7 R4 8 9

  18. Loop testing To test simple loops with a maximum of n passes • Skip the loop entirely. • Only one pass through the loop. • Two passes through the loop. • m passes through the loop where m < n. • n-1, n, n+1 passes through the loop.

  19. To test nested loops • Start at the innermost loop. Set all other loops to minimum values. • Conduct simple loop tests for the innermost loop. • Work outward, conducting tests for the next loop. • Continue until all loops have been tested.

  20. Black box testing It attempts to find out the errors in the following categories. • Incorrect or missing functions. • Interface errors. • Errors in data structures or external data base access. • Behavior or performance errors. • Initialization and termination errors.

  21. Equivalence partitioning • Divide the input domain into classes of data. • If input constraints to range, define one valid class and two invalid classes. • If input constraints to member of a set, define one valid one invalid class. • If inputs condition is boolean, define one valid and one invalid class.

  22. Boundary value analysis • If input is a range specified by a and b, test with values a, b, and just below and above a and b. • Apply above guideline to output conditions. • If internal program data structures have prescribed boundaries, then exercise the data structure at its boundary.

  23. Testing documentation Documentation should provide • Accurate description of how to accomplish each mode of use. • Accurate description of each interaction sequence. • Accurate examples. • Terminology, menu description and system responses that are consistent with actual program.

  24. Easy access to locate guidance with in the document. • Description of troubleshooting. • Accurate and complete table of contents and index. • Accurate and complete hyper links. • Easy navigation for information. • Good design. (indentation, typefaces, layout, graphics, etc.)

  25. Is this the end? Testing never ends. It just gets transferred from from us to our customer. Every time the customer uses the program, a test is being conducted. Our aim of testing is to discover and correct the maximum possible number of errors before the “customer’s tests” begin.

More Related