1. 1 Levi Lúcio © A Test Selection Language for CO-OPN Specifications Levi Lúcio, Luis Pedro and Didier Buchs University of Geneva

2. 2 Levi Lúcio © Presentation Plan oThe CO-OPN Modeling Language l CO-OPN as a prototyping tool oTesting Theory l Stating hypotheses about the SUT for test selection oA Test Selection Language for CO-OPN Specifications l Language Structure l Hypotheses On Paths On Values oConclusion

3. 3 Levi Lúcio © Presentation Plan oThe CO-OPN Modeling Language l CO-OPN as a prototyping tool oTesting Theory l Stating hypotheses about the SUT for test selection oA Test Selection Language for CO-OPN Specifications l Language Structure l Hypotheses On Paths On Values oConclusion

4. 4 Levi Lúcio © The CO-OPN Modeling Language oCO-OPN (Concurrent Object-Oriented Petri Nets) is a formal specification language, with clearly stated semantics. Based on: l Algebraic Data Types: data and associated operations l Petri Nets: behavior oIt includes object based concepts: l Class Attributes: places in a Petri Net Methods: guarded transitions in a Petri Net oPowerful synchronization mechanism l Coordination of the components of a specification Objects Contexts (stateless coordination units) l “All or nothing” semantics (sequence / parallel / choice)

5. 5 Levi Lúcio © Structure of a CO-OPN Specification Contexts (instances of) Classes Algebraic Data Types Coordinate Use Coordinate

6. 6 Levi Lúcio © Example specification in CO-OPN oA (simple) mobile phone is composed by: l A card containing (among other things) the personal identification number (PIN) to activate the phone; l A phone controller holding (among other things) the state of the phone, which can be: Off Standby (waiting for the correct PIN) Idle (ready to receive or make calls) oIn our specification the user can perform two actions: l Turn on the phone; l Insert a PIN number

7. 7 Levi Lúcio © Outer Context Coordinates the Phone Controller and the Card gate (output event) method (input event)

8. 8 Levi Lúcio © Class PhoneController Algebraic Data Types Typed values (+ operations) inside the Petri Net places…

9. 9 Levi Lúcio © CO-OPN as a Prototyping Tool oOur tool (CoopnBuilder) is able to produce Java code from a CO- OPN specification. We can then execute the specification…

10. 10 Levi Lúcio © SUT (System Under Test) Verification oWe can “run” the specification to make sure the prototype will act as expected, but… l What if the prototype is changed / extended, or simply implemented in a language other than Java? l There is no way of keeping a record of previously tested behaviors (for example for regression testing…) oSolution: devise a testing language to include test modules in CO-OPN specifications: l The test module will use the specification to generate syntactically and semantically meaningful tests; l Prototype execution provides an easy way of deciding what should be the result of a given test case when it is applied to the SUT (System Under Test).

11. 11 Levi Lúcio © Presentation Plan oThe CO-OPN Modeling Language l CO-OPN as a prototyping tool oTesting Theory l Stating hypotheses about the SUT for test selection oA Test Selection Language for CO-OPN Specifications l Language Structure l Hypotheses On Paths On Values oConclusion

12. 12 Levi Lúcio © Presentation Plan oThe CO-OPN Modeling Language l CO-OPN as a prototyping tool oTesting Theory l Stating hypotheses about the SUT for test selection oA Test Selection Language for CO-OPN Specifications l Language Structure l Hypotheses On Paths On Values oConclusion

13. 13 Levi Lúcio © Testing Theory oProblem: How do we select “interesting” tests? oIn the general case, the amount of tests for a given system is infinite: l Infinite domains for operation’s domains; l Infinite paths of execution in the SUT’s state space. oIt is necessary to restrict the “exhaustive” test set to a practicable one. This is done by providing hypotheses about the functioning of the SUT: Reduce test set Increase hypothesis strength H0H0 H1H1 … H k-1 HkHk T0T0 T1T1 … T k-1 TkTk

14. 14 Levi Lúcio © Testing Process Does P satisfy SP? PSP Test Selection (Hypotheses H Application) Execution of P using T Oracle P satisfies, or not, T! P does not satisfy SPUndefinedP satisfies SP! P satisfies, or not, H Test Set T noinconclusiveyes noyes Correction of P Test Procedure

15. 15 Levi Lúcio © Presentation Plan oThe CO-OPN Modeling Language l CO-OPN as a prototyping tool oTesting Theory l Stating hypotheses about the SUT for test selection oA Test Selection Language for CO-OPN Specifications l Language Structure l Hypotheses On Paths On Values oConclusion

