lf/publications/formaltesting.pdf · formal testing – lars frantzen tarot summer school – july...

Formal TestingTheories for Practice

Lars FrantzenRadboud University Nijmegen

The [email protected]

Formal Testing – Lars FrantzenTAROT Summer School – July 4, 2007 – Grenoble, France

COPYING

Version: 26/06/2008

These slides are © Lars Frantzen 2007/2008

These Slides are released under a CC license:

http://creativecommons.org/licenses/by-nc-sa/3.0/

Feel free to use them under the restrictions of the license, I

would be happy if you send a short notice to

[email protected]

http://creativecommons.org/licenses/by-nc-sa/3.0/

mailto:[email protected]


Agenda

From Ideas of a system to Model-Based Testing

A Formal Framework for Model-Based Testing

Instantiation 1: Finite State Machines

Instantiation 2: Labeled Transition Systems

Extensions and Variations


Ideas and Systems

has

Idea

System

develops


Ideas and Systems

has

Idea

System

develops

specifies

conforms to


Plato

The world that appears to our senses is in some way defective and filled with error, but there is a more real and perfect realm, populated by entities (called “forms” or “ideas”) that are eternal, changeless, and in some sense paradigmatic for the structure and character of our world.

© Stanford Encyclopedia of Philosophy


Ideas and Systems

has

Idea

System

develops

specifies

conforms to


Ideas and Systems

has

Idea

System

develops

specifies

conforms to

partia

l, blu

rry


Ideas and Systems

has

Idea

System

develops

specifies

conforms to

partia

l, blu

rry

makes errors


What is Failure?

What does it mean for a system to fail?

Some terminology:

But how to define a Failure?

Human being makes an Error

which leads to a Fault in the system,

leading to a Failure of the system


Software Quality – ISO 9126

FunctionalitySuitabilityAccuracy

InteroperabilityCompliance

Security

ReliabilityMaturity

RecoverabilityFault Tolerance

UsabilityLearnability

UnderstandabilityOperability

EfficiencyTime Behavior

Resource Behavior

MaintainabilityStability

AnalysabilityChangeability

Testability

PortabilityInstallability

ReplaceabilityAdaptability


Measuring Quality

To quantify quality, the quality attributes must be

measurable.

To do so, a metric for the attribute must be defined.

Such a metric can be measured.

Background: Factor Criteria Metrics by McCall 1977

EfficiencyTime Behavior

Resource BehaviorT = ResponseTime - QueryTime

Metric


Measuring Quality

How to measure Functionality?

Measuring here means Testing!

But still: what is a Failure?

FunctionalitySuitabilityAccuracy

InteroperabilityCompliance

Security

Metrics

Fault Density = #Faults / KLOC

Failure Rate = #Failures / Execution Time

Fault Days = Day of Failure – Day of Error

From: IEEE 982.1


Requirements

The idea of a system is denoted in Requirements.

To give the requirements of a system, metrics are not

enough, further documents are needed.

The componentmust be very usable,and always return bar

when given a foo.

Failure Rate < 2/h

Plain Text Metrics

?yPressed ?rPressed

?allOK

!rAlarm!yAlarm

Models

Requirements


Ideas and Systems Revisited

has

Idea

System

develops

specifies

conforms to



has

Idea

System

develops

specifies

Requirementsconforms to

specifies

conforms to

designs



has

Idea

System

develops

specifies

Requirementsconforms to

specifies

conforms to

designs

Validation Verification


Terminology

Error means that a human being writes code which has a

Fault.

A Fault is a piece of code which, when being executed,

may lead to a Failure.

Failure is an observable behavior of a system which does

not conform to a requirement.

Testing means running a system with the ability to detect

failures.


How to Improve Quality?

Error

Fault

Failure

Organize, assess and improve the development process:V-Model, RUP, XP, ...TQM, Six Sigma, ...CMM(I), SPICE, ...

Static AnalysisReviews

Organize, assess and improve the testing process:Certified Tester, TMM, TPI, ...


Design Errors, Faults and Failures

Designing requirements (aka modeling, specifying) brings

a new source of errors, faults and failures:

Design errors are made by human beings who create a

requirement document which has a design fault.

A design fault is an element of a requirement document

which leads to a design failure.

A design failure is an observable characteristics of a

requirement document which does not conform to the idea

of the system, or a property.


Design Errors, Faults and Failures

Means to improve quality here are validation techniques,

and formal verification.

Idea

specifies

conforms to

Propertiessp

ecifi

es

conf

orm

s to

Validation Formal Verification

Requirements

specifiesconforms to


The Big Picture

Idea

System

specifies

conforms to

specifies

conforms to

Validation Verification (e.g. Testing)

FormalVerification

spec

ifies

conf

orm

s to

Requirements

Properties

specifiesconforms to


Black Boxes and White Boxes

Black-Box testing usually refers to generating test cases

out of requirements.

White-Box testing does not refer to generating test cases

out of code (which is meaningless)!

Instead, white-box testing usually refers to structural

metrics measuring code coverage, e.g.:Statement Coverage

Decision Coverage

Black-Box testing and White-Box “testing” are usually

combined (if source code is available)!

Active Research: “real” White-Box testing, i.e., using the

source code to actively guide the testing process.


ModelBased Testing

Model-Based Testing (MBT) means testing with the ability

to detect Failures which are non-conformities to a Model.

MBT can also include:automatic generation of test cases from the model

automatic execution of these test cases at the system

automatic evaluation of the observed behavior, leading to a verdict

(PASS,FAIL,...)

System

specifies

conforms to

Model


ModelBased Testing

MBT is Black Box testing – test cases are generated from

the model.

In this talk I focus on models specifying functional

requirements:Finite State Machines

Labeled Transition Systems

The main questions to answer are:How does a model specify a system?

What does it mean that a system conforms to a model?


Summary

In practice, systems do not conform to their idea.

Conformity of a system to the idea is also called quality,

and examined by validation techniques.

ISO 9126 gives a taxonomy of quality attributes.

To measure quality, requirements are postulated.

Validation on the requirements tries to spot design

failures caused by design faults, which are due to

design errors made by the designer.

A special validation technique is formal verification on the

requirements.


Summary

Conformity to the requirements is measured by

verification techniques, e.g. testing.

Verification only improves the quality of a system if the

requirements are valid.

Testing tries to spot failures of the system caused by

faults in the system, which are due to errors made by

the developer.

