一、提出问题
最近有测试小伙伴问了一个问题。
发布生产后，总是出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测试、蓝绿发布这样的发布策略。
五、如何在全公司建立质量思维？
当然是转发这篇文章，让你的老板、领导、同事都看到，提高产品质量，不能光靠测试哟。锅是集体的锅哈哈哈～