測試缺陷處理流程圖

　　缺陷管理/軟體缺陷管理是在軟體生命週期中識別、管理、溝通任何缺陷的過程***從缺陷的識別到缺陷的解決關閉***，確保缺陷被跟蹤管理而不丟失。以下是小編為大家整理的關於，給大家作為參考，歡迎閱讀!

　　軟體缺陷

　　處理方法

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

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

　　優點

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

　　缺陷

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