基于缺陷數據的度量與分析

    軟件的度量分析一直是個“虛幻”的話題，因為軟件的開發過程畢竟不能和制造業相比，后者的過程中所產生的數據是非常有類比性的，從而度量也變得容易一些。如何在軟件開發過程中抽象出可度量且具有實際使用意義的屬性確實非常值得思考。
         目前所在的公司是一家美資企業，沒有實際意義上的QA，雖然我自身的角色被定義為QA，但其實質上是Tester。那么沒有QA，也就沒有專門負責收集、統計、分析數據的專職人員，過程的控制和提升更是無從談起。
         怎樣利用現有的資源，從中提取有用的數據，來度量并分析被測系統的質量可靠性、組織效能、過程能力，并為以后的過程能力的提升做好必要的數據分析準備呢？
         作為Tester，平時工作中接觸的最多的莫過于bug庫，我們是否可以從中抽取數據并加以分析呢？答案是肯定的。值得慶幸的是這種數據來源的獲取方式顯得非常容易，幾乎有測試的軟件公司都有自己的bug庫。
 
第一部分：從整體來統計并分析數據本身所包含的信息
         自身參加的測試項目采用了開源工具Jira來管理bug庫，其自帶了很多有用的數據統計報表功能，使用起來非常方便，下面舉例說明，其中涉及到公司項目的信息一并略去。如果所在公司所使用的Bug庫管理工具沒有類似統計功能，那么可以抽出數據放在Minitab這樣的專業化數據分析工具中加以出圖。
1.          Recently Created Issues Report（最近提交缺陷報告）：
說明：
綠色柱體含義為某一天提交的bug數，綠色柱體中重合的紅色柱體表示該天提交的所有bug中到目前統計時間點為止所剩余的未解決掉的bug數。



分析：
如果某一天的提交的bug數量非常多，說明這一天提交的測試版本中可能是添加了某個新的功能點，且該功能點處于不穩定狀態 ；還一種可能就是開發的某一處的修改帶來了連鎖反應，將其它穩定之處也連帶改的不穩定了，從而注入了新的bug（在實際的工作中，確實遇到過這樣的問題，開發為了修改一個bug，將起先版本中穩定的功能點也改壞了）。
 
2.          Created vs Resolved Issues Report（缺陷提交與解決報告）:
說明：
·           紅色曲線表示隨日期增加所提交的bug數累計分布，綠色線條表示隨日期增加所解決的bug數累計分布。
·           末端一處兩曲線呈水平分布，是因為恰逢中國新年。




分析：
·         Bug累計數隨日期的增加還在持續的快速增長，并且紅色曲線斜率多處區域大于45°，說明產品仍存在較多缺陷，質量并沒有穩定下來。
·         兩條曲線斜率多處區域均大于45°，說明測試和開發的效率都還是不錯的
·         因為質量還沒有穩定，所以項目測試暫時不能被關閉
 
其他情況：
情況一：兩條曲線之間的間距越來越小，且紅色曲線的斜率趨于平緩
分析：質量越來越穩定，且可以預見兩條曲線有交織的可能性，可以考慮關閉項目測試。
 
情況二：兩條曲線之間的間距越來越大，且紅色曲線斜率并沒有放緩趨勢
分析：產品質量比較差，需要及時做出修改和調整，使產品質量相對穩定下來。
 
情況三：兩條曲線之間間距穩定，但是曲線斜率趨于平緩
分析：開發遇到了技術挑戰，效率開始降低。由于模塊不能及時發布，同時也影響了測試效率。
 
3.          Resolution Time Report（缺陷解決耗費時間報表）：
說明：
此圖顯示了修復bug所花費的平均天數，橫坐標代表bug關閉的日期




         分析：
絕大部分的bug修復花費了較長的天數，說明此項目對于開發團隊可能是全新的領域，諸多問題對于他們來說都是非常大挑戰；如果此種情況不存在，那么開發的效率可能存在問題，可能是資源受限，如人力不足等
 
4.          Pie Chart：
1)         Component Issue Chart：（模塊缺陷分布圖）

分析：直觀的顯示出各個模塊缺陷的分布情況，從而可以非常好的定位當前工作的重點是優先解決哪些模塊的缺陷
2)         Issue Priority Chart（缺陷優先級分布圖）:
說明：
缺陷的優先級在Jira中這樣定義的：Fix Immediately > Must fix this release > Should fix this release > Fix when possible > No priority




         分析：
         圖中的二級缺陷占到26%的比率，幾乎三分之一，質量控制需待加強。
