using use case scenarios and operational variables for generating test objectives javier j....

Using Use Case Scenarios and Operational Variables

for Generating Test Objectives

Javier J. Gutiérrez María José Escalona

Manuel MejíasArturo H. Torres

Department of Computer Languages and Systems. University of Seville, [email protected]

STV 2007. Paris, France

mailto:[email protected]

IntroductionContext of the work

Introduction

Use cases & test cases generation.

The approach

Conclusions. Use cases are a testing artefact

Use cases is a wide used technique to define functional requirements.

The test phase must assure that the final software system covers these functional requirements.

There are two very used techniques for extracting test cases from use cases:

Scenario analysis, based on scenario identification.

Test data analysis, based on category partition method

IntroductionObjectives of the paper

Introduction


The approach

Conclusions.

Objectives:

Applying Cathegry Partition Method (CPM) and Extended Use Case Test Patterns (both very similar) to obtain test objectives.

Test objectives are defined as combinations of the partitions of the operational variables (categories) identified.

IntroductionDefinitions

Introduction


The approach

Conclusions.

Operational variable: any element that may vary between two use case scenarios (categories of an use case).

Domain: all possible values that a variable operational can get.

Partition: set of domain values which exposes the same behaviour in the use case.

Use cases is a technique to express requirements graphically.

Graphics are not enough detailed to express all the funcional requirements

Some alternatives or representation are defined. For instance, patterns.

Use cases & test cases generationDefinition of use cases (I)

Introduction


The approach

Conclusions.

Use cases & test cases generationDefinition of use cases (II)

Name UC-02. Search link by description.

Precondition No

Main sequence

1 The visitor asks the system for searching links by description.

2 The system asks for the description.

3 The visitor introduces a piece of the description of the searched links.

4 The system searches for the links which matches up with the introduced description.

5 The system shows the results found.

Alternatives 3.1 At any time, the visitor may cancel the search, then this use case ends.

4.1 If the visitor introduces an empty piece of text, then the system searches for all stored links and step 4.2 is executed.

5.1 If no links were found, then the system shows a message and this use case ends.

Errors 4.2 If the system finds any error performing the search, then an error message is shown and this use case ends.

Post condition No.

Notes Only validated links are searched.

NDT + language patterns.

(The) [ACTOR] [ACTION](The) [ACTOR] [ACTION]

Introduction


The approach

Conclusions.

Use cases & test cases generationTest objectives

Test objective: Something to test (with a test case)A test objective is a test case without a result.

Test objectives may be defined in serveral ways.A use case may be a test objective.

Use case scenarions.Test value combination.Both 2 and 3.

Introduction


The approach

Conclusions.

The approachGenerating use cases scenarios. STEP 1

STEP 1: From use cases definition to XML definition Use cases templates are extended with language patterns and they are

translate into a XML document using the same structure than the template

Introduction


The approach

Conclusions.

<useCase id="Search link by description"> <description> A use case searches for a set of links by their description and shows the results. </description> <mainSequence> <step id="1"> The visitor asks the system searching for links by description. </step> <step id="2"> The system asks for the description. </step> <step id="3"> The visitor introduces de description. </step> <step id="4"> The system searches for the links which match up with the description introduced by the visitor. </step> <step id="5"> The system shows the found results. </step> </mainSequence> <alternativeSteps><astep id="3.1"> At any time, the visitor may cancel the search, then the use case ends. </astep><astep id="4.1"> If the visitor introduces an empty description, then the system searches for all the stored links and step 5 is repeated. </astep> </alternativeSteps> <errorneousSteps><estep id="4.2"> If the system finds any error performing the search, then an error message is shown and this use case ends. </estep><estep id="4.3"> If the result is empty, then the system shows a message and this use case ends. </estep> </errorneousSteps> </useCase>

DTD available


STEP 2: From formal pattern in XML to activity diagrams From formal description of pattern an activity diagram can be generated

easily. (tool available: ObjectGen)

Introduction


The approach

Conclusions.

If [CONDITION] then [ACTION] and this use case ends.


STEP 3: From activity diagram to use case scenarios Each path of the activity diagram is a possible use case scenario.

Classical graph techniques may be used to generate scenarios.(tool available ObjectGen)

Introduction


The approach

Conclusions.

