上周，瑞幸道歉登上了熱搜榜，其原因又一次和價格扯上了關系。

4月18日，有網友反饋，瑞幸咖啡在餓了麼平台上出現超低價格，單價僅需要幾元一杯，而正是這麼便宜的價格，使得其在半小時内賣出逾40萬單。

在得到消息後，瑞幸第一時間宣布是因“誤操作”導緻的價格錯誤緊急取消異常訂單，道歉聲明發了，卻也有很多網友并不買賬，聲稱其實為惡意營銷，也因此輿論不斷，而沖上了熱搜。

在詳細看完事情的起因過程後，筆者發現，其根本原因竟和測試息息相關。

瑞幸咖啡最低價，4元買2杯拿鐵

1

4月18日上午，有許多用戶反饋瑞幸咖啡在餓了麼出現了巨額優惠，原價64元2杯的紅絲絨拿鐵隻需要6元，2-3塊錢就能下單一個“冰椰雲拿鐵大福套餐”，還可以疊加餓了麼紅包，一些新注冊的用戶甚至花1分錢就可以買到。

對于瑞幸這一低價活動，許多網友紛紛開始薅起了羊毛，僅僅半個小時就賣出逾40萬單，但大多數的用戶都在此之後遭到了“砍單”。

瑞幸在得知了此現象後，緊急調停，并第一時間在其官方微博發布道歉聲明稱此次失誤是由于餓了麼後台價格配置問題而引起的BUG，導緻瑞幸椰雲套餐價格短時内出現錯誤，之後将為本次退單用戶補發代金券。

消息一經發出後，引得許多網友不滿，紛紛吐槽，熱度一時間持高不下。

很多網友表示，這番操作究竟是否存在營銷性質，還值得商榷，然而無論是BUG營銷還是真工作失誤，毫無意外，對于此次的事件，測試員又一次背上了這一口大鍋。

其實這并不是測試員第一次為此等BUG營銷背鍋了，在不久前，星巴克也出現了 Bug，多名用戶的賬戶裡突然多了優惠券，官方回應稱正在搶修。

事實上，在我們日常工作中，也正是如此，在産品上線後，無論是否真的存在失誤，但出現側漏事件時，第一反應還是會聯想到是測試員的過錯。

如何避免測試完還有BUG？

2

很多測試的小夥伴都表示，經常會遇到這樣的問題，測試的周期很短，但當自己以及測試了好幾個版本交付後，卻依舊出現了BUG，最後免不了要背鍋。

雖然全世界的軟件研發理論都認為測試不能發現100％的bug且需要整個研發團隊需要對bug負責，但目前大多數的企業還是會将最大的過錯安在測試員人的身上，當我們遇到這種情況時，該如何有理有據的避免這種問題的産生呢？

無法改變大環境的規模制度，我們就隻能從提高自身入手，做到以下幾點，便即使真的出現了錯誤，也能減少背鍋量。

（1）制定充分有效的測試計劃

按照正常的測試流程，制定完整的測試計劃，其中包括，确定測試策略，确定測試系統（軟件和硬件），預估工作量（資源和時間進度計劃），評估時間進度風險并準備風險緩解計劃，準備并複查測試計劃文檔等内容，使得測試計劃不僅僅能夠帶來效率的提升，更能從基礎上保證測試質量。

（2）多方面準備

除了測試計劃，在整個項目進行的過程中，我們也需要随時掌握進度，經常與相關人員溝通改進，關注任何一項會影響到測試的改動，并随着項目的進程修改測試用例，長期和一個組程序員合作的小夥伴，也可以在每次的合作過程中，觀察了解每個程序員的代碼習慣，這樣在下次的合作過程中能夠更快的掌握他們的代碼錯誤。

（3）多用數據說話

用數據說話是最直觀也最省事的，在項目進展中，我們可以對每個BUG産生的原因做相應的分析，避免在日後的項目中遭遇同樣的BUG。

在進行整個項目測試過程中，我們可以進行測試coverage分析，産品bug分布，測試用例效率分析，測試效率分析，研發流程回顧等等分析，将整理的數據合整，萬一之後項目上線後仍出現了BUG，這也是我們所能向老闆展現的強有力數據支撐，并且，周密的測試計劃，也會讓老闆相信即使這次問題出現了，下一次你一定有能力篩選規避。

其次，還有一點也需要注意，很多測試員人害怕麻煩，或是和開發已經合作很多次了，遇到BUG就會通過口頭的方式和開發人員講一下，但不會提交缺陷報告，而開發人員認為這個BUG并不重要，不同意修改，最後就不了了之了。

最後上線了，出現問題時，還是測試員人背大鍋，因此，該上交的報告還是需要上交，不然口說無憑。

（4）BUG仲裁

在一個測試結束後，測試人員對于這個項目軟件質量都有了自己的一定判斷，是否達到質量要求，或是否發布上線，哪裡還存在風險等等，都需要将他們明确的寫出來。

比如當我們在測試的過程中遇到了特殊情況，如需求變更等，使得測試的周期不夠，那麼我們要在測試報告中建議延期發布。如果項目組要求一定要按時發布，這時候就需要BUG仲裁，與産品、開發、測試經理商量，哪些bug是一定要修改的，哪些又是允許帶到線上的，做到三方達成一緻，那麼線上再出問題，大家也都清楚知道，就不會産生什麼問題了。

（5）提高個人技術

最後一點，當然是萬變不離其宗的學習問題，當我們不斷提升自己的業務水平和用例設計水平，将各種情況都思考到，測試用例覆蓋更加全面，就不容易出現側漏。

在遇到問題時，解決後，進行重溫，同樣的坑别踩第二次，技術不足的學習補齊，流程不足的規範流程。将每一次失誤都當作一次提高的機會，留下深刻印象，也可以避免下一次犯錯。

平時可以多提升一下自己的代碼能力和自動化工具的能力，自己編寫一些腳本，這樣即使開發改代碼出現問題，我們也能夠更快更高效的發現問題。

寫在最後

3

測試員側漏背鍋，相信對于每個測試同學而言，都是“談虎變色”的事，但是實際工作中，側漏是不可能絕對避免的，我們隻能做到盡量減少側漏，并根據工作經驗的增加而減少側漏。

同時，在測試的時候，一定要仔細仔細再仔細，畢竟找出BUG，也是每個測試員的本職工作。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!