scispace - formally typeset
Search or ask a question

Showing papers on "Test harness published in 1978"


Journal ArticleDOI
TL;DR: Test cases can be designed so that their associated subsets cover the entire input domain, allowing reliability estimatesto be made for expected operational use profiles.

175 citations


ReportDOI
01 Mar 1978
TL;DR: The report presents a test description language, NOPAL, in which a user may describe diagnostic tests, and a software system which automatically generates test programs for an automatic test equipment based on the descriptions of tests.
Abstract: : The objective of the research is to design an automation aid for generating test programs that will (1) reduce the required user expertise, (2) reduce labor, (3) enhance efficiency, (4) improve user confidence, and (5) provide documentation for furture utilization and maintenance. The report presents a test description language, NOPAL, in which a user may describe diagnostic tests, and a software system which automatically generates test programs for an automatic test equipment based on the descriptions of tests. The software system accepts as input the tests specified in NOPAL, performs syntax analysis, and constructs a directed graph. Based on the graph the system proceeds to check for consistency, completeness, and unambiguity in the supplied descriptions. The execution sequence of the tests is then optimized. Finally, an efficient program in a test equipment programming language, OPAL, is generated. (Author)

7 citations


Proceedings ArticleDOI
10 May 1978
TL;DR: The TPL/2.0 automatic software test driver described in this paper automates both the initial generation and subsequent revision of test procedure model outputs.
Abstract: An automatic software test driver is a new type of software tool which controls and monitors the execution of software tests. An automatic test driver is controlled by a formal test procedure coded in a special software test language. The test procedure replaces the test data and test setup instructions of conventional testing. The specific goals of automatic test drivers are to eliminate the need for writing drivers and stubs for module and subsystem testing, to provide a standard format and language for specifying software tests, to provide a standard execution setup for software tests, and to automate the verification of test execution results.A test procedure contains input data to be supplied to the program under test and model outputs against which actual outputs of the target program are verified. Typically, ninety percent or more of the text of a test procedure consists of model outputs which must be revised each time the target program is modified. The TPL/2.0 automatic software test driver described in this paper automates both the initial generation and subsequent revision of test procedure model outputs.

5 citations


Proceedings ArticleDOI
13 Nov 1978
TL;DR: A theory of program testing is presented, based on the idea of "reliable test set", which strengthens the form of specification in the test and restricts the kind of errors that the test must expose.
Abstract: A theory of program testing is presented, based on the idea of "reliable test set." Intuitively, a test is reliable if it exposes all errors that any test could find. To obtain a practical theory, two alterations of this idea are suggested: (1) strengthen the form of specification in the test, (2) restrict the kind of errors that the test must expose. Both of these changes have a natural application to program maintenance.

4 citations


Proceedings ArticleDOI
28 Nov 1978
TL;DR: This paper defines the functions and activi ties involved in testing Automatic Test Equipment (ATE) software as black box testing and four areas of test facility design tradeoffs.
Abstract: This paper defines the functions and activi ties involved in testing Automatic Test Equipment (ATE) software. Software testing is defined here in as black box testing. In addition, an examina tion is made of four areas of test facility design tradeoffs: *simulated versus real software, both software under test and environment simulation soft ware, .organization of the components of executable test software; *selection of the methods of exiting the code under-test during execution; and *selection of the methods of assembling and loading all executable software

1 citations


Journal ArticleDOI
TL;DR: The functions and requirements for an interface between a microprocessor-based test system controller and a digital ‘unit under test’ are investigated and two approaches of testing are compared and discussed.

1 citations


Journal ArticleDOI
01 Jan 1978
TL;DR: IDBUG is presented, a facility called IDBUG that reduces the programming effort required to employ dynamic testing by automating the construction of the test harness and provides an interactive test environment which permits more flexible testing.
Abstract: The construction of a reliable computer program requires, in part, a means of verification of its component parts prior to their integration into the overall system. The verification process may consist of building a test harness to exercise or exhaustively test a procedure. This technique is known as dynamic testing. In practice, the application of dynamic testing requires the coding of a special harness for each procedure. This consumes valuable programming time, as much as 50% of the total effort (FAIR78). It is also restrictive because the test harness cannot be easily modified to test aspects of a program which it was not originally designed to test.We have built a facility called IDBUG that reduces the programming effort required to employ dynamic testing by automating the construction of the test harness. Additionally, it provides an interactive test environment which permits more flexible testing. This paper describes IDBUG and discusses our experience in its application to maintenance tasks in a commercial environment. Nyone of the ideas put forth here will be especially novel; dynamic testing as a software testing tool has been in use for some time. What we hope to do is illustrate the beneficial aspects of a particular application of dynamic testing. It is argued that testing should play a more limited role in assuring the reliability of software in light of techniques such as structured coding, top-down design, proof of correctness, etc. (McG075). While it is true that eventually the “art of computer programming” will become the “science of producing correct programs”, we believe that more emphasis must be placed on interim solutions to aid in the construction of reliable software. We present IDBUG as such a solution.