缺陷管理

軟體缺陷軟體程屬，提供息。熟軟體組織采式管缺陷。低熟軟體組織錄缺陷，跟蹤缺陷糾程。熟軟體組織，充缺陷提供息，建組織程基線，量化程管，基礎，缺陷預防程持續優化。

軟體缺陷（）軟體程"副產品"。，缺陷導致軟體產品某程足戶需。

軟體組織必須妥善軟體缺陷。系軟體組織存、展質量根。遺憾，非軟體組織效管軟體缺陷。

對缺陷的描述應該包含以下的內容：

缺陷ID

唯一的缺陷ID，可以根據該ID追蹤缺陷

缺陷狀態

常見的缺陷狀態有：“新建”、“待解決”、“已解決”、“已修復”

一般的，測試人員識別缺陷，其初始狀態是“新建”；項目經理或技術領導分析缺陷，分配給合適的開發人員來解決，狀態流轉為“待解決”；指定的工程師解決缺陷，將其狀態跟蹤到“已解決”，測試人員複核該缺陷，如果複核通過，則關閉缺陷，狀態是“已修復”，如果複核不通過，則打回到“待解決”。

缺陷標題

描述缺陷的標題

缺陷的詳細描述

對缺陷的詳細描述，缺陷如何復現的步驟等等，之所以把這項單獨列出來，是因為對缺陷描述的詳細程度直接影響開發人員對缺陷的修改，描述應該儘可能詳細

缺陷的嚴重程度

描述缺陷的嚴重程度，一般分為“致命”、“嚴重”、“一般”、“細微”四種

缺陷的緊急程度

描述缺陷的緊急程度，從1－4，1是優先順序最高的等級，4是優先順序最低的等級

缺陷的緊急程度與嚴重程度雖然是不一樣的，但兩者密切相關，往往的越是嚴重，就越是緊急，所以有些組織只用“嚴重程度”

缺陷提交人

缺陷提交人的名字

缺陷提交時間

缺陷提交的時間

缺陷所屬項目/模塊

缺陷所屬的項目和模塊，最好能較精確的定位至模塊

缺陷指定解決人

缺陷指定的解決人，在缺陷“新建”狀態為空，在缺陷“待解決”狀態下由項目經理指定相關開發人員修改

缺陷指定解決時間

項目經理指定的開發人員修改此缺陷的deadline

缺陷解決人

最終解決缺陷的人

缺陷處理結果描述

對處理結果的描述，如果對代碼進行了修改，要求在此處體現出修改

缺陷處理時間

缺陷複核人

對被處理缺陷複核的驗證人

缺陷複核結果描述

對複核結果的描述（通過、不通過）

缺陷複核時間

對缺陷複核的時間

測試環境說明

對測試環境的描述

必要的附件

對於某些文字很難表達清楚的缺陷，使用圖片等附件是必要的

除上述描述項外，配合不同的統計的角度，還可以添加上“缺陷引入階段”、“缺陷修正工作量”等屬性。

通常大家發現軟體缺陷時會對軟體缺陷進行分類，可分類的方式只有一種，就是嚴重級別，難道沒有其它的分法嗎。比如我們碰到下面這種情況，測試人員發現有一種功能是必需加入進去的，這時他與程序員說，程序員說沒有時間或是不必要，這時這種情況則會形成兩者的扯皮，最終的結果也就不了了知了，這樣會挫傷測試人員的積極性，下次他們再也不會盡心的考慮產品的問題，只要可以運行就可以了。其實這種情況是可以解決的，下面我會提到一個新的軟體缺陷分類概念，從而有效的解決這個問題。

在軟體缺陷中不僅僅只是嚴重極別，更多的則是功能沒有做到。說到這裡也許大家都理解了，就是需求沒有考慮到，可需求不會一次就很完美的，需要大家的共同努力，來不斷的完善。那麼怎樣才能讓測試人員提出的好的建議得到有效的執行？這就是我下面想說的。在軟體缺陷中還有一種分法，跟據缺陷內容來分，主要分為需求Bug與程序Bug，對於這種分法的好處就是明確了Bug處理的責任人。對於程序Bug我們都知道是由相關開發人員進行處理。下面主要討論一下需求Bug，需求Bug從名稱上來看就知道是要交由需求人員進行處理。可怎麼處理，怎樣在處理的過程中有效？這時，我們的測試人員將需求Bug不是提交給程序員，而是提交給需求分析人員，由他們進行處理。不過這裡我想強調的是對需求Bug的定位，如果這個Bug在軟體需求說明書中明確提到了，這時就不可能定位它為需求Bug，它是必須讓程序員實現的，稱為軟體功能缺陷，提交由程序員進行處理。但如果需求說明書沒有明確提到的，我們則可以定位為需求Bug。

這樣處理有以下好處，首先需求Bug再不象以前，沒有人進行確認，需求的處理人員本來就是需求人員，由他們確認與跟蹤是最好不過的，因為他們對需求有絕對的權威。同時測試人員其實就是最早的用戶，他們的需求就是用戶的需求，這種方法加強了需求人員與測試人員的溝通，使需求得到有效的補充，從而讓產品更加完善。還有測試人員從本質上來說與程序員還是對立的，這裡如果為了這樣一個不是軟體本身問題的問題形成與開發人員的對立，則會出現贏得戰役而丟失整個戰爭的情況，測試人員協調好與開發人員的關係，讓他們更有效的對軟體本身的缺陷形成有效的關注是最好的。還有最為關鍵的一點，測試人員的激情是最重要的，如果他們的想法沒有得到體現，這時會漸漸的失去對測試的興趣，從而軟體的質量則會無法得到保證，通過這種方法可以讓他們看到自己的建議可以通過對需求人員的反映得到實現，讓他們時時覺得自己的想法是可以通過這種方法來有效的推行，這樣工作的積極性才會有保障。

