當一個問題在復雜的場景下發(fā)生之后，在做調(diào)試的時候，總是希望可以將復現(xiàn)的步驟簡化，以方便問題debug。這里總結(jié)一下一般實例。文章來源：http://www.zghlxwxcb.cn/news/detail-602205.html
- 當在大量業(yè)務(wù)數(shù)據(jù)流做壓力測試時，發(fā)現(xiàn)TCP有丟包；可能需要使用網(wǎng)絡(luò)相關(guān)的性能測試軟件來簡化復現(xiàn)步驟，將復雜的業(yè)務(wù)去掉；
- 當一個復雜的產(chǎn)品腳本運行出現(xiàn)問題的時候。需要嘗試將腳本簡化；https://mzhan017.blog.csdn.net/article/details/128718368；在處理這個問題的時候，當時產(chǎn)品的腳本就比較復雜，最后通過使用strace分析腳本運行簡化了復現(xiàn)腳本。
- 記得多年以前碰到Windriver系統(tǒng)里的一個49.7天問題，問題需要等49.7天才能復現(xiàn)；后來通過Windriver 操作系統(tǒng)提高的Cshell，以命令方式將那個int變量強制設(shè)置，提前出現(xiàn)49.7天問題。
- 當現(xiàn)場的一個網(wǎng)絡(luò)包導致了內(nèi)核模塊的crash，可以使用scapy來模擬這個異常包來復現(xiàn)。
- 當一個問題的出現(xiàn)可能是由于文件的更替（或者其他觸發(fā)條件）導致，就可以將更替的頻率增大，已驗證問題分析的方向正確。?
- 記得還有一個硬件同步相關(guān)的問題，老GSM的一個產(chǎn)品，發(fā)現(xiàn)同步問題，不好復現(xiàn)。最后的復現(xiàn)步驟是將網(wǎng)卡所光纖人工彎折一下，就可以復現(xiàn)問題，導致信號上有些偏差。
- 之前碰到過一個內(nèi)核hang住的情況，后來發(fā)現(xiàn)是注冊的trace point導致的，但是產(chǎn)品里的trace point有些復雜，后來單獨寫了一個輕裝trace point的內(nèi)核模塊，很輕松復現(xiàn)問題。https://mzhan017.blog.csdn.net/article/details/131119252
復現(xiàn)問題需要注意：
不要在使用調(diào)試工具時，讓調(diào)試工具的運行影響了問題的復現(xiàn)，比如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.文章來源地址http://www.zghlxwxcb.cn/news/detail-602205.html
到了這里，關(guān)于[問題處理] 簡化問題復現(xiàn)步驟的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
