話說回來，可能有人要問了，怎么黑產(chǎn)就能弄出一個不存在的優(yōu)惠券？我不了解具體漏洞細節(jié)，但從目前的信息來看，這個券在系統(tǒng)里肯定確實存在，有可能是內(nèi)部測試或者某些特定條件下可以領(lǐng)。然而 估計程序上并沒有做更多的領(lǐng)取條件限制，只是隱藏了訪問這個券的公開入口 。就好比是有人在銀行的某個保險柜里放了一筆錢，但沒有上鎖，覺得別人不知道這里藏了錢就沒事。后來有人發(fā)現(xiàn)了，就把保險柜的位置告訴了所有人，那么每個人都可以過來拿錢。

講道理，我沒上鎖也不代表你就能隨便拿。但從一個開發(fā)者的角度來看， 不做必要的權(quán)限驗證、規(guī)則判斷，以及特殊情況下的異常處理，僅僅通過隱藏公開入口來限制領(lǐng)取，這是極為低級的失誤 。讓人忍不住想吐槽：拼多多那么有錢，招來的程序員咋這么不專業(yè)？而且為什么凌晨爆發(fā)的問題，到上午9點才封上，下架個優(yōu)惠券也這么難嗎？

不過吐槽歸吐槽，不可否認的是， 軟件的 bug、缺陷、漏洞，這是永遠不可能杜絕的 。被人們看到的漏洞往往很低級，但考慮到軟件產(chǎn)品的復雜度，以及開發(fā)進度、需求變更等客觀情況，漏洞也并不是想象中那么容易避免。就在半個月前，知名民宿平臺 Airbnb 就爆出過類似的大 bug：當你支付房費的時候， 如果切換貨幣，價格并沒有跟著變 。你可以拿2000越南盾支付原價2000歐元的民宿。在計算機史上，類似的問題數(shù)不勝數(shù)，舉幾個知名例子：

1994年，英特爾的奔騰CPU芯片被曝出缺陷： 會在精度要求很高的數(shù)學計算上出現(xiàn)問題 ，比如 (4195835/3145727)*3145727-4195835 這樣的結(jié)果計算出來不為 0。最后英特爾為此付出 4 億多美元更換芯片 。就在大約一年前，英特爾的另一個芯片漏洞也波及了市面上絕大多數(shù)的電腦、手機和云服務(wù)器，這個我去年有文章科普過：關(guān)于這波IntelCPU漏洞，我見過最形象易懂的解釋

1999年，美國航天局的 火星極地登陸器在著陸時失聯(lián) 。后經(jīng)調(diào)查認定，故障原因很可能是一個 決定關(guān)閉推進器的數(shù)據(jù)位設(shè)置邏輯有誤 。

1991年海灣戰(zhàn)爭中，美國的 愛國者導彈防御系統(tǒng)失效 ，未能成功攔截導彈致 28名美軍士兵被炸死 。原因經(jīng)分析后，是因為 系統(tǒng)時鐘數(shù)據(jù)精度不夠 ，存在微小誤差，長時間運行后誤差積累放大，在攔截過程中可能引起數(shù)百米的偏差。

千年蟲問題 ：上世紀早期的軟件開發(fā)者為了節(jié)省空間， 使用兩位數(shù)記錄年份 。然而到2000年時，一些軟件仍在使用，使得99年之后變成00年，引發(fā)異常。有人估計全球為此花費的相關(guān)費用有 數(shù)億美元 。

由此看來，程序員還真是一個高危職業(yè)，一不小心就可能造成巨大損失。 如果你沒有生產(chǎn)過嚴重的 bug，可能是你運氣真的好，但更可能是你代碼寫得還不夠多。 對此我自己也是不少血淚教訓。那面對難以避免的 bug，開發(fā)者應(yīng)該怎么辦呢？我的建議：

1、重視軟件測試

正因為漏洞的普遍存在，以及可能帶來的潛在損失，所以軟件測試是即為必要的。除了需要有專門的測試人員把關(guān)，每個合格的開發(fā)者也應(yīng)該是一個合格的測試者，正如有句話說的： 一個優(yōu)秀的程序員就是那種即使是過單行道都要往兩邊看的人 （Doug Linder）。對于自己寫出的代碼，你自己是最了解的人。在開發(fā)早期就做好 單元測試 ，可以大大提升程序的穩(wěn)定性，降低后期測試的成本。當你寫的每個函數(shù)都通過單元測試，成為一個功能模塊時，再進行 集成測試 ；最后對整個完成的產(chǎn)品進行 系統(tǒng)測試 。

企業(yè)更是應(yīng)當重視軟件測試的必要性，如果只追求功能快速迭代，拼命趕進度，最后有可能得不償失。因為 bug 或操作失誤導致企業(yè)破產(chǎn)的例子也不鮮見。

