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