摘 要：嚴(yán)重性和優(yōu)先級(jí)是軟件缺陷的兩個(gè)重要屬性，在軟件測(cè)試過(guò)程中如果對(duì)兩者的概念、劃分方法和關(guān)聯(lián)性理解的不夠準(zhǔn)確，不但對(duì)缺陷的統(tǒng)計(jì)結(jié)果、缺陷報(bào)告的質(zhì)量造成影響，而且還會(huì)延誤軟件的正常發(fā)布期限。本文就如何正確區(qū)分和處理缺陷的嚴(yán)重性和優(yōu)先級(jí)展開討論，旨在提高軟件質(zhì)量、降低研發(fā)風(fēng)險(xiǎn)。

關(guān)鍵詞：軟件測(cè)試；缺陷；嚴(yán)重性；優(yōu)先級(jí)

缺陷的嚴(yán)重性是指缺陷對(duì)被測(cè)試系統(tǒng)造成的破壞程度的大小，這種破壞既包括缺陷對(duì)被測(cè)系統(tǒng)的影響程度，也包括缺陷妨礙系統(tǒng)使用的程度。在軟件測(cè)試中，判斷缺陷的嚴(yán)重性應(yīng)該從軟件最終用戶的角度出發(fā)，評(píng)估缺陷給用戶造成的惡劣后果和產(chǎn)生的損失。

缺陷的優(yōu)先級(jí)是指處理和修正軟件缺陷先后順序的指標(biāo)，即哪些缺陷需要優(yōu)先修正，哪些缺陷可以稍后修正。確定軟件缺陷優(yōu)先級(jí)，更多的是站在軟件開發(fā)工程師的角度考慮問(wèn)題，因?yàn)槿毕莸男拚樞蚴莻€(gè)復(fù)雜的過(guò)程，不純粹是技術(shù)問(wèn)題，而且開發(fā)人員更熟悉軟件代碼，能夠比測(cè)試工程師更清楚修正缺陷的難度和風(fēng)險(xiǎn)。

1 四種錯(cuò)誤和輕重緩急

1.1 判斷缺陷的4種錯(cuò)誤

正確處理和區(qū)分缺陷的嚴(yán)重性和優(yōu)先級(jí)，是包括軟件測(cè)試人員和開發(fā)人員在內(nèi)的全體項(xiàng)目組成員的一件大事，對(duì)于經(jīng)驗(yàn)不很豐富的項(xiàng)目組成員來(lái)說(shuō)，經(jīng)常會(huì)犯下述4種錯(cuò)誤：

①把低嚴(yán)重性的缺陷當(dāng)作高嚴(yán)重性來(lái)處理。

②把高嚴(yán)重性的缺陷當(dāng)作低嚴(yán)重性來(lái)處理。

③把低優(yōu)先級(jí)的缺陷當(dāng)作高優(yōu)先級(jí)來(lái)處理。

④把高優(yōu)先級(jí)的缺陷當(dāng)作低優(yōu)先級(jí)來(lái)處理。

在此，可以將這4種錯(cuò)誤歸結(jié)為2類，在測(cè)試工作中，犯了前2種錯(cuò)誤說(shuō)明在缺陷的判斷上“不分輕重”，出現(xiàn)后2種錯(cuò)誤則表示在缺陷的判斷上“不分緩急”。如果要在測(cè)試工作中準(zhǔn)確判斷缺陷的嚴(yán)重性與優(yōu)先級(jí)，應(yīng)該合理區(qū)分輕重緩急，這既是保證軟件質(zhì)量的重要環(huán)節(jié)，也是項(xiàng)目組成員能力與經(jīng)驗(yàn)的最好體現(xiàn)。

1.2 何為缺陷的輕重緩急

現(xiàn)代管理學(xué)之父彼得·德魯克說(shuō)過(guò)：“做事情必須分清輕重緩急。最糟糕的是什么事都做，這必將一事無(wú)成。”。測(cè)試工作也正是如此，要避免在缺陷的嚴(yán)重性和優(yōu)先級(jí)上判斷失誤，必須分清缺陷的輕重緩急。

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

2 如何劃分嚴(yán)重性和優(yōu)先級(jí)的等級(jí)

將缺陷的嚴(yán)重性和優(yōu)先級(jí)作等級(jí)分類，對(duì)于IT企業(yè)來(lái)說(shuō)是一項(xiàng)非常重要的任務(wù)，因?yàn)橛辛说燃?jí)分類才能協(xié)調(diào)企業(yè)各部門處理事務(wù)的排程。銷售、客服和項(xiàng)目經(jīng)理都需要知道缺陷發(fā)生時(shí)對(duì)交貨期的影響，QA也需要知道軟件目前的品質(zhì)狀況。

