每次版本发布上线后，测试人员，心里总是忐忑和紧张的；总在担心，会不会有啥严重的稀奇古怪的Bug出现 。
根据老徐这10年+的测试经验，以及最近五年的质量部门管理经验，其实是可以做到上线后0BUG的 。
同步几个名词：
1、线上环境：是指真实用户在使用的生产系统，也称为「生产环境」。
2、零BUG：是指没有任何用户反馈线上问题 。
今天突然想到这个主题：
1）通过关键词，检索了老徐此公号「简尚」的历史文章，发现之前居然没写过 ；
2）另，老徐通过搜索引擎，全网检索，也没发现太多这方面有价值的文章 ；
基于如上两点，老徐打算写一篇这方面的内容，算是跟此公号几万「软件测试从业者」一起探讨，以及分享一些老徐过去的经验 ；
进入主题：
如何做到「零BUG：是指没有任何用户反馈线上问题」呢 ？这里涉及到两个测试行业内的成熟实践「测试左移」&「测试右移」
这块的概念，随机从网上贴一段：
1）测试左移
本质是在一切开始之前先进行测试，测试对象是需求，越早的发现需求不合理的地方出问题的几率就越低。
另外测试左移还可以是在开发阶段就进行测试，开发阶段可能产出只是代码，而不是完成的功能，这时候比较合适的测试是做持续集成的单元测试，通过代码覆盖率的方式找到未经测试的代码，尽可能的保证代码都被测试到。这些单元测试的用例可以在BDD时候通过用户或客户的用例描述来提炼。
总之左移是在测试阶段到来之前，尽可能的抓紧开发前(需求分析)和开发中的时间做测试，提前发现问题，防微杜渐，避免积重难返。
2）测试右移
左移是往测试之前的开发阶段移，右移是往发布之后移。
也就是产品上线了之后也可以进行一些测试活动。当然在生产环境直接做测试是不推荐的，但是可以在生产环境做监控，监控线上性能和可用率，一旦线上发生任何问题，尽快反应，提前反应（在用户发现之前，把问题解决了，这就是所谓的0Bug），给用户良好的体验。
测试右移其实还可以理解为如果线上发生任何问题，我们有没有能力第一时间发现问题并解决问题，并保证线上数据的一致性或尽可能少的影响线上用户。
很对时候，右移比左移更具有挑战性。
OK ，老徐的做法，基本上也是遵循如上两个原则 ：
1）尽可能早的在源头控制产品质量，在需求源头就要控制伪需求，在代码设计阶段、就要控制劣质代码 ；
2）时时刻刻监控线上系统的功能可用性 & 数据异常 & 数据拐点 & 异常Log
当然，如果想科学的执行0BUG策略，也可以根据行业规范 & 根据公司项目&产品特性，定制BUG优先级&BUG严重程度 。
如果无法做法严格意义的0BUG ，至少得实现P0/P1/P2 BUG 0 ，至于P3BUG 0的目标，根据团队磨合情况 & 成员能力提升情况，逐步实现 。
End 。
延伸：
还有一些公司，根据Bug，会有处罚机制 & KPI ，后期再聊 。
这篇文章，更多是先抛出这个话题，并没有写到细节执行层 ；
有兴趣的，底部留言讨论 。
先写到这 。
文 / IDO老徐
转载注明来源 isTester.com