Model-Based Testing tries to spot non-conformities to a

special requirement – a (formal) Model.

Model-Based Testing can also encompass the automatic

generation, execution and evaluation of test cases.


Agenda







Conformance Testing

System

specifies

conforms to

Test Generation Test ExecutionTest Suite

Model

Verdict


Soundness of Conformance Testing

System

specifies

conforms to

Test Generation Test Execution

Model

Verdict


Completeness of Conformance Testing

System

specifies

conforms to


Model

Verdict


Remarks on Soundness and Completeness

A test system, which always says is sound.

A test system, which always says is complete.

We want test systems which are sound and complete!


Soundness and Completeness of Conformance Testing

System

specifies

conforms to


Model

Verdict


More Remarks on Soundness and Completeness

Testing can never be sound and complete!

Edsger W. Dijkstra


More Remarks on Soundness and Completeness

Dijkstra is right (of course).

He refers to the fact, that the number of test cases in a

sound and complete test suite is usually infinite (or at least

too big).

If that would not be the case, testing could prove the

conformity of the system to the model (given some

assumptions on the system).

In practice, conformity is usually only semi-decidable by

finding a failure with a (sound) test system.

But still: completeness is a crucial property of a sound test

system stating that it can potentially find all failures!


Proving Soundness and Completeness

System

specifies

conforms to


Model

Verdict



System

specifies

conforms to


Model

Verdict

Physicalingredients



System

specifies

conforms to


Model

Verdict

Physicalingredients

Observations


Observations

Observations

Executing a test case on the system yields a set of

observations.

Every observation represents a part of the

implementation model of the system, i.e. the model

describing how the real system behaves.

Test Suite

System Test Execution

Observations

Test Cases



Implementation Models

The set of all observations made with all possible test

cases represents the complete implementation model of

the system!

Test Suite


Test Cases


Observations

Implementation Model



Depending on the chosen class of implementation models,

the observations might have to be transformed, first.


Observations

transform



Guide to prove the existence of implementation models:

1. What are the test cases?

2. What are the observations I can make when executing

all possible test cases at a real system?

3. What are the assumptions I make on the test execution

to restrict the set of possible observations?

4. What kind of transformations do I want to make with the

remaining observations?

5. Prove for every system that the (transformed) set of all

possible observations (respecting the assumptions)

yields an implementation model which is

observational equivalent to the system.



Steps to follow when defining a test theory:


























The system is input enabledThe system is deterministicAfter observing quiescence, no output is observedThe system has finite stateEvery prefix of an observation can also be observed















The system is input enabledThe system is deterministicAfter observing quiescence, no output is observedThe system has finite stateEvery prefix of an observation can also be observed

The validity of these assumptions is referred to as the

Test Hypothesis



Assuming from now on the validity of the test hypothesis,

we know that for every system there is a corresponding

observational equivalent implementation model.

This implementation model is unknown since in practice

we cannot execute all possible test cases at the system.

But since we know it exists, we can now define formally

what conformance means!


SystemSystem


Observational Equivalence

System

Test ExecutionTest Suite


FormalTest Execution

Observations

Physicalingredients

=



System

specifies

conforms to


Model

Verdict

Physicalingredients

Observations



specifies

imp

Test GenerationFormal


Model

VerdictObservations




specifies

imp



Model

VerdictObservations


Now we can define:

System conforms-to the specification model⇔

the implementation model is imp-correct to the specification model


Proving Soundness

specifies

imp


Test Execution

Model

VerdictObservations



Proving Completeness

specifies

imp


Test Execution

Model

VerdictObservations




specifies

imp

Test Generation FormalTest Execution

Model

VerdictObservations


Test Suite

The proof-obligation to show the soundness and completenessof a test generation algorithm w.r.t. an implementation relation impis:

Show for all implementation models:

implementation model M is imp-correct to the specification model⇔

M passes all test cases which the algorithm can generate



System

specifies

conforms to


Model

Verdict

Physicalingredients

ObservationsVerdict

Test Suite

Having done so, you have shown that:

System passes all test cases which the algorithm can generate⇔

System conforms-to the specification model


Summary

We want test generation algorithms to be sound and

complete for the conforms-to relation.

Every system has an underlying implementation model

consisting of all possible observations one can make with

all possible test cases.

To restrict the class of systems, assumptions are made

on the test execution.

Based on these assumptions, one has to prove that an

implementation model exists which is observational

equivalent to the system.


Summary

Now the implementation model can be substituted for the

real system (aka the test hypothesis).

Between the implementation model and the specification

model implementation relations can be defined.

Conformity of a system to a model is then defined by the

imp-correctness of its underlying implementation model.

The main proof obligation is to show the soundness and

completeness of the test generation algorithm w.r.t. the

chosen implementation relation.


Agenda







Finite State Machines

Original domains:sequential circuits

communication protocols

Two types of Finite State Machines (FSM) matter for

testing:Mealy Machines

Moore Machines

Commonly, FSM is identified with Mealy Machine.


Alternating Bit Protocol

s1

s4 s3

m/m0

a0/-

a0/-a1/-

a0/m1 m/-

m/m1

a1/-

UserSender Receiver

m m0,m1

a0,a1

s2a1/m0m/-

a0/- a1/-

The Sender as aMealy Machine:


Mealy Machines

s1 m/m0 s2

state s1 state s2 = (s1,m)input m

output m0 = (s1,m)


Conformance

Specification models and implementation models are

Mealy Machines.

What means conformance here?

s1

s2 s3

a/0

b/0

a/0a/1

b/1

b/1

i1

i2 i3

a/0

b/1

a/0a/1

b/1

b/1

Ms Mi1

imp


Conformance

We have Mi imp Ms ⇔ Mi is equivalent to Ms

Two FSM are equivalent iff for every input sequence they

produce the same output sequence.

s1

s2 s3

a/0

b/0

a/0a/1

b/1

b/1

i1

i2 i3

a/0

b/1

a/0a/1

b/1

b/1

Ms Mi1

imp

Ms(bbb) = 110 ≠ Mi1(bbb) = 111


Test Cases

A test case is an input sequence together with its output

sequence, derived from the specification model.

Test case: input: bbb output: 110

s1

s2 s3

a/0

b/0

a/0a/1

b/1

b/1

Ms


Formal Test Execution



Formally executing a test case means giving the input

sequence to the implementation model.

i1

i2 i3

a/0

b/1

a/0a/1

