SYSTEM TEST CASES FROM USE CASES

Javier J. Gutiérrez, María J. Escalona, Manuel Mejías, Jesús Torres

University of Sevilla, Avd. Reina Mercedes sn. Sevilla, Spain

Keywords: System testing, use cases, generation of test cases.

Abstract: Use cases have become a widely used technique to define the functionality

of a software system. This paper

describes a new, formal and systematic approach for generating system test cases from use cases. This

process has been designed specially for testing the system from the point of view of the actors, through it

graphical user interfaces.

1 INTRODUCTION

System testing is a black-box technique which

verifies the satisfaction of the requirements of the

system under test (SUT) (Burnstein, 2003). Early

testing is the generation of test cases in early

development phases. This is not a new idea. Two

surveys (Denger, 2003) and (Gutiérrez, 2004) (22

different approaches in total) expose that there are

many lacks in the exiting approaches. One lack is

the absence of a formal process and the absence of

free available tools. Another lack is that approaches

are not complete; this means that they describe how

to generate partial test cases, mainly test actions,

without describing other important elements such as

test data, expected result, executable test scripts, or

test coverage.

In a previous work it was described how to

gene

rate test cases from use cases for web

application using existing approaches (Gutiérrez,

2005). This paper tries to resolve both lacks offering

a formal approach for obtain executable test scripts

from use cases. It has been specially designed to be

used in early development phases. It also uses UML

and UML Testing Profile (OMG, 2002) (called

UMLTP from now). Related works may be found in

(Denger, 2003) and (Gutiérrez, 2004).

2 A PROCESS TO GENERATE

TEST CASES FROM USE

CASES

This test process is focused on testing use cases

whose principal actor is human. A test case is

composed of three elements: test action, test values

and expected results. Test actions are the actions

developed by the test case over the system under test

(SUT). Test values are the information needed by

the test case. Expected results are the responses of

the system that allows evaluating whether the test is

satisfied or failed. The results for this process are:

test objectives, a set of test cases to verify each

objective and test scripts. Test cases are expressed

using models and graphical notation defined in

UMLTP when possible.

2.1 Testing Models

The models used to store the information about test

cases are: test objective model, test data model,

interface model and event model.

1. Test objective models.

A test objective is an element nam

ed according to

the description of what should be tested. The

UMLTP does not define any notation to represent

test objectives. Thus, we use activity diagrams.

A test objective is a path through the activity

diagram

. Test objectives might be automatically

extracted from the activity diagram applying a

coverage criterion, like all-edges and all-transitions.

Every test objective will have at least one test case

to verify it. An example is shown in table 4.

2. Test data model.

Test data model describes the structure and values of

e test data. The first task is to identify operational

variables (or simply variables) of a use case. An

operational variable is an explicit input or output, an

environmental condition or a representation of the

283

J. Gutiérrez J., J. Escalona M., Mejías M. and Torres J. (2006).

SYSTEM TEST CASES FROM USE CASES.

In Proceedings of the First International Conference on Software and Data Technologies, pages 283-286

DOI: 10.5220/0001309302830286

 SciTePress

SUT (Binder, 1999). The domain of every variable

is divided into data partitions. UMLTP uses class

diagrams and stereotypes to describe the hierarchy

of data partitions. After that, test values are

generated for every data partition. Case study shows

an example of data structures, partitions and test

values in figure 4.

3. Interface model.

Our aim is to test the functionality throughout a

graphical interface, not to test the graphical interface

itself. The objective of this model is to describe the

interface used for the test case to interact with the

system. Since this process has been designed to be

applied in early development phases, this model

represents a high abstract description of the GUI.

UML Testing Profile, and UML in general, does not

include any specific notation for GUI, so it will be

used class and object diagrams to represent the

components and states of a GUI.

Figure 1: Example of components for interface models.

Figure 1 shows a class diagram with some

elements from an interface model.

4. Event model.

Frequently, actor activities from a test objective are

too abstract to be directly translated into a test script.

It is proposed to build up an event model to address

to this complexity. A set of events describes how to

perform actor activities identified in the test

objective model. If an activity needs to supply

information to the system, this information should

have been defined in the test data model. This paper

introduces a simple set of messages to express

events. These messages are listed in table 1. Due to

their simplicity, the messages might be easily

extended. Event model also includes an assert

message (table 1). This message is sent by the test

case to itself to verify an attribute of the GUI. This

message allows codifying the expected results into a

test script, an example is shown in case study.

Table 1: Messages for event model.

Message Meaning

ClickOn(component) Perform a one-click event over

the indicated GUI component.

Screen(screen) Search for the indicate GUI

screen and set the focus over

it.

SetField(field, value) Set the indicated value into the

field object.

Assert(component.

attribute, value)

Verify that the attribute of the

component indicated matches

with the value.

2.2 Steps to Generate Test Cases

We suggest a process of six steps to generate test

models and to obtain executable test scripts. These

steps are shown in the activity diagram in figure 2

and described in the following paragraphs.

Figure 2: Activities to generate test cases.

The first step is to build up a test objective model

from a use case, as described in point 2.1. The

second one is to build up the test data model as

described in point 2.1. In the third step, test cases are

generated combining test objectives with test values.

The number of test cases is determined by the test

objectives and the different partitions for the

variables involved in that test objective. In the fourth

step, interface model is generated, as described in

point 2.1. In the fifth step event model is generated.

