據說拼多多因漏洞被薅了200億？- 談談軟件測試

昨天看到一個大新聞：拼多多在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，開發者應該怎麼辦呢？個人建議：

一、重視軟件測試

正由於漏洞的廣泛存在，以及可能帶來的潛在損失，因此軟件測試是即爲必要的。除了須要有專門的測試人員把關，每一個合格的開發者也應該是一個合格的測試者，正若有句話說的：一個優秀的程序員就是那種即便是過單行道都要往兩邊看的人（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

更多關於測試的知識，歡迎你們找本《軟件測試》相關書籍看一看，這個真的頗有必要。

二、相信墨菲定律

墨菲定律：若是你擔憂某種狀況發生，那麼它就更有可能發生。

測試作得再好，也只能是減少 bug 的機率。做爲一個開發者，你仍是要認清現實，作好最壞的打算。

• 若是你要上線新功能，那極可能致使宕機
• 若是你要更新數據庫，那極可能會丟失數據
• 若是你沒有檢查備份，那極可能它就恢復不了
• 若是你搞一個促銷活動，那極可能會被羊毛黨擼死
• 若是系統出現了漏洞，那極可能是在半夜
• ……

但真當你意識到這些絕望的時候，反倒能夠提早作好應急預案，將損失限制在最小。若是拼多多在設置出100元無門檻券的時候就至關虎視眈眈的黑產羊毛黨，可能事情就不會這樣。不過也許如今就是他們的應急預案也說不定呢：控制損失的同時還賺了一大波曝光。世事難料啊！

換個角度，能形成巨大損失也是一種幸運。相比之下，你的產品掛了兩天都沒人發現，域名過時了都沒人跟你搶，那才叫悲慘。因此最後，但願各位有朝一日都能參與影響巨大的項目，但要有安全意識，千萬別捅出大簍子

════

其餘文章及回答：

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

歡迎搜索及關注公*號：Crossin的編程教室