线上问题数量大、难复现时，如何提升问题的复现率

特大号青青

于 2024-02-23 00:30:05 发布

阅读量751

点赞数 25

分类专栏：测试左移右移文章标签：可用性测试

本文链接：https://blog.csdn.net/qq_42905388/article/details/136245640

版权

测试左移右移专栏收录该内容

3 篇文章 0 订阅

订阅专栏

本人新接手某业务线，有数万历史线上问题，治理过程中发现这些问题的平均复现率只有40%，并且持续无法提升。最终治理取得了不错的成果，在此分享如果遇到问题复现率较低应该怎么突破。

一、治理思路

●问题分类：

通过问题描述中提取关键词：分应用、分功能模块、分类型、分端等措施将大池子分割成有规律的、能具体到处理人的小池子。（这个阶段可能会有大量不准确，没关系，后续调整即可）

●问题标签化：

在确认-修复的整个过程中，积累对应标签（包括但不局限于：复现\不可复现、主链路\非主链路、问题类型）

●问题复现操作经验积累：

通过问题描述复现。如果第一次无法复现，集中处理，寻找复现规律。

●标签校准和信息补齐：

能复现（确认）的问题，直接校准分类和标签（确认高频问题和多问题模块）；不能复现的问题，做可测性建设。

二、抽象总结的参考方法

2.1 正常场景问题复现

2.1.1 场景链路法复现：

用户提供的信息充足（截图、录屏或详细文字等有效信息以及机型、日志等辅助信息）表明了错误比较显著，同时操作链路比较完整，则可以通过场景链路复现。

2.1.2 日志追踪复现:

用户提供的信息表明了crash等触发日志上报的问题，但是未复现或偶现（复现有一定困难），则可以直接排查追踪日志，并根据操作、提示等信息根据日志复现；如果日志中无法具体定位问题，再保持观察或增加技术埋点等保持观察。

2.1.3 推测复现：

用户提供的信息足以表明了错误存在，同时操作链路不完整，但能够直观推测可能存在的链路，则可以通过推测复现。

2.2 异常场景复现（正常场景之下无法复现）

2.2.1 场景链路法复现：

用户提供的信息充足（截图、录屏或详细文字等有效信息以及机型、日志等辅助信息）表明了错误比较显著，同时操作链路比较完整，通过场景链路无法复现，则考虑常见的异常场景进行复现。

2.2.2 日志追踪复现：

相对于正常场景，特别地，用户提供的信息表明了crash等触发日志上报的问题，但是未复现或偶现（复现有一定困难），则可以直接排查追踪日志，并根据日志中的错误信息、异常信息复现；

2.2.3 推测复现：

用户提供的信息充足（截图、录屏或详细文字等有效信息以及机型、日志等辅助信息）表明了错误可能存在，但操作链路不完整，则推测用户的操作行为来复现，例如：
i）用户可能为非主流操作路径，需要增加一些操作（功能边界、切换应用、断开应用、数据过期、重复操作、多次操作、组合操作）；
ii）用户可能不会使用APP或操作不当（比如没看到贴纸出格了、忘记切换了功能），以为出现了不符合自身理解和认知的场景，误将需求设计如此认为是问题；
iii）用户可能把本机系统、第三方app上的问题认为是我们模块的问题；
iv) 用户可能自己也不清楚是不是bug，只是想了解一下产品设计；
v）其他对业务理解总结出的推测情况。

2.2.4 错误码代码复现：

用户提供的信息中包含了错误码或错误提示，则一定程度知道了错误可能的范围和原因，从而根据错误码对应的代码场景进行复现，例如：
（i）用户提供的信息中包含了具体的错误码或错误提示（如空、错误码：4，错误码：00xffff4等），则可以通过与研发（客户端错误如文件不存在、格式不正确、网络异常；服务端错误如没有权限、用户异常等）回溯错误码对应代码，确认问题的触发条件或数据，再执行复现。一般地，错误是系统设计如此，不需要特殊处理，但也可能转需求优化（如内存优化、错误分类优化、埋点日志优化、功能优化等）。注意：与产品沟通后发现错误文字信息不符合预期（文字内容、简繁体）、向用户暴露错误代码、或错误提示与触发场景不匹配等则可定为bug。
（ii）用户提供的信息中包含了模糊的错误提示（如操作失败，无法处理，错误原因：其他等），则与研发确认可能触发的条件再复现；如果错误情形实际为异常抛出但未处理，可定为bug；如果是无法具体排查错误情形，则保持观察。
（iii）用户提供的信息中包含了抽象的错误提示（如文字/图片无法识别、无法识别是王者荣耀游戏等），则与相关研发确认可能触发的原因再复现；