Test Procedure

Dealing with an enormous amount of data is characteristic of validating complex and safety-critical software systems. ATP, a high-level programming language, supports the validation process. In a patient monitor test environment it has shown its usefulness and power by enabling a dramatic increase in productivity. Its universal character allows it to migrate validation scenarios to different products based on other architectural paradigms. by Andreas Pirrung This article concentrates on the specific problem of transforming a test design into concrete automatic test procedures. For a systematic overview and context the reader is referred to Article 12. As described in that article, the test design identifies and documents the test set for a given product. It is derived from external and internal specifications, software quality engineer expertise, and risk and hazard analysis results. A test design is normally informal and describes test cases and test data on a high, abstract level, independent of the test environment. On the other hand, an automatic test procedure has to deal with all the details of the test environment and reflects the abstraction capabilities of the existing tools. In our software quality engineering department the automatic test environment is based upon two major tools: AutoTest1 and AutoCheck. The first is a test execution tool and the latter is responsible for test evaluation (see Article 14). AutoTest is very close to the devices it controls and requires detailed commands on a low abstraction level. AutoCheck has to cope with the detailed low-level information produced by AutoTest and therefore also requires input on a detailed, low abstraction level (see Fig. 1). The strengths of the low-level interfaces are their flexibility and adaptability to various different test situations