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