b/1

b/1

Mi1



Observations




sequence to the implementation model, and observing the

corresponding output sequence.i1

i2 i3

a/0

b/1

a/0a/1

b/1

b/1

Mi1

Observation: input: bbb output: 111



a/0

Verdicts




sequence to the implementation model, and observing the

corresponding output sequence - leading to a verdict.i1

i2 i3

b/1

a/0a/1

b/1

b/1

Mi1


+

=

Observation: input: bbb output: 111



But we don't know the implementation model a priori, we

have just executed a single test case!

What has really happened, is this:

o1 o2 o3b/1b/1b/1

Mi1


o4

System

Test ExecutionObservation: input: bbb output: 111

transform



All we know is a little puzzle-piece from Mi1.

Mi1

o1 o2 o3b/1b/1b/1

o4

a/? a/? a/? a/?

????

Black Box

o1 o2 o3b/1b/1b/1

o4

?b/?



But this is sufficient to observe non-conformity, since all

possible completions of the Black Box are non-

conforming!

s1 s2 s3b/1b/1b/1

s4

s1

s2 s3

a/0

b/0

a/0a/1

b/1

b/1

Ms

imp

Mi1

o1 o2 o3b/1b/1b/1

o4

a/? a/? a/? a/?

????

Black Box

?b/?


Test Generation

A sound and complete test generation algorithm must

generate all possible test cases.

s1

s2 s3

a/0

b/0

a/0a/1

b/1

b/1

Ms

Test Cases

Input Output

a 0b 1ab 01aab 001bbb 110abababab 01110001...


Dijkstra Revisited

A sound and complete test generation algorithm must

generate all possible test cases.

Test Cases

Input Output

a 0b 1ab 01aab 001bbb 110abababab 01110001...

Testing can never be sound and complete!

Edsger W. Dijkstra


Dijkstra Revisited

When should we stop testing?

Which test cases shall we select?

⇒ How to deal with the practical incompleteness of testing?

1) Accept it, and focus on heuristics like code coverage,

model coverage, timing constraints, randomness,

test purposes, etc.

2) Try to find further assumptions, which makes testing

complete in practice, i.e., leading to a finite sound and

complete test suite.


Remember...

Dijkstra is right (of course).

He refers to the fact, that the number of test cases in a

sound and complete test suite is usually infinite (or at least

too big).

If that would not be the case, testing could prove the

conformity of the system to the model (given some

assumptions on the system).





Checking Sequences

A checking sequence for Ms is an input sequence that

distinguishes the class of machines equivalent to Ms from

all other machines.

The length of this sequence can be used to compare the

time complexity of the several algorithms.


Mandatory Assumptions

(1) Ms is minimized, meaning that Ms has no equivalent

states. Equivalent states produce the same output

sequence for every input sequence.

s1

s2 s3

b/1a/0

Ms

s4

b/1b/1

a/0 a/0

a/0b/0


equivalent





s1

s2 s3

b/1a/0

Ms

s4

b/1b/1

a/0 a/0

a/0b/0






s1

s5

b/1a/0

Ms (minimized)

s4

b/1

a/0

a/0b/0



(1) Ms is minimized.

(2) Ms is strongly connected, meaning every state can reach

every other state.

s1

s5

b/1a/0

Ms (minimized)

s4

b/1

a/0b/0

Ms is not strongly connected!a/0




(2) Ms is strongly connected.

(3) Mi has the same inputs and outputs as Ms, and does

not change during runtime.







Mandatory


Mandatory and Additional Assumptions





(4) Ms and Mi have an initial state.








(5) Ms and Mi have a reset message that from any state of

the machine causes a transition which ends in the initial

state, and produces no output.








(5) Ms and Mi have a reset message. s1

s5

b/1a/0

Ms (minimized)

s4

b/1

a/0b/0

Having a reset message,Ms is strongly connected!

a/0

reset








(5) Ms and Mi have a reset message.

(6) Mi has the same number of states than Ms.









(6) Mi has the same number of states than Ms. Under this

assumption, two types of faults can be present in Mi:

Output faults: a transition produces a wrong output

Transfer faults: a transition goes to a wrong state


Output and Transfer Faults

s1

s2 s3

a/0

b/0

a/0a/1

b/1

b/1

i1

i2 i3

a/0

b/1

a/0a/1

b/1

b/1

Ms

Mi1

imp

i1

i2 i3

b/0

a/0

b/1b/1

a/1

a/0 Mi2imp

Output fault

Transfer and

Output faults










(7) Ms and Mi have a status message. Giving a particular

input “status”, the output uniquely defines the current state.










(7) Ms and Mi have a status message.

(8) Ms and Mi have a set message. From the initial state the

system can be transferred to every other state s by giving

the input set(s). No output is produced while doing so.










(7) Ms and Mi have a status message.

(8) Ms and Mi have a set message.

Additional


A Sound and Complete Algorithm

For all states s and all inputs a do:

1. Apply the reset message to bring Mi to the initial state.

2. Apply a set message to transfer Mi to state s.

3. Apply the input a.

4. Verify that the output conforms to the specification Ms.

5. Apply the status message and verify that the final state

conforms to the specification Ms.

This algorithm is sound and complete given that all assumptions(1) – (8) hold.

The length of the checking sequence is 4 * |I| * |S|


Transition Tours

To get rid of the set message, and possibly shorten the

test suite, we can build a sequence that visits every state

and every transition at least once – a transition tour.

The shortest transition tour visits each transition exactly

once, and is called an Euler tour. It only exists for

symmetric FSM (every state is the start state and end

state of the same number of transitions).

An Euler Tour can be computed in linear time w.r.t. the

number of transitions.

In non-symmetric FSM finding the shortest tour is referred

to as the Chinese Postman Problem. It can be solved in

polynomial time.


Transition Tours

Problem:

Covering all transitions of Ms, and checking whether

Mi produces the same output, is

not complete!

s1

s2 s3

a/0

b/0

a/0a/1

b/1

b/1

i1

i2 i3

a/0

b/1

a/0a/1

b/1

b/1

Ms

Mi1imp

i1

i2 i3

b/0

a/0

b/1b/1

a/1

a/0 Mi2imp


Transition Tours

Problem:



not complete!

s1

s2 s3

a/0

b/0

a/0a/1

b/1

b/1

i1

i2 i3

a/0

b/1

a/0a/1

b/1

b/1

Ms

Mi1imp

