51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 6486|回复: 5
打印 上一主题 下一主题

[转贴] Test Case Design Tip

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2007-12-28 10:34:09 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
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.
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
发表于 2009-12-2 17:07:31 | 只看该作者
Good tips and it is very usfully especially for those complicated ones
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2009-12-2 18:28:56 | 只看该作者
good?
回复 支持 反对

使用道具 举报

该用户从未签到

4#
发表于 2009-12-10 12:24:23 | 只看该作者

翻译-Test Case Design Tip

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则与前面提到的解决方法中设计的用例是一样的。
回复 支持 反对

使用道具 举报

该用户从未签到

5#
发表于 2009-12-10 14:12:52 | 只看该作者

在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则与前面提到的解决方法中设计的用例是一样的。
回复 支持 反对

使用道具 举报

该用户从未签到

6#
发表于 2010-1-12 14:01:09 | 只看该作者
有个地方有问题

‘we tend to partion tasks
according to the AURS.”的
“partion"应为“partition”
回复 支持 反对

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-11-8 11:18 , Processed in 0.074118 second(s), 27 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表