软件测试线上故障规范及模板

写在前面 

      对于每一个测试人员来说，软件测试过程中有一个四字成语，真的是如噩梦一般的存在，会在你不注意的时候，就突然蹦出来，劳你筋骨、空乏你身、乱你心神、行拂乱你所为，那就是——线上故障。

      线上故障顾名思义，就是项目上线后出现的故障。诱发线上故障的因素有很多，每一个团队，大大小小，都会受到各种各样的线上故障，我们有时候会局限于故障的本身，但是如何应对、避免线上故障的发生，是每个技术研发团队都要面对的事情。并且，由于线上故障的解决跟踪过程，能直接体现一个团队的应急反应能力，所以，线上故障的解决并不是测试一个人的问题，而是整个团队协同一致，共同面对的一个问题。因此在这个基础上，我们的测试团队在部门长的指导下，制定出了我们团队的线上故障等级和处理规范，供大家参考学习

《故障等级定义》

        由于无法配置表格，只能以拙劣的截图奉上了

线上故障规范及模板

文档背景

为保障线上功能正常使用，并在遇到问题时及时反馈并快速解决，现编写规范如下

问题分类

线上BUG:

① 运营同事的错误操作导致的体验类型问题，如：文案错误；

② 运营后台使用异常，如：无法修改商品状态，不能正常打开使用后台管理；

③ 产品设计缺陷，不合理需求，等

线上故障：

① 由技术原因导致的线上使用异常，如：无法正常支付、无法正常跳转配置的链接地址、订单异常等；

② 运营同事的错误操作导致的问题，如：错配优惠券为无限量无门槛；

非故障类型

产品设计未实现的需求问题，如：需要新增某种功能，或者产品未覆盖的功能点等

问题录入

录入问题必须写明：项目（线上故障NOF）、模块（android、ios、公众号、小程序、后台）、环境（手机配置、浏览器及版本）、描述（故障产生场景及操作）、影响版本（故障对应版本号）、严重性、优先级（紧急故障会立即启动故障流机制）、经办人、附件（非必填）；问题发生（收到反馈）的时间等，尽可能的详细

等级评判

评级标准可参考《故障等级参考》

问题修复

1、 定位问题原因，和影响范围

2、 修改问题耗时，和修改方案

3、 确认后续跟踪方案

故障Review

故障责任人：故障问题的负责人

问题修复：开发and 开发组长，测试and测试组长

定责内容：确认故障级别、故障原因、故障导致的影响以及最终的解决方案，后续跟踪

为方便理解以上规范内容，现取一条线上问题作为模板供阅读此规范的同事参考：

[NOF-32] 全平台所有业务下单后支付异常，无法调起支付 创建: XX年/XX月/XX日 更新: XX年/XX月/XX日 解决: XX年/XX月/XX日
项目:	线上故障
模块:	无
影响版本:	4.X
解决版本:	无

类型:	技术方故障	优先级:	高
报告人:	雪姨	经办人:	陈独秀
解决结果:	完成	责任人:	陈独秀
标签:	无
剩余时间:	XX天XX时XX分
耗费时间:	XX天XX时XX分钟
原预估时间:	尚未登记

严重程度:

严重

描述

全平台所有业务下单后支付异常，无法调起支付。 持续时间：XX小时XX分钟，重启服务后恢复正常

测试-克莱瑞斯复盘 [ XX/XX月/XX ]

问题解决： 1．临时通过重启服务器解决无法支付的问题 2．最终通过代码修复，发布版本解决问题， 原因分析： 1. 因为没有.......（问题原因），导致........（问题） 2. 问题出现时，没有能够及时联系到相关值班人，导致时间延误 解决方案： 1、陈独秀通过修正........，添加...........，并在XX时，经小组长抖音帝验证后发布到线上环境， 2、万能钢新增...........机制，通过.........实现.......，与经小组长抖音帝验证后发布到线上环境 3、互留手机号，避免由于沟通不畅影响故障修复速度，部门长已验证通过 影响范围： 通过日志确定XX日XX时XX分出现问题，XX日XX时XX分开始解决， XX日XX时XX分问题解决并发布上线，影响时长 XX天XX小时XX分 全平台不能调起支付，经核算，问题时间段内影响客户影响交易量为XXXX元 参与修复人：陈独秀、万能钢 问题责任人：陈独秀 故障评级： 经过以上影响范围评估，此判定等级为P-1级故障

后续Action：

此次支付故障后，由于该问题具有普遍性，所以阿尔法小组伙伴排查了线上所有的任务并做了危险等级评估

1、业务一......危险评估高，计划某月某号某人优化修改

2、业务二......危险评估中，计划某月某号某人优化修改

3、业务三......危险评估低，计划某月某号某人优化修改

贝塔小组也做出了同样的预防措施如下：

1、 实现A功能优化，执行人Eason，计划完成日期XX

2、 通过B方法检查来review代码，

3、 通过C方案避免.......问题。

由于此次问题具有代表性，需要引起各位同事的重视和品质意识，所以有了此规范文档。又因为是首次复盘线上故障，过程和步骤生疏，导致耗时比较长。所以为了更高效的解决线上故障，以后每周由每条业务线的测试人员驱动，进行故障Review，若本周内未录入线上故障，则不走此流程。

所有的流程和步骤，都是为了高效、优质、有意义的工作，祝大家工作顺利

写在最后

      因为是第一次执笔写故障定级和规范，所以有很多不足之处，也请大家多多指正出来，我们共同讨论，更高效，高质量的管控故障，共同保证我们的项目，安全平稳的运行