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