前言

             之前寫深入bug產生原因分析(一)，這裡主要從實際的專案bug中，總結出了實際bug的根源的幾個方面。這些問題的解決不但沒有對最終交付的產品有所裨益，反而耽誤了不少測試時間。現在就簡要做下梳理，並彙總自己在處理這些問題時的一些經驗。

             無效bug： 是針對有效bug來說的。無效bug是指需要花時間修復，但修復後又不會給即將交付的產品帶來使用者價值的bug。

那些耽誤了測試時間的無效bug來源

一、第三方問題

• 第三方的測試環境查資料時斷時續的
• 介面返回時有時無
• 第三方的敏感詞稽核服務的問題 
• 簡訊平臺傳送驗證碼問題
• 第三方機制問題。例如：xxx元件的介面程式碼更新機制
• 訊息出現積壓時，消費過慢時處理機制 
• 介面/服務呼叫超時
• 許可權控制-組織架構調整；
• 第三方資料隨著時間的推移資料變少，例如，1周前有資料A--利用資料A新建了資訊；現在沒有了資料A，導致系統獲取資料A有關資訊時異常；
• 基礎資料-線下與線上存在差異，例如： 線下-長沙市的商圈與線上不一致；

二、本身環境問題

服務偶爾出現超時(例如：訪問10次，2次出現超時)

測試資料存在髒資料(例如：之前測試的髒資料沒有及時刪除，導致測試時發現異常，不得不花時間排查問題)

測試環境不穩定，不能隨時ready(例如：一個緊急需求要上線，卻發現環境不能使用，此時不得不花時間重新搭建環境了)

三、技術本身限制

例如：OPPO+ UC瀏覽器，頁面下拉滑動不重新整理資料

四、與需求不符合

• 頁面跳轉
• 無結果時顯示
• 列表與詳情頁 時間資訊顯示 與需求不符合
• 多個端之間操作/互動行為不一致

五、違反了開發/實現規範

• xxx場景下，介面重複呼叫；
• 多端直接公用資料，導致一端登入資訊失效，另一端的異常；
• API不列印日誌了；
• 實現異常未考慮；

不規範問題帶來的嚴重問題：日常迭代中的開發人員不斷反覆重構/修改

如何有效避開無效bug,提升測試效率

遵循的核心原則：採用各種手段，儘可能減少測試被block/測試被幹擾

這裡的各種手段有：

1、針對第三方問題。 這裡是非自己可100%控制的問題，可以結合自己的需要考慮以下方案：

• mock掉第三方服務
• 對第三方監控，一旦發現問題，反饋給第三方
• 測試時，有意識將“和第三方密切互動的實現” 放到每輪的測試後半段進行。 這有點像答題，先易後難的套路了。

2、針對本身環境問題。這裡基本可以自己100%控制的問題了，可以參考使用如下方案：

• 測試環境由QA100%控制，並做統一的管理和清理
• 髒資料產生後，及時清理(屬於規範類了)
• 對測試資料進行檢測，一旦發現“不合格”資料，馬上清理
• 一套完整的隨時可用的測試環境，100%不耽誤測試需求

3、針對技術本身限制問題。這裡非人為因素可控制了，所以為了儘可能減少對測試進度的干擾，一旦發現與需求期望、使用者使用習慣不符，立即與開發人員確認，並對已經確認為此類問題的bug專門文件記錄，並對團隊成員一一週知到位，避免對此問題過度糾結。

4、針對與需求不符合問題。此類問題屬於產品需求對開發人員周知不到位，可以考慮採取：

• 周知團隊產品人員、開發人員此問題，協商方案
• 測試用例評審時強調

5、針對違反了開發/實現規範問題。此類問題屬於開發人員雖然對需求實現了，但由於規範沒有遵守，可能給後續產品帶來隱患，或增加後續技術的重構需求。此類問題，最好由開發人員制定相應的規範，並統一執行，可以考慮：

• 測試人員與開發人員共同商定規範，並落實到執行
• 對發現違反規範的問題，由具體人對原因進行分享

總結

            固定的測試周期內，無效bug佔據的時間越多，留給真正的bug暴露的時間就越少。這裡又回到了統一的質量控制問題了，無論bug暴露，還是質量控制都需要團隊成員共同努力，把交付穩定的產品作為每次迭代的最終目標。或許你意識到了這一點是一回事，而真正落實到行動上又是另一回事了，但無論如何，都要以自己業務和測試的實際需要為前提了。