R. A. DeMillo, R. J. Lipton, and F. G. Sayward. Hints for test data selection: help for the practicing programmer. IEEE Computer, 11(4):34--41, Apr. 1978.  Home/Search   Document Not in Database   Summary   Related Articles   Check

.... methodology, but we are already working in four directions to improve its correctness and efficiency : in order to improve time generation, we are working on STCS solver for domain propagations and constraint store analysis ; for each test vector we plan to implement several mutations [12] in order to increase the efficiency of the errors detection ; in order to improve false path detection, symbolic manipulations of constraints are needed ; comparing coverage of the VHDL model with functional coverage of the corresponding ISS, using the same test vectors, remains to be ....

R. A. DeMillo, R. J. Lipton, and F. G. Sayward, "Hints on test data selection: Help for the practicing programmer," IEEE Computer, pp. 34--41, April 1978.

....secure whilst our assumptions hold, but we need to consider what happens if they do not, and what the likelihood of this is. In practice we need to consider the operation of the system under normal conditions and also under various failure conditions. 1. 2 Mutation testing Mutation testing [5] is the best known software fault injection technique. It is used to assess how thoroughly a test set exercises a program. Small syntactic variants of programs are derived; these mutants di er from the original source program in a very small way, for example, a single operator may be replaced ....

R. A. DeMillo, R. J. Lipton, and F. G. Sayward. Hints on Test Data Selection: Help for the Practicing Programmer. IEEE Computer, 11(4):34-41, April 1978.

....complete test cases [31] A completely di erent approach to generating counterexamples is modifying the source code of the model checker to nd counterexamples with certain qualities. However, this approach is beyond the scope of the paper. 1. 3 Speci cation Mutation Criterion Mutation adequacy [9] is a test criterion that naturally yields negative requirements. The speci cation based mutation analysis scheme in [3] applies mutation operators to the state machine or the temporal logic expressions yielding a set of faulty, or mutant, expressions. Some common mutation operators are: ....

Richard A. DeMillo, Richard J. Lipton, and Frederick G. Sayward. Hints on test data selection: Help for the practicing programmer. IEEE Computer, 11(4):34-41, April 1978.

....for good design and development practices, testing is necessary to con rm the quality of an implementation. Thus the tester must choose some relatively tiny set of tests. Can a tiny set of tests, no matter how chosen, really be expected to detect most faults The coupling e ect hypothesis [21], supported in [38] states that tests that detect simple faults are likely to detect complex faults, too. Thus the tester has some con dence that choosing tests to nd simple faults may suce. Test sets can be chosen by many di erent criteria, such as, random sample, frequency of use, critical ....

....transition pair coverage requires the execution for every state of every combination of transitions into and out of that state. Finally, branch coverage requires that every case in SMV next statements is exercised. 3. 1 Speci cation Based Mutation Coverage Traditional program mutation analysis [21] is a code based method for developing a test set that is sensitive to small syntactic changes to the structure of a program. Following is a theoretical foundation for mutation analysis of state machine descriptions such as might be found in SMV or Spin. We are interested in generating and ....

Richard A. De Millo, Richard J. Lipton, and Frederick G. Sayward. Hints on test data selection: Help for the practicing programmer. IEEE Computer, 11(4):34-41, April 1978.

....Australia. Email: tychen it.swin.edu.au. HKU CSIS Tech Report TR 2002 06 HKU CSIS Tech Report TR 2002 06 HKU CSIS Tech Report TR 2002 06 HKU CSIS Tech Report TR 2002 06 HKU CSIS Tech Report TR 2002 07 better performances. The mutation adequacy (or relative adequacy) criteria were introduced [5, 15, 16] to provide a realistic approach for determining whether a test set is relatively sufficient. It restricts the faulty programs to a smaller set, possibly finite in size. Such faulty programs can be differentiated from the original program by a test set that is also finite. Thus, suppose p is a ....

R. A. DeMillo, R. J. Lipton, and F. G. Sayward, Hints on test data selection: help for the practicing programmer, IEEE Computer 11 (4) (1978) 34--41.

....to category partition testing is to target the generation of test data at revealing specific faults in the implementation that can be represented as mutations of the specification. This method of test data generation (hereafter referred to as fault based) was inspired by mutation testing [Bud85, DLS78] Mutation testing involves generating a number of copies of the program under test, each modified slightly to represent a fault typical of those that might occur during actual development. Test data that are generated to detect these faults (kill the mutants) are then assumed to have a good ....

