Sponsored Ad

Monday, October 26, 2009

Design an experiment to test the software

When DOE is used to test the software, there are a lot of savings in testing time and cost. Several users of telecommunications and automobile defense industries report significant improvements in the productivity of traditional testing methods. This success is due to two main factors important:
1. Focused on software use, and
2. A good way to cover the domain mathematical entire operating with a minimal
set of test cases.
The job of a software tester is to try to break the system as much as possible so that all faults will be detected and therefore increase the likelihood of delivering software to the customer free of defects.

Consider the example of functionality testing machine to copy the test parameters and levels. Here, a parameter could be the number of original and paper levels are 1, 10 papers or 51 papers. Parameter B can be duplex with the levels being unilateral or two-sided copies, etc. as shown in Table 1. The software has to work well for all possible values of these parameters.

A thorough analysis of the requirements document and understand the use of software is needed to prepare the table level parameter and test plans. Knowledge of how to write the software is not usually necessary to prepare this table.
Orthogonal Array-Based Check Cases-
Table 2 shows the check plan using OA (Orthogonal Array) L9. It's nine rows and two columns. The rows correspond to check cases; the columns correspond to the check parameters. Thus, the first check case comprises Level 1 for each parameter, i.e., it represents the combination A1, B1, C1, D1. The second check case comprises combination A1, B2, C2, D2, etc.
An orthogonal matrix has the balancing property that for each pair of columns, all parameters of level combinations occur an equal number of times. In OA of L9, there are nine combinations of level settings of each pair of columns, and each combination occurs once. By performing nine tests indicated on L9, we can accomplish the following:

1-Detect and isolate all the errors in a single mode. A single fault is a problem in a manner consistent with any level of any single parameter. For example, if all cases of factor Provided A1 level error cause is a single failure mode. In this example, Tests 1, 2 and 3 shows the errors. By analyzing information about the tests show that the error can be identified that the level of factor causes of failure. In this example, noting those tests 1, 2 and 3 causes an error, you can isolate A1 as the source of the fault. This fault isolation, it is important to repair the fault.

2-Detect all double-mode faults. If there is a consistent problem in that specific levels of the two parameters are presented together, is called a dual-mode error. In fact, a double fault mode is an indication of the incompatibility of pairs or undesirable interactions between the two test parameters.

3-Failures multimode. OAS force 2 can ensure detection of only single and double mode faults. However, many multi-faults are also detected by these tests. This can be understood by studying the interaction tables and geometrical view of the test cases presented in the next section.
See geometric test cases-
Software faults can be divided into two categories: failures and faults isolated region, as shown in Figure 1. Faults that occur only a specific combination of levels of test parameters, such as a data entry error, mistakes are called isolated. Warranty against defects cannot be isolated without trying all combinations. However, when the logic is faulty, there is a tendency to a test domain region to show a malfunction. Errors are called bugs region. The way one-and two-mode errors are special cases of failure region. Orthogonal Array computerized evaluation is highly effective for detecting defects in the region with a relatively small number of trials.

A geometric image of the test cases can provide insight into the benefits of OA based on test cases to detect defects in the region. To facilitate geometric visualization, take the example of software with only three test parameters A, B and C. The test domain is cube-shaped and consists of 27 points in the network. Test cases based on the L9 OA-based and factor-in-time method is shown graphically in Figure 2 The OA-based test cases are dispersed uniformly throughout the test domain.

A Case Study-
A comprehensive case study of evidence-based orthogonal array was released by AT & T in 1992 [3]. The detailed study of regression testing of a computer (IBM format) and LAN-based email software called Star Mail. Originally, a test plan was prepared, consisting of 1,500 tests that had 18 weeks to complete. However, due to delays in development, test time had to be suspended at just eight weeks. The lead test engineer had, therefore, prepared alternative plan participation than 1,000 tests that having two people in eight weeks. But he was sure the quality of the evidence, i.e., its ability to detect all defects. To alleviate these problems, a test plan was carried out using orthogonal array-based robust testing method.

The Robust Testing method began with the division of the functions of the Star Mail program in to 18 categories, check parameters & levels for each section were found, & an OA to select check cases for each section was used. For example, for the copy/move function, the chosen OA L27 was used to ensure all pair wise combinations of these parameters. Different parameter tables were prepared for remaining 17 categories.

In total, only 422 tests were necessary to test the software. These tests identified 41 faults in the software, fixing, and the software was released. Two years of operation in the field did not cause failures in the field of tests, which indicated that with respect to the scenarios found, the test plan was 100 percent effective in identifying faults. AT & T had run the test plan alternatives involving over 1,000 tests, the estimated lead tester may have found only 32 of the 41 defects. Compared with the original test plan, testing required robust 50 percent less strain on the evidence, identify the shortcomings of 28 percent, and is more productive (number of faults detected by tester week) by a factor of 2.6.

Regression Testing-
Orthogonal array based testing is useful in regression testing. After fixing the failures, it is easy to prepare a new test plan using the technique of rotation of the array.

Conclusion-
The use of orthogonal array based testing has shown to produce superior test plans that improve testing productivity by a factor of 2. This method is effective in increasing the evidence found work in all phases of software development. These steps include the requirements of writing, the selection of architecture, system design (functional breakdown), unit testing, platform testing, and integration testing, testing of prototypes and testing the system.

0 comments:

Post a Comment

Sponsored Ad

Development Updates

Tech Updates