Issue No. 11 - November (1997 vol. 23)
DOI Bookmark: http://doi.ieeecomputersociety.org/10.1109/32.637384
<p><b>Abstract</b>—Operational testing, which aims to generate sequences of test cases with the same statistical properties as those that would be experienced in real operational use, can be used to obtain quantitative measures of the reliability of software. In the case of safety critical software it is common to demand that all known faults are removed. This means that if there is a failure during the operational testing, the offending fault must be identified and removed. Thus an operational test for safety critical software takes the form of a specified number of test cases (or a specified period of working) that must be executed <it>failure-free</it>. This paper addresses the problem of specifying the numbers of test cases (or time periods) required for a test, when the <it>previous</it> test has terminated as a result of a failure. It has been proposed that, after the obligatory fix of the offending fault, the software should be treated as if it were completely novel, and be required to pass exactly the same test as originally specified. The reasoning here claims to be conservative, inasmuch as no credit is given for any previous failure-free operation prior to the failure that terminated the test. We show that, in fact, this is not a conservative approach in all cases, and propose instead some new Bayesian stopping rules. We show that the degree of conservatism in stopping rules depends upon the precise way in which the reliability requirement is expressed. We define a particular form of conservatism that seems desirable on intuitive grounds, and show that the stopping rules that exhibit this conservatism are also precisely the ones that seem preferable on other grounds.</p>
Safety-critical software, software reliability, operational testing, statistical testing, testing stopping rule.
David Wright, Bev Littlewood, "Some Conservative Stopping Rules for the Operational Testing of Safety-Critical Software", IEEE Transactions on Software Engineering, vol. 23, no. , pp. 673-683, November 1997, doi:10.1109/32.637384