....improvement efforts. For example, Chapter 5 describes how test sets can be automatically generated based on a formal specification of the test criteria. These test sets can be automatically applied to the implementation and many mutations (deliberately incorrect versions of the implementation) DLS78] in order to assess the tests effectiveness at detecting particular faults. This information can be fed back into the process for deciding which test criteria to use. Mutation analysis has the advantage of being an automated approach to assessing a test set s ability to detect certain classes of ....

Richard A. DeMillo, Richard J. Lipton, and Frederick G. Sayward. Hints on test data selection: Help for the practicing programmer. IEEE Computer, pages 34--41, April 1978.

....in [1, 2] One begins with some system speci cations and, through nite modeling and with the aid of automated tools, turns them into speci cations suitable for a model checker. After this point all processing can be automatic. 2. 1 Background on Mutation Analysis Standard mutation analysis [12] is a method based on program source code to develop a set of test cases which is sensitive to small syntactic changes to a 3 modeling specs generate mutants mutant specs model generate tests drivers test harness drivers source execute test results analyze ....

Richard A. De Millo, Richard J. Lipton, and Frederick G. Sayward. Hints on test data selection: Help for the practicing programmer. IEEE Computer, 11(4):34-41, April 1978.

....of P. Let r be a rule according to which P is changed. r is also known as a operator . There could potentially be an infinite number of mutant operators. However, to keep mutation testing within reasonable bounds, the set of mutant operators is kept small and consists of simple mutant operators [2, 4, 7, 20]. Consider, for example, a mutant operator that generates two routants of P by replacing a use of x by x d i and x 1. When applied to a program containing the assignment statement z : x d , this mutant operator will generate two routants of P, one obtained by replacing this assignment by z ....

R. A. DeMillo, R. J. Lipton, and F. G. Sayward, "Hints on test data selection: Help for the practicing programmer," IEEE Computer, 11(4):34 41, April 1978.

....However, from these results, we do not see how one can make convincing arguments about the relative fault detection effectiveness of constrained mutation and the all uses criterion. 3 An overview of mutation and data flow testing Details of data flow and mutation testing may be found in [7, 8, 23]. Below we overview the two methods presenting only the details required for an understanding of the remaining sections. Let P denote a program under test. D is the set of all possible test cases in the input domain of P. A test case is a sequence of inputs that is input to P during one execution ....

....Let v be a rule according to which P is changed. r is also known as a mutant operator. There could potentially be an infinite number of mutant operators. However, to keep mutation testing within reasonable bounds, the set of mutant operators is kept small and consists of simple mutant operators [3, 8]. Consider, for example, a mutant operator that generates two routants of P by replacing a use of x by x d 1 and x 1. When applied to a program containing the assignment statement z : x d y, this mutant operator will generate two routants of P, one obtained by replacing this assignment by z ....

R. A. DeMillo, R. J. Lipton, and F. G. Sayward, "Hints on test data selection: Help for the practicing programmer," IEEE Computer, 11(4):34 41, April 1978.

....design can be viewed as a reverse program synthesis problem of nding adequate abstractions [2, 1, 3] In this paper we focus on mutation testing and its relation to re nement. 1. 1 Mutation Testing Mutation testing is a fault based testing technique introduced by Hamlet [9] and DeMillo et al. [7]. It is a means of assessing test suites. When a program passes all tests in a suite, mutant programs are generated and the suite is assessed in terms of how many mutants it distinguishes from the original program. If some mutants pass the test suite, additional test cases are designed until all ....

....test case) that is able to detect this error due to a mutated requirement in an implementation of the Min speci cation. However, not all changes in a contract actually produce mutants that re ect errors in the original contract. This e ect in program mutations has been reported by DeMillo et al. [7] and it holds for general contracts, too. Consider again our previous contract: Example 4.2 A mutation m 2 might change the operator in Min to leading to another mutant Min 2 : Min 2 , if x y then [z : z The mutant Min 2 is equivalent to Min from an extensional view of a tester. ....

[Article contains additional citation context not shown here]

R. DeMillo, R. Lipton, and F. Sayward. Hints on test data selection: Help for the practicing programmer. IEEE Computer, 11(4):34-41, April 1978.

....paths. Keywords software testing, mutation testing, constraints, feasible path analysis The Journal of Software Testing, Verification, and Reliability, Vol 7, No. 3, pages 165 192, September 1997. 1 Introduction Mutation testing is a technique, originally proposed by DeMillo et al. DLS78] and Hamlet [Ham77] that requires testers to create test data that cause a finite, well specified set of faults to result in failure. The testers do this by finding test cases that cause faulty versions of the program to fail. These test cases will then either result in correct output from the ....

