此文已由作者夏君授權網易云社區發布。

歡迎訪問網易云社區，了解更多網易技術產品運營經驗。

產品測試組_理財基金
統計季度：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群組部署、依賴部署一鍵解決

轉載于:https://www.cnblogs.com/zyfd/p/9836557.html

總結

以上是生活随笔為你收集整理的如何作缺陷分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。