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“事故”，有什麼感想呢？歡迎留