程式設計師,你碰到過的最難調的Bug是什麼樣的?

博為峰網校發表於2018-11-16

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*10 8  *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難在你不敢改,那是你的修改方案沒有做好充分的分析。

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31407649/viewspace-2220413/,如需轉載,請註明出處,否則將追究法律責任。

相關文章