缺陷生命周期(3)

　　重復(Duplicated)：缺陷評審委員會認為該缺陷和某個已經提交的缺陷描述的是同一個問題，可以將該缺陷狀態設置為重復。

　　延期(Deferred)：缺陷不在當前版本解決。

　　無計劃(Unplanned)：在用戶需求中沒有要求或計劃。

　　(3)嚴重程度

　　缺陷的嚴重程度指的是假如缺陷沒有修復時，軟件缺陷對軟件質量的破壞程度，即此軟件缺陷的存在對軟件功能特性和非功能特性產生的影響。缺陷的嚴重程度關注的是缺陷引發的問題對客戶的影響程度。在給缺陷確定嚴重程度的時候，應該從軟件最終用戶的角度進行判斷，即根據缺陷會對用戶使用造成的影響程度來確定。軟件缺陷的嚴重程度和缺陷發生的可能性沒有直接的關系。一般而言，缺陷的影響越大，缺陷的嚴重程度越高。下面是該項目的缺陷嚴重程度的分類，缺陷的嚴重程度被分為四個等級。

　　嚴重程度1(致命的)：產品在正常的運行環境下無法給用戶提供服務，并且沒有其他的工作方式可以補救;或者軟件失效會造成人身傷害或危及人身安全，例如：

　　問題會自發地影響系統的數據傳輸。

　　用戶使用正常的操作步驟就會影響系統提供的服務。

　　軟件的操作系統崩潰，造成數據丟失。

　　無法提供系統的主要功能。

　　可能會造成人身傷害。

　　嚴重程度2(嚴重的)：極大地影響系統提供給用戶的服務，或者嚴重影響系統要求或者基本功能的實現，例如：

　　系統中的一些硬件單板會自動重啟，但沒有影響它們所提供的傳輸性能。

　　用戶使用正常的命令會導致系統重啟或掛起，但不影響系統的數據傳輸。

　　軟件的某個子菜單不起作用，或者會產生錯誤的結果。

　　嚴重程度3(一般的)：系統功能需要增強或存在缺陷，但有相應的補救方法解決這個缺陷，例如：

　　系統的一塊硬件單板失效了，但系統沒有上報相應的告警。

　　功能特征設計不符合系統的需求，不影響系統的業務，并且有相應的補救方法。

　　本地化軟件的某些字符沒有翻譯或者翻譯錯誤。

　　嚴重程度4(輕微的)：細小的問題，不需要補救方法或對功能進行增強;或者操作不方便，容易使用戶誤操作，例如：

　　上報的信息不符合系統的需求，描述不精確或可能對用戶有些誤導。

　　GUI界面問題，不精確或可能產生歧義。

　　(4)優先級

　　優先級是處理軟件缺陷的先后順序的指標。確定缺陷的優先級更多的是站在軟件開發和軟件測試的角度來進行考慮。確定缺陷的優先級有時候可能并不是純技術的問題，還需要考慮修復缺陷的難度和存在的風險，因此，缺陷優先級的確定是一個復雜的過程。同時，優先級的確定也需要考慮缺陷發生的頻率和對目標用戶的影響。該項目中，缺陷的優先級被分為四個等級：

　　優先級1(立即)：用戶的業務或工作過程受阻，或運行中的測試無法繼續。該問題需要立即修復，或必要的話采取臨時措施(如：打補丁的方式)。

　　優先級2(下次發布)：在下次常規的產品發布或下次(內部)測試對象版本交付時實施修正。

　　優先級3(必要時)：在受影響的系統部件應當進行修訂時進行修正。

　　優先級4(未決)：尚無修正計劃。

　　缺陷的嚴重程度和優先級是含義不同但相互聯系密切的兩個概念，它們從不同方面描述了軟件缺陷對軟件質量、用戶、開發過程的影響程度和處理方式。一般來說，嚴重程度高的缺陷具有較高的優先級。嚴重程度高說明缺陷對軟件造成的質量危害性大，需要優先處理，而嚴重性低的缺陷可能只是軟件的瑕疵，可以稍后處理。但是優先級和嚴重程度并不總是一一對應的，也存在優先級低但嚴重程度高的缺陷，或者優先級高但嚴重程度低的軟件缺陷。

　　修改軟件缺陷并不是純技術的問題，有時候需要考慮軟件版本發布和質量風險等因素。下面是關于缺陷嚴重程度和優先級設置方面的一些建議：

　　如果某個嚴重的缺陷只在非常極端的條件下產生，則可以將缺陷的優先級設置得比較低。

　　如果修正一個軟件缺陷需要重新修改軟件的整體架構，可能會產生更多的潛在缺陷，而且市場要求盡快發布軟件版本，那么即使這個缺陷嚴重程度很高，也需要仔細考慮是否需要修改。

原文轉自：http://www.uml.org.cn/Test/201405223.asp