一個由"2020年1月7日 京東出現的重大 Bug 漏洞"引發的思考...

2020年1月7日，京東因爲優惠券設置錯誤，致使大量產品以0元或者超低價成交，而且發貨。網傳小家電被薅24萬件，損失損失金額高達7000多萬。不少網友表示收到貨了，在網上曬出到貨截圖。下面爲購買截圖：

以後，京東作出關於此事件的說明，將攔截訂單，召回發貨商品。

《關於2020-1-7，大量0元單活動說明》

尊敬的京東用戶你們好，由於1月7日優惠券設置錯誤緣由，致使大量產品以0元或者超低價的狀況下成交，而且發貨。

目前對此京東已經作出處理方案。

1，針對未發貨的訂單，京東已經作攔截處理，而且後續不會發貨。

2，針對已經發貨的產品，京東已經作出攔截處理，商品將會召回。

3，針對部分已簽收的訂單，若是您滿意手中的產品，能夠按照原價的8折購買，若是不滿意請直接取消，取消後配送員將在24小時內上門取回商品，感謝您的配合。

由於此次錯誤給您帶來的抱歉，京東深感歉意，全部被召回或者攔截的訂單，處理成功後系統會自動爲您發放一個20元的無門檻優惠券，做爲賠償。

感謝您對京東的支持，提早祝福各位新年快樂。

 

網上更是傳出京東負責小家電的項目組全體被開除，年終獎金補償沒有，甚至可能還會被京東法務起訴，被問責的消息！

不少IT從業者表示職業高危性，由於一個「不當心」，就天降「重大bug」，公司遭受重大損失，我的面臨賠償甚至坐牢的風險。

 

 

這裏不禁得讓我想起去年1月20號凌晨「拼多多薅羊毛事件」，一樣是優惠券的bug，用戶能夠直接領取一個無門檻的100元優惠券，全場通用(特殊商品除外)，有效期一年。羊毛黨半夜被同伴叫醒開始瘋狂薅羊毛。

以後，拼多多於20號上午9點左右把100元無門檻優惠券所有下架，以前領到未使用的優惠券也所有下架。並官方迴應稱，此事系黑灰產團伙利用平臺漏洞進行不正當牟利，公司已第一時間修復漏洞並向公安機關報案。網傳這起薅羊毛事件致使拼多多預計損失200億。

 

 

時間再往前回到17年，有網友爆料支付寶存在一個漏洞，陌生人有1/5的機會登陸你的支付寶，而熟人則可能100%登陸你的支付寶。

方法是這樣的：登陸手機帳號——忘記密碼——手機不在身邊——淘寶買過的東西9張圖片選1個——好友驗證9個好友圖片選1個——重置密碼——登陸成功。

登陸成功後擁有支付寶的所有功能。支持免密支付。甚至直接掃二維碼付款不用密碼。

從支付寶改密碼的步驟，像經過熟人、最近購買過的商品驗證，就存在很大的不安全性。對於熟人、甚至只是微信好友中的陌生人，獲取這些信息很容易！！

以後支付寶針對此事作出迴應：

後面有網友作出嘗試，發現依據網傳方式確實已經沒法找回登陸密碼了。也就是說支付寶已經升級系統，修復了這個漏洞。

 

啓示

以上的bug「事故」也只是由於一場熱搜，被廣大網友所熟知。實際軟件出現的bug「事故」要多得多，有些被及時修復未被暴露到公衆視野，有些暴露了只是未引發重大反響。回顧以上的這些軟件「事故」，不管是運營事故，仍是測試事故。在實際工做中，關於責任歸屬，相干利益，開發/測試/運營/風控可能都跑不脫。那做爲專業的軟件測試工程師，如何更有效地避免各個環節出漏子，因而有了如下思考：

• 具有過硬的專業技能，讓測試工做「無可挑剔」

做爲一名專業的軟件測試工程師，不能由於測試技能不到位致使bug「事故」。咱們首先要保證的是本職工做的嚴謹及無可挑剔，所以須要具有：

軟件測試技能：測試流程、bug管理流程、計劃/用例/報告編寫、linux、數據庫、相關測試工具使用；計算機網絡知識、定位問題及分析等；

編程能力：例如java、Python；儘量瞭解開發代碼的實現邏輯，代碼設計及結構、數據庫結構；

產品的業務知識及行業背景：除了業務自己以外，多瞭解整個行業背景，競品分析；依據不一樣的業務採起不一樣的測試策略及方法

• 跳脫傳統崗位職責，多立於產品設計思考

像以上的支付寶bug，並不能說開發實現邏輯或測試覆蓋上存在紕漏。而更多多是安全等級設計上的不完善。

咱們90%以上的測試工程師一切以產品爲尊，徹底按照產品需求進行測試。這樣錯了麼？貌似沒錯。但「測試至關於半個產品經理」不能只爲一句空話，要多立於產品設計自己去思考，去懷疑！

用戶權限須要多層控制嗎？這樣設計會不會暴露安全性問題？操做步驟對於小白用戶來講是否太繁瑣？敏感信息是否須要加密處理？畢竟產品經理或是開發人員並非什麼都能想到，且面面俱到的。

• 提早預見「手殘」行爲，提高安全風險意識

像京東的bug，也許可能只是運營的一次「手殘」行爲，優惠券設置錯誤了。但由於損失過大，做爲測試的咱們也難辭其咎。做爲一名專業的軟件測試工程師，尤爲是涉及錢的產品，咱們能夠儘可能去預見下可能出現的」手殘「行爲，而後多考慮若是」手殘「了，我們的系統是否具有應對」手殘「結果的處理能力。

好比像此次的優惠券bug，是否設定無門檻金額提醒？是否設定界面自動化巡檢功能？是否對數據異常進行監控並設定報警機制，同時是否具有及時撤銷功能...

• 基於用戶行爲，增強α、β測試

像不少問題，是須要特定的用戶場景纔會出現。當專業的測試團隊在測試時，會受到必定的用戶使用場景的限制。測試人員侷限於用戶個體，天然不會預想到全部用戶出現的真實場景。

這個時候，α、β測試可讓大量真實用戶參與其中，經過「人海戰術」人爲地遍歷更多真實用戶使用場景，並實時反饋真實場景中出現的bug。

這樣當產品正式發佈後，能夠提早規避掉不少用戶可能會碰到的問題。但這種測試方法，要基於產品自己數據安全性去作把控，不必定適用。

 

你們經過此次的bug「事故」，有什麼感想呢？歡迎留言~