在軟件項目中,缺陷是衡量軟件質量和測試工作的一個重要參數,而對于缺陷的分析則是度量測試過程是一個很重要的環節。在測試過程中,通過對缺陷的有效分析而得到的度量結果,對于改進測試過程、提高軟件質量都有著重大意義。IBM Rational ClearQuest 作為 IBM Rational 家族的核心產品之一,提供了包括缺陷數據的管理服務在內的強大的軟件項目全方位管理平臺,并且能夠基于數據自動生成多種圖表報告,為項目提供全方位、全過程的支持?;诖?,本文介紹了如何根據項目需求應用 IBM Rational ClearQuest 創建缺陷報告圖表,并通過分析缺陷報告對測試過程進行有效的度量,從而幫助項目和測試過程的管理做出科學的決策和改進。
軟件測試過程度量和缺陷分析
從當今軟件技術的發展趨勢來看,軟件開發的首要問題更多的集中在管理問題而不是技術問題上,而如何對軟件開發進行有效的控制,提高軟件的質量很大程度上取決于對其開發和測試過程的度量、分析以及改進。通過軟件度量可以改進軟件開發過程,促進項目成功,開發高質量的軟件產品。度量的取向是軟件開發諸多事項的橫斷面。由于在軟件項目中,缺陷是衡量軟件質量和測試工作的一個重要參數,因此對于度量軟件測試過程而言,缺陷的分析是一個十分關鍵的度量取向。通過分析缺陷報告對測試過程進行有效的度量,能夠很大程度上幫助項目和測試過程的管理做出科學的決策和改進。
由于在測試過程中,通過對缺陷的有效分析而得到的度量結果,對于改進測試過程、提高軟件質量都有著重大意義。因此,本文將介紹應用 IBM Rational ClearQuest 生成缺陷數據圖表的主要步驟和應用典型的缺陷圖表對測試過程進行度量的基本方法。
![]() ![]() |
![]()
|
應用 IBM Rational ClearQuest 創建缺陷圖表
IBM Rational ClearQuest 作為 IBM Rational 家族的核心產品之一,提供了包括缺陷數據的管理服務在內的強大的軟件項目全方位管理平臺,并且能夠基于數據自動生成多種圖表報告,為項目提供全方位、全過程的支持。因此,目前很多軟件項目應用 IBM Rational ClearQuest 來管理項目數據并根據選取的特定數據生成圖表。本章將著重介紹如何應用 IBM Rational ClearQuest 生成幾種典型的缺陷數據圖表,包括缺陷模塊分布圖表 (Defect by component),缺陷趨勢圖表 (Defect Submit/Resolve Rate Daily) 和缺陷狀態跟蹤圖表 (Defect Opened Rate Tracking)。
度量圖表的分類和選取步驟
缺陷分析報告的分類
有關測試過程中的圖表按照作用和映射信息的方式大致能分為以下幾類:對比型,狀態跟蹤型,預言型,信息型和過程型。每種圖表有可能涵蓋其中一種或者多種類型。如 IBM Rational ClearQuest 支持缺陷的圖表共有三種:分布圖,趨勢圖和回顧圖。這三類圖表的定義和作用如下:
分布圖用于查看有多少條記錄歸于已定義類別或者與指示的值匹配。它表明所指示記錄的當前狀態。理論上來講,對于缺陷來說,每種屬性字段都能夠定義與之相對應的缺陷分布圖。例如,基于缺陷的屬性如模塊,版本,迭代,所屬者,提交者,優先級,嚴重等級等的缺陷分布都屬于這一類。在基于每個屬性字段的基礎上,還可以進行最多兩次的屬性迭代。那么從定義和作用來看,分布圖就能夠用來反映并比較屬于不同屬性的缺陷信息,它就屬于信息型和對比型的圖表。
趨勢圖用于需要對一段時間的變更請求活動進行度量的場合。只有基于狀態的記錄類型才能用于趨勢圖,其水平軸是以時間作為衡量標準,而用于顯示過濾的第一個字段是狀態,第二個字段可選。趨勢圖可以分為兩類:累計計數和分散計數。
回顧圖又稱期齡圖,用于顯示多少記錄處于選定狀態已有多久。和趨勢圖一樣,也只有基于狀態的記錄類型才能用于回顧圖,如缺陷具有提交中,等待解決,已解決,已關閉等狀態,如果我們想了解有多少缺陷記錄處于提交中狀態超過一周,或者有多少缺陷處于待測試狀態超過 5 天等信息,那么基于缺陷數據的回顧圖可以幫助我們得到答案。
缺陷分析報告的選取步驟
缺陷報告的創建主要分為以下幾個步驟:
在項目的最初階段,就應該明確需要獲得的對象信息有哪些,以便進行數據的收集。如要生成缺陷報告,在項目測試的整個生命周期中,首先需要正確記錄每一個缺陷以及缺陷的必要屬性,其次,要實時的監控并更新這些數據以保證數據的及時性和有效性,此外,如 ODC(正交缺陷分析)還提供了設置某些人員和審核流程的方法以保證缺陷數據的有效性。只有這樣,才能保證數據能夠正確并完整地被記錄下來,才能創建出對項目分析和決策有益的報表。
定義報告也是在項目初期就啟動的操作。用戶首先明確需求,如用戶需要按照不同模塊報告的缺陷的總數,那么圖表報告對象就是缺陷的個數,而缺陷的歸屬類就是模塊。
報告的方式和類型有很多種,如圖表,表格,圖,列表,文字等。到底選什么樣的方式去展示主要取決于哪種方式能夠使用戶最簡單輕松的獲取所需信息。圖表越復雜,信息的涵蓋面就越多,但理解起來也相對晦澀;反之,簡單的圖表較易理解,但也就不能表現較綜合的信息。因此,跟隨用戶角色和需要選擇最適合的就是最好的。
缺陷圖表根據自身定義,可以決定其更新和報告的頻率。如時間間隔為周的缺陷趨勢圖需按周進行更新匯報即可,不需要匯報得太頻繁,因為頻率小于一周報告不會更新任何信息。而某些關鍵圖表便需要更短的匯報周期,以便于及時發現項目中存在的問題。
在分析報告的結果的同時,我們也應考慮:報告結果是不是充足完善,圖表定義是否需要改進等。如按照不同模塊報告的缺陷個數分布圖,當項目過程中,模塊的個數發生改變時,圖表也應該隨之改進,否則就不能夠及時準確的報告項目信息。
原文轉自:http://www.anti-gravitydesign.com