测试基础 测试用例评审

阿尔图其网 测试交流1 8字数 1022阅读3分24秒阅读模式

测试用例评审是测试活动中的一个重要环节,做好测试用例评审,可以有效的发现用例中的不足,并更好的补充,以免测试场景遗漏或者出现业务逻辑理解不一致。那么,如何做好测试用例评审呢?文章源自玩技e族-https://www.playezu.com/179528.html

做好测试用例分级,并不是所有的测试用例都需要上评审会,或者说有些用例是需要自己内部消化的。一般情况下,我会把测试用例分为三个层级:文章源自玩技e族-https://www.playezu.com/179528.html

01

页面功能用例:
主要验证的是页面功能,比如常见的数据增、删、改、查,页面显示、按键功能、布局以及简单的数据流向验证。这类用例个人建议不用上用例评审,如果小组内有较多的新人,这类的用例应该由测试负责人自行把关就好。文章源自玩技e族-https://www.playezu.com/179528.html

业务流程用例
基于用户行为,通过场景化的案例来验证系统内部各子模块的关联,确保数据及状态的流转有序、正常,对于异常数据能够正常处理或者给于明确的提示。这类用例是评审的重点,也是需求的核心内容,需要大家重点来评审的。文章源自玩技e族-https://www.playezu.com/179528.html

跨系统接口用例
随着业务的复杂性逐步增加,我们可能需要更多的和别的系统打交道,在跨系统的接口功能验证中,我们需要明确预期检查点是什么;需要考虑的异常用例分为两类,1 类是上游异常如何承接(状态是否回传、上游数据修改是否会影响到本系统等)2 是自己系统异常对上下游系统的影响。文章源自玩技e族-https://www.playezu.com/179528.html

02

如何更好的开展测试用例评审呢?笔者的经验有以下几点:文章源自玩技e族-https://www.playezu.com/179528.html

聚焦:每次用例评审不超过 1 小时,只评审核心内容及测试设计思路,不对具体的每条用例展开评审,实际上这个意义确实不大,只要测试思路没什么问题,大体上也不会有偏差;文章源自玩技e族-https://www.playezu.com/179528.html

事先准备:事先和研发及产品沟通,让他们提前阅读文档。在评审的时候,不需要拉上所有的人,只需要相关人员即可文章源自玩技e族-https://www.playezu.com/179528.html

持续反馈:测试用例并不是一成不变的,哪怕是评审完。不能让测试用例成为一个借口(很多测试人员经常对其它人说为会不在评审的时候提出来,这种做法很不推荐,别人只是帮你 check,而不是让他来替你思考)文章源自玩技e族-https://www.playezu.com/179528.html

给出行动项:需要修改的内容,及时修改并反馈,让大家有参与感,同时表示感谢。文章源自玩技e族-https://www.playezu.com/179528.html

要注意测试用例的颗粒度,在评审时,不需要逐条过,评审测试思路即可。本质上测试用例也是一个测试思维可视化的过程,除非你们的测试团队特别年轻(例如第一类的测试用例,不太适合进行大范围的评审)文章源自玩技e族-https://www.playezu.com/179528.html

03

不要用例评审当做一个负担,做好事前事中的准备,利用好这个机会,再一次方对齐需求理解的机会。可以保证大家对同一个需求的理解是一致的,避免更多可能出现的返工浪费文章源自玩技e族-https://www.playezu.com/179528.html

原文链接:https://mp.weixin.qq.com/s/_QibVb8acc4VqyGR4ITK-w文章源自玩技e族-https://www.playezu.com/179528.html

注意:本文法律责任由该作者承担,侵权请联系2523030730▷诈骗举报◁▷新闻不符◁▷我要投稿◁
  • 我们QQ群
  • QQ扫一扫
  • weinxin
  • 微信公众号
  • 公众号扫一扫
  • weinxin
评论  1  访客  1
    • 小叮当
      小叮当 9 未知系统 IANA

      我们的研发和产品说 “又到了和测试一起摸鱼的时候,他讲他的,我摸我的”

      事先和研发及产品沟通,让他们提前阅读文档。在评审的时候,不需要拉上所有的人,只需要相关人员即可
      看君一席帖,胜读十篇书 所以每次不要拉太多人,没有必要。
      很多测试人员经常对其它人说为会不在评审的时候提出来,这种做法很不推荐,别人只是帮你 check,而不是让他来替你思考

      这句说得好~开发,测试,产品 到齐了就开始,
      评审完签字画押,留痕迹。
      完事就可以随心所欲的点点点了 测试用例评审完了,然后还是根据测试点进行验收 没有过用例评审用例评审:
      1、对齐产研测三方信息,尤其是中途发生过变更的点;
      2、范围包括:模块用例、联调用例、测试物料;
      3、评审过中,说不定能发现提测前 Bug;温故而知新 大佬,写用例的时候这三种用例是一起写还是分开写呢?我们是按模块分任务,很多时候一个功能三种用例都有,所以评审都是所有用例一起评审,感觉挺浪费时间的。其实这就可以看出,大部分产品和研发是看不起测试的正解,如果说测试用例评审就是听听开发和产品的意见或者测试还有哪些地方需要测试,这不就是开发和产品教测试做事吗,反而觉得测试用例评审没有必要了建议是分开来写,因为关注的重点不一样。

    匿名

    发表评论

    匿名网友

    确定