Fault-Based Test Case Generation for Component Connectors

Abstract

The complex interactions appearing in service-oriented computing make coordination a key concern in serviceoriented systems.

Passive conformance testing of service choreographies

“…The trace sets of R1, R2, and R = R1 R2, that represent respectively all possible executions of R1, R2, and their collaboration: [1,2] !, c2 [2,1] ?, c3 [2,1] ? , c1 [1,2] !, c3 [2,1] ?, c2 [2,1] [1,2] ?, c2 [2,1] !, c3 [2,1] ! , c1 [1,2] ?, c3 [2,1] !, c2 [2,1] [1,2] , c2 [2,1] , c3 [2,1] , c1 [1,2] , c3 [2,1] , c2 [2,1] …”

“…This is especially the case with non-realizable choreographies. Take for example the specification C = c1 [1,2] ; c2 [3,4] . Projecting it on its roles we get R1 = c1 [1,2] !, R2 = c1 [1,2] ?, R3 = c2 [3,4] !, and R4 = c2 [3,4] ?.…”

“…Take for example the specification C = c1 [1,2] ; c2 [3,4] . Projecting it on its roles we get R1 = c1 [1,2] !, R2 = c1 [1,2] ?, R3 = c2 [3,4] !, and R4 = c2 [3,4] ?. Implementing the specification using these four peers as-is, i.e., I = R1 R2 R3 R4, the developer cannot prevent that R3 and R4 interact on c2 before R1 has sent c1 to R2: trace c2 [3,4] , c1 [1,2] [1,2] , c2 [3,4] }.…”

“…Projecting it on its roles we get R1 = c1 [1,2] !, R2 = c1 [1,2] ?, R3 = c2 [3,4] !, and R4 = c2 [3,4] ?. Implementing the specification using these four peers as-is, i.e., I = R1 R2 R3 R4, the developer cannot prevent that R3 and R4 interact on c2 before R1 has sent c1 to R2: trace c2 [3,4] , c1 [1,2] [1,2] , c2 [3,4] }. Therefore, the developer may decide to add a synchronizing message between R2 and R3, csync, to enforce the choreography, i.e., replacing R2 and R3 above respectively by c1 [1,2] ?…”

Generating Distinguishing Tests Using the Minion Constraint Solver

“…Our group used different modeling styles and tools to generate the distinguishing test cases: for OCL pre-postcondition contracts a constraint-solver was used [18], for Spec# contracts we exploited Microsoft's Z3 SMT-solver [21], for LOTOS protocol specifications first a bisimulation checker [16], then an ioco-conformance checker [24] was applied, and finally model checkers served to generate distinguishing test cases for embedded systems [25] and REO coordination models [15]. None of these papers considered programs.…”