Test Case Design Tip:测试案例的进一步划分

In testing, when the test target is quite complicated, try
to partition target tasks and design separate test scrīpt
for each simpler task.


During testing case design, we tend to partion tasks
according to the AURS. Actually, we can partition even
further. This is to make our design clear, clean and ensure
the test coverage. Otherwise, to design & implement a
complicated test case is time consuming and error prone, and
what’s more, test coverage may not be guaranteed.

Example:
This is an application we are going to test: File_1 -->Function_test-->File_3
Internally, there are two submodules in Function_test:
File_1 -->Function_sub1-->File_2
and
File_2 -->Function_sub2-->File_3
We can test the whole application in single case: we supply File_1 to the function_test, and verify if File_3 can be updated properly. The weakness
of this design is:

1. can only test if function_test can work properly, but can't provide more failue information if fails.
2. if function_sub1 generate wrong output opA, however, function_sub2 also does not working properly, s.t when IP=opA, instead of generate faiure result, it generate sucessful result in File_3
3. if function_sub1 generate OP1 wrongly, however, function_sub2 is not supposed
   to handle this specific wrong value (OP1), a failure generate by function_sub2
   , it could be identified as a key failure of function_sub2.