TTCN-3 Test Data Analyser Using Constraint Programming

22
TTCN3 Test Data Analyzer using Constraint Programming Diana Vega, Ina Schieferdecker, George Din, Stefan Taranu

Transcript of TTCN-3 Test Data Analyser Using Constraint Programming

TTCN‐3 Test Data Analyzer using Constraint Programming

Diana Vega, Ina Schieferdecker, George Din, Stefan Taranu

Content

• Motivation

• Test Specification Quality Model

• TTCN‐3 Data Analysis

• Distance Metrics for TTCN‐3 Templates

• Constraint Programming 

• Example

• Conclusions

Motivation• The Problem

– Test specification size increases more and more (e.g. 40.000 LOC for SIP TTCN‐3 test suite)

– Lack of common methodologies for the assessment of the quality of test specifications

– Quality evaluation of test specifications ?

• One View of the Problem

– Test Data Variance [Metrics]• Test Specification Quality Model derived from ISO 9126 – joint work with Univ. of Göettingen

– Test Effectivity [Characteristic]» Test Coverage [Sub‐characteristic]

Test System Interface (TSI) coverage measure 

Related Work – Quality of tests

White Box Testing

SUT is transparent to the test

Coverage measures:Statement coverageBranch coverageBlock coverage…etc.

But …Syntactic coverage

SUT 1Test Suite SUT 2

SUT n

Specification

Different Coverage Measures!!!

Test Specification Quality Model

Test Specification Quality

Suitability

Accuracy

FunctionalityCompliance

Maturity

Fault‐Tolerance

Recoverability

ReliabilityCompliance

Understand‐ability

Learnability

Operability

UsabilityCompliance

Time Behaviour

Resource Utilisation

EfficiencyCompliance

Analysability

Changeability

Stability

MaintainabilityCompliance

Adaptability

PortabilityCompliance

Reliability Usability Efficiency PortabilityMaintainabilityTest

Effectivity

Test Coverage

Test Correctness

SecurityFault‐Revealing

Capability

Test Effectivity Compliance

Test Repeatability

Reusability

Coupling

Flexibility

Comprehen‐sibility

ReusabilityComplianceTest 

Evaluability

6

TSI Port

Size and complexity of potential data space

Data Distance

Test System

System under Test

Data Quantification

Data variance in TTCN‐3 Terminology

1. SUT is represented by TSI

set of ports of different port types allowing various data types

“system” clause in test case definition

2. TSI coverage – data input space

Quantitative similarity distance measures

Qualitative similarity partitioning method

3. Assumption

all TSI ports are message‐based port

TTCN‐3 Data Analysis

Data Templates Construction

• Concrete values

• Variables

• Function calls (user defined, predefined)

• Parameters (test case, function, module)

• Received templates

• Expressions How to solve them?

Constraint Programming (CP)

• Control Flow Graph (CFG)– is a graph abstraction of the program, 

• CFG Symbolic Execution– by selecting only one execution path from the CFG

– instead of supplying the normal inputs to a program, supplies symbols representing arbitrary values within a specific domain or constrained values

CFG Example

p1 : (start) ‐‐> (1; 2) ‐‐> (3) ‐‐> (end)p2 : (start) ‐‐> (1; 2) ‐‐> (3) ‐‐> (4) ‐‐> (6) ‐‐> (3) ‐‐> (end)

Method applied to TTCN‐3 Tests‐ collect all test cases having the same TSI‐ determine all the ports associated with each TSI

Interfaces Identification(TSIs)

‐ currently only message based port are supported‐ collection of messages associated to a port

Template Subset Selection

‐ based on the distance formulaDistancesComputation

‐ select a partitioning method‐ create a number of partitions

TemplatePartitioning

‐ template solving using constraint programmingApply Constraint Programming

‐ count the number of partitions‐ compute coverage

Compute Coverage

Distance ComputationBasic Type Distance based on Definition of distance d for values x and y

Integer One-Dimensional Euclidian Distance d (x, y) =

Float One-Dimensional Euclidian Distance d (x, y) =

Boolean Inequalityd (x, y) =

Bitstring Hamming Distance number of positions for which the bits are different (the shorter bitstring is extended into the longer bitstring by filling it with leading ‘0’B) divided by the longer length:

d (x, y) =

with σ (x, y) = number of i where xi≠ yi