Use case: Search link by descriptionThe Round-Trip CriterionScenarios: 5S 1: 1, 2, D01, End. S 2: 1, 2, D01, 3, D02, 4.1, 5, End.S 3: 1, 2, D01, 3, D02, 4, D03, 4.2, End.S 4: 1, 2, D01, 3, D02, 4, D03, D04, 4.3, End.S 5: 1, 2, D01, 3, D02, 4, D03, D04, 5, End.

Use case scenario 1:1: The visitor asks the system searching for links by description.2: The system asks for the description.3: The visitor cancels the search then the use case ends.

The approachGenerating combinations of partitions. STEP 1 (I)

STEP 1: Definition of operational variables and partitions Every decision node, in the activity diagram, evaluates a logical predicate to choose an output transition.

Therefore, an operational variable is assigned to each decision node and logical predicate.

The domain of the operational variable is divided into as many partitions as output transitions

Introduction


The approach

Conclusions.

The approachGenerating combinations of partitions. STEP 1 (II)

Introduction


The approach

Conclusions.

4.2. an error message is shown.<<System>>

4.1. the system searches for all stored links.<<system>>

5.1. the system shows a message.<<system>>

5. The system shows the results found.<<system>>

4. The system searches for the links which matches up with the introduced description.<<system>>

3. The visitor introduces a piece of the description of the searched links.<<visitor>>

2. The system asks for the description.<<system>>

1. The visitor asks the system for searching links by description.<<visitor>>

no links were found.

Not(no links were found)

the system finds any error performing the search.

Not(the system finds any error performing the search)

the visitor introduces an empty piece of text.

Not(the visitor introduces an empty piece of text)

Not(cancel the search)

cancel the search.

D01

D02

D03 D04

Variables: activity and decision nodes.

Particiones: Decisions output flows.

The approachGenerating combinations of partitions. STEP 2 (I)

Introduction


The approach

Conclusions.

STEP 2: Construction of the dependency matrix and generation constraint

1 -> 2 -> 3 -> V_D01(Sí)

One path with variables and the partitions in which variables takes values.

We see, in dependency map, that from V_D01, variables V_D02, V_D03 and V_D04 may be evaluated.

But those variables do not appear in the path, so, we have identifiyed a restriction.

If V_D01 == P_1 (cancels) then V_D02 = V_D03 = V_D04 = no value

V_D01: User cancels peration. Boolean

V_D01 V_D02 V_D03 V_D04

V_D01 0 1 1 1

V_D02 0 0 1 1

The approachGenerating combinations of partitions. STEP 2 (II)

STEP 2: Construction of the dependency matrix and generation constraint

These steps can be automatically generate with an available tool: ValueGen

Introduction


The approach

Conclusions.

The approachResults with the constraint construction

Introduction


The approach

Conclusions.

Without constraints:

4 variables, 2 partitions for each variable:

16 combinations.

With constraints:

4 variables, 2 partitions, 2 constraints:

7 combinations.

ConclusionsGeneral conclusions

The approach introduced may be applied in the early stages of the development process, when use cases are being defined, because it does not need a set of complete use cases

The full automatism of the process and the availability to support tools allow the easy re-generation of test objectives when use cases change

The approach only uses main, alternative and erroneous steps which are present in all styles, so, it may be easily used without having to change the use case style and format of an organisation

It allows the managing of the traceability of the test cases from a use case through their test objectives. (To know how many use cases were covered by tests)

Introduction


The approach

Conclusions.

ConclusionsFuture works

To improve the tool support: mainly the interface.

To integrate test tools with the use case supporting tool for NDT.

To apply in practise with NDT.

Introduction


The approach

Conclusions.

Address

Introduction


The approach

Conclusions.

Testing & Tools

Javier Gutiérrez ([email protected])

www.lsi.us.es/~javierj/

Requirements

María José Escalona([email protected])

www.lsi.us.es/~escalona/

Using Use Case Scenarios and Operational Variables

for Generating Test Objectives

Javier J. Gutiérrez María José Escalona

Manuel MejíasArturo H. Torres

Department of Computer Languages and Systems. University of Seville, [email protected]

STV 2007. Paris, France

mailto:[email protected]

using use case scenarios and operational variables for generating test objectives javier j....

Documents