问答 | 接口自动化测试数据怎么来？涉及资金的接口如何在线上回归？

最近，有一位小伙伴提出一个问题：

目前在用pytest做接口自动化，因为一开始就想要把这套接口自动化用到生产环境，所以考虑的问题比较多一点点。

请问：

1.在做接口自动化的过程中，参数的数据应该从哪里来比较好。是写死（这种切换一下环境就不能用了，不太好对吧？），还是从数据库里提取？（那如果数据库里有脏数据，会造成测试接口返回信息不准确吧？

2.如果是动态数据，比如需要上一个接口查询商品，下一个接口添加购物车。如果上一个接口出问题，那么下一个接口也跟着出问题。这种接口传参怎么样比较好呢？

3.请问你们已经落地的接口自动化，是在测试环境跑还是预发布、生产环境呢？因为感觉做出来只在测试环境跑，发现不了线上的问题。整个接口自动化意义不大。

4.如果在线上跑接口自动化，涉及到钱的接口，要怎么去跑呢？

观点一

以下纯个人经验：

1.在做接口自动化的过程中，参数的数据应该从哪里来比较好。是写死（这种切换一下环境就不能用了，不太好对吧？），还是从数据库里提取？（那如果数据库里有脏数据，会造成测试接口返回信息不准确吧？）

——从用例中生成最好，其次是从环境的数据库里提取。

2.如果是动态数据，比如需要上一个接口查询商品，下一个接口添加购物车。如果上一个接口出问题，那么下一个接口也跟着出问题。这种接口传参怎么样比较好呢？

——就照常传就好了。多接口串联的用例，本身就是必须要每个接口都 OK 才能持续走的。

3.请问你们已经落地的接口自动化，是在测试环境跑还是预发布、生产环境呢？因为感觉做出来只在测试环境跑，发现不了线上的问题。整个接口自动化意义不大。

——一般在测试环境。发现线上问题不是接口自动化这项工作的的职责，是监控以及巡检（也叫拨测，就是对着线上跑部分不会影响到线上用户的自动化用例）的职责。

4.如果在线上跑接口自动化，涉及到钱的接口，要怎么去跑呢？

——不跑。通过监控实际线上接口的调用情况，而非用接口自动化主动调用，来快速发现问题。

观点二

非常不建议自动化测试在生产环境跑，根据我的经验，自动化测试，基本不会被测试......你还想在线上跑涉及到钱的接口，这就是传说中的吃雷公屙火闪吧~

楼主又问：“那是否会用到做线上监控呢？那不也是在线上跑？”

回答：监控和自动化测试完全是两码事。。。。

观点三

我们做了生产的服务监控，其实只是监控服务，周期啊 频率啊 自己控制，不要产生业务数据，不要给生产增加负担。

目前我是一分钟轮训查询一个服务状态的，遇到服务异常，调云平台的电话服务打电话过来

观点四

提出这种问题，看来楼主还没遭受过社会的毒打。千万不要自作主张动生产数据，无论什么目的，即使领导让你动，也要获取多方确认（领导、运维、业务等）后再实施。不然出了问题锅只能自己背，小测试的抗风险能力差，如果遇到这种问题，基本就是走人了，慎重！

观点五

以下亦纯个人经验：

1.除了配置数据，业务数据都是动态的：

我们是直接前置时通过调用相关接口生成，或者插入数据库生成相关数据，然后后置操作进行删除。这样一般不会有脏数据

2.遵循原则：测试用例之间保持独立性，因此各个用例不会关联影响。

至于多接口串联用例，自然必须每个接口都要正确

3.参考上述大佬回答就行

4.同样参考上述大佬回答，千万别线上跑！实在要跑，就拿一些合适的跑。比如我们的业务核心功能就是各种各样的检索，就算程序挂了，也不会造成脏数据，至于影不影响线上性能，那就另说。

观点六

1.参数数据主要来源肯定就是你的用例设计，其他来源都是补充。补充来源可以是线上流量（access log 里面可以抽取）、可以是埋点上报、也可以是数据库数据。但是关键问题是补充来源的数据是否全部可行，要加什么筛选标准，肯定不是随便一条数据就能拿来直接用，一方面有些数据涉及用户隐私安全，一方面有些数据不完整，一方面有些数据根本没权限拿，所以很多时候最关键的就是搞明白筛选标准和你的测试范围，不是万能的。

”是写死（这种切换一下环境就不能用了，不太好对吧？）..."

没看懂你说的写死是什么意思，是人为确定的参数？为什么切一下环境就不能用呢？能不能按照不同环节做兼容？还是说你的环境本身就有问题？

2.上个接口出问题用例应该直接报错结束吧，没什么特别的方法。上游你的控制不稳定，自然就不用想着下游能好过。这个解决的下手点不在于接口怎么传参，而是确定前置条件有无满足。

3.全量用例是在测试环境跑，我们内部的预发布约等于生产环境，生产环境只跑很小一部分，而且都是读接口。在线上跑写接口就是给业务加脏数据污染，纯纯地坑研发，不仅可能发现不了线上问题，甚至可以引入问题让别人排查半天。这里的建议是把思路打开一些，发现线上问题除了接口自动化（巡检）外还有很多，比如监控、用户反馈跟进，更牛逼一点可以是舆情监控等手段。

4.基本原则是涉及到钱就别在线上去跑自动化，出问题就是事故，老老实实线下自动化或者线上手工验证，不差那么点工作量。一方面钱相关的一般是线下有mock，自动化会比较安全倒还好，但是线上没有mock，第三方支付也很少会给你在线上开这样的测试口子，所以就别去较劲，要是自动化把别人的接口打挂了还要担责；另一方面，如果线下测完了没问题，线上还出问题，我觉得可以想想为什么两者的结果不一致，再去尝试排除这些差异点，至少保证己方是没责任的。建议先了解一下依赖的财经支付方在线上有什么限制再考虑。

对于这个问题

你有什么想说的

最后： 下方这份完整的软件测试视频学习教程已经整理上传完成，朋友们如果需要可以自行免费领取【保证100%免费】

 这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！