之所以想写下线上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，要防止再次出现该问题，重点找出原因并优化改善，结合产品部门、开发组开会商讨，想出解决方案，并入下一个版本需求开发计划。