如何高效开展测试用例评审？附用例评审检查清单及用例评审报告模板

1、前言

       在一个完整的测试流程中，测试用例是很核心的一个产出物。一份优秀的测试用例，能确保软件产品质量的可控。但因为每一个人思惟局限性，对产品背景、需求、功能实现逻辑等理解深度不一致，编写的测试用例或多或少存在一些遗漏点，就算是高级测试工程师，甚至是专家级的，也不能百分百保证说本身写的测试用例质量没有问题。所以，测试用例评审工做就显得相当重要。

 

2、测试用例评审形式

按正式程度来讲：

• 会议评审

          一种正式评审，须要以会议室且投屏的形式，进行评审活动

• 非会议评审

          不须要开会，能够是项目组的成员对测试用例的书面检查。

按参与角色来讲：

•  测试组评审

           测试组内部成员参与的评审。当一份测试用例初稿完成后，通常先进行测试组内部评审。评审内容侧重在测试思惟完整系统性、确保对需求是可追溯且高覆盖的。尤为是当测试团队有测试新人时，测试思惟完整性不够，测试组内部评审必不可少。

• 项目组评审

           即整个项目团队人员参与的评审。通常在测试组评审以后进行。包括项目经理、开发人员、架构设计人员、测试人员、产品需求人员，另外像配置管理人员、运营人员具有评审能力都应积极参与。开发人员会注重用例对程序逻辑的覆盖，产品需求人员会注重业务覆盖，另外可确保测试、开发、产品对于需求理解的一致性。

• 客户评审

          若是是外包项目，可能会有客户方的表明，例如客户方业务人员参与的评审。通常在外包公司较常见。

 

3、测试用例评审流程

 

• 评审计划

          一次高效的用例评审活动，是须要提早作好评审计划的。计划中须要明确：本次评审的目的、评审范围、参与人员的角色与职责、评审过程及形式、评审经过准则等。像用例评审检 查清单(见最后附件模板)通常在此环节整理完成。

• 发起评审通知

          待评审文档即测试用例编写完成，便可发起评审通知。用例初稿完成后，先在测试组内部发起，内部确认用例ok，再到整个项目组评审通知。通常至少用例评审活动前2天发起评审通知，能够是OA通知、邮件通知、或者钉钉/QQ讨论群发布信息。通知内容包括：评审时间、地点、参与人员、待评审文档(测试用例文档)、评审内容(评审检查清单)。这样在正式评审活动以前，评审人员可先行检查用例并记录标注问题，提交汇总到测试负责人，保证后续会议评审效率。

• 用例评审

          测试组内部评审，通常评审彼此的用例，以文档检查的形式居多。若需求业务逻辑复杂，视状况开展会议评审。项目组评审主要是会议评审。

          会议评审，通常测试负责人(参与测试的测试团队负责人，多是测试主管、也多是临时小组长)为会议主持人，会议评审开始时，通常先会大体介绍用例编写的思路，能够按照核心业务流程展开评审，再到各个不一样的模块的用例设计，重点包括测试验证点、测试数据、预期输出。同时针对被指出的用例问题组织讨论并作好用例标记记录。会后，整理问题清单，并明确问题责任人。

• 问题跟踪

          评审会议后，针对用例问题清单，需及时修改测试用例。修改完成后，发给评审组成员确认，直到已达评审经过准则，评审结束。不然需采起二次甚至屡次评审。

• 评审结束

          评审结束后，测试负责人整理测试用例评审报告(见最后附件模板)、评审结果项目经理赞成确认。测试用例评审经过后造成终版并完成归档。

 

4、总结

        做为从业8年的软件测试工程师，常常有接触到一些测试从业者的感慨，例”公司用例不会要求去写、更别说测试用例评审工做了!” 首先关于测试用例，若是由于项目时间关系，能够作弱化，好比能够用xmind整理下测试大纲，但不能没有，它是必须！另外测试用例评审工做，大部分公司是没有这个环节的，其实评审工做能够帮助测试团队更早地发现测试过程当中的问题，能够预防问题被带入发布阶段而致使屡次返工。从时间和人力成本上来讲都是颇有必要实施的一项测试活动。最后，但愿本文章给正在推行评审流程的你，一些帮助。

 

附用例评审检查清单，仅供参考

 附用例评审报告，仅供参考