Bug分析-part1

WHY爲何要作bug分析？

緣由一：藉助bug，提高測試人員對產品質量的總體把控 
從項目初期的產品需求PK，到開發階段的自測、迭代提測、集成上線提測，直至發佈後用戶反饋，能夠說bug幾乎貫穿了產品發展的各個階段。對於測試人員來講，用好手中的bug，提高對產品的理解，可以更高效、更有效的測試，從而把控質量風險，提高產品質量。 
緣由二：追本溯源，從新審視項目過程，推進優化 
有人說，產品一切bug的根源都是代碼。若是把產品的誕生看成一場馬拉松，那bug就是那些年咱們踩過的坑。從哪兒跌倒就從哪兒爬起來，經過分析找到bug產生的根因，思考如何從各個方面去優化改進，避免之後踩到相似的「坑」，下一場比賽才能跑的更快更遠。

HOW怎麼作bug分析？

第一步：怎麼選bug

bug的來源不少，有產品體驗、開發自測、測試發現、衆測反饋、灰度反饋、發佈後反饋，等等。咱們作bug分析首先面臨的就是「如何挑選合適的bug」。這裏給出幾點建議：

• 選擇對用戶影響大的：好比閃退、或者致使某功能沒法使用的bug 

• 選擇典型有表明性的：同類型的一系列問題，好比：skia適配致使2.3和4.4手機必現沒法啓動 

• 選擇有發現難度的：積累問題庫，對測試用例作補充 

• 選擇有推廣價值的：可借鑑到其餘平臺或其餘產品，好比：白屏系列專題 

總之，只要是符合目標經過bug分析，更高效、有效的保證產品質量的bug，均可以選來作bug分析。

第二步、收集哪些bug信息

假設你已經選定了待分析的bug，咱們接下來要作的是，對bug收集儘可能多的有效信息。比較常見的「bug信息」包括如下：

• 被測產品信息：好比APP名稱、版本號 

• 測試機型和環境：好比小米手機4.4系統、wifi網絡、wup測試環境 

• 嚴重級別：好比分爲嚴重、通常、建議 

• BUG模塊：好比書籤模塊、字體模塊 

• 測試步驟：描述測試操做的123步驟 

• 預期結果&實際結果：對比正常狀況下的預知結果，給出bug的表現 

• 附加信息：好比截圖、視頻錄像、logcat信息等

須要指出的是，結合bug的實際表現，咱們在提交bug時應該儘可能多的提供有效信息，對問題自己作「隔離」。這樣作的好處是，可以幫助開發過濾掉干擾因素，減小排查時間，更高效的定位到bug。來看個例子，經過隔離法作「初篩」，測試能夠快速對bug作一輪初步定位。

 

第三步、如何作bug分析

咱們前面說過，bug分析就是要追蹤bug產生的本質緣由。實際測試中，基於BUG分析小組的經驗總結，咱們將bug分析的過程分爲三大類型。結合本身bug的特色，在分析時能夠選擇合適的方法去套用。

一、直接分析法

適用場景：能夠直觀的看到，或者經過隔離篩查，已經初步定位到bug模塊。

舉個例子：

「華爲M版本（6.0內核）下，圖片顯示異常」。 

特定系統的問題，看起來bug緣由比較明確，就是M系統下的顯示問題。咱們經過查看官方版本更新文檔、瞭解代碼變動，一般能夠很快找到bug緣由。

以這個bug來講，Chrome存在一樣問題並已經作了修復，咱們在官網上查找相關資料，就能夠了解到bug根因了。

二、5W分析法

適用場景：比較沒有頭緒，bug自己之外的信息較少。

5W是一種分析方法，經過不斷的追問「爲何」，來識別和說明因果關係，解釋事件發生的本質緣由。這裏咱們用在BUG分析中，借鑑5W思想，深刻追蹤BUG產生的根本緣由，從源頭上尋找BUG緣由。

5W bug分析的特色是：從表象入手，一步步追問，由上一個問題的回答引起下一個問題，直至獲得bug產生的本質緣由。

舉個例子：

BUG來源：X5 實驗室Blink版本 
標題：使用第三方字體，頁面顯示異常 
測試步驟：

1.    對手機更換熱門的「花漾水果」字體；

2.    進入QQ瀏覽器，訪問百度，網易等頁面； 
現象：頁面文字不顯示

分析步驟： 
（1）先找到問題的最外層表現，即明確BUG的表現是什麼； 
（2）對最外層表現提問，找出BUG的直接緣由； 
（3）用5W方法，針對直接緣由，連續追問屢次，直至找到BUG的本質緣由；

可見，經過接二連三地追問why，咱們總能夠深挖到bug產生的最根本緣由。固然，對新手來講，你可能沒辦法一次問到bug的本質，不過不要緊，多問幾回，培養對問題的敏感度，你總能從某條「線」上挖到你想到的結果。

三、探案分析法

適用場景：基於現有的知識儲備，有必定的追查思路，能劃分bug可能的幾大類緣由。

探案分析法，從案情的發生過程，基於經驗分析肯定可能的嫌疑人，再用高科技工具逐個排查疑犯，最終由證據指認真正的「兇手」。