i1

i2 i3

b/0

a/0

b/1b/1

a/1

a/0 Mi2imp

ababab is an Euler tour


Transition Tours

Problem:



not complete!

s1

s2 s3

a/0

b/0

a/0a/1

b/1

b/1

i1

i2 i3

a/0

b/1

a/0a/1

b/1

b/1

Ms

Mi1imp

i1

i2 i3

b/0

a/0

b/1b/1

a/1

a/0 Mi2imp


The Euler tour is sufficientto spot the output fault of Mi1:

011100 ≠ 011101


Transition Tours

Problem:



not complete!

s1

s2 s3

a/0

b/0

a/0a/1

b/1

b/1

i1

i2 i3

a/0

b/1

a/0a/1

b/1

b/1

Ms

Mi1imp

i1

i2 i3

b/0

a/0

b/1b/1

a/1

a/0 Mi2imp


The Euler tour is sufficientto spot the output fault of Mi1:

011100 ≠ 011101

The Euler tour is not sufficientto spot the faults of Mi2:

011100 = 011100


State Identification and Verification

Solution 1:

Use the status message to verify the states while doing

the transition tour.

Solution 2:

If the status message does not exists, use separating

sequences instead. Examples are:Characterizing set (W Method)

Identification set (Wp Method)

UIO sequence (UIO Methods)

Distinguishing sequence (Distinguishing Sequence Method)

...

Not all separating sequences are guaranteed to exists.

Not all of these methods are complete.


Where's the Reset Button?

When even a reset message is not available, more can be

done...

...using distinguishing sequences without reset...

...homing sequence...

...transfer s

equences...

...adaptive distinguishing sequences...

...using identifying sequences instead of distinguishing sequences...


The General Procedure

Every method follows the same scheme:

1. For all states s and all inputs a do:

1. Bring Mi to the state s.

2. Apply the input a.

4. Verify that the output conforms to the specification Ms.

5. Verify that the final state conforms to the specification Ms.


Additional States

A simple water spender:

Water Spender SystemMs

s1

button/water


Additional States



s1

button/water

Assuming that Mi has no morestates than Ms, i.e. 1, theninput: buttonoutput: wateris a sound and complete test suite!


Additional States



s1

button/water

Mi

i2

button/-

i1

button/water

imp


Additional States

Assumption


may not hold in practice.

Many methods can be extended to deal with a bounded

number of states.

This extension causes an exponential growth of the

length of the checking sequence.

“Faults” in extra states are more likely to be discovered

with long input sequences.

Hence, methods not using the reset messages may be

better in practice.


Summary

The test hypothesis for FSM-based testing makes some

general assumptions regarding the system to be tested:The system has finite state.

The system is deterministic.

The system communicates in a synchronous manner (input / output).

FSM-based testing focused on testing for equivalence.

Based on a given set of further mandatory and

additional assumptions, the FSM algorithms can give a

finite sound and complete test suite.

In other words, these algorithm can prove the equivalence.

Most of the theoretical problems have been solved.


Summary

FSM-based testing can be the underlying testing model of

several other formalisms, like UML state machines,

Abstract State Machines, RPC-like systems, etc.

Tools related to FSM-based testing are for instance:Conformance Kit, PHACT, TVEDA, Autofocus, AsmL Test Tool,...

Results regarding other types of state machines have

shown that there is no hope that feasible algorithms can

yield a finite sound and complete test suite, for instance:Nondeterministic machines

Probabilistic machines

Symbolic machines

Real-Time machines

Hybrid machines


Agenda








Original domains:sequential and concurrent programs

hardware circuits

Several formalisms have an underlying Labeled

Transition System (LTS) semantics, for instance:Statecharts

Process Algebras


Customer and Supplier

s2

s1

reqQuote

Customer Supplier

reqQuote, orderGoods

offerQuote, confirm, cancel

s3

offerQuote

s4

orderGoods s6s5

cancel confirm

The Supplier as aLabeled Transition System:



s1 requestQuote s2

state stateaction

We have(s1, requestQuote, s2) ∈


Conformance

Relating two LTS can be done in a variety of manners,

e.g.:

Equivalence relations:Isomorphism, Bisimulation, Trace Equivalence, Testing Equivalence,

Refusal Equivalence, ...

Preorder relations:Observation Preorder, Trace Preorder, Testing Preorder, Refusal Preorder,

...

Input-Output relations:Input-Output Testing

Input-Output Refusal

ioconf

ioco

...


Conformance

An implementation relation is called stronger than another,

if the classes of related LTS are more differentiated.

Implementation relations may also be incomparable.

We want an implementation relation torelate systems we naturally consider as being conforming

be applicable in practice, i.e., having a feasible testing scenario

be as strong as possible

stronger


Isomorphism

Two LTS are isomorph (or: equivalent) iff they are exactly

the same modulo state names.

Isomorphism is the strongest notion of conformance.

Isomorphism is not suited for testing since we cannot

observe the unobservable action!

b

a

s2

s1

s2

s1

s3

≡ ≡a a

a


Bisimulation

Two LTS are (weak) bisimular iff they simulate each other

and go to states from where they can simulate each other

again.

Bisimulation is not suited for testing since its testing

scenario comprises means which are infeasible in practice.

s2

s1

s2

s1

s3

≈b

a

a

s2

s1

s3

a

s4

c

s1

s2 s3

a

s5

c

a≈b

b

s4

b


Trace Equivalence

A trace is an observable sequence of actions.

Two LTS are trace equivalent iff they have the same

traces.

Trace equivalence is the weakest notion of conformance.

For testing purposes it is usually considered too weak.

isomorphism bisimularity trace equivalence

s2

s1

s3

b

a

s2

s1

s4

b

a

s3

a

≈ tr s2

s1

s3

a

s4

c

s1

s2 s3

a

s5

c

a

b

s4

b

≈ tr


Completed Trace Equivalence

A completed trace is a trace leading to a state refusing

all actions – a final state.

Two LTS are completed trace equivalent iff they are

trace equivalent, and also share the same completed

traces.

Here we need to be able to observe the absence of all

actions, i.e., deadlocks.

s2

s1

s3

b

a

s2

s1

s4

b

a

s3

a≈ctr


More Relations

Testing equivalence is stronger than completed trace

equivalence, and demands a test scenario which can

observe the refusal of actions.

conf is a modification of testing equivalence restricting the

observations to only those traces contained in the

