假设前置数据法|全网唯一

       系统中A模块是发布岗位，B模块是岗位详情，小王测试的是A模块，小张测试的是B模块，小张在测试B模块时往往很少去考虑前置模块A产生的各种类型、各种异常不确定数据，导致了经常出现一些问题，如果小张当时考虑了A模块可能产生的所有前置数据，去测试B系统，后面就不会频繁出现一系列问题，这就是我们今天要讨论的假设前置数据法。以下只是几个思路和想法，大家可以发散思维继续扩展

一、假设边界

A模块发布岗位，岗位名必填、可输入字符长度2-10，我们需要考虑B模块岗位详情岗位名长度2、10时，显示正常显示

二、假设非必填字段

A模块发布岗位，有3个发布入口，岗位图片非必填、入口1只能传图片、入口2只能传视频、入口3视频和图片都可传，我们需要考虑B模块岗位详情岗位几种情况如下：

1 岗位详情无图片视频时展示 2 岗位详情是图片时展示 3  岗位详情是视频时展示 4、岗位详情是图片+视频时展示，所以这时需要考虑好几种情况，不只是单独看能展示就好了

三、假设字段过长、过大

1、薪资字段过大，查看B模块岗位详情，是否出现异常

2、岗位描述文字过多，查看B模块岗位详情，是否出现异常

四、假设字段异常

1、薪资字段为0，查看B模块岗位详情，是否出现异常

2、薪资字段为空，查看B模块岗位详情，是否出现异常

3、薪资字段为null，查看B模块岗位详情，是否出现异常

很多人会说，这些字段都是必填的，永远不会出现上面这些情况，我想说你错了，所有的BUG都是在某些情况下发生的，假如我这个版本发布了作息模式为做一休一的岗位，下个版本需求要把作息模式为做一休一的的类型删掉，这时如果当时没有测试这种情况，下个版本上线后，再去查看这个岗位详情，有可能就会出现异常，如果我们当时测了，最起码保证查看岗位详情不会闪退异常等。

五、假设多种状态

假设发布岗位后，岗位的状态变化会有多种状态（待审核、审核通过、审核拒绝、上架、下架、禁用、已删除）我们需要考虑当岗位为这些状态时，查看B模块岗位详情，是否正常

六、假设多种类型

A模块发布岗位，可以发布普通岗位、急招岗位，岗位的类型为普通、急招时，查看B模块岗位详情，是否正常

七、假设前置模块错误

1、假设用户未登录，进行提现操作

2、假设用户未实名认证，进行提现操作

3、假设用户未绑卡，进行提现操作

4、假设用户绑定了别人的银行卡，进行提现操作

又有人会说，没有通过1、2、3怎么可能操作提现，我想问一句，你能确定1、2、3永远是正确的，不会出BUG吗？所以前置模块、前置数据皆有可能

其实以上情况，我们完全可以通过岗位数据库去快速构造各种数据，去测试岗位详情的容错等情况，保证了岗位详情的稳定性