淺談軟件缺陷的分類與管理

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

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

圖1

原文轉自：http://www.kjueaiud.com