某位高人曾說過：日復(fù)一日地重復(fù)著既有的測(cè)試，然后被類似的Bug折磨得無可奈何，不如稍作停頓，分析總結(jié)找到Bug的源頭，以除之。本篇文章我們就來聊聊如何通過可視化的數(shù)據(jù)進(jìn)行分析，進(jìn)而提升測(cè)試質(zhì)量。

為了讓產(chǎn)品的質(zhì)量可度量、可視化，我們可以建立一些指標(biāo)數(shù)據(jù)，以幫助我們發(fā)現(xiàn)產(chǎn)品質(zhì)量的各種問題，比如：被測(cè)功能模塊發(fā)現(xiàn)Bug太晚，某位開發(fā)同學(xué)的代碼質(zhì)量一直很低，某個(gè)功能總是在兼容性方面存在大量問題等。有了問題之后，我們就可以有針對(duì)性地進(jìn)行改進(jìn)，有的放矢，從而使得被測(cè)產(chǎn)品的質(zhì)量逐步改善。以搜狗的項(xiàng)目為例，我們建立的指標(biāo)有以下三個(gè)方向：Bug、代碼行和漏測(cè)問題數(shù)量。

關(guān)于Bug的指標(biāo)

Bug是軟件開發(fā)過程中最基本的問題載體，在這一方向，我們可以細(xì)化為幾種數(shù)據(jù)指標(biāo)，例如：

1.Bug數(shù)量分布(功能模塊維度)：

按照功能模塊維度，分別統(tǒng)計(jì)Bug的數(shù)量(也可以是嚴(yán)重Bug數(shù)量)情況，該項(xiàng)指標(biāo)用以反映哪個(gè)功能模塊的質(zhì)量情況最低。例如：搜狗輸入法有語音輸入、拼音輸入、手寫輸入，分別統(tǒng)計(jì)某個(gè)版本這三個(gè)模塊的Bug情況。

解釋說明：

首先我們可以判斷Bug數(shù)量高的模塊是否合理。如上圖所示，本次版本開發(fā)主要實(shí)現(xiàn)和修改的是語音功能，那么Bug數(shù)量多是合理的。

其次我們可以有針對(duì)性的部署測(cè)試策略。語音功能的問題數(shù)量較多，功能比較復(fù)雜，只是按照既有的測(cè)試計(jì)劃可能模塊質(zhì)量覆蓋不夠全面，所以我們有針對(duì)性地對(duì)這個(gè)模塊進(jìn)行二輪、三輪甚至四輪的回歸測(cè)試，或者安排更多地人力。

2.Bug數(shù)量分布(開發(fā)人員維度)：

按照開發(fā)人員維度，分別統(tǒng)計(jì)每個(gè)開發(fā)人員所產(chǎn)生的Bug數(shù)量情況，該項(xiàng)指標(biāo)用以輔助評(píng)估開發(fā)人員的代碼質(zhì)量情況。

解釋說明：

這一指標(biāo)可以幫助我們了解哪位開發(fā)的Bug修復(fù)壓力最大(壓力越大，連帶Bug的可能性也會(huì)越大)，測(cè)試人員可以留意對(duì)應(yīng)開發(fā)的Bug修復(fù)率。

如果某位開發(fā)的Bug數(shù)量常年居高不下，測(cè)試人員就要注意小心了~~。

需要特別說明的一點(diǎn)是，Bug數(shù)量不能作為唯一評(píng)判開發(fā)人員代碼質(zhì)量好壞的數(shù)據(jù)，Bug數(shù)量是與開發(fā)人員提交代碼量和模塊復(fù)雜度成正比的，綜合地查看Bug數(shù)量和代碼提交量是比較可行的方法。

3.Bug易發(fā)現(xiàn)分布(功能模塊維度)：

Bug易發(fā)現(xiàn)是指一個(gè)功能模塊在用戶可觸及的主路徑上就會(huì)遇到的Bug，例如：在輸入法的鍵盤上按下語音鍵進(jìn)行語音輸入時(shí)，功能不能使用。該指標(biāo)用以統(tǒng)計(jì)提測(cè)模塊的開發(fā)自測(cè)情況，數(shù)據(jù)越多說明提測(cè)時(shí)質(zhì)量越差。