R. A. DeMillo, R. J. Lipton, and F. G. Sayward. Hints on test data selection: Help for the practicing programmer. IEEE Computer, 11(4):34--41, April 1978.

....Our results indicate that weak mutation can be applied in a manner that is almost as effective as mutation testing, and with significant computational savings. Index Terms: fault based testing, firm mutation, mutation testing, software testing, weak mutation 1 1 INTRODUCTION Mutation testing [6] is a powerful technique for unit level software testing that, as usually implemented [4] is computationally expensive. Weak mutation testing was proposed by Howden [13] as a refinement and extension of his earlier work on algebraic testing [12] and Foster s work [8] He suggested a modification ....

....for unit testing. In this introduction, we summarize strong mutation testing, describe weak mutation testing, and then review some related work. 1. 1 Strong Mutation Testing Mutation testing is a fault based technique for unit testing of software that has been widely studied in recent years [4, 6, 10, 15, 25]. Fault based testing strategies are based on the notion of testing for specific kinds of faults. Mutation testing describes faults as simple syntactic changes to a program, called mutations. These mutations are used to create mutant versions of a test program, and test data are created to cause ....

[Article contains additional citation context not shown here]

R. A. DeMillo, R. J. Lipton, and F. G. Sayward. Hints on test data selection: Help for the practicing programmer. IEEE Computer, 11(4):34--41, April 1978.

....portions of the code that are not included in any executable du path or in any executable simple OI path, it is possible to construct programs for which these criteria are less likely to expose a fault than branch testing. 4 Mutation Testing We next consider the mutation testing criterion [3]. Unlike the other criteria examined so far, mutation testing is not a path oriented criterion. Instead, it considers a test suite T adequate for testing program P if T distinguishes P from each of a set of variants of P called mutants. These mutants are formed by applying mutation operators, ....

R. A. DeMillo, R. J. Lipton, and F. G. Sayward. Hints on test data selection: Help for the practicing programmer. Computer, 11(4):34--41, Apr. 1978.

....is at the program source code level. Ritchey and Ammann used a model checker to provide comprehensive attack scenarios to test heterogeneous networks [25] Ramakrishnan and Sekar used a model checker to carry out a related analysis in single host systems [24] Traditional program mutation analysis [10] is a code based method for developing a test set that is sensitive to small syntactic changes to the structure of a program. A variety of researchers, including the current authors, have adapted mutation analysis to the specification level [3, 13, 14, 27] What is new in the present work is the ....

R. A. De Millo, R. J. Lipton, and F. G. Sayward. Hints on test data selection: Help for the practicing programmer. IEEE Computer, 11(4):34--41, April 1978.

....by other test methods, such as dataflow testing, or logic based testing. Coverage measurement is widely supported by software development tool vendors [Paxs98, SR] Mutation testing. Mutation testing is an error oriented structural approach to software testing introduced by DeMillo et al. in [DeMi78]. Mutation testing considers programs, termed mutants, that differ from the given program by only simple errors, such as replacing by in one conditional expression. The task of the tester is to construct tests that distinguish the mutants from the given program. Mutation testing provides a ....

R. A. DeMillo, R. J. Lipton, and F. G. Sayward. Hints on test data selection: help for the practicing programmer. Computer, pages 34--41, April 1978.

....proposed the initial concepts of mutation in a class term paper titled Fault Diagnosis of Supported by the National Science Foundation under awards CCR 9804011 and CCR 9707792. Computer Programs. It was not until the end of the 1970 s, however, before major work was published on the subject [1, 2, 3]; the DeMillo, Lipton, and Sayward paper [3] is generally cited as the seminal reference. PIMS [1, 4, 5, 6] an early mutation testing tool, pioneered the general process typically used in mutation testing of creating mutants (of Fortran IV programs) accepting test cases from the users, and then ....

