不會做bug分析？套路走起~
轉(zhuǎn)自--騰訊優(yōu)測 http://mp.weixin.qq.com/s/RV8KzojLRUGuAPrrhp-Xyg
導(dǎo)語
說起bug分析，測試同學(xué)都不陌生。那么，我們?yōu)槭裁匆鯾ug分析？如何做bug分析？最后又怎么樣落實(shí)bug分析的效果呢？今天小優(yōu)就來跟大家聊聊bug分析的那些事兒。
WHAT. 什么是bug分析？
bug分析：本文指的是微觀的bug分析。從單個有價值的bug入手，追蹤和分析bug產(chǎn)生的本質(zhì)原因，在此基礎(chǔ)上對產(chǎn)品各個角色、以及項(xiàng)目流程做改善和優(yōu)化。
可見，bug分析分為兩部分。一是“bug分析”本身，二是以分析結(jié)果為前提，所做的一系列優(yōu)化改善。
WHY. 為什么要做bug分析？
原因一：借助bug，提升測試人員對產(chǎn)品質(zhì)量的整體把控
從項(xiàng)目初期的產(chǎn)品需求PK，到開發(fā)階段的自測、迭代提測、集成上線提測，直至發(fā)布后用戶反饋，可以說bug幾乎貫穿了產(chǎn)品發(fā)展的各個階段。對于測試人員來說，用好手中的bug，提升對產(chǎn)品的理解，能夠更高效、更有效的測試，從而把控質(zhì)量風(fēng)險，提升產(chǎn)品質(zhì)量。
原因二：追本溯源，重新審視項(xiàng)目過程，推動優(yōu)化
有人說，產(chǎn)品一切bug的根源都是代碼。如果把產(chǎn)品的誕生當(dāng)作一場馬拉松，那bug就是那些年我們踩過的坑。從哪兒跌倒就從哪兒爬起來，通過分析找到bug產(chǎn)生的根因，思考如何從各個方面去優(yōu)化改進(jìn)，避免以后踩到類似的“坑”，下一場比賽才能跑的更快更遠(yuǎn)。
HOW. 怎么做bug分析？
先上模型，以下我們逐步講解怎么對應(yīng)模型去做bug分析。
第一步：怎么選bug？
bug的來源很多，有產(chǎn)品體驗(yàn)、開發(fā)自測、測試發(fā)現(xiàn)、眾測反饋、灰度反饋、發(fā)布后反饋，等等。我們做bug分析首先面臨的就是“如何挑選合適的bug”。這里給出幾點(diǎn)建議：
選擇對用戶影響大的：比如閃退、或者導(dǎo)致某功能無法使用的bug
選擇典型有代表性的：同類型的一系列問題，比如：skia適配導(dǎo)致2.3和4.4手機(jī)必現(xiàn)無法啟動
選擇有發(fā)現(xiàn)難度的：積累問題庫，對測試用例做補(bǔ)充
選擇有推廣價值的：可借鑒到其他平臺或其他產(chǎn)品，比如：白屏系列專題
總之，只要是符合目標(biāo)通過bug分析，更高效、有效的保證產(chǎn)品質(zhì)量的bug，都可以選來做bug分析。
第二步、收集哪些bug信息？
假設(shè)你已經(jīng)選定了待分析的bug，我們接下來要做的是，對bug收集盡量多的有效信息。比較常見的“bug信息”包括以下：
被測產(chǎn)品信息：比如APP名稱、版本號
測試機(jī)型和環(huán)境：比如小米手機(jī)4.4系統(tǒng)、wifi網(wǎng)絡(luò)、wup測試環(huán)境
嚴(yán)重級別：比如分為嚴(yán)重、一般、建議
BUG模塊：比如書簽?zāi)K、字體模塊
測試步驟：描述測試操作的123步驟
預(yù)期結(jié)果&實(shí)際結(jié)果：對比正常情況下的預(yù)知結(jié)果，給出bug的表現(xiàn)
附加信息：比如截圖、視頻錄像、logcat信息等
需要指出的是，結(jié)合bug的實(shí)際表現(xiàn)，我們在提交bug時應(yīng)該盡量多的提供有效信息，對問題本身做“隔離”。這樣做的好處是，能夠幫助開發(fā)過濾掉干擾因素，減少排查時間，更高效的定位到bug。來看個例子，通過隔離法做“初篩”，測試可以快速對bug做一輪初步定位。
第三步、如何做bug分析？
我們前面說過，bug分析就是要追蹤bug產(chǎn)生的本質(zhì)原因。實(shí)際測試中，基于BUG分析小組的經(jīng)驗(yàn)總結(jié)，我們將bug分析的過程分為三大類型。結(jié)合自己bug的特點(diǎn)，在分析時可以選擇合適的方法去套用。
1、直接分析法
適用場景：可以直觀的看到，或者通過隔離篩查，已經(jīng)初步定位到bug模塊。
舉個例子：
“華為M版本（6.0內(nèi)核）下，圖片顯示異?！?。
特定系統(tǒng)的問題，看起來bug原因比較明確，就是M系統(tǒng)下的顯示問題。我們通過查看官方版本更新文檔、了解代碼變更，通?？梢院芸煺业絙ug原因。
以這個bug來說，Chrome存在同樣問題并已經(jīng)做了修復(fù)，我們在官網(wǎng)上查找相關(guān)資料，就可以了解到bug根因了。
2、5W分析法
適用場景：比較沒有頭緒，bug本身以外的信息較少。
5W是一種分析方法，通過不斷的追問“為什么”，來識別和說明因果關(guān)系，解釋事件發(fā)生的本質(zhì)原因。這里我們用在BUG分析中，借鑒5W思想，深入追蹤BUG產(chǎn)生的根本原因，從源頭上尋找BUG原因。
5W bug分析的特點(diǎn)是：從表象入手，一步步追問，由上一個問題的回答引發(fā)下一個問題，直至得到bug產(chǎn)生的本質(zhì)原因。
舉個例子：
BUG來源：X5 實(shí)驗(yàn)室Blink版本
標(biāo)題：使用第三方字體，頁面顯示異常
測試步驟：
對手機(jī)更換熱門的“花漾水果”字體；
進(jìn)入QQ瀏覽器，訪問百度，網(wǎng)易等頁面；
現(xiàn)象：頁面文字不顯示
分析步驟：
（1）先找到問題的最外層表現(xiàn)，即明確BUG的表現(xiàn)是什么；
（2）對最外層表現(xiàn)提問，找出BUG的直接原因；
（3）用5W方法，針對直接原因，連續(xù)追問多次，直至找到BUG的本質(zhì)原因；
可見，通過連續(xù)不斷地追問why，我們總可以深挖到bug產(chǎn)生的最根本原因。當(dāng)然，對新手來說，你可能沒辦法一次問到bug的本質(zhì)，不過沒關(guān)系，多問幾次，培養(yǎng)對問題的敏感度，你總能從某條“線”上挖到你想到的結(jié)果。
3、探案分析法
適用場景：基于現(xiàn)有的知識儲備，有一定的追查思路，能劃分bug可能的幾大類原因。
探案分析法，從案情的發(fā)生過程，基于經(jīng)驗(yàn)分析確定可能的嫌疑人，再用高科技工具逐個排查疑犯，最終由證據(jù)指認(rèn)真正的“兇手”。
舉個例子：
“小米4（4.4.4）進(jìn)入看準(zhǔn)網(wǎng)任意二級鏈接進(jìn)度條加載完成后白屏”。
首先，從bug的描述信息提煉有價值的點(diǎn)。
【初步評估】
1、UC正?？梢耘懦W(wǎng)絡(luò)異常導(dǎo)致
2、小米4手機(jī)獨(dú)有問題
3、網(wǎng)址導(dǎo)航配置的鏈接，較容易被發(fā)現(xiàn)
【懷疑對象】
1、渲染模塊，渲染異常，沒有正確上屏
2、網(wǎng)絡(luò)模塊，網(wǎng)絡(luò)交互異常，沒有拉取到資源
【提煉疑點(diǎn)】
疑點(diǎn)1：只有小米4手機(jī)有這個問題？跟機(jī)型和ROM版本有關(guān)嗎？線上是否有類似用戶反饋？
疑點(diǎn)2：看準(zhǔn)網(wǎng)是做什么的？有什么特殊性？為什么一級鏈接正常，二級鏈接就白屏了？
【收集證據(jù)&排除干擾】
Step1針對疑點(diǎn)1用其他機(jī)型做對比驗(yàn)證，驗(yàn)證結(jié)果：其他機(jī)型未復(fù)現(xiàn)。
Step2查找線上數(shù)據(jù)，確認(rèn)線上是否有類似用戶反饋。查找結(jié)果：有1條反饋
獲取到如下關(guān)鍵信息：
（1）反饋版本是6.5.0.2170，反饋時間20160324，早于上述bug發(fā)現(xiàn)時間。
（2）用戶機(jī)型是：LetvX500，換手機(jī)也是如此。推翻上述單個機(jī)型問題的判斷。
Step3看準(zhǔn)網(wǎng)是中國最大的企業(yè)點(diǎn)評、雇主品牌展示和員工分享平臺。
其他招聘類站點(diǎn)未出現(xiàn)類似問題，初步看不出這個站點(diǎn)有什么特殊性。
Step4通過inspector調(diào)試發(fā)現(xiàn)，訪問看準(zhǔn)網(wǎng)二級鏈接，網(wǎng)絡(luò)請求直接返回403，并沒有拉取到網(wǎng)頁資源，請求被服務(wù)器拒絕了。
【分析推理】
服務(wù)器為什么在有些場景下會拒絕網(wǎng)絡(luò)請求呢？懷疑是代理直連的策略導(dǎo)致，部分機(jī)型走直連，部分機(jī)型走代理。另外即使是配置成代理，但是由于各種不可控因素會導(dǎo)致走直連。
從log看當(dāng)時出現(xiàn)白屏?xí)r，確實(shí)是走的代理。
當(dāng)時未能進(jìn)一步驗(yàn)證：沒有出現(xiàn)問題的手機(jī)訪問該站點(diǎn)走的直連。
猜測原因：代理情況下會出現(xiàn)，同一個IP高頻訪問，看準(zhǔn)網(wǎng)屏蔽了我們的代理IP。
解決方案：在強(qiáng)制直連白名單里增加看準(zhǔn)網(wǎng)，之后可以正常拉取到資源。如下是QB從后臺拉取的強(qiáng)制代理白名單，確實(shí)有增加看準(zhǔn)網(wǎng)。
【結(jié)案陳詞】
白屏問題是由網(wǎng)絡(luò)模塊異常導(dǎo)致，代理策略的局限性會導(dǎo)致：代理方式訪問有做無效訪問屏蔽的站點(diǎn)可能會存在這類問題（如：購票、投票等）。
第四步、總結(jié)經(jīng)驗(yàn)和改進(jìn)優(yōu)化
1、Bug左移
大家都知道，bug發(fā)現(xiàn)的越早，修復(fù)的成本越低。通過bug分析，做好預(yù)防，盡量早的發(fā)現(xiàn)問題，從而降低修復(fù)成本和產(chǎn)品風(fēng)險。
2、測試優(yōu)化
通過bug分析的案例積累，提升測試對產(chǎn)品整體架構(gòu)的理解，高效、有效的設(shè)計測試方案，更好的把控產(chǎn)品質(zhì)量風(fēng)險。
3、項(xiàng)目各角色改進(jìn)
產(chǎn)品側(cè)：需求更合理、預(yù)知實(shí)現(xiàn)風(fēng)險，前期從設(shè)計層面規(guī)避bug;
開發(fā)側(cè)：通過編碼規(guī)范、加強(qiáng)自測和code review，提高代碼質(zhì)量 ;
測試側(cè)：補(bǔ)充優(yōu)化測試方案，了解產(chǎn)品架構(gòu)邏輯，經(jīng)驗(yàn)和技術(shù)提升，更精準(zhǔn)的關(guān)注重點(diǎn)bug、提升產(chǎn)品風(fēng)險評估能力。
舉個例子：
Bug分析案例：“一個較大excel文件的白屏問題”
通過分析后得到的bug根因：在實(shí)現(xiàn)文件加載漸隱漸顯效果時代碼有邏輯缺陷，會導(dǎo)致文章內(nèi)容在加載完成前webview被隱藏，頁面白屏，文件打開失敗。
(1) 測試優(yōu)化改進(jìn)方案：
a. 補(bǔ)充了需要驗(yàn)證的QB支持的文件格式;
b. 從之前的隨意選取幾個格式進(jìn)行文件邏輯驗(yàn)證改為有針對性的選取文件格式以保證;
c. 特定打開邏輯的驗(yàn)證（集成時要求每種邏輯至少用一種文件格式驗(yàn)證）保證了文件格式和打開邏輯驗(yàn)證的覆蓋度;
(2) 補(bǔ)充文件測試中對于文件大小的關(guān)注。
收獲：文件格式兼容的測試更有針對性，后面在測試第三方調(diào)起打開需求和手Q拉新需求的時候，都是直接按照表格上的格式讓開發(fā)自測，同時我們自己也是這樣驗(yàn)證的，既覆蓋了QB的文件打開邏輯，也基本涵蓋了用戶常用的文件格式
實(shí)際效果：
從6.2版本至6.9版本，共發(fā)現(xiàn)14個與特定文件格式相關(guān)的bug；
比如：
【文件】gz壓縮包格式文件打開均失敗ID:51182410
【文件】第三方使用瀏覽器打開txt顯示亂碼ID:51343519
上線后：線上沒有出現(xiàn)關(guān)于文件格式相關(guān)的用戶反饋。
總結(jié)
Bug分析是一種手段，但不是目的。從得到的bug根因，反思和回溯bug產(chǎn)生的各個階段，思考如何避免類似問題，不再踩坑，在下次測試中得到提升，才是我們想要的結(jié)果。同樣的，bug分析的成果是一個持續(xù)改進(jìn)優(yōu)化閉環(huán)的過程，它是測試人員潛移默化中測試能力的提升，也是項(xiàng)目流程中各個角色共同保障產(chǎn)品質(zhì)量意識的推動。因此，請做好bug分析，為產(chǎn)品質(zhì)量保駕護(hù)航 !