4.Bug易發(fā)現(xiàn)分布(開發(fā)人員維度)：

同上，以開發(fā)人員維度進(jìn)行分析統(tǒng)計(jì)。

5.Bug往返率(開發(fā)人員維度)：

該指標(biāo)用于統(tǒng)計(jì)Bug在缺陷管理系統(tǒng)中的來回指派數(shù)量的情況。比如：某Bug在開發(fā)人員A和測(cè)試人員B之間來回指派了3次，那么則統(tǒng)計(jì)開發(fā)人員A的Bug往返平均數(shù)量。

6.Bug發(fā)現(xiàn)的階段：

該指標(biāo)可選項(xiàng)有預(yù)測(cè)試、一輪測(cè)試、二輪測(cè)試、回歸測(cè)試、上線前測(cè)試、上線后幾個(gè)可選項(xiàng)，它用于體現(xiàn)Bug的發(fā)現(xiàn)時(shí)間段。

解釋說明：

預(yù)測(cè)試一般是開發(fā)提測(cè)后進(jìn)行1天的測(cè)試，用以評(píng)估提測(cè)的版本是否符合測(cè)試的要求。如果大量的Bug在預(yù)測(cè)試階段發(fā)現(xiàn)(甚至是阻塞的Bug出現(xiàn))，說明提測(cè)版本的質(zhì)量可能不好，這就需要督促開發(fā)給出質(zhì)量更高的版本提測(cè)，以節(jié)省Bug溝通處理的成本，從而大大提升測(cè)試效率。

正式提測(cè)后，按照預(yù)期的效果，我們希望是大量的Bug在一輪測(cè)試階段發(fā)現(xiàn)，少量的Bug在二輪測(cè)試階段發(fā)現(xiàn)，極少量的Bug在回歸測(cè)試階段暴露。但是實(shí)際情況可能有所不同，如果二輪和回歸階段的Bug數(shù)量很多，這有可能是測(cè)試人員的測(cè)試方法、測(cè)試策略有問題，導(dǎo)致Bug暴露發(fā)現(xiàn)得比較晚;也可能是開發(fā)修復(fù)Bug時(shí)連帶其他Bug數(shù)量多，這間接反映了開發(fā)修復(fù)Bug的方式方法可能有問題。

7.Bug產(chǎn)生的原因：

這一選項(xiàng)是Bug在提交測(cè)試驗(yàn)證時(shí)，由由開發(fā)人員填寫的字段，該字段可選內(nèi)容有：服務(wù)器問題、第三方SDK問題、適配性問題、UI顯示問題、程序邏輯問題、性能問題、溝通不足問題、需求理解問題。(具體字段可選項(xiàng)可根據(jù)實(shí)際項(xiàng)目進(jìn)行設(shè)定)，這一指標(biāo)用來輔助開發(fā)人員分析Bug產(chǎn)生的原因。

解釋說明：

服務(wù)端問題(本例因?yàn)槭强蛻舳顺绦颍赃x項(xiàng)中有服務(wù)端問題)如果存在大量的Bug，這說明服務(wù)端的質(zhì)量控制不足。

第三方SDK問題。因?yàn)锳pp一般會(huì)使用其他方提供的SDK直接調(diào)用，對(duì)于SDK的質(zhì)量情況可以通過該項(xiàng)指標(biāo)數(shù)據(jù)來暴露，如果問題集中且較多，后續(xù)應(yīng)該推動(dòng)SDK方提升其質(zhì)量品質(zhì)。

溝通不足、需求理解問題一般是工作配合類問題，如果是此類問題集中，應(yīng)該重新評(píng)估整體項(xiàng)目流程運(yùn)轉(zhuǎn)是否正常有效。

關(guān)于代碼的指標(biāo)

借助功能強(qiáng)大的StatSVN，我們可以方便地統(tǒng)計(jì)出與SVN相關(guān)的各種數(shù)據(jù)指標(biāo)，如：每位提交者的情況、每月的代碼提交情況，代碼修改占代碼總數(shù)的百分比、每天中哪幾小時(shí)比較活躍、每周哪幾天比較活躍、文件數(shù)量統(tǒng)計(jì)等，關(guān)于StatSVN的介紹網(wǎng)上有很多使用教程，本文不再贅述，請(qǐng)感興趣的同學(xué)自行”搜狗 StatSVN”即可。

