129–145.
A. A. Porter, H. P. Siy, C. A. Toman, and L. G. Votta, “An Experiment to Assess the Cost-Benefits of Code Inspection in Large Scale Software Development,”IEEE Transactions on Software Engineering, Vol. 23, No. 6, June 1997, pp. 329–346.
A. A. Porter and L. G. Votta, “What Makes Inspection Work,”IEEE Software, Vol. 14, No. 5, May 1997, pp. 99–102.
C. Sauer, D. Jeffery, L. Land, and P. Yetton, “The Effectiveness of Soft- ware Development Technical Reviews: A Behaviorally Motivated Program of Search,” IEEE Transactions on Software Engineering, Vol. 26, No. 1, January 2000, pp. 1–14.
An alternative non-execution-based technique is formal verification of code. Formal verification consists of mathematical proofs to show that a program is correct. The two most prominent methods for proving program properties are those of Dijkstra and Hoare:
E. W. Dijkstra, A Discipline of Programming, Prentice-Hall, Englewood Cliffs, NJ, 1976.
C. A. R. Hoare, “An Axiomatic Basis of Computer Programming,”Commu- nications of the ACM, Vol. 12, No. 10, October 1969, pp. 576–580. Hoare presented an axiomatic approach in which properties of program fragments are described using preconditions and postconditions. An example statement with a precondition and a postcondition is {PRE} P {POST}, where PRE is the pre- condition, POST is the postcondition, and P is the program fragment. Both PRE and POST are expressed in first-order predicate calculus, which means that they can include the universal quantifier∀(“for all”) and existential quantifier∃(“there exists”). The interpretation of the above statement is that if the program fragment P starts executing in a state satisfying PRE, then if P terminates, P will do so in a state satisfying POST.
Hoare’s logic led to Dijkstra’s closely related “calculus of programs,” which is based on the idea of weakest preconditions. The weakest preconditions R with respect to a program fragment P and a postcondition POST is the set of all states that, when subject to P, will terminate and leave the state of computation in POST. The weakest precondition is written as WP(P, POST).
While mutation testing systematically implants faults in programs by applying syntactic transformations, perturbation testing is performed to test a program’s robustness by changing the values of program data during run time, so that the subsequent execution will either fail or succeed. Program perturbation is based on three parts of software hypothesis as explained in the following:
• Execution: A fault must be executed.
• Infection: The fault must change the data state of the computation directly after the fault location.
• Propagation: The erroneous data state must propagate to an output vari- able.
In the perturbation technique, the programmer injects faults in the data state of an executing program and traces the injected faults on the program’s output. A fault injection is performed by applying a perturbation function that changes the program’s data state. A perturbation function is a mathematical function that takes a data state as its input, changes the data state according to some specified criteria, and produces a modified data state as output. For the interested readers, two excellent references on perturbation testing are as follows:
M. A. Friedman and J. M. Voas, Software Assessment—Reliability, Safety, Testability, Wiley, New York, 1995.
J. M. Voas and G. McGraw,Software Fault Injection—Inoculating Programs Against Errors, Wiley, New York, 1998.
The paper by Steven J. Zeil (“Testing for Perturbation of Program State- ment,” IEEE Transactions on Software Engineering, Vol. 9, No. 3, May 1983, pp. 335–346) describes a method for deducing sufficient path coverage to ensure the absence of prescribed errors in a program. It models the program computation and potential errors as a vector space. This enables the conditions for nondetection of an error to be calculated. The above article is an advanced reading for students who are interested in perturbation analysis.
Those readers actively involved in software configuration management (SCM) systems or interested in a more sophisticated treatment of the topic must read the article by Jacky Estublier, David Leblang, Andr´e V. Hoek, Reidar Conradi, Geoffrey Clemm, Walter Tichy, and Darcy Wiborg-Weber (“Impact of Software Engineering Research on the Practice of Software Configuration Management,” ACM Transactions on Software Engineering and Methodology, Vol. 14, No. 4, October 2005, pp. 383–430). The authors discussed the evolution of software configuration management technology, with a particular emphasis on the impact that university and industrial research has had along the way. This article creates a detailed record of the critical value of software configuration management research and illustrates the research results that have shaped the functionality of SCM systems.
REFERENCES
1. M. E. Fagan. Design and Code Inspections to Reduce Errors in Program Development.IBM Systems Journal, July 1976, pp. 182– 211; reprinted 1999, pp. 258– 287.
2. E. Yourdon.Structured Walkthroughs. Prentice-Hall, Englewood Cliffs, NJ, 1979.
3. D. Parnas and M. Lawford. The Role of Inspection in Software Quality Assurance.IEEE Transac- tions on Software Engineering, August 2003, pp. 674– 676.
4. G. Myers. A Controlled Experimentat in Program Testing and Code Walk-throughs/Inspections.
Communications of the ACM, September 1978, pp. 760– 768.
5. H. Sutter and A. Alexandrescu.C++Coding Standards: 101 Rules, Guidelines, and Best Practices. Addison-Wesley, Reading, MA, 2004.
REFERENCES 85