3)         Issue Severity Chart（缺陷嚴重性分布圖）:




分析：
大部分的缺陷屬于功能缺失。
4)         Issue Reporter Chart（缺陷提交者分布圖）:




分析：對喜歡通過Tester提交的缺陷數來衡量員工績效的公司來講，這圖屬必備之物，當然本身不提倡這樣做，此圖還和多種因素相關，如Tester負責的模塊的穩定性，參加測試的時間長短等等。
5)         Issue Resolution Chart（缺陷解決分布圖）：


        

          分析：
·         Fixed和Unresolved說明了當前開發的工作進度和效能。
·         Duplicate/Cannot Reproduce/Not a bug 三項直接說明了測試組工作細致程度，如果數值偏大，那么工作嚴謹程度有待加強。
6)         Issue Waiting Reason（缺陷等待原因分布圖）：
說明：Waiting for build指的是缺陷已經解決，等待Build發布




分析：
Waiting for information/Waiting for review兩項數值如果較高的話，說明spec定義出現了空缺的地方，無據可循。
 
第二部分：分階段來統計和分析數據所包含的信息
對于采用瀑布模型的軟件開發，過程的迭代，也使缺陷不斷的被注入，并不斷的被發現。眾所周知，缺陷是越早發現越好，越是到后來，修改缺陷導致的代碼變更會越大，從而軟件質量得不到很好的保證。那么在里程碑和里程碑之間我們的工作做的充分了嗎？有多少缺陷我們沒有及時的發現并修正，從而流入到了下一階段呢？ 這些信息我們怎么去度量和分析呢？
1.          缺陷注入-發現矩陣：
普通的軟件開發過程會經歷需求分析（對應需求評審）、設計、編碼（對應單元測試）、系統集成（對應系統測試）等多個階段?，F所在的公司的流程是Spec審核、FS Alpha、FS RC 、APP RC，原理上還是一致，這里就以此過程來說明缺陷注入矩陣的數據分析（注：以下數據均為人為編制，暫沒有從Bug庫中進行收集統計）。

缺陷注入階段 缺陷發現階段	Spec	FS Alpha新增功能	FS RC 新增功能	App RC 新增功能	階段測試發現總計
Spec文檔審核	10				10
FS Alpha Test	20	60			80
FS RC Test	10	30	50		90
App RC Test	10	10	20	10	50
注入總計	50	100	70	10	230
本階段缺陷移除率	20%	60%	71.4%	100%

表1 缺陷注入-發現矩陣
引出重要的一個概念：階段缺陷移除率。
階段缺陷移除率=(本階段發現的屬于本階段功能的缺陷數/最終統計的所有屬于本階段功能的缺陷數)x100%
階段缺陷移除率可以有效的衡量測試用例是否充分，測試效率是否充足。如在上圖中spec中所隱含的缺陷在spec發布到測試組內部時，通過閱讀只發現了10個缺陷，本階段的缺陷移除率只有20%，而在FS Alpha測試中陸續發現了20個缺陷，這就說明在spec審核階段測試進行的不夠充分。
說明：基于上圖中的數據，需要開發能在當前測試階段提供哪些功能點已經可測試，哪些功能點Blocked。
2.          DRM模型
該模型分析了缺陷注入、缺陷發現、階段測試有效性三者之間的關系。什么是階段測試有效性？
階段測試有效性=本階段測試發現的缺陷數/(前多個階段注入的缺陷總數+本階段注入的缺陷數-前多個階段發現的缺陷總數)x100%
同樣采用缺陷注入-發現矩陣中所使用的表格數據，FS Alpha階段測試的有效性=80/(50+100-10)x100%=57%；FS RC階段測試的有效性=90/(50+100+70-10-80)=69%。
階段測試有效性和階段缺陷移除率采用的源數據相同，只不過后者更多的考慮到了累計效應，當然累計效應的影響也是我們需要盡可能避免的，不然初始時的缺陷在測試的最后階段才發現，成本是非常高的。
 
