写写个人测试心得,以及与志同道合者交流的空间
测试20100623-2
上一篇 /
下一篇 2010-06-23 14:48:23
/ 个人分类:个人测试
四、 TestCase的编写经验
就个人认为,编写时,要注意两个问题:
1) 如何对于一个整体的测试对象(例如:软件和应用程序等)设计TestCase;
2) 如何管理TestCase;
再重申一次,我这里所说的所有关于TestCase的内容都是针对的黑盒测试,并且是以Excel文档的形式来呈现。
4.1 设计TestCase
针对一个测试对象设计的TestCase的条数是不少的,尤其当TestCase细分到某个小组件的操作上时,那总TestCase数量就很多了。上面提供的一条TestCase的内容是一个基本的依据和框架,但在实际的操作过程中,可能需要考虑进行一些调整,因为,通过采用等价划分,因果图,状态图,或者其他的测试方法分析后,再以如上述【表1】的方式呈现TestCase时,就不一定能直观的呈现出思考意图,这时,可以考虑以表格的形式将要操作的内容进行呈现,以达到既可以直观和清晰的呈现内容,又可以方便测试。
首先,对于一个测试对象整体进行划分,将一个整体划分为更简单和更小的测试子对象(根据具体情况而定,一般可以分2~3级),这样可以更有针对性的设计TestCase,当完成各个子对象的TestCase用例的设计之后,再将这些各个小的测试子对象的TestCase进行整合,要考虑到测试子对象之间整合时的操作,也要设计TestCase。
图1
当确定了功能模块的划分,针对每一个子对象设计TestCase时,有几项内容没有在【表一】中体现,这包括以下几项:
测试版本
描述测试对象的版本
测试工具
描述测试时使用的工具
测试环境
描述测试时的环境
测试结果统计
描述测试的TestCase数,pass数,fail数,Block数等
同时,为了减少重复内容,对于一个子对象,它的这几项内容基本是一致的,所以可以将这几项拿出来,单独进行列表,减少在执行TestCase时,重复的内容,如果可行,可以将测试人员和测试时间也放在此处,这样,设计完成后的子对象的TestCase就可以比较完整的体现在对其进行测试时,所包含的基本内容。在设计子对象的TestCase用例时,就可以采用常用的因果图,状态图等价划分等几种方法(详细关于这些方法的操作已有很多的介绍和说明),具体的根据实际的情况具体的分析,目标是尽可能的覆盖用户的正确操作,非法操作。
※ 注意,每一个TestCase应该是具体的,不可再分的。
4.2 整合子对象TestCase
在整合测试子对象的TestCase时,更多的考虑子对象之间的协同操作的TestCase的编写,这里,个人在进行编写时,更多的以如下表格方式进行:
Sub1 Sub2
| Action1 | Action2
| Action3
|
Action1 | Result | | |
Action2 | | | |
Action3 | | | |
第一列和第一行分别列出协同操作的两个子对象的可协同操作项,右下端填写两种操作项的操作结果,如果两个操作项之间还有各种不同的参数,则可以根据具体的情况再细分。
五、管理TestCase
这里,我主要说的是,在完成了TestCase的设计和整合后,还需要考虑,如何统计执行完TestCase后的测试结果,以便于对于对象进行后期的质量的评估。这里可以根据之前的每个划分的测试对象进行绘制表格,形成图表来显示测试的结果。
参考图表:
TestCase Item
| Pass
| Fail
| Block
| Total
|
Item1 | | | | |
Item2 | | | | |
Item3 | | | | |
.... | | | | |
相关阅读:
- 基于数据驱动的软件自动化测试框架 (fishy, 2010-6-01)
- 组合测试用例生成技术 (fishy, 2010-6-07)
- 基于模型检测的软件测试技术 (fishy, 2010-6-08)
- 关于测试用例理念的个人想法 (yangzy707, 2010-6-10)
- 关于测试用例理念的一些想法 (fishy, 2010-6-11)
- 从测试用例看测试的问题及变化(转) (8596991, 2010-6-12)
- 基于状态转换的测试 (fishy, 2010-6-13)
- 测试用例的价值 (fishy, 2010-6-17)
- 一致性测试中的时间约束及测试用例生成算法 (fishy, 2010-6-23)
- 测试20100623 (carlli213, 2010-6-23)
收藏
举报
TAG:
测试用例