|
Topics
Center for Software Engineering Home
Orthogonal Defect Classification
Testing
Software Data Analysis
University Partnerships
Publications
Conferences & Workshops
Write Us
|
System Test via
Use Case Based Testing (UCBT)
Overview:
IBM Research has developed Use Case Based Testing (UCBT),
which is a technique for generating test cases and recommended configurations
for system level testing. In our approach, testers build a test model
based on the standard UML notions of use cases, actors, and the relationships
between these elements. The use cases are enhanced with additional
information, including the inputs from actors, the outputs to the
actors, and how the use case affects the state of the system. Newly
developed algorithms use this model to generate a test suite which
provides a specified level of coverage of each use case. We also generate
workload configurations that combine the test cases according to requirements
specified in the model. The generation algorithm performs minimization
to reduce the number of test cases required to cover the system to
the specified level. The workload configurations are based on desired
percentages associated with each actor that the tester provides. These
features form a powerful basis for model-based test case generation.
What testing phase does UCBT address?
UCBT addresses phases where the tester is interested in exploring
behavior that flows through multiple use cases, which are typically
the late function, system, and solution phases of the test life cycle.
In late function level test, the tester has tested the use cases individually,
and is now interested in looking at combinations of the use cases.
System test addresses the situation when all required functionality
for the system is present, and the tester seeks to ensure the proper
functioning of the system as a whole. An important component of system
test is also ensuring that the system can handle customer-like scenarios
and workloads. Solution test addresses the situation in which several
complete systems are combined to provide complex functionality through
some process that involves the systems. These processes can be captured,
modeled, and tested using UCBT.
What does the tester do in UCBT?
To do UCBT, the tester needs to identify four things:
-
the use cases of interest,
-
the actors involved in using the system,
-
the input, output, and system effects for the use
cases,
-
the flows of interest between the use cases.
A use case is a semantically meaningful function that
provides some value from the user's point of view. For example, saving
a file in a word processing system would be represented by the Save
File use case. Each use case can have input parameters associated
with it, and for each parameter, a set of logical partitions of the
values that parameter can take may be identified. Finally, the use
cases can be connected using flows that describe a sequence of use
case that are performed to accomplish some goal.
What is produced by UCBT Tool?
UCBT produces two types of test cases. The first type are abstract
test cases, which are not executable. These are suitable for incorporation
in a test plan and are provided in structured English. They show the
ordering of use cases to be performed and the inputs and expected
results that each use case should have during the test. The second
type of test cases are in a format known as ATS, which can be used
to create executable test cases using another tool known as TCBeans.
TCBeans was developed by IBM Research in Haifa. The test suite produced
by UCBT is minimized in size by performing a two pass optimization
based upon the input parameter interactions that the tester specifies,
as well as the flows of interest. This ensures that the number of
test cases is reasonable, so execution and evaluation can be done
with a feasible amount of effort.
For more information:
The initial work that led to this technique is described in "Efficient
Regression Testing of Multi-Panel Systems" by Clay Williams and
Amit Paradkar. This paper was presented at the International Symposium
on Software Reliability Engineering (ISSRE) in November, 1999.
We will add additional references as they become available.
|