如何进行测试用例评审

进行测试用例评审

测试用例评审工作对测试人员能力的提高,测试效率的提高都有很好的作用,那么如果进行测试用例评审呢?它又哪些标准呢?通过的标准又是什么呢?

关于“测试用例内部评审的标准”的讨论的摘要:

首先要清楚内部评审的定义,是测试组内部的评审,还是项目组内部的评审。评审的定义不同,内容也不会相同。

如果是测试组内部的评审,应该着重于:
1. 测试用例本身的描述是否清晰,是否存在二义性
2.是否考虑到测试用例的执行效率.往往测试用例中步骤不断重复执行,验证点却不同,而且测试设计的冗余性,都造成了效率的低下
3.是否针对需求跟踪矩阵,覆盖了所有的软件需求,
4.是否完全遵守了软件需求的规定。这并不一定的,因为即使再严格的评审,也会出现错误,应具体情况具体对待。

如果是项目组内部的评审,也就需要评审委员会来做了,角度不同,评审的标准也不同。比如:
收集客户需求的人员注重你的业务逻辑是否正确;
分析软件需求规格的人注重你的用例是否跟规格要求一致;
开发负责人会注重你的用例中对程序的要求是否合理。

要清楚地一点是:为了保证测试用例设计的质量,以及评审的收益,在提交项目组评审之前,必须通过测试部门或测试组内部的评审。


1.测试用例是否覆盖了所有需求.
2.测试用例内容是否正确,是否与需求目标一致.
3.测试用例内容是否完整,是否清楚包含输入和预期输出结果.
4.测试用例是否具有指导性,是否能灵活指导测试人员通过用例发现更多缺陷,而不是限制他们的思维.
初期设计测试点时,应该进行测试组内部评审,当然首先是要保证需求全被覆盖,如果能在评审时,让需求分析人员参与进来,效果会更好。


测试用例评审如何去做呢?
测试用例的评审能够使用例的结构更清晰,覆盖的用户场景更全面;对于测试工程师来说也是一个快速提高用例设计能力的过程。

  1、需要评审的原因

  测试用例是软件测试的准则,但它并不是一经编制完成就成为准则。由于用例开发人员的设计经验和对需求理解的深度各不相同,所以用例的质量难免会有不同程度的差异。

  2、进行评审的时机

  一般会有两个时间点。第一,是在用例的初步设计完成之后进行评审;第二是在整个详细用例全部完成之后进行二次评审。如果项目时间比较紧张,尽可能保证对用例设计进行评审,提前发现其中的不足之处。

  3、参与评审人员

  这里会分为多个级别进行评审。

  1) 部门评审,测试部门全体成员参与的评审。

  2) 公司评审,这里包括了项目经理、需求分析人员、架构设计人员、开发人员和测试人员。

  3) 客户评审,包括了客户方的开发人员和测试人员。这种情况在外包公司比较常见。

  4、评审内容

  评审的内容有以下几个方面:

  1) 用例设计的结构安排是否清晰、合理,是否利于高效对需求进行覆盖。

  2) 优先极安排是否合理。

  3) 是否覆盖测试需求上的所有功能点。

  4) 用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确;期待结果是否有明显的验证方法。

  5) 是否已经删除了冗余的用例。

  6) 是否包含充分的负面测试用例。充分的定义,如果在这里使用2&8法则,那就是4倍于正面用例的数量,毕竟一个健壮的软件,其中80%的代码都是在“保护”20%的功能实现。

  7) 是否从用户层面来设计用户使用场景和使用流程的测试用例。

  8) 是否简洁,复用性强。例如,可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。

  个人认为,一个“健康”的测试用例至少要通过前5个标准。

  5、评审的方式

  1) 召开评审会议。与会者在设计人员讲解之后给出意见和建议,同时进行详细的评审记录。

  2) 通用邮件与相关人员沟通

  3) 通用IM工具直接与相关人员交流

  方式只是手段,得到其它人员对于用例的反馈信息才是目的。

  无论采用那种方式,都应该在沟通之前把用例设计的相关文档发送给对方进行前期的学习和了解

,以节省沟通成本。

  6、评审结束标准

  在评审活动中会收集到用例的反馈信息,在此基础上进行用例更新,直到通过评审。

  个人愚见,仅参考 ^o^

 

测试用例评审检查单:

     序号 主要检查项

  1《需求规格说明书》是否评审并建立了基线?

  2 是否按照测试计划时间完成用例编写?

  3 需求新增和变更是否进行了对应的调整?

  4 用例是否按照公司定义的模板进行编写?

  5 测试用例是否覆盖了《需求规格说明书》?

  6 用例编号是否和需求进行对应?

  7 非功能测试需求或不可测试需求是否在用例中列出并说明?

  8 用例设计是否包含了正面、反面的用例?

  9 每个测试用例是否清楚的填写了测试特性、步骤、预期结果?

  10 步骤/输入数据部分是否清晰,是否具备可操作性?

  11 测试用例是否包含测试数据、测试数据的生成办法或者输入的相关描述?

  12 测试用例是否包含边界值、等价类分析、因果图、错误推测、等测试用例设计方法?是否针对需求不同部分设计使用不同设计方法?

  13 重点需求用例设计至少要有三种设计方法?

  14 每个测试用例是否都阐述预期结果和评估该结果的方法?

  15 需要进行打印、表格、导入、导出、接口是否存在打印位置、表格名称、指定数据库表名或文件位置;表格和数据格式是否有说明或附件?

  16 用例覆盖率是否达到相应质量指标?

  17 用例预期缺陷率是否达到相应质量指标?

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
测试用例评审结论范文: 在进行测试用例评审的过程中,我们团队对每个测试用例进行了仔细的分析和讨论。通过评审,我们得出以下结论: 1. 测试用例的质量较高:我们的团队在编写测试用例时,考虑了系统的各个功能和边界条件,并且将测试场景设计得非常详尽和全面。测试用例中包含了清晰的步骤和预期结果,有助于测试人员准确地执行和验证系统的功能。 2. 测试用例的覆盖范围广泛:我们特别关注了系统的核心功能和重要的边界条件,并编写了多个验证场景来测试其正确性和稳定性。除此之外,我们还考虑了各种异常情况和极端情况,以确保系统在不同条件下的稳定性和鲁棒性。 3. 改进建议和优化点:在评审过程中,我们也提出了一些建议和优化点。例如,对于某些测试用例,我们建议进一步细化步骤或添加更多的预期结果,以增强测试用例的准确性和可重复性。此外,对于较复杂的功能,我们建议增加更多的负向测试用例,以确保系统在不良条件下的处理能力。 综上所述,通过测试用例评审,我们团队对测试用例的质量和完整性进行了全面的检查和讨论。我们的测试用例在覆盖范围和质量方面得到了高度认可,同时也提出了改进建议来进一步提升测试用例的效果。我们将持续关注测试用例的执行和反馈,并进行必要的优化和更新。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值