第三部分：我們的過程穩定嗎，性能怎樣？ 統計和分析隱藏在數據背后的信息
基礎知識準備：
1.        過程穩定性：一個過程是否穩定，就是通過過去的數據是否可以預見將來過程的發展。如一個射擊運動員的過程是穩定的（不考慮心理因素等外界原因），因為通過平時的數據積累可以預見他的射擊成績；學生的考試成績也是個差多不的例子。彩票抽獎則是一個不穩定的過程，因為它伴隨著太多的隨機性，你今天中獎了，不可能預見你下一次中獎是在什么時候發生。
2.        過程能力：過程穩定是過程能力的前提，但是過程穩定并不能說明能力就行。過程能力描述的是過程是否能滿足客戶的要求。同樣采用上面的例子，奧運會射擊項目的金牌一般要求運動員的成績均值在9.9環以上（假設），這就是一個客戶要求，如果說某一個運動員達不到這個要求，則說明他的過程能力是有限的。
3.        控制圖：利用歷史數據，通過科學的方法來分析過程是否受控，可預見是分析過程穩定和能力的重要手段。常用的方法就是SPC（統計過程控制），而控制圖則是穩定性和能力指標的圖像化描述手段。其中針對連續數據用的最廣泛有以下幾種圖X圖（組內均值分布圖）、R圖（組內最大和最小值的差值的分布圖）、XmR圖（單點值差值分布圖）等等，至于這些圖中的出圖算法請參看相關書籍或可使用Minitab工具自動生成。
進入正題。分析過程是否性能和可控性，前提至少過程必須是穩定的。分析缺陷庫中的多個屬性，查看是否有符合要求的屬性可用來進行度量和分析。以下數據均是按時間跨度為統計X軸，如每一周進行數據統計。
1.        總缺陷數：這是我們最容易想到的，但不適合，原因是缺陷數會隨著新功能點的添加呈快速增長的方式，很容易超出理性范圍。
2.        缺陷解決所費時間：也不適合，原因是缺陷和缺陷之間在修復的難易程度上有很大的差異性，即使兩個bug在等級和嚴重程度上看上去是一樣的，但對開發而言，涉及的技術方面挑戰性可能有本質的差別。
3.        某一模塊的缺陷數占總的缺陷數的比率：也不適合，原因是某一個模塊的缺陷率會受到其它模塊的直接影響。
4.        某一類型（優先級/重要性）的缺陷數占所有類型的缺陷數的比率：這個可以，分析的結果可以得出產品的質量（如通過某一等級的缺陷率分布）在某段時間內是否受控。但是使用的頻率好像不是很高。
5.        千行代碼缺陷率：這個統計屬性在平時的使用中頻率非常高，它可以有效的評估開發編寫的代碼質量的優劣程度，即使先增了功能點而導致注入了很多新缺陷，但是伴隨的式代碼量也有一定幅度的增長，所以本身比率還是一個非常值得參考的重要度量屬性。如果考慮到不同模塊由不同的開發人員負責，可采用模塊千行代碼覆蓋率來進行分析。唯一要做的就是需要開發人員在某一時間點上提供模塊或系統的代碼行總量。
 
下面就以千行代碼缺陷率做為度量屬性來進行過程性能分析（注：沒有摘取當前公司缺陷庫中的數據。以下數據來自于《度量軟件過程》一書，原書中該數據為項目所費工時統計，這里借用拿來主義，變相為千行代碼缺陷率）。

 

                                                               表2  過去16周每日千行代碼缺陷率
 
          
                                      圖1千行代碼缺陷率X圖
 

                                      圖2千行代碼缺陷率R圖

控制圖檢測過程穩定的判斷標準:
·         一個點落在3σ控制線之外
·         三個連續的點中至少兩個點落在中心的一側，并且距離中心線有兩個以上的σ單位
·         五個連續的點種至少有四個點落在中心線的一側，并且距離中心線有一個以上的σ單位
·         至少有八個連續的點落在中心線的同一側
 
通過以上判斷準則，可以得出結果，被測系統千行代碼缺陷率的過程是穩定的，且可控的，間接說明開發的過程能力是穩定的。
如果我們發現過程是不穩定的，該怎么辦呢？這時我們可以采用6Sigma中所提及的相關工具及方法找出問題所在（可采用頭腦風暴/魚骨圖收集可能的原因；采用柏拉圖分析主要原因），并在探尋試驗中改進方法和流程，這就是6Sigma最著名的DMAIC方法。在軟件工程中存在同樣類似的方法，即PDCA過程。這里就不一一詳細介紹了，畢竟本文所探討的主題是基于缺陷數據的度量和分析。

 
參考書籍：
1.        度量軟件過程-用于軟件過程改進的統計過程控制（Measuring the Software Process-Statistical Process Control for Software Process Improvement）[美]William A. Elrac and Antita D. Carleton，任愛華、劉又誠譯，北京航空航天大學出版社
2.        軟件的質量管理實踐-軟件缺陷預防、清除、管理實用方法，于波、姜艷編著，電子工業出版社

原文轉自：https://blog.csdn.net/roger_ge/article/details/5327331