做接口测试有个难点一直没有找到很好的解决方案,就是针对业务流程非复杂的末端的接口测试逻辑时,依赖的数据应该通过什么方式准备。
例如:
有一个单据,需要经过【处理 1】-【处理 7】后,操作【处理 8】进行完结这笔单据,并且单据的处理 1-处理 7 操作从前端操作上是不可跨越的。
我需要测试【处理 8】这个接口的业务逻辑的时候,需要单据已经完成了【处理 1】-【处理 7】的操作,且经过【处理 8】后的单据是不可逆,不能再利用的。
问题:
那么我的测试【处理 8】这个接口的时候,数据准备应该如何?
试过的方案:
方案 1
调用前置接口【处理 1】-【处理 7】,但是流程过于长,前置接口有出问题的风险,且逻辑分支比较多,通过此方法造数据可能造数据的调用代码远远大于实际测试【处理 8】接口的数据。
方案 2
先页面造好数据,进行数据库 dump,由于外部因素,开发这边不能给出一个接口涉及掉的表结构等等,所以整个数据库 dump,但是存在各个业务可能同时由不同的人触发,整个库 dump 就不能多线程执行用例,不灵活,而每个业务接口一个库也不现实。

求助,有什么好的方案?

追加
1、说明一下另一个不太愿意调用接口去造数据的原因是,现在业务中例如单据这种都是要求的 id,包括单据中的一些属性值都是需要传值 id,然后和公司账号相关联的,还考虑到环境的问题,例如我测试环境和灰度环境,数据库是两套,所以一套入参不能满足两个环境运行,可能我还是想要脱离这个限制吧,让这个接口测试代码是可复用的,而不是一旦换了环境或者数据库因为某种原因重置了,一些前置的操作还需要手动去执行。
2、不知道大家现在服务架构是如何的,我们现在是在切换到 vue+springboot 的模式进行中,会有一个 service 和 controller,我的理解上,要做接口测试,应该是针对 controller 层的,但是实际要求我做 service 层的接口测试,会有点迷茫吧,就是一个 service 接口可能支持了好多 controller 的,实际上 service 接口的入参真的有点庞大了,让我在对入参组合的测试上非常的懵,不知道界限是什么。


↙↙↙阅读原文可查看相关链接,并与作者交流