試述軟件缺陷的嚴重性與優先級

摘 要：嚴重性和優先級是軟件缺陷的兩個重要屬性，在軟件測試過程中如果對兩者的概念、劃分方法和關聯性理解的不夠準確，不但對缺陷的統計結果、缺陷報告的質量造成影響，而且還會延誤軟件的正常發布期限。本文就如何正確區分和處理缺陷的嚴重性和優先級展開討論，旨在提高軟件質量、降低研發風險。

關鍵詞：軟件測試；缺陷；嚴重性；優先級

缺陷的嚴重性是指缺陷對被測試系統造成的破壞程度的大小，這種破壞既包括缺陷對被測系統的影響程度，也包括缺陷妨礙系統使用的程度。在軟件測試中，判斷缺陷的嚴重性應該從軟件最終用戶的角度出發，評估缺陷給用戶造成的惡劣后果和產生的損失。

缺陷的優先級是指處理和修正軟件缺陷先后順序的指標，即哪些缺陷需要優先修正，哪些缺陷可以稍后修正。確定軟件缺陷優先級，更多的是站在軟件開發工程師的角度考慮問題，因為缺陷的修正順序是個復雜的過程，不純粹是技術問題，而且開發人員更熟悉軟件代碼，能夠比測試工程師更清楚修正缺陷的難度和風險。

1 四種錯誤和輕重緩急

1.1 判斷缺陷的4種錯誤

正確處理和區分缺陷的嚴重性和優先級，是包括軟件測試人員和開發人員在內的全體項目組成員的一件大事，對于經驗不很豐富的項目組成員來說，經常會犯下述4種錯誤：

①把低嚴重性的缺陷當作高嚴重性來處理。

②把高嚴重性的缺陷當作低嚴重性來處理。

③把低優先級的缺陷當作高優先級來處理。

④把高優先級的缺陷當作低優先級來處理。

在此，可以將這4種錯誤歸結為2類，在測試工作中，犯了前2種錯誤說明在缺陷的判斷上“不分輕重”，出現后2種錯誤則表示在缺陷的判斷上“不分緩急”。如果要在測試工作中準確判斷缺陷的嚴重性與優先級，應該合理區分輕重緩急，這既是保證軟件質量的重要環節，也是項目組成員能力與經驗的最好體現。

1.2 何為缺陷的輕重緩急

現代管理學之父彼得·德魯克說過：“做事情必須分清輕重緩急。最糟糕的是什么事都做，這必將一事無成。”。測試工作也正是如此，要避免在缺陷的嚴重性和優先級上判斷失誤，必須分清缺陷的輕重緩急。

“輕”，指的是相對重要但不緊急的缺陷；“重”，是指最重要也是最緊急的缺陷；“緩”，指的是不重要也不緊急的缺陷；“急”，則是指不是最重要但卻最為緊急的缺陷。理清這種關系之后，就算同時測試許多不同類型的缺陷，也會很快弄清楚哪些缺陷是必須馬上完成的，哪些缺陷可以暫時緩一緩，這樣也就不會被堆積如山的Bug所壓垮，缺陷修復和回歸測試的效率自然也會得到很大的提高。當然，要做到這一點必須明白嚴重性與優先級的等級劃分和其間的關聯性，并借助相關的評估技術工具才能實現。

2 如何劃分嚴重性和優先級的等級

將缺陷的嚴重性和優先級作等級分類，對于IT企業來說是一項非常重要的任務，因為有了等級分類才能協調企業各部門處理事務的排程。銷售、客服和項目經理都需要知道缺陷發生時對交貨期的影響，QA也需要知道軟件目前的品質狀況。

確定嚴重性和優先級的等級必須全面了解和深刻的體會缺陷的特征，要從用戶和開發人員以及市場等因素綜合考慮。從項目組分工來看，應由軟件測試人員確定缺陷的嚴重性，由軟件開發人員確定缺陷的優先級。往往在實際測試中，通常都是由軟件測試人員在缺陷報告中同時確定嚴重性和優先級。

2.1 缺陷的嚴重性級別劃分

缺陷的嚴重性和優先級通常按照級別劃分，不同的公司或不同的項目組有各自具體表示方式。根據CMMI5中的定義規范，缺陷嚴重等級可分為3到5個等級，所以筆者對于缺陷嚴重程度的劃分也分為5個等級。1為最嚴重，依次遞降。

2.2 缺陷的優先級劃分

對于缺陷的優先級分類在業界尚無統一的劃分規范。一般來說，如果分級超過4級，則會使分類的判斷尺度變得復雜，而少于4級，則無法保證分類的精確性。所以筆者通常將優先級分為4級。1為最緊急，依次遞降。

3 嚴重性與優先級的關聯性

缺陷的嚴重性和優先級是含義不同但相互聯系密切的兩個概念。它們都從不同的側面描述了軟件缺陷對軟件質量和最終用戶的影響程度和處理方式。

