1 Software Testing

2 Equivalence Class Testing

3 The use of equivalence class testing has two motivations: –Sense of complete testing –Avoid redundancy Equivalence classes form a partition of a set that is a collection of mutually disjoint subsets whose union is the entire set. Two important implications for testing: 1.The fact that the entire set is represented provides a form of completeness 2.The disjointness assures a form of non-redundency

4 Equivalence Classes The idea of equivalence class testing is to identify test cases by using one element from each equivalence class. If the equivalence classes are chosen wisely this greatly reduces the potential redundancy among test cases. The key point in equivalence class testing is the choice of the equivalence relation that determines the classes (partitions). In general, an equivalence class is a subset of domain of a variable such that the program’s behavior is uniform for all values in the class.

5 Equivalence Class Selection –no dependence on knowledge of code, only the specification –needs knowledge of input domain that usually goes beyond what an interface design spec provides »familiarity with specifications –must understand how inputs are mutually dependent.

6 Example Let us consider a program P with 3 inputs: a, b and c and the corresponding input domains are A, B, and C. –Let the partitions be defined as:

7 define a 1, a 2 and a 3 as: –let a i be a “representative” or “typical” value within its respective equivalence class (e.g., the midpoint in a linear equivalence class). –similarly define b i and c i. test cases can be stated for the inputs in terms of the representative points. the basic idea behind the techniques is that one point within an equivalence class is just as good as any other point within the same class.

8 Weak Equivalence Class Testing Weak equivalence class testing is accomplished by using one value of each variable from each equivalence class in test cases. The minimum number of test cases is equal to the number of classes in the domain with the largest number of subsets. From the previous example, we have four test cases: Test Case Variable a Variable b Variable c WE1 a1a1 b1b1 c1c1 WE2 a2a2 b2b2 c2c2 WE3 a3a3 b3b3 c1c1 WE4 a1a1 b4b4 c2c2

9 Strong Equivalence Class Testing Strong equivalence class testing is based on the Cartesian Product of the partition subsets. From the previous example, this would generate: 3 * 4 * 2 = 24 test cases Generates more test cases which test for any interaction between the representative values from each of the subsets. For either method, it may be possible to define equivalence relations for the program output, then test cases can also be based on these.

10 Test Case #abc SE1a1b1c1 SE2a1b1c2 SE3a1b2c1 SE4a1b2C2 SE5a1b3C1 SE6a1b3C2 SE7a1b4C1 SE8a1b4C2 SE9a2b1C1 SE10a2b1C2 SE11a2b2C1 SE12a2b2C2 SE13a2b3C1 SE14a2b3C2 SE15a2b4C1 SE16a2b4C2 SE17a3b1C1 SE18a3b1C2 SE19a3b2C1 SE20a3b2C2 SE21a3b3C1 SE22a3b3C2 SE23a3b4C1 SE24a3b4c2

11 Robust Equivalence Class Testing In addition to the valid partitions of the input domains, invalid partitions are also considered Invalid partitions contain invalid values or the values lying outside of the allowed range May be combined with both weak normal and strong normal equivalence class testing

12 Traditional View The traditional view of equivalence class testing defines equivalence in terms of validity that is, test cases determined from the valid and invalid values for each input variable. For each input variable there are valid and invalid values. In the traditional approach, these are identified and numbered, and then incorporated into test cases.

13 Traditional View Given valid and invalid sets of inputs, the traditional equivalence testing strategy identifies test cases as follows: –For valid inputs, use one value from each valid class (as in what we have called weak equivalence class testing). In this context, each input in these test cases will be valid. –For invalid inputs, a test case will have one invalid value and the remaining values will be valid. In this context, a “single failure” should cause the test case to fail. If the input variables have defined ranges, then the test cases from traditional equivalence class testing will always be a subset of those that would be generated by robustness testing.

14 Issues with Traditional View There are two problems with the traditional equivalence testing: –The first is that, very often, the specification does not define what the expected value for an invalid test case should be. –The second problem is that strongly typed languages eliminate the need for the consideration of invalid inputs.

15 Example For example consider a program with two input variables size and weight : –valid ranges: S1: 0 < size < 200 W1: 0 < weight < 1500 –corresponding invalid ranges might be:

16 Test Cases Example (Traditional View) Test Case sizeweight Expected Output TE what ever it should be TE2100invalid input TE invalid input TE4750invalid input TE invalid input

