正常情况下,业务方来了一个需求,产品会将需求分解,设计成需求文档,开发也会根据这个设计对应的接口文档,而测试,需要做的是结合需求文档、接口文档以及自己目前对业务的了解,设计各种场景,考虑目前这样的设计,是否存在弊端,并且进一步明确一些不确定的点。
一:多与产品沟通
在某种维度上,测试是最了解业务的人,而且测试考虑问题的角度,应该是从客户的角度出发,这与产品的角度所类似。所以,为了更好的了解需求,也为了能及早的发现一些设计上的问题,测试应该与产品保持密切的联系。就产品需求,多与产品沟通,明确业务背景、需求愿景、具体场景、实现逻辑等各个点。一个研发团队,与产品沟通最多的人,不应该是开发,而是测试。
二:新增功能不一定是测试的重难点
一份测试用例设计,一次需求剖析,我们首先要明确的是这次测试,哪些点是重点,哪些点是可以后期优化的不是这么重要的。
如果这是一个完全的新产品,那么本次的改动点,都是重点。但是更多的时候,我们拿到的是在现有产品上的一些更新优化,有时候,新的功能就不一定是重点了。
1:向“钱”看齐,公司利益至上
举个例子,本次在车辆出库操作的时候,增加了一个可以批量的动作,方便业务人员操作。那么,这个批量的操作里面,那些极限的可能发生问题的场景,其实根据发生的概率,不是那么的重要,反而,这个车不能出库的车被出库了,或者说车费用没算对&#