基于過程數據的軟件測試工作充分性評價

◎中國人民解放軍63921部隊 劉文紅

◎中國航天系統科學與工程研究院 郭 棟 董冠濤 楊 昕

隨著裝備向高精度、智能化方向的快速發展，軟件在裝備中的數量迅速增加，裝備中軟件的復雜程度也越來越高，作為計算機控制系統核心的軟件質量就顯得尤為重要。然而，當前在裝備軟件測試領域，沒有建立全面充分的測試數據收集機制，缺少對測試數據的整理分析工作，嚴重影響了上級機構對軟件質量的全面掌握和把控。各級質量管理部門雖然對于軟件測試十分重視，但在實際工作開展過程中，缺乏對測試工作的質量評價，沒有實際數據支撐，無法科學有效的開展工作。軟件研制單位在對軟件進行開發方測試時，往往按照各自的理解和經驗進行。軟件任務下達方、研制單位、使用單位大多僅了解最后測試結果，只能反映軟件測試工作中某階段或者某類特性的質量情況，將測試過程產生的數據與實際工作相結合的非常少。目前度量軟件測試工作充分性的方式，除了測試覆蓋率指標以外，并沒有其他參考。上級機構只能依靠測試大綱和報告評審會上專家的把關，來定性了解軟件測評的結果情況，而對測試過程和測試工作的把握極不到位。

如何有效度量軟件測試工作的充分性，是擺在各級質量管理部門面前一道亟待解決的難題。研究并給出一套基于測試過程數據對軟件測試工作的充分性進行評價的方法，快速衡量每個測試項目的測試工作充分性，量化的分析和總結，可以幫助軟件測試機構改進軟件測試過程，提高軟件測試效率，從而進一步提升軟件的質量。

一、基于過程數據的軟件測試工作充分性原始度量指標

軟件測試工作質量評價體系的構建是軟件測試工作質量度量的基礎性工作，構建方法通常是對所搜集到的數據進行歸納整理，并根據尺度進行衡量。在選取軟件測試工作質量評價指標時，要盡量將軟件測試工作質量特性以量化形式表示，使評價結果客觀、準確、科學。結合對軟件測試工作現狀的調研分析和對新形勢下測試工作新要求的研究，對軟件測試工作質量的主要影響因素進行分析，并結合測試工作實際和特點，軟件測試驗證過程質量數據收集如下：

（一）工期進度評估

工期進度的評估主要著眼于測試機構按照委托方的時間要求完成工作的能力，包括合同的履約情況和接受緊急工作能力情況兩類參數。最簡單的方式是按照工作進度是否符合合同要求進行評估。更進一步還可按照回歸測試時間要求是否滿足等進行度量。測評的時效數據也可作為測試項目的數據統計積累之一，納入測試工作側面的評價指標。

（二）測試類型評估

對應于《軍用軟件測評實驗室測評過程和技術能力要求》中列出的22 種常用測試類型，每個測試項目都會選擇其中的一些測試類型進行測試。在中國航天科技集團有限公司的企業標準Q/QJA 300-2013 中，分別針對開發方測試和第三方測試所必須選擇的測試類型有一定要求。一般地，CD 級軟件的配置項測試至少應包括文檔審查、功能測試、性能測試、接口測試，具有人機交互界面的軟件應進行人機交互界面測試，具有安裝卸載功能的軟件應進行安裝性測試，具有功能邊界或數據邊界的軟件應進行邊界測試，此外，AB 級軟件的測試在此基礎上還必須包括邏輯測試。

當前軟件測試項目相對于軟件的安全性級別來說，所選擇的測試類型數是否充分，也是一個測試工作質量的參考指標。使用更多測試類型對軟件進行測試，能關注到更多的軟件質量方面，測試工作質量會更好。

（三）測試用例設計充分性

對應每一個選擇的測試類型，根據軟件的規格說明對其進行用例設計，用例應充分覆蓋軟件的各項功能、性能、接口要求。測試用例個數的規模應有一定要求。

該部分是結合筆者另一個研究課題的成果《一種基于主成分分析的軟件測試用例規模估計方法》[1]，通過對被測項目的代碼行數、安全關鍵級別、軟件復雜度、接口復雜度、測試類型個數和編程語言等測試用例規模影響因子信息，在拿到被測軟件，使用靜態工具掃描圈復雜度，閱讀接口文檔得到接口復雜度信息之后，即可通過該課題的算法結果給出完成該項測試工作預計應設計的測試用例規模數量。

該算法成果建立在同類項目的測試用例設計具有較大的相似性和關聯性的基礎上。為了有效利用歷史軟件測試活動的經驗，首先需要構建一個軟件測試項目管理數據庫，對近年來機構從事的測試活動的數據進行收集、梳理和維護。軟件測試項目數據庫中包含被測軟件的基本數據如下：

（1）測試軟件的基本信息：項目名稱、項目標識符、軟件類型、軟件版本、代碼大小、程序語言等；

（2）測試過程數據：測試級別、測試類型、測試項、測試用例、測試用例設計方法、測試環境、測試數據、測試用例執行率等；

