在一个完整的测试流程中，测试用例是很核心的一个产出物。一份优秀的测试用例，能确保软件产品质量的可控。
但由于每个人思维局限性，对产品背景、需求、功能实现逻辑等理解深度不一致，编写的测试用例或多或少存在一些遗漏点，就算是高级测试工程师，甚至是专家级的，也不能百分百保证说自己写的测试用例质量没有问题。因此，测试用例评审工作就显得至关重要。
测试用例评审形式
按正式程度来说：
会议评审
一种正式评审，需要以会议室且投屏的形式，进行评审活动非会议评审
不需要开会，可以是项目组的成员对测试用例的书面检查。
按参与角色来说：
测试组评审
测试组内部成员参与的评审。当一份测试用例初稿完成后，一般先进行测试组内部评审。评审内容侧重在测试思维完整系统性、确保对需求是可追溯且高覆盖的。尤其是当测试团队有测试新人时，测试思维完整性不够，测试组内部评审必不可少。项目组评审
即整个项目团队人员参与的评审。一般在测试组评审之后进行。包括项目经理、开发人员、架构设计人员、测试人员、产品需求人员，另外像配置管理人员、运营人员具备评审能力都应积极参与。开发人员会注重用例对程序逻辑的覆盖，产品需求人员会注重业务覆盖，另外可确保测试、开发、产品对于需求理解的一致性。客户评审
如果是外包项目，可能会有客户方的代表，例如客户方业务人员参与的评审。一般在外包公司较常见。
测试用例评审流程
评审计划
一次高效的用例评审活动，是需要提前做好评审计划的。计划中需要明确：本次评审的目的、评审范围、参与人员的角色与职责、评审过程及形式、评审通过准则等。像用例评审检查清单(见最后附件模板)一般在此环节整理完成。发起评审通知
待评审文档即测试用例编写完成，即可发起评审通知。用例初稿完成后，先在测试组内部发起，内部确认用例ok，再到整个项目组评审通知。一般至少用例评审活动前2天发起评审通知，可以是OA通知、邮件通知、或者钉钉/QQ讨论群发布信息。通知内容包括：评审时间、地点、参与人员、待评审文档(测试用例文档)、评审内容(评审检查清单)。这样在正式评审活动之前，评审人员可先行检查用例并记录标注问题，提交汇总到测试负责人，保证后续会议评审效率。
用例评审
测试组内部评审，一般评审彼此的用例，以文档检查的形式居多。若需求业务逻辑复杂，视情况开展会议评审。项目组评审主要是会议评审。会议评审，一般测试负责人(参与测试的测试团队负责人，可能是测试主管、也可能是临时小组长)为会议主持人，会议评审开始时，一般先会大致介绍用例编写的思路，可以按照核心业务流程展开评审，再到各个不同的模块的用例设计，重点包括测试验证点、测试数据、预期输出。同时针对被指出的用例问题组织讨论并做好用例标记记录。会后，整理问题清单，并明确问题责任人。
问题跟踪
评审会议后，针对用例问题清单，需及时修改测试用例。修改完成后，发给评审组成员确认，直到已达评审通过准则，评审结束。否则需采取二次甚至多次评审。评审结束
评审结束后，测试负责人整理测试用例评审报告(见最后附件模板)、评审结果项目经理同意确认。测试用例评审通过后形成终版并完成归档。
总结
作为从业8年的软件测试工程师，经常有接触到一些测试从业者的感慨，例”公司用例不会要求去写、更别说测试用例评审工作了!”
首先关于测试用例，如果因为项目时间关系，可以做弱化，比如可以用xmind整理下测试大纲，但不能没有，它是必须！
另外测试用例评审工作，大部分公司是没有这个环节的，其实评审工作可以帮助测试团队更早地发现测试过程中的问题，可以预防问题被带入发布阶段而导致多次返工。
从时间和人力成本上来说都是很有必要实施的一项测试活动。最后，希望本文章给正在推行评审流程的你，一些帮助。
附用例评审检查清单，仅供参考
附用例评审报告，仅供参考
感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取
)
)
