少一点问别人为什么，多一点问自己凭什么。我是范范，我为自己代言！
怎么做好测试用例评审（转载）
上一篇 /
下一篇 2017-02-27 10:07:47
/ 个人分类：基本理论
转载自http://www.51testing.com/html/13/n-3708413.html
什么是测试用例评审 测试用例（Test Case）：是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。 评审：指评议和审查；审议。为确定主题事项达到规定目标的适宜性、充分性和有效性所进行的活动。
测试用例评审如何走向正规
做事的方式有从上而下和从下往上，我比较擅长的是从下往上。
第一步：先开始评审
8月份正式开始做测试用例评审这件事情，刚开始时团队成员都不知道怎么开始做，一来是团队有四个新人，技能和业务上都不够熟，为了让评审能走下去，采取
的方式：一写测试用例的人会讲解下需求，二是测试经理会主动说出疑问。其他人成员听和理解较多，这一评审方式好处
让团队成员可以更快地理解需求（在较短的时间内积累不同业务知识），坏处就是：团队成员思考的时间少，不能发现问题，去提交自己编写测试用例的技能。
经过三个月的工作积累，也明显感觉到团队成员对业务有了一定的了解和分析能力，到了测试用例评审改进的时机啦，毕竟测试用例评审最终目的就是提交大家编写测试用例的水平。 第二步：优化评审方式
优化评审前，会先有一个培训会，再次告诉所有成员较为规范的测试用例评审 评审哪些内容，我们当前的评审有哪些缺点，如何来改进（这里有讨论），以下是初步优化内容：
1）提前二天发出需求和测试用例 ?给参与用例评审的人员
2）会议前2小时 参与用例评审人员 将问题反馈到 主持人
3）主持人根据问题排优先级和严重程度（正式评审时 按优先级和严重程度 开始讨论）
4）评审过程中发现问题能当场修正的当场修正，修正时间超过5分钟的，会后修正。
5）评估测试用例所需的执行时间和优先级
6）整理待修正内容和评估修正需要的时间，会后发出
7）编写测试用例成员需要在预估修正所需时间内 发出 修改的测试用例
8）主持人检查 测试用例是否修正，没有修正则继续盯着
9）测试用例的主持人每月换一次，测试部门成员轮流当主持人
第三步：明规范、定标准
根据前段时间的测试用例评审经验，将前后台的测试用例进行总结，定义出明确的规范和标准。
1）简单业务需求 ，团队成员交叉审核即可
2）核心业务流程+复杂业务，启动团队评审流程
收藏
举报
TAG:
