此文已由作者夏君授權網易雲社區發布。
歡迎訪問網易雲社區，了解更多網易技術產品運營經驗。
產品測試組_理財基金
統計季度：2016_Q1
關鍵字：jira、Bug收斂、零Bug反彈、同比/環比
第一部分 jira圖表數據分析
1. 最新問題圖（以柱狀統計圖顯示指定項目最新創建的問題）：
說明：
綠色柱體含義為某一周提交的bug數，綠色柱體重合的紅色柱體表示該天提交的所有bug中到目前統計時間點為止所剩余的未解決掉的bug數。 
分析：
如果某一天的提交的bug數量非常多，說明這一天提交的測試版本中可能是添加了某個新的功能點，且該功能點處於不穩定狀態 ；還一種可能就是開發的某一處的修改帶來了連鎖反應，將其它穩定之處也連帶改的不穩定了，從而注入了新的bug（在實際的工作中，確實遇到過這樣的問題，開發為了修改一個bug，將起先版本中穩定的功能點也改壞了）。
2. 創建與解決的問題對比圖（顯示一個項目或保存的過濾器的問題創建與解決對比情況）:
說明：
紅色曲線表示隨日期增加所提交的bug數累計分布，綠色線條表示隨日期增加所解決的bug數累計分布。
末端一處兩曲線呈水平分布，穩定狀態。
分析：
Bug累計數隨日期的增加還在持續的快速增長，並且紅色曲線斜率多處區域大於45°，說明產品仍存在較多缺陷，質量並沒有穩定下來。
兩條曲線斜率多處區域均大於45°，說明測試和開發的效率都還是不錯的
因為質量還沒有穩定，所以項目測試暫時不能被關閉
其他情況：
情況一：兩條曲線之間的間距越來越小，且紅色曲線的斜率趨於平緩
分析：質量越來越穩定，且可以預見兩條曲線有交織的可能性，可以考慮關閉項目測試。
情況二：兩條曲線之間的間距越來越大，且紅色曲線斜率並沒有放緩趨勢
分析：產品質量比較差，需要及時做出修改和調整，使產品質量相對穩定下來。
情況三：兩條曲線之間間距穩定，但是曲線斜率趨於平緩
分析：開發遇到了技術挑戰，效率開始降低。由於模塊不能及時發布，同時也影響了測試效率。
3. 解決時間（顯示指定項目或過濾器解決問題的時間柱狀圖）：
說明：
此圖顯示了修復bug所花費的平均天數，橫坐標代表bug關閉的日期
分析：
絕大部分的bug修復花費了較長的天數，說明此項目對於開發團隊可能是全新的領域，諸多問題對於他們來說都是非常大挑戰；如果此種情況不存在，那么開發的效率可能存在問題，可能是資源受限，如人力不足等
4. 餅圖匯總統計：
1) 應用模塊占比（模塊缺陷分布圖）
分析：直觀的顯示出各個模塊缺陷的分布情況，從而可以非常好的定位當前工作的重點是優先解決哪些模塊的缺陷
2) 問題解決優先級（優先級分布圖）:
說明：問題的優先級表示其重要性，以下列示出當前的優先級別：
P0 必須有
P1 應該有
Major loss of function.
P2 有了更好
分析：
圖中的P1 缺陷占到 95% 的比率，幾乎全部，質量控制需待加強。
3) 缺陷重要程度占比（缺陷嚴重性分布圖）:
分析：大部分的缺陷屬於功能缺失。
4) 報告者占比（缺陷提交者分布圖）:
分析：本季度產出缺陷效率高， 442/66天/3人=2.23/人*天
5) 缺陷處理時間（缺陷解決分布圖）：
分析：
· 已完成和已修復說明了當前開發的工作進度和效能。
· 重復/無法復現/無效三項直接說明了測試組工作細致程度，如果數值偏大，那么工作嚴謹程度有待加強。
6）BUG 發現階段（測試/預發/線上分配）_盈米基金:
分析：
預發階段暴露部分測試階段遺漏問題
預發典型遺漏問題
簡要描述： 首頁-我的資產沒有顯示基金資產 --遺漏場景
支付定時鍾未輪詢 --開發未提供
余額不足跳失敗頁面 --合作方待配合
未上架基金產品不能作為精選基金 --遺漏場景
新加的頁面文案
提供真實數據與實際測試數據不一樣，有些字段控制，比如判費率
預發人為因素：數據庫表索引未提供明確
相關配置未整理完畢
分析結果：
QA：補充用例，引入多角色資源測試
開發：配置問題整理預發上線checklist
5 BUGBASH分布（盈米基金PC版）
分析：
用戶體驗46，占總缺陷比例= 46 / 365 = 12.6%
程序設計BUG，占總缺陷比例=3/365=0.8%
第二部分 依據項目階段分析數據——盈米基金PC版
目前項目周期短，采取半敏捷開發模式，迭代提測及開發，過程功能不斷迭代，也使缺陷不斷的引入，並不斷發現。眾所周知，缺陷越早發現，修復的成本越低，越到后面，質量不能得到很好的保證。因此分析階段缺陷，有效避免流入下一個階段，非常必要的。
1. 缺陷引入-各項目階段配比圖：
說明：
a. 階段缺陷移除率可以有效的衡量測試用例是否充分，測試效率是否充足。
b. 開發需要在當前測試階段提供哪些功能點已經可測試，哪些功能點Blocked。
陷發現階段\缺陷注入階段 |
需求評審 |
迭代1 |
迭代2 |
迭代3 |
階段測試發現總計 |
需求文檔審核 |
10 |
15 |
|||
冒煙測試 |
10 |
64 |
74 |
||
第一輪測試 |
10 | 30 |
50 |
90 |
|
第二輪測試 |
10 | 90 |
20 |
120 |
|
第三輪測試 |
10 | 30 | 10 |
10 |
60 |
預發/線上測試 |
- |
20 |
|||
引入總計 |
50 |
214 |
80 |
10 |
379 |
本階段缺陷移除率 |
13.19% |
56.46% |
21.11% |
2.64% |
階段缺陷移除率=(本階段發現的屬於本階段功能的缺陷數/最終統計的所有屬於本階段功能的缺陷數)x100%
2. 各階段之活動BUG圖/BUG打開關閉圖模型分析：
說明：
打開bug：包括重新打開數量
關閉bug：單位為次數
活動bug：解決中，已解決（指在項目中還需要大家去關注的Bug）
提測階段圖
分析：
1. 活動bug數字越大，說明軟件的質量越差。
2. 當天打開，關閉數字很大，說明Bug的處理非常活躍，軟件非常不穩定
3. 關閉Bug>打開Bug，活動Bug數回落(“Bug收斂”)
4. 正常的項目測試應該是，活動Bug先上揚，再回落，最后在低位小幅振盪，零打開BUG反彈。
第三部分 其他分析維度及典型缺陷分析思路
1) 同比、環比
a. 同一合作方同一個產品，不同迭代缺陷各維度分析
eg: 以上 盈米：中金
b. 不同合作方同一類產品，缺陷對比分析
eg: 公募基金 ： 易錢袋
c. 不同產品對比分析
d. 不同業務線對比分析
……
2）系統過程穩定，引入其他維度分析
現有：總缺陷數、缺陷解決所費時間、某一模塊的缺陷占總的缺陷數的比率、某一類型（優先級/重要性）的缺陷數占所有類型的缺陷數的比率、千行代碼缺陷率
穩定性條件：頭腦風暴、魚骨頭收集可能的原因，柏拉圖分析主要原因
3）典型缺陷思路，經典案例之前每組都有分析過
10why法：
1w：這個問題是什么？有什么影響？
2w：為什么會出現這個問題？什么場景下會出現這個問題？
3w：這個問題是在哪個階段發現的？
4w：缺陷是在哪個階段引入的？
5w：為什么會在這個階段引入問題？
6w：（how）如何避免引入這個問題？
7w：應該在哪個階段發現這個問題？
8w：為什么沒有在這個階段發現這個問題？
9w：（how）如何才能在這個階段發現這個問題？
10w：（how）如何改進基於風險測試的過程，提取預估到這樣的產品風險？
第四部 總結
可能存在的潛在缺陷和后續工作：
a. 第一次與我們平台對接，數據流程上面可能有些不可預測性的問題，后續持續跟進
做的好的地方：
a. 發動全員參與質量保障，本期新增頁面交互量多，發起BUGBASH
b. 及時溝通反饋，統計未解決問題
c. 前期數據准備，比如業務測試場景的分析，預期的風險
d. 提前與其他項目溝通上線發布
e. 開發修復BUG響應速度很快，且自行協助測試分析容易出錯的點
做的不好的地方：
a. 中間涉及需求不斷變更，包括頁面
b. 質量比較差，對於頁面交互評審工作可以提前
c. 穩定性、可靠性測試未開展，接口自動化
d. 開發盡量自己多下訂單
e. 開發沒有復測缺陷，沒有利用自行環境，直接提測，干擾測試時間
f. BUG基本上面備注，開發層面原因分析
后續改進：
a. 用例整理，修正和補充遺漏分析點
b. 分析穩定、可靠性測試需求
c. 業務測試技能交叉分享，組內相互串通
d. 盈米問題跟蹤
e. 借助fiddler、瀏覽器插件排查問題快速定位總結
遺留未解決問題：
討論：
1. 缺陷格式和屬性沒有嚴格要求，記錄簡單，很多必要信息的缺失，對后續的跟蹤和分析極為不利。
2. 有些屬性可能不是那么有意義，導致存儲信息不僅沒用反而添亂，也不利於分析。
3. 創新引入分析
網易雲免費體驗館，0成本體驗20+款雲產品！
更多網易技術、產品、運營經驗分享請點擊。
相關文章：
【推薦】 Omad群組部署、依賴部署一鍵解決