[问题处理] 简化问题复现步骤-Toy模板网

这篇具有很好参考价值的文章主要介绍了[问题处理] 简化问题复现步骤。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

当一个问题在复杂的场景下发生之后，在做调试的时候，总是希望可以将复现的步骤简化，以方便问题debug。这里总结一下一般实例。

当在大量业务数据流做压力测试时，发现TCP有丢包；可能需要使用网络相关的性能测试软件来简化复现步骤，将复杂的业务去掉；
当一个复杂的产品脚本运行出现问题的时候。需要尝试将脚本简化；https://mzhan017.blog.csdn.net/article/details/128718368；在处理这个问题的时候，当时产品的脚本就比较复杂，最后通过使用strace分析脚本运行简化了复现脚本。
记得多年以前碰到Windriver系统里的一个49.7天问题，问题需要等49.7天才能复现；后来通过Windriver 操作系统提高的Cshell，以命令方式将那个int变量强制设置，提前出现49.7天问题。
当现场的一个网络包导致了内核模块的crash，可以使用scapy来模拟这个异常包来复现。
当一个问题的出现可能是由于文件的更替（或者其他触发条件）导致，就可以将更替的频率增大，已验证问题分析的方向正确。
记得还有一个硬件同步相关的问题，老GSM的一个产品，发现同步问题，不好复现。最后的复现步骤是将网卡所光纤人工弯折一下，就可以复现问题，导致信号上有些偏差。
之前碰到过一个内核hang住的情况，后来发现是注册的trace point导致的，但是产品里的trace point有些复杂，后来单独写了一个轻装trace point的内核模块，很轻松复现问题。https://mzhan017.blog.csdn.net/article/details/131119252

复现问题需要注意：
不要在使用调试工具时，让调试工具的运行影响了问题的复现，比如cpu使用率占用太大，导致问题出不来。
《Lockless Multi-Core High-Throughput Buffering Scheme for Kernel Tracing》
Furthermore, the workload must not be disturbed by tracing, thereby causing the problematic behavior to become unreproducible.文章来源地址https://www.toymoban.com/news/detail-602205.html

到了这里，关于[问题处理] 简化问题复现步骤的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！