Predictive metric for likely feasibility of program paths

Infeasible paths in the context of data flow based testing criteria: Identification, classification and prediction

“…Malevris et al used paths generated to cover LCSAJ testing [24]. Our study used potential-du-paths, required by the all-potential-du-paths criterion.…”

“…Studies on infeasible paths, described in the literature, address three basic approaches: prediction, classification and identification of infeasibility. Malevris et al [24] use the number of predicates in a path to predict infeasibility, considering the all-LCSAJs (Linear Code Sequence and Jumps) criterion. They concluded that the greater the number of predicates in a path, the greater the probability of the path being infeasible.…”

An objective comparison of the cost effectiveness of three testing methods

“…In an attempt to derive such a heuristic, Yates and Hennell [27] advanced, and argued the proposition that: a program path that involves q P 0 predicates is more likely to be feasible than one involving p > q. Formal statistical investigation of this proposition was undertaken in Malevris et al [15], wherein it was concluded, with great statistical significance, that the feasibility of a path decays exponentially with the increasing number of predicates it involves. As a result, Yates and Malevris [29] proposed a path selection method, extending that of Yates and Hennell, to reduce, a priori, the incidence of infeasible paths amongst those that are generated for the purpose of branch testing.…”

“…Correspondingly, it is pertinent to enquire whether infeasible paths are more likely to be engendered in code written in one programming language than in another. In the substantially sized study performed by Malevris et al [15] of the feasibility/infeasibility of program paths, statistical analysis of the results showed that with a certainty of 99.95%, the potential infeasibility of a program path is characterised by the number of predicates that it involves. Given such a definitive result, one of two possibilities must obtain.…”

The collateral coverage of data flow criteria when branch testing

“…In practice, this is rarely the case, because certain of the program paths are found to be infeasible; an infeasible path being one that cannot be exercised by any data set as a result of conflicting predicates. Infeasible paths have been investigated by a number of authors, see [2,4] and [31], for example, and attempts to quantify and minimise their influence have been made [21,34,35]. Unfortunately, however, there exists no possible means for avoiding them altogether, see [12].…”