The art of software testing. Myers (2nd edition) (2004) (811502), страница 16
Текст из файла (страница 16)
Of course,you could attempt to cover boundary conditions during the process.For instance, instead of identifying the single causehexloc2 ⭌ hexloc1you could identify two causes:hexloc2 = hexloc1hexloc2 > hexloc1The problem in doing this, however, is that it complicates the graphtremendously and leads to an excessively large number of test cases.For this reason it is best to consider a separate boundary-value analysis. For instance, the following boundary conditions can be identifiedfor the DISPLAY specification:1. hexloc1 has one digit.2. hexloc1 has six digits.3. hexloc1 has seven digits.4. hexloc1 = 0.Test-Case Design875.
hexloc1 = 7FFF.6. hexloc1 = 8000.7. hexloc2 has one digit.8. hexloc2 has six digits.9. hexloc2 has seven digits.10. hexloc2 = 0.11. hexloc2 = 7FFF.12. hexloc2 = 8000.13. hexloc2 = hexloc1.14. hexloc2 = hexloc1 + 1.15. hexloc2 = hexloc1 − 1.16. bytecount has one digit.17. bytecount has six digits.18. bytecount has seven digits.19. bytecount = 1.20. hexloc1 + bytecount = 8000.21. hexloc1 + bytecount = 8001.22. display 16 bytes (one line).23. display 17 bytes (two lines).Note that this does not imply that you would write 60 (37 + 23)test cases.
Since the cause-effect graph gives us leeway in selectingspecific values for operands, the boundary conditions could beblended into the test cases derived from the cause-effect graph. Inthis example, by rewriting some of the original 37 test cases, all 23boundary conditions could be covered without any additional testcases. Thus, we arrive at a small but potent set of test cases that satisfyboth objectives.Note that cause-effect graphing is consistent with several of thetesting principles in Chapter 2. Identifying the expected output ofeach test case is an inherent part of the technique (each column inthe decision table indicates the expected effects). Also note that itencourages us to look for unwanted side effects. For instance, column(test) 1 specifies that you should expect effect 91 to be present andthat effects 92 through 97 should be absent.88The Art of Software TestingThe most difficult aspect of the technique is the conversion of thegraph into the decision table.
This process is algorithmic, implyingthat you could automate it by writing a program; several commercialprograms exist to help with the conversion.Error GuessingIt has often been noted that some people seem to be naturally adeptat program testing. Without using any particular methodology suchas boundary-value analysis of cause-effect graphing, these peopleseem to have a knack for sniffing out errors.One explanation of this is that these people are practicing, subconsciously more often than not, a test-case-design technique thatcould be termed error guessing.
Given a particular program, they surmise, both by intuition and experience, certain probable types oferrors and then write test cases to expose those errors.It is difficult to give a procedure for the error-guessing techniquesince it is largely an intuitive and ad hoc process. The basic idea is toenumerate a list of possible errors or error-prone situations and thenwrite test cases based on the list.
For instance, the presence of thevalue 0 in a program’s input is an error-prone situation. Therefore,you might write test cases for which particular input values have a 0value and for which particular output values are forced to 0. Also,where a variable number of inputs or outputs can be present (e.g., thenumber of entries in a list to be searched), the cases of “none” and“one” (e.g., empty list, list containing just one entry) are error-pronesituations. Another idea is to identify test cases associated withassumptions that the programmer might have made when reading thespecification (i.e., things that were omitted from the specification,either by accident or because the writer felt them to be obvious).Since a procedure cannot be given, the next-best alternative is todiscuss the spirit of error guessing, and the best way to do this is bypresenting examples.
If you are testing a sorting subroutine, the following are situations to explore:Test-Case Design••••89The input list is empty.The input list contains one entry.All entries in the input list have the same value.The input list is already sorted.In other words, you enumerate those special cases that may have beenoverlooked when the program was designed. If you are testing abinary-search subroutine, you might try the situations where (1)there is only one entry in the table being searched, (2) the table sizeis a power of two (e.g., 16), and (3) the table size is one less than andone greater than a power of two (e.g., 15 or 17).Consider the MTEST program in the section on boundary-valueanalysis. The following additional tests come to mind when using theerror-guessing technique:• Does the program accept “blank” as an answer?• A type-2 (answer) record appears in the set of type-3 (student)records.• A record without a 2 or 3 in the last column appears as otherthan the initial (title) record.• Two students have the same name or number.• Since a median is computed differently depending on whetherthere is an odd or an even number of items, test the programfor an even number of students and an odd number of students.• The number-of-questions field has a negative value.Error-guessing tests that come to mind for the DISPLAY commandof the previous section are as follows:••••DISPLAY 100DISPLAY 100.DISPLAY 100-10A 42DISPLAY 000-0000FF(partial second operand)(partial second operand)(extra operand)(leading zeros)90The Art of Software TestingThe StrategyThe test-case-design methodologies discussed in this chapter can becombined into an overall strategy.
The reason for combining themshould be obvious by now: Each contributes a particular set of usefultest cases, but none of them by itself contributes a thorough set of testcases. A reasonable strategy is as follows:1. If the specification contains combinations of input conditions, start with cause-effect graphing.2. In any event, use boundary-value analysis. Remember thatthis is an analysis of input and output boundaries.
Theboundary-value analysis yields a set of supplemental test conditions, but, as noted in the section on cause-effect graphing,many or all of these can be incorporated into the cause-effecttests.3. Identify the valid and invalid equivalence classes for the inputand output, and supplement the test cases identified above ifnecessary.4. Use the error-guessing technique to add additional test cases.5. Examine the program’s logic with regard to the set of testcases.
Use the decision-coverage, condition-coverage, decision/condition-coverage, or multiple-condition-coveragecriterion (the last being the most complete). If the coveragecriterion has not been met by the test cases identified in theprior four steps, and if meeting the criterion is not impossible (i.e., certain combinations of conditions may be impossible to create because of the nature of the program), addsufficient test cases to cause the criterion to be satisfied.Again, the use of this strategy will not guarantee that all errors willbe found, but it has been found to represent a reasonable compromise.
Also, it represents a considerable amount of hard work, but noone has ever claimed that program testing is easy.CHAPTER 5Module (Unit) TestingUp to this point we have largelyignored the mechanics of testing and the size of the program beingtested. However, large programs (say, programs of 500 statements ormore) require special testing treatment. In this chapter we consideran initial step in structuring the testing of a large program: moduletesting. Chapter 6 discusses the remaining steps.Module testing (or unit testing) is a process of testing the individual subprograms, subroutines, or procedures in a program. That is,rather than initially testing the program as a whole, testing is firstfocused on the smaller building blocks of the program. The motivations for doing this are threefold. First, module testing is a wayof managing the combined elements of testing, since attention isfocused initially on smaller units of the program.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
