軟件測試管理中BUG狀態的定義

軟件測試管理中BUG狀態的定義

談到缺陷（BUG）狀態的狀態，不得不提一下測試的工作模式，較為常見有以下兩種：第一種工作模式為交互式，也就是說由測試工程師提交BUG到管理工具，通知軟件工程師進行修改，軟件工程師根據BUG狀態做出反應或修改，然后將問題狀態更新，提交測試版本后，由軟件工程師確認并再次更新問題的狀態，這種工作模式是較為理想化的，因為中間需要多次溝通協調，所以轉換周期會長一些，比較適用于大型軟件項目；那么單方觸發的工作模式，以測試工程師為主導，發現問題并督促軟件工作師修改，跟蹤修改結果，這種工作模式較為靈活，測試工程師與軟件工程師之間是一對一或一對二的關系，問題發現后能夠及時修改，修復的周期較短，這種工作模式適用于中小型軟件開發項目。在這里，我主要說明一下在第二種工作模式下，BUG的狀態定義。

　　1.任務：適用出因為增加合理化要求而提出的問題，在開發工程師解決問題時，此類問題的優先級較低。

　　2.待改：功能性缺陷，主要體現在功能缺失、程序運行異常、沒有產生正確的運行結果等，需要軟件工程師優先解決的問題。

　　3.關閉：表明該問題經測試工程師驗證后已經解決，并且沒有帶來新錯誤的BUG。

　　4.需求未定：在《軟件需求說明書》未描述，程序也未實現，但因為該業務不完整導致程序不能正常執行的問題，需要項目經理等管理人員參與討論確定的功能特性。

　　5.遺留：對軟件影響較小，此次項目周期不做修改的問題。

　　6.重新開啟：在前面的版本經測試工程師驗證通過，在當前版本中重復出現的問題，建議在記錄這類問題時，增加“重復次數”字段，用以說明問題的重現概率。

　　7.非錯：由于測試工程師對軟件需求的理解錯誤，所提交的問題。

　　8.關閉的需求：在第4項中說明的問題，經過討論后加以確定，并在提交的軟件版本中得以實現，經過測試工作師驗證后與確定需求一致并且功能無缺陷的問題。

　　以上八種狀態并非適應于所有的軟件項目，測試工程師可以對其中的狀態進行合并或是拆分，根據測試工程師對程序的理解及測試的不同要求，還可以制定其他的問題狀態，定義BUG的狀態主要目的是明確問題的種類，為評價程序缺陷修復質量提供依據。

原文轉自：http://www.anti-gravitydesign.com