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

写在前面

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

线上故障规范及模板

文档背景

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

问题分类

线上BUG:

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

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

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

线上故障：

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

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

非故障类型

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

问题录入

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

等级评判

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

问题修复

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

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

3、 确认后续跟踪方案

故障Review

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

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

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

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

后续Action：

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

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

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

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

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

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

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

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

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

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

写在最后

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