Generation of TTCN-3 Test Cases from Use Case Map

Scenarios

Bryan Mulvihill

Supervised by Dr. Daniel Amyot

Goal

• The goal of this project is to convert Use Case Map Scenarios to test goals and test cases expressed in Testing and Test Control Notation version 3.

What are Use Case Maps?

• Use Case Maps (UCMs) are a scenario-based software engineering technique that have a history of application to the description of object-oriented systems and reactive systems in various areas, including wireless, mobile, and agent domains.

• UCMs are used as a visual notation for describing causal relationships between responsibilities of one or more use cases.

• UCMs model the functional requirements as scenarios.

Use Case Map Example

Use Case Map Scenarios

• Scenarios define a path through the UCM given a set of conditions.

• Allows for the extraction of individual scenarios from an integrated collection for visualization, analysis, and conversion to other representations.

Use Case Map Scenario Example

Scenario follows the red line.

Testing and Test Control Notation 3

• TTCN-3 is a flexible and powerful language applicable to the specification of all types of reactive system tests over a variety of communication interfaces

• TTCN-3 is intended to be used for the specification of test suites which are independent of test methods, layers and protocols.

• TTCN-3 is not restricted to conformance testing and can be used for many other kinds of testing including interoperability, robustness, regression, system and integration testing.

• In earlier versions of  the language TTCN stands for Tree and Tabular Combined Notation. The new meaning Testing and Test Control Notation is more apt for TTCN-3.

Purpose of this Project

• Develop test cases from functional requirements.

• Show proof of concept.

Technologies Used

• XML – UCM Scenarios are defined by an XML format.

• Java & Xerces Parser – Used to read in scenario and manipulate Document Object Model (DOM).

• XSLT & Xalan – Used to convert DOM using a stylesheet.

Structure of a UCM Scenarioscenarios

group

scenario

par seq

do condition

*

*

* *

Structure of a TTCN-3 ModuleThe principal building blocks of TTCN-3 are modules. Modules

may define a suite of testcases, or just a library. Modules mainly consist of:

• Functions – used for commonly executed behaviour. Much like functions in C++ or methods in Java.

• Signature declarations – declares a method called across a port. Acts like a remote procedure call.

• Components – data types that testcases run on. A main test component (MTC) is created when the testcase is executed.

• Testcases – an executable portion of the module. A module may contain any number of testcases.

TTCN-3 Ports

Ports are how components communicate with the system under test (SUT) and other components. TTCN has three types of ports:

• Message – allows for sending data.• Procedure – allows for remote procedure

calls (defined by signatures).• Mixed – acts as both a message based port

and procedure based port.

TTCN Example/* An example module */

module Example

{

// Port declaration

type port MyPortType procedure

{

inout all

}

// Component declaration

type component MyTestComponent

{

port MyPortType MyPort

}

// Function definitionfunction MyFunction(inout integer foo){

foo := 10 * foo;}

//signature declarationsignature MyMethod(in integer num) return charstring;

testcase ExampleTestCase()runs on MyTestComponentsystem MyTestComponent{

map(mtc:MyPort, system:MyPort);thePort.call(MyMethod:{3});alt {

[] thePort.getreply(MyMethod:{3} value “success”) {}[] thePort.getreply { //non zero value, failverdict.set(fail);}

}verdict.set(pass);

}}

Mappings

• Group – a group of scenario elements. group elements map to TTCN modules. Each module is put into its own TTCN file.

<group name=”GroupName” group-id = "1" description=”group description”>…</group>

module GroupName{/*group description*/...}

XML of UCMS

Generated TTCN

Mappings

• Scenario - A scenario is a sequential or parallel set of instructions. These map to TTCN testcases.

<scenario name='ScenarioName'>…</scenario>

testcase ScenarioName()runs on DefaultComponentsystem DefaultSystemComponent{...}

XML of UCM Scenario

Generated TTCN

Mappings

• Par – Represents a set of instructions to be executed in parallel. par elements are modelled as parallel test components (PTC) and called when encountered in the scenario. This requires the group template to look for par elements and create functions for each set of instructions in them. When they are encountered in the scenario, a PTC is created and started for each set of instructions in the par element.

<par><seq>…</seq><seq>…</seq>

</par>

XML of UCM Scenario

function PTC001() runs on DefaultPTC{...} function PTC002() runs on DefaultPTC{...} //in scenariovar DefaultPTC PTC001;PTC001 := DefaultPTC.create;PTC001.start(PTC001()); var DefaultPTC PTC002;PTC002 := DefaultPTC.create;PTC002.start(PTC002()); PTC001.done;PTC002.done;

Generated TTCN

