Glass, Robert. Persistent Software Errors. In IEEE transactions on Software Engineering, pages 162-168, vol. SE-7, No. 2, March 1981.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....the experiment (i.e. creating missing specifications, designing test cases, calculating the amount of time used designing the test cases, etc. The systems measured were C programs consisting of 30 to 272 LOC. Results from such small experiments cannot be generalized to include larger systems [18] or be generalized to other granularities of coverage since each coverage type has different weaknesses [19] Therefore, these findings cannot be generalized to method level coverage. So how much effort is needed to reach 100 method level coverage is unknown. In this research, effort will be ....

Glass, Robert. Persistent Software Errors. In IEEE transactions on Software Engineering, pages 162-168, vol. SE-7, No. 2, March 1981.

....implementation, else why does it exist Since any perfect test suite will test all the features and special cases, it must exercise all the branches. However, high coverage alone does not necessarily mean the test suite is thorough. The fault of omis sion is a common type of bug ( Basili84] [Glass81], Ostrand84] It is exemplified by this code: a = b c; which should read if (c = 0) a = b c; Since you are testing the incorrect program, a branch coverage tool cannot tell you that you need a test where c=0 it can t measure the coverage of a branch that doesn t exist. So a test ....

Robert L. Glass, "Persistent Software Errors", Transactions on Software Engineering, vol. SE-7, No. 2, pp. 162-168, March, 1981.

....was oriented towards differentiating between high level design faults and low level programming faults. Another early error study, Thayer78] provides some of the same level of error analysis that our study provides, but on errors discovered during the testing and validation phases. Glass81] provides another high level, specification oriented picture of software errors discovered during the development process. Basili84] studies the relationship between software errors and complexity. Chillarege 91] provides an analysis of defects found during the test process and their impact on ....

R. Glass. Persistent Software Errors. IEEE Trans. on Software Engineering, SE-7, March 1981

....code surrounding an unsatisfied condition, I discovered an under tested aspect of the specification and added tests for it, even though those tests were not necessary for coverage. This is not uncommon; often these tests probe whether special case code needs to be added to the program. Note that [Glass81] reports that such omitted code is the most important class of fault in fielded systems. These seven test conditions led to four test cases. One of the serendipitous test conditions discovered a fault. Satisfying weak mutation coverage required 3.25 hours, the vast majority of it devoted to ....

....(2) any test suite that achieves high coverage must be good. Yet (1) does not imply (2) In particular, tests designed to satisfy coverage tend to miss faults of missing code, since a tool cannot create coverage conditions for code that ought to be there, but isn t. These are the very faults that [Glass81] found most important in fielded systems. An unexercised coverage condition should be considered a signal pointing to an under exercised part of the specification. New test conditions should be derived from that part, not just from the coverage condition that points to it. This may seem an ....

Robert L. Glass. "Persistent Software Errors". Transactions on Software Engineering, vol. SE-7, No. 2, pp. 162-168, March, 1981.

....patterns or method(ologie)s. It is therefore necessary to classify faults and to determine those of higher frequency for particular dependencies. 4 Taxonomies of Faults In the testing literature there are many references to classifications of faults for particular experiments [BP84, BS87, Wei79, Gla81, OW84, Mar90, RT88] Some experiments also attempted to determine which (structural) technique was more likely to display faults. Coverage testing usually came out with a higher fault determination and localisation than data flow testing and (weak) mutation testing was also considered a powerful ....

R.L. Glass. Persistent Software Errors. IEEE Trans. on Software Engineering, 7(2):162--168, March 1981.

No context found.

Robert L. Glass, "Persistent Software Errors," IEEE Transactions on Software Engineering, Vol. SE-7, No. 2, March, 1981.

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