（3）被測軟件的故障數據：故障位置、故障等級、故障類型、故障編號、發現時間、打開或關閉等。

基于軟件測試項目數據庫，我們給出軟件測試用例設計評價方法的大致思想。在軟件測試項目管理中，軟件測試項目的測試用例個數評估是一個持續改進優化的過程。可以將用例設計規模評估分為三個階段：初始階段，確定當前項目的測試類型和測試范圍，在歷史數據庫中選擇同類項目數據，進行評估模型定制，并基于定制的評估模型預測當前測試項目所需的用例規模；測試項目執行過程，得到實際測試用例個數；結項后，對測試用例評估結果的準確性進行評價，并將測試項目的過程數據匯總到歷史數據庫中，以提高以后估算結果的準確性。

我們選擇回歸分析方法，利用歷史項目數據估計同類測試項目的預估用例數量，并不斷更新歷史數據庫。測試項目實際完成后，檢查其實際使用的測試用例與預估用例數量的比值，如果嚴重低于預估用量，則其測試工作質量是有問題的。

表1 軟件測試覆蓋率要求

（四）測試覆蓋率

對于軟件的測試覆蓋率，Q/QJA 300-2013《航天型號軟件測試規范》針對開發方測試、第三方測試和驗收測試，對不同安全關鍵級別的軟件分別進行了要求[2]。

（五）測試文檔質量

該部分同樣結合《一種基于主成分分析的軟件測試用例規模估計方法》[1]，使用類似的方法，軟件的相關信息除了能夠對軟件測試用例個數進行預估，也可以預估提交的測試大綱、測試說明、測試報告的文檔頁數。

測試項目實際完成后，檢查其實際編制的測試文檔頁數與預估頁數的比值，如果嚴重低于預估用量，則其測試工作質量是有問題的。

（六）測試過程評審意見情況

測試大綱評審、測試用例評審等質量控制關鍵節點中，對評審所提出的問題易發現程度和問題嚴重程度的綜合評估。每條評審意見的針對問題的嚴重等級越高，易發現程度越低（問題易發現但自己沒有發現），則說明工作質量越糟糕，評價分數越低。

（七）下一驗證過程的問題回溯情況

常規考慮的測出問題數和千行代碼問題數KLOC，更多表征的是衡量被測軟件的質量，而非測試工作的質量。因此在軟件的測試工作質量中，我們并未選擇該指標，而是選擇了另一個指標：下一驗證過程問題回溯，來對測試工作質量進行評價。

軟件測試工作的目標是盡可能發現問題。在從單元測試、部件測試、配置項測試到系統測試這樣一輪輪的測試，乃至后續的定型測試和軟件使用過程中，每一個測試過程都可能發現新的軟件問題，其中一些問題是在前述測試過程中無法發現的。例如：單元測試更關注軟件單元內部的結構和功能，對單元間的調用接口關注不夠，軟件單元間的調用接口如果出現問題，不容易在單元測試中發現，而更容易在部件測試中去發現。

但若在前一個測試過程檢出的問題未檢出，而在后一個測試過程被檢出，則表明前一測試過程的工作質量有所欠缺。因此需要對每一測試過程測出的問題進行分類計數，統計測出問題中屬于前一測試過程應測出未測出的個數，作為本項評價指標。

該項指標的設立，也是對軟件測試工作質量問題的一個針對性的措施，通過相應指標的設立來促使軟件測試機構提高測試工作質量，盡可能的減少問題遺留到后續驗證過程。

表2 軟件測試工作質量度量元定量計算

度量指標名子度量指標名方法?■ 0.6 ?0.6 ?????測試用例設計充分性語 句覆 蓋率參考GB/T 38634.4-2021 的計算方式。建議采用測試工具自動統計。測試用例設計充分性所設計的用例個數與預期設計的用例個數間的到的語句行數占代碼可執行代碼總行數的比率測試項目所設計的用例個數與預期設計的用例個數間的符合程度??X=B/A A—— 代碼可執行代碼總行數；B——執行測試時所執行到的語句行數???，當???0.6 ?0.4 ?????，當????2?1，當??2?測試項目的預期用例個數A計算參考1.3中的方法。實際測試用例個數B從測評報告中可直接獲得，或從測試說明/記錄中計數得到。A——測試項目的預期用例個數B——實際測試用例個數語句覆蓋率測 試覆 蓋率執行測試時所執行到的語句行數占代碼可執行代碼總行數的比率分 支覆 蓋率X=B/A A—— 代碼可執行代碼總行數B——執行測試時所執行到的語句行數X=B/A A—— 代碼可執行代碼總行數；B——執行測試時所執行到的語句行數參考GB/T 38634.4-2021的計算方式。建議采用測試工具自動統計。參考GB/T 38634.4-2021 的計算方式。建議采用測試工具自動統計。測試覆蓋率分支覆蓋率執行測試時所執行到的代碼分支數占代碼中所有分支總數的比率執行測試時所執行到的代碼分支數占代碼中所有分支總數的比率X=B/A A—— 代碼可執行代碼總行數B——執行測試時所執行到的語句行數參考GB/T 38634.4-2021的計算方式。建議采用測試工具自動統計。MC/DC覆 蓋率修正的條件判定覆蓋率MC/DC覆蓋率修正的條件判定覆蓋率X=B/A A——代碼中，所有單個布爾條件可以獨立影響判定結果的判定條件，其布爾值的可行組合總數B——執行測試時實際執行到的組合數參考GB/T 38634.4-2021 的計算方式。建議采用測試工具自動統計。X=B/A A——代碼中，所有單個布爾條件可以獨立影響判定結果的判定條件，其布爾值的可行組合總數B——執行測試時實際執行到的組合數參考GB/T 38634.4-2021的計算方式。建議采用測試工具自動統計。???■ 0.6 ?0.6 ?????，當???0.6 ?0.4 ?????測試文檔質量測試文檔質量測試文檔頁數與預期文檔頁數間的符合程度測試文檔頁數與預期文檔頁數間的符合程度???，當????2?1，當??2?A——測試項目對應文檔的預期文檔頁數B——實際測試文檔頁數針對測試項目中每一份要求的文檔計算出分別的X之后，求均值測試項目的預期文檔頁數A計算參考1.5中的方法。實際測試文檔頁B從各測試文檔中可直接獲得。時所執行

