The paper discusses the application of state diagrams in UML to class testing. A set of coverage criteria is proposed based on control and data ow in UML state diagrams and it is shown how to generate test cases satisfying these criteria from UML state diagrams. First, control ow is identi ed by transforming UML state diagrams into extended nite state machines (EFSMs). The hierarchical and concurrent structure of states is attened and the broadcast communication is eliminated in the resulting EFSMs. Second, data ow is identi ed by transforming EFSMs into ow graphs to which conventional data ow analysis techniques can be applied.

This paper presents a method for the selection of test sequences from statecharts. It is shown that a statechart can be transformed into a flow graph modelling the flow of both control and data in the statechart. The transformation enables the application of conventional control and data flow analysis techniques to test sequence selection from statecharts. The resulting set of test sequences provides the capability of determining whether an implementation establishes the desired flow of control and data expressed in statecharts. Copyright © 2000 John Wiley & Sons, Ltd.

No abstract

Abstract-Context-awareness of mobile applications yields several issues for testing, since the mobile applications should be testable in any environment and with any contextual input. In previous studies of testing for Android applications as eventdriven systems, many researchers have focused on using the generated test cases considering only GUI events. However, it is difficult to detect failures in the changes in the context in which applications run. It is important to consider various contexts since the mobile applications adapt and use novel features and sensors of mobile devices. In this paper, we provide the method of systematically generating various executing contexts from permissions. By referring the lists of permissions, the resources that the applications use for running Android applications can be inferred easily. The various contexts of an application can be generated by permuting resource conditions, and the permutations of the contexts are prioritized. We have evaluated the usefulness and effectiveness of our method by showing that our method contributes to detect faults.

Although numerous empirical studies have been conducted to measure the fault detection capability of software analysis methods, few studies have been conducted using programs of similar size and characteristics. Therefore, it is difficult to derive meaningful conclusions on the relative detection ability and cost‐effectiveness of various fault detection methods. In order to compare fault detection capability objectively, experiments must be conducted using the same set of programs to evaluate all methods and must involve participants who possess comparable levels of technical expertise. One such experiment was ‘Conflict1’, which compared voting, a testing method, self‐checks, code reading by stepwise refinement and data‐flow analysis methods on eight versions of a battle simulation program. Since an inspection method was not included in the comparison, the authors conducted a follow‐up experiment ‘Conflict2’, in which five of the eight versions from Conflict1 were subjected to Fagan inspection. Conflict2 examined not only the number and types of faults detected by each method, but also the cost‐effectiveness of each method, by comparing the average amount of effort expended in detecting faults. The primary findings of the Conflict2 experiment are the following. First, voting detected the largest number of faults, followed by the testing method, Fagan inspection, self‐checks, code reading and data‐flow analysis. Second, the voting, testing and inspection methods were largely complementary to each other in the types of faults detected. Third, inspection was far more cost‐effective than the testing method studied. Copyright © 2002 John Wiley & Sons, Ltd.