Abstract: In testing a system, coverage of the testing is obtained by maintaining a store of information that is populated as the testing progresses. The store maintains information about the ranges of system variables that are employed during the testing. At the conclusion of the testing, the coverage of the testing is reported out, to permit the designer to assess whether other queries ought to be formulated, or whether portions of the system are superfluous. The testing can employ simulations, formal verifications, or some other techniques.

Abstract: Testing of an electronic system is optimized by using a single set of sub-tests and varying the testing sequence to produce tests tailored for different purposes such as screening and diagnostic testing. For example, a programmable test sequencer in the electronic system responds to a test selection variable by using a first sequence of the sub-tests to optimize the testing process for screening and a second sequence of the sub-tests to optimize the testing process for diagnostic testing. In the diagnostic mode, the sub-tests are run so that each sub-test builds upon the previous sub-tests and uses previously-tested hardware to verify additional hardware. In the screening mode, the sub-tests are the same, but the execution order of the sub-tests is reversed so that more complex hardware is tested first as a screening mechanism.

Abstract: Software installation and/or testing of software/hardware on a build-to-order computer system (160) is automated. A descriptor file, containing a series of component (hardware/software) descriptors, is used to obtain a set of steps, which relate to installation/testing, from a database (100) (eg. relational database, Fig 6). Each step has an associated sequence number which is used to sequence the steps. The compatibility between steps and components is check through processing compatibility information stored on the database. Steps may need to be removed or altered depending on their compatibility. For each step it is determined if that step requires a parameter, if so the parameter's value is calculated. A progress or log file is kept during the installation/testing of the system to ensure the correct sequence of steps is followed. Installation/testing may either be carried out using a setup disk (Fig. 1) or a over a network (Fig 2.).

Abstract: Summary form only given. Arithmetic coprocessors (AC) are quite complex circuits and testing them is an important and not easy problem (not covered in the literature). Analyzing diagnostic software for IBM PCs we found that the testing procedures for ACs are limited to simple basic checks. Hence we decided to develop efficient test procedures in a systematic way. They are executed on the main processor and generate appropriate stimuli to AC functional blocks (e.g. instruction sequencer, data path units) and verify test responses. An important contribution of this paper is the integration of various approaches to testing and increased test observability of test results assured by on-chip event monitors and system exceptions.

Abstract: In order to improve reliability and quality, software systems should be tested. The testing of object-oriented software systems is more complex than that of traditional programming. Recently, we have proposed an approach to select a finite number of representative equivalent pairs as test cases from the infinite set of all equivalent pairs. The approach is based on the concept of equivalent fundamental pairs. We analyze the effectiveness of this approach using a class graph. A class graph can be derived from the syntax declaration of the algebraic specification for the given class under test. Using the class graph, we show that our approach omits many testing paths in the class graph but doesn't reduce the testing effect. Hence, the testing efficiency is improved greatly.

Abstract: One of the characteristics of object-oriented software is the complex dependency that may exist between classes due to inheritance, association and aggregation relationships. Hence, where to start testing and how to define an integration strategy are issues that require further investigation. This paper presents an approach to define a test order by exploiting a model produced during design stages (e.g., using OMT, UML), namely the class diagram. Our goal is to minimize the number of stubs to be constructed in order to decrease the cost of testing. This is done by testing a class after the classes it depends on. The novelty of the test order lies in the fact that it takes account of: (i) dynamic (polymorphism) dependencies; (ii) abstract classes that cannot be instantiated, making some testing levels infeasible. The test order is represented by a graph showing which testing levels must be done in sequence and which ones may be done independently. It also provides information about the classes involved in each level and how they are involved (e.g., instantiation or not). The approach is implemented in a tool called TOONS (testing level generator for object-oriented software). It is applied to an industrial case study from the avionics domain.