李軍鋒，顧濱兵，李海浩

(中國人民解放軍91404部隊，河北 秦皇島 066000)

0 引 言

軟件測試作為提高軟件質量的重要手段，測試質量與軟件質量有著直接的關系，國內外測試質量評價的相關研究也提出了不少方法模型[1-2]，但是沒有給出明確、一致的定義[3-16]。軟件測試質量評價，作為測試過程總結階段的一項工作，本身需要快速、準確地得出結果，如果需要建立龐大的模型，進行大量度量元采集和計算[3-12]，在可行性和資源成本[17]等方面往往會受到限制。因此需要一種度量采集簡便、計算方法合理、實施過程可行、評價結果準確的軟件測試質量評價方法。

1 測試質量評價的幾個誤區(qū)

1.1 將軟件缺陷數(shù)量納入測試質量評價

不少評價模型中，將測試過程中能夠發(fā)現(xiàn)的軟件缺陷數(shù)量作為測試質量評價標準之一，但這一點只適用于單獨項目的評價，如果需要對不同項目之間進行測試質量評價對比，除非各個被測軟件的規(guī)模、需求點及隱含的缺陷數(shù)等都完全相同，否則是不適用的。

軟件缺陷的量級是衡量軟件質量的，軟件開發(fā)過程是否嚴謹規(guī)范，開發(fā)人員水平的高低，軟件調試、自測試是否充分，這些都會直接影響最終提交測試的軟件質量。

軟件質量好，本身隱含缺陷極少，測試能夠發(fā)現(xiàn)的缺陷也就越少，不能說明測試質量差；反之軟件質量極差，在測試過程中缺陷頻繁出現(xiàn)，也不能代表測試質量高。

1.2 將測試用例數(shù)量納入測試質量評價

測試用例是指為特定目的而編寫的一組測試輸入、執(zhí)行條件以及預期結果。這里的編寫基本是通過自然語言描述，根據(jù)不同測試人員的個人習慣，會存在不同的語言描述粒度。僅以一個簡單的輸入框功能測試為例，軟件需求是在輸入A、B、C時應分別對應輸出a、b、c，在設計正常的輸入/輸出測試用例時會出現(xiàn)2種極端情況：

1)1個測試用例：測試輸入描述為“分別輸入A、B、C”，預期輸出為“分別對應輸出a、b、c”；

2)3個測試用例：測試輸入分別描述為“A、B、C”，預期輸出分別為“a、b、c”。

以此為例，拓展至一個完整的軟件，這類不同的設計描述習慣，雖然最終的測試效果相同，但用例數(shù)可能會相差數(shù)倍。很顯然，測試用例數(shù)量不適合作為測試質量評價的標準之一。

2 本文提出的測試質量評價方法

通過對當前多種軟件測試質量評價方法的研究，結合軟件測試工作實踐經驗，提出如圖1所示的軟件測試質量評價模型[4-5,13]，評價內容的選取原則為在保證結果相對合理的前提下，盡量易于獲取，其中各評價標準對應的權重值的選擇參考當前不同評價模型[4,13]，并根據(jù)測試實踐經驗進行總結，在實際使用過程中，可在符合普遍標準的前提下進行適當調整，參評項目組達成一致即可。各評價標準的評價內容、取值范圍及權重見表1。

圖1 軟件測試質量評價模型

表1 軟件測試質量評價

評價標準評價內容取值范圍權重/%測試文檔評價測評大綱[-∞,100]4測試說明[-∞,100]4測試記錄[-∞,100]4測試問題單[-∞,100]4測評報告[-∞,100]4測試充分性評價測試類型充分性[0,100]10用例設計充分性[0,100]10測試環(huán)境差異[0,100]10用例執(zhí)行充分性[0,100]10抽測結果評價抽測結果[-∞,100]20測試效率評價需求分析與策劃階段效率[-∞,100]5測試設計與實現(xiàn)階段效率[-∞,100]5測試執(zhí)行階段效率[-∞,100]5測試總結階段效率[-∞,100]5

2.1 測試文檔評價

