Browse Prior Art Database

Testcase Automation Method

IP.com Disclosure Number: IPCOM000105476D
Original Publication Date: 1993-Aug-01
Included in the Prior Art Database: 2005-Mar-19
Document File: 4 page(s) / 151K

Publishing Venue

IBM

Related People

Black, MD: AUTHOR [+3]

Abstract

Runtime-dependent attributes create an inconsistent environment for regression testing, especially in distributed networks with multiprocessing workstations where process numbers and network loads differ at each testcase execution. Current Automation tools are time-dependent and compare only screen outputs. A tool is needed that allows various verification methods to be used across a distributed client/server environment. Actual verification results should be tagged and post-processed to allow the tester to view output of the code-under-test. Common elements used by multiple testcases need universal access to avoid redundancy. This whole process needs to be architected, automated, flexible, an promote code reuse.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 43% of the total text.

Testcase Automation Method

      Runtime-dependent attributes create an inconsistent environment
for regression testing, especially in distributed networks with
multiprocessing workstations where process numbers and network loads
differ at each testcase execution.  Current Automation tools are
time-dependent and compare only screen outputs.  A tool is needed
that allows various verification methods to be used across a
distributed client/server environment.  Actual verification results
should be tagged and post-processed to allow the tester to view
output of the code-under-test.  Common elements used by multiple
testcases need universal access to avoid redundancy.  This whole
process needs to be architected, automated, flexible, an promote code
reuse.

      Described is an automated testcase system as a solution to the
problem described above.  The system consists of a method which
architects testcases in a hierarchical management structure for
control, yet allows testcases to execute in parallel in the
background or on distributed processors.  A tool extracts
code-under-test command output for later verification against known
valid outputs.  Another tool inserts virtual labels in the output
which allows later post-processing.  Common utility tools are called
by testcases from a central repository to increase reuse and testcase
usability and maintainability.  Independence from run-time specific
values and time-variant processes is provided.  Compression of output
before validation to obtain a signature can be used to reduce
verification time.

      The figure describes the main features of this system.  The
operation begins when one of the testcase executables (1) is invoked
from the hierarchical testcase repository (B) to set up a known
initial testcase environment, and the testcases use predefined files
during runtime as well.

      The relationship among testcases is a heirarchical tree
structure, with like testcases grouped into suites managed by a group
master driver.  This is advantageous because:

o   Real world testcases virtually always fall into categories, each
    category correlating to some code-under-test (CUT) function to be
    validated.
o   Groups can be managed mutually exclusively of each other.
o   Groups of testcases can be executed either as background
    processes or on other nodes, with a results rendexvous at the
    point of dispatch.

      The testcase repository, common data repository, and client
testcase engine, and server emgine (D), need not be present on the
same processor.  Alternately, they could all be the same workstation.
Using existing library control systems for the repositories is
possible.

      Testcases are generally a sequential script of actions to
perform, starting from a known state, which produce a target function
or output.  Usually, the steps include environment set up, execution
of the command or code unit under test, capture an...