开发的功能不都是经过上线测试，为什么上线后还会那么多 Bug ？

你是否也经过这样的灵魂拷问：「开发的功能不都是经过上线测试的吗？为什么上线后还会那么多 Bug ？」。

大家明明都很努力，为什么「输出」的结果没有更进一步？今天我们就水一水这个「狗血」话题，究竟是谁个锅？

本篇只是毫无意义的「故事」，内容纯属「虚构」，如有雷同，自己「反思」。

对于这个话题，我想用一个「虚构」的故事来介绍下，这个故事里我有一个「朋友」，他在某电商项目组，当时恰逢经历了公司内部的「双十一需求立项」：

立项时

老板：“这次的需求很简单，主要就是参考去年 TB 的预热活动来走，核心就是提高客单量和活跃，具体细节你们和产品沟通就行”

产品：“TB 去年的活动预热大家应该都了解吧，我们这次主要就是复刻一个类似的活动，时间一个月，具体有***，总的来说，双十一活动一定要准时上线，这次运营那边投入很多经费，需求方面我会把控好，核心围绕老板的思路，细节大家可以看文档，基本就是这些内容，一个月应该够的，大家没问题吧？”

开发：“没问题，保证完成任务”

3 天后：

老板：“我刚看了 JD 好像推出了一个不错的小游戏，我觉得这个可以导入到这边活动里，这样可以提高用户的活跃，用户活跃了，消费自然就起来了”

开会

产品：“鉴于老板的意见，我觉得 JD 的这个游戏活动效果可以提升我们的复购，所以我计划在原本需求基础上增加一个支线活动。

产品：“大家不要紧张，支线会和当前主线同步开发，支线活动比较灵活，不对账号级别做限制，另外「设计」那边看下入口放哪里比较合适。”

开发：“上线时间还是没变吗？”

产品：“双十一日期会变吗？老板说了大家抓紧点，功能不多，时间还是够的”

10 天后：

老板：“我刚和x总沟通了下，他觉得我们的活动少了互动，不利于留存，你看下怎么处理”

开会

产品：“经过这几天和老板的探讨，我们发现这次活动少了一些互动性，必须增加一些交互游戏，这样才能提升日活和用户体验。

产品：“这样吧，这部分功能也是比较迫切，我知道任务比较重，但是为了这次能取到较好成果，大家加把劲，接下来周末幸苦下大家，先不休假，后面调休补回来，具体需求大家可以看文档，有一些调整，不多，时间还是够的”

开发：“。。。。”

14 天后：

老板：“我看大家工作的热情还是可以的，刚运营提了可以增加一些视频支持，我觉得这是一个很好的意见”

开会

产品：“目前看起来我们的开发进度还比较乐观，运营的同学说了他们录制了一些活动视频，我看了还不错，就在主会场增加一些视频播放的功能吧，细节你们直接和设计讨论下”

产品：“这个应该不难吧，把分享和下载加上，视频播放这么基础的东西，应该不耽误事，我看网上开源服务就挺多的。”

开发：“。。。。”

20 天后：

老板：“我刚去开发那里看了下效果，感觉分会场的效果挺好的，做支线太可惜了，给他加回主流程里”

开会

产品：“老板那边觉得分会场的效果更好，让我们把分会场的效果做到主会场里的核心交互里，分会场部分的逻辑就不要了，入口也取消。

产品：“大家不要激动，都是现成的东西，改一改很快的，不过项目进度目前看来确实起有点拉垮，接下来大家晚上多幸苦点，我们晚上11点后再下班，我申请给大家报销打车的费用”

开发：“。。。。”

23 天后：

老板：“整体效果我觉得可以，就是好像有一些糙，你们再过一过，另外大家开个会统一下目标，看看能不能有新的补充”

产品：“可以的，过去我们也一直在开会对齐，基本每两天都会对齐一次”

开会

产品：“我和设计对了下，发现有一些细节可以优化，比如一些模块的颜色可以细调一下，还有这些按键的动画效果也加上，我知道工期紧张，所以我从「隔壁」项目组借了几个开发资源，未来一周他们可以帮助大家缓解下压力”

开发：“。。。。”

28 天后：

开会

产品：“好了，项目可以提测了，相信之前测试也陆续介入跟进了需求，应该问题不大，目前看起来「燃尽图」还可以，测试完了尽快上线，老板那边也在催了”

测试：“不行啊，今天走了用例，一堆问题，而且提测版本怎么和用例还有需求文档不一致，这个提测的版本开发是不是自己没做过测试啊，一大堆问题，根本测不下去，这样我们很难做”

产品：“这个我来沟通，开发接下来这几天大家就不要回家了，马上活动上线，一起攻克难关”

产品：“我也理解大家很努力了，但是这次提测的质量确实不行，你们还是要自己多把把关，不能什么问题都等到 QA 阶段才暴露，这样不利于项目进度，需求一直都很明确，大家把 Bug 尽可能修一修，有什么问题我们及时沟通，尽快解决，敏捷开发”

开发：“。。。。”

上线前一天晚上 10 点：

开会

测试：“不行，还有 20 几个问题没有确认，这种情况我不能签字，上线了有问题谁负责。”

产品：“一些问题其实并不影响正常使用，目前主流程应该没问题，让开发把 P0 的两个问题修了之后先上线，剩下的在运营过程中逐步更新就好了，有问题让运营先收集和安抚”

开发：“上线了脏数据不好弄，会有一些账号同步的问题，而且用户等级可能还有坑”

产品：“没什么不好弄的，到时候有问题的用户让运营做个标志，接下来小步快跑修复就好了，时间不等人，明天就是上线时间， 活动上不去对老板和运营都没办法交代”

项目上线：

老板：“运营和我反馈了好多问题，你们版本上线是怎么测试的，要反思一下xxxx”

开会

产品：“我说过用户要集齐碎片和好友砍价之后才能给优惠券，等级不够的不让他们砍价成功，为什么只完成砍价的新人拿到大额优惠券？”

产品：“什么？因为账号数据绑定有 Bug ，不同渠道用户合并账号就可以满足？为什么会有这个 Bug ，测试那边没覆盖到吗？”

测试：“我不知道啊，需求文档没有说还能账号合并，而且这个功能之前没说过要限制用户等级吧？”

产品：“我出的需求肯定有，文档里肯定有，另外开发你既然知道问题，为什么不提前沟通，现在用户都消费了，这个事故你和测试 55 责，后面复盘的时候要避免这样的问题再次发生”

开发：“。。。。。”

最后

所以大家觉得是谁应该背锅？是开发的能力不够，还是测试用例的覆盖缺失？说起来，其实在此之前，我在掘金也遇到了一个 “Bug” ，比如：

文章 Markdown 里图片链接的 content-type 字段如果不符合 image/*** 规格，那么发布出来的时候链接就不会被掘金转码，所以不会有图片水印，同时直接指向了我自己的图床地址。

那么你觉得这个是 Bug 吗？明明是用户不遵循规范。但是这样不就留下漏洞了吗？

如果在文章审核通过之后，我修改图床上的图片内容，这样不就可以绕过审核在掘金展示一些「违规」内容了吗？

所以有时候一些功能的初衷是好的，但是引发的问题却又很隐蔽，那么这能怪「测试用例覆盖不到位吗」？

那么，你觉得「经过测试，为什么上线后还会那么多 Bug 」更多可能是谁的问题？