ComGeneration

The ComGeneration approach described in (Wacht et al., 2011a) and (Wacht et al., 2011b) defines a methodology that can be specifically applied to functional testing of value-added services. It considers both service implementation and functional testing of the service (see Figure 3.12). Permission to reproduce Figure 3.12 has been granted by the copyright owners of the referenced publication.

Figure 3.12: ComGeneration methodology (Wacht et al., 2011b)

Initially, a so-called service description is specified. This is a natural language-based document that can be understood as the requirements specification and is created by the service provider in consultation with a service customer.

After the service description document has been completed, both service developer and test developer can start with the development. The service developer can use a Service Creation Environment (SCE) to develop and subsequently deploy the service on a SIP Application Server within a Service Delivery Platform (SDP).

Modular Sub Finite State Machines Service Description Modelling Behaviour Model Test Case Generator Service Creation Environment Test Execution Environment ttcn3 --- --- Test Cases Service _SIP Application Server

Just like the service developer, the test developer has to extract the relevant service information for the test purpose from the service description. First, he chooses the service- related characteristics out of a repository of so-called predefined modular extended finite state machines (EFSM). The EFSMs cover basic service characteristics like protocol sequences for SIP (IETF RFC 3261, 2002) or HTTP (Hypertext Transfer Protocol) (IETF RFC 2616, 1999). By composing the chosen predefined modular EFSMs, the test developer creates a behaviour model describing the behaviour of a value-added service. Once the behaviour model is created, it is passed to the Test Case Generator which contains an algorithm to automatically generate the service-specific abstract test cases by identifying every possible path through the EFSM. Afterwards, the abstract test cases are converted into TTCN-3 test cases by using a special mapping concept (Wacht et al., 2011a). Finally, the TTCN-3 test cases are combined to a test suite that can be executed within a TTCN-3 test execution environment. In the approach, the TTworkbench (TTworkbench, 2015) was used.

In the following, an example demonstrates how the behaviour model is established. The service to be tested is a standard Click-to-Instant-Message (Click2IM) service. The input is a SIP URI and a text message. Both have to be set on a web site. By actuating a “Send” button, a SIP message will be send to the entity that is reachable through the SIP URI. The message, of course, contains the specified text message from the web site. In the first step to establish the behaviour model, the test developer has to configure the test architecture through the so-called Connectivity Editor (see Figure 3.13). Permission to reproduce Figure 3.13 has been granted by the copyright owners of the publication.

3.3 Related Work on Current Research Projects on Functional Testing

Figure 3.13: Connectivity Editor for Click2IM service (Wacht et al., 2011b)

The Connectivity Editor contains the protocols that have to be used (SIP, HTTP), specifies certain timers that have to be integrated and includes all required messages (SIP requests and responses as well as HTTP requests and responses). The example also considers certain mistakes a service customer could do while using the service, such as forgetting to include the SIP URI in the text field. In the approach, such considerations require to specify long lists of defined possible messages. In the next step, the messages have to be further specified. In the approach, complex data types have been defined that represent example protocol messages. By using a so-called Test Data Editor, the test developer can determine the test data for each defined message. The following Figure 3.14 shows how a SIP request message can be specified through a tree-like view. Permission to reproduce Figure 3.14 has been granted by the copyright owners of the referenced publication.

Figure 3.14: Tree-like Test Data Editor (Wacht et al., 2011b)

The final step of the modelling process is the design of the behaviour model itself. Here, an EFSM is applied and the main information is included on the transitions (see Figure 3.15). Permission to reproduce Figure 3.15 has been granted by the copyright owners of the referenced publication.

3.3 Related Work on Current Research Projects on Functional Testing

The illustrated Behaviour Model in the ComGeneration approach contains five states, each representing a predefined EFSM, either SIP-based or HTTP-based. The transitions between the states either describe events that might occur or specify actions that take place as soon as the events happened. Finally, based on the complete EFSM-based Behaviour Model, a test generation transition coverage algorithm has been implemented to derive test cases and execute them against the value-added service running on a SIP AS.

To the author’s knowledge, the described methodology of the ComGeneration project is the only test approach that has been specifically applied to the field of NGN or rather SIP- over-IP-based environments. It can be understood as the foundation of this research. A few aspects of the ComGeneration project have been adopted in this research, however, mainly aspects the author has established during the project work. In this connection, publications have been done, such as (Wacht et al., 2010), (Wacht et al., 2011a), (Wacht

et al., 2011b) and (Wacht et al., 2011c).

Regarding the ComGeneration approach, the separation of the development process and the test process enables a thorough verification based on the service description. Unfortunately, the role of the service customer in this approach is only relevant at the project start. This leads to the question, if the ComGeneration approach also validates the value-added services. Furthermore, the approach lacks an efficient test case derivation algorithm from the behaviour model to avoid the well-known combinatorial explosion issue in EFSMs. Also in the ComGeneration approach, the agile concepts have not been considered.