Seventh International Conference on Computer and Information Technology

An Automatic Tool for Generating Test Cases

from the System's Requirements

Rosziati Ibrahima
Mohd Zainuri Saringat, Noraini Ibrahim and Noraida Ismailb
a
Research Management and Innovation Centre (RMIC),
b
Faculty of Information Technology and Multimedia,
Universiti Tun Hussein Onn Malaysia (UTHM)
rosziati@uthm.edu.my, zainuri@uthm.edu.my, noraini@uthm.edu.my, noraida@menersys.com

Abstract This paper discusses on software testing where

An automatic generator is used to generate
programming codes from a specific domain. We use
this concept to introduce an automatic tool for
software testing, where the tool is used to generate the
test cases automatically according to the system’s
requirements. Manual creation of test cases is time
consuming and high costing. The purpose of producing
the tool to generate test cases automatically is to
reduce the cost of testing the system as well as to save
the time of deriving test cases manually. The system’s
requirements are transformed using use case
diagrams, flow of events and sequence diagrams. The
flow of events and sequence diagrams are used to
check the consistency of the use cases as well as the
validity of test cases.
1. Introduction
Software testing is important when developing a
system. In many organizations, 30 to 50 percent of
software development costs go to testing the system
[3]. Testing is defined as an attempt to reveal errors in
software. The conventional way of software
development life cycle (SDLC - analysis, design,
prototyping, testing) proposed that testing a software is
done at a later stage. However, delaying the testing at a
later stage will make the software testing cost more
and expensive to correct the errors. In object-oriented
software development (OOSD), software testing is
proposed to be done as soon as the system’s
requirements are available. This will avoid postponing
the software testing at the end of the software creation.
Thus, it will minimize the errors and cost of fixing the
errors.
testing shows the present of faults and proposes an
automatic testing tool to generate test cases
automatically. The rest of the paper is organized as
follows. Section 2 presents the related work and
Section 3 discusses the system’s requirements. We also
present our idea on how to convert the use cases into
test cases in Section 3. Section 4 discusses our tool in
details. Finally, we conclude our paper in Section 5
and give some suggestions for future work of the tool.
2. Related Work
In software testing, test cases are manually
generated from use cases. Heumann [3] discusses how
to manually generate test cases from use cases using
the basic flow of events and alternate flows of events.
The scenarios are first created from combination of the
basic flow and alternate flows. These scenarios are
then used as the basis for creating test cases. However,
generating test cases manually consumes more time
and requires more tedious job. Therefore, many
researchers study ways to automate the process of
generating test cases, for example Wee et al. [8], Hui et
al. [4], Gutierrez et al. [2] and Nebut et al. [5]. Wee et
al. [8] study the automation of test cases using the
behavior of object-oriented classes, where the test
cases are automatically generated from the closed
specifications of classes. They propose a scheme that
combines the setup process, test execution and test
validation into a single test program for testing the
behavior of object-oriented classes. The test program is
generated automatically using the test cases and closed
specifications of the classes.
Hui et al. [4] study the validation of input and
propose an approach for automated verification and

0-7695-2983-6/07 $25.00 © 2007 IEEE 861

