Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Automated Test and Verification

IP.com Disclosure Number: IPCOM000082496D
Original Publication Date: 1974-Dec-01
Included in the Prior Art Database: 2005-Feb-28
Document File: 2 page(s) / 14K

Publishing Venue

IBM

Related People

Heuermann, CA: AUTHOR [+3]

Abstract

In general, testing at a module level is a manual job. Many of todays methods provide some of the functions needed to automatically test a module, however, Automated Test (AUT) provides a general system to automatically test a unit of code and verify its results. The system also verifies program interfaces and simulates unavailable programs, based solely on the data transformations which the unavailable programs will perform. AUT is passed information via an interface language MIL-S which describes test cases of the module being tested.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 2

Automated Test and Verification

In general, testing at a module level is a manual job. Many of todays methods provide some of the functions needed to automatically test a module, however, Automated Test (AUT) provides a general system to automatically test a unit of code and verify its results. The system also verifies program interfaces and simulates unavailable programs, based solely on the data transformations which the unavailable programs will perform. AUT is passed information via an interface language MIL-S which describes test cases of the module being tested.

The testing system is driven by a test case which defines the external environment needed (input) for the tested program to execute, and the external environment after the tested program has executed this test case (output). A test case defines one path of execution through a program. AUT tests this path by building the inputs from the test case and invoking the module being tested.

The program being tested will then execute using the input built from the test case and, upon completion, returns control to AUT. At this time, the real output from the tested program is available to AUT. The real output consists of the data items identifiable to the testing system. The data items are described by the test case and, from it, the testing system can build an expected output structure. AUT will compare the real output data from the tested program to the expected output data. This comparison will determine if the test case was successful.

The test case is stored on a data base with many other test cases which are used to test the other paths of execution through the program. AUT will run one test case, then go to the data base for the next test case. This cycle is repeated until all test cases have been executed. In this way, AUT automatically tests a program and verifies its results. The steps in the process are:. . Step 1 - Identify interfaces: Identify all supervisor calls issued, external calls to routines, and any other interface which causes other code to get executed during the execution of code. . Step 2 - Determine how to verify the interfaces: In order to automate the testing, the verification has to be done by the use of MIL-S or the use of real code that is executed during the test of the unit of code. If the MIL-S statements for the interface already exist and performs the desired function, they may be used or new test cases...