iswim for testing

42
© Xactium Ltd. 2007 1 ISWIM For Testing – A Model Driven Approach Tony Clark Xactium [email protected] www.xactium.com

Upload: clarktony

Post on 14-Jun-2015

190 views

Category:

Technology


0 download

TRANSCRIPT

Page 1: Iswim for testing

© Xactium Ltd. 2007 1

ISWIM For Testing – A Model Driven Approach

Tony ClarkXactium

[email protected]

Page 2: Iswim for testing

© Xactium Ltd. 2007 2

Overview

• A Requirement for Constraints:– Telecomms– Aerospace– Business Migration– Information Systems, SOA

• ISWIM Constraint Representation• ISWIM for testing• Conclusion

Page 3: Iswim for testing

© Xactium Ltd. 2007 3

Modelling with Constraints

Page 4: Iswim for testing

© Xactium Ltd. 2007 4

Telecomms

Page 5: Iswim for testing

© Xactium Ltd. 2007 5

Network Models

Check configurations based on properties of devices and network components.

Page 6: Iswim for testing

© Xactium Ltd. 2007 6

Aerospace

Message Bus

Integrated Modular Avionics (IMA)

Page 7: Iswim for testing

© Xactium Ltd. 2007 7

IMA Models

Check configurations of IMA components that must satisfy requirements of navigation modes.

Page 8: Iswim for testing

© Xactium Ltd. 2007 8

Payload Configurations

Page 9: Iswim for testing

© Xactium Ltd. 2007 9

Business Processes

Page 10: Iswim for testing

© Xactium Ltd. 2007 10

Restructuring A CompanyRestructureCompany

ProducePlans

Implement Plans

ProduceBizRep

DevelopPlans

ProduceRestructuringPlan

Produce OperatingPlan

DitchUnprofitableCustomers

Reorganizeproducts

Check sequences of company snapshots – do they satisfy the business goals?

Page 11: Iswim for testing

© Xactium Ltd. 2007 11

Web Services and SOA

Page 12: Iswim for testing

© Xactium Ltd. 2007 12

Information Systems

Page 13: Iswim for testing

© Xactium Ltd. 2007 13

ISWIM Constraint Representation

Page 14: Iswim for testing

© Xactium Ltd. 2007 14

Constraints

• What not to be: OCL, Java.

• Visual language (why?), with examples:– Simple state.– Variables.– And/Or/Not– Quantification– Predicates.

Page 15: Iswim for testing

© Xactium Ltd. 2007 15

Snapshots

• Objects, slots and links.

• Context must be given:– Parameters– Root object– Self in state machine.– Observations in goals.

• Conjunction of contents.

• Negation.

Page 16: Iswim for testing

© Xactium Ltd. 2007 16

Snapshots as Constraints

not c.business_report.terminal andc.restructuring_plan.addresses = c.business_report

Page 17: Iswim for testing

© Xactium Ltd. 2007 17

Sharing via Identifiers(separation of concerns)

Page 18: Iswim for testing

© Xactium Ltd. 2007 18

Negation

… but not ...

Page 19: Iswim for testing

© Xactium Ltd. 2007 19

Unknowns Tied Together

… same as …

Page 20: Iswim for testing

© Xactium Ltd. 2007 20

Links Over Collections

Page 21: Iswim for testing

© Xactium Ltd. 2007 21

Universal Quantification

Page 22: Iswim for testing

© Xactium Ltd. 2007 22

Existential Quantification

Page 23: Iswim for testing

© Xactium Ltd. 2007 23

Snapshot Checking Machine

Page 24: Iswim for testing

© Xactium Ltd. 2007 24

Syntax Model

Page 25: Iswim for testing

© Xactium Ltd. 2007 25

An Execution Machine

Page 26: Iswim for testing

© Xactium Ltd. 2007 26

Machine Transitions

Page 27: Iswim for testing

© Xactium Ltd. 2007 27

Auxiliary Machine Defs

Page 28: Iswim for testing

© Xactium Ltd. 2007 28

An Implementation –ISWIM for Model Driven Testing

