如何高效进行测试用例评审

发表于:2023-10-09 09:27

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:laofashi2015    来源:CSDN

  1.用例评审的目的
  ·为了减少测试人员执行阶段做无效工作,执行无效case,提交无效缺陷(可以友情提醒研发同学,讲到自己负责的相关模块时,注意下是否存在异议点)
  · 为了避免三方(产品、研发、测试)需求理解不一致;
  · 为了每个测试人员的质量标准与项目要求标准达成一致。
  2.评审前的准备工作
  2.1用例编写
  需求评审结束后,可以把需求拆分为功能点
  测试点梳理时,要关注横向逻辑,即功能点本身,更要关注纵向逻辑,即业务流。
  工具:建议用XMind
  优点:用画思维导图的方式,逻辑清楚,便于评审人员(产品和开发人员)快速查看,评审效率高。
  具体用什么工具方法,大家可依个人喜好和项目需要而定,不过目标都是让用例评审高效快捷的开展,并产生价值。
  把功能点分解为具体的测试用例
  需在思维导图上补全明确的操作步骤、预期结果;执行阶段可以追加实际测试结果,便于测试结果跟进。
  用XMind写思维导图的方式设计用例更便捷,思维导图层级可以按照用例模板进行定义,方便用例评审结束后导出excel备份。
  用例自检
  整体把控用例组成,让评审讲解更清晰、有序
  针对有疑问的点罗列出来,可事先跟产品、开发讨论,确定结果后完善用例
  讨论后仍有疑问的可先做标记,评审会上抛出一起讨论。
  标注重点:【未在需求文档中明确描述&在设计测试用例过程中已同产品确认】,需要在用例评审中着重提醒开发,保持信息同步。
  ·需求疑问:在经过产品确认后,输出具体测试用例,记得同步给研发
  · 设计交互:未提供交互,需求文档未描述的功能的实际交互细节,提出讨论
  提前发出用例
  和评审人员(开发和产品)确定好具体的评审时间并提前把测试用例发给参会人员查看。
  2.2用例评审通知
  用例评审参加人员
  主要是产品、开发(客户端和后端)、测试、项目负责人、运营(如性能测试的评审)。
  约定用例评审时间、评审方式
  评审时间:根据实际情况提前约定
  评审方式:会议(具体的会议室或线上会议)、邮件等
  评审时长
  对于敏捷开发项目,建议控制在半小时以内。
  如果项目需求复杂,功能点太多,建议:
  · 对功能点划分优先级,优先评审优先级高的用例
  ·再针对疑问多的用例评审
  · 最后对于功能简单的用例可简单带过。
  3.正式评审
  3.1评审形式
  3.1.1逐条评审
  对照测试用例,从上而下,从左到右,逐条念。
  传统评审方式的特点:
  ·费时,不分主次,参会人员的热情与注意力逐渐降低
  · 整个用例评审效率低,往往讲的口干舌燥,达到的效果却是事倍功半。
  相信有过这种评审经历的同学,一定不喜欢这种方式,因为它流于形式,整个评审过程随着时间的推移,大家互动热情逐渐降低,往往效果不及预期。
  现状是业务流程较为繁长的测试用例条数较多,少则上百,多则上千,逐一讲解,不论是对开发或产品,甚至测试本身,都会出现前后文衔接不上。本着最重要的事最先做的原则,我们对用例评审形式作出如下改进:
  3.1.2逻辑概述+核心评审
  “全局流程+局部细节”的方式评审测试用例,先对核心流程、功能复杂,优先级高,疑问多的用例进行评审,再评审功能简单,优先级低的功能点。
  全局流程-逻辑概述
  借助“Xmind”思维导图,进行简要的逻辑概述,阐述用例描述的基础流程。该阶段描述后,经产品和开发确认无疑问,则进行用例评审时,可略过该部分的基础测试用例。
  比如,某某系统要实现什么功能,具体包含模块1、模块2、模块...,涉及的业务流程和数据交互有1...2...3...,是用例的评审重点,等下我们优先评审。同时我在用例设计时主要包括了哪些场景,具体有页面展示的校验、功能按钮实现的校验、页面元素必填项校验、字符类型校验、字符长度校验、异常场景校验等。(具体的页面元素、字符类型、字符长度、异常场景可以粗略带过)
  局部细节-突出核心细节用例
  除了基础业务流程外的,一些特殊场景细节的测试用例,可能影响业务流程或对公司造成损失,使用加粗/颜色标注,在用例评审时着重提醒开发。
  比如某系统的内容引用功能,被引用内容下线,对内容会产生不良的影响,这种容错性的处理逻辑的校验。
  改进后的评审方式特点:
  ·测试人员要全局了解项目目标、业务流程(想得明白才能讲得明白,可以促进测试同学多多思考)
  · 评审刚开始时,大家注意力集中,参与激情高,讨论有难度、有疑问的问题,效率高。
  · 整个评审会主次分明,有高潮有缓点,可以更高效的达到我们评审的目的。
  3.2评审原则
  评审要按用例的优先级,核心业务流优先、再按功能的复杂程度进行;
  评审过程中尽量做到,思路清晰,用最简洁的语言阐述每一个功能点;
  超过5分钟无法确定结果的问题留作会后讨论跟进。
  (正式评审过程中需要注意几个细节,如果你都做到了,相信整个评审会是非常成功的,有成就感的。)
  4.评审结束后需要做些什么事?
  总结用例评审会议纪要,包含需要作出的修改点、未确认的项和对应责任人、是否有需求变更或延期情况等。
  ·用例评审会议纪要需同步给项目组其他成员,做好信息共享。
  整理补充测试用例,把修正的内容重新整理补全。
  · 编写用例修改记录(如修正了哪些功能点,补全了哪些?等),修改后的用例重新发出供大家评审。
  会上未确定的内容,会后继续跟进,直到确定结果。
  本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理
精选软件测试好文,快来阅读吧~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号