Messages msg and msg are identi-fied the two test cases

Towards a Model Based Approach for Integration Testing

Mohamed Mussa and Ferhat Khendek

The development of test artifacts goes through several stages in parallel with the software development process. Important stages include unit-level, integration-level and acceptance-level testing. Unit-level testing is applied to components and targets frequent developers’ bugs. Integration-level testing is used to check compatibility, interoperability and the consistency among the integrated components. Acceptance-level testing aims at validating the system against user requirements.

To master and overcome the increasing complexity of software systems, new development and testing techniques need to be developed. The Unified Modeling Language (UML) [28] is nowadays a widely accepted modeling language. The Mod-el-Driven Engineering (MDE) paradigm [23] aims at increasing the level of abstrac-tion in the early stages of the software development process and eliminate barriers between modeling (documentation) and implementation (code). Model Driven Archi-tecture (MDA) [25] is the most widely known initiative of MDE. On the other hand, Model-Based Testing (MBT) [29] was introduced to cope with model development techniques, involve and enforce test planning in the early stages of the software life-cycle. Test models can be shared among stakeholders and enable mutual understand-ing. MBT approaches based on UML have been proposed for different testing phases; see for instance [1, 5, 11, 20]. Moreover, several domains have been targeted includ-ing automotive and telecommunications [7, 19, 24].

research investigations based on UTP, see for instance [16, 17, 19, 20]. However, most of these studies focus on one phase of the testing process, mainly unit-level or system level testing. In our research project, we aim at covering the integration and acceptance testing starting from available unit testing artifacts. We focus on an MDA conform approach to generate integration UTP models from unit UTP models. In this approach, components are integrated into system context in a recursive manner. A component and a context test models are merged to generate an integration test mod-el, which will form the context test model for the next integration step. Test cases with interactions involving the component and the context are selected and merged to build the integration test model. Unit test stubs and drivers are reused in the integra-tion test model. Our approach is illustrated throughout the paper.

The rest of this paper is structured as follows. Section 2 introduces briefly UTP for setting up the context. We introduce our approach for integration test models genera-tion in Section 3. In Section 4, we discuss related work and we finally conclude in Section 5.

testAtt1: type

Towards a Model Based Approach for Integration Testing 109

«TestComponent» «SUT» «TestComponent» tc1: TClass1 Sys:sSUTContext tc2: TClass5 msg1

Fig. 4. UTP test case

In addition to the aforementioned concepts, there are several others that can be used to model concise test specifications. For example, testers can use time concepts to define shared time zone among group of test components, use data concepts to define wild cards for ignoring unimportant data in the test model, or use test arbiters to evaluate the test case verdict. A UTP test model can be mapped to a test execution environment such as JUnit [12] or TTCN-3 [26] to execute the test cases and analyze the results [1].

System Context

2.Integration testing phase (as detailed in Figure 7)
(a)Initially, two unit UTP models (UTPc1 & UTPc2) are supplied to the trans- formation engine to generate the first integration UTP model (UTPint).

(i)Integration testing is applied to the sub-system (Context) consisting of the two components (comp1, comp2).

(iii)Step 2.b is repeated for subsequent components integration.

3.Acceptance testing phase
(a)Independently, the acceptance UTP model is generated from the user re- quirements.

Fig. 7. UTP based integration testing

The framework is based on standards where test models are built and generated based on UTP and the transformations using QVT (Query, View and Transformation) [21]. Reusability is a central asset in the framework where unit UTP models are reused to generate the integration UTP model and test case merger is used to produce an optimized UTP model.

112 M. Mussa and F. Khendek

Step 1: Selecting test cases with interactions between the Context and the Compo-nent.Finding interaction test cases between the two SUTs (the Context and the Component) is not an easy task. An instance of the two SUTs must be present in the selected test case with at least one exchanged message. This interaction can be direct or indirect. The interaction is direct when one or each SUT is present in the other UTP model as a TestComponent (stub or driver). Interactions are called indirect when there is a shared UTP test-component in the two input UTP models. The shared UTP test-component must interact with the two SUTs with complementary messages in one test case at least in each input UTP model. The following algorithm uses UTP Test-context Diagrams of the two input UTP models to locate the interaction objects.

to the UTP specification. Similarly, the component SUT object is compared to the UTP test-components in the test-context of the Context UTP model. In addition to the identification of each SUT in the other UTP model, the algorithm looks for the exis-tence of any shared UTP test-components defined in the two UTP models. This task is accomplished by comparing each UTP test-component in the Context test-context diagram against the UTP test-components in the Component test-context diagram.

Figure 8 illustrates a direct interaction scenario. From the two UTP Test-contexts, the Context SUT (comp1) is represented in the Component UTP model as a TestCom-ponent and the Component SUT (comp2) is represented in the Context UTP model as a TestComponent. By searching test cases (testCase1, testCase2, testCase3, testCase4 and testCase5), test cases with comp1 and comp2 present in their diagram are selected (testCase1 and testCase4). The flow of the received/sent messages of the two objects is examined in each selected test case. The existence of direct or indirect messaging between the two objects moves the selected test cases to the next step.

