UML 2.0 Testing Profile

The UML 2.0 Testing Profile (U2TP) defines a modelling language for designing, visualising, specifying, constructing and documenting artefacts of test systems and is an Object Management Group (OMG) standard (OMG, 2013a). According to (Zander et al., 2005), U2TP can be applied to test systems in various applications and can be either used

3.3 Related Work on Current Research Projects on Functional Testing

stand alone for the handling of test artefacts or in an integrated manner with UML 2.0 (OMG, 2011a) for handling of both system and test artefacts. In principal, U2TP enhances UML 2.0 with test-specific concepts such as test architecture, test behaviour, test data and time concepts (see Table 3.1). Permission to reproduce Table 3.1 has been granted by Springer Publishing.

Table 3.1: Overview of the UML 2.0 Testing Profile concepts (Zander et al., 2005)

Architecture concepts Behaviour concepts Data concepts Time concepts

SUT Test objective Wildcards Timer

Test components Test case Data pools Time zone

Test context Defaults Data partitions Test configuration Verdicts Data selectors

Arbiter Test Control Coding rules

Scheduler

The test architecture group covers the concepts related to test structure and test configuration such as specifying test components, their interfaces, possible connections among test components and between test components and SUT. The test behaviour group embodies dynamic aspects of test procedures and addressing observations and activities during the test. Test behaviours can be defined by any behavioural diagram of UML 2.0, e.g. interaction diagrams or state machines. The test data group includes concepts for specifying test data used in test procedures, such as the structures and meaning of values to be processed in a test. Finally, the time group covers concepts for a time quantified definition of test procedures, e.g. the time constraints and time observation for test execution (Zander et al., 2005) (OMG, 2013a).

Based on the U2TP concepts, a given design model specified in UML notation can be extended with test-specific information. According to (Dai et al., 2004), a tester first has

to define a new UML package as the test package of the system. Then, he imports the implementation code, all classes and interfaces, and starts with the specification of the test architecture and test behaviour. Oftentimes, the test data and time aspects are already comprised in either the test architecture or test behaviour. In order to define a complete test model, the following steps within the test architecture have to be performed:

1. Assigning the system components to be tested (SUT).

2. Depending on their functionality, the test components have to be defined. The test components should be grouped to the system components of the design model. 3. Specifying a test suite class that lists the test attributes and test cases as well as

test control and test configuration.

Besides the test architecture definitions, the test behaviour includes the designing of the test cases. Here, the given interaction diagrams of the design model can be reused, but the instances have to be assigned with stereotypes of U2TP according to their functionalities. At each test case specification, verdicts (such as pass, fail or inconclusive) have to be assigned.

As soon as the test model is final, the test cases still have to be generated and executed against the SUT. Actually, U2TP provides two mappings towards test execution environments or rather technologies, either JUnit (JUnit, 2015) or TTCN-3 (ETSI ES 201 873-1, 2015). Both technologies allow the execution of tests and deliver an evaluation report.

In the following, an example test case specification using U2TP is demonstrated. The specific test case concerns the use of a bank Automated Teller Machine (ATM), especially the verification of an entered pin number. It shall be tested how the ATM reacts

3.3 Related Work on Current Research Projects on Functional Testing

if a wrong pin number is entered after a bank card is inserted. In order to test this, a “hardware emulator” (HW Emulator) is defined as test component as well as an external component “current” which determines whether the pin number is correct for the given bank card or not. The test case specification is illustrated as a UML sequence diagram in the following Figure 3.8. Permission to reproduce Figure 3.8 has been granted by OMG.

Figure 3.8: Example test case specification with U2TP using a UML sequence diagram (adapted from (OMG, 2013a))

A significant information within the sequence diagram is defined as soon as the HW Emulator is terminated, the so-called validation action. If the two messages “Invalid PIN” and “Enter PIN again” are displayed on the HW Emulator after the pin number has been checked, the test case passes.

The proponents of U2TP claim that the approach is standardised by the OMG and is based on standard UML notations. Actually, U2TP has a lot of features, such as the support for

sd InvalidPIN

{readOnly} Integer invalidPIN; {current.isPinCorrect(invalidPin) == false}

HW

Emulator Bank ATM<<SUT>> Current

storeCardData(current) display("Enter PIN") t1 (2.0) t1 isPinCorrect(invalidPIN) isPINCorrect(invalidPIN) isPinCorrect: false isPinCorrect: false {0 .. 3} display("Invalid PIN") display("Enter PIN again")

<<validationAction>>

domain-independent test modelling, test case specification and test data specification. The close connection with UML enables also the combination with other standardised profiles like the Systems Modeling Language (SysML) (OMG, 2012a) or the Service oriented architecture Modeling Language (SoaML) (OMG, 2012b).

The negative aspects of U2TP correlate with the negative aspects of Model-Based Testing (MBT). A lot of training is required for the testers to build adequate U2TP test models with complete test architecture and test behaviour configurations. As the domain model and the test model are closely coupled, possible changes triggered by the customer of a system or service lead to changes in the domain model and in the test model. Another restriction of U2TP is that many important aspects relevant for testing are not covered, such as a proper test management, audits and reviews or a thorough test methodology. Finally, agile concepts cannot be applied easily, as the system model always has to exist before the test model can be defined.