The art of software testing. Myers (2nd edition) (2004) (The art of software testing. Myers (2nd edition) (2004).pdf), страница 9

Comparisons of base-2fractional values?7. Operator precedence understood?8. Compiler evaluation of Booleanexpressions understood?36Table 3.2Inspection Error Checklist Summary, Part IIControl Flow1. Multiway branches exceeded?2. Will each loop terminate?3. Will program terminate?Input/Output1. File attributes correct?2. OPEN statements correct?3.

Format specification matchesI/O statement?4. Buffer size matches record size?4. Any loop bypasses because ofentry conditions?5. Are possible loop fall-throughscorrect?6. Off-by-one iteration errors?7. DO/END statements match?8. Any nonexhaustive decisions?9. Any textual or grammaticalerrors in output information?5. Files opened before use?6. Files closed after use?7.

End-of-file conditions handled?8. I/O errors handled?InterfacesOther Checks1. Number of input parameters1. Any unreferenced variables inequal to number of arguments?cross-reference listing?2. Parameter and argument2. Attribute list what was expected?attributes match?3. Parameter and argument units3.

Any warning or informationalsystem match?messages?4. Number of arguments4. Input checked for validity?transmitted to called modulesequal to number of parameters?5. Attributes of arguments trans5. Missing function?mitted to called modules equalto attributes of parameters?6. Units system of arguments transmitted to called modules equalto units system of parameters?7.

Number, attributes, and order ofarguments to built-in functionscorrect?8. Any references to parameters notassociated with current point of entry?9. Input-only arguments altered?10. Global variable definitionsconsistent across modules?11. Constants passed as arguments?3738The Art of Software TestingOther Checks1. If the compiler produces a cross-reference listing of identifiers, examine it for variables that are never referenced or arereferenced only once.2. If the compiler produces an attribute listing, check the attributes of each variable to ensure that no unexpected defaultattributes have been assigned.3. If the program compiled successfully, but the computer produced one or more “warning” or “informational” messages,check each one carefully. Warning messages are indicationsthat the compiler suspects that you are doing something ofquestionable validity; all of these suspicions should bereviewed. Informational messages may list undeclared variables or language uses that impede code optimization.4.

Is the program or module sufficiently robust? That is, does itcheck its input for validity?5. Is there a function missing from the program?This checklist is summarized in Tables 3.1 and 3.2 on pages 36–37.WalkthroughsThe code walkthrough, like the inspection, is a set of procedures anderror-detection techniques for group code reading. It shares muchin common with the inspection process, but the proceduresare slightly different, and a different error-detection technique isemployed.Like the inspection, the walkthrough is an uninterrupted meetingof one to two hours in duration. The walkthrough team consists ofthree to five people. One of these people plays a role similar to that ofthe moderator in the inspection process, another person plays the roleof a secretary (a person who records all errors found), and a third person plays the role of a tester.

Suggestions as to who the three to fiveProgram Inspections, Walkthroughs, and Reviews39people should be vary. Of course, the programmer is one of thosepeople. Suggestions for the other participants include (1) a highlyexperienced programmer, (2) a programming-language expert, (3) anew programmer (to give a fresh, unbiased outlook), (4) the personwho will eventually maintain the program, (5) someone from a different project, and (6) someone from the same programming team as theprogrammer.The initial procedure is identical to that of the inspection process:The participants are given the materials several days in advance toallow them to bone up on the program. However, the procedure inthe meeting is different. Rather than simply reading the program orusing error checklists, the participants “play computer.” The persondesignated as the tester comes to the meeting armed with a small setof paper test cases—representative sets of inputs (and expected outputs) for the program or module.