確定嚴(yán)重性和優(yōu)先級(jí)的等級(jí)必須全面了解和深刻的體會(huì)缺陷的特征，要從用戶和開發(fā)人員以及市場(chǎng)等因素綜合考慮。從項(xiàng)目組分工來(lái)看，應(yīng)由軟件測(cè)試人員確定缺陷的嚴(yán)重性，由軟件開發(fā)人員確定缺陷的優(yōu)先級(jí)。往往在實(shí)際測(cè)試中，通常都是由軟件測(cè)試人員在缺陷報(bào)告中同時(shí)確定嚴(yán)重性和優(yōu)先級(jí)。

2.1 缺陷的嚴(yán)重性級(jí)別劃分

缺陷的嚴(yán)重性和優(yōu)先級(jí)通常按照級(jí)別劃分，不同的公司或不同的項(xiàng)目組有各自具體表示方式。根據(jù)CMMI5中的定義規(guī)范，缺陷嚴(yán)重等級(jí)可分為3到5個(gè)等級(jí)，所以筆者對(duì)于缺陷嚴(yán)重程度的劃分也分為5個(gè)等級(jí)。1為最嚴(yán)重，依次遞降。

2.2 缺陷的優(yōu)先級(jí)劃分

對(duì)于缺陷的優(yōu)先級(jí)分類在業(yè)界尚無(wú)統(tǒng)一的劃分規(guī)范。一般來(lái)說(shuō)，如果分級(jí)超過(guò)4級(jí)，則會(huì)使分類的判斷尺度變得復(fù)雜，而少于4級(jí)，則無(wú)法保證分類的精確性。所以筆者通常將優(yōu)先級(jí)分為4級(jí)。1為最緊急，依次遞降。

3 嚴(yán)重性與優(yōu)先級(jí)的關(guān)聯(lián)性

缺陷的嚴(yán)重性和優(yōu)先級(jí)是含義不同但相互聯(lián)系密切的兩個(gè)概念。它們都從不同的側(cè)面描述了軟件缺陷對(duì)軟件質(zhì)量和最終用戶的影響程度和處理方式。

一般情況下，缺陷的嚴(yán)重性和優(yōu)先級(jí)之間是存在密切關(guān)聯(lián)的，即嚴(yán)重性越高，處理優(yōu)先級(jí)別越高。然而，嚴(yán)重性和優(yōu)先級(jí)并不總是一一對(duì)應(yīng)的。有時(shí)候嚴(yán)重性高的軟件缺陷，優(yōu)先級(jí)不一定高，甚至不需要處理，而一些嚴(yán)重性低的缺陷卻需要及時(shí)處理，具有較高的優(yōu)先級(jí)。舉例說(shuō)明如下。

3.1 高嚴(yán)重性，低優(yōu)先級(jí)

當(dāng)某個(gè)Bug的發(fā)生概率非常低（如執(zhí)行測(cè)試用例出現(xiàn)該缺陷的幾率低于5%），或僅在極端條件下才引發(fā)該缺陷時(shí)，可能將其優(yōu)先級(jí)定得很低。這里其實(shí)包含了一個(gè)風(fēng)險(xiǎn)評(píng)估的思想，當(dāng)缺陷具有高嚴(yán)重性時(shí)，缺陷對(duì)系統(tǒng)造成的破壞力是很強(qiáng)的，但因?yàn)榘l(fā)生概率很低，開發(fā)方會(huì)認(rèn)為該缺陷被用戶發(fā)現(xiàn)的概率非常低，在產(chǎn)品遇到發(fā)布?jí)毫Φ臅r(shí)候，開發(fā)方會(huì)選擇將缺陷留在下一個(gè)發(fā)布版本之前再進(jìn)行修復(fù)。例如，“當(dāng)上傳附件超過(guò)50G時(shí)，傳輸過(guò)程中出現(xiàn)網(wǎng)站崩潰現(xiàn)象”。從在傳輸過(guò)程中出現(xiàn)網(wǎng)站崩潰的現(xiàn)象上看，這是一個(gè)嚴(yán)重級(jí)別最高的Bug，但觸發(fā)它的條件是用戶上傳了一個(gè)超過(guò)50G的附件。通常，在實(shí)際應(yīng)用中很少有用戶會(huì)去刻意上傳一個(gè)超過(guò)50G的文件，這種極端特殊事件發(fā)生概率是相當(dāng)?shù)偷?。?dāng)一個(gè)軟件版本即將發(fā)布，而又來(lái)不及修改時(shí)，可把這個(gè)Bug設(shè)成低優(yōu)先級(jí)，留到下一次版本發(fā)布前修改掉。

3.2 低嚴(yán)重性，高優(yōu)先級(jí)

這類Bug通常是一些界面或文字上的問(wèn)題。例如，“網(wǎng)站主頁(yè)上的軟件Logo中出現(xiàn)錯(cuò)別字”。對(duì)于這類缺陷，為何要優(yōu)先處理呢？因?yàn)檫@類缺陷看似“微小”，但直接關(guān)系到產(chǎn)品和公司的形象，你無(wú)法想象一款蘋果公司的產(chǎn)品上出現(xiàn)微軟的標(biāo)志，這對(duì)于任何企業(yè)而言都是無(wú)法接受的，必須立即修復(fù)。實(shí)際上，這種缺陷也能很快地被修復(fù)。

