Equivalence Class Partitioning , Part II

	Gieno   Equivalence Class Partitioning , Part II
	Jorgensen [2] takes a different approach and defines a formula for calculating a specific number of tests for “weak” equivalence class testing and for “strong” equivalence class testing. The “weak” equivalence class testing approach requires that one element from each equivalence class subset is exercised independently in a test. The total number of equivalence class test cases is equal to the largest number of equivalence class subsets in any union of subsets plus the total number of invalid equivalence class subsets. Using the example function above and applying the formula for “weak” equivalence class testing the total number of tests is 17. The “weak” valid equivalence class tests include: Test Case Argv1 Argv2 1 EQA1 EQB1 2 EQA2 EQB2 3 EQA3 EQB1 4 EQA4 EQB2   While this approach exercises each valid equivalence class independently which would provide more thorough coverage, in this example since EQA4 must be a characteristic of EQA1, EQA2, and EQA3, the number of tests could reasonably be reduced to 3 by creating a union between EQA1, EQA2, and EQA3, and EQA4.   The number of invalid equivalence class tests is equal to the total number of invalid classes. A formula to calculate the minimum number of tests for “weak” equivalence class testing is: Total EQTests = MaxNum EQValid + Total EQInvalid So, in the example above the total number of tests is: MaxNum EQValid + Total EQInvalid = 4 + 6 = 10 tests for weak equivalence class testing   Jorgensen also describes “strong” equivalence class testing in which each test includes every possible combination of subsets of values. The “strong” equivalence class method produces a set of test cases equal to the Cartesian product of each partition’s equivalence class subsets. Thus, in the example above the total number of test cases for “strong” equivalence class testing is Valid EQ Argv1 * Valid EQ Argv2 = (EQA1È EQA2È EQA3, È EQA4) * (EQB1 È EQB2) = 4 * 2 = 8. The complete set of “strong” valid equivalence class test cases is listed in the table below. Test Case Argv1 Argv2 1 EQA1 EQB1 2 EQA1 EQB2 3 EQA2 EQB1 4 EQA2 EQB2 5 EQA3 EQB1 6 EQA3 EQB2 7 EQA4 EQB1 8 EQA4 EQB2   Again, this does not include the invalid equivalence class tests which are equal to the total number of invalid classes. A formula to calculate the minimum number of tests for “strong” equivalence class testing is:   Total EQTests = ((Param1 EQValid) * (Param2 EQValid) etc.)+ Total EQInvalid Jorgensen states “strong” equivalence class testing in which all combinations in which at least one combination of each possible input has been tested guarantees a sense of completeness. Although “strong” equivalence class testing tests every possible combination, it may be considered over-testing. Numerous case studies at Microsoft and within the industry clearly demonstrate testing all possible combinations is unlikely to reveal any errors or changes in functionality beyond a carefully constructed array of combinations using orthogonal arrays or pair-wise testing analysis and expert knowledge.   Although this example focuses on defining the equivalence classes for an input domain space, equivalence class partitioning can also be used to define valid and invalid classes for output equivalence classes. For example, in the triangle problem there are essentially four possible outputs:   ·         Sides A, B, and C equate to an equilateral triangle ·         Sides A, B, and C equate to an isosceles triangle ·         Sides A, B, and C equate to a scalene triangle ·         Sides A, B, and C do not form a valid triangle  Using output condition it is possible to define a more robust set of tests using the EQ Worksheet.   Input/Output  Condition Valid Equivalence Classes Invalid Equivalence Classes Equilateral A = B = C   Isosceles A = B ¹ C A = B + C Isosceles   A > B + C Isosceles   B = A + C ETC… … …   In order to be successful with equivalence class partitioning the test engineer must have an excellent understanding of the domain space. It is up to the test engineer to determine the equivalence relationships for each set of parameters. There is no magic formula for equivalence class partitioning. The test engineer must understand the properties of the values being evaluated and how those values are processed in order to derive an accurate set of equivalence class tests that achieve a reasonable degree of confidence in the program without over-testing.   REFERENCES: [1] Glenford J. Myers. The Art of Software Testing 1979 [2] Paul C. Jorgensen. Software Testing: A Craftsman’s Approach 1995

转载于:https://www.cnblogs.com/gieno/archive/2009/07/28/1532859.html