测试聊聊，线上事故你被迫背过哪些锅
上周五晚上11点半，手机炸了。线上支付接口挂了，用户投诉塞满了群。凌晨两点排查出来，原因是上游第三方服务的证书过期了。跟我们测试半毛钱关系没有。周一复盘会，项目经理来了一句："这块测试的时候没覆盖到吧？"我当时真的气笑了。第三方证书过期，你让我在功能测试环境里怎么测？我还能跑到人家机房去看人家运维有没有续费吗？最后锅还是落测试头上了——理由是"没有做异常场景的边界测试"。行吧，你说啥就是啥。干测试这些年我算是明白了，出了事第一反应就是"测了没有"。开发写bug叫"已知问题"，产品改需求叫"业务调整"，测试没兜住叫"线上事故"。同样的代码，开发叫"实现"，产品叫"优化"，测试叫"漏测"。上次性能测试跑得好好的，上线后因为云服务商那边网络波动，接口响应慢了3秒。客户投诉了。复盘结论："性能测试没有模拟真实网络环境。"我上哪儿模拟真实网络环境去？给服务器插根网线接个不稳定的路由器吗？还有一次，自动化测试全绿，上线后发现某个老用户的数据迁移出了问题。排查半天，是数据迁移脚本有个条件判断写反了。脚本是开发写的。复盘会上的结论："自动化测试用例覆盖不全。"我真的麻了。测试这活儿，做好了没人夸你，做砸了全是你责任。就像一个守门的，球队赢了是前锋牛逼，丢球了全怪门将。现在我学乖了，每次上线前邮件发一遍：已测范围、未测范围、已知风险。出了事邮件一翻，清清楚楚。不背锅的最好方式不是多写用例，是留好证据。有人比我更惨的吗，说出来让我平衡一下。
发布于 山东
分享
评论
赞
未登录
友善发言
评论
加载中