Hexstring Hamming Distance same, but with leading ‘0’H

Octetstring Hamming Distance Same, but with leading ‘0’O

Charstring Hamming Distance Same, but with leading “” (spaces)

Universal Charstring

Hamming Distance Same, but with leading “” (spaces)

)(||

Integersizeofyx −

)(||

Floatsizeofyx −

0 for x=y

1 otherwise{

σ (x, y)

maxlength (x, y)

Distance ComputationStructured Type

Distance based on Definition of distance d for values x and y

Record N-Dimensional Euclidian Distance

d (x, y) =

Record of Hamming Distanced (x, y) =

where d (x, y) = number of i where d (xi, yi) > and where therecord sequence is extended into the longer record sequence by filling it with leading omit.

Set N-Dimensional Euclidian Distance

same as for record

Set of Hamming Distance same as for record of

Enumerated Inequalityd (x, y) =

where n is the sequentially numbered index of the enumeration

Union Distance defined aboved (x, y) = d ( σ (x), σ (y) ) =

n

yxdn

i

ii∑= 1

2)),((

∑=

n

i 1σ (x, y)

maxlength (x, y)

nynxn |)()(| −

1 for σ (x) = σ (y)

0 otherwise{

Template Solving Method

• for each template from the template set identify the TTCN‐3 behavioral entity (e.g. testcase, function) where the statement p.send(<message>)

1. build the control flow graph (CFG) for that specific behavioral entity(e.g. testcase, function).

2. localize the target template (i.e. p.send(<message>)) to a corresponding node in CFG; this node is called target node. 

3. determine the path conditions for each path that connects the CFG head with the target node.

a) identify the decisions blocks and derive the constraints

b) build a variable symbol table on a top down manner which stores for each variable the constrained domain

c) apply the constraints on the variables directly/indirectly involved in the structure of the target template

4. expand the templates set with variations of the target template as resulted from the different constraints on different paths.

Partition MethodNumber of partitions: the number of varying data of a value set for a given type

#partitions T’ : ΠT’ →N #partitions T’ (∅) = 0V ≠∅ : #partitions T’ (V ) = 1 + #partitions T’ (V ’ ) 

V ‘ = V  \ partition T’ (v)  for v in V

Algorithm1. If template set not null2. Select the first template as partition pivot (pp)3. For each template t from the template set (t!=pp)• Compute distance d (pp, t) 

• if d (pp, t) < 1/3 then • t belongs to pp partition• and remove t from the template set

• Goto 1

In the template set remain the templates which do not belong to pp partition

An Examplemodulepar CityType mpCity := 1 ;

type integer CityType ( 1 . . 1 0 ) ;

type integer StarsType ( 0 . . 5 ) ;

type integer PriceType ( 0 . . 5 0 0 ) ;

type record RequestType  { CityType city , PriceType min , PriceType max , StarsType stars }

type record ResponseType  { boolean found , PriceType price }

template RequestType requestTwoStarsTemplate := { 

city := mpCity , min := 0 , max := 100 , stars := 2 }

template RequestType r eque s tFiveStar sTemplat e := {

city := mpCity , min := 0 , max := 100 , stars := 5 }

template ResponseType responseFoundTemplate := { found := true , price := ? }

template ResponseType responseNotFoundTemplate := { found := false , price := ? }

type port P message { out RequestType ; in ResponseType ; }

type component C  { port P p ; timer t := 10 . 0 ; }

modulepar CityType mpCity := 1 ;

type integer CityType ( 1 . . 1 0 ) ;

type integer StarsType ( 0 . . 5 ) ;

type integer PriceType ( 0 . . 5 0 0 ) ;

type record RequestType  { CityType city , PriceType min , PriceType max , StarsType stars }

type record ResponseType  { boolean found , PriceType price }

template RequestType requestTwoStarsTemplate := { 

city := mpCity , min := 0 , max := 100 , stars := 2 }

template RequestType r eque s tFiveStar sTemplat e := {

city := mpCity , min := 0 , max := 100 , stars := 5 }

template ResponseType responseFoundTemplate := { found := true , price := ? }

template ResponseType responseNotFoundTemplate := { found := false , price := ? }

type port P message { out RequestType ; in ResponseType ; }

type component C  { port P p ; timer t := 10 . 0 ; }

