Recently, a class of experimental designs has been devised that guarantee input domain coverage up to all combinations of k test factors taken t at a time. With such designs, all pair-wise combinations (or triplets or quadruplets, etc.) are selected at least once. To evaluate their applicability to software testing, we analyzed the extent to which software coverage (i.e., code execution) achieved by these designs for r = 1 ,...,k is representative of that achieved by exhaustively testing all factor combinations. The block coverage obtained for tS2 was comparable with that achieved by exhaustively testing all factor combinations but higher-order values of t were required for path coverage. Implications of these results for software testing are discussed. field, and that there is a total of 151 characters that can be entered across all 20 screen fields, then there are 95'5'~4.3x102g8 different inputs or test cases corresponding to the different ways a user can populate the screen. Clearly, exhaustive input testing is not feasible and hence, a software tester needs to efficiently generate an effective set of test cases as a means of verifying the correct operation of the software.

No abstract

Software reliability modeling of data collected during the testing of a large-scale industrial system was used to measure software quality from the customer perspective. Specifically, software quality was measured in terms of the system software failure rate expressed as number of failures per hour of system operation. The testing phase analyzed, Stability Test, was an operational profile-driven test in that a controlled load was imposed on the system reflective of the system's busy-hour usage pattern. The usage profile was determined from requirements specifjmg both the frequency of invocation of each command and the alarm arrival rate for the largest expected user site. For this controlled test environment, a Poissontype reliability growth model, the Exponential Non-Homogeneous Poisson Process model (or ENHPP) exhibited a good fit to the observed failure data Furthermore, the model demonstrated predictive power for future failure rates. Differences between model results and observed failure data following release to the Beta site were attributed to differences in these two environments' operational profiles. We conclude that the use of an operational profile to drive System Test is an effective test strategy and that the operational profile must be taken into account when predicting field reliability from reliability measured during test.

No abstract

No abstract