一般情況下，缺陷的嚴重性和優先級之間是存在密切關聯的，即嚴重性越高，處理優先級別越高。然而，嚴重性和優先級并不總是一一對應的。有時候嚴重性高的軟件缺陷，優先級不一定高，甚至不需要處理，而一些嚴重性低的缺陷卻需要及時處理，具有較高的優先級。舉例說明如下。

3.1 高嚴重性，低優先級

當某個Bug的發生概率非常低（如執行測試用例出現該缺陷的幾率低于5%），或僅在極端條件下才引發該缺陷時，可能將其優先級定得很低。這里其實包含了一個風險評估的思想，當缺陷具有高嚴重性時，缺陷對系統造成的破壞力是很強的，但因為發生概率很低，開發方會認為該缺陷被用戶發現的概率非常低，在產品遇到發布壓力的時候，開發方會選擇將缺陷留在下一個發布版本之前再進行修復。例如，“當上傳附件超過50G時，傳輸過程中出現網站崩潰現象”。從在傳輸過程中出現網站崩潰的現象上看，這是一個嚴重級別最高的Bug，但觸發它的條件是用戶上傳了一個超過50G的附件。通常，在實際應用中很少有用戶會去刻意上傳一個超過50G的文件，這種極端特殊事件發生概率是相當低的。當一個軟件版本即將發布，而又來不及修改時，可把這個Bug設成低優先級，留到下一次版本發布前修改掉。

3.2 低嚴重性，高優先級

這類Bug通常是一些界面或文字上的問題。例如，“網站主頁上的軟件Logo中出現錯別字”。對于這類缺陷，為何要優先處理呢？因為這類缺陷看似“微小”，但直接關系到產品和公司的形象，你無法想象一款蘋果公司的產品上出現微軟的標志，這對于任何企業而言都是無法接受的，必須立即修復。實際上，這種缺陷也能很快地被修復。

4 嚴重性與優先級的評估技術工具

正確評估和區分缺陷的嚴重性和優先級，既是確保測試順利進行的要求，也是保證軟件質量的重要環節，應該引起測試人員和開發人員以及全體項目組人員的足夠重視。這里介紹三種常用的技術工具供大家參考。

4.1 80/20法則

意大利經濟學家柏拉圖提出：重要的少數與瑣碎的多數或稱20/80的定律。就是80%的有效工作往往是在20%的時間內完成的，而20%的工作是在80%的時間內完成的。因此，為了提高測試質量，把那些最嚴重、最緊急的Bug歸在20%里的缺陷集里，項目組應投入80%精力修復這些Bug。這樣就不會揀了芝麻，丟了西瓜。所以，只有抓住了重要的關鍵缺陷，測試效果才能產生最大的效益，把測試活動用在最有生產力的事情上。

4.2 ABC法則

ABC法則是設定缺陷優先順序重要工具之一。這ABC工具的關鍵點在于根據缺陷的重要程度決定優先順序，按需求目標進行量化規劃。把A類缺陷作為測試最重要的、最有價值的、最關鍵的缺陷，并保證首先把A類缺陷先處理。其次是B類，然后是C類，還有其它一些不緊急也不重要的缺陷可以不處理或延后處理。因此，應用ABC方法可更明確地確定各項測試目標，當然也能更明確的設定缺陷的優先級。

5 結語

通過上述案例的闡述，可以得知修正軟件缺陷不是一件純技術問題，有時需要綜合考慮市場發布和質量風險等問題。如果某個嚴重的軟件缺陷只在非常極端的條件下產生，則沒有必要馬上解決。另外，如果軟件缺陷的嚴重性很低，如界面文字拼寫錯誤，則必須盡快修正，因為這關系到軟件和公司的市場形象。

為了保證報告缺陷的嚴重性和優先級的一致性，QA需要經常檢查測試和開發人員對于這兩個指標的分配和處理情況，及時發現問題，及時反饋給項目負責人，盡早解決問題。

當然，比較規范的軟件測試，還需要使用軟件缺陷管理工具（如Bugzilla、Quality Center等）進行缺陷報告和處理，開始使用前應對全體測試人員和開發人員進行培訓，對缺陷嚴重性和優先級的表示和劃分方法統一規定和遵守。在測試項目進行過程中，充分利用評估技術法則統計缺陷的嚴重性，確定軟件模塊的開發質量，評估軟件項目實施進度；統計優先級的分布情況，控制開發進度，盡快處理缺陷，使開發按照項目進度有效進行，從而達到提高軟件的質量、降低風險與成本的目的。

[參考文獻]

[1]張海藩，倪寧.《軟件工程（第三版）》（M）.人民郵電出版社，2012.

[2]武劍潔，陳傳波，肖來元.《軟件測試技術基礎》（M）.華中科技大學出版社，2008.

[3]朱少民.《全程軟件測試》（M）.電子工業出版社，2007.