Mappings• Do – Resp type – The do element with type “Resp” (short

for responsibility) acts as a remote procedure call to a component. A call to the right signature is made, and the reply is checked for success.

<do hyperedge-id="17" name="Acquire" type="Resp" component-name = "Security" component-id= "2" />

thePort.call(Security00_00Acquire);alt { [] thePort.getreply(Security00_00Acquire value 0){ } [] thePort.getreply { //non zero value, fail

verdict.set(fail); }}

XML of UCM Scenario

Generated TTCN

Putting it All Together<?xml version='1.0' standalone='no'?><!DOCTYPE scenarios SYSTEM "scenarios1.dtd"><scenarios date ="Tue Oct 1 13:31:25 2002" ucm-file = "SAM02.ucm" design-name = "SAM02" ucm-design-version = "18"> <group name = "PassWord" group-id = "2" > <scenario name = "PWNotOK" scenario-definition-id = "2" > <seq> <par> <seq> <do hyperedge-id="0" name="Access" type="Start" component-name = "TaxPayer" component-id= "5" /> <do hyperedge-id="3" name="CheckID" type="Resp" component-name = "Security" component-id= "2" /> <do hyperedge-id="41" name="PW" type="Connect_Start" component-name = "TaxPayer" component-id= "5"/> <do hyperedge-id="43" name="Wait4PW" type="Timer_Set" component-name = "TaxPayer" component-id= "5"/> </seq> <seq> <do hyperedge-id="59" name="InputPW" type="Start" component-name = "TaxPayer" component-id= "5" /> <do hyperedge-id="61" type="Trigger_End" component-name = "Security" component-id= "2"/> </seq> </par> <do hyperedge-id="43" name="Wait4PW" type="Timer_Reset" component-name = "Security" component-id= "2"/> <condition hyperedge-id="48" label="[PWNotOK]" expression ="!bv0" /> <do hyperedge-id="53" name="Reject" type="Resp" component-name = "Security" component-id= "2"/> <do hyperedge-id="47" name="No" type="Connect_End" component-name = "Security" component-id= "2"/> <do hyperedge-id="16" name="LogRej" type="Resp" component-name = "Security" component-id= "2" /> <do hyperedge-id="14" name="Rejected" type="End_Point" component-name = "TaxPayer" component-id= "5" /> </seq> </scenario> </group></scenarios>

module PassWord{

/*

*///Port type definitiontype port MixedPort mixed{

inout all}timer Wait4PW;

signature Security00_00LogRej() return integer;signature Security00_00CheckID() return integer;signature Security00_00Reject() return integer;

// Default Componenttype component DefaultComponent{

port MixedPort thePort;}

type component DefaultPTC{

port MixedPort thePort;}

function PTCN12() runs on DefaultPTC{

//Start thePort.call(Security00_00CheckID);

alt {[] thePort.getreply(Security00_00CheckID value 0) { }[] thePort.getreply { //non zero value, fail

verdict.set(fail);}

} Wait4PW.start;

}function PTCN23() runs on DefaultPTC{

//Start }

testcase PWNotOK()runs on DefaultComponent system DefaultComponent{

map(mtc:thePort, system:thePort);

var DefaultPTC vPTCN12:= DefaultPTC.create;vPTCN12.start( PTCN12() );var DefaultPTC vPTCN23:= DefaultPTC.create;vPTCN23.start( PTCN23() );vPTCN12.done;vPTCN23.done;

Wait4PW.stop; thePort.call(Security00_00Reject);

alt {[] thePort.getreply(Security00_00Reject value 0) { }[] thePort.getreply { //non zero value, fail

verdict.set(fail);}

}thePort.call(Security00_00LogRej);alt {

[] thePort.getreply(Security00_00LogRej value 0) { }[] thePort.getreply { //non zero value, fail

verdict.set(fail);}

} verdict.set(pass); //by default everything passes } }

Signatures and Generated Java Code

• From the known Components and signatures, Java classes and corresponding methods can be created. This creates a skeleton for the test environment.

signature Security00_00Acquire() return integer;signature Security00_00CheckID() return integer;

//Security.javapublic class Security{ public static int Acquire()

{return 0;

}

public static int CheckID(){

return 0;}

}

Signatures

Generated Java

TTthree

• TTthree is a TTCN-3 parser and compiler. Written by Testing Technologies, TTthree builds a .jar file from the TTCN module that can be executed by μTTman, a TTCN test management application.

• Generated TTCN scripts were tested and compiled using TTthree.

Future Additions

• Execute testcases using μTTman.

• Clean up component names before transformation.

• Use state information from UCM scenario in TTCN script.

• Multiple test components for a distributed test environment.

Thank You!

Any questions?