用例编号怎么规定_怎么做好软件测试用例的评审？

什么是测试用例评审？

测试用例(Test Case)：是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。

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

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

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

开始评审用例

正式开始做测试用例评审时，团队成员都不知道怎么做，而且团队有四个新人，技能和业务上都不够熟，为了让评审能走下去，我所采取的方式：一是设计测试用例人员先讲解下需求、再讲设计思路，二是测试经理、产品经理主动说出自己的疑问。其他人成员主要听和理解，这一评审方式好处 让团队成员可以更快地理解需求(在较短的时间内积累不同业务知识)。坏处就是：团队成员思考的时间少，不能发现问题，较难通过用例评审提高自己设计用例的技能。

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

优化评审方式

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

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

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

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

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

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

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

7)设计测试用例的成员需要在预估修正所需时间内 发出 修改后的测试用例；

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

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

明规范、定标准

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

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

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

3)评审流程标准化，包括 评审人员的构成、评审后的签字确认等。

-- End --

在公众号后台输入 用例模板 ，可以获取一套常用的用例编写模板。

---

---

文末寄语：  折一枝红叶在手，听万顷松涛澎湃。