henk doornbos & rix groenboom - test patterns: a new concept for testing
TRANSCRIPT
Overview
• Testing challenge
• Current testing techniques
• New approaches
• Towards Test Patterns
• Conclusions
Testing is Difficult
• SOA in particular– Heterogeneous interfaces: Web, Gui, WS, JMS, JDBC– Many dependencies– Many re-configurations
• SOA – Mesh:
– Mash up:– Mess: Spaghetti oriented architecture
Testing is Difficult
• Architecture is heterogeneous
JUBES
ERSB2B
B2BG
B2BG
BPEL EBS
IPEX
ebXML / ebMS AQ AQ DB link GUI
TestTool
Advanced Queues
CJIB
VIP
JDS
HTTP / SOAP
Testing is Difficult
• Many different interfaces:
JUBES
ERSB2B
B2BG
B2BG
BPEL EBS
IPEX
ebXML / ebMS AQ AQ DB link GUI
TestTool
Advanced Queues
CJIB
VIP
JDS
HTTP / SOAP
Testing is Difficult
• Tester performs manual steps, eg:– Enter user-data via website (with IE)– Check database status (with TOAD)– Submit XML message (with SOAPui)
– Check database status (with TOAD)
• Therefore, current process is tedious:– hence error propone– Not repeatable
Current testing tools
• Currently, there is a portfolio of testing tools with a focus on automation:– Test management tools– Individual tools for testing (GUI, Web, Load, DB)
• Main problem:– Semantic gap, the tester is the “glue” between the
different tools
Current testing tools
• Example: TestFrame– Excel based technology– Separation between logical and physical test cases– Ad-hoc engine implementation for test automation
– No clear semantics
Current testing tools
• Example: SOAtest– Platform for testing SOA implementations– Supports of multiple protocols (HTTP / JDBC etc)– Test flow over multiple interfaces is possible
– Example CRUD operations:• Search service call• Retrieve service call• Update service call
• Validate Database
Towards solution
• More powerful tools allow automation of testing often for single interfaces– Solves the technical interaction and provides repeatability
• We still need an integrated framework to drive the testing and to process the results (orchestration)– Provides the flexibility to handle overall architecture
Towards solution
• IDEA 1: Use structure of architecture for testing– Architecture is most stable part of applications– Clearly defined interfaces
DatabaseServer
Application Server
Legacy
Presentation Layer
Web Services
Application Logic Thin
ClientWeb Site
Towards solution
• IDEA 2: Regard testing as a business process– Make basic steps executable: call the relevant testing
tools using a web-service interface– BPEL for Test Orchestration
BPEL: Advantages
• BPEL:– Web standard– Direct execution of webservices– Programming language, so you can define patterns
(recurring structures)
– There are semantics so you can reason about processes
• BPEL for testing:– Provide test-tool with web-service interface, so we can
communicate with them directly from BPEL
BPEL: Provides also semantics
• Requires mathematical solution :– Parallelism, non deterministic, asynchronous
• Testing will have mathematic laws:– T1 + T2 = T2 + T1– T1 || T2 = T2 || T1– T1 + ( T2 || T3 ) = (T1 || T2) + (T1 || T3)
• Use process algebra like CSP:– Provides a framework to compose operations
Example pattern (1)
• Standard ESB structure:– Basic services– Integrated services– Business services
– User layer: GUI
• Which test pattern ?
Example pattern (1)
• Proposed test pattern:– Unit testing of basic services– Integration test: no new logic, therefore nothing to test– Business process testing: Web submission
Example pattern (2)
• Database application with WS front-end– B2B communication– Legacy backend communication (mailboxes)
Conclusions
• Testing of SOA is becoming increasingly complex– Requires more mathematical approach
• BPEL can be used to model the test process– Higher level of abstraction– Better defined semantics
• Will lead to a library of test-patterns:– Using proper automation, this gives reuse of test effort