|
 |
馮濤 , IBM中國開發中心軟件工程師 2005 年 11 月 Defect分析是軟件開發和測試中一個重要的環節，ODC介紹了一種不同於大家常用的非常有效的defect分類及分析方法。這篇文章簡單的向大家介紹了什麼是ODC，以及如何在項目和產品開發中使用ODC來改進開發測試流程從而增強產品質量。希望讀者具有基本的軟件開發和測試經驗，並且瞭解defect分析的基本方法。 軟件開發中都包含有控制軟件開發的流程。我們設計模塊、開發代碼、對產品進行測試、然後發佈產品。但是，我們怎樣從以前的錯誤中學習，怎樣做得更好呢？一般情況下，我們會拿一些輸出的數據來進行分析，從而知道我們應該怎麼樣和進行什麼樣的改進（如圖1）。但是如何確定我們做的努力是真正有用的呢？這就是defect classification (defect分類) 能夠幫助我們的地方，如果我們可以正確的使用defect classification，它會對我們有很多的幫助。 圖1 
在軟件開發過程中我們會在不同的階段發現數量不等的defect，如圖2所示，對於所發現的defect我們可以逐一的對它們進行分析，例如使用root causal analysis方法，可是這種分析方法佔用了大量的時間和資源，顯然我們非常需要有一種方法可以明確地告訴我們應該在哪裏改進。 圖2  下面我們來看看幾種我們常見的defect 分析方法： 按照defect 嚴重程度分類 我們在測試過程中會根據defect的嚴重程度對defect 進行分類，在這裏我們將嚴重度稱爲severity, 我們有如下圖所示的一個項目不同測試階段的defect的分佈圖： 圖3  在這個圖中defects跟據它們的severity屬性進行了分類， severity爲1的defect是最嚴重的defect, 它使系統根本不能運轉，需要立即進行改正。那severity爲 2的defect 是一般功能性的錯誤，這些錯誤是需求中所要求的，必須改正才能實現系統完整的功能。Severity 爲3的defect是一些細小的錯誤，它們不影響功能的實現，但可能引起用戶的誤解或者使用不當。Severity爲4 的 的defect是測試人員建議改進的地方，如果時間允許開發人員可以選擇性的改正，或者等到下個版本中再改進。從圖3中我們可以看到第一個圖是在一個項目測試前期的時候，這時候1級的defect很多，整個系統還不能夠運轉，正需要大量的時間和人力進行測試和改正代碼錯誤。第二個圖則顯示項目測試已經到了中期，這時候最嚴重的defect已經很少了，系統已經基本可以運轉，然後測試人員發現了大量的功能性的錯誤和細節上的錯誤需要改正。第三個圖顯示了項目測試已經到了末期，這時的產品需求的功能已經實現，只有部分細節和建議需要改進，產品已經可以發佈了。在用severity分類的圖表中，我們可以瞭解到以下有關項目的幾個方面： 1) 工作的優先級 2) 項目的進展狀態 3) 產品的質量 按照component/module分類 對於不同的component或者module，我們也可以有類似的defect分佈圖來說明另外一些問題： 圖4  圖4中，對於第一個圖，我們能看出C模塊中發現的defect明顯的比其他模塊的少，那麼原因可能是C模塊的開發人員技術非常的好。第二個圖中我們可以看出A和C中發現的defect明顯比其他兩個模塊的多，那麼可能這兩個模塊的難度、大小或者是改動的變化比較大，因此而造成了它們中發現的defect比較多。對於第三個圖，C模塊的defect明顯比其他的多，那麼可能是C模塊的開發人員太差了，需要管理者的特別關注了。
Orthogonal Defect Classification簡介 下面我們來介紹ODC，什麼是ODC（Orthogonal Defect Classification）呢？簡單的說，它是另外一種defect分類的方法，它使你能夠快速得到每一個問題的信息來幫助你後面做出正確的決定來解決問題。 開發中應用ODC 作爲一個開發人員我發現的問題如果按類型（type）分類可能是由如下幾種可能：(括號中的英文爲縮寫圖例) 1) 沒有正確的初始化 （Init） 2) 代碼沒有正確的check-in （Chk） 3) 算法問題 （Alg） 4) 功能性的錯誤，可能是模塊內的功能沒有被正確實現，也可能是模塊與模塊之間相聯繫的部分沒有被正確實現。（Fnct Cls） 5) 有可能是有關時間的錯誤 （Time） 6) 界面相關的錯誤 （Intf） 7) 代碼之間相關聯的錯誤，例如錯誤的繼承關係 （Rel'n） 按照type的分類我們有如下的分佈圖： 圖5  圖6  從圖5、圖6中，我們可以瞭解到開發過程中哪個環節的錯誤比較多，例如圖6中算法錯誤和功能性錯誤是最多的那麼應該在單元測試或者code review中着重注意這兩個部分的代碼質量。另外從上圖中我們也可以知道在哪以及如何來改正錯誤代碼。 功能測試中應用ODC 下面我們來看看測試，在FVT（功能測試）中，一個主要的幫助FVT做得更好的指標是trigger, 在ODC中trigger可以簡單的理解爲是什麼樣的測試發現了這個defect。在FVT中我們定義了一下4個trigger：Coverage (這裏的coverage不是我一般意義上理解的測試覆蓋面的意思，它是指normal function, 是任何用戶都會用到的功能，基本的、簡單的功能)，Variation （對於有些對產品比較熟悉的用戶，有可能會願意用不常用的有創造性方法或者輸入來完成同一種動作或者功能，或者單單就是爲了挑錯，在這些嘗試中往往會發現很多漏掉的defect，例如'邊界限制'），Sequencing (用和以前不同的操作流程來完成一種任務功能)，Interaction （當兩個或者多個功能模塊互相交互時可能會發生一些錯誤，例如同時啓動一些功能時可能會造成系統死機）。 下面我們舉例來看看FVT中按trigger分類的defect分佈圖： 圖7  在圖7中我們可以看到，這個產品中在一般的功能Coverage和改變操作順序Sequencing的測試中發現了比較多的defect, 這說明了代碼還需要作更多的單元測試來減少錯誤，從而我們可以瞭解到產品的基本質量水平。 圖8  在圖8中我們可以看到Coverage的錯誤很少，產品的基本質量是可以保證的；Variation的錯誤很多（看來測試組做了大量的這方面的測試），Sequencing 和 Interaction的錯誤也不少，那麼後面的測試中應該加大這兩塊兒的測試。這裏我們可以清楚地知道我們測了什麼還有哪塊需要加大測試力度。 圖9  在圖9中我們可以看到Variation的錯誤很多，那麼加大單元測試的力度可以很好的解決這個問題，例如增加更多的邊界檢查。 系統測試中應用ODC 下面再讓我們來看看SVT(系統測試)， 在系統測試中，ODC定義了另外一組trigger, 它們是：Blocked （有哪些defect阻止了SVT的執行， 最常見的是FVT的defect），Stress （壓力測試的結果很可能是客戶最關心的數據），Recovery (對於數據恢復和出錯處理)，Restart (x系統的啓動和重啓)，Hardware configuration (硬件配置)，Software configuration (軟件配置)。 下面我們舉例來看看SVT中按trigger分類的defect分佈圖： 圖10  在圖10中我們看到了Blocked的defect太多了，顯然這個時候進行大量的SVT測試是不明智的，那麼應該讓產品繼續的進行功能測試，直到Blocked的問題減少到可以接受爲止。 圖11  在圖11中，我們同樣可以瞭解到SVT中進行了哪些測試，在這裏軟件配置測試和壓力測試是需要加強的。 圖12  在圖12中，我們可以瞭解到硬件配置的defect比較多，那麼我們應該要求開發人員更關注這部分的代碼。 從上面的分析中我們看到了ODC中trigger告訴了我們哪裏發現了問題，應該去做些什麼。 ODC對於客戶影響的應用 那麼下面我們再來看看ODC怎麼樣的來影響客戶。軟件產品對於客戶的影響有哪些方面呢？在ODC中定義瞭如下方面：
1. Installability 圖13  這裏圖13是一個產品的defect 影響分佈圖, 我們可以看到這個產品有非常多的問題出在 "capability性能"、"reliability可靠性"、和"usability可用性"上，那麼這樣的產品如果賣給客戶將是可怕的，那麼我們就應該採取相應的動作來完善這幾個方面的問題。 在ODC中，還定義了其他的元素來組合使用以幫助我們更好的瞭解問題出在哪裏，同時幫助我們做出正確的決定。 在測試人員發現一個問題並且開一個defect時，需要給defect定義下面的屬性： 1) Activity, 它是指在哪種測試中發現的defect, 例如：UT、FVT、SVT 等等。 2) Trigger, 問題出現的情況 3) Impact，影響客戶的方面 當開發人員接到一個defect並且開始修改代碼時，他需要定義下面的屬性： 1) Target, 將要在哪裏改正錯誤，例如：design、code 等等 2) Defect Type, defect的類型，例如：算法、初始化 等等 3) Qualifier: 只有三個，他們是missing、incorrect 和extraneous 4) Source: defect 的來源，例如：內部代碼、outsource的代碼等等 5) Age: defect是新代碼還是重寫的代碼 具體可以參考下圖： 圖14 
在項目和產品開發中，我們經常會想到這樣的問題：我們的測試有多有效？單元測試、功能測試、系統測試都做得正確嗎？我們怎樣在需求、設計、開發階段來減少潛在的defect呢？我們的代碼已經完成並且準備好了進入到下一個階段了嗎？我們發現的defect有哪些是屬於上一個版本的？客戶將會感覺我們的產品質量怎麼樣呢？這些都是很關鍵的問題，需要我們改進開發和測試流程，使它們更加有效，從而進一步增強我們產品的質量。那麼怎麼樣改進呢？通過ODC我們可以知道我們採用的哪種測試方法正在幫助我們找出更多的defect（是基本功能測試，還是邊界條件測試或者壓力測試），還有defect是由哪種錯誤造成的（是初始化的問題或者界面的問題，還是其他的原因），錯誤是由於代碼缺失還是代碼錯誤造成的，defect是在老代碼還是新代碼中發現的, defect對於客戶的影響有哪些有多大。找出了這些問題的答案，我們就可以改進我們開發和測試的有效性，增強產品模塊的穩定性，更早的發現那些高風險的模塊，最後使產品的每個版本都比上一個版本質量更好。
|
|
|
馮濤 , IBM中國開發中心軟件工程師 2005 年 11 月 Defect分析是軟件開發和測試中一個重要的環節，ODC介紹了一種不同於大家常用的非常有效的defect分類及分析方法。這篇文章簡單的向大家介紹了什麼是ODC，以及如何在項目和產品開發中使用ODC來改進開發測試流程從而增強產品質量。希望讀者具有基本的軟件開發和測試經驗，並且瞭解defect分析的基本方法。 軟件開發中都包含有控制軟件開發的流程。我們設計模塊、開發代碼、對產品進行測試、然後發佈產品。但是，我們怎樣從以前的錯誤中學習，怎樣做得更好呢？一般情況下，我們會拿一些輸出的數據來進行分析，從而知道我們應該怎麼樣和進行什麼樣的改進（如圖1）。但是如何確定我們做的努力是真正有用的呢？這就是defect classification (defect分類) 能夠幫助我們的地方，如果我們可以正確的使用defect classification，它會對我們有很多的幫助。 圖1
在軟件開發過程中我們會在不同的階段發現數量不等的defect，如圖2所示，對於所發現的defect我們可以逐一的對它們進行分析，例如使用root causal analysis方法，可是這種分析方法佔用了大量的時間和資源，顯然我們非常需要有一種方法可以明確地告訴我們應該在哪裏改進。 圖2 下面我們來看看幾種我們常見的defect 分析方法： 按照defect 嚴重程度分類 我們在測試過程中會根據defect的嚴重程度對defect 進行分類，在這裏我們將嚴重度稱爲severity, 我們有如下圖所示的一個項目不同測試階段的defect的分佈圖： 圖3 在這個圖中defects跟據它們的severity屬性進行了分類， severity爲1的defect是最嚴重的defect, 它使系統根本不能運轉，需要立即進行改正。那severity爲 2的defect 是一般功能性的錯誤，這些錯誤是需求中所要求的，必須改正才能實現系統完整的功能。Severity 爲3的defect是一些細小的錯誤，它們不影響功能的實現，但可能引起用戶的誤解或者使用不當。Severity爲4 的 的defect是測試人員建議改進的地方，如果時間允許開發人員可以選擇性的改正，或者等到下個版本中再改進。從圖3中我們可以看到第一個圖是在一個項目測試前期的時候，這時候1級的defect很多，整個系統還不能夠運轉，正需要大量的時間和人力進行測試和改正代碼錯誤。第二個圖則顯示項目測試已經到了中期，這時候最嚴重的defect已經很少了，系統已經基本可以運轉，然後測試人員發現了大量的功能性的錯誤和細節上的錯誤需要改正。第三個圖顯示了項目測試已經到了末期，這時的產品需求的功能已經實現，只有部分細節和建議需要改進，產品已經可以發佈了。在用severity分類的圖表中，我們可以瞭解到以下有關項目的幾個方面： 1) 工作的優先級 2) 項目的進展狀態 3) 產品的質量 按照component/module分類 對於不同的component或者module，我們也可以有類似的defect分佈圖來說明另外一些問題： 圖4 圖4中，對於第一個圖，我們能看出C模塊中發現的defect明顯的比其他模塊的少，那麼原因可能是C模塊的開發人員技術非常的好。第二個圖中我們可以看出A和C中發現的defect明顯比其他兩個模塊的多，那麼可能這兩個模塊的難度、大小或者是改動的變化比較大，因此而造成了它們中發現的defect比較多。對於第三個圖，C模塊的defect明顯比其他的多，那麼可能是C模塊的開發人員太差了，需要管理者的特別關注了。
Orthogonal Defect Classification簡介 下面我們來介紹ODC，什麼是ODC（Orthogonal Defect Classification）呢？簡單的說，它是另外一種defect分類的方法，它使你能夠快速得到每一個問題的信息來幫助你後面做出正確的決定來解決問題。 開發中應用ODC 作爲一個開發人員我發現的問題如果按類型（type）分類可能是由如下幾種可能：(括號中的英文爲縮寫圖例) 1) 沒有正確的初始化 （Init） 2) 代碼沒有正確的check-in （Chk） 3) 算法問題 （Alg） 4) 功能性的錯誤，可能是模塊內的功能沒有被正確實現，也可能是模塊與模塊之間相聯繫的部分沒有被正確實現。（Fnct Cls） 5) 有可能是有關時間的錯誤 （Time） 6) 界面相關的錯誤 （Intf） 7) 代碼之間相關聯的錯誤，例如錯誤的繼承關係 （Rel'n） 按照type的分類我們有如下的分佈圖： 圖5 圖6 從圖5、圖6中，我們可以瞭解到開發過程中哪個環節的錯誤比較多，例如圖6中算法錯誤和功能性錯誤是最多的那麼應該在單元測試或者code review中着重注意這兩個部分的代碼質量。另外從上圖中我們也可以知道在哪以及如何來改正錯誤代碼。 功能測試中應用ODC 下面我們來看看測試，在FVT（功能測試）中，一個主要的幫助FVT做得更好的指標是trigger, 在ODC中trigger可以簡單的理解爲是什麼樣的測試發現了這個defect。在FVT中我們定義了一下4個trigger：Coverage (這裏的coverage不是我一般意義上理解的測試覆蓋面的意思，它是指normal function, 是任何用戶都會用到的功能，基本的、簡單的功能)，Variation （對於有些對產品比較熟悉的用戶，有可能會願意用不常用的有創造性方法或者輸入來完成同一種動作或者功能，或者單單就是爲了挑錯，在這些嘗試中往往會發現很多漏掉的defect，例如'邊界限制'），Sequencing (用和以前不同的操作流程來完成一種任務功能)，Interaction （當兩個或者多個功能模塊互相交互時可能會發生一些錯誤，例如同時啓動一些功能時可能會造成系統死機）。 下面我們舉例來看看FVT中按trigger分類的defect分佈圖： 圖7 在圖7中我們可以看到，這個產品中在一般的功能Coverage和改變操作順序Sequencing的測試中發現了比較多的defect, 這說明了代碼還需要作更多的單元測試來減少錯誤，從而我們可以瞭解到產品的基本質量水平。 圖8 在圖8中我們可以看到Coverage的錯誤很少，產品的基本質量是可以保證的；Variation的錯誤很多（看來測試組做了大量的這方面的測試），Sequencing 和 Interaction的錯誤也不少，那麼後面的測試中應該加大這兩塊兒的測試。這裏我們可以清楚地知道我們測了什麼還有哪塊需要加大測試力度。 圖9 在圖9中我們可以看到Variation的錯誤很多，那麼加大單元測試的力度可以很好的解決這個問題，例如增加更多的邊界檢查。 系統測試中應用ODC 下面再讓我們來看看SVT(系統測試)， 在系統測試中，ODC定義了另外一組trigger, 它們是：Blocked （有哪些defect阻止了SVT的執行， 最常見的是FVT的defect），Stress （壓力測試的結果很可能是客戶最關心的數據），Recovery (對於數據恢復和出錯處理)，Restart (x系統的啓動和重啓)，Hardware configuration (硬件配置)，Software configuration (軟件配置)。 下面我們舉例來看看SVT中按trigger分類的defect分佈圖： 圖10 在圖10中我們看到了Blocked的defect太多了，顯然這個時候進行大量的SVT測試是不明智的，那麼應該讓產品繼續的進行功能測試，直到Blocked的問題減少到可以接受爲止。 圖11 在圖11中，我們同樣可以瞭解到SVT中進行了哪些測試，在這裏軟件配置測試和壓力測試是需要加強的。 圖12 在圖12中，我們可以瞭解到硬件配置的defect比較多，那麼我們應該要求開發人員更關注這部分的代碼。 從上面的分析中我們看到了ODC中trigger告訴了我們哪裏發現了問題，應該去做些什麼。 ODC對於客戶影響的應用 那麼下面我們再來看看ODC怎麼樣的來影響客戶。軟件產品對於客戶的影響有哪些方面呢？在ODC中定義瞭如下方面：
1. Installability 圖13 這裏圖13是一個產品的defect 影響分佈圖, 我們可以看到這個產品有非常多的問題出在 "capability性能"、"reliability可靠性"、和"usability可用性"上，那麼這樣的產品如果賣給客戶將是可怕的，那麼我們就應該採取相應的動作來完善這幾個方面的問題。 在ODC中，還定義了其他的元素來組合使用以幫助我們更好的瞭解問題出在哪裏，同時幫助我們做出正確的決定。 在測試人員發現一個問題並且開一個defect時，需要給defect定義下面的屬性： 1) Activity, 它是指在哪種測試中發現的defect, 例如：UT、FVT、SVT 等等。 2) Trigger, 問題出現的情況 3) Impact，影響客戶的方面 當開發人員接到一個defect並且開始修改代碼時，他需要定義下面的屬性： 1) Target, 將要在哪裏改正錯誤，例如：design、code 等等 2) Defect Type, defect的類型，例如：算法、初始化 等等 3) Qualifier: 只有三個，他們是missing、incorrect 和extraneous 4) Source: defect 的來源，例如：內部代碼、outsource的代碼等等 5) Age: defect是新代碼還是重寫的代碼 具體可以參考下圖： 圖14
在項目和產品開發中，我們經常會想到這樣的問題：我們的測試有多有效？單元測試、功能測試、系統測試都做得正確嗎？我們怎樣在需求、設計、開發階段來減少潛在的defect呢？我們的代碼已經完成並且準備好了進入到下一個階段了嗎？我們發現的defect有哪些是屬於上一個版本的？客戶將會感覺我們的產品質量怎麼樣呢？這些都是很關鍵的問題，需要我們改進開發和測試流程，使它們更加有效，從而進一步增強我們產品的質量。那麼怎麼樣改進呢？通過ODC我們可以知道我們採用的哪種測試方法正在幫助我們找出更多的defect（是基本功能測試，還是邊界條件測試或者壓力測試），還有defect是由哪種錯誤造成的（是初始化的問題或者界面的問題，還是其他的原因），錯誤是由於代碼缺失還是代碼錯誤造成的，defect是在老代碼還是新代碼中發現的, defect對於客戶的影響有哪些有多大。找出了這些問題的答案，我們就可以改進我們開發和測試的有效性，增強產品模塊的穩定性，更早的發現那些高風險的模塊，最後使產品的每個版本都比上一個版本質量更好。
|