....term paper titled Fault Diagnosis of Supported by the National Science Foundation under awards CCR 9804011 and CCR 9707792. Computer Programs. It was not until the end of the 1970 s, however, before major work was published on the subject [1, 2, 3] the DeMillo, Lipton, and Sayward paper [3] is generally cited as the seminal reference. PIMS [1, 4, 5, 6] an early mutation testing tool, pioneered the general process typically used in mutation testing of creating mutants (of Fortran IV programs) accepting test cases from the users, and then executing the test cases on the mutants to ....

[Article contains additional citation context not shown here]

R. A. DeMillo, R. J. Lipton, and F. G. Sayward, \Hints on test data selection: Help for the practicing programmer," IEEE Computer, vol. 11, pp. 34-41, April 1978.

....testing for simple faults, we are also implicitly testing for more complicated faults, giving us confidence that fault based testing is an effective way to test software. 1 INTRODUCTION Fault based testing is a general strategy for testing software that has been widely studied in recent years [5, 6, 12, 17, 20, 21, 22]. Fault based testing strategies are based on the notion of testing for specific kinds of faults and succeed because programmers tend to make certain types of faults that can be well defined. Since the number of possible faults for a given program can be large, fault based testing strategies ....

....faults for a given program can be large, fault based testing strategies assume that by testing for certain restricted classes of faults, we can find a wide class of faults. The set of faults is commonly restricted by two principles, the Competent Programmer Hypothesis [1] and the Coupling Effect [6]. The Competent Programmer Hypothesis states that competent programmers tend to write programs that are close to being correct. In other words, a program written by a competent programmer may be incorrect, but it will differ from a correct version by relatively simple faults. The Coupling ....

[Article contains additional citation context not shown here]

R. A. DeMillo, R. J. Lipton, and F. G. Sayward. Hints on test data selection: Help for the practicing programmer. IEEE Computer, 11(4):34--41, April 1978.

....through several mutation systems. The mutation operators are limited to simple changes on the basis of the coupling effect, which says that complex faults are coupled to simple faults in such a way that a test data set that detects all simple faults in a program will detect most complex faults [3]. The coupling effect has been supported experimentally [9] and theoretically [8] The mutation testing process begins with the construction of mutants of a test program. The user then adds test cases (generated manually or automatically) to the mutation system and checks the output of the ....

R. A. DeMillo, R. J. Lipton, and F. G. Sayward. Hints on test data selection: Help for the practicing programmer. IEEE Computer, 11(4):34--41, April 1978.

....must be an approximation, but we wish to know whether such an approximation might yield a prioritization technique superior in terms of rate of fault detection than techniques based solely on code coverage. To approximate the fault exposing potential (FEP) of a test case we used mutation analysis [7, 15]. Given program P and test suite T , for each test case t 2 T , for each statement s in P , we determined the mutation score ms(s; t) of t on s to be the ratio of mutants of s exposed by t to total mutants of s. We then calculated, for each test case t k in T , an award value for t k , by summing ....

Richard A. DeMillo, Richard J. Lipton, and Frederick G. Sayward. Hints on Test Data Selection: Help for the Practicing Programmer. Computer, 11(4):34--41, April 1978.

....adequacy criteria, that is, criteria that are used to determine when software has been tested enough , and can be released. Numerous test data adequacy criteria have been proposed, including those based on control flow analysis [25, 26] data flow analysis [23, 29, 31, 34] and program mutation [9]. Tools based on several of these criteria have been built [8, 14, 28] and many theoretical studies of their formal properties and of certain aspects of their relations to one another have been done [6, 12, 15, 34] But surprisingly, relatively little work has focussed on the crucial question: how ....

....cases satisfied the LCSAJ, all edges, required pairs, and TER n criteria. Several studies of this nature have been performed on mutation testing; for example, DeMillo, Lipton, and Sayward measured the extent to which randomly generated test sets satisfied mutation testing on the buggyfind program [9], and Offutt measured the extent to which test sets that kill first order mutants also kill second order mutants [32] Note that this type of study does not address the question of error detecting ability. While the above cited studies each contributed in some way toward better understanding of ....

R. A. DeMillo, R. J. Lipton, and F. G. Sayward. Hints on test data selection: Help for the practicing programmer. Computer, 11(4):34--41, Apr. 1978.

....discuss techniques that can be useful in program analysis systems such as debuggers, testing systems, and development environments. Mutation analysis Techniques for generating sets of test data include path coverage [2] symbolic testing [3] functional testing [4] as well as mutation analysis [5, 6]. The references [7, 8] survey these and other techniques. Because software testing cannot guarantee program correctness [2] these techniques 2 do not attempt to establish the absolute correctness of a program but to provide the tester with some level of confidence in the program. Although ....

