测试用例评审是测试活动中的一个重要环节,做好测试用例评审,可以有效的发现用例中的不足,并更好的补充,以免测试场景遗漏或者出现业务逻辑理解不一致。那么,如何做好测试用例评审呢?
一、做好测试用例分级,并不是所有的测试用例都需要上评审会,或者说有些用例是需要自己内部消化的。一般情况下,我会把测试用例分为三个层级:
主要验证的是页面功能,比如常见的数据增、删、改、查,页面显示、按键功能、布局以及简单的数据流向验证。这类用例个人建议不用上用例评审,如果小组内有较多的新人,这类的用例应该由测试负责人自行把关就好。
基于用户行为,通过场景化的案例来验证系统内部各子模块的关联,确保数据及状态的流转有序、正常,对于异常数据能够正常处理或者给于明确的提示。这类用例是评审的重点,也是需求的核心内容,需要大家重点来评审的。
随着业务的复杂性逐步增加,我们可能需要更多的和别的系统打交道,在跨系统的接口功能验证中,我们需要明确预期检查点是什么;需要考虑的异常用例分为两类,1类是上游异常如何承接(状态是否回传、上游数据修改是否会影响到本系统等)2是自己系统异常对上下游系统的影响。
二、如何更好的开展测试用例评审呢?
要注意测试用例的颗粒度,在评审时,不需要逐条过,评审测试思路即可。本质上测试用例也是一个测试思维可视化的过程,除非你们的测试团队特别年轻(例如第一类的测试用例,不太适合进行大范围的评审)
三、不要用例评审当做一个负担,做好事前事中的准备,利用好这个机会,再一次方对齐需求理解的机会。可以保证大家对同一个需求的理解是一致的,避免更多可能出现的返工浪费。