specification (conf is not transitive).

Refusal equivalence is stronger than testing equivalence,

and demands a test scenario which can continue the test

after observing the refusal of actions.

Tool: Cooper for the Co-Op method for conf


Preorder Relations

i imp s means that implementation model i implements

specification model s.

Do we want imp to bereflexive s imp s ✔

symmetric i imp s s imp i

transitive i imp s ∧ s imp t i imp t ✔

anti-symmetric i imp s ∧ s imp i i = s

total i imp s ∨ s imp i

congruent i imp s f(i) imp f(s) ✔

An equivalence is reflexive, symmetric and transitive.

A preorder is just reflexive and transitive.


Preorder Relations

The motivation for preorder relations is to simplify the

testing scenario.

For almost every equivalence ≈ a corresponding preorder

≤ can be defined such that

p≈q ⇔ p≤q ∧ q≤p

Trace preorder:

i ≤tr s ⇔ traces(i) ⊆ traces(s)

In the same way testing preorder ≤te and refusal

preorder ≤rf can be defined.


InputOutput Labeled Transition Systems

In Input-Output relations, the set of action labels is

partitioned into input actions and output actions, leading

to an Input-Output Labeled Transition System (IOLTS).

Compared to FSM, IOLTS differ inhaving asynchronous transitions (either input or output)

having potentially an infinite number of states

being potentially nondeterministic

being not necessarily completely specified for all inputs

being compositional

An IOLTS, which is completely specified for all inputs is

called an input enabled IOLTS.


InputOutput Relations

Testing preorder and refusal preorder can be adapted to

deal with IOLTS, leading to the relationsInput-Output Testing Relation

Input-Output Refusal Relation

conf can also be adopted, leading to ioconf

In the remainder we focus on the

input-output conformance relation - ioco


ioco Conformance

Specification models are IOLTS

Implementation models are input-enabled IOLTS

What means ioco-conformance?

iocos2

s1

?reqQuote

s3

!offerQuote

s4

?orderGoods s6s5

!cancel !confirm

p2

p1

?reqQuote

p3

!offerQuote

p4

?orderGoods

!confirm

IOLTS input enabled IOLTS


Generalized Transitions

s2

s1

?a

s3

!x

s4

?b s6s5

!y !z

s1 ⇒ s1

s1 ⇒ s2

s2 ⇒ s3

s3 ⇒ s4

s4 ⇒ s5

s1 s4

s3 ⇒ s5

s3 s1

s1 s1

s1 s1

?a

!x

?b

?a!x?b

?b

?b!y

?a!x?b!y

?a!x?b!z


Quiescence

s2

s1

?a

s3

!x

s4

?b s6s5

!y !z


Suspension Transitions

s1 s4

s3 ⇒ s5

s3 s1

s1 s1

s1 s1

?a!x?b

?b

?b!y

?a!x?b!y

?a!x?b!z

s2

s1

?a

s3

!x

s4

?b s6s5

!y !z

s1 s4

s3 s5

s3 s1

s1 s1

s1 s1

?a!x?b

?b

?b!y

?a!x?b!y

?a!x?b!z


after

s1 after = {s1}

s1 after ?a = {s2}

s2 after !x?b = {s4,s5,s6}

s2 after !x?b = {s4,s5,s6}

s1 after ?a!x?b!z = {s1}

s2

s1

?a

s3

!x

s4

?b s6s5

!y !z


out

s2

s1

?a

s3

!x

s4

?b s6s5

!y !z

out(s1) = {}out(s2) = {!x}out(s3) = {}out(s4) = ∅out(s5) = {!y}out({s1,s2}) = {,!x}

out(s1 after ?a) = {!x}out(s1 after ?a!x?b) = {!y,!z}


ioco


ioco

Just writing ioco abbreviates iocoF with F = Straces(s0).


ioco

Intuition:

i ioco s, iff

● if i produces output x after trace , then s can produce x after trace .

● if i cannot produce any output after trace , then s cannot produce any output after trace (quiescence).


ioco

iocos2

s1

?reqQuote

s3

!offerQuote

s4

?orderGoods s6s5

!cancel !confirm

p2

p1

?reqQuote

p3

!offerQuote

p4

?orderGoods

!confirm

S P


ioco

ioco

S P

s2

s1

s3

?1€

s4

!tea!coffee

p2

p1

p3

?1€

p4

!tea!coffee

?2€


ioco

ioco

S P

s2

s1

s3

?1€

s4

!tea!coffee

p2

p1

?1€

p3

!tea

?2€


ioco

ioco

S P

s2

s1

s3

?1€

s4

!tea!coffee

p2

p1

p4

?1€

!coffee

?2€

p3

p5

!cappuccino


ioco

ioco

S P

s2

s1

s3

?1€

s4

!tea!coffee !cappuccino

p2

p1

p3

?1€

p4

!coffee

?2€


ioco

ioco

S P

s2

s1

s3

?1€

s4

!tea!coffee !cappuccino

p2

p1

p3

?1€

p4

?2€

!coffee

out(p1 after ?1€) = {!coffee, !cappuccino}⊈

out(s1 after ?1€) = {!coffee, !tea}


ioco

ioco

S P

s2

s1

s3

?1€

s4

!tea!coffee

p2

p1

p4

?1€

!coffee

?1€

p3


ioco

S P

s2

s1

s3

?1€

s4

!tea!coffee

p2

p1

p4

?1€

!coffee

?1€

p3ioco

out(p1 after ?1€) = {!coffee, }⊈

out(s1 after ?1€) = {!coffee, !tea}


ioco

ioco

Q P

iocoq2

q1

q4

?€

!tea

?€

q3

q5

?€

q6

!coffee

?€

?€

?€

?€

p2

p1

p4

?€

!tea

?€

p3

p5

?€

p7

!coffee

?€

?€

?€

?€

p6?€

!tea


ioco

ioco

Q P

iocoq2

q1

q4

?€

!tea

?€

q3

q5

?€

q6

!coffee

?€

?€

?€

?€

p2

p1

p4

?€

!tea

?€

p3

p5

?€

p7

!coffee

?€

?€

?€

?€

p6?€

!tea

out(p1 after ?€?€) = {!tea, !coffee}⊈

out(q1 after ?€?€) = {!coffee}


Test Cases

A test case is an IOLTS

having a quiescence label (modeling the observation of quiescence)

having inputs and outputs swapped

being tree-structured

