Generation of TTCN-3 Test Cases from Use Case Map Scenarios

1. Generation of TTCN-3 Test Cases from Use Case Map Scenarios Bryan Mulvihill Supervised by Dr. Daniel Amyot

2. Goal • The goal of this project is to convert Use Case Map Scenarios to test goals and test cases expressed in Testing and Test Control Notation version 3.

3. What are Use Case Maps? • Use Case Maps (UCMs) are a scenario-based software engineering technique that have a history of application to the description of object-oriented systems and reactive systems in various areas, including wireless, mobile, and agent domains. • UCMs are used as a visual notation for describing causal relationships between responsibilities of one or more use cases. • UCMs model the functional requirements as scenarios.

4. Use Case Map Example

5. Use Case Map Scenarios • Scenarios define a path through the UCM given a set of conditions. • Allows for the extraction of individual scenarios from an integrated collection for visualization, analysis, and conversion to other representations.

6. Use Case Map Scenario Example Scenario follows the red line.

7. Testing and Test Control Notation 3 • TTCN-3 is a flexible and powerful language applicable to the specification of all types of reactive system tests over a variety of communication interfaces • TTCN-3 is intended to be used for the specification of test suites which are independent of test methods, layers and protocols. • TTCN-3 is not restricted to conformance testing and can be used for many other kinds of testing including interoperability, robustness, regression, system and integration testing. • In earlier versions of  the language TTCN stands for Tree and Tabular Combined Notation. The new meaning Testing and Test Control Notation is more apt for TTCN-3.

8. Purpose of this Project • Develop test cases from functional requirements. • Show proof of concept.

9. Technologies Used • XML – UCM Scenarios are defined by an XML format. • Java & Xerces Parser – Used to read in scenario and manipulate Document Object Model (DOM). • XSLT & Xalan – Used to convert DOM using a stylesheet.

10. Structure of a UCM Scenario

11. Structure of a TTCN-3 Module The principal building blocks of TTCN-3 are modules. Modules may define a suite of testcases, or just a library. Modules mainly consist of: • Functions – used for commonly executed behaviour. Much like functions in C++ or methods in Java. • Signature declarations – declares a method called across a port. Acts like a remote procedure call. • Components – data types that testcases run on. A main test component (MTC) is created when the testcase is executed. • Testcases – an executable portion of the module. A module may contain any number of testcases.

12. TTCN-3 Ports Ports are how components communicate with the system under test (SUT) and other components. TTCN has three types of ports: • Message – allows for sending data. • Procedure – allows for remote procedure calls (defined by signatures). • Mixed – acts as both a message based port and procedure based port.