千行代碼Bug率：

在搜狗輸入法項(xiàng)目我們主要使用了StatSVN的一個(gè)數(shù)據(jù)項(xiàng)：開發(fā)人員代碼行數(shù)量，再結(jié)合上述1中的Bug指標(biāo)數(shù)據(jù)，我們可以得到一個(gè)新的指標(biāo)數(shù)據(jù)：千行代碼Bug率，該指標(biāo)用于側(cè)面體現(xiàn)開發(fā)人員的代碼質(zhì)量情況。

解釋說明：

這一指標(biāo)數(shù)據(jù)會(huì)定期發(fā)送給開發(fā)Leader，以便開發(fā)Leader對(duì)其下的開發(fā)人員質(zhì)量情況有一個(gè)清晰的認(rèn)識(shí)，同時(shí)也會(huì)督促開發(fā)人員提升代碼質(zhì)量意識(shí)。

關(guān)于漏測(cè)問題的指標(biāo)

除了測(cè)試環(huán)節(jié)Bug及代碼的統(tǒng)計(jì)分析，對(duì)于上線后用戶反饋暴露的質(zhì)量問題，也應(yīng)加以統(tǒng)計(jì)分析。在搜狗測(cè)試部，我們通過Bug總結(jié)流程來進(jìn)行這一環(huán)節(jié)的數(shù)據(jù)錄入和統(tǒng)計(jì)。(Bug總結(jié)具體的流程和方法請(qǐng)見推文【質(zhì)量管理改進(jìn)】Bug總結(jié)流程)

1.漏測(cè)問題數(shù)量分布(模塊維度)

該指標(biāo)從功能模塊的維度，對(duì)線上用戶反饋的問題進(jìn)行統(tǒng)計(jì)分析，例如：搜狗瀏覽器的線上用戶反饋數(shù)量最多的問題是瀏覽網(wǎng)頁這一功能。

2.漏測(cè)問題原因類型：

根據(jù)以往的工作經(jīng)驗(yàn)，我們將線上用戶反饋的問題歸為以下六大類，每一大類下細(xì)分小分類。

解釋說明：

通過分析線上漏測(cè)的問題原因，可以發(fā)現(xiàn)測(cè)試、開發(fā)或者流程上的不足，以PC瀏覽器的分析為例：

瀏覽頁面功能是TOP1被用戶反饋的功能模塊(這也符合瀏覽器最主要的功能就是瀏覽網(wǎng)頁)，進(jìn)而發(fā)現(xiàn)這一功能出現(xiàn)問題最多的是兼容性站點(diǎn)的問題，或者是用戶的測(cè)試環(huán)境比較復(fù)雜特殊導(dǎo)致的。

• (882590) : 【問題類】打開某鏈接會(huì)穩(wěn)定崩潰 (Google Doc)
• (832095) : 【問題類】玩4399的小游戲時(shí)狙擊槍不能開鏡
• (967951) : 【問題類】交通銀行信用卡頁面首次打開時(shí)輸入框和驗(yàn)證碼輸入界面顯示不全

基于以上的數(shù)據(jù)分析，我們重新制定了詳細(xì)的瀏覽器站點(diǎn)兼容性測(cè)試方案，每個(gè)版本加大兼容性站點(diǎn)的測(cè)試，在測(cè)試階段即發(fā)現(xiàn)了大量的Bug。

總結(jié)

作為項(xiàng)目管理者，我們可以通過分析項(xiàng)目每個(gè)版本的Bug數(shù)據(jù)、代碼行數(shù)據(jù)、漏測(cè)的問題數(shù)量，發(fā)現(xiàn)數(shù)據(jù)背后的問題(開發(fā)問題、測(cè)試問題、流程問題等)，針對(duì)問題尋找解決方案并實(shí)施，從而提升整個(gè)產(chǎn)品的質(zhì)量控制。