Integration Testing of Context-Sensitive Middleware-Based Applications: A Metamorphic Approach

Abstract

During the testing of context-sensitive middleware-based software, the middleware checks the current situation to invoke the appropriate functions of the applications. Since the middleware remains active and the situation may continue to evolve, however, the conclusion of some test cases may not easily be identified. Moreover, failures appearing in one situation may be superseded by subsequent correct outcomes and, therefore, be hidden. We alleviate the above problems by making use of a special kind of situation, which we call checkpoints, such that the middleware will not activate the functions under test. We recommend testers to generate test cases that start at a checkpoint and end at another. Testers may identify relations that associate different execution sequences of a test case. They then check the results of each test case to detect any contravention of such relations. We illustrate our technique with an example that shows how hidden failures can be detected. We also report the experimentation carried out on an RFID-based location-sensing application on top of a context-sensitive middleware.

Experimental Study to Compare the Use of Metamorphic Testing and Assertion Checking

“…As we shall review in Section 2, metamorphic testing (MT) [4][9] [10][11] [12] and assertion checking [13] [14] are techniques to alleviate the oracle problem. Assertion checking verifies the test result or intermediate states of the program when executing a test case.…”

“…Gotlieb and Botella [16] developed an automated framework to check against a class of metamorphic relations. Chan and colleagues applied metamorphic approach to the unit testing [17] and integration testing [9] of context-sensitive middleware-based applications. Chan and others [11][18] also developed a metamorphic approach to online testing of service-oriented software applications.…”

Static Slicing for Pervasive Programs

“…The tuple V is configured as (v [1], v [2], v [3], v [4]), in which v [1], v [2], and v [3] represent either ⊥ or a node in G s 1 , G s 2 , and G s 3 , respectively, and v [4] represents either ⊥ or n ev . Initially, the worklist is set to be (n 17 , (⊥, ⊥, n 17 , ⊥)) .…”

Towards a Metamorphic Testing Methodology for Service-Oriented Software Applications

“…In general, x 1 is termed as the original test case, and y 1 is termed as the follow-up test case. We refer readers to [3][4][5][6]14] for more details about metamorphic testing.…”

“…2 We note that we choose to show the internal interactions with other services as parameters in the relation to ease our discussion. 3 In practice, we need to take rounding into account. …”