Bug無論是對於測試還是開發來說，應該都不陌生，雖然我們經歷的大部分bug有的被其他人修復了並且在互聯網分享出來了，這時候我們通過Stackoverflow、Baidu、Google等搜索引擎找到答案了。
但是我們在工作中也可能會遇到一些疑難的bug，這裡bug我們在搜素引擎上找不到解決方案，可能好幾天都不得其解，這些遲遲沒有解決的bug往往搞得人焦頭爛額。
那作為一個苦逼的程序員，究竟碰見過哪些高難度的bug呢？下面，我們來看看他們與bug的故事。
程序員小羅：
寫JS，自己手機沒電了，拿同事老張的安卓機調試，很簡單的獲取用戶微信暱稱，結果死活獲取不到，一直顯示為null。應該是跨平臺問題，因為之前在自己iPhone上是沒有bug的，拼命看api文檔，但是都沒提到這方面。急死我了。......剛剛老張告訴我他的暱稱就是null。......老張已被打死......前面誇張修辭，老張最後當然沒死，腿打斷了而已。
電商行業程序員小馬哥：
也談談自己遇到的一個bug吧，我之前是做電商的，某較大的電商平臺，突然有一天，C2C的店主反饋，看到的訂單不是自己的，看到後臺的商品列表也不是自己的。當時在睡午覺，看到這個問題，立馬嚇醒了，平時5個投訴就是一個故障單，那還都是一點體驗上的小問題，這種訂單混亂，商品混亂的錯誤，真是要緊急死了於是，主管，總監都來看這個問題，一群大佬在後面看著，趕緊找最近幾天的發佈，測試情況，一個個回退，一個個檢查，最後都無法解決問題，要知道時間一分一秒過去，半個小時還解決不了就要出大事了後續又有用戶來投訴，直接電話聯繫，遠程控制電腦，發現操作起來巨慢，於是順口問了一下用戶的網絡是什麼網絡。結果他說是："某城寬帶"，一瞬間，有點感覺了，繼續問其他幾個投訴的客戶都是"某城寬帶"，然後我們打電話到那個寬帶的運營商，得到的回覆是"年底了，為了省流量，他們做了一部分緩存"他們做了緩存做了緩存……緩存……存……可是為毛TM的動態請求還做緩存啊，修改商品和訂單的時候，隨機返回成功或者失敗 ......1.這個和時間戳也沒關，我們都加了token的，他們也忽略了
2. 你沒猜錯，他們把POST和GET動態請求也緩存了，就是說你提交了一個POST修改商品的請求，他從環緩存裡面隨便丟個回覆給用戶，用戶感覺修改成功了，其實請求根本沒到我們這邊，是的，就是這麼喪心病狂。
系統管理員老王：從前我是個系統管理員，平時去機房登錄服務器時都是站著操作。有一次腰疼，搬了個凳子坐在了機器前面，完蛋，死活登錄不進去，提示密碼錯誤。於是我站了起來，重新輸入了一次密碼，進去了。後來我覺得奇怪，於是抽時間做了測試，發現：只要一坐下，就密碼錯誤，站起來就好了。這個 Bug 在我的職業生涯中持續了好幾年，一直以為是什麼靈異事件。直到有一天公司升級設備給我換了個鍵盤。原來是老鍵盤上有兩個鍵裝反了，站著打字是看著鍵盤，坐著盲打就錯了，真的是很無語啊……
海外程序員Steven：
曾經聽說過一個讓人目瞪口呆的bug，分享給大家。該bug發生於麻省理工，當時其系統管理員接到統計系主任的求助電話，主任在電話中說："咱們的郵件系統無法發送距離 500 英里以外的地方，準確地說好像是 520 英里。"
此時的系統管理員內心是"毫無波瀾"的，嗯!
然後，他開始了漫長且苦逼的測試，最後發現郵件服務器操作系統(SunOS)被人更新了，因為操作系統發行版往往配備舊軟件，因此郵件軟件實際上是被降級了(Sendmail 8 -> Sendmail 5) ，最後的結果是：Sendmail5 試圖解析Sendmail8 的配置文件。
所以，為什麼一定是 500 英里呢?且看大神講解：
原因是這樣的，Sendmail 5面對陌生的配置文件，凡是不理解的部分都會忽略，凡是沒設置過的配置項自動設置成0。這樣其中有一個被設置成0，只一向就是（連接遠端SMTP服務器的超時時間）timeout to connect to the remote SMTP server。後來經過實驗，發現0秒的timeout會導致Sendmail在3毫秒後中斷連接。
所以，你會問為啥是500miles？
在當年，MIT的校園網是沒有那麼多router的，也就沒那麼多網絡延遲，所以連接一個遠端主機的時間大概是光所需的時間。於是3毫秒，就意味著：
0.003*3*108 *0.001*0.621=558.9000000000001
558英里。也就是588英里以外的服務器，都無法連接到，而588以內的服務器，都可以正常通信。
面對這些各式各樣難調的bug，那程序員如何快速高效的改 bug呢？
先根據情況試一下下面的步驟：
1. 換個環境試試
2. 換個用戶試試
3. 換個操作方式試試
4. 換一下數據試試
5. 換個瀏覽器試試
6. 換個版本試試
根據上的情況搞清楚下面這幾個問題：
1. 這個BUG什麼情況下出現？什麼情況下不出現？兩種情況的區別在哪裡？
2. 這個BUG之前沒有，現在出現了，中間都動了什麼？
3. 這個BUG生產環境出現測試環境不出現，兩個環境區別是什麼？
4. 同樣的功能，這樣操作沒有BUG，那樣有BUG，兩個操作的區別是什麼？這些問題搞清楚了，先嚐試採用代碼回退、配置調整、環境替換等方式驗證BUG是否會消失，然後再找其中的原因。
下面列出一些常見的疑難BUG類型以及每種BUG的診斷方法：
1. 輸出結果與預期不符，這種BUG一般都是由於代碼邏輯錯誤造成的，如果能在開發環境重現，最好解決方法就是單步調試，設定每一步代碼的預期結果，然後跟蹤判斷實際結果是否與預期結果一致。
2. 系統異常報錯，這種情況下需要提取日誌，找出錯誤堆棧信息，這時候最重要的事情是要把堆棧信息看懂、看完整，而且往往堆棧信息是一個套一個輸出的。
3. 系統Crash，這個問題常見的原因是負載過高、併發過高、或者配置錯誤。最常見的就是內存溢出。這時候要首先排除配置錯誤的原因，主要靠查看Crash Log來分析原因，再排查硬件、內存、網絡等方面的設置，看是否有配置錯誤的地方。再找不到就在測試環境用開發模式進行壓測和調試。
4. 系統響應緩慢，這種問題一般是存在資源競爭或者系統資源不足的情況，先檢查服務器內容、CPU、網絡情況，如果服務器壓力過大，排查應用系統負載情況是否異常，如果這些數據都正常，就需要排查代碼中的性能瓶頸。特別需要留意依賴第三方接口的情況，比如同步的方式發送郵件、發送短信、寫文件等。
總結：
bug千奇百怪，不是每個bug都需要經歷所有流程的。每個步驟都有它的難點。有些bug難在事發點的定位，比如多線程，異步邏輯中的bug；有些bug難在原因很難分析，多數是你看不懂代碼；有些bug難在你不敢改，那是你的修改方案沒有做好充分的分析。
閱讀更多 Atstudy網校 的文章
