如何评审测试用例

简介: 经验

测试用例评审是测试活动中的一个重要环节,做好测试用例评审,可以有效的发现用例中的不足,并更好的补充,以免测试场景遗漏或者出现业务逻辑理解不一致。那么,如何做好测试用例评审呢?


01


做好测试用例分级,并不是所有的测试用例都需要上评审会,或者说有些用例是需要自己内部消化的。一般情况下,我会把测试用例分为三个层级:


页面功能用例:

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


业务流程用例:

基于用户行为,通过场景化的案例来验证系统内部各子模块的关联,确保数据及状态的流转有序、正常,对于异常数据能够正常处理或者给于明确的提示。这类用例是评审的重点,也是需求的核心内容,需要大家重点来评审的。


跨系统接口用例:

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


02


如何更好的开展测试用例评审呢?笔者的经验有以下几点:

聚焦:每次用例评审不超过 1 小时,只评审核心内容及测试设计思路,不对具体的每条用例展开评审,实际上这个意义确实不大,只要测试思路没什么问题,大体上也不会有偏差;


事先准备:事先和研发及产品沟通,让他们提前阅读文档。在评审的时候,不需要拉上所有的人,只需要相关人员即可


持续反馈:测试用例并不是一成不变的,哪怕是评审完。不能让测试用例成为一个借口(很多测试人员经常对其它人说为会不在评审的时候提出来,这种做法很不推荐,别人只是帮你 check,而不是让他来替你思考)


给出行动项:需要修改的内容,及时修改并反馈,让大家有参与感,同时表示感谢。


要注意测试用例的颗粒度,在评审时,不需要逐条过,评审测试思路即可。本质上测试用例也是一个测试思维可视化的过程,除非你们的测试团队特别年轻(例如第一类的测试用例,不太适合进行大范围的评审)


03


不要用例评审当做一个负担,做好事前事中的准备,利用好这个机会,再一次方对齐需求理解的机会。可以保证大家对同一个需求的理解是一致的,避免更多可能出现的返工浪费。


目录
相关文章
|
15小时前
|
测试技术
你还在写测试用例吗
你还在写测试用例吗
|
15小时前
|
测试技术
面试题4:什么样的测试用例是合格的测试用例
面试题4:什么样的测试用例是合格的测试用例
|
15小时前
|
测试技术 数据库
怎么样写出好的测试用例?
怎么样写出好的测试用例?
|
9月前
|
测试技术 数据安全/隐私保护 UED
【软件测试】如何设计测试用例?
设计测试用例的万能公式: 功能测试+性能测试+界面测试+兼容性测试+易用性测试+安全测试
|
12月前
|
敏捷开发 测试技术 数据安全/隐私保护
【软件测试】测试用例的设计
针对没有需求的案例,我们可以从如下几个方面思考来设计测试用例
|
搜索推荐 测试技术 UED
需求评审那些事
需求评审那些事
|
测试技术
关于需求评审和讲解的一些思考
上图为[产品迭代开发协作流程],上次聊了一下关于 Code Review 的一些思考。 在上面的流程中,需求评审通过后,要产出最终的需求文档、原型等交付物,还要对本次需求封版;在测试阶段的补充需求的处理方式;上线后记录或反馈的问题列入下一版的迭代。 可是,流程中都是比较理想的状态,现实工作中并没有达到设想的目标。作为一个开发人员,分别站在产品经理的角度和开发人员的角度分析一下问题的可能原因。
测试思想-文档评审 关于需求评审
测试思想-文档评审 关于需求评审
55 0
|
数据可视化 测试技术
测试用例评审如何开展
测试用例评审如何开展
135 0
测试用例评审如何开展
|
敏捷开发 安全 中间件
测试用例,写不写?
测试用例,写不写?
72 0
测试用例,写不写?