本文章轉(zhuǎn)載于搜狗測試
某位高人曾說過：日復(fù)一日地重復(fù)著既有的測試演侯，然后被類似的Bug折磨得無可奈何，不如稍作停頓，分析總結(jié)找到Bug的源頭眯漩，以除之。本篇文章我們就來聊聊如何通過可視化的數(shù)據(jù)進(jìn)行分析麻顶，進(jìn)而提升測試質(zhì)量赦抖。
為了讓產(chǎn)品的質(zhì)量可度量、可視化辅肾，我們可以建立一些指標(biāo)數(shù)據(jù)队萤，以幫助我們發(fā)現(xiàn)產(chǎn)品質(zhì)量的各種問題，比如：被測功能模塊發(fā)現(xiàn)Bug太晚矫钓，某位開發(fā)同學(xué)的代碼質(zhì)量一直很低要尔，某個功能總是在兼容性方面存在大量問題等。有了問題之后新娜，我們就可以有針對性地進(jìn)行改進(jìn)赵辕，有的放矢，從而使得被測產(chǎn)品的質(zhì)量逐步改善概龄。以搜狗的項目為例还惠，我們建立的指標(biāo)有以下三個方向：Bug、代碼行和漏測問題數(shù)量私杜。
關(guān)于Bug的指標(biāo)
Bug是軟件開發(fā)過程中最基本的問題載體蚕键，在這一方向，我們可以細(xì)化為幾種數(shù)據(jù)指標(biāo)衰粹，例如：
1.Bug數(shù)量分布(功能模塊維度)：
按照功能模塊維度锣光，分別統(tǒng)計Bug的數(shù)量(也可以是嚴(yán)重Bug數(shù)量)情況，該項指標(biāo)用以反映哪個功能模塊的質(zhì)量情況最低寄猩。例如：搜狗輸入法有語音輸入嫉晶、拼音輸入、手寫輸入田篇，分別統(tǒng)計某個版本這三個模塊的Bug情況替废。
解釋說明：
首先我們可以判斷Bug數(shù)量高的模塊是否合理。如上圖所示泊柬，本次版本開發(fā)主要實現(xiàn)和修改的是語音功能椎镣，那么Bug數(shù)量多是合理的。
其次我們可以有針對性的部署測試策略兽赁。語音功能的問題數(shù)量較多状答，功能比較復(fù)雜冷守，只是按照既有的測試計劃可能模塊質(zhì)量覆蓋不夠全面，所以我們有針對性地對這個模塊進(jìn)行二輪惊科、三輪甚至四輪的回歸測試拍摇，或者安排更多地人力。
2.Bug數(shù)量分布(開發(fā)人員維度)：
按照開發(fā)人員維度馆截，分別統(tǒng)計每個開發(fā)人員所產(chǎn)生的Bug數(shù)量情況充活，該項指標(biāo)用以輔助評估開發(fā)人員的代碼質(zhì)量情況。
解釋說明：
這一指標(biāo)可以幫助我們了解哪位開發(fā)的Bug修復(fù)壓力最大(壓力越大蜡娶，連帶Bug的可能性也會越大)混卵，測試人員可以留意對應(yīng)開發(fā)的Bug修復(fù)率。
如果某位開發(fā)的Bug數(shù)量常年居高不下窖张，測試人員就要注意小心了~~幕随。
需要特別說明的一點是，Bug數(shù)量不能作為唯一評判開發(fā)人員代碼質(zhì)量好壞的數(shù)據(jù)宿接，Bug數(shù)量是與開發(fā)人員提交代碼量和模塊復(fù)雜度成正比的赘淮，綜合地查看Bug數(shù)量和代碼提交量是比較可行的方法。
3.Bug易發(fā)現(xiàn)分布(功能模塊維度)：
Bug易發(fā)現(xiàn)是指一個功能模塊在用戶可觸及的主路徑上就會遇到的Bug澄阳，例如：在輸入法的鍵盤上按下語音鍵進(jìn)行語音輸入時拥知，功能不能使用。該指標(biāo)用以統(tǒng)計提測模塊的開發(fā)自測情況碎赢，數(shù)據(jù)越多說明提測時質(zhì)量越差低剔。
4.Bug易發(fā)現(xiàn)分布(開發(fā)人員維度)：
同上，以開發(fā)人員維度進(jìn)行分析統(tǒng)計肮塞。
5.Bug往返率(開發(fā)人員維度)：
該指標(biāo)用于統(tǒng)計Bug在缺陷管理系統(tǒng)中的來回指派數(shù)量的情況襟齿。比如：某Bug在開發(fā)人員A和測試人員B之間來回指派了3次，那么則統(tǒng)計開發(fā)人員A的Bug往返平均數(shù)量枕赵。
6.Bug發(fā)現(xiàn)的階段：
該指標(biāo)可選項有預(yù)測試猜欺、一輪測試、二輪測試拷窜、回歸測試开皿、上線前測試、上線后幾個可選項篮昧，它用于體現(xiàn)Bug的發(fā)現(xiàn)時間段赋荆。
解釋說明：
預(yù)測試一般是開發(fā)提測后進(jìn)行1天的測試，用以評估提測的版本是否符合測試的要求懊昨。如果大量的Bug在預(yù)測試階段發(fā)現(xiàn)(甚至是阻塞的Bug出現(xiàn))窄潭，說明提測版本的質(zhì)量可能不好，這就需要督促開發(fā)給出質(zhì)量更高的版本提測酵颁，以節(jié)省Bug溝通處理的成本嫉你，從而大大提升測試效率月帝。
正式提測后，按照預(yù)期的效果幽污，我們希望是大量的Bug在一輪測試階段發(fā)現(xiàn)嚷辅，少量的Bug在二輪測試階段發(fā)現(xiàn)，極少量的Bug在回歸測試階段暴露油挥。但是實際情況可能有所不同潦蝇，如果二輪和回歸階段的Bug數(shù)量很多款熬，這有可能是測試人員的測試方法深寥、測試策略有問題，導(dǎo)致Bug暴露發(fā)現(xiàn)得比較晚贤牛；也可能是開發(fā)修復(fù)Bug時連帶其他Bug數(shù)量多惋鹅，這間接反映了開發(fā)修復(fù)Bug的方式方法可能有問題。
7.Bug產(chǎn)生的原因：
這一選項是Bug在提交測試驗證時殉簸，由由開發(fā)人員填寫的字段闰集，該字段可選內(nèi)容有：服務(wù)器問題、第三方SDK問題般卑、適配性問題武鲁、UI顯示問題、程序邏輯問題蝠检、性能問題沐鼠、溝通不足問題、需求理解問題叹谁。(具體字段可選項可根據(jù)實際項目進(jìn)行設(shè)定)饲梭，這一指標(biāo)用來輔助開發(fā)人員分析Bug產(chǎn)生的原因。
解釋說明：
服務(wù)端問題(本例因為是客戶端程序焰檩，所以選項中有服務(wù)端問題)如果存在大量的Bug憔涉，這說明服務(wù)端的質(zhì)量控制不足。
第三方SDK問題析苫。因為App一般會使用其他方提供的SDK直接調(diào)用兜叨，對于SDK的質(zhì)量情況可以通過該項指標(biāo)數(shù)據(jù)來暴露，如果問題集中且較多衩侥，后續(xù)應(yīng)該推動SDK方提升其質(zhì)量品質(zhì)国旷。
溝通不足、需求理解問題一般是工作配合類問題顿乒，如果是此類問題集中议街，應(yīng)該重新評估整體項目流程運轉(zhuǎn)是否正常有效。
關(guān)于代碼的指標(biāo)
借助功能強大的StatSVN璧榄，我們可以方便地統(tǒng)計出與SVN相關(guān)的各種數(shù)據(jù)指標(biāo)特漩，如：每位提交者的情況吧雹、每月的代碼提交情況，代碼修改占代碼總數(shù)的百分比涂身、每天中哪幾小時比較活躍雄卷、每周哪幾天比較活躍、文件數(shù)量統(tǒng)計等蛤售，關(guān)于StatSVN的介紹網(wǎng)上有很多使用教程丁鹉，本文不再贅述，請感興趣的同學(xué)自行"搜狗StatSVN"即可悴能。
千行代碼Bug率：
在搜狗輸入法項目我們主要使用了StatSVN的一個數(shù)據(jù)項：開發(fā)人員代碼行數(shù)量揣钦，再結(jié)合上述1中的Bug指標(biāo)數(shù)據(jù)，我們可以得到一個新的指標(biāo)數(shù)據(jù)：千行代碼Bug率漠酿，該指標(biāo)用于側(cè)面體現(xiàn)開發(fā)人員的代碼質(zhì)量情況冯凹。
解釋說明：
這一指標(biāo)數(shù)據(jù)會定期發(fā)送給開發(fā)Leader，以便開發(fā)Leader對其下的開發(fā)人員質(zhì)量情況有一個清晰的認(rèn)識炒嘲，同時也會督促開發(fā)人員提升代碼質(zhì)量意識宇姚。
關(guān)于漏測問題的指標(biāo)
除了測試環(huán)節(jié)Bug及代碼的統(tǒng)計分析，對于上線后用戶反饋暴露的質(zhì)量問題夫凸，也應(yīng)加以統(tǒng)計分析浑劳。在搜狗測試部仰美，我們通過Bug總結(jié)流程來進(jìn)行這一環(huán)節(jié)的數(shù)據(jù)錄入和統(tǒng)計揽趾。(Bug總結(jié)具體的流程和方法請見推文【質(zhì)量管理改進(jìn)】Bug總結(jié)流程)
1.漏測問題數(shù)量分布(模塊維度)
該指標(biāo)從功能模塊的維度，對線上用戶反饋的問題進(jìn)行統(tǒng)計分析啡捶，例如：搜狗瀏覽器的線上用戶反饋數(shù)量最多的問題是瀏覽網(wǎng)頁這一功能啼止。
2.漏測問題原因類型：
根據(jù)以往的工作經(jīng)驗道逗，我們將線上用戶反饋的問題歸為以下六大類，每一大類下細(xì)分小分類献烦。
序號
問題分類
問題小分類
1
需求了解不足
需求溝通不到位滓窍，理解出錯，多方理解不一致
2
未通知導(dǎo)致測試不知情
3
產(chǎn)品未考慮周全（例如多個入口的需求巩那，雙拼方案英文修改為中文）
4
測試范圍確認(rèn)不足
測試角度吏夯，范圍確認(rèn)有誤
5
測試角度，范圍確認(rèn)無誤即横，開發(fā)修改影響到不相關(guān)模塊
6
用例設(shè)計不足
設(shè)計層面了解不足（灰白盒）
7
基本用例設(shè)計方法考慮不足
8
測試經(jīng)驗,測試發(fā)散度不足.
9
容錯性和異常環(huán)境考慮不足
10
模塊間相互影響考慮不足
11
兼容性問題考慮不足
12
測試執(zhí)行疏漏
13
上線出錯
開發(fā)上錯代碼
14
相關(guān)數(shù)據(jù)噪生、接口未同步更新
15
其他
開發(fā)誤操作
16
不是問題
17
已知問題
解釋說明：
通過分析線上漏測的問題原因，可以發(fā)現(xiàn)測試东囚、開發(fā)或者流程上的不足跺嗽，以PC瀏覽器的分析為例：
瀏覽頁面功能是TOP1被用戶反饋的功能模塊(這也符合瀏覽器最主要的功能就是瀏覽網(wǎng)頁)，進(jìn)而發(fā)現(xiàn)這一功能出現(xiàn)問題最多的是兼容性站點的問題，或者是用戶的測試環(huán)境比較復(fù)雜特殊導(dǎo)致的桨嫁。
(882590) :【問題類】打開某鏈接會穩(wěn)定崩潰(Google Doc)
(832095) : ?【問題類】玩4399的小游戲時狙擊槍不能開鏡
(967951) : ?【問題類】交通銀行信用卡頁面首次打開時輸入框和驗證碼輸入界面顯示不全
基于以上的數(shù)據(jù)分析植兰，我們重新制定了詳細(xì)的瀏覽器站點兼容性測試方案，每個版本加大兼容性站點的測試璃吧，在測試階段即發(fā)現(xiàn)了大量的Bug楣导。
總結(jié)
作為項目管理者，我們可以通過分析項目每個版本的Bug數(shù)據(jù)畜挨、代碼行數(shù)據(jù)筒繁、漏測的問題數(shù)量，發(fā)現(xiàn)數(shù)據(jù)背后的問題(開發(fā)問題巴元、測試問題毡咏、流程問題等)，針對問題尋找解決方案并實施务冕，從而提升整個產(chǎn)品的質(zhì)量控制血当。