測試的方式一般分為 黑盒測試 和 白盒測試 。上面說的開發(fā)者自測一般是白盒測試，即你對代碼的實現(xiàn)邏輯是已知的。白盒測試在選取測試用例時，講究對 代碼邏輯的覆蓋 ，即你選用的測試數(shù)據(jù)要能保證讓每一行代碼每一個條件都被執(zhí)行到，尤其是一些 邊界條件 。而黑盒測試是指不考慮代碼邏輯，僅關(guān)注程序的功能和輸入輸出。軟件發(fā)布測試版讓用戶使用，就屬于一種黑盒測試。在黑盒測試時，講究對 等價類的覆蓋 ，通俗地講就是覆蓋到所有可能發(fā)生的情況，包括正常的和不正常的，同樣要注意邊界。

我們 碼上行動 有個期中項目，就是對教程中“猜數(shù)字”游戲的擴展，增加多次游戲的功能?？此坪唵蔚墓δ?，實現(xiàn)起來不難，但幾乎大部分同學提交的代碼都會存在一定的缺陷。這就是由于編程新手缺乏測試的意識和方法，一般只會按照自己的設(shè)想輸入，發(fā)現(xiàn)結(jié)果對了就認為大功告成。其實不然，你得考慮用戶如果猜的數(shù)字超過范圍怎么辦？輸入了小數(shù)怎么辦？輸入空白怎么辦？輸入了字符怎么辦？……

那測試做到什么程度才到位？我覺得知乎上有人分享的一個笑話很到位：

一個測試工程師走進一家酒吧，要了一杯啤酒  
一個測試工程師走進一家酒吧，要了一杯咖啡  
一個測試工程師走進一家酒吧，要了0.7杯啤酒  
一個測試工程師走進一家酒吧，要了-1杯啤酒  
一個測試工程師走進一家酒吧，要了2^32杯啤酒  
一個測試工程師走進一家酒吧，要了一杯洗腳水  
一個測試工程師走進一家酒吧，要了一杯蜥蜴  
一個測試工程師走進一家酒吧，要了一份asdfQwer@24dg!&*(@  
一個測試工程師走進一家酒吧，什么也沒要  
一個測試工程師走進一家酒吧，又走出去又從窗戶進來又從后門出去從下水道鉆進來  
一個測試工程師走進一家酒吧，又走出去又進來又出去又進來又出去，最后在外面把老板打了一頓  
一個測試工程師走進一  
一個測試工程師走進一家酒吧，要了一杯燙燙燙的錕斤拷  
一個測試工程師走進一家酒吧，要了NaN杯Null  
1T測試工程師沖進一家酒吧，要了500T啤酒咖啡洗腳水野貓狼牙棒奶茶  
1T測試工程師把酒吧拆了  
一個測試工程師化裝成老板走進一家酒吧，要了500杯啤酒并且不付錢  
一萬個測試工程師在酒吧門外呼嘯而過  
一個測試工程師走進一家酒吧，要了一杯啤酒";DROP TABLE 酒吧  
測試工程師們滿意地離開了酒吧。然后一名顧客點了一份炒飯，酒吧炸了  
via 知乎 @今日飛雪  
https://www.zhihu.com/question/20034686/answer/52063718

更多關(guān)于測試的知識，歡迎大家找本《 軟件測試 》相關(guān)書籍看一看，這個真的很有必要。

2、相信墨菲定律

墨菲定律：如果你擔心某種情況發(fā)生，那么它就更有可能發(fā)生。

測試做得再好，也只能是減小 bug 的概率。作為一個開發(fā)者，你還是要認清現(xiàn)實，做好最壞的打算。

如果你要上線新功能，那很可能導致宕機

如果你要更新數(shù)據(jù)庫，那很可能會丟失數(shù)據(jù)

如果你沒有檢查備份，那很可能它就恢復不了

如果你搞一個促銷活動，那很可能會被羊毛黨擼死

如果系統(tǒng)出現(xiàn)了漏洞，那很可能是在半夜

……

但真當你意識到這些絕望的時候，反倒可以提前做好應(yīng)急預案，將損失限制在最小。如果拼多多在設(shè)置出100元無門檻券的時候就相當虎視眈眈的黑產(chǎn)羊毛黨，可能事情就不會這樣。不過也許現(xiàn)在就是他們的應(yīng)急預案也說不定呢：控制損失的同時還賺了一大波曝光。世事難料??！

換個角度，能造成巨大損失也是一種幸運。相比之下，你的產(chǎn)品掛了兩天都沒人發(fā)現(xiàn)，域名過期了都沒人跟你搶，那才叫悲慘。所以最后， 希望各位有朝一日都能參與影響巨大的項目 ，但要有安全意識，千萬別捅出大簍子

════

其他文章及回答：

如何自學Python | 新手引導 | 精選Python問答 | Python單詞表 | 人工智能 | 爬蟲 | 我用Python | requests | 計算機視覺 | 字符播放器 | 一圖學Python

歡迎搜索及關(guān)注公眾號： Crossin的編程教室