目前在用 pytest 做接口自动化，因为一开始就想要把这套接口自动化用到生产环境，所以考虑的问题比较多一点点。
我好像在 testhome 看过类似的文章，说测试数据分几类，比如公共通用的数据、动态数据（需要上一个接口返回才能使用）、死数据等等。
但是我搜索了下，还有看下自己收藏的文章，没有找到。
如果看到该问题，有类似的文章也可以贴下链接给我参考。感谢
请问：
1、在做接口自动化的过程中，参数的数据应该从哪里来比较好。是写死（这种切换一下环境就不能用了，不太好对吧？），还是从数据库里提取？（那如果数据库里有脏数据，会造成测试接口返回信息不准确吧？）
2、如果是动态数据，比如需要上一个接口查询商品，下一个接口添加购物车。如果上一个接口出问题，那么下一个接口也跟着出问题。这种接口传参怎么样比较好呢？
3、请问你们已经落地的接口自动化，是在测试环境跑还是预发布、生产环境呢？因为感觉做出来只在测试环境跑，发现不了线上的问题。整个接口自动化意义不大。
4、如果在线上跑接口自动化，涉及到钱的接口，要怎么去跑呢？
非常不建议自动化测试在生产环境跑，根据我的经验，自动化测试，基本不会被测试。。。你还想在线上跑涉及到钱的接口，这就是传说中的吃雷公屙火闪吧
吃雷公屙火闪 - 胆大包天
以下纯个人经验：
1、在做接口自动化的过程中，参数的数据应该从哪里来比较好。是写死（这种切换一下环境就不能用了，不太好对吧？），还是从数据库里提取？（那如果数据库里有脏数据，会造成测试接口返回信息不准确吧？）
——从用例中生成最好，其次是从环境的数据库里提取。
2、如果是动态数据，比如需要上一个接口查询商品，下一个接口添加购物车。如果上一个接口出问题，那么下一个接口也跟着出问题。这种接口传参怎么样比较好呢？
——就照常传就好了。多接口串联的用例，本身就是必须要每个接口都 OK 才能持续走的。
3、请问你们已经落地的接口自动化，是在测试环境跑还是预发布、生产环境呢？因为感觉做出来只在测试环境跑，发现不了线上的问题。整个接口自动化意义不大。
——一般在测试环境。发现线上问题不是接口自动化这项工作的的职责，是监控以及巡检（也叫拨测，就是对着线上跑部分不会影响到线上用户的自动化用例）的职责。
4、如果在线上跑接口自动化，涉及到钱的接口，要怎么去跑呢？
——不跑。通过监控实际线上接口的调用情况，而非用接口自动化主动调用，来快速发现问题。
搬个板凳来看看
我们做了生产的服务监控，其实只是监控服务，周期啊 频率啊 自己控制，不要产生业务数据，不要给生产增加负担
目前我是一分钟轮训查询一个服务状态的，遇到服务异常 调云平台的电话服务打电话过来
以下亦纯个人经验：
1、除了配置数据，业务数据都是动态的：
我们是直接前置时通过调用相关接口生成，或者插入数据库生成相关数据，然后后置操作进行删除。这样一般不会有脏数据
2、遵循原则：测试用例之间保持独立性，因此各个用例不会关联影响。
至于多接口串联用例，自然必须每个接口都要正确
3、参考上述大佬回答就行
4、同样参考上述大佬回答，千万别线上跑！实在要跑，就拿一些合适的跑。比如我们的业务核心功能就是各种各样的检索，就算程序挂了，也不会造成脏数据，至于影不影响线上性能，那就另说
提出这种问题，看来楼主还没遭受过社会的毒打。千万不要自作主张动生产数据，无论什么目的，即使领导让你动，也要获取多方确认（领导、运维、业务等）后再实施。不然出了问题锅只能自己背，小测试的抗风险能力差，如果遇到这种问题，基本就是走人了，慎重！
数据库里有脏数据，会造成测试接口返回信息不准确吧? 这个是指研发环境存在开发过程中的脏数据吗？
1、在做接口自动化的过程中，参数的数据应该从哪里来比较好。是写死（这种切换一下环境就不能用了，不太好对吧？），还是从数据库里提取？（那如果数据库里有脏数据，会造成测试接口返回信息不准确吧？）
参数数据主要来源肯定就是你的用例设计，其他来源都是补充。补充来源可以是线上流量（access log 里面可以抽取）、可以是埋点上报、也可以是数据库数据。但是关键问题是补充来源的数据是否全部可行，要加什么筛选标准，肯定不是随便一条数据就能拿来直接用，一方面有些数据涉及用户隐私安全，一方面有些数据不完整，一方面有些数据根本没权限拿，所以很多时候最关键的就是搞明白筛选标准和你的测试范围，不是万能的。
【是写死（这种切换一下环境就不能用了，不太好对吧？）】没看懂你说的写死是什么意思，是人为确定的参数？为什么切一下环境就不能用呢？能不能按照不同环节做兼容？还是说你的环境本身就有问题？
2、如果是动态数据，比如需要上一个接口查询商品，下一个接口添加购物车。如果上一个接口出问题，那么下一个接口也跟着出问题。这种接口传参怎么样比较好呢？
上个接口出问题用例应该直接报错结束吧，没什么特别的方法。上游你的控制不稳定，自然就不用想着下游能好过。这个解决的下手点不在于接口怎么传参，而是确定前置条件有无满足
3、请问你们已经落地的接口自动化，是在测试环境跑还是预发布、生产环境呢？因为感觉做出来只在测试环境跑，发现不了线上的问题。整个接口自动化意义不大。
全量用例是在测试环境跑，我们内部的预发布约等于生产环境，生产环境只跑很小一部分，而且都是读接口。在线上跑写接口就是给业务加脏数据污染，纯纯地坑研发，不仅可能发现不了线上问题，甚至可以引入问题让别人排查半天。这里的建议是把思路打开一些，发现线上问题除了接口自动化（巡检）外还有很多，比如监控、用户反馈跟进，更牛逼一点可以是舆情监控等手段
4、如果在线上跑接口自动化，涉及到钱的接口，要怎么去跑呢？
基本原则是涉及到钱就别在线上去跑自动化，出问题就是事故，老老实实线下自动化或者线上手工验证，不差那么点工作量。一方面钱相关的一般是线下有 mock，自动化会比较安全倒还好，但是线上没有 mock，第三方支付也很少会给你在线上开这样的测试口子，所以就别去较劲，要是自动化把别人的接口打挂了还要担责；另一方面，如果线下测完了没问题，线上还出问题，我觉得可以想想为什么两者的结果不一致，再去尝试排除这些差异点，至少保证己方是没责任的。建议先了解一下依赖的财经支付方在线上有什么限制再考虑
公司用的 apifox 跑接口，我一般用的是后置操作提取变量