DOI 10.1109/CIT.2007.116
test case generation of input validation from source
code. Their work is concentrated on program source
codes to get the input validation for generating the test
cases. Gutierrez et al. [2], on the other hand, propose
an approach for automatic generation of test cases
from use cases for web applications using activity
diagrams representing the behavioral model of the
system’s requirements.
Nebut et al. [5] propose to generate test cases using
use cases with contracts and test scenarios. Their
research is focusing on adding contracts and test
scenarios manually to use cases prior to generating test
cases automatically. Our approach is similar to [5],
since we also propose generating test cases using use
cases. However, instead of using contract and test
scenarios, we are using sequence diagrams and flow of
events as added information in generating the test
cases automatically.
Following on the suggestion made by Heumann [3]
on generating test cases manually using use cases and
flow of events, we propose to automate the process to
reduce the cost of testing the system and save the time
of producing the test cases manually. Therefore,
instead of testing the software at the later stage, this
research will use use-case diagrams based on system’s
requirements to generate the test cases automatically.
3. The System’s Requirements
Requirements of a system are usually captured
during the analysis phase. Requirements are then
classified into functional and non-functional
requirements. Functional requirements concern with
the task that the new system is going to perform while
non-functional requirements concern will all the
constraints of the new system [7]. The functional
requirements for a system describe what the system
should do and these requirements are usually
represented using system specification before the
system can be implemented.
In UML specification, functional requirements
system analysis and design are usually done using
diagrams [1]. One particular diagram (a use-case
diagram) is used to specify functional requirements of
the system. In a use-case diagram, two important
factors are used to describe the functional requirements
of a system. They are actors and use cases. Actors are
external entities that interact with the system and use
cases are the behavior (or the functionalities) of a
system [6]. The use cases are used to define the
requirements of the system. These use cases represent
862
the functionalities of the system. Most often, each use
case is then converted into a function representing the
task of the system. Therefore, we can convert from
each of the use case into one test case or many test
cases. The relationship of the conversion is either one
to one or one to many. However, if we have many use
cases, then we will have many test cases. Therefore, an
automatic tool would be more wisely used in order to
generate test cases from use cases of any system.
In most cases, use cases are developed based on the
user perspective since the user is going to use the
system. In order to make sure that the system does the
requirements as it supposed to do, the test cases are
designed according to the tester perspective. These test
cases are basically designed to test the input and output
of a system. Most often, the input, key-in by the user,
will be accepted by the system. The system then
processes the input and produces the required output
according to its specification.
In this paper, we present an example of an
application for a simple drink vending machine
system. The requirements of the system include the
capability to purchase drink by customer, get the drink
from the vending machine and then the capability of
the machine to return the balance. These three
requirements are then transformed into a use-case
diagram as shown in Figure 1.
Figure 1: A Use-Case Diagram for a
Drink Vending Machine System
Figure 1 shows a simple use-case diagram for a
customer (an actor) to communicate with the drink
vending machine system. From Figure 1, a customer is
able to do three tasks: purchase drink, get drink and get
balance of money. These three tasks represent the use
cases of this simple drink vending machine system.
 From the use case diagram, the flow of events can be events. Figure 2 shows the sequence diagram for use
constructed. For example, Table 1 shows the flows of case PurchaseDrink for a scenario when invalid coins
events for the basic flows, the alternative, as well as are input.
the preconditions and the postconditions of the use
case PurchaseDrink.
: Customer : VMCustomer : DrinkContainer : File
Panel

Table 1: Flow of events for use case PurchaseDrink

: Customer
1: selectBrand()

Preconditions: 2: checkAvailDrinks()

(i) The vending machine system is running. 3: getDrink()

(ii) The vending machine system is not executing 4: retrieve()

other task. 5: getType( )

6: getQuantity( )

7: getPrice( )
Main Success Scenario: 8: getQuantity( )

(i) The customer selects brand of drink 9: displayPrice()

(ii) The customer panel checks availability of
drink.
(iii) The system verifies the choices of the drink
and its price.
(iv) The system displays the price of the drink.
(v) The user inputs valid coins into the vending
machine system.
(vi) The system checks and validates the coins
(vii) The system produces the requested drink
Alternative sequences:
(i) A1: the coins that input by the customer are
invalid.
(ii) The system informs the customer that the
invalid coins are input.
(iii) A2: no coins are input.
(iv) The system informs the customer that no coins
are input.
10: inputCoin( )
11: validateCoin()
12: displayInvalidCoin( )
Figure 2: Sequence Diagram for PurchaseDrink
when invalid coins are input
Based on Figure1 together with Table 1 and Figure
2, good test cases can be formed. That is, a use-case
diagram can be used with added information of the
flow of events and sequence diagrams to generate test
cases of that particular system. The flow of events and
sequence diagrams are used to check on the
consistency of the use cases. If both information are
consistent, then these information are used to generate
the test cases. For example, Table 2 shows the test
cases generated from the use case PurchaseDrink.

