概念
测试用例（test case）为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。
好处
1、有效的、快速的熟悉了解待测产品
2、测试用例的编写、执行的数量可以评估需求的覆盖程度
3、测试用例的细化程度，可以作为阶段性工作排期的一个依据
4、测试用例的输出可以将人为因素的影响减小，例如编写测试用例的人不能操作执行工作，那么依据用例文档，其他人可以进行执行操作。
总结：思路清晰、避免遗漏、跟进测试进展、历史参考、避免重复性
测试用例开始设计时间
当需求文档定版后，就可以进行测试点的提炼，开展测试用例的编写
如果文档不合格，最好带着解决方法去找领导
在测试过程中如果出现需求变更，一定要评估
如何设计
1、将产品文档中或者需求文档中的原则或规则转化为每个用例的检查点
2、单个用例最小化原则，一条用例只做一件事
3、先从单个模块或者功能点开始入手
4、借助一些用例设计方法，如等价类、边界值、因果图等
5、兼容性：如浏览器兼容性、操作系统兼容性等
PS：1.设计用例时要注意数据库中数据正确性的验证
2.要考虑关联模块的问题
3.异常用例非常重要
实际工作中测试用例的设计
1、首先根据需求文档匹配模块与角色的关系即usecase
2、输出流程图
3、依照usecase图和流程如、业务规则以及设计用例方法，输出测试用例
思考
1、用例的评审与更新？
所有的用例都要评审，评审过后用例更新了才有价值
2、所有的项目都需要写测试用例？
中型或大型的需求
3、测试用例越详细越好
只要保证任何人能看懂
元素：编号、用例描述、前置条件、步骤、预期结果
感想
其实我真正做测试的时间也不长，大概只有2个多月。转正没多久，就被领导派去做别的事情了，直到今年3月初才结束，简直喜大普奔。现在在跟一个项目，还在开发阶段，所以刚好面临用例编写。之前我只写过一次，还是做得二期项目，所以基本就是在前人的用例基础上更新。现在是新开的一个项目，3个人测试，我资历最浅，所以负责相对简单的部分。负责这个项目的开发有组织过2次小会，讲解这个项目。第一次讲解了项目流程图和参与项目的人员以及项目的计划。第二次是因为需求有变动。然而，木有需求说明书，现有的文档只有项目流程图和技术方案，写用例简直麻爪。其实开会的时候，我自认为对整个流程听得还是比较认真的，也觉得理解的还行，觉得用例编写应该还可以。但是，我现在基本只列出了测试点，具体内容不知道咋写，没有需求说明书，一些小细节就不是很清楚，再加上开发说还要对现有的页面功能点进行改造，所以简直一言难尽。现在才发现，用例编写也没有我想的那么简单。困难总是要克服的，我打算在仔细研究下技术方案，然后再跟测试小组长请教下。希望我的第一次用例编写能够顺利完成。
网友评论