测试用例评审会议开得好,事后甩锅没烦恼!

发表于:2022-3-17 09:45

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

 作者:李玲    来源:51Testing软件测试网原创

  我们经常会听到开发对测试抱怨说:这个问题怎么现在才测出来,这个问题怎么暴露到线上了,测试都是怎么测的?
  为了消除误解,让开发了解到底测试都覆盖了哪些内容,双方更好的配合,保障线上版本质量,测试用例的评审就显得十分重要。
  测试用例评审的参与人员是:开发、产品、测试人员。
  产品人员参与,可以方便核对测试用例是否覆盖产品需求,在评审的过程中完善产品说明文档,完善产品的逻辑。
  开发人员参与用例评审,可以从代码实现角度给出建议,防止漏测或过度测试,保证测试的全面性,减少无效测试,增加重点模块的测试。
  测试人员参与用例评审,可以审查用例是否规范,对于交互模块的用例覆盖的是否齐全。

  评审前的准备
  预审时需要提供xmind思维导图文件,xmind思维导图需要包含全部用例的设计思路及测试功能点,并重点标注出有疑问的测试点。
  在评审前一天提前发出给相关与会人,预留时间给研发和产品先过下用例的内容,留意会议侧重点。

  评审中的要求
  对于敏捷开发项目,会议时间一般建议控制在半小时以内,超过这个时间就需要中场休息了,因为人持续集中注意力的时间基本只有二十分钟。为了保障评审效果,需要采取一些有效策略。
  测试用例评审使用xmind软件,这样评审时更容易直观的看到结构树和层级关系,方便参评人员一目了然,更快的搞懂设计者要表达的意思。
  复杂的功能在开始前先概述下文档构成,然后按照文件顺序讲解。
  切记不可一马平川读到底,应该重点抓用例设计时存疑的地方,然后三方确认,这个时候预审是标注的有疑惑的地方就派上用场了。
  简言之,对功能点划分优先级,优先评审优先级高的用例,再针对疑问多的用例评审,最后对于功能简单的用例可简单带过。
  时刻记住我们用例的评审目标,不能流于形式。对于评审过程中,一时半会没有结论的问题,可以记录下来,作为会后讨论跟进的重点。
  功能举例如下:在商品详情页,进行中的拼团列表,点击“去拼团”会进入拼团详情页。
  原始版的用例如下图:

  评审内容如下:该用例考虑的点过于狭隘,基本等同于抄需求文档的。
  实际上还应考虑一些瞬时场景和一些异常情况:比如点开页面后团购结束,点击页面时小程序账号还未登录等。
  另外,因为测试用例评审和开发代码设计是同步进行的,所以在评审过程中,稍微复杂的没有把握的功能可以与开发确认实现方式。
  比如,哪些数据是从接口获取的,哪些数据是从其他页面的接口请求带过来的,哪些是前端写死的,哪些页面有必要实时刷新,哪些页面无需已进入就刷新。
  通过探讨,明确可能的bug重灾区,设计一些合理的处理方式,从根源上遏制bug的出现。

  评审后的收尾
  用例评审完成之后,需要及时整理会上的评审意见,形成会议纪要并发送邮件。
  同时测试人员需要根据会议上各方建议进行测试用例的修改完善,再将整理补充后的用例同步给项目相关人员,试具体情况确定是否有必要进行二轮评审。
  若无其他问题则将用例整理后即可定稿等待执行。该用例经过评审的集思广益之后,补充如下:

  评审的流程

  版权声明:本文出自51Testing会员投稿,51Testing软件测试网及相关内容提供者拥有内容的全部版权,未经明确的书面许可,任何人或单位不得对本网站内容复制、转载或进行镜像,否则将追究法律责任。
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

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

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

沪ICP备05003035号

沪公网安备 31010102002173号