二、軟件測試工作質量的綜合評價方法

根據軟件測試工作質量評價模型及采集到的各工作評價指標度量元的原始數據，設計科學的定性與定量結合的評價方法，對數據進行分析、整理與擬合，將每個度量元的原始數據通過計算函數將其轉換成值域范圍在[0,1]區間內的度量指標值，再將其結合權重指標進行加權計算。

上節中所列出的測試工作質量評價各度量元，定量計算如下。

（一）測試過程評審意見情況的計算

測試過程中常見的控制節點評審包括測試需求評審、測試計劃評審、測試說明評審、測試環境就緒評審、測試總結評審等。記錄每次評審中專家所提意見共計n 條，并劃分每條意見所針對問題的嚴重等級A 和易發現程度B 兩個屬性。每個屬性均分解為5 級。針對問題的嚴重等級越高，易發現程度越低（問題易發現但自己沒有發現），則說明工作質量越糟糕，評價分數越低。所有評審意見的這兩個屬性分的均值即為對應子度量指標值。具體如下：

最終測試過程評審意見情況的度量指標計算公式如下：

（二）下一測試過程問題回溯情況的計算

在下一個測試過程中發現上一測試過程中應發現而沒發現的問題，每個問題都具有發現問題難度、問題嚴重等級、發現問題的應發現驗證過程三個屬性，發現問題難度越小、問題嚴重等級越高、發現問題的應發現驗證過程越靠前（與當前驗證過程距離越遠），最終的評價分數越低。

設發現問題難度包括1、2、3、4、5 五個等級。其中，等級1 為執行軟件基本功能即能發現的問題；等級2 為需要進行一定的用例設計方法，執行到較偏的邏輯分支才能發現的問題；如此遞推直至等級5 為極為隱蔽難以發現的問題。發現問題難度每增加一個等級，則權重增加p1，發現的問題難度等級為N1，則發現問題難度對交付后軟件問題評價結果權重公式為：

設發現問題嚴重等級包括1（致命）、2（嚴重）、3（一般）、4（輕微）、5（建議）五個等級，發現問題嚴重等級每降低一個等級（對應的值增加），則權重增加p2，發現的問題難度等級為N2，則發現問題難度對交付后軟件問題評價結果權重公式為：

設發現問題發生階段包括單元測試、部件測試、配置項測試、分系統測試、系統測試等，假設劃分階段數為S，按階段先后順序對應的標注值為1、2、3、…、S，發現問題發生階段往后一個階段，則權重增加p3，發現問題發生階段對應值為N3，則發現問題難度對交付后軟件問題評價結果權重公式為：

設該階段總分為B，如果在軟件交付后共發現k 個問題，第i 問題對應的發現問題難度、問題嚴重等級、發現問題的發生階段指標值分別為Ni1、Ni2、Ni3（當未發現問題，即k=0 時，N01=6、N02=6、N03=S+1），對應該階段的得分值權重為：

同前，p1、p2、p3初始值可以根據專家經驗確定，在后期累積歷史數據后，可通過對原始數據經過數學處理獲取權重來進行調整。

X 歸一化后計算公式為：

三、權重的確定

本項目邀請了數十名軟件測試領域專家對影響軟件測試工作質量的各個指標權重進行評估，采用專家打分法最后給出了軟件測試工作質量評價的權重層次化結構如下表所示。

表3 軟件測試工作質量評價的權重層次化結構表

四、總結

本研究指出了軟件測試工作的現狀與不足問題，提出了相應的改進途徑，包括采取全面工作質量評價方法來以評為促，幫助軟件測試工作質量提高。在此基礎上研究提出的軟件測試工作質量度量評價模型可用于各軟件測評單位的內部質量管理。對于同一組織內部，主要采用度量評價模型中的項目層面數據，通過對各個測試項目的相關數據采集來評價測試項目的工作質量，定量分析軟件測試工作績效數據，形成對軟件測試質量的持續正向反饋。