01

2020年1月7日，京東由於優惠券設置錯誤，導致大量產品以0元或者超低價成交，並且發貨。很多網友還表示收到貨了，在網上曬出到貨截圖。下面為購買截圖：

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

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

尊敬的京東用戶大家好，因為1月7日優惠券設置錯誤原因，導致大量產品以0元或者超低價的情況下成交，並且發貨。目前對此京東已經做出處理方案。

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

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

3，針對部分已簽收的訂單，如果您滿意手中的產品，可以按照原價的8折購買，如果不滿意請直接取消，取消後配送員將在24小時內上門取回商品，感謝您的配合。因為這次錯誤給您帶來的抱歉，京東深感歉意，所有被召回或者攔截的訂單，處理成功後系統會自動為您發放一個20元的無門檻優惠券，作為賠償。

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

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

很多IT從業者表示職業高危性，因為一個「不小心」，就天降「重大bug」，公司遭受重大損失，個人面臨賠償甚至坐牢的風險。

02

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

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

03

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

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

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

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

之後支付寶針對此事做出回應：

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

啟示

以上的bug「事故」也只是因為一場熱搜，被廣大網友所熟知。實際軟體出現的bug「事故」要多得多，有些被及時修復未被暴露到公眾視野，有些暴露了只是未引起重大反響。回顧以上的這些軟體「事故」，無論是運營事故，還是測試事故。在實際工作中，關於責任歸屬，開發/測試/運營/風控一個都跑不脫。那作為專業的軟體測試工程師，於是有了以下思考：

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

作為一名專業的軟體測試工程師，不能因為測試技能不到位導致bug「事故」。我們首先要保證的是本職工作的嚴謹及無可挑剔，因此需要具備：

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

編程能力：例如java、Python；儘可能了解開發代碼的實現邏輯，代碼設計及結構、資料庫結構；

產品的業務知識及行業背景：除了業務本身之外，多了解整個行業背景，競品分析；依據不同的業務採取不同的測試策略及方法

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

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

我們90%以上的測試工程師一切以產品為尊，完全按照產品需求進行測試。這樣錯了麼？貌似沒錯。但「測試相當於半個產品經理」不能只為一句空話，要多立於產品設計本身去思考，去懷疑！

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

• 提前預見「手殘」行為，提升安全風險意識

像京東的bug，也許可能只是運營的一次「手殘」行為，優惠卷設置錯誤了。但因為損失過大，作為測試的我們也難辭其咎。作為一名專業的軟體測試工程師，尤其是涉及錢的產品，我們可以儘量去預見下可能出現的」手殘「行為，然後多考慮如果」手殘「了，咱們的系統是否具備應對」手殘「結果的處理能力。

比如像這次的優惠卷bug，是否設定無門檻金額提醒？是否設定介面自動化巡檢功能？是否對數據異常進行監控並設定報警機制，同時是否具備撤銷功能,等。

• 基於用戶行為，加強α、β測試

像很多問題，是需要特定的用戶場景才會出現。當專業的測試團隊在測試時，會受到一定的用戶使用場景的限制。測試人員局限於用戶個體，自然不會預想到所有用戶出現的真實場景。

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

這樣當產品正式發布後，可以提前規避掉很多用戶可能會碰到的問題。但這種測試方法，要基於產品本身數據安全性去做把控，不一定適用。