怎么做好测试用例评审

怎么做好测试用例评审

什么是测试用例评审

评审：指评议和审查;审议。为确定主题事项达到规定目标的适宜性、充分性和有效性所进行的活动。

测试用例评审如何走向正规

做事的方式有从上而下和从下往上，我比较擅长的是从下往上。

第一步：先开始评审

8月份正式开始做测试用例评审这件事情，刚开始时团队成员都不知道怎么开始做，一来是团队有四个新人，技能和业务上都不够熟，为了让评审能走下去，采取的方式：一写测试用例的人会讲解下需求，二是测试经理会主动说出疑问。其他人成员听和理解较多，这一评审方式好处 让团队成员可以更快地理解需求(在较短的时间内积累不同业务知识)，坏处就是：团队成员思考的时间少，不能发现问题，去提交自己编写测试用例的技能。

经过三个月的工作积累，也明显感觉到团队成员对业务有了一定的了解和分析能力，到了测试用例评审改进的时机啦，毕竟测试用例评审最终目的就是提交大家编写测试用例的水平。

第二步：优化评审方式

优化评审前，会先有一个培训会，再次告诉所有成员较为规范的测试用例评审 评审哪些内容，我们当前的评审有哪些缺点，如何来改进(这里有讨论)，以下是初步优化内容：

1)提前二天发出需求和测试用例 ?给参与用例评审的人员

2)会议前2小时 参与用例评审人员 将问题反馈到 主持人

3)主持人根据问题排优先级和严重程度(正式评审时 按优先级和严重程度 开始讨论)

4)评审过程中发现问题能当场修正的当场修正，修正时间超过5分钟的，会后修正。

5)评估测试用例所需的执行时间和优先级

6)整理待修正内容和评估修正需要的时间，会后发出

7)编写测试用例成员需要在预估修正所需时间内 发出 修改的测试用例

8)主持人检查 测试用例是否修正，没有修正则继续盯着

9)测试用例的主持人每月换一次，测试部门成员轮流当主持人

第三步：明规范、定标准

根据前段时间的测试用例评审经验，将前后台的测试用例进行总结，定义出明确的规范和标准。

1)简单业务需求 ，团队成员交叉审核即可

2)核心业务流程+复杂业务，启动团队评审流程