being finite and deterministic

having final states pass and fail

where from each state ≠ pass and fail:

either a single output and all inputs

or all inputs and

t2

t1

?coffee !€

t3 t4

?tea

pass

fail fail

?coffee?tea

failt7t6t5

tat9t8

?coffee !€ ?tea

failfail

tdtctb

?tea ?coffee

failfail pass



Formally executing a test case means putting it in parallel

with the implementation model, leading to a verdict.

t2

t1

?coffee !€

t3 t4

?tea

pass

fail fail

?tea

failt7t6t5

tat9t8

?coffee !€ ?tea

failfail

tdtctb

?tea ?coffee

failfail pass

P

p2

p1

p4

?€

!tea

?€

p3

p5

?€

p7

!coffee

?€

?€

?€

?€

p6?€

!tea

?coffee



t2

t1

?coffee !€

t3 t4

?tea

pass

fail fail

?tea

failt7t6t5

tat9t8

?coffee !€ ?tea

failfail

tdtctb

?tea ?coffee

failfail pass

P

p2

p1

p4

?€

!tea

?€

p3

p5

?€

p7

!coffee

?€

?€

?€

?€

p6?€

!tea



?coffee



t2

t1

?coffee !€

t3 t4

?tea

pass

fail fail

?tea

failt7t6t5

tat9t8

!€ ?tea

failfail

tdtctb

?tea ?coffee

failfail pass

P

p2

p1

p4

?€

!tea

?€

p3

p5

?€

p7

!coffee

?€

?€

?€

?€

p6?€

!tea

A test run has been completed:!€?tea

with verdict pass

?coffee



?coffee



t2

t1

?coffee !€

t3 t4

?tea

pass

fail fail

?tea

failt7t6t5

tat9t8

?coffee !€ ?tea

failfail

tdtctb

?tea ?coffee

failfail pass

P

p2

p1

p4

?€

!tea

?€

p3

p5

?€

p7

!coffee

?€

?€

?€

?€

p6?€

!tea



?coffee



t2

t1

?coffee !€

t3 t4

?tea

pass

fail fail

?tea

failt7t6t5

tat9t8

?coffee !€ ?tea

failfail

tdtctb

?tea ?coffee

failfail pass

P

p2

p1

p4

?€

!tea

?€

p3

p5

?€

p7

!coffee

?€

?€

?€

?€

p6?€

!tea



?coffeeA test run has been completed:

!€!€?teawith verdict fail


Observations

The test runs represent the observations.

In the previous example, two observations have been

made:!€?tea

!€!€?tea

Note that the set of all test runs for a given test case

comprises all possible observations for all

nondeterministic cases.

One more observation could have been made in the

previous example:

!€!€?coffee (with verdict pass)


Dijkstra Revisited






test purposes, etc.







test purposes, etc.

Dijkstra Revisited







The possibly infinite state space, and the nondeterministiccharacter, make computing a finite sound and complete test suitean infeasible task!




test purposes, etc.

Dijkstra Revisited








Dijkstra Revisited






test purposes, etc.





A Sound and Complete Test Generation Algorithm

Given a specification LTS with initial state s0

Initially compute the set of states K = s0 after

Do a finite number of recursive applications of the following

three nondeterministic choices:

a) Stop the test case with the verdict pass

pass



b) Let the test case produce an output !a with K after a≠∅

Also accept all inputs at the same time.

ta is obtained by applying the algorithm with K = K after !atxi are obtained by applying the algorithm with K = K after xi

!a

xi ∈ out(S) yk ∉ out(S)

fail fail

ta tx1 txj

... ...



c) Let the test case accept all inputs – and quiescence.

t is obtained by applying the algorithm with K = K after txi are obtained by applying the algorithm with K = K after xi

xi ∈ out(S) yk ∉ out(S)

fail fail

t tx1 txj

... ...



Q

q2

q1

q4

?€

!tea

?€

q3

q5

?€

q6

!coffee

?€

?€

?€

?€

We generate a test case out of Q.

Initially, K = {q1}



Q

q2

q1

q4

?€

!tea

?€

q3

q5

?€

q6

!coffee

?€

?€

?€

?€



t2

t1

?coffee !€

t3 t4

?tea

fail failK = {q2,q3}



t2

t1

?coffee !€

t3 t4

?tea

fail fail

?coffee?tea

failt7t6t5

Q

q2

q1

q4

?€

!tea

?€

q3

q5

?€

q6

!coffee

?€

?€

?€

?€


K = {q3} K = {q4}



Q

q2

q1

q4

?€

!tea

?€

q3

q5

?€

q6

!coffee

?€

?€

?€

?€

t2

t1

?coffee !€

t3 t4

?tea

pass

fail fail

?coffee?tea

failt7t6t5


K = {q3}



Q

q2

q1

q4

?€

!tea

?€

q3

q5

?€

q6

!coffee

?€

?€

?€

?€

t2

t1

?coffee !€

t3 t4

?tea

pass

fail fail

?coffee?tea

failt7t6t5

tat9t8

?coffee !€ ?tea

failfail



K = {q5}



Q

q2

q1

q4

?€

!tea

?€

q3

q5

?€

q6

!coffee

?€

?€

?€

?€

t2

t1

?coffee !€

t3 t4

?tea

pass

fail fail

?coffee?tea

failt7t6t5

tat9t8

?coffee !€ ?tea

failfail

tdtctb

?tea ?coffee

failfail K = {q6}




Q

q2

q1

q4

?€

!tea

?€

q3

q5

?€

q6

!coffee

?€

?€

?€

?€

t2

t1

?coffee !€

t3 t4

?tea

pass

fail fail

?coffee?tea

failt7t6t5

tat9t8

?coffee !€ ?tea

failfail

tdtctb

?tea ?coffee

failfail pass



OnTheFly Testing

In every state a test case has to be defined for all

possible inputs, i.e., outputs from the system.

This can easily let the state space explode.

Some tools do not firstly generate a test suite, and then

apply it on the system.

They combine the test case generation and execution

process.

By so doing, outputs observed from the system guide

the “test case” generation.

So doing avoids this state space explosion problem.

This kind of testing is called on-the-fly testing.


OnTheFly Testing

Q

q2

q1

q4

?€

!tea

?€

q3

q5

?€

q6

!coffee

?€

?€

?€

?€

We test on-the-fly with Q.

Initially, K = {q1}


OnTheFly Testing

Q

q2

