人生就是一场测试！
关于编写测试用例的反思
上一篇 /
下一篇 2011-10-16 08:40:26 / 天气: 晴朗
/ 心情: 高兴
/ 精华(1)
/ 置顶(1)
/ 个人分类：测试用例
所谓测试用例就是指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试步骤ID、测试环境、输入数据、预期结果、实际结果、测试人员、测试日期几部分。
测试用例主要分为五部分：
1.测试用例对需求覆盖的完整性：明确需求，理顺业务路径，从全局上把握住需求
2.测试用例的有效性
3.测试用例的可理解性：描述清晰，不能出现模棱两可的词语
4.测试用例的清晰性：用例清晰重点突出
5.测试用例的可维护性：注意测试用例的有效性，通用性。
这里我主要想讨论的就是测试的用例的实用性，记得我在刚入门学习软件测试编写测试用例的时候，单个模块写的用例用很多都是重复冗余的，主要是想写够老师讲的3000个测试用例，我们老师讲的是一个微软的测试人员，单就登陆模块就写了3000个测试用例，当时心里一直想好厉害啊！当然了，只有这种大公司才有充足的资源与技术的支持，那家公司会跟他们一样呢？ 单元测试、集成测试说明的是测试的范围，功能测试，性能测试这些说明的是测试的手段，当然某个功能测试包含了很多单元测试的联动，而我们在测试的时候实际上就是对代码设定路线的一种验算，如果我们生活在单线程，无UI的世界里，我们会更清楚的看到"PASS","ERROR","FAIL"三种状态，可是我们生在有包装UI的世界里，前几天我们公司还培训UI的设计课程，有了UI，就有了封装的API，有了各种各样的MESSAGE，所以就会有更多的ERROR的出现。这个时候很多编写测试用例的人就会通过编写测试用例的数量来回避这些陷阱，出发点虽不坏，但是做法是累死人的。如果你愿意为机器码写1亿个测试用例，如果你还很偏执，你可以为电路写上1万亿个测试用例，关键是你有命执行吗？
我在些测试用例的过程中，更倾向于构造实用的测试用例，我会有原则的：
1.接到任务不急于做，而是多思考，在纸上画出业务流程图
2.流程构造好了以后，快速剔除公用的测试用例。
3.构造用例先写符合主路径的用例“PASS”，“FAIL”，“ERROR”
4.精化测试用例，努力为ERROR，构造1-7种假设
5.执行用例强化FAIL的标准化输出，减少对应PASS的用例
6.进一步简化测试用例，是三者的百分比保持在：PASS:ERROR:FAIL=2：7：1
相关阅读:
- 【转】测试用例检查单 (莲藕之家, 2011-9-14)
- 马行走路线的测试用例设计 (xin_晴, 2011-9-29)
- 如何引导开发人员及项目经理评审测试用例及测试方案 (xin_晴, 2011-9-30)
- 如何评审测试用例 (holyghost0213, 2011-9-19)
- 浅谈手机软件测试用例设计方法 (xin_晴, 2011-9-30)
- 转 浅谈手机软件测试用例设计方法 (397917842, 2011-10-08)
- 用例设计心得---新人之路系列 (xin_晴, 2011-10-10)
- 如何编写一个好的测试用例 (xin_晴, 2011-10-26)
- 典型测试用例设计题总结——小强作品 (xin_晴, 2011-10-24)
- 自动化测试用例设计 (xin_晴, 2011-10-14)
收藏
举报
TAG:
测试用例
构建实用用例
朴实测试用例