舉個例子：

「小米4（4.4.4）進入看準網任意二級連接進度條加載完成後白屏」。 
首先，從bug的描述信息提煉有價值的點。

 

【初步評估】 

一、UC正常能夠排除網絡異常致使 
二、小米4手機獨有問題 
三、網址導航配置的連接，較容易被發現 

【懷疑對象】 
一、渲染模塊，渲染異常，沒有正確上屏 
二、網絡模塊，網絡交互異常，沒有拉取到資源 
【提煉疑點】 
疑點1：只有小米4手機有這個問題？跟機型和ROM版本有關嗎？線上是否有相似用戶反饋？ 
疑點2：看準網是作什麼的？有什麼特殊性？爲何一級連接正常，二級連接就白屏了？ 
【收集證據&排除干擾】 
Step1 針對疑點1用其餘機型作對比驗證，驗證結果：其餘機型未復現。 
Step2 查找線上數據，確認線上是否有相似用戶反饋。查找結果：有1條反饋 
獲取到以下關鍵信息： 
（1）反饋版本是6.5.0.2170，反饋時間20160324，早於上述bug發現時間。 
（2）用戶機型是：LetvX500，換手機也是如此。推翻上述單個機型問題的判斷。 
Step3 看準網是中國最大的企業點評、僱主品牌展現和員工分享平臺。 
其餘招聘類站點未出現相似問題，初步看不出這個站點有什麼特殊性。 
Step4 經過inspector調試發現，訪問看準網二級連接，網絡請求直接返回403，並無拉取到網頁資源，請求被服務器拒絕了。 
【分析推理】 
服務器爲何在有些場景下會拒絕網絡請求呢？懷疑是代理直連的策略致使，部分機型走直連，部分機型走代理。另外即便是配置成代理，可是因爲各類不可控因素會致使走直連。 
從log看當時出現白屏時，確實是走的代理。 
當時未能進一步驗證：沒有出現問題的手機訪問該站點走的直連。 
猜想緣由：代理狀況下會出現，同一個IP高頻訪問，看準網屏蔽了咱們的代理IP。 
解決方案：在強制直連白名單裏增長看準網，以後能夠正常拉取到資源。以下是QB從後臺拉取的強制代理白名單，確實有增長看準網。 
【結案陳詞】 
白屏問題是由網絡模塊異常致使，代理策略的侷限性會致使：代理方式訪問有作無效訪問屏蔽的站點可能會存在這類問題（如：購票、投票等）。

第四步、總結經驗和改進優化

 

一、Bug左移

你們都知道，bug發現的越早，修復的成本越低。經過bug分析，作好預防，儘可能早的發現問題，從而下降修復成本和產品風險。 

二、測試優化

經過bug分析的案例積累，提高測試對產品總體架構的理解，高效、有效的設計測試方案，更好的把控產品質量風險。 

三、項目各角色改進

產品側：需求更合理、預知實現風險，前期從設計層面規避bug;
開發側：經過編碼規範、增強自測和code review，提升代碼質量 ;
測試側：補充優化測試方案，瞭解產品架構邏輯，經驗和技術提高，更精準的關注重點bug、提高產品風險評估能力.

舉個例子：

Bug分析案例：「一個較大excel文件的白屏問題」 
經過分析後獲得的bug根因：在實現文件加載漸隱漸顯效果時代碼有邏輯缺陷，會致使文章內容在加載完成前webview被隱藏，頁面白屏，文件打開失敗。 
(1) 測試優化改進方案： 
a. 補充了須要驗證的QB支持的文件格式; 
b. 從以前的隨意選取幾個格式進行文件邏輯驗證改成有針對性的選取文件格式以保證;
c. 特定打開邏輯的驗證（集成時要求每種邏輯至少用一種文件格式驗證）保證了文件格式和打開邏輯驗證的覆蓋度;

 

 

(2) 補充文件測試中對於文件大小的關注。 
收穫：文件格式兼容的測試更有針對性，後面在測試第三方調起打開需求和手Q拉新需求的時候，都是直接按照表格上的格式讓開發自測，同時咱們本身也是這樣驗證的，既覆蓋了QB的文件打開邏輯，也基本涵蓋了用戶經常使用的文件格式

實際效果： 
從6.2版本至6.9版本，共發現14個與特定文件格式相關的bug； 
好比：

【文件】gz壓縮包格式文件打開均失敗ID:51182410 
【文件】第三方使用瀏覽器打開txt顯示亂碼ID:51343519 
上線後：線上沒有出現關於文件格式相關的用戶反饋。

 

Bug分析是一種手段，但不是目的。從獲得的bug根因，反思和回溯bug產生的各個階段，思考如何避免相似問題，再也不踩坑，在下次測試中獲得提高，纔是咱們想要的結果。一樣的，bug分析的成果是一個持續改進優化閉環的過程，它是測試人員潛移默化中測試能力的提高，也是項目流程中各個角色共同保障產品質量意識的推進。所以，請作好bug分析，爲產品質量保駕護航 !