在做接口自动化测试时，遇到下面这个疑惑，然后再群里请教了大家，讨论如下，可以参考下：
讨论1：
上海—橙子探索测试 10:12:34
自动化测试中，提现接口一般会依赖前置功能实名认证、绑卡、设置交易密码等才能进行提现操作或依赖前置接口实名认证、绑卡、设置交易密码的响应数据（姓名、身份证、卡号、交易密码）等 ，这只是简单的实例，可能实际场景中远比这种复杂的多，所以进行提现接口测试时，需先构建完成前置功能实名认证、绑卡、设置交易密码且构建前置接口的响应数据，一般调前置功能接口或用sql构造前置功能数据两种方法，那种方法更合理方便呢？
风い 10:14:00
要保证用例独立运行的能力 只能麻烦
z 10:14:56
做成场景测试用例
天 10:19:08
上海—橙子探索测试 自动化测试中，接口4依赖前置接口顺序或数据1 2 3 ，接口5依赖前置接口顺序或数据1 2 3 4，（比如：提现 可能需要先设置登录密码、再实名认证，才能提现），所以接口4时，需要构建前置接口顺序或数据1 2 3，接口5时，需要构建前置接口顺序或数据1 2 3 4 …… 这样的话，每个接口里都存在大量重复前置sql侯建，感觉太麻烦了，有什么好的方法吗？
@上海—橙子探索测试 如果测试环境中，数据不会被清理，可以把参数写死。否则的话，只能通过接口来造前置条件的数据，来保证脚本的健壮性
上海—橙子探索测试 10:39:53
@天 嗯 我目前是通过sql构建数据的 用完又清掉 所以导致每个用例都要重新构造
上海—橙子探索测试 10:40:17
@z 场景的话那就是场景自动化了 不是单接口自动化
翡翠 10:41:08
直接调接口
翡翠 10:41:17
不行上容器，开虚拟数据库
翡翠 10:41:20
随用随删
上海—橙子探索测试 10:41:46
调接口不稳定吧 我觉得还不如sql吧
翡翠 10:42:04
的确不如sql稳定
翡翠 10:42:19
所以我说，不行上容器
翡翠 10:42:25
随用随删
天 10:43:44
你们在用docker吗
翡翠 10:43:59
我在弄
翡翠 10:44:16
还没弄好
天 10:44:59
上海—橙子探索测试 @天 嗯 我目前是通过sql构建数据的 用完又清掉 所以导致每个用例都要重新构造
@上海—橙子探索测试 你的sql会向服务器插入数据吗
天 10:46:34
我之前就想过用docker来实现，先把数据添加到docker中的数据库中。跑自动化时就切换到docker里面的数据库，执行完毕后就切换到测试环境的数据库
z 10:46:58
@上海—橙子探索测试 你这本来有就依赖关系的，除非你再数据库维护一组数据 专门用于测试这个接口，执行完毕后把数据还原
天10:48:41
z @上海—橙子探索测试 你这本来有就依赖关系的，除非你再数据库维护一组数据 专门用于测试这个接口，执行完毕后把数据还原
@zx 我以前也是这么想的，但是没有实现
zz 10:49:22
@翡翠 不行上容器，开虚拟数据库
天锥树 10:49:23
数据都是在数据库中准备好的，直接跑接口来验证逻辑，比较麻烦的是维护数据
zz 10:49:26
这是啥意思啊
天 10:49:46
什么是虚拟数据库啊
z 10:50:30
把业务熟悉后，维护起来也不是很难
翡翠 10:50:54
开个容器，容器里面有数据
翡翠 10:51:09
因为数据库是假的，你随便弄
翡翠 10:51:19
不考虑环境污染那些
翡翠 10:51:23
反正最后都要删
z 10:51:54
数据不一定要存储在数据库，可以用文本，执行前写入进去就好
z 10:52:02
执行完毕后，再删掉
zz 10:56:48
意思是我们自己copy一套生产坏境的数据库
zz 10:57:10
跑case的时候 把业务服切到虚拟数据库来？
翡翠 10:57:49
case就在容器里面炮
翡翠 10:57:51
跑
翡翠 10:57:58
具体你看一下docker
上海—橙子探索测试 10:58:24
@天 各种sql都会的
上海—橙子探索测试 10:59:13
增删改查
zz 11:05:19
在哪里跑有什么没关系呀
zz 11:05:31
你总得连服务器啊
天 11:15:23
上海—橙子探索测试 @天 各种sql都会的
@上海—橙子探索测试 搞那么多sql，还真不如调用接口来造数据。万一sql错了，出现的问题，开发肯定不认，而且还会是觉得浪费他们的开发时间。如果接口造的数据，有问题，绝对是代码的问题，开发跑不脱
天11:15:55
反正接口之前有依赖的自动化很麻烦
像风 11:17:28
sql性能高得多
像风 11:17:43
开发给你sql就行了啊
上海—橙子探索测试 11:19:11
嗯 各有利弊吧
讨论2：
橙子：接口自动化中，前置数据大家都是怎么准备的
橙子：我发现前置数据又是一个大头
H：前置数据？是指？传参？
橙子：比如要提现是不是要登录、实名认证-审核、绑卡-审核、充值
橙子：这只是一个示例 也许实际项目中更复杂 涉及多个系统
H：这个是 挺复杂的一个，而且还是必须的，接口之间存在很强的依赖
橙子：我们目前1个项目涉及3个系统交互的，我目前走的sql，单发现，走sql需要对业务逻辑、表关联需要非常数据，且sql之间页存在依赖，有点麻烦
H：1.从接口关联方面做，2.通过sql方面做
橙子：感觉还是sql简单点
H：嗯嗯，如果表关联很强，不建议走sql方面，除非是 把涉及的表关系理的很清楚
橙子：是的 要不然数据容易错，且如果表字段、业务一旦发生变化，sql随时需要改动
H：不过这些如果发生变化，那对应的 接口 也会有变更的，从接口方面走，也的改
由以上总结得出：
1、调业务接口构造前置功能数据，更合理，避免出现错误数据导致测试结果的不准确、接口会被重复调用多次
封装被调用的独立方法，需要时直接调用，判断是否成功，如果成功，进行响应数据提取进行下一步接口用例测试；如果失败，直接报出失败的接口，不进行下一步接口用例测试
2、使用sql操作构造前置功能数据，不推荐使用，容易出现数据错误导致测试结果不准确或不稳定性、对业务熟悉度，表关联关系熟悉度要求高
根据业务关系、表之间关系封装构造前置sql和数据清理sql，再用例执行前进行前置功能数据构造调用和执行后进行测试数据清理还原，保证用例可重复执行
3、根据实际情况合理选取
由于只是针对提现接口进行测试，所以重点不关心实名认证、绑卡、设置交易密码模块，故1和2都可以
大家有更好的方法可以私发我，感谢！！！