q1

q4

?€

!tea

?€

q3

q5

?€

q6

!coffee

?€

?€

?€

?€

b) We choose some output !a with K after a≠∅

We also accept all inputs at the same time.

We choose to give!€ to the system.t1

!€

t3K = {q2,q3}


OnTheFly Testing

t1

!€

t3

?coffee?tea

failt7t6t5

Q

q2

q1

q4

?€

!tea

?€

q3

q5

?€

q6

!coffee

?€

?€

?€

?€

c) We accept all inputs – and quiescence.

We observe quiescence and hence only need to continue with state t5 and K = {q3}

K = {q3} K = {q4}


Tools

The following tools implement (variants) of the ioco

relation:

TorXOn-The-Fly execution

Random walk or test purposes

Input languages: LOTOS, Promela, FSP, CRL

TGV (part of the CADP toolsuite)Batch execution

Test purposes

Input Languages: LOTOS, SDL, UML

TGV has been incorporated into other tools like TestComposer,

ObjectGéode and AGEDIS.


Summary

LTS are a common formalism to model reactive systems.

LTS are the underlying semantics of several other

formalisms like like statecharts or process algebras.

Relating two LTS can be done in a variety of manners.

Not all relations are suited for testing purposes.

Partitioning the action labels into inputs and outputs leads

to an IOLTS.

A common implementation relation for IOLTS is ioco.

ioco assumes implementation models to be input

enabled.

ioco allows specifications to be not input enabled –

allowing for partial specifications.


Summary

A test case is a tree-structured IOLTS with pass and fail

leaves.

Test cases must be output-complete for all possible

outputs of the system.

To avoid a state space explosion in test cases, the

generation and execution of test cases can be combined –

called on-the-fly testing.

A simple sound and complete test case generation for ioco

exists.

This algorithm is implemented in an on-the-fly manner in

the TorX tool.

The TGV tool combines ioco testing with test purposes.


Agenda








The following slides give a few pointers to current

research directions.

This list is far from being complete in any sense.

The focus is on extensions and variations of the ioco

implementation relation.

For many aspects similar results exist for FSM-based

testing, which are not covered here.


Compositionality

Given components j and k which are ioco correct to their

interface specifications sj and sk, respectively.

Component j

Component k

sj

sk


Compositionality

When such components are composed, they

synchronize on common actions.

Note that the specifications sj and sk cover both the

synchronized and independent actions.

Component j Component k

sj sk


Compositionality

The result is a new composed component. This is

modeled by the || operator.

To not have to retest the composed component, we want

that: j ioco sj ∧ k ioco sk ⇒ j || k ioco sk || sk

Component j Component k

sj || sk

Component j || k


The BOOM! Device


The BOOM! Device

m1 m2!siren

m3 m4!siren

sm

!BOOM


The BOOM! Device

m1 m2!siren

m3 m4!siren

sm

b1 b2?siren

sb

!BOOM


The BOOM! Device

m1 m2!siren

m3 m4!siren

sm

b1 b2?siren

sb

m1 m2!siren

m3 m4!siren

im

b1

?siren

ib

ioco ioco

!BOOM

!BOOM


The BOOM! Device

m1 m2!siren

m3 m4!siren

sm

b1 b2?siren

sb

m1 m2!siren

m3 m4!siren

im

b1

?siren

ib

ioco ioco

!BOOM

!BOOM

BOOM!


The BOOM! Device

m1 m2!siren

m3 m4!siren !BOOM

sm

b1 b2?siren

sb

m1 m2!siren

m3 m4!siren !BOOM

im

b1

?siren

ib

ioco ioco ioco

BOOM!


Compositionality

ioco is in general not compositional for || due to

underspecified inputs.

ioco is compositional for || when the specifications are

input-complete.

The only (known) meaningful way of making specifications

input complete is via demonic completion.

Demonic completion explicitly allows all behaviors after

previously underspecified inputs.

This is a different interpretation for partially underspecified

inputs than ioco has, leading to a weaker variant of ioco:

uioco

uioco is the proper choice when dealing with components.


Environmental Conformance

Components often come in practice with just a specification

of their provided interface.

Thus, components are usually only tested at their provided

interface, the requested interface is hidden.

This can be done, e.g., with standard (u)ioco-testing.

Component i

si



But a component may be combined with other components

at its requested interface.

Problem: quiescence may occur at the requested

interface!

We call k an environmental component of i.

Component kComponent i

si sk



Bottom-Up testing

Component kTester t

sk



Bottom-Up testing

Component kComponent iTester t

si



Bottom-Up testing

What if i violates k provided interface specification sk?

This might be invisible to the tester of i given that, e.g., k is

robust enough to deal with the violations.

But another component substituting k may not!

Component kComponent iTester t

si sk



Top-Down testing

Stub for kComponent iTester t

si



eco testing

The eco tester for k is testing if i correctly invokes k.

The specification for the requested interface of i is

generated out of the provided interface specification sk of

k. Now the provided interface is hidden!

Component iTester t eco-Testerfor k

si sk



Quiescence turns out to be not practical anymore for

environmental components.

Hence, eco testers do not observe quiescence.

This led to a new conformance relation – eco.

eco is the foundation of several current testing approaches

like Audition and functional Puppet.

Component iTester t eco-Testerfor k

(u)ioco? eco

si sk


Multiple Channels

Inputs and outputs can be partitioned into channels.

By so doing, input-completeness can be defined channel-

wise.

For all input channels, all inputs are simultaneously

enabled or simultaneously disabled.

Not every channel must be always input-enabled.

Every channel has its own quiescence.

Component i


Action Refinement

To get executable test cases, abstract actions may

have to be mapped to concrete actions.

Goal: automatic generation of test cases via refinement.

s1

s2

?address

s3

?store

!ok!nok

s1

s2

?street

s3

?city

!ok!nok

s4

s5

?store

?postalcode

refine


Symbolic Models

To deal with data symbolically means havingseveral Data Types

Variables and Constants

Operations

A model having these ingredients is called a symbolic

model.

Symbolic models are by far the most common models in

mathematics and computer science (Functions, Programs).

For instance, one can see a C-Program as a symbolic

implementation model (if we trust the compiler).


Symbolic Models

Famous symbolic models in Model-Based domains are for

instance:UML

Process Algebras with data (e.g. LOTOS, CRL)

Contracts

Symbolic models usually have a finite syntax and an

infinite semantics.

