Test Case Design Tip

hpdynasty

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:


can only test if function_test can work properly, but can't provide more failue information if fails.
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
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.
The better design for the test of this example could be:
we partition the test into to 2, one for each module, i.e, case 1 will test
File_1 -->Function_sub1 -->File_2; case 2 will test File_2 --> Function_sub2 -->File_3; case 3 is the same as the case designed in the solution mentioned above.

enjoytest

Good tips and it is very usfully especially for those complicated ones

mentgmery

good?

caueva2006

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.
在测试用例设计过程中，我们趋向于根据AURS来划分任务。实际上，我们可以进行更加深入的划分。这样就会使得我们的设计更加清晰、规则，并能保证测试覆盖率。否则，设计并实施一个复杂的测试用例就是浪费时间和易于出错的，而且，测试覆盖率也将无法得到保证。

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->功能_测试->文件_3
从内部来看，这个功能_测试包括两个子模块：
文件_1->功能_子模块1->文件_2
文件_2->功能_子模块2->文件_3
我们可以用一个单一的测试用例来测试这整个应用程序：我们给文件_1提供功能_测试，然后验证文件_3是否得到适当的更新。这个设计的缺点是：

can only test if function_test can work properly, but can't provide more failue information if fails.
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
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.
The better design for the test of this example could be:
we partition the test into to 2, one for each module, i.e, case 1 will test
File_1 -->Function_sub1 -->File_2; case 2 will test File_2 --> Function_sub2 -->File_3; case 3 is the same as the case designed in the solution mentioned above.
只能测试这个功能_测试是否正常运行，但是如果测试失败则无法提供更多有关失败原因的信息。如果功能_子模块1产生了错误的输出opA，尽管如此，功能_子模块2的运行也不正常，也就是说，当IP=opA，文件_3将产生正确的结果而不是一个失败的结果。如果功能_子模块1错误地生成OP1，尽管如此，功能_子模块2并没有处理这个特定的错误值（OP1），功能_子模块2就会生成一个错误，这个错误就会被认定为功能_子模块2的关键错误。
这个例子的一个更好的测试用例设计应该是这样的：
我们将测试分成2部分，每一部分对应一个模块。例如，用例1测试文件_1->功能_子模块1->文件_2；用例2测试文件_2->功能_子模块2->文件_3；用例3则与前面提到的解决方法中设计的用例是一样的。

brilliantking

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.
在测试用例设计过程中，我们趋向于根据AURS来划分任务。实际上，我们可以进行更加深入的划分。这样就会使得我们的设计更加清晰、规则，并能保证测试覆盖率。否则，设计并实施一个复杂的测试用例就是浪费时间，并且容易出错，而且，测试覆盖率也可能无法得到保证。

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->功能_测试->文件_3
从内部来看，这个功能_测试包括两个子模块：
文件_1->功能_子模块1->文件_2
和
文件_2->功能_子模块2->文件_3
我们可以用一个单一的测试用例来测试这整个应用程序：我们把文件_1提供给功能_测试，然后验证文件_3是否得到正确的更新。这个设计的缺点是：

can only test if function_test can work properly, but can't provide more failue information if fails.
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
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.
The better design for the test of this example could be:
we partition the test into to 2, one for each module, i.e, case 1 will test
File_1 -->Function_sub1 -->File_2; case 2 will test File_2 --> Function_sub2 -->File_3; case 3 is the same as the case designed in the solution mentioned above.
只能测试这个功能_测试是否正常运行，但是如果该功能运行不正确，则无法提供更多有关失败原因的信息。如果功能_子模块1产生了错误的输出opA，而功能_子模块2的运行也不正常，也就是说，当输入(IP)=opA时，功能_测试会在文件_3中生成正确的结果而不是一个失败的结果。如果功能_子模块1错误地生成OP1，然而，功能_子模块2并没有被设计来处理这个特定的错误值（OP1），功能_子模块2就会生成一个错误，这个错误就会被认定为功能_子模块2的关键错误。
这个例子的一个更好的测试用例设计应该是这样的：
我们将测试分成2部分，每一部分对应一个模块。即，用例1测试文件_1->功能_子模块1->文件_2；用例2测试文件_2->功能_子模块2->文件_3；用例3则与前面提到的解决方法中设计的用例是一样的。

fanglyfan

有个地方有问题

‘we tend to partion tasks
according to the AURS.”的
“partion"应为“partition”