一、前言

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

 

二、测试用例评审形式

按正式程度来说:

  • 会议评审

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

  • 非会议评审

          不需要开会,可以是项目组的成员对测试用例的书面检查。

按参与角色来说:

  •  测试组评审

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

  • 项目组评审

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

  • 客户评审

          如果是外包项目,可能会有客户方的代表,例如客户方业务人员参与的评审。一般在外包公司较常见。

 

三、测试用例评审流程

 

  • 评审计划

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

  • 发起评审通知

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

  • 用例评审

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

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

  • 问题跟踪

          评审会议后,针对用例问题清单,需及时修改测试用例。修改完成后,发给评审组成员确认,直到已达评审通过准则,评审结束。否则需采取二次甚至多次评审。

  • 评审结束

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

 

四、总结

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

 

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

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

 

 posted on 2020-02-21 13:37  豆姐姐  阅读(3157)  评论(1编辑  收藏  举报