軟體缺陷的分類與管理
通常大家發現軟體缺陷時會對軟體缺陷進行分類，可分類的方式只有一種，就是嚴重極別,難道沒有其它的分法嗎。比如我們碰到下面這種情況，測試人員發現有一種功能是必需加入進去的，這時他與程式設計師說，程式設計師說沒有時間或是不必要，這時這種情況則會形成兩者的扯皮，最終的結果也就不了了知了，這樣會戳傷了測試人員的積極性，下次他們再也不會盡心的考慮產品的問題，只要可以執行就可以了。其實這種情況是可以解決的,下面我會提到乙個新的軟體缺陷分類概念，從而有效的解決這個問題。
在軟體缺陷中不僅僅只是嚴重極別，更多的則是功能沒有做到。說到這裡也許大家都理解了，就是需求沒有考慮到，可需求不會一次就很完美的，需要大家的共同努力，來不斷的完善。那麼怎樣才能讓測試人員提出的好的建議得到有效的執行？這就是我下面想說的。在軟體缺陷中還有一種分法，跟據缺陷內容來分，主要分為需求bug與程式bug，對於這種分法的好處就是明確了bug處理的責任人。對於程式bug我們都知道是由相關開發人員進行處理。下面主要討論一下需求bug,需求bug從名稱上來就知道是要交由需求人員進行處理，可怎麼處理，怎樣在處理的過程中有效的讓這些創意得到體現。現在我們都有bug管理系統，這時我們的測試人員將需求bug不是提交給程式設計師，而是提交給需求分析人員，由他們進行處理，不過這裡我想強調的是對需求bug的定位，如果這個bug在軟體需求說明書中明確提到了，這時就不可能定位它為需求bug，它是必需讓程式設計師實現的，稱為軟體功能缺陷，提交由程式設計師進行處理。但如果需求說明書沒有明確提到的，我們則可以定位為需求bug，處理的流程如圖。
圖1這樣處理有以下好處，首先需求bug再不象以前，沒有人進行確認，需求的處理人員本來就是需求人員，由他們確認與跟蹤是最好不過的，因為他們對需求有絕對的權威。同時測試人員其實就是最早的使用者，他們的需求就是使用者的需求，這種方法加強了需求人員與測試人員的溝通，使需求得到有效的補充，從而讓產品更加完善。還有測試人員從本質上來說與程式設計師還是對立的，這裡如果為了這樣乙個不是軟體本身問題的問題形成與開發人員的對立，則會出現贏得戰役而丟失整個戰爭的情況，測試人員協調好與開發人員的關係，讓他們更有效的對軟體本身的缺陷形成有效的關注是最好的。還有最為關鍵的一點，測試人員的激情是最重要的，如果他們的想法沒有得到體現，這時會漸漸的失去對測試的興趣，從而軟體的質量則會無法得到保證，通過這種方法可以讓他們看到自己的建議可以通過對需求人員的反映得到實現，讓他們時時覺得自己的想法是可以通過這種方法來有效的推行，這樣工作的積極性才會有保障。
不過從實施的角度來說，還是有一定的困難的，首先要讓大家改變以前那種凡是bug就是由開發人員負責的觀念，其次需求人員的工作量要加大，不過廣泛的了解需求是他們的本份工作，想來不會很困難，還有必需要有有效的bug管理工具，比如bugmanage等等，不要出現那種對需求人員說了，可過兩天就忘的情況出現，這時需求bug的生命週期會出現跨越兩個軟體開發周期，因為有些需求會在下一版實現，這時測試人員需要延長對這些需求bug的管理，不過我想這些需求是他們提出的，會有興趣對這些bug進行管理的。
軟 件 缺 陷 分 類 標 準
缺陷的定義 軟體沒有達到產品說明書表明的功能 軟體出現了產品說明書中不一致的表現 軟體功能超出產品說明書的範圍 軟體沒有達到使用者期望的目標 雖然產品說明書中沒有要求 測試員或使用者認為軟體的易用性差 不是所有缺陷都會修改 市場的壓力使得產品最終發行有時間限制 測試員錯誤理解或者不正確操作引出的缺陷...
軟體缺陷管理流程
軟體缺陷 bug 能夠引起軟體執行時產生的一種不希望或不可接受的外部行為結果，而 軟體測試缺陷管理流程。一 缺陷產生的原因 通常開發及測試人員所講述的軟體錯誤和軟體缺陷是兩個不同的概念，簡單的來講軟體錯誤是指在軟體宣告週期內不希望或不可見接受的人為錯誤，其結果是導致軟體缺陷的產生。在軟體動態執行過程...
軟體缺陷管理流程
軟體缺陷 bug 能夠引起軟體執行時產生的一種不希望或不可接受的外部行為結果，而軟體測試的過程簡單來說就是圍繞缺陷進行的。而為了有效的的跟蹤 管理bug的處理情況，指導測試團隊和開發人員有效的處理相關bug，有必要採用一套完整的方法 手段對其進行管理，也就是本文將介紹的缺陷管理流程。一 缺陷產生的原...