XML-based Representation of Test Cases for Distributed Systems

1. XML-based Representation of Test Cases for Distributed Systems Alexander Kraas 7. October 2008

2. Contents • Motivation • Toolchain and Workflow • Design Goals • Structure and Mapping of XTR Test Cases • Conclusion & Future work

3. Motivation • Actual situation • Many commercial and academic tools for the model-based test generation • Different solutions for test case specification: • Using the same language for programming the SUT and writing test cases • Specification of test cases with scripting languages, e.g. TCL • Utilization of specialized testing languages, for example TTCN-3 • Only a small number of test generation tools support several target languages • Motivation for using an abstract representation format • A test representation format can facilitates: • The exchange of test cases between different tools • The implementation of adapters for different target languages • Advantages of using XML for test case representation: • XML documents can be formalized by XML Schemata (XSD) • XML is human-readable

4. Toolchain and Workflow (1) • Exemplarily architecture of a tool chain which utilizes the XTR format • Different test case generators and other optional modules • Adaptors for different target languages

5. Toolchain and Workflow (2) • Workflow of test case generation with the XTR format • Test Case Generator produces test cases in the XTR format • Optional modules can be used for post-processing of XTR test cases • A Language Adapter transforms XTR test cases into a target language,e.g. TTCN-3 or JUnit

6. Design Goals • The design of the XTR format rests on following main objectives • Representation of black-box test cases for the test of distributed communication systems • Support of concurrency and asynchronous communication • Usage of a simplified test architecture (without communication ports) • Powerful data type concept for representing user-defined as well as object-oriented data types • Providing only a minimal set of test interactions, because only automatic generated test cases should be represented

7. Structure and Mapping of XTR Test Cases (1) • The structure of a XTR test suite consists of four different element groups • <typeDefinitions> • Containing all data types used by the test cases • Definitions can consists of simple as well as complex data types • <templateDefinitions> • Optional template definitions for data types. • Templates can represent pre-defined values or matching expressions • <testArchitecture> • Specification of an abstract test architecture • The architecture have to be used by all test cases of a XTR test suite. • <testCases> • This element contains all test cases of a XTR test suite

8. Structure and Mapping of XTR Test Cases (2) • Data type definitions and their mapping to TTCN-3

9. type record attrib_ExampleClass { charstring name }signature setName_ExampleClass (inout charstring par1) exception (charstring); Structure and Mapping of XTR Test Cases (2) • Data type definitions and their mapping to TTCN-3

10. Structure and Mapping of XTR Test Cases (3) • Test architecture • A XTR test architecture can consists of: • Test components for protocol tests • Test components for API tests

11. Structure and Mapping of XTR Test Cases (3) • Test architecture

12. Structure and Mapping of XTR Test Cases (3) testcase TC_1() runs on mtcType { //creating parallel testComponents:var t_Component_1 Component_1 := Component_1.create;var t_Component_2 Component_2 := Component_2.create; // mapping to System Portsmap (Component_1.pco1:system.pco1);map (Component_2.pco2:system.pco2); // starting Components behaviour Component_1.start(testBehaviour_1()); Component_2.start(testBehaviour_2());} • Test architecture

13. Structure and Mapping of XTR Test Cases (4) • Specification of a XTR test case • Concurrent test behavior: • Expressed by different groups of <testBehavior> elements • Running on different testComponents

14. Structure and Mapping of XTR Test Cases (4) • Specification of a XTR test case • <testInteraction> elements are used to specify different interactions with the SUT: • For message-based communication <send> and <receive> • For procedure-basedcommunication <call>, <return> and <catch>

15. Structure and Mapping of XTR Test Cases (4) • Specification of a XTR test case • Values for test interactions can be assigned in three different ways: • Fixed inline values • Templates • Dynamic values from local variables

16. Structure and Mapping of XTR Test Cases (4) • Specification of a XTR test case • Test verdict is determined by the result of • <receive>, • <return> or • <catch> test interactions.

17. Structure and Mapping of XTR Test Cases (4) function testBehaviour_2 () runs on Component_2 { timer timeOutTimer := 15.0; timer waitTimer := 15.0; { pco2.send(...) // sending a fixed value timeOutTimer.start; alt { []pco2.receive(aTemplate) { setverdict(pass); timeOutTimer.stop;} []pco2.receive(?) { setverdict(fail); timeOutTimer.stop;} [] timeOutTimer.timeout{ setverdict(fail);} } synchronize(); // Waiting for other testcomponents} • Specification of a XTR test case

18. Conclusion & Future work • Summary • The XTR format has been designed in order to represent test cases for distributed communicating systems • Support for asynchronous communication and concurrency • Mappings to different target languages • XTR is independent from any test generation tool • Open Issues • Further refinements of the XTR format specification • Applicability of the XTR format for representing large test cases • Integration of different test case generators

19. Any Questions?