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