写在前面
之所以想写下线上 bug，因为发觉有些公司对线上 bug 的处理是比较严格甚至是很苛刻，涉及到的相关人可能会因此而背黑锅。

之所以会存在这样情况，因为公司各部门都有关联，特别是用户、老板的投诉，也给公司会造成直接口碑或经济等重大损失。

第一节：

 下面举几个实际发生过的关于线上 bug 的例子：

1.一个修改 update 操作，结果引起删除 delete 了一条数据；

    问题追溯：实际上测试漏测了，导致项目开发 leader 辞退，团队扣奖金。 

2.一个地图上的所有目标加油站数据加载不出来；

    问题追溯：实际上因为客户端 app 上线了，但是那晚后台开发同事未加班，后台 api 及数据未同步上线，从而导致这个问题，测试 leader 辞退。

3.一个活动， 1 分钱团购旅游门票，预计是放出 300 张，结果未做限制导致被抢了过多超 10000 张，导致华侨城景点游客堵塞混乱；

     问题追溯：实际上是系统未设置默认张数，业务部门也未设置，用户可以无限制抢购，抢到门票的人过多引起堵塞和导致投诉并造成损失。

第二节：

线上的问题，有用户咨询类、用户操作不当类，那么其他可以归属于系统 bug 即生产事故：

1.一方面我们又要有效预防生产事故，因为测试的一个比较重要职责是暴漏风险，保障质量，要起到防火的作用，而不应是把重点放在救火；

衡量指标：缺陷密度

2.一方面我们不太可能 100% 的保证线上没有任何一个 bug，这时要救火；

衡量指标：漏测率

那么我们思考怎样去做会比较好呢，其实每个公司都不完全一样，但是我们尽可能细致入微的方向去做肯定是没有错的

1.防火：测试流程规范，进行线下充分高效测试，充分暴漏问题；产品项目流程规范及时解决线下 bug；线上也进行冒烟测试等；

这个过程做的足够好，其实线上 bug 风险，我们通常也是在可控范围内的。

2.救火：有效及时处理掉线上 bug。

第三节：

1：线上 bug 测试处理过程

2：线上 bug 研发处理过程

3：线上 bug 详情及进度

4：线上 bug 功能分类统计

5：线上 bug 环境分类统计

6：线上 bug 定级标准

7：线上 bug 总结优化

后记
通过收集，分析，总结，从而对重复出现 2 次及以上的 bug，要防止再次出现该问题，重点找出原因并优化改善，结合产品部门、开发组开会商讨，想出解决方案，并入下一个版本需求开发计划。