The following algorithm searches for the existence of the two SUTs in the test cas-es. It consists of two rounds. The first round is executed when the Component SUT is identified in Context UTP model. It searches through the meta-model of the Context UTP model for the declared test cases in the test-context class. The Context UTP test-components of each test case are compared to the Context UTP test-component which represents the Component SUT. If there is a match then this test case is added to the selected test cases list. The second round is executed only if the Context SUT is iden-tified in Component UTP model. It searches through the meta-model of the Compo-nent UTP model for the declared test cases in the test-context class. The Component UTP test-components of each test case are compared to the Component UTP test-component which represents the Context SUT. If there is a match then this test case is added to the selected test cases list.

intTestCases = intTestCases-> append(tc); }
}

// select test cases that consist both SUTs from the Component UTP model

Fig. 9. Indirect interaction between Context and Component

Figure 9 illustrates an indirect interaction scenario. The TestComponent (comp3) exists in the two input UTP models (the Context and the Component). By searching remaining test cases (testCase2, testCase3 and testCase5) for the existence of the shared TestComponent (comp3) in their diagram. If there is at least one test case from

The integrated test case23

Step 3: Merging the selected test cases. In this step, complementary test cases among the selected test cases are merged. Messages of the merged objects are ordered to preserve their order according to the specification of the two test cases. TestContext which represents the test-environment is replaced with the actual TestComponent or SUT when applicable. For instance, test cases (testCase2 and testCase3) in Figure 9 are merged to produce one test case (testCase23) shown in Figure 10. Test-component (comp3) is the shared UTP test-component. Messages (msg11 and msg14) are identi-fied in the two test cases. The TestContext (tTestCont05), which represents the test-environment in the first test case (testCase2), is substituted by the Component SUT (comp2). The two test cases are mapped with reference to the shared (comp3). Mes-sages of the shared component (comp3) in the two test cases (testCase2 and testCase3) are merged with order preservation.

Fig. 11. Test cases merging issues

Phase II: UTP Test-context Generation. The second phase targets the construction of the test-context diagram of the integration UTP model. Since the UTP test-context represents the structural part of the UTP model, the two input test-contexts share most of their components. Our approach generates the integration test-context by updating the Context test-context from the Component test-context using the following trans-formation rules:

•A copy of the Context test-context diagram builds the initial integration test- context diagram.

Towards a Model Based Approach for Integration Testing 117

•If a Context stub (or driver) which represents the Component SUT exists, it is re- placed with the Component SUT package from the Component test-architecture.

Otherwise, the Component SUT package is copied to the generated test-architecture.

4 Related Work

UTP has been adopted recently, thus there is a limited work related to its usage in the literature. Busch et al. [6] present an MDA approach for generating UTP models from design models. Platform independent models (PIMs) are transformed into plat-form independent UTP models (PITs). Platform specific models (PSMs) are trans-formed into Platform specific UTP models (PSTs), and finally PITs are transformed into PSTs. Both PIT and PST are based on UTP. The approach focuses only on sys-tem testing; while our approach focuses on integration testing. In this approach, sys-tem testing is applied after integration testing and prior to acceptance testing, and it is intended to demonstrate that the system behaves as designed/specified. Lamancha et al. [16] propose an MDA approach to generate UTP models from the system design models. UTP models are built from UML use cases and sequence diagrams.

5 Conclusion

In this paper, an approach for building integration test models using UTP has been presented. Integration UTP models are constructed recursively from unit UTP models. Notice that this integration can be done, and repeated, at different levels depending on the level of granularity of the units. Our work is still in progress and a full frame-work is under investigation.

1.Baker, P.: Model-Driven Testing: Using the UML Testing Profile. Springer, New York (2008)
2.Ben-Abdallah, H., Leue, S.: Syntactic detection of process divergence and non-local choice in message sequence charts. In: Brinksma, E. (ed.) TACAS 1997. LNCS, vol. 1217, pp. 259–274. Springer, Heidelberg (1997)

120 M. Mussa and F. Khendek

21.QVT, http://www.omg.org/spec/QVT
22.Sadaoui, S.: Composition of Structured Process Specifications. Electronic Notes in Theo- retical Computer Science, 132–143 (2003)
23.Schmidt, D.C.: Guest Editor’s Introduction: Model-Driven Engineering. Computer, 25–31 (2006)
24.Suss, J.G., Pop, A., Fritzson, P., Wildman, L.: Towards integrated model-driven testing of SCADA systems using the eclipse modeling framework and modelica. In: 19th Australian Conference Software Engineering, ASWEC 2008, pp. 149–159 (2008)
25.The Architecture of Choice for a Changing World, http://www.omg.org/mda 26.TTCN-3, http://www.ttcn-3.org
27.UML Testing Profile, http://utp.omg.org
28.Unified Modeling Language, http://www.uml.org
29.Utting, M., Legeard, B.: Practical Model-Based Testing: A Tools Approach. Morgan Kaufmann Publishers, Boston (2007)
30.Valmari, A.: The state explosion problem. Advances in Petri Nets, 429–528 (1998) 31.Xie, G., Dang, Z.: Testing systems of concurrent black-Boxes—An automata-theoretic and decompositional approach. In: Grieskamp, W., Weise, C. (eds.) FATES 2005. LNCS, vol. 3997, pp. 170–186. Springer, Heidelberg (2006)