Postconditions: Table 2: Test Cases of Use Case PurchaseDrink

(i) The result of purchasing drink is displayed to Use Case Test Cases
the customer. PurchaseDrink Valid coins are input
Invalid coins are input
Most often, use cases represent the functional No coins are input
requirements of a system. If the requirements are
gathered correctly, then a good use-case diagram can From Table 2, the generated test cases are the simplest
be formed. In UML, sequence diagrams are usually test cases for this particular example.
used to manually record the behavior of a system by
viewing the interaction between the system and its
environment [6]. These sequence diagrams describe in
4. GenTCase
details activities for use cases. Therefore, the sequence
The tool, which we call GenTCase (Generator for
diagrams can be used to help in generating the correct
Test Cases), can be used to layout the use-case
test cases. From these use cases, sequence diagrams
diagram of any system. This use-case diagram
are formed to record the scenarios of the use cases. For
represents the functional requirements of a system. We
example, for use case PurchaseDrink, when scenario
do not consider any non-functional requirements since
of invalid coins is input, then the sequence diagram for
these requirements only concern with the constraints of
that particular scenario will be formed and checked
a system and how the system is implemented not what
against the consistency of its use case via flow of

863
the system should do. The tool is also able to generated; otherwise, an invalid error message will be
automatically generate the test cases of the system displayed indicating that the inconsistency exists
according to the use-case diagram that has been between the flow of events and the sequence diagrams.
formed previously. The test cases are generated automatically from the
tool as the output of the tool. The output is displayed
The tool is developed using object-oriented
on the screen as well as stored in a file with extension
approach with C++ programming language. The tool
.txt, namely output.txt. A user can open this output file
has 3 major components as shown in Figure 3.
by using a Notepad or Microsoft Word. The output can
be used as a checklist for a programmer to test the
system that he or she will develop according to the
provided test cases. These test cases can also be used
Workspac Î Engine Î Test to validate the results of the test cases so the
e requirements of the system are meet.
Cases Figure 4 shows the tool for generating the test cases.
A user who uses the tool can layout the use cases using
the Workspace. The Toolbox is used in order to ease
Figure 3: Components of GenTCase the drawing of the use-case diagram. The description
of each of the button in the Toolbox is explained in
Figure 5. User can also use the Workspace to layout
From Figure 3, the tool allows a user to layout the the flow of events and sequence diagrams. Then, the
use-case diagram of any system in the workspace button (as shown in number 11 for generator of test
provided. The workspace is used as a place for a user cases) is clicked to generate the test cases.
to provide the system’s requirements by means of a
use-case diagram, flow of events and sequence
diagrams. In the workspace, a Toolbox is used to
create, edit and display the use-case diagram, flow of
events and sequence diagrams. The Toolbox consists
of standard symbols and arrows for UML Specification
such as symbols for an actor and a use case, and
arrows for connecting an actor with use cases as well
as arrow for generalizations. In the Workspace, a user
can also type-in the text for each of the use cases used
in the Text Box provided by the tool. The Workspace
will allow a user of the tool to layout the use-case
diagram, flow of events and sequence diagrams
according to any system.
Once the use-case diagram has been finalized, the
user can layout the flow of events and sequence
diagrams using the workspace provided. Then the user Figure 4: Interface of GenTCase for Test Cases
can generate the test cases by using the generator of
the tool. The Engine will take all the use cases, check For this particular example of an application for a
the consistency of the flow of events with sequence simple drink vending machine system, the use-case
diagrams and search the keywords used in the provided diagram from Figure 1 is used in the Workspace
database. The database consists of most standard together with added information from Table 1 (flow of
keywords of a use case. Once the use case used events) and Figure 2 (sequence diagram). Then, the
matches the keyword inside the database, the engine generator is used to generate the test cases of the drink
will generate its respective test cases according to its vending machine system.
use case.
The tool will produce the test cases based on the
use-case diagram provided in the workspace. The
validity of test cases is checked using the flow of
events and sequence diagrams. If the flow of events
and sequence diagrams are consistent, the test cases are

