接口测试 [跪求各位测试大佬填坑] 接口测试引发的线上事故

哆啦JJ · 2019年07月27日 · 最后由 YangPower海盐 回复于 2019年07月30日 · 3096 次阅读

在测试自动化的大前提下,越来越多的小伙伴开始深入接口测试、性能测试,在不断进步的前提下,我希望留出一点时间进行总结。在这个过程中我们往往更在意的是我使用什么工具、什么框架做的测试,使用什么手段进行的断言,提高了多少测试效率。而忽略了真正实施接口测试过程中存在的隐患问题,【重重一击】警醒大家,在做接口测试时可能也会出现线上故障(当然这只是个别情况才出现的问题)。那么在出现事故后不管是处于对用户的使用,还是对公司的业务影响都感到非常抱歉,在这里希望各位大佬能凭借久经沙场的经验帮忙填一下坑,总结一下经验~

我先填一个:
场景一:
小组内A同学,在预生产环境测试完接口后,未修改配置IP直接提交了代码(并误提交了环境配置文件),B同学拉取git代码后,未考虑到要先检查一下配置文件,直接执行了代码,导致代码中的所有接口均在预生产环境执行(可想而知,线上的配置,信息都受到了影响!!)
避免同类事故发生方案
1、执行接口测试时,一定记得检查环境配置文件是否测试环境ip,增删改的接口就不要在预发布&生产环境操作了 ~ 多人合作的项目,拉取git代码后也要检查一下配置文件在执行脚本

共收到 12 条回复 时间 点赞

增删改的接口不要在正式环境做:
需要做的是权限控制。可以在正式环境测增删改,但要控制好数据范围,最好有专门对应的测试数据进行测试,而且对正式数据进行隔离控制

Jerry li 回复

谢谢🤗 ,宝贵意见

1、测试环境管理,test、at、rt、pr、uat、prod 各种环境,最好在测试平台中统一管理,加强校验;
2、测试账号,各种环境的账号密码禁止使用一样的,这样即使地址错了,也无法通过认证;
3、服务端拦截,在测试请求(自动化、性能测试)中添加对应的标记,服务端检测到直接返回错误(具体行为可以配置,有时候会在生产环境做性能测试,但是服务端必须区别处理 mock 或者影子库)。

数据隔离;没有隔离不要在线上做

配置用 apollo 管理

没明白:事故是由于测试接口的代码导致的,还是错误的配置连同被测试的业务代码直接让测试搞到了线上导致的。

hellohell 回复

是配置被修改成 预发布环境了

我不太理解,为什么已经到了预发布环境了,还要向 git 提交代码。。这个已经跟接口测试无关了。是流程存在问题

1、项目代码应该有比如 dev、test、online 等多套配置
2、各自环境通过各自的类似 jenkins 工具进行管理,通过配置 job 进行环境区分
3、尽量不要使用 ip、服务的调用可以使用内部域名和外部域名,比如内部域名:生产和测试可以使用各自的私有 DNS 进行管理,外部域名则根据生产域名添加 test、dev 等前缀进行管理。

我们是切环境。如果不改 IP 执行会报错。

“”【重重一击】警醒大家,在做接口测试时可能也会出现线上故障(当然这只是个别情况才出现的问题)。那么在出现事故后不管是处于对用户的使用,还是对公司的业务影响都感到非常抱歉 “” 我直接说了,你这些都是废话,生产问题避免不了,不要妄想在接口,杜绝一切的问题, 现在的测试最有效的测试方式 是组合测试:测试、开发、产品、伪用户 多方联合参与项目,为项目把关的; 如果你一个部门这么有能耐 ,你咋不上天呢

产品 写的不明白、
开发技术不精练、
测试人员不精通业务、
伪用不明白 用户痛点,

为啥,项目都是一个团队在玩,不是一个人; 你这个 问题 出发点就没有在根子上寻求恰当的途径,横冲直撞,

哆啦JJ 关闭了讨论 08月22日 14:11
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册