接口测试 [跪求各位测试大佬填坑] 接口测试引发的线上事故
在测试自动化的大前提下，越来越多的小伙伴开始深入接口测试、性能测试，在不断进步的前提下，我希望留出一点时间进行总结。在这个过程中我们往往更在意的是我使用什么工具、什么框架做的测试，使用什么手段进行的断言，提高了多少测试效率。而忽略了真正实施接口测试过程中存在的隐患问题，【重重一击】警醒大家，在做接口测试时可能也会出现线上故障（当然这只是个别情况才出现的问题）。那么在出现事故后不管是处于对用户的使用，还是对公司的业务影响都感到非常抱歉，在这里希望各位大佬能凭借久经沙场的经验帮忙填一下坑，总结一下经验~
我先填一个：
场景一：
小组内A同学，在预生产环境测试完接口后，未修改配置IP直接提交了代码（并误提交了环境配置文件），B同学拉取git代码后，未考虑到要先检查一下配置文件，直接执行了代码，导致代码中的所有接口均在预生产环境执行（可想而知，线上的配置，信息都受到了影响！！）
避免同类事故发生方案
1、执行接口测试时，一定记得检查环境配置文件是否测试环境ip，增删改的接口就不要在预发布&生产环境操作了 ~ 多人合作的项目，拉取git代码后也要检查一下配置文件在执行脚本
增删改的接口不要在正式环境做：
需要做的是权限控制。可以在正式环境测增删改，但要控制好数据范围，最好有专门对应的测试数据进行测试，而且对正式数据进行隔离控制
，宝贵意见
1、测试环境管理，test、at、rt、pr、uat、prod 各种环境，最好在测试平台中统一管理，加强校验；
2、测试账号，各种环境的账号密码禁止使用一样的，这样即使地址错了，也无法通过认证；
3、服务端拦截，在测试请求（自动化、性能测试）中添加对应的标记，服务端检测到直接返回错误（具体行为可以配置，有时候会在生产环境做性能测试，但是服务端必须区别处理 mock 或者影子库）。
数据隔离；没有隔离不要在线上做
配置用 apollo 管理
没明白：事故是由于测试接口的代码导致的，还是错误的配置连同被测试的业务代码直接让测试搞到了线上导致的。
感觉楼主的解决方案，不好保障是否做到位？比如要求大家都检查配置文件的 ip 是否正确，如果刚好这次是一个新入职的同学，不知道或者不记得要这么做，问题是不是还会存在？有什么手段检查大家是否都有做到位，甚至达到做不到位就无法进行线上/预发布环境的接口测试的地步，杜绝问题的再次发生？
个人建议，可以从这几个方面做：
- 对于生产、预发布这类直接对接线上数据的环境，相关配置数据都通过环境变量配置，不允许写在 git 仓库里。同时配置读取时，若有同名环境变量配置，优先读取环境变量值。可以参考下 spring boot config 的设定。杜绝由于没检查配置导致跑到生产/预发布环境的问题（用的配置就不是 git 仓库别人提交的配置）
- 单独设定另外的 jenkins job ，job 中设定好第一点提到的环境变量。大部分测试人员不需要，也不应该知道生产/预发布的配置。job 配置权限只有组长级别有，固定写死只跑生产/预发布不测试环境，且测试集名称固定。禁止在用户本地执行此类测试（手工操作是最不可控的），可以通过 ip 限制等手段封禁，只允许 jenkins 服务器访问生产/预发布环境。杜绝用户本地随意修改执行，影响到生产/预发布。也杜绝 jenkins job 被任意修改为执行不能在线上执行的测试集的问题
- 线上/预发布环境的测试集，和平时的测试集区分，且每次修改必须通过组长审核通过。如果脚本是 git 仓库管理的，可以使用 gitlab 的 protect 分支特性，jenkins job 只执行 master 中的用例，而 master 分支是 protect 分支，若要变更，只有组长级别有权限。可以通过 MR 让组长只审核，不用自己改代码。杜绝线上/预发布环境的测试集被错误加入线上不能运行的用例的问题
上述几个如果做到了的话，那么如果一个测试人员要让一个本不该在生产环境跑的用例，到生产环境跑，必须拿到 jenkins job 的配置权限并改为自己的用例集/绕过组长往线上用例集中加入不该加入的用例，除非故意做，否则不可能由于粗心达到这个目标。这样是否能更有效地避免同类问题发生？
我不太理解，为什么已经到了预发布环境了，还要向 git 提交代码。。这个已经跟接口测试无关了。是流程存在问题
1、项目代码应该有比如 dev、test、online 等多套配置
2、各自环境通过各自的类似 jenkins 工具进行管理，通过配置 job 进行环境区分
3、尽量不要使用 ip、服务的调用可以使用内部域名和外部域名，比如内部域名：生产和测试可以使用各自的私有 DNS 进行管理，外部域名则根据生产域名添加 test、dev 等前缀进行管理。
我们是切环境。如果不改 IP 执行会报错。
“”【重重一击】警醒大家，在做接口测试时可能也会出现线上故障（当然这只是个别情况才出现的问题）。那么在出现事故后不管是处于对用户的使用，还是对公司的业务影响都感到非常抱歉 “” 我直接说了，你这些都是废话，生产问题避免不了，不要妄想在接口，杜绝一切的问题， 现在的测试最有效的测试方式 是组合测试：测试、开发、产品、伪用户 多方联合参与项目，为项目把关的； 如果你一个部门这么有能耐 ，你咋不上天呢
产品 写的不明白、
开发技术不精练、
测试人员不精通业务、
伪用不明白 用户痛点，
为啥，项目都是一个团队在玩，不是一个人； 你这个 问题 出发点就没有在根子上寻求恰当的途径，横冲直撞，
