TTCN-3 in a Nutshell

by Bernard Stepien

University of Ottawa

What is TTCN-3?

TTCN-3 is a test scripting language

TTCN-3 is an international standard

TTCN-3's main feature is the separation of concern between Abstract Test Suites and the Adapter Layer which allows full portability of test suites and thus make them independent of any platform implementation. The test adapter handles all platform and implementation languages (java, C, C++) issues for the communication with a System Under Test and also the actual coding and decoding requirements of an application.

TTCN-3 has a powerfull matching mechanism

TTCN-3 basic testing model

TTCN-3 Test Adapter concept

A TTCN-3 example

The following is an example of an Abstract Test Suite (ATS) where we are trying to test a weather service. The tester sends a request consisting of a location, a date and a kind of report to some on-line weather service and receives a response with confirmation of the location and date along with the temperature, the wind velocity and the weather conditions at this location.

A TTCN-3 ATS is always composed of four sections:

type definitions: data structures like in C but also an easy to use concept of lists and sets.

template definitions: A TTCN-3 template consists of two separate concepts merged into one:

test data definition
test data matching rules

test cases definitions: specifies the sequences and alternatives of sequences of messages sent and received to and from the System Under Test (SUT)

test control definitions defines the order of execution of various test cases

Sample TTCN-3 Abstract Test Suite


module SimpleWeather {

	type record weatherRequest {
 		charstring location,
 		charstring date,
 		charstring kind	
	}

	template weatherRequest ParisWeekendWeatherRequest := {
		location := "Paris",
		date := "15/06/2006",
		kind := "actual"
	}
	
	type record weatherResponse {
		charstring location,
		charstring date,
		charstring kind,
		integer temperature,
		integer windVelocity,
		charstring conditions		
	}
	
	template weatherResponse ParisResponse := {
		location := "Paris",
		date := "15/06/2006",
		kind := "actual",
		temperature := (15..30),
		windVelocity := (0..20),
		conditions := "sunny"
	}
	
	type port weatherPort message {
		in weatherResponse;
		out weatherRequest;
	}
	
	type component MTCType {
		port weatherPort weatherOffice;	
	}
	
	testcase testWeather() runs on MTCType {
		
		weatherOffice.send(ParisWeekendWeatherRequest);
		alt {
			[] weatherOffice.receive(ParisResponse) {
					setverdict(pass)	
				}
			[] weatherOffice.receive {
					setverdict(fail)
				}
		}
	}
	
	control {
		execute	(testWeather())
	}
}

The role of the test adapter and codec

The test adapter and the codec are the glue between the Abstract Test Suite and the System Under Test. It converts the data into the format that the SUT understands.

In the above example, the abstract data is converted into a text string with some command "request weather", and pairs of field names and field values.
Note that the concrete field names are intentionally different than the abstract types field names.
The adapter layer enables us to re-use the same abstract test cases for different weather forecast providers.
For example while provider A may use the above text messages, provider B may use an XML representation instead in the following form:


	<weatherRequest kind="actual">
		<weatherStation location= "Paris"/>
		<date day="15" month="06"  year="2006"/>
	</weatherRequest>

Abstract Test Cases re-usability

What is the TTCN-3 Matching Mechanism?

The TTCN-3 matching mechanism enables to specify the values expected in a response from the SUT in a user-friendly and concise way. It is composed of two language constructs:

a template definition

	template weatherResponse ParisResponse := {
		location := "Paris",
		date := "15/06/2006",
		kind := "actual",
		temperature := (15..30),
		windVelocity := (0..20),
		conditions := "sunny"
	}

a behavior receive statement

	weatherOffice.receive(ParisResponse);
	setverdict(pass)

The receive statement uses the template definition to specify that the data received from the SUT should match the values of the fields of this template.
The template enables to specify a variety of matching rules:

single value: location="Paris"
list of alternate values: conditions= ("cloudy", "overcast")
sets of unordered values: (a ,c ,b) or (c,a, b), etc...
ranges of numeric values: temperature := (12..50)
string patterns: conditions:= pattern "*snow* " will match the phrase "light snow"

Test Behavior specification

When a SUT can respond in different ways to the same stimuli, we represent this behavior using trees. Branches of the behavior tree are specified with the TTCN-3 alt construct.

TTCN-3 achieves yet another separation of concern. It separates behavior from the conditions governing behavior. TTCN-3 enables to specify test behavior as trees of alternate behaviors. The conditions governing this behavior are specified using TTCN-3 templates that in essence act as traditional if-then-else statements but in a very concise way. This behavior presentation approach enables a clear overview quality of the test behavior, a quality rarely found in traditional programming languages.

In our weather service example, we use an alternative to specify the possibility to receive an unexpected and unspecified response message in which case we could decide that the test case failed.
Verdicts are usually located in the leafs of the behavior tree.

		alt {
			[] weatherOffice.receive(ParisResponse) {
					setverdict(pass)	
				}
			[] weatherOffice.receive {
					setverdict(fail)
				}
		}

Parametrization

One of TTCN-3's major feature is parametrization. This feature enables to maximize the principle of re-usability.

Parametric templates
templates can be assembled using other templates.

	template myTypeA myRomeLocation := {
		city := "Roma",
		country := "italy"
	}

	template myTypeB myGenericWeatherRequest (myTypeA theLocationTemplate) := {
		location := theLocationTemplate,
		request := "road conditions"
	}

the above template myGenericWeatherRequest can be actualized when used in a TTCN-3 send or receive operation:

	weatherOffice.send(myGenericWeatherRequest(myRomeLocation));
	...

Parametric test cases
templates can be passed to a test case or function as parameters and can be used in any of the TTCN-3 send or receive operation.

	testcase testWeather(myTypeB theWeatherRequest, someResponseType theExpectedResponse) runs on MTCType {
		
		weatherOffice.send(theWeatherRequest);
		alt {
			[] weatherOffice.receive(theExpectedResponse) {
			      setverdict(pass)	
			}
			[] weatherOffice.receive {
			      setverdict(fail)
			}
		}
	}

The above test case can be executed with actual values as follows:

	execute(testWeather(myGenericWeatherRequest(myRomeLocation), myExectedResponse));
	...

and this test case can be re-used for a variety of similare tests like in our case checking the weather in different locations:

	execute(testWeather(myGenericWeatherRequest(myParisLocation), parisExpectedResponse));
	...

Where to obtain the TTCN-3 standard

The TTCN-3 standard can be obtained free of charge from ETSI: link to the official TTCN-3 Web Site