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

综合技术 2018-12-08 阅读原文

写在前面

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

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

《故障等级定义》

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

线上故障规范及模板

文档背景

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

问题分类

线上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,若本周内未录入线上故障,则不走此流程。

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

写在最后

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

稀土掘金

责编内容by:稀土掘金阅读原文】。感谢您的支持!

您可能感兴趣的

Digital IC Bring-Up With A Bench-Top Environment One of the hottest markets for IC today is artificial intelligence (AI). The designs for AI chips are also among the lar...
Testing Nodejs with Coffeescript I'm dabbling with node.js and coffeescript and I want to know what is a good unit test and acceptance test setup f...
Instill a DevOps Testing Culture in Your Team and ... Summary: The DevOps movement is here. Companies across many industries are breaking down siloed IT departments and fe...
The Continuous Integration Legend The importance of achieving continuous quality visibility during Continuous Integration is growing these days. Releas...
Flutter—See Why It’s Worth Testing Flutteris an SDK by Google that provides for and facilitates the development of mobile applications, and promises nat...