程序員的踩過的坑也是可以分類的，很常見又很難解決的一類是偶然的現象，表現起來比較怪異。
而把一個問題Bug的偶現變成必現，是開發人員的一種能力。我認為也應該是測試人員的一種能力，但是各個公司要求不一樣吧。我在華為做過測試，雖然時間過去很久了，但是當時學到的方法影響至今。總之還是那句話，對你要求高的才讓你成長更快，所以不要辜負對你嚴格的人！
最近有幾個Bug和小伙伴成功的從偶然的現象變成必然的現象，所以還是記錄下這種有成就感的心情吧。早在華為測試的時候就可以幫開發定位問題了，后面到現在公司也時不時的把Bug的偶現變成必現，而現在帶人了更多的是傳授經驗。
案例一
應該在去年最后一個季度，我們有個現場的Bug很怪異。時不時的有些文件出現亂碼，我們是音視頻文件，很大幾百M，有特定的格式以便於讀取。這些亂碼的文件就是不按規則來，導致整個文件讀不了！也不是所有的目錄下，也不是一個目錄下所有的文件，就是時不時冒出來搗亂！初看，就像是個非常頑皮孩子和你躲貓貓！
我和小伙子說，看日志吧。“日志都很正常”小伙子回答。我又說“那就加日志吧”，小伙子一臉懵懂。我對日志應該用“高度重視”這個詞，我認為日志是除了代碼外第二大武器，調試和定位的強大武器。有時間可以寫寫日志！當然這個見仁見智了，有人喜歡gdb、windbg，這都沒問題。不過話又說回來，日志在系統軟件還是應用軟件都是遍地開花！你看着辦：）回到正題，我和小伙子一番討論后，小伙子加了日志。我記得小伙子第一次對文件和緩沖區進行讀寫操作，很是陌生，因為代碼還是我們老一代人寫的。文件怎么循環讀，緩沖怎么循環寫，哈哈。現在應該都沒問題了。所以有Bug沒什么，我認為快速鍛煉一個人有兩種途徑，項目開發和改Bug。日志慢慢的能用上了，重新編庫、替換庫、運行和等待。小毛孩終於被逮住了。
原因是和視頻源的操作有關系，這個視頻源帶有音頻，而且時不時的被操作和被修改！而就在修改的時候，文件的偏移量也被重置了。懂文件的知道了，一旦偏移量錯亂了，后面全跟着變了。這里的關鍵是日志如何加，需要根據文件的特點，我們文件大部分是順序寫，有一部分是隨機寫。日志的添加就是要根據變化的時候，記錄各個變量。而這個Bug還有一點點規律，就是亂碼從除了文件頭信息后的地方開始錯亂的。所以每次變化的時候重新seek文件，是否從這個位置開始的，一旦使這里開始就加ERROR級別的日志。只要后面一旦出現就可以逮捕了！
后面再回到看代碼，發現確實是seek出問題了！查歷史記錄，有改動，考慮新加驅動庫和元數據類型兩種的情況，卻沒有考慮通用的情況！好吧，而改動之時我正在休產假了。通用的情況都忘了考慮，怎么會偶現呢？問題的根源還是和音頻有關，在我們行業音頻一般用的不多，絕大部分是視頻業務。所以，按一般常規的測試，再加上新加代碼估計都沒有進行回歸測試，更不用說有音頻的回歸測試了，問題就這樣拖到了現場。
只要原因找到了，后面解決起來就當然容易了。而這個時候，我再看了下原來的日志，其實是有提示音頻的變化的，只是級別不高。所以當時我再次叮囑”多看日志“！
案例二
最近，有個現場的項目在視頻回放的時候出現了崩潰！也沒發現規律，正常操作都不會，無規律非常頻繁的操作控制視頻回放偶爾出現。
用gdb分析CORE文件，崩潰的位置是回放退出時釋放內存的時候。“嗯，內存越界了！”當時我意識到。可是小伙子開始對着釋放內存的函數左思右想，和我探討，是不是該處指針用的不對。但是從代碼分析，上下文都很很正常。“你想想正常情況下，這里沒問題，對吧。出現越界不一定是最后的指針的問題，而是之前就被其他給破壞了，真正要釋放時發現該處內存無法訪問了。所以還需要看其他變量的值”我於是說。小伙子再次打印this指針下各個變量的值，發現幀長度明顯不對，竟然長達6M多。事實上一般較長的I幀也就200K左右，相差幾個數量級。
看日志，其實已經有打印幀長度達到6M多了（再次論日志的重要性）！下一個問題，原因是什么，為什么會有6M多呢，基本不可能的事。搜索有關幀長度所有的變量使用。原來是從網絡接收的時候，大小端變化的函數被改變了位置，往后挪了！先使用了變量（這時的變量就是一個異常的值）再轉換。那不出問題才奇怪呢！那為啥正常情況下沒有？這段代碼是后面加的需求，我們的幀類型加多了。所以這是不同一般的幀類型，是智能元數據。當然可以再總結下，論代碼審查的重要性！而上面的Bug也是因為新加代碼導致的。
其實內存越界不太好查，有點神出鬼沒，不知道哪個時候就破壞了內存。這次其實還算好！日志有打印6M的異常。而且崩潰的堆棧顯示幾次都是同一個地方，說明局部性原理用的還可以。
寫到這里有人會說，你沒有把偶像變成必現了！哈哈，都找到原因了，需要重現還不容易嗎？
偶現變必現其實是把測試輸入范圍或者說輸入條件縮小甚至是固定到某個條件或者某種情況。
不是模模糊糊的，對輸入條件一問三不知，“我就測試出問題了！？”測試還懟開發。我曾經還多次碰到過測試提的問題，結果發現是測試環境都搞錯了。好了，不吐槽了。造成這種現象和公司氛圍有很大關系。
再回到開發，其實回來再看上面兩個問題，現象很怪異，但是結果和原因都很簡單。所以總結一句：怪異現象的背后總有一個愚蠢的初級Bug。這句話引自一位高人，我深以為然。自己常說的是，看上去越詭異的現象，背后的原因往往越簡單。事實上，我們經常碰到一些：配置項不對，亂象叢生的問題，有時甚至系統都跑不起來。
所以也不用太擔心，多分析日志，當然前提是：多做代碼審查、多加有效的日志！
對測試的建議是多了解業務背后的原理和邏輯，可以多去參與問題的分析和定位。
希望對你排查問題有所幫助！