Specifying with non-symbolic models (FSM, LTS) is usually

not feasible in practice.


Symbolic Models

Testing based on symbolic model specifications means

dealing with very big, or even infinite transition systems,

leading to a state space explosion problem.

One simple “solution” here: prune the underlying transition

system to make it finite. Problem here:Often still too big

Completeness is lost

Symbolic information is lost

Better: don't transfer the symbolic model to its semantical

model, test directly with the symbolic model!


Symbolic Models

A precise and well studied language for symbolic

expressions is First Order Logic.

The LTS-based test theory ioco has been (partially)

reformulated based on First-Order Logic.

This led to a new instantiation of the formal framework

which is equivalent in testing capability to ioco, but based

on symbolic models: sioco

In sioco:Specification models are

Input-Output Symbolic Transition Systems (IOSTS)

Implementation models are

input enabled IOSTS


Symbolic Models

Several variants of IOSTS have been defined.

emergency = low

?buttonPressed<ButtonType btype>[btype = yellow]emergency := middle

?buttonPressed<ButtonType btype>[btype = red]emergency := high

?allOK<>[]emergency := low

!ackRedAlarm<Time expectedTime>[0 <= expectedTime <= 15]

!ackYellowAlarm<Time expectedTime>[0 <= expectedTime <= 45]


Symbolic Models

Doing symbolic testing does not come for free!

Problems:is a guard true for a given valuation of the global variables?

does a guard have a solution? (SAT)

which solution to choose for a guard?

how can I reach a given location (symbolic reachability)?

what is a “useful” symbolic coverage criteria?

what is a symbolic test case?

...

Possible solutions:choose a feasible subset of First-Order Logic

use techniques like constraint solving, model checking, theorem proving,...


Service State Machines

Service State Machines (SSM) are a pragmatic variant of

IOSTS tailored for modeling and testing Web Services.

Web Service Interfaces are specified in the

Web Service Description Language (WSDL)

WSDL allows to define four kinds of Operations:

A first natural choice: model a port-type via an IOSTS.

Possible extension: extend to multi-ports. This would

allow for specifying Coordination Protocols and

Compositions.

Web Service

OnewayRequest-Response

NotificationSolicit-Response

1

1

2

2



IOSTS have input and output actions (aka gates)

In WSDL:Oneway input message

Request-Response input message followed by an output message

Notification output message

Solicit-Response output action followed by an input message

For IOSTS we map:Oneway input action

Request-Response input action followed by an output action

Notification output action

Solicit-Response output action followed by an input action

Web Service

OnewayRequest-Response

NotificationSolicit-Response

1

1

2

2



Modelling Request-Response and Solicit-Response

operations in this manner has a bunch of consequences

for the IOSTS:actions are related to operations

actions must appear in the order the operation dictates

operations must complete:

between actions belonging to the same operations, no other actions must be

specified at the same port

quiescence must not be possible after a request in a Request-Response

operation (this is a satisfiability property!)

???

The resulting IOSTS variant is baptized

Service State Machine (SSM)



A prototype tool for automatic testing of Web Services

based on WSDL+SSM specifications is being implemented

– Ambition

Current status:only Request-Response and Oneway operations supported

based on a Java library for simulating SSM

uses the constraint solver of GNU Prolog

on-the-fly testing

random walk through the SSM

data types similar to XML-Schema types:

simple types (boolean, enumeration, integer, string, enumeration)

complex types (to model objects of classes)

simple language to express guards

some experimental features like floats with fixed precision



SSM object

Web Service

describes structural aspectsand binding of

describes behavioral aspects of

Ambition

tests

structural aspects behavioral aspects

binding

structural andbehavioral aspects

WSDLinstance

SSMinstance



A Supplier Web Service offering the operations:requestQuote(r : quoteRequest) : quote (Request-Response)

orderGoods(ref : integer, quant : integer) : boolean (Request-Response)

makePayment(ref : integer, amount : float) (Oneway)

Complex Types (Classes):quoteRequest product (Enumeration)

product : product {foo, bar}

quantity : integer

quote

price : float

product : product

quantity : integer

refNumber : integer

sum : float



A Supplier Web Service:

?requestQuote<r:quoteRequest>[r.quantity > 0]quoteRequested = r;

quoteRequestproduct : productquantity : integer





!requestQuoteResponse<return:quote>[return.product == quoteRequested.product && return.quantity <= quoteRequested.quantity && return.sum == return.quantity * return.price]quoteIssued = return;

quoteprice : floatproduct : productquantity : integerrefNumber : integersum : float

quoteRequestproduct : productquantity : integer





!requestQuoteResponse<return:quote>[return.product == quoteRequested.product && return.quantity <= quoteRequested.product && return.sum == return.quantity * return.price]quoteIssued = return;

?orderGoods<ref:int, quant:int>[ref == quoteIssued.refNumber && quant == quoteIssued.quantity]







!orderGoodsResponse<return:boolean>[]orderSucceeded = return;








?makePayment<ref:int, amount:float>[orderSucceeded == true && ref == quoteIssued.refNumber && amount == quoteIssued.sum]








?makePayment<ref:int, amount:float>[orderSucceeded == true && ref == quoteIssued.refNumber && amount == quoteIssued.sum]

[orderSucceeded == false]


Real Time Systems

Tailored symbolic model: Timed Automata

Real time is semantically modeled via ℝ.

Transition systems are extended with a time-passage

action.

Problem: uncountable state space

Solution: symbolic test cases

Different ideas for dealing with quiescence

Many promising approaches and tools ((r)tioco, T-

UPPAAL, T-TorX, ...)

+

Start?x := 0

Pos1?x >= 10x < 30x:=0

Startedx < 30Waiting

Pos1x < 30


Hybrid Systems

Brake Control System

System ON/OFF Light ON/OFF

A hybrid system not only has discrete inputs and outputs...


Hybrid Systems

Brake Control System

System ON/OFF Light ON/OFF

A hybrid system not only has discrete inputs and outputs,

but also continuous inputs and outputs.

Even “more continuous” than real time.

Hence, even more complex to deal with.

Very active research topic (Hybrid Automata, CHARON,

Hybrid UML, Hybrid Transition Systems, hioco, ...)

Distance Brake Pressure


Thank You

Thanks for your attention!

P.S.: References will be provided in a separate document.

lf/publications/formaltesting.pdf · formal testing – lars frantzen tarot summer school – july...

Documents