測試文檔評價(DQ)，主要是指對測評大綱、測試說明、測試記錄、測試問題單及測評報告共5類測試文檔工作產品，依據(jù)評審會及測試質量評價組織的審查提出的文檔問題進行評價，問題級別定義見表2，各問題的分值據(jù)實際經驗而來，計算方式如下：

測試文檔評價=100-(致命問題×100+嚴重問題×10+一般問題×3+輕微問題)

表2 測試文檔問題級別定義

等級問題定義分值輕微問題存在類似編寫格式等問題,但對測試范圍、方法、實施、結論等內容不產生影響1一般問題存在對測試范圍、方法、實施、結論產生輕微不符合、不可信、不完整情況,但不影響工作產品的有效性等問題3嚴重問題存在對測試范圍、方法、實施、結論產生嚴重不符合、不可信、不完整情況,嚴重影響工作產品的有效性等問題10致命問題存在文檔記錄造假、測試過程不實、測試結論不可信、工作產品無效等問題100

定義評價對象集合，測試文檔={測評大綱，測試說明，測試記錄，測試問題單，測評報告}，即D={d1, d2, d3, d4, d5}，可計算出測試文檔評價：

DQ=(d1+d2+d3+d4+d5)×4%

2.2 測試充分性評價

測試充分性評價(AQ)的內容包括測試類型、用例設計、測試環(huán)境建立及用例執(zhí)行4個方面。

1)測試類型充分性。

測試類型的選取通常主要依據(jù)軟件的等級、測試級別及測試委托方要求，根據(jù)軟件需求本身可進行相應裁剪。測試對象明確后，測試類型的基準值相應地就可以確定。

已選取測試類型覆蓋或多于應選取測試類型時，可認為測試類型充分性為100。

已選取測試類型少于應選取測試類型時，在認為各類型的權重相同的情況下，可進行如下計算：

測試類型充分性=

2)用例設計充分性。

測試用例充分性主要考核用例設計是否覆蓋軟件所有需求的功能點、是否覆蓋異常情況、是否覆蓋邊界情況，計算方式如下：

測試設計充分性=100-(未覆蓋功能點×2+未覆蓋異常情況×2+未覆蓋邊界值情況)

功能點是指廣義的功能，含功能、性能、接口、安全性等所有軟件需求。

3)測試環(huán)境差異。

測試環(huán)境充分性主要是從搭建的環(huán)境是否與軟件運行實際環(huán)境一致，環(huán)境差異在采取彌補措施后是否仍會影響測試結果的角度考慮，計算方式如下：

測試環(huán)境充分性=

4)用例執(zhí)行充分性。

未執(zhí)行用例數(shù)與數(shù)量龐大的總設計用例數(shù)進行單純的比較得出的結果，并不能直接反映測試的充分性，這里選取“未執(zhí)行測試用例涉及的功能點”作為評價內容，計算方式如下：

用例執(zhí)行充分性=

5)測試充分性評價[14]。

定義評價內容集合，測試充分性={測試類型充分性，用例設計充分性，測試環(huán)境充分性，用例執(zhí)行充分性}，即A={a1, a2, a3, a4}，可計算得出測試充分性評價：

AQ=(a1+a2+a3+a4)×10%

2.3 抽測結果評價

抽測結果評價(RQ)主要是從抽測考核的角度，由專家組主要結合自身工作經驗采用猜錯法，對軟件部分主要需求指標進行抽選并重新測試，再次確認是否存在未發(fā)現(xiàn)的軟件問題，用例的選擇具有主觀性，但需覆蓋軟件重要功能、工作流程及技術指標等，通過抽測發(fā)現(xiàn)的問題數(shù)量、級別加權、抽測問題系數(shù)計算評價結果，問題級別參見統(tǒng)一行業(yè)的標準。

抽測結果(R)=100-(致命問題×100+嚴重問題×10+一般問題×3+輕微問題)×抽測問題系數(shù)

依據(jù)評價標準權重，可計算得出抽測結果評價：

RQ=R×20%

2.4 測試效率評價[13]

