01
2020年1月7日，京東由於優惠券設定錯誤，導致大量產品以0元或者超低價成交，並且發貨。很多網友還表示收到貨了，在網上晒出到貨截圖。下面為購買截圖：
之後，京東做出關於此事件的說明，將攔截訂單，召回發貨商品。
《關於2020-1-7，大量0元單活動說明》
尊敬的京東使用者大家好，因為1月7日優惠券設定錯誤原因，導致大量產品以0元或者超低價的情況下成交，並且發貨。目前對此京東已經做出處理方案。
1，針對未發貨的訂單，京東已經做攔截處理，並且後續不會發貨。
2，針對已經發貨的產品，京東已經做出攔截處理，商品將會召回。
感謝您對京東的支援，提前祝福各位新年快樂。
網上更是傳出京東負責小家電的專案組全體被開除，年終獎金補償沒有，甚至可能還會被京東法務起訴，被問責的訊息！
很多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。
這樣當產品正式釋出後，可以提前規避掉很多使用者可能會碰到的問題。但這種測試方法，要基於產品本身資料安全性去做把控，不一定適用。