Finally, event messages, test values and assertions

are translated into test scripts, completed with test

harness (Binder, 1999) and executed over the real

SUT.

ICSOFT 2006 - INTERNATIONAL CONFERENCE ON SOFTWARE AND DATA TECHNOLOGIES

284

3 CASE STUDY

This section applies the process described in section

2 over a real system to generate test cases. The

system under test is an implementation of a classic

notepad. The use case selected to generate test cases

is Open File (table 2).

Table 2: Template for use case "Open File".

Description Load document from file

Precondition No

Main

scenario

1 User select “Open file” option.

2 System asks for the file to

open.

3 User selects a file.

4 System loads the file and

shows the document.

Alternative /

errors

3 User may cancel the loading

operation at any time.

4 If file does not exist or there is

an error, system shows an error

message.

Post

condition

No.

A full coverage for the use case is selected. This

means that at least one test case for every identified

test objective will be generated.

3.1 Generation of Test Objectives

First of all, the test objective model is built (figure

3). Activities 01 and 03 are developed by the user

and activities 02, 04, 04.1 and 04.2 are performed by

the system. Step 4 (table 4) has been divided into

activities 04, 04.1 and 04.2, and due to their results

they may be different if there is an error when

opening the file.

Figure 3: Test objective model.

Table 4 shows test objectives obtained by

traversing figure 3.

3.2 Generation of Test Values

Firstly the variables involved in the use case are

identified. Test objective model in figure 3 reveals

that there are, at least, two variables (the same

number as decision nodes). Variables and domains

are resumed in table 3.

Table 3: Variables and domains.

Variable Domain

User-Option Options available for the user: load

file or cancel.

File File to open

User-Option is a variable of an enumerated type.

However, File is a variable of a complex type. For

the testing purpose there must be known, at least, the

name of the file, its content and its attributes.

Figure 4: Test data.

Now, we divide the domains into data partitions.

Finally, at least one test value is generated for each

partition. Object diagram in figure 4 shows tests

values.

3.3 Build Test Cases

A test case is a test objective with a concrete value

for its variables. Variables and their partitions are

added to the test objectives, as shown in table 4.

Table 4: Test objectives with variables and partitions.

Test objectives

1 01, 02, 03(f01: Without-Errors, op01:LoadOption), 04,

04.1

2 01, 02, 03(f02: With-Errors, op02:LoadOption), 04, 04.1

3 01, 02, 03(f03: *, op03:CancelOption), 04, 04.1

3.4 Generate Interface Model

It is assumed that the system under test is not built

yet. So, it is generated an abstract description of the

user interface with the minimum set of components

to perform the use case.

Studying the use case, we realize that there are

three screens involved: the main screen, where user

actor clicks on open option, the file selection screen,

SYSTEM TEST CASES FROM USE CASES

285

where user actor selects the file to open, and the

error screen where system shows the error message,

if any.

The interface model is shown in the object

diagram in figure 5.

Figure 5: Interface model.

3.5 Generate Event Models and

Expected Results

First, each user activity is refined using messages

listed in table 1 and the user interface, defined in

point 3.4. The event model to verify the main

scenario is described as UML sequence diagram in

figure 6.

Figure 6: Event model.

Validation actions are implemented using the

assert proposition shown in table 1 and activities

diagrams as proposed in the UMLTP. Due their

simplicity, the have been omitted.

The process has ended. There have been

generated test actions (shown in the event model),

test values (shown in the test value model) and

expected results (shown in the event model too) that

commits our test objectives (shown in the test

objective model). Up to now, we have not needed

the design or the code of the system.

3.6 Building Test Scripts

The information obtained in the points before, might

be automatically translated into executable test

scripts. Details of the implementation and test tool

are needed to perform this step. It is used a real

implementation of the notepad, called Stylepad, to

generate test scripts. The Stylepad is distributed in

the Java Developer Kit. It has been used an open

source tool called Abbot to codify executable

scripts.

4 CONCLUSIONS

This paper has shown a process for the early-testing

of use cases. Although this process has been

designed to test use cases from the perspective of

human actors, it can be also used to test other actors.

This process can be applied in early development

stages. In fact, in case study described in section 3,

all test cases have been generated before choosing a

real implementation to test.

REFERENCES

Binder R.V. 1999. Testing Object-Oriented Systems.

Addison-Wesley. USA.

Burnstein, I. 2003. Practical software Testing. Springer

Professional Computing. USA.

Denger, C. Medina M. 2003. Test Case Derived from

Requirement Specifications. Fraunhofer IESE Report.

Escalona M.J. 2004. Models and Techniques for the

Specification and Analysis of Navigation in Software

Systems. Ph. European Thesis. Department of

Computer Language and Systems. University of

Seville. Seville, Spain.

Gutiérrez, J.J., Escalona M.J., Mejías M., Torres, J. 2004.

Comparative Analysis of Methodological Proposes to

Systematic Generation of System Test Cases. 3º

Workshop on System Testing and Validation. Paris.

France.

Gutiérrez J.J., Escalona M.J., Mejías M., Torres J. 2005. A

practical approach of Web System Testing. Advances

in Information Systems Development. Ed. Springer

Verlag Karlstad, Sweeden.

Object Management Group. 2002. The UML 2.0 Testing

Profile. www.omg.org

ICSOFT 2006 - INTERNATIONAL CONFERENCE ON SOFTWARE AND DATA TECHNOLOGIES

286