软件测试线上故障规范和模板,希望能帮到大家
目录
[NOF-32] 全平台所有业务下单后支付异常,无法调起支付
创建: XX年/XX月/XX日 更新: XX年/XX月/XX日 解决: XX年/XX月/XX日
前言
对于每一个测试人员来说,软件测试过程中有一个四字成语,真的是如噩梦一般的存在,会在你不注意的时候,就突然蹦出来,劳你筋骨、空乏你身、乱你心神、行拂乱你所为,那就是——线上故障。
线上故障顾名思义,就是项目上线后出现的故障。诱发线上故障的因素有很多,每一个团队,大大小小,都会受到各种各样的线上故障,我们有时候会局限于故障的本身,但是如何应对、避免线上故障的发生,是每个技术研发团队都要面对的事情。并且,由于线上故障的解决跟踪过程,能直接体现一个团队的应急反应能力,所以,线上故障的解决并不是测试一个人的问题,而是整个团队协同一致,共同面对的一个问题。因此我们团队特此制定了线上故障的规定及模板。
线上故障规范及模板
文档背景
为保障线上功能正常使用,并在遇到问题时及时反馈并快速解决,现编写规范如下
问题分类
线上BUG:
① 运营同事的错误操作导致的体验类型问题,如:文案错误;
② 运营后台使用异常,如:无法修改商品状态,不能正常打开使用后台管理;
③ 产品设计缺陷,不合理需求,等
线上故障:
① 由技术原因导致的线上使用异常,如:无法正常支付、无法正常跳转配置的链接地址、订单异常等;
② 运营同事的错误操作导致的问题,如:错配优惠券为无限量无门槛;
非故障类型
产品设计未实现的需求问题,如:需要新增某种功能,或者产品未覆盖的功能点等
问题录入
录入问题必须写明:项目(线上故障NOF)、模块(android、ios、公众号、小程序、后台)、环境(手机配置、浏览器及版本)、描述(故障产生场景及操作)、影响版本(故障对应版本号)、严重性、优先级(紧急故障会立即启动故障流机制)、经办人、附件(非必填);问题发生(收到反馈)的时间等,尽可能的详细
等级评判
评级标准可参考《故障等级参考》
问题修复
1、 定位问题原因,和影响范围
2、 修改问题耗时,和修改方案
3、 确认后续跟踪方案
故障Review
故障责任人:故障问题的负责人
问题修复:开发and 开发组长,测试and测试组长
定责内容:确认故障级别、故障原因、故障导致的影响以及最终的解决方案,后续跟踪
为方便理解以上规范内容,现取一条线上问题作为模板供阅读此规范的同事参考:
[NOF-32] 全平台所有业务下单后支付异常,无法调起支付创建: XX年/XX月/XX日 更新: XX年/XX月/XX日 解决: XX年/XX月/XX日 |
|
项目: |
线上故障 |
模块: |
无 |
影响版本: |
4.X |
解决版本: |
无 |
类型: |
技术方故障 |
优先级: |
高 |
报告人: |
XX |
经办人: |
XXX |
解决结果: |
完成 |
责任人: |
XXX |
标签: |
无 |
||
剩余时间: |
XX天XX时XX分 |
||
耗费时间: |
XX天XX时XX分钟 |
||
原预估时间: |
尚未登记 |
严重程度: |
严重 |
描述 |
全平台所有业务下单后支付异常,无法调起支付。 持续时间:XX小时XX分钟,重启服务后恢复正常 |
测试-XXX复盘 [ XX/XX月/XX ] |
问题解决: 1.临时通过重启服务器解决无法支付的问题 2.最终通过代码修复,发布版本解决问题, 原因分析: 1. 因为没有.......(问题原因),导致........(问题) 2. 问题出现时,没有能够及时联系到相关值班人,导致时间延误 解决方案: 1、陈独秀通过修正........,添加...........,并在XX时,经小组长抖音帝验证后发布到线上环境, 2、万能钢新增...........机制,通过.........实现.......,与经小组长抖音帝验证后发布到线上环境 3、互留手机号,避免由于沟通不畅影响故障修复速度,部门长已验证通过 影响范围: 通过日志确定XX日XX时XX分出现问题,XX日XX时XX分开始解决, XX日XX时XX分问题解决并发布上线,影响时长 XX天XX小时XX分 全平台不能调起支付,经核算,问题时间段内影响客户影响交易量为XXXX元 参与修复人:XXX、XXX 问题责任人:XXX 故障评级: 经过以上影响范围评估,此判定等级为P-1级故障 |
后续Action:
此次支付故障后,由于该问题具有普遍性,所以阿尔法小组伙伴排查了线上所有的任务并做了危险等级评估
1、业务一......危险评估高,计划某月某号某人优化修改
2、业务二......危险评估中,计划某月某号某人优化修改
3、业务三......危险评估低,计划某月某号某人优化修改
贝塔小组也做出了同样的预防措施如下:
1、 实现A功能优化,执行人Eason,计划完成日期XX
2、 通过B方法检查来review代码,
3、 通过C方案避免.......问题。
由于此次问题具有代表性,需要引起各位同事的重视和品质意识,所以有了此规范文档。又因为是首次复盘线上故障,过程和步骤生疏,导致耗时比较长。所以为了更高效的解决线上故障,以后每周由每条业务线的测试人员驱动,进行故障Review,若本周内未录入线上故障,则不走此流程。
所有的流程和步骤,都是为了高效、优质、有意义的工作,祝大家工作顺利
总结
感谢每一个认真阅读我文章的人!!!
那么在这里我也精心准备了软件测试、自动化测试的详细资料包含:电子书,简历模块,各种工作模板,面试宝典,自学项目等。需要的点击下方名片加入群聊大家一起学习交流。
这篇好文章是转载于:学新通技术网
- 版权申明: 本站部分内容来自互联网,仅供学习及演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系,请提供相关证据及您的身份证明,我们将在收到邮件后48小时内删除。
- 本站站名: 学新通技术网
- 本文地址: /boutique/detail/tanhgcecbi
-
photoshop保存的图片太大微信发不了怎么办
PHP中文网 06-15 -
Android 11 保存文件到外部存储,并分享文件
Luke 10-12 -
《学习通》视频自动暂停处理方法
HelloWorld317 07-05 -
word里面弄一个表格后上面的标题会跑到下面怎么办
PHP中文网 06-20 -
photoshop扩展功能面板显示灰色怎么办
PHP中文网 06-14 -
微信公众号没有声音提示怎么办
PHP中文网 03-31 -
excel下划线不显示怎么办
PHP中文网 06-23 -
excel打印预览压线压字怎么办
PHP中文网 06-22 -
怎样阻止微信小程序自动打开
PHP中文网 06-13 -
TikTok加速器哪个好免费的TK加速器推荐
TK小达人 10-01