一、提出问题

最近有测试小伙伴问了一个问题。

发布生产后，总是出bug，领导让测试反思怎么才能让生产上零bug，并且能实际付诸行动。该怎么做？

一个很好的问题，因为当测试做好了自己该做的事情后，锅还是常常从天上飘来。

二、解决问题

• 首先，大家都知道的一个事实，零bug是不可能的。

因为产品的诞生、开发都是运用人的思维、人的行为去实施的，是人为就会有漏洞。在不长的计算历史上，还没有人写过没有bug的完美软件。

所以问题转化为如何提高产品质量，减少bug，以及减少生产上出bug带来的影响。

为什么领导怕生产上出bug，本质是，生产上的bug会对用户造成影响，直接或间接造成了公司的损失。

• 其次，减少bug，也不止是测试的事情。毕竟，bug并不是测试引入的。

在我初初入行时，也对测试这个岗位有些许误解。

而且我相信大多数从业者都有这样的误解，因为我对于测试岗位的误解就是来源于一些测试从业人员朋友、一些测试从业人员的网上言论。

所以，在从事测试工作最初，如果生产上出现了bug，我认为：

• 测试过程不够认真；
• 测试用例写得不够完善；
• 自己思考问题不够全面；
• 出现bug，就是测试背锅；
• ……

直到我开始看许多测试大佬们的文章、视频，才纠正了我错误的观念。

一个产品的质量保障，是需要一套完整的质量保障体系。

产品从立项开始，到开发、到发布、到维护都应该贯穿质量保障思维。

而不是单靠测试人员来保证产品的质量。

三、建立全面质量保障体系

如何建立全面的质量保障体系呢？目前一个产品，基本上按需求阶段、研发阶段、测试阶段、维护阶段（即发布后）。每个阶段都有一定的质量保障手段。

需求阶段通过需求评审、测试用例评审（我把测试用例评审放在需求阶段，因为我认为测试用例评审更像是在细化需求实现，让产品、测试、开发对于需求的理解达成一致）、UI设计稿评审去保障，研发阶段通过单元测试、代码分析、代码评审、冒烟测试去保障，测试阶段通过服务端测试、客户端测试去保障，发布后通过线上监控、用户反馈进行质量保障。

需求阶段通过需求评审、测试用例评审（我把测试用例评审放在需求阶段，因为我认为测试用例评审更像是在细化需求实现，让产品、测试、开发对于需求的理解达成一致）、UI设计稿评审去保障；

研发阶段通过单元测试、代码分析、代码评审、冒烟测试去保障；

测试阶段通过服务端测试、客户端测试去保障；

发布后通过线上监控、用户反馈进行质量保障。

可以看出，产品开发的各个阶段其实都影响到了产品最终质量，除了测试阶段不会引入bug之外，其他阶段都会引入bug。

实际工作中，并不是所有公司都具备这么完善的手段去保障质量手段，把上表当作一个工具箱，根据公司规模大小、公司实际情况，抽取其中可以实施的工具。

如何知道自己公司添加哪个工具投资回报最大呢？

bug归因，对于每一个bug产生的原因归类，追溯bug是由什么阶段引入，对应的选择工具箱中的工具。

四、如何追溯bug到底是何时引入的呢？

bug归因，对于每一个bug产生的原因归类，分类主要是需求不明/变更、代码错误、界面优化、性能问题、配置相关、安全相关……可以根据自己公司的具体情况来确定有哪几类，每一个bug修复后都标记上bug的原因。当一个版本测试完成时，可以得到bug归因统计。

所以当一个产品，总是bug较多，除了完成基本的功能测试外，检测产品开发的全流程中哪个阶段引入的bug最多，提升那个阶段的质量保障手段。

比如，bug归因统计下来，因需求不明造成的bug最多，
我们能做：
1.建议产品提高需求文档的细节。
2.建议产品在需求评审会前一天发送需求文档给相关人员提前阅读，提高需求评审的质量。

如果因代码错误造成的bug最多，
我们能做：
1.建议提高单元测试覆盖率
2.建议开发团队增加培训，提高开发人员水平
3.增加代码审查、代码分析环节。

回到最初的问题，如何提高产品质量，减少bug，以及减少生产上出bug带来的影响。以上内容已经回答了半个问题。

那如何减少生产上出bug带来的影响？
可以靠线上监控、用户反馈机制。

线上监控及报警，能在检测到线上出问题时，第一时间得知。同时要有相应的生产事故响应流程，能在得知之后如何快速敲定解决方案。

用户反馈，线上监控可能只监控了核心的接口、核心功能，而且一个产品的使用，每一个用户还受制于他的操作习惯、设备、网络等问题。重视用户反馈，相当于他在给你进行测试。

除此之外，良好的发布策略也能将影响减到最小。对于用户量庞大的产品，全量发布的话，面临较大的风险。可以选择灰度发布、A/B测试、蓝绿发布这样的发布策略。

五、如何在全公司建立质量思维？

当然是转发这篇文章，让你的老板、领导、同事都看到，提高产品质量，不能光靠测试哟。锅是集体的锅哈哈哈～