Some conservative stopping rules for the operational testing of safety critical software | IEEE Journals & Magazine | IEEE Xplore

Some conservative stopping rules for the operational testing of safety critical software


Abstract:

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 b...Show More

Abstract:

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 failure-free. This paper addresses the problem of specifying the numbers of test cases (or time periods) required for a test, when the previous 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, in as much 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.
Published in: IEEE Transactions on Software Engineering ( Volume: 23, Issue: 11, November 1997)
Page(s): 673 - 683
Date of Publication: 06 August 2002

ISSN Information:


Contact IEEE to Subscribe

References

References is not available for this document.