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

Folie 2 Alexander Kraas Oct Contents  Motivation  Toolchain and Workflow  Design Goals  Structure and Mapping of XTR Test Cases  Conclusion & Future work

Folie 3 Alexander Kraas Oct 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

Folie 4 Alexander Kraas Oct 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

Folie 5 Alexander Kraas Oct 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

Folie 6 Alexander Kraas Oct 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

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

Folie 8 Alexander Kraas Oct Data type definitions and their mapping to TTCN-3 Structure and Mapping of XTR Test Cases (2)

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

Folie 10 Alexander Kraas Oct Test architecture Structure and Mapping of XTR Test Cases (3) A XTR test architecture can consists of:  Test components for protocol tests  Test components for API tests

Folie 11 Alexander Kraas Oct Test architecture Structure and Mapping of XTR Test Cases (3)

Folie 12 Alexander Kraas Oct Test architecture 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 Ports map (Component_1.pco1:system.pco1); map (Component_2.pco2:system.pco2); // starting Components behaviour Component_1.start(testBehaviour_1()); Component_2.start(testBehaviour_2()); }

Folie 13 Alexander Kraas Oct Specification of a XTR test case Structure and Mapping of XTR Test Cases (4) Concurrent test behavior:  Expressed by different groups of elements  Running on different testComponents

Folie 14 Alexander Kraas Oct Specification of a XTR test case Structure and Mapping of XTR Test Cases (4) elements are used to specify different interactions with the SUT:  For message-based communication and  For procedure-based communication, and

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

Folie 16 Alexander Kraas Oct Specification of a XTR test case Structure and Mapping of XTR Test Cases (4) Test verdict is determined by the result of ,  or  test interactions.

Folie 17 Alexander Kraas Oct Specification of a XTR test case 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 }

Folie 18 Alexander Kraas Oct 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

Folie 19 Alexander Kraas Oct Any Questions?