通過可視化數據分析提升測試質量-36大數據
作者:?Deadwalk
某位高人曾說過:日復一日地重復著既有的測試,然后被類似的Bug折磨得無可奈何,不如稍作停頓,分析總結找到Bug的源頭,以除之。本篇文章我們就來聊聊如何通過可視化的數據進行分析,進而提升測試質量。
為了讓產品的質量可度量、可視化,我們可以建立一些指標數據,以幫助我們發現產品質量的各種問題,比如:被測功能模塊發現Bug太晚,某位開發同學的代碼質量一直很低,某個功能總是在兼容性方面存在大量問題等。有了問題之后,我們就可以有針對性地進行改進,有的放矢,從而使得被測產品的質量逐步改善。以搜狗的項目為例,我們建立的指標有以下三個方向:Bug、代碼行和漏測問題數量。
關于Bug的指標
Bug是軟件開發過程中最基本的問題載體,在這一方向,我們可以細化為幾種數據指標,例如:
1.Bug數量分布(功能模塊維度):
按照功能模塊維度,分別統計Bug的數量(也可以是嚴重Bug數量)情況,該項指標用以反映哪個功能模塊的質量情況最低。例如:搜狗輸入法有語音輸入、拼音輸入、手寫輸入,分別統計某個版本這三個模塊的Bug情況。
解釋說明:
- 首先我們可以判斷Bug數量高的模塊是否合理。如上圖所示,本次版本開發主要實現和修改的是語音功能,那么Bug數量多是合理的。
- 其次我們可以有針對性的部署測試策略。語音功能的問題數量較多,功能比較復雜,只是按照既有的測試計劃可能模塊質量覆蓋不夠全面,所以我們有針對性地對這個模塊進行二輪、三輪甚至四輪的回歸測試,或者安排更多地人力。
2.Bug數量分布(開發人員維度):
按照開發人員維度,分別統計每個開發人員所產生的Bug數量情況,該項指標用以輔助評估開發人員的代碼質量情況。
解釋說明:
- 這一指標可以幫助我們了解哪位開發的Bug修復壓力最大(壓力越大,連帶Bug的可能性也會越大),測試人員可以留意對應開發的Bug修復率。
- 如果某位開發的Bug數量常年居高不下,測試人員就要注意小心了~~。
- 需要特別說明的一點是,Bug數量不能作為唯一評判開發人員代碼質量好壞的數據,Bug數量是與開發人員提交代碼量和模塊復雜度成正比的,綜合地查看Bug數量和代碼提交量是比較可行的方法。
3.Bug易發現分布(功能模塊維度):
Bug易發現是指一個功能模塊在用戶可觸及的主路徑上就會遇到的Bug,例如:在輸入法的鍵盤上按下語音鍵進行語音輸入時,功能不能使用。該指標用以統計提測模塊的開發自測情況,數據越多說明提測時質量越差。
4.Bug易發現分布(開發人員維度):
同上,以開發人員維度進行分析統計。
5.Bug往返率(開發人員維度):
該指標用于統計Bug在缺陷管理系統中的來回指派數量的情況。比如:某Bug在開發人員A和測試人員B之間來回指派了3次,那么則統計開發人員A的Bug往返平均數量。
6.Bug發現的階段:
該指標可選項有預測試、一輪測試、二輪測試、回歸測試、上線前測試、上線后幾個可選項,它用于體現Bug的發現時間段。
解釋說明:
- 預測試一般是開發提測后進行1天的測試,用以評估提測的版本是否符合測試的要求。如果大量的Bug在預測試階段發現(甚至是阻塞的Bug出現),說明提測版本的質量可能不好,這就需要督促開發給出質量更高的版本提測,以節省Bug溝通處理的成本,從而大大提升測試效率。
- 正式提測后,按照預期的效果,我們希望是大量的Bug在一輪測試階段發現,少量的Bug在二輪測試階段發現,極少量的Bug在回歸測試階段暴露。但是實際情況可能有所不同,如果二輪和回歸階段的Bug數量很多,這有可能是測試人員的測試方法、測試策略有問題,導致Bug暴露發現得比較晚;也可能是開發修復Bug時連帶其他Bug數量多,這間接反映了開發修復Bug的方式方法可能有問題。
7.Bug產生的原因:
這一選項是Bug在提交測試驗證時,由由開發人員填寫的字段,該字段可選內容有:服務器問題、第三方SDK問題、適配性問題、UI顯示問題、程序邏輯問題、性能問題、溝通不足問題、需求理解問題。(具體字段可選項可根據實際項目進行設定),這一指標用來輔助開發人員分析Bug產生的原因。
解釋說明:
- 服務端問題(本例因為是客戶端程序,所以選項中有服務端問題)如果存在大量的Bug,這說明服務端的質量控制不足。
- 第三方SDK問題。因為App一般會使用其他方提供的SDK直接調用,對于SDK的質量情況可以通過該項指標數據來暴露,如果問題集中且較多,后續應該推動SDK方提升其質量品質。
- 溝通不足、需求理解問題一般是工作配合類問題,如果是此類問題集中,應該重新評估整體項目流程運轉是否正常有效。
關于代碼的指標
借助功能強大的StatSVN,我們可以方便地統計出與SVN相關的各種數據指標,如:每位提交者的情況、每月的代碼提交情況,代碼修改占代碼總數的百分比、每天中哪幾小時比較活躍、每周哪幾天比較活躍、文件數量統計等,關于StatSVN的介紹網上有很多使用教程,本文不再贅述,請感興趣的同學自行”搜狗?StatSVN”即可。
千行代碼Bug率:
在搜狗輸入法項目我們主要使用了StatSVN的一個數據項:開發人員代碼行數量,再結合上述1中的Bug指標數據,我們可以得到一個新的指標數據:千行代碼Bug率,該指標用于側面體現開發人員的代碼質量情況。
解釋說明:
這一指標數據會定期發送給開發Leader,以便開發Leader對其下的開發人員質量情況有一個清晰的認識,同時也會督促開發人員提升代碼質量意識。
關于漏測問題的指標
除了測試環節Bug及代碼的統計分析,對于上線后用戶反饋暴露的質量問題,也應加以統計分析。在搜狗測試部,我們通過Bug總結流程來進行這一環節的數據錄入和統計。(Bug總結具體的流程和方法請見推文 【質量管理改進】Bug總結流程 )
1.漏測問題數量分布(模塊維度)
該指標從功能模塊的維度,對線上用戶反饋的問題進行統計分析,例如:搜狗瀏覽器的線上用戶反饋數量最多的問題是瀏覽網頁這一功能。
2.漏測問題原因類型:
根據以往的工作經驗,我們將線上用戶反饋的問題歸為以下六大類,每一大類下細分小分類。
解釋說明:
通過分析線上漏測的問題原因,可以發現測試、開發或者流程上的不足,以PC瀏覽器的分析為例:
瀏覽頁面功能是TOP1被用戶反饋的功能模塊(這也符合瀏覽器最主要的功能就是瀏覽網頁),進而發現這一功能出現問題最多的是兼容性站點的問題,或者是用戶的測試環境比較復雜特殊導致的。
- (882590) :?【問題類】打開某鏈接會穩定崩潰?(Google Doc)
- (832095) : ?【問題類】玩4399的小游戲時狙擊槍不能開鏡
- (967951) : ?【問題類】交通銀行信用卡頁面首次打開時輸入框和驗證碼輸入界面顯示不全
基于以上的數據分析,我們重新制定了詳細的瀏覽器站點兼容性測試方案,每個版本加大兼容性站點的測試,在測試階段即發現了大量的Bug。
總結
作為項目管理者,我們可以通過分析項目每個版本的Bug數據、代碼行數據、漏測的問題數量,發現數據背后的問題(開發問題、測試問題、流程問題等),針對問題尋找解決方案并實施,從而提升整個產品的質量控制。
End.
轉載請注明來自36大數據(36dsj.com): 36大數據 ? 通過可視化數據分析提升測試質量