Iswim for testing

425 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
425
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Iswim for testing

  1. 1. ISWIM For Testing – A Model Driven Approach Tony Clark tony.clark@tvu.ac.ukhttp://itcentre.tvu.ac.uk/~clark 1
  2. 2. Overview• A Requirement for Constraints: – Telecomms – Aerospace – Business Migration – Information Systems, SOA• ISWIM Constraint Representation• ISWIM for testing• Conclusion 2
  3. 3. Modelling with Constraints 3
  4. 4. Telecomms 4
  5. 5. Network ModelsCheck configurations basedon properties of devices andnetwork components. 5
  6. 6. Aerospace Message BusIntegrated Modular Avionics (IMA) 6
  7. 7. IMA Models Check configurations of IMA components that must satisfy requirements of navigation modes. 7
  8. 8. Payload Configurations 8
  9. 9. Business Processes 9
  10. 10. Restructuring A Company Restructure Company Produce Implement Plans Plans Develop DitchProduce Reorganize Plans UnprofitableBizRep products Produce Produce Customers Restructuring Operating Plan Plan Check sequences of company snapshots – do they satisfy the business goals? © Xactium Ltd. 2007 10
  11. 11. Web Services and SOA © Ltd. 2007 11
  12. 12. Information Systems © Xactium Ltd. 2007 12
  13. 13. ISWIM Constraint Representation 13
  14. 14. Constraints• What not to be: OCL, Java.• Visual language (why?), with examples: – Simple state. – Variables. – And/Or/Not – Quantification – Predicates. 14
  15. 15. Snapshots• Objects, slots and links.• Context must be given: – Parameters – Root object – Self in state machine. – Observations in goals.• Conjunction of contents.• Negation. 15
  16. 16. Snapshots as Constraintsnot c.business_report.terminal andc.restructuring_plan.addresses = c.business_report 16
  17. 17. Sharing via Identifiers (separation of concerns) 17
  18. 18. Negation… but not ... 18
  19. 19. Unknowns Tied Together … same as … 19
  20. 20. Links Over Collections 20
  21. 21. Universal Quantification 21
  22. 22. Existential Quantification 22
  23. 23. Snapshot Checking Machine 23
  24. 24. Syntax Model 24
  25. 25. An Execution Machine © Xactium Ltd. 2007 25
  26. 26. Machine Transitions 26
  27. 27. Auxiliary Machine Defs 27
  28. 28. An Implementation –ISWIM for Model Driven Testing 28
  29. 29. Testing Architecture C A Model Interface Program (XMF-Mosaic) (XML) B E D Display Test TestingTest Cases Cases Engine (XML) (HTML) G H Test cases include: F • Static Scenarios Test Display • Dynamic Scenarios Test Reports (XML)Program • Invariants Reports • Pre/Post Conditions (HTML) • State Machines 29 I
  30. 30. A sales system keeps info on customers, accounts and their orders. 30Customer ids (CID) are unique, but custotheir mer information may be distributed.
  31. 31. Model BrowserA model is constructed that shows thestructure and behaviour of theapplication.The model could be extracted froman implementation or could beconstructed by hand or could beconstructed from another modellingtool.The example shows the classesextracted from a Java application. 31
  32. 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. 32
  33. 33. Static Scenarios A 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,SomeContacts configuration. The scenario can be exported in XML and recreated as implementation data. 33
  34. 34. Example InvariantFor any sales system,With a contacts database,For each known person p,It is not the case,That the customer id value isEMPTY. NoEmptyCID 34
  35. 35. Another InvariantFor any sales system,With a contactsdatabase,For each knownperson p1,With an id x,It is not the case that,There is a knownperson p2,With the id x,Where p1 and p2 are 35 AllCIDsUniquedifferent people.
  36. 36. addContact(String id,String info) Pre-condition Post-condition 36
  37. 37. placeOrder(String id,int items) post-condition 37
  38. 38. Export as XML © Xactium Ltd. 2007 38
  39. 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); }} 39
  40. 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();} 40
  41. 41. Test Results © Xactium Ltd. 2007 41
  42. 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. 42

×