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