Reducing regression test size by exclusion.

Operational software is constantly evolving. Regression testing is used to identify the unintended consequences of evolutionary changes. As most changes affect only a small proportion of the system, the challenge is to ensure that the regression test set is both safe (all relevant tests are used) and unclusive (only relevant tests are used). Previous approaches to reducing test sets struggle to find safe and inclusive tests by looking only at the changed code. We use decomposition program slicing to safely reduce the size of regression test sets by identifying those parts of a system that could not have been affected by a change; this information will then direct the selection of regression tests by eliminating tests that are not relevant to the change. The technique properly accounts for additions and deletions of code. We extend and use Rothermel and Harrold’s framework for measuring the safety of regression test sets and introduce new safety and precision measures that do not require a priori knowledge of the exact number of modification-revealing tests. We then analytically evaluate and compare our techniques for producing reduced regression test sets

Reducing regression test size by exclusion.

Operational software is constantly evolving. Regression testing is used to identify the unintended consequences of evolutionary changes. As most changes affect only a small proportion of the system, the challenge is to ensure that the regression test set is both safe (all relevant tests are used) and unclusive (only relevant tests are used). Previous approaches to reducing test sets struggle to find safe and inclusive tests by looking only at the changed code. We use decomposition program slicing to safely reduce the size of regression test sets by identifying those parts of a system that could not have been affected by a change; this information will then direct the selection of regression tests by eliminating tests that are not relevant to the change. The technique properly accounts for additions and deletions of code. We extend and use Rothermel and Harrold’s framework for measuring the safety of regression test sets and introduce new safety and precision measures that do not require a priori knowledge of the exact number of modification-revealing tests. We then analytically evaluate and compare our techniques for producing reduced regression test sets

Stop-list slicing.

Traditional program slicing requires two parameters: a program location and a variable, or perhaps a set of variables, of interest. Stop-list slicing adds a third parameter to the slicing criterion: those variables that are not of interest. This third parameter is called the stoplist. When a variable in the stop-list is encountered, the data-flow dependence analysis of slicing is terminated for that variable. Stop-list slicing further focuses on the computation of interest, while ignoring computations known or determined to be uninteresting. This has the potential to reduce slice size when compared to traditional forms of slicing. In order to assess the size of the reduction obtained via stop-list slicing, the paper reports the results of three empirical evaluations: a large scale empirical study into the maximum slice size reduction that can be achieved when all program variables are on the stop-list; a study on a real program, to determine the reductions that could be obtained in a typical application; and qualitative case-based studies to illustrate stop-list slicing in the small. The large-scale study concerned a suite of 42 programs of approximately 800KLoc in total. Over 600K slices were computed. Using the maximal stoplist reduced the size of the computed slices by about one third on average. The typical program showed a slice size reduction of about one-quarter. The casebased studies indicate that the comprehension effects are worth further consideration

Distribution of human waste samples in relation to sizing waste processing in space

Human waste processing for closed ecological life support systems (CELSS) in space requires that there be an accurate knowledge of the quantity of wastes produced. Because initial CELSS will be handling relatively few individuals, it is important to know the variation that exists in the production of wastes rather than relying upon mean values that could result in undersizing equipment for a specific crew. On the other hand, because of the costs of orbiting equipment, it is important to design the equipment with a minimum of excess capacity because of the weight that extra capacity represents. A considerable quantity of information that had been independently gathered on waste production was examined in order to obtain estimates of equipment sizing requirements for handling waste loads from crews of 2 to 20 individuals. The recommended design for a crew of 8 should hold 34.5 liters per day (4315 ml/person/day) for urine and stool water and a little more than 1.25 kg per day (154 g/person/day) of human waste solids and sanitary supplies

Automatic data processing for photographic photometry in spectrographic analysis

Automatic data processing for photographic photometry in spectrographic analysi