测试开发笔记:一次版本更新的故障复盘
2024软件测试面试刷题,这个小程序(永久刷题),靠它快速找到工作了!(刷题APP的天花板)_软件测试刷题小程序-CSDN博客文章浏览阅读3k次,点赞86次,收藏13次。你知不知道有这么一个软件测试面试的刷题小程序。里面包含了面试常问的软件测试基础题,web自动化测试、app自动化测试、接口测试、性能测试、自动化测试、安全测试及一些常问到的人力资源题目。最主要的是他还收集了像阿里、华为这样的大厂面试真题,还有互动交流板块……_软件测试刷题小程序编辑https://blog.csdn.net/AI_Green/article/details/134931243?spm=1001.2014.3001.5502编辑https://blog.csdn.net/AI_Green/article/details/134931243?spm=1001.2014.3001.5502编辑https://blog.csdn.net/AI_Green/article/details/134931243?spm=1001.2014.3001.5502https://blog.csdn.net/AI_Green/article/details/134931243?spm=1001.2014.3001.5502https://blog.csdn.net/AI_Green/article/details/134931243?spm=1001.2014.3001.5502https://blog.csdn.net/AI_Green/article/details/134931243?spm=1001.2014.3001.5502编辑https://blog.csdn.net/AI_Green/article/details/134931243?spm=1001.2014.3001.5502https://blog.csdn.net/AI_Green/article/details/134931243?spm=1001.2014.3001.5502编辑https://blog.csdn.net/AI_Green/article/details/134931243?spm=1001.2014.3001.5502https://blog.csdn.net/AI_Green/article/details/134931243?spm=1001.2014.3001.5502https://blog.csdn.net/AI_Green/article/details/134931243?spm=1001.2014.3001.5502https://blog.csdn.net/AI_Green/article/details/134931243?spm=1001.2014.3001.5502https://blog.csdn.net/AI\_Green/article/details/134931243?spm=1001.2014.3001.5502
初步参与测试开发工作,工作中马上经历了一次上线的故障并最终回滚。
本文尝试记录这次故障,文内已隐去具体业务,使用翻译服务的案例代替并简化了服务链路,旨在简明扼要地展示问题。
因为本文作者经验尚浅,对一些术语还不太熟悉,词语可能出现误用的情况,请测试前辈读者们不吝指教。
本文内容简介
本文的结构安排遵循了背景交代、业务与变更阐述、故障分析、总结的步骤。具体来说,本文首先介绍了本案例使用的流式传输的协议,然后介绍服务调用流程,然后说明本次服务变更以及原因,然后记录故障并分析原因,最后总结经验。
传输协议背景
业务的服务接口使用 websocket 协议,并约定流式一次性传输是指在调用服务的时候将数据一次性发送给服务端,并设置status
字段值为 2,例如下面:
请求服务发送的数据:
{
"status": 2,
"seq": 0,
"data": "春眠不觉晓,
处处闻啼鸟。
夜来风雨声,
花落知多少。"
}
流式一次性传输适应的场景是,服务需要拿到完整的传入数据才能提供服务结果。例如计算算式 1+(2*(3/4+3)+2)/2,服务侧需要拿到完整的算式才能给出结果。
而流式分帧传输是指调用服务的时候分多次发送,status
为 0 表示开始发送的起始帧,为 1 表示中间帧,为 2 表示最后一帧,例如:
请求服务发送的第一帧数据:
{
"status": 0,
"seq": 0,
"data": "春眠不觉晓,"
}
请求服务发送的第二帧数据:
{
"status": 1,
"seq": 1,
"data": "处处闻啼鸟。"
}
请求服务发送的第三帧数据:
{
"status": 1,
"seq": 2,
"data": "夜来风雨声,"
}
请求服务发送的第四帧数据:
{
"status": 2,
"seq": 3,
"data": "花落知多少。"
}
流式分帧传输适应的场景是,服务可以逐步提供服务结果,最后由调用方拼凑响应的结果来呈现最终的结果。例如翻译,可以逐句翻译并响应结果。
当前翻译服务
如下图,当前翻译服务串联了两个子服务:A 封装了第三方审核服务,对需要翻译的全文进行审核;B 是翻译引擎,对送入的文本执行翻译并返回结果。
服务调用链路的示意图
因为 A 服务是按调用次数计费,基于控制成本的考虑,一次会话中总是期望用户按照流式一次性传输的方式传入待翻译的文本。
B 服务支持流式一次性传输和流式分帧传输。
变更以及评估
为了更快地给用户反馈,内部自研了审核服务,支持逐句审核,也就是说 A 服务从原来的只支持流式一次性传输扩展为两种方式都支持,记为 A’服务。
经评估认为 A’兼容当前线上的调用协议,B 服务本次无变更,更新的风险较低。
更新版本首先部署在测试环境中,经本文作者测试,可以正常支持原来的流式一次性传输方式和流式分帧传输方式。本文第一部分的两个例子可视为执行的测试用例,响应结果符合预期。
故障反馈分析
上午发布新的版本,10 分钟左右有用户开始反馈调用出错,未能第一识别识别原因并排除错误,服务回滚到更新前的版本。
后经过排查,用户调用服务时参数使用不规范:原本约定在流式一次性传输时status
设置为 2,而部分用户使用的时候将status
设置为了 1,而status
为 1 时候表示流式分帧传输的中间帧。
具体来说,A 中并没有对status
参数做校验,会直接按流式一次性传输的方式将接收的文本发送给 B,因此,当用户调用现网服务并设置status
为 1 时,可以获得正确的结果。
而更新后的 A’在不接受起始帧的前提下,接收到中间帧,会认为此次会话无效。所以,新版本并不兼容线上的使用方式。
寻找蛛丝马迹
疑问:用户为什么会错误地设置状态参数呢?
经检查,可能是因为提供的协议文档中给出了的错误的示例。
文档首先给了一个示例,然后在正文解释了各个参数的可选值,正文部分强调了状态参数的取值应该为2,而给出的示例中状态赋值为1.
疑问:为什么上一个版本测试时没发现问题?
据观察,内部工具在开源的HttpRunner基础上实现了流式一次性传输和流式分帧传输的逻辑,以适应业务测试的需要。
测试脚本中如果指定使用前者方式,那么status
字段会固定设置为2。因此,内部工具不支持构造流式一次性传输并设置status
为1的异常测试用例。
教训总结
首先,应认识到了在服务接口设计和协议文档的重要性。在本次故障中,由于协议文档中示例与正文描述不一致,导致了用户在使用服务时出现了参数设置错误,这反映出在文档编写和审核过程中存在疏漏。
其次,要认识到测试工具的局限性。在本案例中,虽然当前工具能够很好地支持正常的测试用例,但对于异常情况的测试覆盖不足。
最后,应在变更评估过程中需要更加细致和全面。尽管我们对 A’ 服务进行了评估,并认为其兼容当前线上的调用协议,但实际上却忽略了用户可能的误操作情况。这说明我们在评估过程中需要更多地从用户的角度出发,考虑实际使用中的各种可能性。
行动吧,在路上总比一直观望的要好,未来的你肯定会感谢现在拼搏的自己!如果想学习提升找不到资料,没人答疑解惑时,请及时加入群: 759968159,里面有各种测试开发资料和技术可以一起交流哦。
最后: 下方这份完整的软件测试视频教程已经整理上传完成,需要的朋友们可以自行领取【保证100%免费】
软件测试面试文档
我们学习必然是为了找到高薪的工作,下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料,并且有字节大佬给出了权威的解答,刷完这一套面试资料相信大家都能找到满意的工作。
还没有评论,来说两句吧...