Test Casestestcase t1() runs on C system C {    map (self:p, system: p);p.send(requestTwoStarsTemplate);    t.start;

alt {

[] p.receive(responseFoundTemplate) {setverdict(pass); }  

[] p.receive(responseNotFoundTemplate) {setverdict(fail); }

[] t.timeout { setverdict(inconc); }

}  }

testcase t1() runs on C system C {    map (self:p, system: p);p.send(requestTwoStarsTemplate);    t.start;

alt {

[] p.receive(responseFoundTemplate) {setverdict(pass); }  

[] p.receive(responseNotFoundTemplate) {setverdict(fail); }

[] t.timeout { setverdict(inconc); }

}  }

testcase t2() runs on C system C {map (self:p, system: p);var RequestType vRequest := requestFiveStarsTemplate;

p.send(requestFiveStarsTemplate);t.start;alt {[] p.receive(responseFoundTemplate) {setverdict(pass); }  [] p.receive(responseNotFoundTemplate) {t.stop;       if(vRequest.stars >= 1) {vRequest.stars := vRequest.stars‐1;p.send(vRequest);t.start;repeat;}else { setverdict(fail); }        }[] t.timeout { setverdict(inconc); }}  }

testcase t2() runs on C system C {map (self:p, system: p);var RequestType vRequest := requestFiveStarsTemplate;

p.send(requestFiveStarsTemplate);t.start;alt {[] p.receive(responseFoundTemplate) {setverdict(pass); }  [] p.receive(responseNotFoundTemplate) {t.stop;       if(vRequest.stars >= 1) {vRequest.stars := vRequest.stars‐1;p.send(vRequest);t.start;repeat;}else { setverdict(fail); }        }[] t.timeout { setverdict(inconc); }}  }

Templates Set without CP

• Set={requestTwoStarsTemplate, requestFiveStarsTemplate, vRequest}

• Distance computationd(requestTwoStarsTemplate, requestFiveStarsTemplate) = 0,125 < 1/3, which is lower than the 1/3, the chosen threshold.

d(requestTwoStarsTemplate; vRequest) = 1 > 1/3, since the vRequest is a local testcase variable which has been not resolved

d(requestFiveStarsTemplate; vRequest) = 1 > 1/3

• PartitionsP1 = {requestTwoStarsTemplate; requestFiveStarsTemplate}P2 = {vRequest}

• Coverage = 2/3

Constraints Identification

Template Set with CP• Identified 6 paths; each path provides a vRequest(Cpathi)

• Example Cpath6 : { vRequest := requestF iveStarsT emplate;  

vRequest:stars >= 1;

vRequest:stars := vRequest:stars‐1 }

• Set={requestTwoStarsTemplate, requestFiveStarsTemplate, vRequest(Cpathi)}

• Distance computation

d(requestTwoStarsTemplate, requestFiveStarsTemplate) = 0,125 < 1/3

d(vRequest(Cpathi), requestTwoStarsTemplate) = 1/12 < 1/3

d(vRequest(Cpathi); requestFiveStarsTemplate) = 1/24 < 1/3

d(vRequest(Cpathi), vRequest(Cpathj)) < 1/3

since vRequest.stars becomes 4 due to constraint vRequest:stars := vRequest:stars ‐1.

• Partitions

P1 = {requestTwoStarsTemplate; requestFiveStarsTemplate, vRequest(Cpathi)}

• Coverage = 1/3 (all templates in the new template set belong to the same partition)

TTCN‐3 Test Data Analyzer and  CSP

TTCN‐3 User Conference, Madrid  2008 20

System Under Test - SUT

(Control Flow Graph - CFG)

Symbolic Execution - SE

Test Inputs (Data) Generator

Test Specification (TTCN-3)

(Control Flow Graph - CFG)

Symbolic Execution - SE

&&

Constraint Programming

Test Data Variability Analysis

Test Quality (Improvement)

Prototype

Control Flow Graph (CFG)

TTCN-3 Code

Constraints Table

Results

TTworkbench 

TTCN‐3 EMF Model Instance

Conclusions

• Defined a method to measure the test effectivity– Introduced data variance concept– Intelligent template resolving based on Constraint 

Programming– Applied a data partitioning method based on template 

similarity

• Further Work– Calibrate formulas– Experiment other partitioning methods– Test data generation