864
 No. Item to the customer’s request, and the drink is not served at
1 Selection Tools all.
2 Text Box
3 Use Case
4 Actor
5 Note
6 Anchor Note
7 Package
8 Undirectional association
9 Dependency or instantiates
10 Generalizations
11 Generator for the Test Cases
Figure 8: Test Cases of Use Case GetBalance
Figure 5: Descriptions of Buttons in Tool Box
From Figure 8, for use case GetBalance, the test
Once the button of the “Generator for the Test cases consist of whether the correct balance of coins is
Cases” is clicked, the consistency of flow of events returned or incorrect balance of coins is returned, and
and sequence diagrams is checked in order to generate no balance returned.
the valid test cases accordingly. For example, Figures
6, 7 and 8 show the generated test cases according to
5. Conclusion and Future Work
use cases PurchaseDrink, GetDrink and GetBalance,
respectively.
GenTCase is a tool that is able to generate the test
cases automatically according to the system’s
requirements. The system’s requirements are
transformed into use case diagram, flow of events and
sequence diagrams. The flow of events and sequence
diagrams are used as added information for
consistency and validity of the generated test cases.
The test cases can be used as a checklist for a
programmer to validate that the system meets its
requirements. The purpose of GenTCase is to reduce
the cost of testing the system as well as save the time
Figure 6: Test Cases of Use Case PurchaseDrink of producing the test cases manually.
GenTCase has its limitations where the use cases
From Figure 6, for use case PurchaseDrink, the test used are only for functional requirements of a system.
cases consist of whether the coins that input by the The tool is unable to capture the non-functional
customer are enough or not enough for the drink requirements of a system. Therefore, the non-
purchased, and no coins are input. functional requirements need to be captured and tested
outside of the tool. For future work, we intend to
extend the capabilities of the tool such as incorporating
activity diagrams to allow more efficient test cases
being generated.

6. Acknowledgements
This research is under UTHM Fundamental
Research Grant Vot 0233.

Figure 7: Test Cases of Use Case GetDrink

7. References
From Figure 7, for use case GetDrink, the test cases
consist of whether the drink is served according to the [1] Bahrami A. Object-Oriented Systems Development, Mc-
Graw Hill, Singapore, 1999.
customer’s choice, or the drink is served not according

865

[2] Gutierez J., Escalona M.J. and Torres M.M. An
Approach to Generate Test Cases from Use Cases,
Proceedings of the 6th International Conference on Web
Engineering, 2006, pp. 113-114.
[3] Heumann J. Generating Test Cases from Use Cases,
Rational Software, IBM, 2001.
[4] Hui L. and Hee B.K.T. Automated Verification and Test
Case Generation for Input Validation, Proceedings of
the 2006 International Workshop on Automation on
Software Test (AST’06) 2006, pp. 29-35.
[5] Nebut C, Fleurey F, Traon Y.L. and Jezequel J.M.
Automatic Test Generation: A Use Case Driven
866
Approach, IEEE Transactions on Software
Engineeering, Vol 32, No. 3, 2006, pp. 140-155.
[6] Rational. Mastering Requirements Management with
Use Cases, Rational Software, IBM, 2003.
[7] Sommerville I. Software Engineering Eight Edition,
Addison Wesley, 2007.
[8] Wee K.L., Siau C.K. and Yi S. Automated Generation
of Test Programs from Closed Specifications of Classes
and Test Cases, Proceedings of the 26th International
Conference on Software Engineering (ICSE’04), 2004,
pp. 52-57.