不過從實施的角度來說，還是有一定的困難的，首先要讓大家改變以前那種凡是Bug就是由開發人員負責的觀念，其次需求人員的工作量要加大，不過廣泛的了解需求是他們的本份工作，想來不會很困難，還有必需要有有效的Bug管理工具，比如BugManage等等，不要出現那種對需求人員說了，可過兩天就忘的情況出現，這時需求Bug的生命周期會出現跨越兩個軟體開發周期，因為有些需求會在下一版實現，這時測試人員需要延長對這些需求Bug的管理，不過我想這些需求是他們提出的，會有興趣對這些Bug進行管理的。

缺陷能夠引起軟體運行時產生的一種不希望或不可接受的外部行為結果，軟體測試過程簡單說就是圍繞缺陷進行的，對缺陷的跟蹤管理一般而言需要達到以下的目標：

a,確保每個被發現的缺陷都能夠被解決；

b,這裡解決的意思不一定是被修正，也可能是其他處理方式（例如，在下一個版本中修正或是不修正），總之，對每個被發現的BUG的處理方式必須能夠在開發組織中達到一致；

c,收集缺陷數據並根據缺陷趨勢曲線識別測試過程的階段；決定測試過程是否結束有很多種方式，通過缺陷趨勢曲線來確定測試過程是否結束是常用並且較為有效的一種方式；

d,收集缺陷數據並在其上進行數據分析，作為組織的過程財富。

上述的第一條是最受到重視的一點，在談到缺陷跟蹤管理時，一般人都會馬上想到這一條，然而對第二和第三條目標卻很容易忽視。其實，在一個運行良好的組織中，缺陷數據的收集和分析是很重要的，從缺陷數據中可以得到很多與軟體質量相關的數據。

處於CMM第一級（或稱為初始級）的軟體組織，對軟體缺陷的管理無章可循。工程師們只是在發現缺陷后，修改相應的軟體。通常，沒有人會去記錄自己發現的缺陷。也沒有人知道在新的軟體版本里，究竟糾正了哪些缺陷，還有哪些缺陷未被糾正。而且，只有在下一輪測試中才有可能知道那些所謂已被糾正了的缺陷是否真的被糾正了，更重要的是糾正過程是否引入了新的缺陷。

所以這樣的軟體組織的項目交貨期（Release Date）表現出強烈的不可預測性。並且，為了獲得一個高質量的軟體產品（如果能夠的話），通常要在測試上花費大量的人力。

在CMM第二級（或稱為可重複級）的軟體組織中，軟體項目會從自身的需要出發，制定本項目的缺陷管理過程。一個完備軟體缺陷管理過程通常會包括如下幾個方面： （1）提交缺陷

（2）分析和定位缺陷

（3）提請修改相應的軟體

（4）修改相應的軟體

（5）驗證修改

項目組會完整地記錄開發過程中的缺陷，監控缺陷的修改過程，並驗證修改缺陷的結果。

CMM第三級（或稱為已定義級）的軟體組織會彙集組織內部以前項目的經驗教訓，制定組織級的缺陷管理過程。並且，要求項目根據組織級的缺陷管理過程定製本項目的缺陷管理過程。

從而，整個軟體組織中的項目都遵循類似的過程來管理缺陷。好的缺陷管理實踐成為所有項目的實踐，而教訓也為所有項目所了解。更重要的是，隨著組織的不斷發展完善，組織的過程會得到持續性的改進，所有項目的過程也都會相應的改進。

CMM第四級（或稱為已管理級）的軟體組織會根據已收集的缺陷數據，採用SPC的方法建立軟體過程能力基線（Process CapabilityBaseline）。對於缺陷管理，可以缺陷密度為例，過程能力基線通常包括期望（Mean），能力上限（Upper Control Limit，UCL），能力下限（Low Control Limit，LCL）。其中，"期望"描述了未來項目的缺陷密度的預期值，而UCL和LCL描述了未來項目的缺陷密度的合理變化範圍。

這樣的過程能力基線可以用來：(1)幫助未來的項目設立量化的項目質量目標；(2)理解和控制未來項目的實際結果。

以上圖為例，在項目開始時，項目可以根據過程能力基線並結合本項目的實際情況來設立缺陷密度目標；而在項目的生命周期里，可以使用這樣的過程行為圖（Process Behaviour Chart）來理解和控制項目的實際的缺陷密度。當項目的實際缺陷密度在UCL和LCL之間波動時，可以理解為項目的開發過程處於受控狀態。換言之，當項目的實際缺陷密度超越了UCL或LCL時，可認為某異常的原因（Special Cause）導致了這一現象，必須進行分析並實施某種行動來防止該異常的原因再次發生，從而確保開發過程始終處於受控狀態。

與CMM第四級相比，CMM第五級（或稱為持續優化級）更強調對組織的過程進行持續性改進，從而使過程能力得到不斷的提升。

就缺陷管理而言，軟體組織應當在量化理解其過程能力的基礎上，持續地改進組織級的開發過程、缺陷發現過程，引入新方法、新工具，加強經驗交流，從而實現缺陷預防（Defect Prevention）。

缺陷預防的著眼點在於缺陷的共性原因（Common Cause）。通過找尋、分析和處理缺陷的共性原因，實現缺陷預防。

當實施了缺陷預防，缺陷密度的過程行為圖將可表現為下圖的形式。