During the meeting, each test caseis mentally executed. That is, the test data are walked through thelogic of the program. The state of the program (i.e., the values of thevariables) is monitored on paper or whiteboard.Of course, the test cases must be simple in nature and few in number, because people execute programs at a rate that is many orders ofmagnitude slower than a machine. Hence, the test cases themselvesdo not play a critical role; rather, they serve as a vehicle for gettingstarted and for questioning the programmer about his or her logicand assumptions. In most walkthroughs, more errors are found during the process of questioning the programmer than are founddirectly by the test cases themselves.As in the inspection, the attitude of the participants is critical.Comments should be directed toward the program rather than theprogrammer.

In other words, errors are not viewed as weaknesses inthe person who committed them. Rather, they are viewed as beinginherent in the difficulty of the program development.The walkthrough should have a follow-up process similar to thatdescribed for the inspection process. Also, the side effects observedfrom inspections (identification of error-prone sections and educationin errors, style, and techniques) also apply to the walkthrough process.40The Art of Software TestingDesk CheckingA third human error-detection process is the older practice of deskchecking.

A desk check can be viewed as a one-person inspection orwalkthrough: A person reads a program, checks it with respect to anerror list, and/or walks test data through it.For most people, desk checking is relatively unproductive. Onereason is that it is a completely undisciplined process. A second, andmore important, reason is that it runs counter to a testing principle ofChapter 2—the principal that people are generally ineffective in testing their own programs. For this reason, you could deduce that deskchecking is best performed by a person other than the author of theprogram (e.g., two programmers might swap programs rather thandesk check their own programs), but even this is less effective thanthe walkthrough or inspection process. The reason is the synergisticeffect of the walkthrough or inspection team. The team session fosters a healthy environment of competition; people like to show off byfinding errors.

In a desk-checking process, since there is no one towhom you can show off, this apparently valuable effect is missing. Inshort, desk checking may be more valuable than doing nothing at all,but it is much less effective than the inspection or walkthrough.Peer RatingsThe last human review process is not associated with program testing(i.e., its objective is not to find errors). This process is included here,however, because it is related to the idea of code reading.Peer rating is a technique of evaluating anonymous programs interms of their overall quality, maintainability, extensibility, usability,and clarity. The purpose of the technique is to provide programmerself-evaluation.A programmer is selected to serve as an administrator of theprocess.

The administrator, in turn, selects approximately 6 to 20 participants (6 is the minimum to preserve anonymity). The participantsProgram Inspections, Walkthroughs, and Reviews41are expected to have similar backgrounds (you shouldn’t group Javaapplication programmers with assembly language system programmers, for example). Each participant is asked to select two of his orher own programs to be reviewed.

One program should be representative of what the participant considers to be his or her finest work;the other should be a program that the programmer considers to bepoorer in quality.Once the programs have been collected, they are randomly distributed to the participants. Each participant is given four programsto review. Two of the programs are the “finest” programs and two are“poorer” programs, but the reviewer is not told which is which. Eachparticipant spends 30 minutes with each program and then completesan evaluation form after reviewing the program. After reviewing allfour programs, each participant rates the relative quality of the fourprograms.

The evaluation form asks the reviewer to answer, on a scalefrom 1 to 7 (1 meaning definitely “yes,” 7 meaning definitely “no”),such questions as these:•••••Was the program easy to understand?Was the high-level design visible and reasonable?Was the low-level design visible and reasonable?Would it be easy for you to modify this program?Would you be proud to have written this program?The reviewer also is asked for general comments and suggestedimprovements.After the review, the participants are given the anonymous evaluation forms for their two contributed programs. The participants alsoare given a statistical summary showing the overall and detailed ranking of their original programs across the entire set of programs, aswell as an analysis of how their ratings of other programs comparedwith those ratings of other reviewers of the same program.

The purpose of the process is to allow programmers to self-assess their programming skills. As such, the process appears to be useful in bothindustrial and classroom environments.42The Art of Software TestingSummaryThis chapter discussed a form of testing that developers do not oftenconsider—human testing. Most people assume that because programs are written for machine execution machines should test programs as well.