16. 16 Levi Lúcio © Presentation Plan oThe CO-OPN Modeling Language l CO-OPN as a prototyping tool oTesting Theory l Stating hypotheses about the SUT for test selection oA Test Selection Language for CO-OPN Specifications l Language Structure l Hypotheses On Paths On Values oConclusion

17. 17 Levi Lúcio © Test Language Structure CO-OPN event pairs input event (method), output event (gate) (black-box approach) HML (Hennessy-Milner Logic) next operator not, and operators Hypotheses constraints over the exhaustive test set

18. 18 Levi Lúcio © Mobile Phone Example Revisited oLet us create a test module for an extended version of the Mobile phone CO-OPN specification: l A (simple) mobile phone is composed by: A card containing (among other things) the personal identification number (PIN) to activate the phone. The card gets blocked after 3 wrong attempts at inserting a PIN. A phone controller holding (among other things) the state of the phone, which can be: –Off –Standby (waiting for the correct PIN) –Idle (ready to receive or make calls) l In our specification the user can perform two actions: Turn on the phone; Insert a PIN number, Reset the card when it becomes blocked

19. 19 Levi Lúcio © ConstraintSet NatelBehaviors; Interface Constraints insertPins; block; reachOn; Body Constraints nWrongPins; Use Boolean; Pin; Axiom [] in nWrongPins; f in nWrongPins => f. HML( ) in nWrongPins; f in nWrongPins, depth(f) HML( ). f. HML( ) in insertPins; depth(f) HML( ). f. HML( ) in block; depth(f) HML( ). f. HML( ) in reachOn; Variables f : HML; m : method; g : gate; End NatelBehaviors; Test Module for the Mobile Phone Exported constraints Locally defined constraints Imported Algebraic Data Types Variables used in constraint definition Constraints’ Semantics

20. 20 Levi Lúcio © Hypotheses on Paths oThe language allows defining the shape of sequences of input/output pairs that will be used to generate tests: [] in nWrongPins; f in nWrongPins => f. HML( ) in nWrongPins; f in nWrongPins, depth(f) HML( )}. f. HML( ) in insertPins; onWrongPins (local constraint) defines an (infinite) sequence of insertPin inputs with a wrong PIN; oinsertPins defines a sequence of operations starting by turnOn, followed by a sequence of at most three insertPin inputs with a wrong PIN and finishing by any input/output pair. HML(,, ),false HML(,, <insertPin(newPin(1 1 1 1)), pinResult(false)>,, ),true HML(,,true... Examples of tests generated by the insertPin constraint:

21. 21 Levi Lúcio © Hypotheses on Values oBy default, the tests generated by the pinTest will correspond to all values of type Pin - large amount oSolution 1: Axioms HML(, ) in pinTest; Variables p : Pin; g : gate; uniformity(p) => HML(, ) in pinTest l Choose one value from the domain - equivalent to random testing… l Corresponds to the hypotheses: “if insertPin works well for one PIN, it will work well for all PINs”.

22. 22 Levi Lúcio © Hypotheses on Values (2) oSolution 2: subUniformity(p) => HML(, ) in pinTest l Choose one value from each equivalence class of the behavior of the insertPin operation. insertPin(p) P is the good PIN => Send pinResult(true) P is a wrong PIN => Send pinResult(false) oIn order to decompose the behavior of an operation we need to analyze its choice points… oThis is done by analyzing the CO-OPN specification. l Feature under development, using Prolog for symbolic execution and constraint resolution.

23. 23 Levi Lúcio © Managing Non-Determinism in the SUT oWe would like to manage behaviors of the SUT which cannot be calculated in test generation time… l Example: an e-banking application proposes a challenge as part of the authentication mechanism. How do we calculate the reply to the challenge in order to login successfully during the test? oSolution: Introduce the possibility to have “external” functions that will perform calculations in testing time. l In the e-banking case there would be a function to calculate the answer to the challenge in function of the proposed value.

24. 24 Levi Lúcio © Conclusion oWe have presented a test selection language intended at testing software (and possibly hardware) prototypes specified in CO-OPN; oThe test selection is done by the test engineer, assisted by the tool while decomposing the behavior of the operations in a specification; oThe tool is currently half implemented. We envisage on the short term a case study to fully validate our ideas, also in terms of scalability.