Structured Testing - McCabe and Associates

More documents

Recommendations

Info

than developing the module with complexity in mind from the outset. Awareness of manual techniques for complexity analysis helps design and build good software, rather than deferring complexity-related issues to a later phase of the life cycle. Automated tools are an effective way to confirm and control complexity, but they work best where at least rough estimates of complexity are used during development. In some cases, such as Ada development, designs can be represented and analyzed in the target programming language. 30
5 Structured Testing Structured testing uses cyclomatic complexity and the mathematical analysis of control flow graphs to guide the testing process. Structured testing is more theoretically rigorous and more effective at detecting errors in practice than other common test coverage criteria such as statement and branch coverage [WATSON5]. Structured testing is therefore suitable when reliability is an important consideration for software. It is not intended as a substitute for requirements-based “black box” testing techniques, but as a supplement to them. Structured testing forms the “white box,” or code-based, part of a comprehensive testing program, which when quality is critical will also include requirements-based testing, testing in a simulated production environment, and possibly other techniques such as statistical random testing. Other “white box” techniques may also be used, depending on specific requirements for the software being tested. Structured testing as presented in this section applies to individual software modules, where the most rigorous code-based “unit testing” is typically performed. The integration level Structured testing technique is described in section 7. 5.1 The structured testing criterion After the mathematical preliminaries of section 2 (especially Sec. 2.3), the structured testing criterion is simply stated: Test a basis set of paths through the control flow graph of each module. This means that any additional path through the module’s control flow graph can be expressed as a linear combination of paths that have been tested. Note that the structured testing criterion measures the quality of testing, providing a way to determine whether testing is complete. It is not a procedure to identify test cases or generate test data inputs. Section 6 gives a technique for generating test cases that satisfy the structured testing criterion. Sometimes, it is not possible to test a complete basis set of paths through the control flow graph of a module. This happens when some paths through the module can not be exercised by any input data. For example, if the module makes the same exact decision twice in sequence, no input data will cause it to vary the first decision outcome while leaving the second constant or vice versa. This situation is explored in section 9 (especially 9.1), including the possibilities of modifying the software to remove control dependencies or just relaxing the testing criterion to require the maximum attainable matrix rank (known as the actual complexity) whenever this differs from the cyclomatic complexity. All paths are assumed to be exercisable for the initial presentation of the method. 31
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 and 10: 11 Maintenance ....................
Page 11 and 12: 1 Introduction 1.1 Software testing
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: 4.3 Use of automated tools The most
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?