分析現象發現問題
看到這些現象，我們就會問：真正的問題是什么？通常地，圖表本身只能提供一些現象和事實，并不能告訴我們問題是什么。具體問題的分析還需要借助很多要素和信息。如從現象 1（模塊 4 的缺陷總數最多，模塊 1 的最少）本身來看，出現這種情況的相關因素有很多：
從模塊本身的角度考慮，與模塊本身邏輯復雜程度相關；
從開發角度考慮，與模塊開發質量，開發人員對需求的熟悉程度相關；
從測試角度考慮，與測試覆蓋率，測試人員經驗等相關；
從項目管理角度考慮，與開發測試周期長短，資源多少，環境等因素相關。
這就需要結合項目的其他信息，挖掘問題的根源，才能透過現象看到本質。
假設通過對上述元素的相關信息的調研，我們得出下表的分析結果：
| 模塊 1 | 模塊 2 | |
| 模塊邏輯復雜程度 | 簡單 | 復雜 |
| 模塊開發質量 | 高 | 中等 |
| 開發人員對需求的熟悉程度 | 熟悉 | 一般 |
| 測試覆蓋率 | 高 | 較高 |
| 測試人員經驗 | 豐富 | 豐富 |
| 開發測試周期長短 | 短 | 長 |
| 開發測試資源 | 充足 | 不充足 |
| …… |
根據上表所示，度量人員就能分析出兩模塊缺陷數量差異的原因，分析結果也能在一定程度上為處于項目不同角色的人員提供改進過程的依據。
缺陷趨勢圖
解讀圖表
以第二章的第三節創建的缺陷趨勢圖表 (Defect Submit/Resolve Rate Daily) 為例，如圖 9，圖中折線的個數是狀態和測試類型迭代屬性值的乘積。從圖例可看出，定義狀態是所選擇的值：提交（submitted）和已解決（resolved）；測試類型（Test type）有三種值：FVT，SVT 和 Accessibility。因此折線的個數是 6。圖中藍色折線表示在指定時間段內，功能測試中每天缺陷的提交數量。
列舉現象
通過解讀圖中藍色折線，我們就能夠發現很多現象，如：
現象 1：缺陷提交的數量在 12 月底，1 月上旬某天，2 月上旬某天出現峰值
現象 2：1 月中旬到 2 月下旬這段時間所有類型的缺陷提交數和解決數都趨于零。
……
分析現象發現問題
針對現象 1，我們可以根據追溯缺陷個數峰值出現當天（12 月 31 日）的歷史事件，去解析軟件過程度量軟件質量。假如通過查找項目日志等發現 12 月 31 日，是第一個用于功能測試的 build 產生。通過查詢和總結當天提交的缺陷，發現大部分缺陷都是關于模塊 A 的，那么我們就可以將問題定位于這個 build 的模塊 A。
針對現象 2，通過追溯項目日志，發現這段時間是春節假期，因此缺陷提交數和解決數都趨于零。
提供指導
根據上述兩個現象的問題定位，我們可以提出以下問題并給出建議：
作為開發人員，需要專注在哪里？
當某個 build 產生前，需要更加有效的驗證測試。
對于模塊 A，也許需要總結一下出現大量缺陷的原因，再進行其他模塊的設計和開發作為經驗參考。
作為測試人員，需要專注在哪里？
盡可能在較長的假期前驗證所有缺陷，以提高測試用例的通過率，加快項目進度，并盡早發現問題和解決問題。
缺陷狀態跟蹤圖
解讀圖表
以第二章的第三節創建的缺陷狀態跟蹤圖表 (Defect Opened Rate Tracking) 為例，如圖 12。
此圖表中，橫坐標為 0-1 的柱狀圖表示處于打開狀態持續時間在 1 周以內的缺陷個數。不同的顏色表示不同的測試類型（TestType）。
列舉現象
通過解讀圖表，我們就能夠發現如下現象：
現象 1：處于打開狀態持續時間在 1 周以內的缺陷個數最多
現象 2：測試類型為 Prod 的缺陷處于打開狀態持續時間最長。
……
分析現象發現問題
針對現象 1 和現象 2，我們可以判斷出來 FVT 階段的缺陷處理和解決的速度是較快的；而 Prod 測試的缺陷則解決時間較長。
如果迭代的屬性是模塊，那么我們也可以分析出來哪些模塊的缺陷解決速度較快，哪些較慢。
對于這些解決速度較慢的缺陷，我們就能有針對性地進一步分析其原因，根據原因提出解決方案以便于在今后的項目中避免類似問題的發生。
  |
|
結束語
本文主要介紹了應用 IBM Rational ClearQuest 生成缺陷數據圖表的步驟和應用典型的缺陷圖表對測試過程進行度量的基本方法。通過基于不同缺陷圖表所反映出來的各類趨勢和現象進行分析總結，挖掘可能引起這些趨勢和現象的原因，結合項目執行的實際情況剖析問題的根源，可以使項目組及管理人員獲得正確的信息來改進測試過程，減少研發、測試中的重復工作和預測項目風險。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
