Structured Testing - McCabe and Associates

More documents

Recommendations

Info

Appendix B Extended Example......................................................105 x B.1 Testing the blackjack program.................................................................................. 105 B.2 Experimental comparison of structured testing and branch coverage...................... 112
1 Introduction 1.1 Software testing This document describes the structured testing methodology for software testing. Software testing is the process of executing software and comparing the observed behavior to the desired behavior. The major goal of software testing is to discover errors in the software [MYERS2], with a secondary goal of building confidence in the proper operation of the software when testing does not discover errors. The conflict between these two goals is apparent when considering a testing process that did not detect any errors. In the absence of other information, this could mean either that the software is high quality or that the testing process is low quality. There are many approaches to software testing that attempt to control the quality of the testing process to yield useful information about the quality of the software being tested. Although most testing research is concentrated on finding effective testing techniques, it is also important to make software that can be effectively tested. It is suggested in [VOAS] that software is testable if faults are likely to cause failure, since then those faults are most likely to be detected by failure during testing. Several programming techniques are suggested to raise testability, such as minimizing variable reuse and maximizing output parameters. In [BER- TOLINO] it is noted that although having faults cause failure is good during testing, it is bad after delivery. For a more intuitive testability property, it is best to maximize the probability of faults being detected during testing while minimizing the probability of faults causing failure after delivery. Several programming techniques are suggested to raise testability, including assertions that observe the internal state of the software during testing but do not affect the specified output, and multiple version development [BRILLIANT] in which any disagreement between versions can be reported during testing but a majority voting mechanism helps reduce the likelihood of incorrect output after delivery. Since both of those techniques are frequently used to help construct reliable systems in practice, this version of testability may capture a significant factor in software development. For large systems, many errors are often found at the beginning of the testing process, with the observed error rate decreasing as errors are fixed in the software. When the observed error rate during testing approaches zero, statistical techniques are often used to determine a reasonable point to stop testing [MUSA]. This approach has two significant weaknesses. First, the testing effort cannot be predicted in advance, since it is a function of the intermediate results of the testing effort itself. A related problem is that the testing schedule can expire long before the error rate drops to an acceptable level. Second, and perhaps more importantly, the statistical model only predicts the estimated error rate for the underlying test case distribution 1
Page 1 and 2: NIST Special Publication 500-235 St
Page 3: Abstract The purpose of this docume
Page 7 and 8: CONTENTS Abstract..................
Page 9: 11 Maintenance ....................
Page 13 and 14: used to represent software systems
Page 15 and 16: Figure 1-1 shows the dependencies a
Page 17 and 18: 2 Cyclomatic Complexity Cyclomatic
Page 19 and 20: Figure 2-2. Control flow graph for
Page 21 and 22: Virtual Edge Figure 2-4. Control fl
Page 23 and 24: 2.4 Example of v(G) and basis paths
Page 25 and 26: than the cyclomatic complexity numb
Page 27 and 28: 3 Examples of Cyclomatic Complexity
Page 29 and 30: Figure 3-3. Control flow graph with
Page 31 and 32: Figure 3-7. Control flow graph with
Page 33 and 34: 4 Simplified Complexity Calculation
Page 35 and 36: In addition to counting predicates
Page 37 and 38: Figure 4-6 shows a C code module wi
Page 39 and 40: 4.3 Use of automated tools The most
Page 41 and 42: 5 Structured Testing Structured tes
Page 43 and 44: Next, with structured testing, test
Page 45 and 46: Figure 5-2. Code for module “coun
Page 47 and 48: that satisfies the structured testi
Page 49: 5.7 Critical software Different typ
Page 52 and 53: First, for every decision in the mo
Page 54 and 55: 6.4 Example of the baseline method
Page 56 and 57: Of the tests in Figure 6-2, the bas
Page 58 and 59: integration testing can be combined
Page 60 and 61:
tured testing at the module level r
Page 62 and 63:
ule 3 illustrates that a conditiona
Page 64 and 65:
7.5 Integration complexity The inte
Page 66 and 67:
Although a basis set of paths throu
Page 68 and 69:
Figure 7-7 illustrates the structur
Page 70 and 71:
When abstraction works well, it hid
Page 72 and 73:
are objects of a class type, the ex
Page 74 and 75:
ment is to provide evidence that th
Page 77 and 78:
9 Complexity Reduction Although the
Page 79 and 80:
Figure 9-3. Code after removing unn
Page 81 and 82:
There are many situations in which
Page 83 and 84:
show the reengineered functions “
Page 85 and 86:
Figure 9-10.Graph for structured mo
Page 87:
In addition to the trade-off betwee
Page 90 and 91:
understood code, since the connecti
Page 92 and 93:
tured logic is superimposed on the
Page 94 and 95:
complexity may not be obvious from
Page 96 and 97:
11.4 Reuse of testing information A
Page 98 and 99:
call resolutions based on complexit
Page 100 and 101:
[DAHL] Dahl, O. and E. Dijkstra and
Page 102 and 103:
[MCCABE5] McCabe, T. and A. Watson,
Page 104 and 105:
[WARD] Ward, W., “Software Defect
Page 106 and 107:
A.3 Walsh 96 The propensity to make
Page 108 and 109:
to avoid changing very complex proc
Page 110 and 111:
testing and maintenance. The projec
Page 112 and 113:
The suggested explanation is that o
Page 114 and 115:
A.21 Koshgoftaar et al Koshgoftaar,
Page 116 and 117:
B.1.2 The module Figure B-1 shows t
Page 118 and 119:
dealer’s hand value. Those two va
Page 120 and 121:
The ninth functional test is a win
Page 122 and 123:
B.2 Experimental comparison of stru
Page 124:
114
show all

Structured Testing - McCabe and Associates

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?