Structured Testing - McCabe and Associates

More documents

Recommendations

Info

equired for each software module is exactly the cyclomatic complexity. Other common white box testing criteria have the inherent anomaly that they can be satisfied with a small number of tests for arbitrarily complex (by any reasonable sense of “complexity”) software as shown in section 5.2. 1.4 Document overview and audience descriptions • Section 1 gives an overview of this document. It also gives some general information about software testing, software complexity measurement, and the relationship between the two. • Section 2 describes the cyclomatic complexity measure for software, which provides the foundation for structured testing. • Section 3 gives some examples of both the applications and the calculation of cyclomatic complexity. • Section 4 describes several practical shortcuts for calculating cyclomatic complexity. • Section 5 defines structured testing and gives a detailed example of its application. • Section 6 describes the Baseline Method, a systematic technique for generating a set of test paths that satisfy structured testing. • Section 7 describes structured testing at the integration level. • Section 8 describes structured testing for object-oriented programs. • Section 9 discusses techniques for identifying and removing unnecessary complexity and the impact on testing. • Section 10 describes the essential complexity measure for software, which quantifies the extent to which software is poorly structured. • Section 11 discusses software modification, and how to apply structured testing to programs during maintenance. • Section 12 summarizes this document by software lifecycle phase, showing where each technique fits into the overall development process. • Appendix A describes several related case studies. • Appendix B presents an extended example of structured testing. It also describes an experimental design for comparing structural testing strategies, and applies that design to illustrate the superiority of structured testing over branch coverage. 4
Figure 1-1 shows the dependencies among the first 11 sections. 1. Introduction 2. Cyclomatic Complexity 3. Examples 4. Simplified 5. Structured Testing 6. Baseline 7. Integration 8. Object-Oriented Figure 1-1. Dependencies among sections 1-11. 10. Essential Complexity 9. Simplification 11. Modification Readers with different interests may concentrate on specific areas of this document and skip or skim the others. Sections 2, 5, and 7 form the primary material, presenting the core structured testing method. The mathematical content can be skipped on a first reading or by readers primarily interested in practical applications. Sections 4 and 6 concentrate on manual techniques, and are therefore of most interest to readers without access to automated tools. Readers working with object-oriented systems should read section 8. Readers familiar with the original NBS structured testing document [NBS99] should concentrate on the updated material in section 5 and the new material in sections 7 and 8. Programmers who are not directly involved in testing may concentrate on sections 1-4 and 10. These sections describe how to limit and control complexity, to help produce more testable, reliable, and maintainable software, without going into details about the testing technique. Testers may concentrate on sections 1, 2, and 5-8. These sections give all the information necessary to apply the structured testing methodology with or without automated tools. Maintainers who are not directly involved in the testing process may concentrate on sections 1, 2, and 9-11. These sections describe how to keep maintenance changes from degrading the 5
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: used to represent software systems
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?