實踐經驗表明，測試的時間越長，發(fā)現(xiàn)的缺陷就會越多，軟件的質量也就越好。經過測試的各個階段后，會發(fā)現(xiàn)軟件的大部分缺陷，在測試結束后軟件交付使用的過程中，隨著時間的推移和用戶對軟件的頻繁使用，仍舊會不斷發(fā)現(xiàn)軟件缺陷。理論上只要有足夠的時間，就能不斷趨近于發(fā)現(xiàn)軟件的所有缺陷，軟件的質量將趨近于完美。

但這樣的測試過程并不是高質量的測試，人們常說的測試工作作為軟件生命周期的一部分，無論是從項目管理角度還是實際的實施過程考慮，終歸是有時間限制的。這就不得不將測試效率納入測試質量評價標準。

測試效率評價(EQ)基準值的來源為軟件測評大綱的進度安排，要求在大綱評審時需要慎重考慮工作量、軟件狀態(tài)、測試環(huán)境、管理成本等多方面因素制定合理的進度計劃，以便對需求分析與策劃、測試設計與實現(xiàn)、測試執(zhí)行及測試總結4個階段的效率進行評價，計算方式如下：

1)當實際完成階段工作的時間≤計劃完成階段工作的時間，可直接給出該階段測試效率評價結果=100。

2)當實際完成階段工作的時間>計劃完成階段工作的時間，計算方式如下：

階段測試效率評價=

這里需要注意，測試進度計劃的制定僅考慮有效測試工作量，以工作日/人為單位，不包括軟件問題整改周期等不可控因素。

3)當實際時間超過計劃時間2倍時，階段測試效率評價會出現(xiàn)負值，同測試文檔評價標準負值一樣，正常納入最終的測試質量評價結果計算。

定義評價內容集合，測試階段效率={需求分析與策劃階段效率，測試設計與實現(xiàn)階段效率，測試執(zhí)行階段效率，測試總結階段效率}，即E={e1, e2, e3, e4}，可計算出測試效率評價：

EQ=(e1+e2+e3+e4)×5%

2.5 測試質量評價

根據(jù)以上評價標準、內容及方法定義，得到測試質量評價(TQ)結果：

TQ=DQ+AQ+RQ+EQ

以2個軟件測試項目A、B為例進行示意驗證，比如通過各項評價內容采集計算分別得到如表3所示的評價結果。

項目A測試質量評價總分為69.3，根據(jù)具體評價結果來看，在“抽測結果評價”過程中因發(fā)現(xiàn)的軟件問題較多導致評價結果為0分，同時“測試執(zhí)行階段效率”因實際工作時間超出計劃工作時間50%，導致該階段測試效率評價為50分，在測試效果和效率上均不夠理想。項目B測試質量評價總分為91.2，從評價結果來看，各項評價內容得分確實均較高。綜上，這種方法得到的評價結果能夠相對合理地體現(xiàn)出各軟件測試項目之間測試質量的差別。

表3 項目A、B測試質量評價結果

評價標準評價內容權重/%評價結果得分ABABDQd1480703.22.8d2480703.22.8d3490803.63.2d4490803.63.2d5480803.23.2AQa1101001001010a21080100810a31080100810a4101001001010RQR20090018EQe151009054.5e25809044.5e3550902.54.5e451009054.5

但很明顯，以上評價結果還存在一個問題，即某一項評價內容得分過低甚至為0或者負數(shù)時，受權重計算方式的影響，最后的測試質量評價結果仍可能是較高的分值，導致評價結果不能完全準確地反映測試的質量。所以最后還需要再增加一個附加條件，如果某一單項評價結果<60分，則要求測試項目組整改相應問題或進行解釋，并由測試質量評價組進行補充檢查，將首次評價及補充整改情況一并納入評價結論。

3 結束語

本文提出的軟件測試質量評價方法，在大幅簡化評價過程的同時，能夠得到合理的評價結論。以促進軟件測試質量的提升為目標，可以與測評機構內部質量管理體系相結合，對各項目測試情況進行打分評價；也可以在多家測評機構聯(lián)合完成大規(guī)模軟件測試項目后，作為不同測評機構間軟件測試質量比對的主要依據(jù)。本文方法還需要進一步研究，重點將在如何使各項評價內容取值的權重更加科學合理，進一步規(guī)范后可制定一定范圍內的評價標準。