2-10

Pervasive Communications Handbook

c ontext sequences. The supporting infrastructure for their approach consists of the
following components:
Context-Aware Program Point Identifier: This component identifies program
points where context changes may affect the applications behavior.
Context Driver Generator: Once context-aware program points have been identified, one would like to explore the context scenarios that are likely to generate
different program behaviors. This component forms potential context interleaving that may be of value to fulfill a context-coverage criterion.
Program Instrumentor: This component incorporates a scheduler and contextaware program point identifier controllers into the application to enable direct
context manipulation.
Context Manipulator: This component attempts to expose the application to the
enumerated context interleavings through the manipulation of the scheduler.
Lu etal. [18] proposed a set of three-test criteria using data flow testing. The control
flow graph of the source code is first built and then the life-cycle of data variables (their
definitions and the usages) is tracked. The approach leads to test cases that focus on
improper use of data due to coding errors. Their approach uses these criteria to create
test cases that detect faults in the context-aware interface that are otherwise difficult to
be discovered through conventional testing methods.
Taranu and Tiemann [19] proposed a testing approach by applying and extending the
classical approach of testing communication systems. In their approach, they isolated
the core of a context-aware system, which is the control or algorithmic part for adapting
the system to the current scenario and requested service. Their approach uses a context
management system that takes internal and external information into account for local
decisions. The isolated part (i.e., the decision algorithm or control part) is directly stimulated with context information via the context management. The appropriate context is
directly generated, and the context represents the environment or situation of the System
under Test (SUT). Their work is a unique effort where both foreground and background
testers are explicitly considered. The testers represent one or more instances in the communication and contain an implementation of protocol. A foreground tester interacts
with the SUT, that is, the generated traffic is also influenced by the SUT. A background
tester is an implementation without feedback from the tested system, and it is used to
generate the background load efficiently. The context or situation is generated by context
generators, categorized as foreground and background generators. The situation generator is implemented in Java programming language and it generates different situations
in radio network. The situations refer not only to traffic and load generation, but also to
contain information generated out of location, interference, or mobility models.
Another issue relevant to testing context-aware application is the context inconsistency, which is becoming increasingly important in the presence of more and smarter
sensors. Some researchers have recently proposed inconsistency detection in the applications where patterns identify conflicts among context inputs at run-time before the
contexts are fed into an application [2022]. The patterns are designed beforehand based
on the understanding of relevant physical and mathematical laws under which the application is supposed to run. In Lu et al. [23], a framework is proposed where the middleware