Unit Test Study Note 5

Chapter 5 How to Develop Test Cases

5.1Basic Strategies for developing test cases

In software testing, there are two different test ideas: functional testing and structural testing.

Functional testing, also known as black box testing, has the basic idea that any program can be seen as a function that maps the value of an input definition field to an output value field. use functional tests to develop test cases. The only information used is the specification of the software.

Structural testing, also known as white-box testing, enables testers to develop test cases based on functional implementation.

The advantage of functional testing is that the test cases it develops are independent of the software implementation. Even if the implementation changes, the test cases are still effective. the disadvantage of functional testing is that its test cases may have serious redundancy.

The advantage of structural testing is that it can provide well-defined test coverage indicators, so as to visually display the tested scope of the software, but its disadvantage is that its developed test cases depend on implementation.

Therefore, the basic strategy for developing test cases is to develop test cases using functional testing methods, and then use test coverage indicators to improve test coverage and remove redundant test cases, this guarantees the quality of test cases.

The above-mentioned development strategies for test cases reflect the idea that unit testing tests the behaviors of classes or objects rather than member functions of classes or objects; unit tests should be behavior-centric without worrying about which class is being tested. Some member functions are only involved in a specific function (feature), rather than implementing this function, so it is not worthwhile to test such a member function independently. Focusing on Testing behavior, rather than each individual member function, we can better take into account the test coverage rate and the simplicity of refactoring.

5.2Boundary Value Test

The Boundary Value test is based on the following two assumptions:

• Software bugs are more likely to occur near the extreme values of input variables.
• Software failures are rarely caused by the occurrence of two (or more) defects at the same time.

Based on the preceding assumptions, the boundary value test generates test cases as follows:

• For each input variable, the values are at the minimum value, slightly higher than the minimum value, slightly lower than the maximum value, and maximum value. These values are recorded as Min, min +, Max-, and Max.
• Let only one variable take the above extreme values, while all other variables take the normal values.

The Boundary Value test is suitable for input variables that are independent from each other. the keywords here are "independence" and "physical quantity ". because these variables are independent of each other, we can only let one of them take the extreme value, and let other variables take the normal value. because these variables are physical quantities, they often have extreme values (even if there is no extreme value, we can also manually set the extreme values for testing ).

5.3Robustness Test

Robustness testing is responsible for testing whether the method under test is correct in handling exceptions. In unit testing, we should test the error processing logic by simulating exceptions.

However, it must be noted that, if the method itself is not required to handle certain exceptions, it is not necessary to perform a robustness test on the method. only perform robustness tests on the code that really requires exception handling.

5.4Equivalence test

The idea of equivalence testing is to develop test cases through one element in each equivalence class, thus reducing the redundancy of test cases. the key to the equivalence test is to determine the equivalence relationship of the class. The common method is to predict the possible implementation, and consider the functional operations that must be provided in the implementation.

The equivalence test can not only divide equivalence classes for input variables, but also divide equivalence classes for output results. therefore, when using an equivalence test, both input and output should be taken into account, which often produces good test results. after a proper equivalence class is divided, the test results are better when the Boundary Value of the equivalence class is tested.

Some common criteria for dividing equivalence classes include:

• Existence or not
• Value Range
• Element sequence
• Number of Elements
• Data format

5.5Decision Table Test

It is a schematic decision table.

	Rule 1	Rule 2	Rule 3, 4	Rule 5	Rule 6	Rules 7, 8
Condition1 Condition2 Condition3	T T T	T T F	T F -	F T T	F T F	F F -
Action1 Action2 Action3 Action4	O O	O O	O	O O	O	O

The following table describes the decision table:

• The value of condition is usually t/F (true/false), but it can also be the equivalence class mentioned in the previous section.
• A special condition value is "don't card" (don't care), which is represented by "-" in the decision table.
• The action of a decision table has some special values, such as impossible and report error ).

5.6Comprehensive use of multiple methods

In the previous sections, we have introduced several test case development technologies. when generating test cases for the tested and tested methods, these technologies are often used in combination, rather than one or two of them.

5.7Test Coverage rate indicator

The test coverage rate is an indicator to measure the quality of test cases. Therefore, after a test case is developed, we always need to use the code coverage monitoring software to test whether our test cases practice the tested code has achieved satisfactory test coverage.

For C ++, testcocoon is recommended. For C #, partcover is recommended. For Java, eclemma is recommended.

Is there an end to unit test case development? A good guideline is: Always test your fear to turn to dislike. As we have mentioned above, unit testing aims to provide us with a "Software clamp" or a "safety net ". If we already feel that the unit test cases are sufficient, so that we no longer worry about introducing bugs to code modifications, it is time to stop developing unit test cases. Therefore, you do not have to pursue a 100% test coverage rate. this is because some code does not contain any logic and therefore does not need to be tested. instead of testing for testing, you should test the code that actually produces bugs.