Page 29: Iswim for testing

© Xactium Ltd. 2007 29

Testing Architecture

Program

Testing Engine

Interface(XML)

TestCases

(XML)

TestReports

(XML)Program

DisplayTest

Reports(HTML)

DisplayTest Cases

(HTML)

Model(XMF-Mosaic)

Test cases include:• Static Scenarios• Dynamic Scenarios• Invariants• Pre/Post Conditions• State Machines

C

B

A

DE

F

G

H

I

Page 30: Iswim for testing

© Xactium Ltd. 2007 30A sales system keeps info on customers, their accounts and their orders.Customer ids (CID) are unique, but customer information may be distributed.

Page 31: Iswim for testing

© Xactium Ltd. 2007 31

Model Browser

A model is constructed that shows the structure and behaviour of the application.

The model could be extracted from an implementation or could be constructed by hand or could be constructed from another modelling tool.

The example shows the classes extracted from a Java application.

Page 32: Iswim for testing

© Xactium Ltd. 2007 32

Test Specification

Each class may have:

• Static scenarios defining typical configurations of instances. These may be positive and negative examples.• Invariants defining conditions that must hold true at all times.

Each operation may have specifications defining:• Precondition defining an expectation of the method.• Postcondition defining a corresponding guarantee if the precondition is satisfied.

Page 33: Iswim for testing

© Xactium Ltd. 2007 33

Static ScenariosA static scenario defines a collection of objects that conforms to the model.

The tool will support the construction of the scenarios by completing slots and links where possible.

Types of values can be checked by the tool.

The scenario represents an implementation independent definition of application data.

It might represent a correct, or an illegal, configuration.

The scenario can be exported in XML and recreated as implementation data.

SomeContacts

Page 34: Iswim for testing

© Xactium Ltd. 2007 34

Example Invariant

For any sales system,

With a contacts database,

For each known person p,

It is not the case,

That the customer id value is EMPTY.

NoEmptyCID

Page 35: Iswim for testing

© Xactium Ltd. 2007 35

Another InvariantFor any sales system,

With a contacts database,

For each known person p1,

With an id x,

It is not the case that,

There is a known person p2,

With the id x,

Where p1 and p2 are different people.

AllCIDsUnique

Page 36: Iswim for testing

© Xactium Ltd. 2007 36

addContact(String id,String info)

Pre-condition Post-condition

Page 37: Iswim for testing

© Xactium Ltd. 2007 37

placeOrder(String id,int items)

post-condition

Page 38: Iswim for testing

© Xactium Ltd. 2007 38

Export as XML

Page 39: Iswim for testing

© Xactium Ltd. 2007 39

Modify Source (or use class loader)

public class SalesSystem { ContactsDB contactsDB = new ContactsDB(); OrderSystem orderSystem = new OrderSystem();

public void addContact(String CID,String info) { JTest test = JTest.startCall("test/SalesSystem","addContact",this,CID,info); if(legal(CID)) contactsDB.addContact(CID,info); test.endCall(null); } public void placeOrder(String CID,int amount) { JTest test = JTest.startCall("test/SalesSystem","placeOrder",this,CID,amount); orderSystem.placeOrder(CID,amount); test.endCall(null); }}

Page 40: Iswim for testing

© Xactium Ltd. 2007 40

A Test Harnesspublic static void main(String[] args) { SalesSystem sales =

(SalesSystem)JTest.build("test/SalesSystem", "SomeContacts"); JTest.startRecording("C:/testResults.xml"); JTest.checkInv("test/SalesSystem", sales); sales.addContact("PERSON1","Fred is a sales manager."); System.out.println(); sales.placeOrder("PERSON1",10); JTest.stopRecording();}

Page 41: Iswim for testing

© Xactium Ltd. 2007 41

Test Results

Page 42: Iswim for testing

© Xactium Ltd. 2007 42

Conclusion

• Constraints occur everywhere in modelling

• Constraints can be expressed as snapshots (ISWIM).

• Constraints can be executed in various ways to suit the solution.

• ISWIM-constraints can be implemented as a tool for model driven testing.