bug无穷尽，永远是解不完的，有人撸码的地方，就有bug。我们能做的就是尽量减少bug的出现。

bug多的可能原因

这是个逆向思维，我们知道什么场景会出现bug的时候，反向操作就可以减少bug。

编号场景说明方案

1产品人员能力问题新手产品经理可能会出现此问题1、需求评审要仔细，及时反馈问题。

2、产品迭代流程要遵守规范。

3、重要、高风险、高成本的需求，要多次确认。

2需求理解不到位 一般都是人为问题1、加强责任心，认真理解需求文档。

2、加强沟通，做到真实理解产品需求。

3、做好时间管理，明确需求的轻重缓急。

4、引入奖惩机制

3工期短一般都是p0需求1、分清主次需求。

2、迭代任务拆分。

3、加强人员协调

4业务逻辑复杂1、加强研发能力，加强组内技术沟通

2、加强前期规划、设计

3、出流程图、逻辑图、时序图

4、组织代码review

5、产研加强沟通，信息同步

5项目参与人多1、明确责任人，统一负责问题对接，任务分配，信息同步，进度跟进

2、组织代码review

6功能多大部分可以转换成3，5场景1、需求合理拆分排期

2、同3、5解决方案

7开发者能力问题一般为个人问题1、传帮带

2、循序渐进的安排与能力匹配的任务（tl）

3、组织代码review

8填坑老旧项目1、加强项目规划、调研、沟通

2、补足文档，避免二次资源浪费

3、推动改版重构

4、扩大测试场景，测试完备

9自测不充分一般个人责任心问题偏多1、加强责任心

2、完成冒烟测试

3、回归产品需求文档

4、bug黑名单检查

5、组织代码review

6、加强个人时间管理能力

7、引入奖惩机制

10测试环境不完备1、积累经验，形成文档，方便后来者查阅

2、缺失的场景提前明确，和测试人员沟通到位，避免异常、遗漏

3、推动改进，完善测试场景

11兼容适配问题一般较为棘手1、经验积累，形成文档

2、组织分享，广而告之

12测试人员能力问题一般表现为误报1、加强团队磨合，了解任务分工

2、加强沟通协调，增加业务理解

3、重新分配bug

13bug修复效率低bug修复不彻底，不及时1、加强问题定位能力，避免猜测

2、加强自测

3、加强责任心

4、通过工具及时告知相关bug责任人

bug常见分类

用于代码上线后，做bug分析。

bug级别

级别描述说明

0赶紧修复线上bug

1紧急测试中断，无法测试

2重要需求不符或者关键性逻辑错误

3一般次要逻辑功能

4次要文案，设计和需求不符

5无关紧要建议

bug分类

编号分类说明级别方案

1功能bug逻辑错误

需求理解错误

功能未实现

异常未处理

性能问题

重复

需求变更

场景补充

产品建议

无需修复

误报

bug黑名单

可以通过此文档查阅而人为避免的bug，就是黑名单bug。此类bug后续不得出现，是惩罚机制的参考。

编号描述说明方案

图片缺省图片大小没有处理，导致展示问题

图片加载异常，导致出现X图，影响展示

文案长度没有限制字数，导致展示异常

网络请求是否需要loading

超时处理

数据异常处理

统计代码没有添加统计代码