13. TTCN Example /* An example module */ module Example { // Port declaration typeport MyPortType procedure { inout all } // Component declaration typecomponent MyTestComponent { port MyPortType MyPort }

14. // Function definition function MyFunction(inoutinteger foo) { foo := 10 * foo; } //signature declaration signature MyMethod(ininteger num) return charstring; testcase ExampleTestCase() runson MyTestComponent system MyTestComponent { map(mtc:MyPort, system:MyPort); thePort.call(MyMethod:{3}); alt { [] thePort.getreply(MyMethod:{3} value “success”) {} [] thePort.getreply { //non zero value, fail verdict.set(fail); } } verdict.set(pass); } }

15. Mappings • Group – a group of scenario elements. group elements map to TTCN modules. Each module is put into its own TTCN file. XML of UCMS <group name=”GroupName” group-id = "1" description=”group description”> … </group> Generated TTCN module GroupName { /*group description*/ ... }

16. Mappings • Scenario - A scenario is a sequential or parallel set of instructions. These map to TTCN testcases. XML of UCM Scenario <scenario name='ScenarioName'> … </scenario> Generated TTCN testcase ScenarioName() runson DefaultComponent system DefaultSystemComponent { ... }

17. Mappings • Par – Represents a set of instructions to be executed in parallel. par elements are modelled as parallel test components (PTC) and called when encountered in the scenario. This requires the group template to look for par elements and create functions for each set of instructions in them. When they are encountered in the scenario, a PTC is created and started for each set of instructions in the par element.

18. Generated TTCN function PTC001() runs on DefaultPTC { ... } function PTC002() runs on DefaultPTC { ... } //in scenario var DefaultPTC PTC001; PTC001 := DefaultPTC.create; PTC001.start(PTC001()); var DefaultPTC PTC002; PTC002 := DefaultPTC.create; PTC002.start(PTC002()); PTC001.done; PTC002.done; XML of UCM Scenario <par> <seq> … </seq> <seq> … </seq> </par>

19. Mappings • Do – Resp type – The do element with type “Resp” (short for responsibility) acts as a remote procedure call to a component. A call to the right signature is made, and the reply is checked for success. XML of UCM Scenario <do hyperedge-id="17" name="Acquire" type="Resp" component-name = "Security" component-id= "2" /> Generated TTCN thePort.call(Security00_00Acquire); alt { [] thePort.getreply(Security00_00Acquire value 0){ } [] thePort.getreply { //non zero value, fail verdict.set(fail); } }

20. Putting it All Together <?xml version='1.0' standalone='no'?> <!DOCTYPE scenarios SYSTEM "scenarios1.dtd"> <scenarios date ="Tue Oct 1 13:31:25 2002" ucm-file = "SAM02.ucm" design-name = "SAM02" ucm-design-version = "18"> <group name = "PassWord" group-id = "2" > <scenario name = "PWNotOK" scenario-definition-id = "2" > <seq> <par> <seq> <do hyperedge-id="0" name="Access" type="Start" component-name = "TaxPayer" component-id= "5" /> <do hyperedge-id="3" name="CheckID" type="Resp" component-name = "Security" component-id= "2" /> <do hyperedge-id="41" name="PW" type="Connect_Start" component-name = "TaxPayer" component-id= "5"/> <do hyperedge-id="43" name="Wait4PW" type="Timer_Set" component-name = "TaxPayer" component-id= "5"/> </seq> <seq> <do hyperedge-id="59" name="InputPW" type="Start" component-name = "TaxPayer" component-id= "5" /> <do hyperedge-id="61" type="Trigger_End" component-name = "Security" component-id= "2"/> </seq> </par> <do hyperedge-id="43" name="Wait4PW" type="Timer_Reset" component-name = "Security" component-id= "2"/> <condition hyperedge-id="48" label="[PWNotOK]" expression ="!bv0" /> <do hyperedge-id="53" name="Reject" type="Resp" component-name = "Security" component-id= "2"/> <do hyperedge-id="47" name="No" type="Connect_End" component-name = "Security" component-id= "2"/> <do hyperedge-id="16" name="LogRej" type="Resp" component-name = "Security" component-id= "2" /> <do hyperedge-id="14" name="Rejected" type="End_Point" component-name = "TaxPayer" component-id= "5" /> </seq> </scenario> </group> </scenarios>

21. module PassWord { /* */ //Port type definition typeport MixedPort mixed { inout all } timer Wait4PW; signature Security00_00LogRej() returninteger; signature Security00_00CheckID() returninteger; signature Security00_00Reject() returninteger; // Default Component typecomponent DefaultComponent { port MixedPort thePort; } typecomponent DefaultPTC { port MixedPort thePort; }

22. function PTCN12() runs on DefaultPTC { //Start thePort.call(Security00_00CheckID); alt { [] thePort.getreply(Security00_00CheckID value 0) { } [] thePort.getreply { //non zero value, fail verdict.set(fail); } } Wait4PW.start; } function PTCN23() runs on DefaultPTC { //Start } testcase PWNotOK() runson DefaultComponent system DefaultComponent { map(mtc:thePort, system:thePort); var DefaultPTC vPTCN12:= DefaultPTC.create; vPTCN12.start( PTCN12() ); var DefaultPTC vPTCN23:= DefaultPTC.create; vPTCN23.start( PTCN23() ); vPTCN12.done; vPTCN23.done;

23. Wait4PW.stop; thePort.call(Security00_00Reject); alt { [] thePort.getreply(Security00_00Reject value 0) { } [] thePort.getreply { //non zero value, fail verdict.set(fail); } } thePort.call(Security00_00LogRej); alt { [] thePort.getreply(Security00_00LogRej value 0) { } [] thePort.getreply { //non zero value, fail verdict.set(fail); } } verdict.set(pass); //by default everything passes } }

24. Signatures and Generated Java Code • From the known Components and signatures, Java classes and corresponding methods can be created. This creates a skeleton for the test environment.

25. Signatures signature Security00_00Acquire() return integer; signature Security00_00CheckID() return integer; Generated Java //Security.java publicclass Security { publicstaticint Acquire() { return 0; } publicstaticint CheckID() { return 0; } }

26. TTthree • TTthree is a TTCN-3 parser and compiler. Written by Testing Technologies, TTthree builds a .jar file from the TTCN module that can be executed by μTTman, a TTCN test management application. • Generated TTCN scripts were tested and compiled using TTthree.

27. Future Additions • Execute testcases using μTTman. • Clean up component names before transformation. • Use state information from UCM scenario in TTCN script. • Multiple test components for a distributed test environment.

28. Thank You!Any questions?