程序員的踩坑經驗總結（一）：如何把Bug的偶現變必現

程序員的踩過的坑也是能夠分類的，很常見又很難解決的一類是偶然的現象，表現起來比較怪異。

而把一個問題Bug的偶現變成必現，是開發人員的一種能力。我認爲也應該是測試人員的一種能力，可是各個公司要求不同吧。我在華爲作過測試，雖然時間過去好久了，可是當時學到的方法影響至今。總之仍是那句話，對你要求高的才讓你成長更快，因此不要辜負對你嚴格的人！

 

最近有幾個Bug和小夥伴成功的從偶然的現象變成必然的現象，因此仍是記錄下這種有成就感的心情吧。早在華爲測試的時候就能夠幫開發定位問題了，後面到如今公司也時不時的把Bug的偶現變成必現，而如今帶人了更多的是傳授經驗。

 

案例一

應該在去年最後一個季度，咱們有個現場的Bug很怪異。時不時的有些文件出現亂碼，咱們是音視頻文件，很大幾百M，有特定的格式以便於讀取。這些亂碼的文件就是不按規則來，致使整個文件讀不了！也不是全部的目錄下，也不是一個目錄下全部的文件，就是時不時冒出來搗亂！初看，就像是個很是頑皮孩子和你躲貓貓！

我和小夥子說，看日誌吧。「日誌都很正常」小夥子回答。我又說「那就加日誌吧」，小夥子一臉懵懂。我對日誌應該用「高度重視」這個詞，我認爲日誌是除了代碼外第二大武器，調試和定位的強大武器。有時間能夠寫寫日誌！固然這個見仁見智了，有人喜歡gdb、windbg，這都沒問題。不過話又說回來，日誌在系統軟件仍是應用軟件都是遍地開花！你看着辦：）回到正題，我和小夥子一番討論後，小夥子加了日誌。我記得小夥子第一次對文件和緩衝區進行讀寫操做，非常陌生，由於代碼仍是咱們老一代人寫的。文件怎麼循環讀，緩衝怎麼循環寫，哈哈。如今應該都沒問題了。因此有Bug沒什麼，我認爲快速鍛鍊一我的有兩種途徑，項目開發和改Bug。日誌慢慢的能用上了，從新編庫、替換庫、運行和等待。小毛孩終於被逮住了。

緣由是和視頻源的操做有關係，這個視頻源帶有音頻，並且時不時的被操做和被修改！而就在修改的時候，文件的偏移量也被重置了。懂文件的知道了，一旦偏移量錯亂了，後面全跟着變了。這裏的關鍵是日誌如何加，須要根據文件的特色，咱們文件大部分是順序寫，有一部分是隨機寫。日誌的添加就是要根據變化的時候，記錄各個變量。而這個Bug還有一點點規律，就是亂碼從除了文件頭信息後的地方開始錯亂的。因此每次變化的時候從新seek文件，是否從這個位置開始的，一旦使這裏開始就加ERROR級別的日誌。只要後面一旦出現就能夠逮捕了！

後面再回到看代碼，發現確實是seek出問題了！查歷史記錄，有改動，考慮新加驅動庫和元數據類型兩種的狀況，卻沒有考慮通用的狀況！好吧，而改動之時我正在休產假了。通用的狀況都忘了考慮，怎麼會偶現呢？問題的根源仍是和音頻有關，在咱們行業音頻通常用的很少，絕大部分是視頻業務。因此，按通常常規的測試，再加上新加代碼估計都沒有進行迴歸測試，更不用說有音頻的迴歸測試了，問題就這樣拖到了現場。

只要緣由找到了，後面解決起來就固然容易了。而這個時候，我再看了下原來的日誌，實際上是有提示音頻的變化的，只是級別不高。因此當時我再次叮囑」多看日誌「！

  

案例二

最近，有個現場的項目在視頻回放的時候出現了崩潰！也沒發現規律，正常操做都不會，無規律很是頻繁的操做控制視頻回放偶爾出現。

用gdb分析CORE文件，崩潰的位置是回放退出時釋放內存的時候。「嗯，內存越界了！」當時我意識到。但是小夥子開始對着釋放內存的函數冥思苦想，和我探討，是否是該處指針用的不對。可是從代碼分析，上下文都很很正常。「你想一想正常狀況下，這裏沒問題，對吧。出現越界不必定是最後的指針的問題，而是以前就被其餘給破壞了，真正要釋放時發現該處內存沒法訪問了。因此還須要看其餘變量的值」我因而說。小夥子再次打印this指針下各個變量的值，發現幀長度明顯不對，居然長達6M多。事實上通常較長的I幀也就200K左右，相差幾個數量級。

看日誌，其實已經有打印幀長度達到6M多了（再次論日誌的重要性）！下一個問題，緣由是什麼，爲何會有6M多呢，基本不可能的事。搜索有關幀長度全部的變量使用。原來是從網絡接收的時候，大小端變化的函數被改變了位置，日後挪了！先使用了變量（這時的變量就是一個異常的值）再轉換。那不出問題才奇怪呢！那爲啥正常狀況下沒有？這段代碼是後面加的需求，咱們的幀類型加多了。因此這是不一樣通常的幀類型，是智能元數據。固然能夠再總結下，論代碼審查的重要性！而上面的Bug也是由於新加代碼致使的。

其實內存越界不太好查，有點神出鬼沒，不知道哪一個時候就破壞了內存。此次其實還算好！日誌有打印6M的異常。並且崩潰的堆棧顯示幾回都是同一個地方，說明局部性原理用的還能夠。

 

寫到這裏有人會說，你沒有把偶像變成必現了！哈哈，都找到緣由了，須要重現還不容易嗎？

偶現變必現實際上是把測試輸入範圍或者說輸入條件縮小甚至是固定到某個條件或者某種狀況。

不是模模糊糊的，對輸入條件一問三不知，「我就測試出問題了！？」測試還懟開發。我曾經還屢次碰到過測試提的問題，結果發現是測試環境都搞錯了。好了，不吐槽了。形成這種現象和公司氛圍有很大關係。

再回到開發，其實回來再看上面兩個問題，現象很怪異，可是結果和緣由都很簡單。因此總結一句：怪異現象的背後總有一個愚蠢的初級Bug。這句話引自一位高人，我深覺得然。本身常說的是，看上去越詭異的現象，背後的緣由每每越簡單。事實上，咱們常常碰到一些：配置項不對，亂象叢生的問題，有時甚至系統都跑不起來。

因此也不用太擔憂，多分析日誌，固然前提是：多作代碼審查、多加有效的日誌！

對測試的建議是多瞭解業務背後的原理，能夠多去參與問題的分析和定位。

但願對你排查問題有所幫助！