SATEL Semi Automatic TEsting Language University of Geneva Levi Lúcio VALID Meeting - Besançon...

SATELSemi Automatic TEsting Language

University of Geneva

Levi Lúcio

VALID Meeting - Besançon 10/3/06

2VALID Meeting - Besançon

Presentation Plan

CO-OPN and testing; Semi-automatic test selection; Syntax of SATEL; Semantics of SATEL; Preliminary results; Future.


Presentation Plan



CO-OPN Specification Language

QuickTime™ and aTIFF (LZW) decompressor

are needed to see this picture.

Algebraic Data Type (ADT)

Petri Net (extended)

MethodGate

CO-OPN Class Account


Transactional Semantics and Concurrency



Concurrency is automaticallymanaged by Petri Nets…



A transaction is either possible orthe state of the system is not changed!

Synchronization operators: Sim (//), Seq (..), Alt (+)


Testing CO-OPN Specs as Reactive Systems

CO-OPN specs may be seen as reactive systems: Stimulations: method events Observations: gate events (may be absent…)

We can extend this notion to: Stimulations: simple or synchronized method events Observations: simple or synchronized gate events


Black Box and Integration Testing



Black BoxIntegration Testing



Stimulations - method events or method synchronizations

Observations - gate events or gate synchronizations


Tests for CO-OPN Specs

A Test is a graphof Stimulation / Observation pairs with a truth value;

The graphs are expressed in Hennessy-Milner (HML) temporal logic: Sequence Negation Conjunction


Why HML?

HML is expressive enough to distinguish all possible executions of a CO-OPN Spec.

Simple traces are not!





Hiddentransition

uncovering


Presentation Plan



Why is our Test SelectionSemi-Automatic?

The test engineer employs her semantic knowledge of the SUT to: Select execution paths to test (HML formulas) Constrain parameters of stimulation/observation pairs

She can also impose the automatic decomposition of a method’s behavior


Test Selection Process



“Manual” selection“Automatic” selection


Presentation Plan



What are Test Intentions?

Test Intention 1

Test Intention 2

Test Intention 3

A test intention selectsa part of the model’s transition system andabstracts it…


Writing Test Intentions

A SATEL test intention is defined by axioms with constrained variables:

Parameters of methods or gates ADT types or Class types

Stimulations Observations HML formulas

A test intention “produces” a test set!


Axiom Structure

hmlFormula in intention cond1 & cond2 & … condn => hmlFormula in intention

HML(<loginUser(usr) with obs> T> in login;

Axioms

Variables obs : observation usr : username (ADT)

Non constrained variablesassume all their possible values

(usr into jean::luc::[]) = true =>HML(<loginUser(usr) with obs> T) in login;

Algebraic conditionconstraining the usr variable


Recursive Axioms and Test Intention Reuse

Several axioms may exist for one test intention and they may be recursive:

Variables f : HML

[] in nWrongPins;

f in nWrongPins => f . HML(<login(newUser(mario),newPin(1 1 1 1)) with errorLogin> T) in nWrongPins;

Base case for the recursion(empty test intention)Recursive call

Axioms may be reused in other test intentions:

f in nWrongPins & nbEvents(f) < 4 => f in 4LessWrongPins

Condition over HML formulaTest intention reuse


ADT Class Types

Algebraic conditions defined by term equalities

onlySimultaneity bool depth int

uniformity onlySequence bool nbEvents int

subuniformity onlyAlternative boolnbOccurrences (of a method)

int

simpleEvent bool sequence boolnbSynchronizations int positive bool

trace boolonlyConstructor boolonlyMutator boolonlyObserver bool

Observations / Stimulations HML Formulas

?

All constraints over variables

int and bool are primitive types of the test language(not ADT!)

“Automatic” constraining predicate


“Automatic” constraints for ADT variables

subUniformity(usr) => HML(<login(usr) with obs> in login;

During the transition induced by the “login” method select one value for “usr” per behavior of the login operation;

This depends on the axioms defining the method!


Managing Non-Determinism

We want to be able to include in our tests output events not predictable by the model;

These events are dependent on internal random procedures of the SUT or reactions of the SUT to the environment!


Dealing with Uncertainty

Lazy Variables: temp : observation

External: react : temperature manager ADT operation

HML(<measure_temp with temp> <react(temp) with statusOK> T) in SecureTempAction;

Variable instantiation posponedto testing time

ADT operation to be passedto the test driverProblem: Validation of semi-instantiated tests!


Presentation Plan



Denotational Semantics

For each test intention:

1. For each axiom find the set of variable substitutions that makes the condition true

Except variables marked with subuniformity

2. Generate per axiom a set of partially instantiated HML formulas


Denotational Semantics (2)

3. “Run” the partially instantiated tests through the Spec’s transition system to find values for the remaining variables and validate…

withdraw(m):(b >= m) => balance b -> balance b-m

Algebraic condition allowing themethod to fire

Petri net pre-conditionPetri net post-conditionAppying a subuniformity predicate on m implies at eachfire of the withdraw calculating one m for equation equations:

(b >= m) = true(b >= m) = false


Presentation Plan



Implementation of Test Intention modules


Presentation Plan



Future

Solidify syntax; Finish denotational semantics; Implement SATEL’s semantics in

Prolog; Some work on coverage of the state

space?

SATEL Semi Automatic TEsting Language University of Geneva Levi Lúcio VALID Meeting - Besançon...

Documents

Transcript of SATEL Semi Automatic TEsting Language University of Geneva Levi Lúcio VALID Meeting - Besançon...