淺談如何寫出一個讓(坑)人(王)很(之)難(王)發現的bug

該文章內容來自腳本之家，原文連接：https://www.jb51.net/news/598404.html

程序員的平常三件事：寫bug、改bug、背鍋。連程序員都自我調侃道，爲何天天都在加班？由於個人眼裏常含bug。

那麼如何寫出一個讓(坑)人(王)很(之)難(王)發現的bug呢？

一、 新手開發+新手測試=無敵巨坑

有一天凌晨，某組的程序員們被電話轟炸醒了。用戶紛紛投訴本身的業務數據離奇消失了！

大夥排查半天，原來是新來的小王埋的坑。他三個月前開發的定時任務出bug了！

那時剛來的小王刷刷地將代碼寫完後，手把手教新來的測試實習妹子怎樣測試這塊代碼，估計是妹子還沒搞清楚裏面的邏輯時便稀裏糊塗地將代碼上線了。

萬萬沒想到這bug隱藏這麼久，因爲錯誤的邏輯致使錯誤的數據，錯誤的數據致使任務死循環執行，當執行的時間過長，到某個點時，系統如汽水開瓶般「砰」地崩了。

業務不熟致使邏輯理解有問題，是大部分新人都會存在的問題。此時最好安排個有經驗的測試「調教」下，下降bug發生率。

二、不考慮系統拓展性，怎麼方便怎麼寫

史上最出名的「千年蟲」bug令全世界恐慌，甚至傳出「世界末日」的謠言。

緣由竟讓人哭笑不得：當時的程序員沒考慮到軟件會被使用至21世紀，爲了節省內存省略掉表明年份的前兩位數字」19」，或者默認前兩位爲」19」。

「千年蟲「千年一遇，可平常關於時間的低級bug常常發生，並且一般等到一段時間後的某個特定時間點才暴露出來，讓人防不勝防。

例如正則只匹配了「16」，「17」年，等到18年零點到來問題才暴露。

關於時間的bug很是多，大到閏年、夏令時、節假日、時區等，小到時間格式，每一年都會碰到不當心遺漏的時間bug，因此不少公司對時間的通用測試用例就有許多條。

除了時間問題，程序員若是隻考慮本次需求或者單個系統時，經常將字段設置不正確，後續業務拓展或者和別的系統交互時發現字段不夠用，只能修改字段長度了。

三、不考慮上下游系統，招呼不打便隨意改接口

曾遇到A系統上線後，大夥迴歸A系統正常運行後，正樂滋滋地鬆一口氣之際，原本好端端運行的B系統忽然壞了，B組人排查半天發現，原來是A提供的接口改了，B系統不兼容新接口。

大概程序員走過最長的路即是背鍋之路了。

2005 年 12 月 8 日瑞穗證券的交易員因手誤輸入錯的股價，2 分鐘後這人試圖經過交易軟件撤銷這筆賣單。但是連續輸入 3 次撤單指令，都被東證的交易系統拒絕了。此次事故形成400 億日元的損失。

後來查明是交易系統出 bug了，程序員在 2000 年某次程序修改時不當心埋進去的。

因此不少公司會嚴格要求在程序修改後必須通過嚴格的迴歸測試，來驗證對其餘業務流程有沒有影響。

四、複製、粘貼，我閉着眼，有bug看不見，debug了沒？

已發佈已驗證的代碼，是安全可靠的，是能夠拿來即用的，無需質疑，不用浪費時間去調試，這是程序員的慣性思惟。

被記入史上bug王之一的阿麗亞娜5型自毀事件就是因代碼複用而致使的。1996年6月4日，阿麗亞娜5型運載火箭發射點火後，因爲bug，在發射39秒後火箭發生偏軌，最終被迫引爆自毀。

這件事情發生的緣由是由於5型火箭是基於4型火箭開發的，發射系統的代碼程序員也直接照搬4型的。

該段代碼在4型火箭中被反覆驗證，但在5型卻沒有進行驗證。實際上4型的飛行條件和5型的飛行條件大相徑庭，最終致使事故發生，這次事故損失3.7億美圓。

有測試工程師說，最懼怕開發說此次沒啥改動，跟線上某功能差很少。這時候反而要細心驗證代碼的正確性。

這是由於「安全心理」做祟：程序員直覺已信任上線的代碼是正確的，便直接複製過來用，不會再花時間自測，由於這是「對的」，「毋庸置疑」的。

此時測試人員不可輕易聽信開發的話，更要嚴謹對待，畢竟程序員的三大謊話有：沒問題的；只改了兩行代碼；和線上同樣。

程序員花30分鐘寫程序，花2小時改bug。bug，子子孫孫無窮盡也。因此在面對測試人員的質疑時，程序員們必定要保持鎮定，該甩鍋時速速甩掉：這是歷史問題，我沒動過；剛剛在我這是好的，你環境配錯了；你重啓試試……

最後一招是兩個字：我改！