Inter-context control-flow and data-flow test adequacy criteria for nesC applications

Abstract

NesC is a programming language for applications that run on top of networked sensor nodes. Such an application mainly uses an interrupt to trigger a sequence of operations, known as contexts, to perform its actions. However, a high degree of inter-context interleaving in an application can cause it to be error-prone. For instance, a context may mistakenly alter another context's data kept at a shared variable. Existing concurrency testing techniques target testing programs written in general-purpose programming languages, where a small scale of inter-context interleaving between program executions may make these techniques inapplicable. We observe that nesC blocks new context interleaving when handling interrupts, and this feature significantly restricts the scale of inter-context interleaving that may occur in a nesC application. This paper models how operations on different contexts may interleave as inter-context flow graphs. Based on these graphs, it proposes two test adequacy criteria, one on inter-context data-flows and another on intercontext control-flows. It evaluates the proposal by a real-life open-source nesC application. The empirical results show that the new criteria detect significantly more failures than their conventional counterparts.

Weaving Context Sensitivity into Test Suite Construction

“…The removal of value from the context stream may reveal the failure. For instance, from Table II, we observe that execution of the expected version of Convey Belt over t 4 ' produces 2 as the result. It is because the application has triggered the context dropping service, which removes the last position value (which is 1) produced by its main component.…”

“…Suppose further that all factors related to the internal property of the program under test are equal, we may randomly pick one of such context stream fragments. This is the approach taken by some existing techniques [4][5] [6] [12].…”

“…Without further information, the best we can assume is that any projection is feasible and these projections distribute uniformly. We thus measure the overall change in contextual values for a given sequence as context diversity: Take t 4 ' for example: The Hamming distance between the first pair of two context instances is 4 because the value of r0 should be edited from 20 to 10 (i.e., one change), and the values for r1, r2, and r3 alike. In the same manner, the Hamming distance of the next pair of context instances is only 3 because the value for r2 does not change.…”

“…Apart from testing techniques [4][5] [6][12] discussed in Section I, there are verification efforts to assure the correctness of context-aware applications. Roman et al [9] propose Mobile UNITY as a model to represent mobile applications and verify applications against the specified properties.…”

“…Many state-of-the-art testing techniques have been proposed to exercise various context-dependent data-flow [5][6] and control-flow [4][5] entities, manipulate the thread interleaving choices at the context-related function call level [12] or at the scheduler level [4], or check the context relationships among executions as alternate test oracles [10].…”