17 Equivalence Test Cases for the Triangle Problem (Output Domain) In the problem statement we note that there are four possible outputs: –Not a Triangle –Isosceles –Equilateral –Scalene We can use these to identify output (range) equivalence classes: R1= { | the triangle with sides a, b, c, is equilateral} R2= { | the triangle with sides a, b, c, is isosceles} R3= { | the triangle with sides a, b, c, is scalene} R4= {a, b, c> | sides a, b, c do not form a triangle} These classes yield the following simple set of test cases:

18 Sample Test Cases based on Output Domain Test CaseabcExpected Output OE1555Equilateral OE2223Isosceles OE3345Scalene OE4412Not a Triangle

19 Equivalence Test Cases for the Triangle Problem (Input Domain) If we base the equivalence classes on the input domain, we will obtain a larger set of test cases. We can define the sets: D1= { | a=b=c} D2= { | a=b, a≠c} D3= { | a=c, a≠b} D4= { | b=c, a≠b} D5= { | a≠b, a≠c, b≠c} As a separate property we can apply the triangle property to see even if the input constitutes a triangle D6= { | a ≥ b+c} D7= { | b ≥ a+c} D8= { | c ≥ a+b} If we wanted also we could split D6 into D6’={ | a = b+c} and D6’’= { | a > b+c}

20 Equivalence Test Cases for the NextDate Problem (Input Domain) Nextdate is a function of three variables, month, day, and year and these have ranges defined as: 1 ≤ month ≤ 12 1 ≤ day ≤ ≤ year ≤ 2012 We will examine below the valid, invalid equivalence classes, strong, and weak equivalence class testing.

21 Traditional Test Cases The valid equivalence classes are: M1= {month | 1 ≤ month ≤ 12} D1= {day | 1 ≤ day ≤ 31} Y1= {year | 1812 ≤ year ≤ 2012} The invalid equivalence classes are: M2= {month | month < 1} M3= {month | month > 12} D2= {day | day < 1} D3= {day | day > 31} Y2= {year | year < 1812} Y3= {year | year > 2012} These classes yield the following test cases, where the valid inputs are mechanically selected from the approximate middle of the valid range:

22 Traditional Test Cases Case IDMonthDayYearExpected Output TE /16/1912 TE Invalid TE Invalid TE461912Invalid TE Invalid TE Invalid TE Invalid

23 Choice of Equivalence Classes If we more carefully chose the equivalence relation, the resulting equivalence classes will be more useful M1= {month | month has 30 days} M2= {month | month has 31 days} M3= {month | month is February} D1= {day | 1 ≤ day ≤ 28} D2= {day | day = 29} D3= {day | day = 30} D4= {day | day=31} Y1= {year | year = 1900} Y2= {year | 1812 ≤ year ≤ 2012 AND year ≠ 1900 AND (year = 0 mod 4} Y3= {year | 1812 ≤ year ≤ 2021 AND year ≠ 0 mod 4}

24 Weak Equivalence Class Test Cases Case IDMonthDayYearExpected Output WE /15/1900 WE /30/1912 WE Invalid WE Invalid

25 Strong Equivalence Test Cases CASE IDMonthDayYearOutput SE /15/1900 SE /15/1912 SE /15/1913 SE /30/1900 SE /30/1912 SE /30/1913 SE /1/1900 SE /1/1912 SE /1/1913 SE ERROR SE ERROR SE ERROR SE /15/1900 SE /15/1912 SE /15/1913 SE /30/1900 SE /30/1912 SE /30/1913

26 Strong Equivalence Test Classes CASE IDMonthDayYearOutput SE /31/1900 SE /31/1912 SE /31/1913 SE /1/1900 SE /1/1912 SE /1/1913 SE /15/1900 SE /15/1912 SE /15/1913 SE ERROR SE /1/1912 SE ERROR SE ERROR SE ERROR SE ERROR SE ERROR SE ERROR SE ERROR

27 Guidelines and Considerations The traditional form of equivalence testing is generally not as thorough as equivalence testing with carefully chosen partitions which, in its turn, is not as thorough as strong equivalence testing If error conditions is a priority we can extend strong equivalence testing to include invalid classes Equivalence class testing is appropriate when input data is defined in terms of ranges and sets of discrete values. Logic of functionality of the program can help define the equivalence classes Strong equivalence takes the presumption that variables are independent, otherwise it generates some “error” test cases Can be strengthened by using it with domain testing (boundary value)