作为一个程序员，一提到 bug 就很反感；激怒一个程序员最简单的方法就是对他大声说，你写的程序 bug 非常多。但是作为一个测试，一看到他提了这么多 bug 就会感到开心。从 bug 上来看，开发和测试就是对立的两个面，一个写 bug，相当于埋地雷，然后另一个排地雷。但是不管怎么说都是为了项目顺利交付，从这个方面来说，开发和测试也是"战友"，相互协作，非常融洽。
然而有一天很不幸的事情发生了，开始考核测试环境 bug 数量了，测试环境 bug 多则表示提测质量差，而测试提的 bug 多则表示测试测的"专业"，测的仔细。开发和测试不得不站在对立面而相互攻伐，这不得不让开发开始思考 bug 到底是如何产生的，到底如何减少 bug 数量，提高提测质量呢。
bug源自prd
没错，所有的 bug 都源自 prd，认真一点的测试会编写测试用例，那么这个测试用例就是以 prd 为蓝本。如果 prd 写的逻辑有问题，或者不全面，都会影响后续的开发，导致 bug 产生。
因此在评审的过程中，每个人都需要带好自己的电脑，边听边思考，对 prd 作注解 ，另外就是做好会议纪要，评审完成后需要对评审内容再次进行回顾，找到评审内容之中一些矛盾点，在开发之前与产品沟通明确 。这需要花一些时间，有时候会影响其他业务的开发，因此在排期的时候应当给自己预留一个小时的需求分析的时间。
确保 prd 没问题之后，才能开始开发。开发的过程中要对照 prd 的每一项逐个去实现，不能脱离 prd 想当然地去做需求，这样往往会导致实现出来的效果与 prd 大相径庭。
当然仅仅只是对照 prd 还不够，prd 上面对于交互与 UI 是没有要求的，但是这一部分也会产生 bug。
bug源自代码
交互与 UI 也是 bug 的"重灾区"，这些内容是灵活的不像 prd 上面该是怎么样就怎么样。
针对 UI，我们需要格外地仔细，不能太"依赖"于后端能够返回"规规矩矩"的数据，对于空数据要做提前的预判 。UI 展示除了依赖于后端返回的数据，还依赖于地址栏参数、本地存储的数据 ，因此需要考虑所有能够进入当前页面的前置页面的逻辑，不能单纯地认为当前这个参数一定存在。
针对交互，我们需要考虑各种交互的可能性，不管是自己封装的组件还是组件库提供的组件，都要做好充分的自测。
bug源自沟通
在开发进行过程中，原则上不允许对 prd 的功能进行调整，但是有时候避免不了这种情况，一旦发生这种情况，就很有可能导致开发、产品、测试三方同步不及时，进而产生 bug。
另外还有一种情况就是前端或者后端私自更改了某个字段而未告知对方，这个时候也有可能被忽视而产生 bug。
充分自测
对照 prd，应该每做完一个点就自测一下，通过后记录一下，后面发到测试环境之后再总体自测，避免因环境不同而造成问题。
自测应该注意的点：
- 必填还是选填字段一定要区分清楚，必填字段的校验
- 默认值、数据的回显
- 业务的不了解也会产生 bug，比如说我改一个功能，可能影响到其他功能；或者我要做的功能可能收到其他功能的影响，这些地方需要产品明确指出
- 当前这一点自测完了，做了后面的又影响到了前面的内容
总结
总结一下所有可能产生 bug 的地方：
- 需求评审时边听边思考，对 prd 作注解，完结之后阅读一遍 prd 与产品沟通清楚所有的问题。
- 在排期的时候应当给自己预留一个小时的需求分析的时间
- 对照 prd 的每一项逐个去实现，如果对于某一模块的业务不了解，则需要先了解业务再开发，否则会浪费很多时间
- 写代码过程中需要注意不要依赖于后端的返回，对空数据要做判断，对于提交的数据格式要和后端约定好
- 考虑所有能够进入当前页面的前置页面的逻辑，不能单纯地认为当前这个参数一定存在
- prd 的修改需要同步到每一个人，私自修改字段前后端要同步
- 每完成一个功能点进行自测，自测完成后进行下一个功能点开发，所有功能点开发完成之后再进行整体的自测
- 必填还是选填字段一定要区分清楚，必填字段的校验
- 默认值、数据的回显
- 业务的不了解也会产生 bug，比如说我改一个功能，可能影响到其他功能；或者我要做的功能可能收到其他功能的影响，这些地方需要产品明确指出
- 当前这一点自测完了，做了后面的又影响到了前面的内容
当然如果具有"极客"精神，我想要追求 bug free，那么只有一条路："成为测试"，开发也能够成为测试，只要我们学习一些测试主流使用的方法就可以了，一些常见的测试术语：
1、等价类
2、边界值
3、场景法
4、判定表
5、因果图
6、错误推断法
7、正交测试法（正交表）
最后一个方式就是：bug 根因分析，每次产生了 bug 然后解决了 bug，这并没有完，需要对 bug 的产生进行根因分析，这样才能最大程度的减少 bug，提高提测质量。本文也就是从作者自己 100 个 bug 中进行根因分析之后得出的结论，可能不一定能覆盖所有的情况，如有遗漏，请大家一起来补充。