定義BUG狀態(tài) 談到BUG的狀態(tài)，不得不提一下測試的工作模式，較為常見有以下兩種：第一種工作模式為交互式，也就是說由測試工程師提交BUG到管理工具，通知軟件工程師進行修改，軟件工程師根據(jù)BUG狀態(tài)做出反應(yīng)或修改，然后將問題狀態(tài)更新，提交測試版本后，由軟件工程師確認并再次更新問題的狀態(tài)，這種工作模式是較為理想化的，因為中間需要多次溝通協(xié)調(diào)，所以轉(zhuǎn)換周期會長一些，比較適用于大型軟件項目；那么單方觸發(fā)的工作模式，以測試工程師為主導(dǎo)，發(fā)現(xiàn)問題并督促軟件工作師修改，跟蹤修改結(jié)果，這種工作模式較為靈活，測試工程師與軟件工程師之間是一對一或一對二的關(guān)系，問題發(fā)現(xiàn)后能夠及時修改，修復(fù)的周期較短，這種工作模式適用于中小型軟件開發(fā)項目。在這里，我主要說明一下在第二種工作模式下，BUG的狀態(tài)定義。 1.任務(wù)：適用出因為增加合理化要求而提出的問題，在開發(fā)工程師解決問題時，此類問題的優(yōu)先級較低。
2.待改：功能性缺陷，主要體現(xiàn)在功能缺失、程序運行異常、沒有產(chǎn)生正確的運行結(jié)果等，需要軟件工程師優(yōu)先解決的問題。
3.關(guān)閉：表明該問題經(jīng)測試工程師驗證后已經(jīng)解決，并且沒有帶來新錯誤的BUG。
4.需求未定：在《軟件需求說明書》未描述，程序也未實現(xiàn)，但因為該業(yè)務(wù)不完整導(dǎo)致程序不能正常執(zhí)行的問題，需要項目經(jīng)理等管理人員參與討論確定的功能特性。
5.遺留：對軟件影響較小，此次項目周期不做修改的問題。
6.重新開啟：在前面的版本經(jīng)測試工程師驗證通過，在當(dāng)前版本中重復(fù)出現(xiàn)的問題，建議在記錄這類問題時，增加“重復(fù)次數(shù)”字段，用以說明問題的重現(xiàn)概率。
7.非錯：由于測試工程師對軟件需求的理解錯誤，所提交的問題。
8.關(guān)閉的需求：在第4項中說明的問題，經(jīng)過討論后加以確定，并在提交的軟件版本中得以實現(xiàn)，經(jīng)過測試工作師驗證后與確定需求一致并且功能無缺陷的問題。 以上八種狀態(tài)并非適應(yīng)于所有的軟件項目，測試工程師可以對其中的狀態(tài)進行合并或是拆分，根據(jù)測試工程師對程序的理解及測試的不同要求，還可以制定其他的問題狀態(tài)，定義BUG的狀態(tài)主要目的是明確問題的種類，為評價程序缺陷修復(fù)質(zhì)量提供依據(jù)。

轉(zhuǎn)載于:https://blog.51cto.com/38453/271136

與50位技術(shù)專家面對面20年技術(shù)見證，附贈技術(shù)全景圖

總結(jié)

以上是生活随笔為你收集整理的定义BUG的状态的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。