昨天看到一個大新聞： 拼多多在20日凌晨出現漏洞，用戶可以領100元無門檻優惠券 。一夜之間，被黑產、羊毛黨和聞訊而來的吃瓜羣衆薅了個底朝天，直到第二天上午9點纔將優惠券下架。網上傳言這一波損失超過200億，但拼多多官方很快回應： 漏洞確有此事，但損失沒這麼多，不到千萬，已報警，正在追回 。
拼多多本來就是家爭議頗大的公司，這次事件更是引發輿論熱議。據說，這個優惠券本不能正常訪問，而是有做黑產（利用互聯網不正當牟利）的人 挖到了一個漏洞，使得能從某個二維碼入口領取到這個券，並把這個券散發出去。你別以爲這是想劫富濟貧，他們只是想拉足夠的炮灰墊背 ，同時自己迅速將這個券兌換成話費、Q幣等，以此獲利。這事情從法律角度來說算得上“ 不當得利 ”，就算涉事賬面金額真的有200億，大部分也是可以追回的。所以，沒吃到瓜的羣衆別懊悔，反倒是真佔了便宜的，得考慮考慮了。
話說回來，可能有人要問了，怎麼黑產就能弄出一個不存在的優惠券？我不瞭解具體漏洞細節，但從目前的信息來看，這個券在系統裏肯定確實存在，有可能是內部測試或者某些特定條件下可以領。然而 估計程序上並沒有做更多的領取條件限制，只是隱藏了訪問這個券的公開入口 。就好比是有人在銀行的某個保險櫃裏放了一筆錢，但沒有上鎖，覺得別人不知道這裏藏了錢就沒事。後來有人發現了，就把保險櫃的位置告訴了所有人，那麼每個人都可以過來拿錢。
講道理，我沒上鎖也不代表你就能隨便拿。但從一個開發者的角度來看， 不做必要的權限驗證、規則判斷，以及特殊情況下的異常處理，僅僅通過隱藏公開入口來限制領取，這是極爲低級的失誤 。讓人忍不住想吐槽：拼多多那麼有錢，招來的程序員咋這麼不專業？而且爲什麼凌晨爆發的問題，到上午9點才封上，下架個優惠券也這麼難嗎？
不過吐槽歸吐槽，不可否認的是， 軟件的 bug、缺陷、漏洞，這是永遠不可能杜絕的 。被人們看到的漏洞往往很低級，但考慮到軟件產品的複雜度，以及開發進度、需求變更等客觀情況，漏洞也並不是想象中那麼容易避免。就在半個月前，知名民宿平臺 Airbnb 就爆出過類似的大 bug：當你支付房費的時候， 如果切換貨幣，價格並沒有跟着變 。你可以拿2000越南盾支付原價2000歐元的民宿。在計算機史上，類似的問題數不勝數，舉幾個知名例子：
- 1994年，英特爾的奔騰CPU芯片被曝出缺陷： 會在精度要求很高的數學計算上出現問題 ，比如 (4195835/3145727)*3145727-4195835 這樣的結果計算出來不爲 0。最後英特爾爲此付出 4 億多美元更換芯片 。就在大約一年前，英特爾的另一個芯片漏洞也波及了市面上絕大多數的電腦、手機和雲服務器，這個我去年有文章科普過：關於這波IntelCPU漏洞，我見過最形象易懂的解釋
- 1999年，美國航天局的 火星極地登陸器在着陸時失聯 。後經調查認定，故障原因很可能是一個 決定關閉推進器的數據位設置邏輯有誤 。
- 1991年海灣戰爭中，美國的 愛國者導彈防禦系統失效 ，未能成功攔截導彈致 28名美軍士兵被炸死 。原因經分析後，是因爲 系統時鐘數據精度不夠 ，存在微小誤差，長時間運行後誤差積累放大，在攔截過程中可能引起數百米的偏差。
- 千年蟲問題 ：上世紀早期的軟件開發者爲了節省空間， 使用兩位數記錄年份 。然而到2000年時，一些軟件仍在使用，使得99年之後變成00年，引發異常。有人估計全球爲此花費的相關費用有 數億美元 。
由此看來，程序員還真是一個高危職業，一不小心就可能造成巨大損失。 如果你沒有生產過嚴重的 bug，可能是你運氣真的好，但更可能是你代碼寫得還不夠多。 對此我自己也是不少血淚教訓。那面對難以避免的 bug，開發者應該怎麼辦呢？我的建議：
1、重視軟件測試
正因爲漏洞的普遍存在，以及可能帶來的潛在損失，所以軟件測試是即爲必要的。除了需要有專門的測試人員把關，每個合格的開發者也應該是一個合格的測試者，正如有句話說的： 一個優秀的程序員就是那種即使是過單行道都要往兩邊看的人 （Doug Linder）。對於自己寫出的代碼，你自己是最瞭解的人。在開發早期就做好 單元測試 ，可以大大提升程序的穩定性，降低後期測試的成本。當你寫的每個函數都通過單元測試，成爲一個功能模塊時，再進行 集成測試 ；最後對整個完成的產品進行 系統測試 。
企業更是應當重視軟件測試的必要性，如果只追求功能快速迭代，拼命趕進度，最後有可能得不償失。因爲 bug 或操作失誤導致企業破產的例子也不鮮見。
測試的方式一般分爲 黑盒測試 和 白盒測試 。上面說的開發者自測一般是白盒測試，即你對代碼的實現邏輯是已知的。白盒測試在選取測試用例時，講究對 代碼邏輯的覆蓋 ，即你選用的測試數據要能保證讓每一行代碼每一個條件都被執行到，尤其是一些 邊界條件 。而黑盒測試是指不考慮代碼邏輯，僅關注程序的功能和輸入輸出。軟件發佈測試版讓用戶使用，就屬於一種黑盒測試。在黑盒測試時，講究對 等價類的覆蓋 ，通俗地講就是覆蓋到所有可能發生的情況，包括正常的和不正常的，同樣要注意邊界。
我們 碼上行動 有個期中項目，就是對教程中“猜數字”遊戲的擴展，增加多次遊戲的功能。看似簡單的功能，實現起來不難，但幾乎大部分同學提交的代碼都會存在一定的缺陷。這就是由於編程新手缺乏測試的意識和方法，一般只會按照自己的設想輸入，發現結果對了就認爲大功告成。其實不然，你得考慮用戶如果猜的數字超過範圍怎麼辦？輸入了小數怎麼辦？輸入空白怎麼辦？輸入了字符怎麼辦？……
那測試做到什麼程度纔到位？我覺得知乎上有人分享的一個笑話很到位：
一個測試工程師走進一家酒吧，要了一杯啤酒
一個測試工程師走進一家酒吧，要了一杯咖啡
一個測試工程師走進一家酒吧，要了0.7杯啤酒
一個測試工程師走進一家酒吧，要了-1杯啤酒
一個測試工程師走進一家酒吧，要了2^32杯啤酒
一個測試工程師走進一家酒吧，要了一杯洗腳水
一個測試工程師走進一家酒吧，要了一杯蜥蜴
一個測試工程師走進一家酒吧，要了一份asdfQwer@24dg!&*(@
一個測試工程師走進一家酒吧，什麼也沒要
一個測試工程師走進一家酒吧，又走出去又從窗戶進來又從後門出去從下水道鑽進來
一個測試工程師走進一家酒吧，又走出去又進來又出去又進來又出去，最後在外面把老闆打了一頓
一個測試工程師走進一
一個測試工程師走進一家酒吧，要了一杯燙燙燙的錕斤拷
一個測試工程師走進一家酒吧，要了NaN杯Null
1T測試工程師衝進一家酒吧，要了500T啤酒咖啡洗腳水野貓狼牙棒奶茶
1T測試工程師把酒吧拆了
一個測試工程師化裝成老闆走進一家酒吧，要了500杯啤酒並且不付錢
一萬個測試工程師在酒吧門外呼嘯而過
一個測試工程師走進一家酒吧，要了一杯啤酒';DROP TABLE 酒吧
測試工程師們滿意地離開了酒吧。然後一名顧客點了一份炒飯，酒吧炸了via 知乎 @今日飛雪
https://www.zhihu.com/question/20034686/answer/52063718
更多關於測試的知識，歡迎大家找本《 軟件測試 》相關書籍看一看，這個真的很有必要。
2、相信墨菲定律
墨菲定律：如果你擔心某種情況發生，那麼它就更有可能發生。
測試做得再好，也只能是減小 bug 的概率。作爲一個開發者，你還是要認清現實，做好最壞的打算。
- 如果你要上線新功能，那很可能導致宕機
- 如果你要更新數據庫，那很可能會丟失數據
- 如果你沒有檢查備份，那很可能它就恢復不了
- 如果你搞一個促銷活動，那很可能會被羊毛黨擼死
- 如果系統出現了漏洞，那很可能是在半夜
- ……
但真當你意識到這些絕望的時候，反倒可以提前做好應急預案，將損失限制在最小。如果拼多多在設置出100元無門檻券的時候就相當虎視眈眈的黑產羊毛黨，可能事情就不會這樣。不過也許現在就是他們的應急預案也說不定呢：控制損失的同時還賺了一大波曝光。世事難料啊！
換個角度，能造成巨大損失也是一種幸運。相比之下，你的產品掛了兩天都沒人發現，域名過期了都沒人跟你搶，那才叫悲慘。所以最後， 希望各位有朝一日都能參與影響巨大的項目 ，但要有安全意識，千萬別捅出大簍子
════
其他文章及回答：
如何自學Python | 新手引導 | 精選Python問答 | Python單詞表 | 人工智能 | 爬蟲 | 我用Python | requests | 計算機視覺 | 字符播放器 | 一圖學Python
歡迎搜索及關注公衆號： Crossin的編程教室
