A Practical approach to UML-based derivation of integration tests F. Basanieri, A. Bertolino IEI-CNR, Pisa, Italy Abstract: We present an on-going project for developing a We present here our practical approach for UML- tool supported test methodology based on UML descriptions. based integration testing, that is called Use- The leading criteria of this investigation are that no Interaction testing, as it mainly uses the UML Use additional language or expertise is required more than UML, Case and Interaction diagrams (specifically, the and that the methodology can be easily transferred to Sequence diagram). Indeed, integration testing is industrial contexts. aimed at verifying that the (hopefully pre-tested) system components interact correctly, and UML Keywords: Interaction diagrams can provide the information Category-partition, Integration test strategy, UML, Use- of how the system components should interact. Interaction test. The proposed approach is very simple, and is inspired at large by the well-known Category 1. INTRODUCTION Partition method [OB88]: we first look at the Use In recent years, the object oriented (OO) Case diagram to identify the suitable steps of an paradigm has got widespread use. Software incremental test strategy. For each identified sub- developers need appropriate OO models and Use Case, we then look at the Sequence diagram support tools for describing and analysing the to identify the relevant components, or "Test characteristics of complex distributed systems. OO Units". For each Test Unit, we derive the relevant system models usually involve graphical notations, "Settings" (could be parameters, variables, so that the relationships between the many environmental states) and the relevant elements (objects) forming the system can be "Interactions" (essentially, messages from other easily visualized. Test Units), and identify for them the significant UML, the Unified Modeling Language, is the "Choices" (with the same meaning of the Category emerging graphical notation to model, document Partition method). To do this, we can analyse the and specify OO systems along all the phases of related Class Diagrams, as well as other design the software process. Indeed, there exist now documentation. Hence, by following the many studies about using UML for design, and sequences of messages between the components many tools are available. However, only a little over the Sequence Diagram, we construct the Test part of these studies so far has addressed the usage Cases, whereby each Test Case is characterized by of UML for testing, and none of the available a combination of all suitable choices of the commercial tools provide specific assistance for involved Settings and Interactions. test planning and generation from the UML We have applied the method to a case study, descriptions. Argo/UML [Argo]. Argo/UML is an open source In this paper we address UML-based testing. tool that provide cognitive support to system Specifically, we want to address this task design. We have developed quite a few Test Cases, according to the following two guidelines: (i) we and we have been able to identify a few bugs in aim at a test method that is entirely based on the case study. However, the method is currently UML, so that it can be easily adopted by manual, and still under evaluation. Our short term industries already using UML; and, (ii) we refer to plan is the realization of a tool that support it, by high level descriptions of the system: indeed, we smoothly expanding an existing UML design want to address test planning for the integration tool. test phase starting from the very first stages of The paper is organized in the following way. In system design. the next section, we provide some introductory material to UML and Integration testing. In 1 Section 3, we describe the method in more detail, Sequence diagram: it shows the dynamic explaining it step by step. Then, in Section 4 the collaborations between a certain number of case study Argo/UML is briefly introduced, so objects, highlighting the way in which a particular that in Section 5 some examples of application of scenario1 is realized using the interactions of a Use-Interaction to it are shown. In Section 6 we (sub)set of these objects. More precisely, a also provide a very brief sketch of a UML scenario is described by the set of messages definition of the Use Interaction method itself by exchanged between objects. A Sequence diagram means of the UML extension mechanism of expresses the same information of a Collaboration stereotypes. diagram, whereby the former describes the interactions between the objects during their life- 2. BACKGROUND cycle, while the latter shows the relative UML is a graphical modeling language to distribution of these objects links in the space. visualize, specify, design and document all the phases of a software development process. Born 2.2 Integration Testing and UML-based Testing by the unification of I. Jacobson, J. Rumbaugh The testing goal is to execute the system to verify and G. Booch methods, in 1997 it was declared by its behaviour and to reveal possible failures. OMT the standard for analysis and design of Testing is an important piece of the software Object-Oriented systems. development process, because of its cost and impact on the reliability of final product. In our 2.1 UML diagrams methodology we consider the Integration Testing A UML design consists of an integrated meta- phase, performed to find errors in unit interfaces model composed of many elements representing and to build up the whole structure of software OO common world concepts. Through this meta- system in a systematic way. model we define Views showing different aspects To do this, one could use a non-incremental of the system to be modelled (Logical View, approach (big-bang), where all the modules are Component View, Deployment View, linked together and tested all at once, or Concurrency View and Use Case View). As a preferably, incremental approaches like top-down, whole, these views provide a complete picture of where modules are integrated from the main the system to be built. UML diagrams are graphs, program downto the subordinated ones, or, each describing the content of a view; they can be bottom-up, where tests are constructed from arranged in different combinations to provide modules at the lowest hierarchical level and then several system’s views. are linked together upwards, to construct the We only provide in this section a brief description whole system. of the UML diagrams mainly used in our But, when we consider an object-oriented system, methodology (for more details see [UML97a], the described techniques are not always usable, [UML97b]): because, for example, we cannot identify the Use Case diagram: a use case is the hierarchical structure of control by which it is representation of a functionality (a specific use) possible to define top-down or bottom-up provided by the system. This diagram shows a strategies. In an object-oriented environment we number of external users (actors) and their can test the class interactions by, for example, relationships with the system, when this is used to integrating together those classes used in reply to satisfy a specific functional requirement. a particular input or system event (thread-based Class diagram: it shows the static structure of the testing) or by testing together those classes that system through the representation of its classes contribute to a particular use of the system. In the with their attributes and methods. Moreover it proposed methodology, the classes to be specifies the relations between the classes using integration tested (modules, subsystem, processes) different types of associations. A system can have are those that realize a system functionality more than one Class diagram; in subsequent identified from a Use Case diagram. phases of the software development process, the Class diagram represents objects at different levels 1 A scenario is defined as a specific sequence of actions that of abstraction. illustrates behaviour and may be used to show an interaction. [UML97b] 2 As a matter of fact, even though UML is a Use Cases, since, to obtain a complete system powerful mechanism of description, we have functionality, it is generally necessary to execute found few studies about its use to guide the testing several actions realizing lower level functionalities. phases. In our methodology, Use Case diagrams drive Some researchers have proposed methods to Integration test according to an incremental translate a UML description into another formal strategy. We start analysing low-level description, and then derive the tests from the functionalities that represent a subset of actions latter. For instance, in [JGP98] the authors present described by a sub-Use Case, and then we a tool, UMLAUT, that is used to manipulate the progressively put them together, until the whole UML representation of the system and system described in the main Use Case is automatically transforms it into an intermediate obtained. form, suitable for validation. Another interesting For each selected Use Case we analyse the paper is [OA99], where a method is proposed to corresponding Sequence diagram, composed by generate test data from UML State diagrams. objects and the messages they exchange. The They translate the UML State diagram into formal objects involved in the diagram are those that SRC specifications, from which input data for unit realize and execute the functionality described in testing are automatically generated. Finally, in a the Use Case through elaborations and message recent paper from Siemens Corporate Research exchanges and so they are precisely the [HIM00] UML diagrams are used to components to be tested. In this phase we consider automatically construct test cases as follows. The the Class diagram too, and particularly a Class developers first define the dynamic behaviour of diagram at high level of abstraction.