4 嚴(yán)重性與優(yōu)先級(jí)的評(píng)估技術(shù)工具

正確評(píng)估和區(qū)分缺陷的嚴(yán)重性和優(yōu)先級(jí)，既是確保測(cè)試順利進(jìn)行的要求，也是保證軟件質(zhì)量的重要環(huán)節(jié)，應(yīng)該引起測(cè)試人員和開發(fā)人員以及全體項(xiàng)目組人員的足夠重視。這里介紹三種常用的技術(shù)工具供大家參考。

4.1 80/20法則

意大利經(jīng)濟(jì)學(xué)家柏拉圖提出：重要的少數(shù)與瑣碎的多數(shù)或稱20/80的定律。就是80%的有效工作往往是在20%的時(shí)間內(nèi)完成的，而20%的工作是在80%的時(shí)間內(nèi)完成的。因此，為了提高測(cè)試質(zhì)量，把那些最嚴(yán)重、最緊急的Bug歸在20%里的缺陷集里，項(xiàng)目組應(yīng)投入80%精力修復(fù)這些Bug。這樣就不會(huì)揀了芝麻，丟了西瓜。所以，只有抓住了重要的關(guān)鍵缺陷，測(cè)試效果才能產(chǎn)生最大的效益，把測(cè)試活動(dòng)用在最有生產(chǎn)力的事情上。

4.2 ABC法則

ABC法則是設(shè)定缺陷優(yōu)先順序重要工具之一。這ABC工具的關(guān)鍵點(diǎn)在于根據(jù)缺陷的重要程度決定優(yōu)先順序，按需求目標(biāo)進(jìn)行量化規(guī)劃。把A類缺陷作為測(cè)試最重要的、最有價(jià)值的、最關(guān)鍵的缺陷，并保證首先把A類缺陷先處理。其次是B類，然后是C類，還有其它一些不緊急也不重要的缺陷可以不處理或延后處理。因此，應(yīng)用ABC方法可更明確地確定各項(xiàng)測(cè)試目標(biāo)，當(dāng)然也能更明確的設(shè)定缺陷的優(yōu)先級(jí)。

5 結(jié)語(yǔ)

通過(guò)上述案例的闡述，可以得知修正軟件缺陷不是一件純技術(shù)問(wèn)題，有時(shí)需要綜合考慮市場(chǎng)發(fā)布和質(zhì)量風(fēng)險(xiǎn)等問(wèn)題。如果某個(gè)嚴(yán)重的軟件缺陷只在非常極端的條件下產(chǎn)生，則沒(méi)有必要馬上解決。另外，如果軟件缺陷的嚴(yán)重性很低，如界面文字拼寫錯(cuò)誤，則必須盡快修正，因?yàn)檫@關(guān)系到軟件和公司的市場(chǎng)形象。

為了保證報(bào)告缺陷的嚴(yán)重性和優(yōu)先級(jí)的一致性，QA需要經(jīng)常檢查測(cè)試和開發(fā)人員對(duì)于這兩個(gè)指標(biāo)的分配和處理情況，及時(shí)發(fā)現(xiàn)問(wèn)題，及時(shí)反饋給項(xiàng)目負(fù)責(zé)人，盡早解決問(wèn)題。

當(dāng)然，比較規(guī)范的軟件測(cè)試，還需要使用軟件缺陷管理工具（如Bugzilla、Quality Center等）進(jìn)行缺陷報(bào)告和處理，開始使用前應(yīng)對(duì)全體測(cè)試人員和開發(fā)人員進(jìn)行培訓(xùn)，對(duì)缺陷嚴(yán)重性和優(yōu)先級(jí)的表示和劃分方法統(tǒng)一規(guī)定和遵守。在測(cè)試項(xiàng)目進(jìn)行過(guò)程中，充分利用評(píng)估技術(shù)法則統(tǒng)計(jì)缺陷的嚴(yán)重性，確定軟件模塊的開發(fā)質(zhì)量，評(píng)估軟件項(xiàng)目實(shí)施進(jìn)度；統(tǒng)計(jì)優(yōu)先級(jí)的分布情況，控制開發(fā)進(jìn)度，盡快處理缺陷，使開發(fā)按照項(xiàng)目進(jìn)度有效進(jìn)行，從而達(dá)到提高軟件的質(zhì)量、降低風(fēng)險(xiǎn)與成本的目的。

[參考文獻(xiàn)]

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

[2]武劍潔，陳傳波，肖來(lái)元.《軟件測(cè)試技術(shù)基礎(chǔ)》（M）.華中科技大學(xué)出版社，2008.

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