....analysis has been shown analytically and experimentally to be a generalization of other test methodologies [9, 10] Thus, a mutation analysis testing tool gives a tester the capabilities of several other test techniques as well as features that are unique to mutation testing. Mutation analysis [5, 11] helps the user create test data and then interacts with the user to improve the quality of that test data. Mutation analysis involves constructing a set of mutants of the test program, each of which is a version of the test program that differs from the original by one mutation. A mutation is a ....

R. A. DeMillo, R. J. Lipton and F. G. Sayward, `Hints on test data selection: help for the practicing programmer', IEEE Computer 11, (4), 34-41 (April 1978).

....of the Mothra mutation testing software system. HyperMothra currently runs on a sixteen processor Intel iPSC 2 hypercube, but its design is applicable to any MIMD computer. Overview of Mutation Testing Mutation testing is a software testing technique based on the notion of relative adequacy [3]: Definition. If P is a program to implement function F and Pi is a collection of programs, then test set T is adequate for P relative to Pi if P(t) F(t) 8 t2T, and 8 Q 2 Pi, where Q is incorrect, Q 6= F ) 9 t2T such that Q(t)6=F(t) In other words, a test set is adequate if it distinguishes ....

....perturbation; the mutation operators also directly model many types of faults. Each mutation operator is said to create a different mutant type. The faults considered by relative adequacy are commonly restricted by two principles, the competent programmer hypothesis [1] and the coupling effect [3]. The 1 competent programmer hypothesis states that competent programmers tend to write programs that are close to being correct. In other words, a program written by a competent programmer may be incorrect, but it will differ from a correct version by only a few faults. The coupling effect ....

R. A. DeMillo, R. J. Lipton, and F. G. Sayward. Hints on test data selection: Help for the practicing programmer. IEEE Computer, 11(4):34--41, April 1978.

....that can be targeted with standard ATPG tools. This provides a method to generate tests with a provably high coverage for certain classes of modeled errors. A second method originated from observing the similarities between software testing and hardware design verification. Mutation testing [11] considers programs, termed mutants, that differ from the program under test by a single simple error. The rationale for the approach is supported by two hypotheses: 1) programmers write programs that are close to correct ones, and 2) a test set that distinguishes a program from all its mutants is ....

R. A. DeMillo, R. J. Lipton, and F. G. Sayward, "Hints on test data selection: Help for the practicing programmer", IEEE Computer, pp. 34--41, April 1978.

....coverage divides program inputs into subsets where each test case in a subset will cause the same statement to be reached. Fault based testing is a general strategy for developing test data that divides test data into subsets that will detect the same general kinds of faults. Mutation testing [DLS78, DO91, Ham77] is one such fault based testing method. Supported in part by the National Science Foundation under grant CCR 93 11967. Much of this work was done while the authors were with Clemson University. 1 Original Program With Embedded Mutants INTEGER FUNCTION Min (I,J) INTEGER FUNCTION ....

R. A. DeMillo, R. J. Lipton, and F. G. Sayward. Hints on test data selection: Help for the practicing programmer. IEEE Computer, 11(4):34--41, April 1978.

....The test cases considered in the method constitute a complete test suite, that is, all test cases include both inputs and expected results. Model checking is a formal technique for verifying that temporal logic expressions are consistent with all executions of a state machine. Mutation analysis [9] uses mutation operators to introduce small changes, or mutations, into the specification, producing mutant specifications. Better test sets are those which reveal more mutants. Ammann and Black defined a few mutation operators for formal specifications, but did not consider their relative ....

R. A. De Millo, R. J. Lipton, and F. G. Sayward. Hints on test data selection: Help for the practicing programmer. IEEE Computer, 11(4):34--41, April 1978.

No context found.

R. A. DeMillo, R. J. Lipton, and F. G. Sayward. Hints for test data selection: help for the practicing programmer. IEEE Computer, 11(4):34--41, Apr. 1978.

No context found.

Richard A. DeMillo, Richard J. Lipton, and Frederick G. Sayward. Hints on test data selection: Help for the practicing programmer. Computer, 11(4):34--41, April 1978. 21

No context found.

R.A. DeMillo, R.J. Lipton, F.G. Sayward, Hints on Test Data Selection: Help for the Practicing Programmer. IEEE Computer 11(4) (1978) 34-43.

No context found.

R. DeMillo, R. Lipton, and F. Sayward. Hints on test data selection: Help for the practicing programmer. IEEE Transactions on Computers, 12(4):34--41, Apr. 1978.

No context found.

R.A. DeMillo, R.J. Lipton, F.G. Sayward, Hints on Test Data Selection: Help for the Practicing Programmer. IEEE Computer 11(4) (1978) 34-43.

No context found.

R. A. DeMillo, R. J. Lipton, and F. G. Sayward. Hints on test data selection: help for the practicing programmer. IEEE Computer, 11 (4): 34--41, 1978.

No context found.

Richard A. DeMillo, Richard J. Lipton, and Frederick G. Sayward. Hints on test data selection: Help for the practicing programmer. IEEE Computer, pages 34--41, April 1978.

No context found.

R. De Millo, R. Lipton, and F. Sayward. Hints on test data selection : Help for the practicing programmer. IEEE Computer, 11:34--41, 1978.

No context found.

R. DeMillo, R. Lipton, and F. Sayward, "Hints on Test Data Selection : Help For The Practicing Programmer", IEEE Computer, Vol. 11, pp. 34-41, 1978.

No context found.

R. DeMillo, R. Lipton, and F. Sayward, "Hints on Test Data Selection : Help For The Practicing Programmer," IEEE Computer, vol. 11, pp. 34-41, 1978.

No context found.

R. DeMillo, R. Lipton, and F. Sayward, "Hints on Test Data Selection : Help For The Practicing Programmer," IEEE Computer, Vol. 11, pp. 34-41, 1978.

No context found.

R. DeMillo, R. Lipton, and F. Sayward, "Hints on Test Data Selection : Help For The Practicing Programmer," IEEE Computer , vol. 11, pp. 34-41, 1978.

No context found.

R. DeMillo, R. Lipton, and F. Sayward, "Hints on Test Data Selection : Help For The Practicing Programmer". IEEE Computer. Vol.11(4), p. 34-41, 1978.

No context found.

R. DeMillo, R. Lipton, and F. Sayward, "Hints on Test Data Selection : Help For The Practicing Programmer", IEEE Computer, vol. 11, pp. 34-41, 1978.

No context found.

R. DeMillo, R. Lipton, and F. Sayward, "Hints on Test Data Selection : Help For The Practicing Programmer". IEEE Computer. Vol.11(4), p. 34-41, 1978.

No context found.

R. A. DeMillo, R. J. Lipton, and F. G. Sayward. Hints on test data selection: Help for the practicing programmer. IEEE Comp, 11(4):34--41, 1978.

No context found.

R. DeMillo, R. Lipton, and F. Sayward. Hints on test data selection: Help for the practicing programmer. Computer, 11(4), April 1978.

No context found.

R. A. DeMillo, R. J. Lipton, and F. G. Sayward. Hints on test data selection: Help for the practicing programmer. IEEE Computer, 11(4):34--43, 1978.

No context found.

Richard A. DeMillo, Richard J. Lipton, and Frederick G. Sayward. Hints on test data selection: help for the practicing programmer. Computer, 11(4):34--41, April 1978.

No context found.

R. A. DeMillo, R. J. Lipton, F. G. Sayward, Hints on test data selection: Help for the practicing programmer, IEEE Computer 11 (4) (1978) 34--41.

No context found.

Richard A. DeMillo, Richard J. Lipton, and Frederick G. Sayward. Hints on test data selection: Help for the practicing programmer. IEEE Computer, pages 34-41, April 1978.

No context found.

R. A. DeMillo, R. J. Lipton, and F. G. Sayward. Hints on test data selection: Help for the practicing programmer. Computer, 4(11):34--41, Apr. 1978.

No context found.

Richard A. DeMillo, Richard J. Lipton, and Frederick G. Sayward. Hints on test data selection: Help for the practicing programmer. Computer, 11(4):34--41, April 1978. 21

No context found.

Richard A. DeMillo, Richard J. Lipton, and Frederick G. Sayward. Hints on test data selection: Help for the practicing programmer. Computer, 11(4):34--41, April 1978. 21

No context found.

R. A. DeMillo, R. J. Lipton and F. G. Sayward, `Hints on test data selection: help for the practicing programmer', IEEE Computer, 11, (4), 34--41 (1978).

First 50 documents  Next 50

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC