Data Flow Testing Criteria Research Articles

Test Case Selection for All-Uses Criterion-Based Regression Testing of Composite Service

Composite services evolve for various reasons. Test case selection in the regression testing is an effective technique to ensure the correctness of modified versions meanwhile to reduce the cost of testing. However, few work has studied the test case selection problem based on the data flow testing criteria. In addition, there are three observable kinds of changes during the evolution, including Process change, Binding change and Interface change, which all bring impact to the data flow. To address these issues, a test case selection approach is proposed for regression testing of BPEL (Business Process Execution Language) composite service where all-uses criterion is satisfied and all the three change types are involved. BPEL composite service is modeled with a two-level model in which XCFG (eXtended Control Flow Graph) describes the behavior of BPEL process in the first level and WSDM (Web Service Description Model) depicts the interface information of composite service and partner services in the second level. Change impact analysis is performed to identify the affected definition-use pairs by comparing and analyzing two-level models of the baseline and evolved versions. And testing paths are generated to cover the affected definition-use pairs and select test cases based on the path condition analysis. Empirical result shows that the proposed approach is effective.

A Language for the Description of Program Instrumentation and Automatic Generation of Instrumenters


 
 
 Instrumentation is a technique frequently used in software engineering for several different purposes, e.g. program and/or specification execution trace, testing criteria coverage analy- sis, and reverse engineering. Instrumenting a software product can be divided into two main tasks: (i) deriving the software product structure and (ii) inserting statements for collecting runtime/simulation information.
 Most instrumentation approaches are specific to a given domain or language. Thus, it is very difficult to reuse the effort expended in developing an instrumenter, even if the target languages are quite similar. To tackle this problem, in this paper, we propose an instrumentation-oriented meta-language, named IDeL, designed to support the description of both main tasks of instru- mentation process, namely: (i) the product structure derivation and (ii) the insertion of the instrumentation statements. In order to apply IDeL to a specific language L, it should be in- stantiated with a context-free grammar of L. To promote IDeL’s practical use, we also developed a supporting tool, named idelgen, that can be thought of as an application generator, based on the transformational programming paradigm and tailored to the instrumentation process. We illustrate the main concepts of our proposal with examples describing the instrumentation required in some traditional data flow testing criteria for C language.
 
 

Improving the Effectiveness of Testing Pervasive Software via Context Diversity

Context-aware pervasive software is responsive to various contexts and their changes. A faulty implementation of the context-aware features may lead to unpredictable behavior with adverse effects. In software testing, one of the most important research issues is to determine the sufficiency of a test suite to verify the software under test. Existing adequacy criteria for testing traditional software, however, have not explored the dimension of serial test inputs and have not considered context changes when constructing test suites. In this article, we define the concept of context diversity to capture the extent of context changes in serial inputs and propose three strategies to study how context diversity may improve the effectiveness of the data-flow testing criteria. Our case study shows that the strategy that uses test cases with higher context diversity can significantly improve the effectiveness of existing data-flow testing criteria for context-aware pervasive software. In addition, test suites with higher context diversity are found to execute significantly longer paths, which may provide a clue that reveals why context diversity can contribute to the improvement of effectiveness of test suites.

Software testing and quality assurance: theory and practice

Software testing and quality assurance: theory and practice

The collateral coverage of data flow criteria when branch testing

When exercising program code with test data in an attempt to satisfy a given testing criterion, there will be a concurrent accrual of coverage in respect of other testing criteria. Knowledge of the extent of such ‘collateral coverage’ can be used to advantage both in providing better estimates of the overheads entailed by the overall testing exercise, and in helping to determine an optimal sequence for the application of a set of testing methods. In this paper, the results deriving from a set of experiments are reported. The aim of the experiments was to investigate the extent of the collateral coverage that is achieved in respect of the data-flow testing criteria when branch testing is undertaken.

More experience with data flow testing

Experience is provided about the cost and effectiveness of the Rapps-Weyuker data flow testing criteria. This experience is based on studies using a suite of well-known numerical programs, and supplements an earlier study (Weyuker 1990) using different types of programs. The conclusions drawn in the earlier study involving cost are confirmed in this study. New observations about tester variability and cost assessment, as well as fault detection, are also provided. >

An empirical evaluation (and specification) of the all-du-paths testing criterion

The all-du-paths structural testing criterion is one of the most discriminating of the data-flow testing criteria. Unfortunately, in the worst case, the criterion requires an intractable number of test cases. In a case study of an industrial software system, we find that the worst-case scenario is rare. Eighty percent of the subroutines require ten or fewer test cases. Only one subroutine out of 143 requires an intractable number of tests. However, the number of required test cases becomes tractable when using the all-uses criterion. This paper includes a formal specification of both the all-du-paths criterion and the software tools used to estimate a minimal number of test cases necessary to meet the criterion.

Estimating the number of test cases required to satisfy the all-du-paths testing criterion

The all-du-paths software testing criterion is the most discriminating of the data flow testing criteria of Rapps and Weyuker. Unfortunately, in the worst case, the criterion requires an exponential number of test cases. To investigate the practicality of the criterion, we develop tools to count the number of complete program paths necessary to satisfy the criterion. This count is an estimate of the number of test cases required. In a case study of an industrial software system, we find that in eighty percent of the subroutines the all-du-paths criterion is satisfied by testing ten or fewer complete paths. Only one subroutine out of 143 requires an exponential number of test cases.

An applicable family of data flow testing criteria

The authors extend the definitions of the previously introduced family of data flow testing criteria to apply to programs written in a large subset of Pascal. They then define a family of adequacy criteria called feasible data flow testing criteria, which are derived from the data-flow testing criteria. The feasible data flow testing criteria circumvent the problem of nonapplicability of the data flow testing criteria by requiring the test data to exercise only those definition-use associations which are executable. It is shown that there are significant differences between the relationships among the data flow testing criteria and the relationships among the feasible data flow testing criteria. The authors discuss a generalized notion of the executability of a path through a program unit. A script of a testing session using their data flow testing tool, ASSET, is included. >