GJB5000A二級的MA過程域在軟件測試中的應(yīng)用

胡多海

（南京科瑞達(dá)電子裝備有限責(zé)任公司 江蘇省南京市 211100）

1 研究背景

隨著信息化和電子對抗技術(shù)在戰(zhàn)場中的應(yīng)用越來越廣泛，嵌入在各種武器裝備和系統(tǒng)中的計算機越來越多。由于軟件在設(shè)計、更改上比硬件更靈活和方便，越來越多的本由硬件來實現(xiàn)的功能改成由軟件完成，各武器裝備和系統(tǒng)的功能和性能變得越來越依賴于軟件。因此，軟件的質(zhì)量已經(jīng)成為影響系統(tǒng)質(zhì)量的重要因素。

如何提高軟件的質(zhì)量已經(jīng)成為各研制單位和相關(guān)組織面臨的重要問題。隨著軟件工程在國內(nèi)發(fā)展的幾十年過程中，政府組織和軟件企業(yè)開始意識到其根本問題是在于不能有效管理其軟件過程，在無序和混亂的項目狀態(tài)下，組織無法從先進的技術(shù)、方法和工具中獲益。面對軟件開發(fā)活動，首先需要解決的是無章可循、有章不循問題，其過程通常是隨意的、無序的。從而進行項目管理顯得尤為重要。

針對以上情況，中國人民解放軍總裝備部批準(zhǔn)發(fā)布了GJB5000A-2008，軍標(biāo)中將組織的軟件研制能力成熟度分為五個等級，初始級(1 級)，已管理級（2 級），已定義級（3 級），已定量管理級（4 級），優(yōu)化級（5 級）[1]。如圖 1 所示。

2 級中MA 過程域的目的是開發(fā)和保持測量能力，以支持管理信息的需要。MA 過程域必需實現(xiàn)的專用目標(biāo)和專用實踐如圖 2，“SG”表示專用目標(biāo)，“SP”表示專用實踐。

2 軟件測試概述

軟件測試，是驗證軟件及相關(guān)文檔是否滿足用戶或設(shè)計需求，并盡可能多的發(fā)現(xiàn)潛在的問題。以通過測試發(fā)現(xiàn)問題為手段，以提高軟件的質(zhì)量為目的，更好的滿足用戶需求，提高軟件的可靠性。軍用軟件的研制過程中，各大軍用標(biāo)準(zhǔn)明確軟件測試是必不可少的一部分。軟件測試一般都需要進行測試策劃、測試設(shè)計和實現(xiàn)、測試執(zhí)行以及測試總結(jié)4 個步驟[2,3]。

測試策劃，這個過程要求測試分析人員依據(jù)開發(fā)計劃和被測試軟件有關(guān)設(shè)計文檔對被測試軟件進行分析，以確定測試的要求和終止條件，并滿足軟件特性，獲取測試資源，必要時開發(fā)測試軟件等，并最終形成軟件測試計劃。

測試設(shè)計和實現(xiàn)，這個過程一般要求由開發(fā)人員輔助測試人員完成。一般根據(jù)軟件測試計劃、需求或其它開發(fā)文檔進行測試用例的設(shè)計、獲取測試數(shù)據(jù)、確定測試順序、獲取需要的測試資源、建立有效的測試環(huán)境以及需要時編寫測試程序，最終形成軟件測試說明。

測試執(zhí)行，這個過程要求測試員按照已經(jīng)編制的軟件測試計劃和軟件測試說明的要求進行測試。在執(zhí)行過程中，測試員如實地記錄測試過程、發(fā)現(xiàn)的軟件或文檔的錯誤，并填寫完整測試結(jié)果，最終形成測試記錄。

測試總結(jié)，這個過程要求測試分析人員根據(jù)被測軟件的設(shè)計說明、測試計劃和說明、測試記錄和軟件問題記錄等，對軟件測試進行總結(jié)，最終形成軟件測試報告。

表1：MA 專用目標(biāo)和專用實踐

圖1：軍用軟件研制能力成熟度的五個等級

圖2：MA 過程域

以上4 個測試過程形成的軟件測試計劃、軟件測試說明以及軟件測試報告3 份文檔，充分體現(xiàn)了測量分析的專用目標(biāo)和專用實踐在軟件測試中的應(yīng)用。

3 MA在軟件測試中的應(yīng)用

測量與分析的目的是開發(fā)和保持測量能力，以支持管理信息的需要。MA包含2個專用目標(biāo)，共8個專用實踐。具體分布情況見表 1。

3.1 SG1安排測量與分析活動

表2：SG1 的應(yīng)用

圖3：函數(shù)覆蓋率

圖4：MC/DC 分析圖

圖5：MC/DC 覆蓋率圖

（1）確定測量目標(biāo)：根據(jù)已標(biāo)識的信息需要和目標(biāo)，建立和維護測量目標(biāo)[1,4]。

從產(chǎn)品研制過程和項目管理角度，掌握產(chǎn)品質(zhì)量狀況和減少總的生存周期成本為已標(biāo)識的信息需要。那么建立改進先前的質(zhì)量水平為測量目標(biāo)，并進行維護，才可以滿足已標(biāo)識的信息需要。并且，盡早發(fā)現(xiàn)代碼中的缺陷，避免后期問題追蹤的復(fù)雜性，從而能有效縮短軟件生存周期。

至于如何達(dá)到改進先前的質(zhì)量水平這個測量目標(biāo)，就需要指明測量項。通過測量項來統(tǒng)計分析是否滿足測量目標(biāo)。

（2）指明測量項：指明涉及測量目標(biāo)的測量項[1,4]。

測量項一般包括基本測量項和導(dǎo)出測量項。注釋率、缺陷數(shù)這些數(shù)據(jù)由直接測量獲得，為基本測量項。語句覆蓋率、分支覆蓋率、缺陷密度，這些均是通過兩個或更多基本測量項組合而成，為導(dǎo)出測量項。

（3）指明數(shù)據(jù)采集和存儲規(guī)程：指明將如何獲得和存儲測量數(shù)據(jù)[1,4]。

確保恰當(dāng)?shù)夭杉秸_的數(shù)據(jù)就要明確采集方法，明確了采集方法才能幫助進一步澄清信息需要和測量目標(biāo)。并規(guī)定通過何種手段獲得和存儲數(shù)據(jù)。

（4）指明分析規(guī)程：指明如何對測量數(shù)據(jù)進行分析和報告[1,4]。

事先指明分析規(guī)程，確保能按文檔化的測量目標(biāo)進行合格的分析和報告。這個方法也是對實際上是否采集了必要數(shù)據(jù)的一種查驗。

綜合以上情況，假若當(dāng)前有兩個信息需要：掌握產(chǎn)品質(zhì)量狀況和減少總的生存周期成本，那么專用目標(biāo)1 的4 個專用實踐在軟件測試中的應(yīng)用情況可見表 2。

3.2 SG2提供測量結(jié)果

（1）采集測量數(shù)據(jù)：獲得規(guī)定的測量數(shù)據(jù)[1,4]。

首先，獲得基本測量項的數(shù)據(jù)。如缺陷數(shù)，執(zhí)行測試用例通過數(shù)和不通過數(shù)，執(zhí)行不通過的測試用例要分析是軟件缺陷還是測試用例設(shè)計錯誤。當(dāng)確定為缺陷后方可參與統(tǒng)計，避免數(shù)據(jù)統(tǒng)計出現(xiàn)差錯。其次，生成導(dǎo)出測量項數(shù)據(jù)，導(dǎo)出測量項的數(shù)據(jù)值都是新計算得到的。比如缺陷密度是從基本測量項缺陷數(shù)和有效代碼行數(shù)通過計算衍生出的導(dǎo)出測量項。

（2）分析測量數(shù)據(jù)：分析并解釋測量數(shù)據(jù)[1,4]。

對發(fā)現(xiàn)的缺陷從嚴(yán)重等級角度分析。嚴(yán)重等級從高到低分別是致命、嚴(yán)重、一般和輕微。若致命和嚴(yán)重缺陷占比較高，需要與利益相關(guān)方一起評審結(jié)果，并給出附加分析。如表3 是某型產(chǎn)品在配置項測試中問題等級統(tǒng)計情況。

對表3 中數(shù)據(jù)可進行以下分析；

1.從行數(shù)據(jù)分析，功能測試出現(xiàn)的問題最多，占比高達(dá)69.17%，性能測試出現(xiàn)的問題最少，占比僅4.5%。這說明，開發(fā)人員以后要注意對功能的實現(xiàn)情況，同時軟件測試人員需要更多關(guān)注功能，問題越多的地方越需要更充分的測試，以發(fā)現(xiàn)更多潛在的問題。

2.從列數(shù)據(jù)分析，致命問題出現(xiàn)2 個，一般問題有107 個，占比高達(dá)80.45%。致命問題也就是導(dǎo)致軟件直接退出或卡死，無法繼續(xù)使用。需要同軟件開發(fā)人員一同分析原因，舉一反三，避免類似問題再次發(fā)生。一般問題多數(shù)屬于開發(fā)人員容易忽略的部分，一般常見的有輸入數(shù)據(jù)的有效性未判斷，長度、字符類型、特殊字符等未進行校驗。

從缺陷類型角度分析，分別有設(shè)計缺陷、代碼缺陷、文檔缺陷及其它。一般情況代碼缺陷居多，若出現(xiàn)過多的設(shè)計缺陷，需要進行分析并引起重視。如表4 是某產(chǎn)品在配置項測試中問題類型統(tǒng)計情況。

表3：某型產(chǎn)品配置項測試問題等級統(tǒng)計

表4：某產(chǎn)品配置項測試問題類型統(tǒng)計

表5：某產(chǎn)品部分源代碼

對表4 中數(shù)據(jù)可進行以下分析：

1.從行數(shù)據(jù)比較，此處分析可參考表3 的分析1。

2.從列數(shù)據(jù)分析，代碼問題113 個，占比84.96%，而設(shè)計問題3 個，無其他問題。這說明該軟件從設(shè)計上，基本滿足要求，是可信的。從設(shè)計到代碼實現(xiàn)過程，代碼問題嚴(yán)重影響軟件的質(zhì)量，直接導(dǎo)致功能未實現(xiàn)或性能未達(dá)到指標(biāo)要求。需要開發(fā)人員自身提高對代碼的質(zhì)量審查和調(diào)試，讓問題盡量暴露，節(jié)約開發(fā)成本和周期，從而提高軟件質(zhì)量。

（3）存儲數(shù)據(jù)和結(jié)果：管理和存儲測量數(shù)據(jù)、測量規(guī)格說明和分析結(jié)果[1,4]。

目前可進行軟件測試數(shù)據(jù)管理的相關(guān)軟件比較多。比如開源的禪道集成運行環(huán)境軟件可以實現(xiàn)對測試用例、執(zhí)行情況、缺陷等進行管理。這些重要的測試數(shù)據(jù)均可在測試報告上進行存儲和展示。

（4）交流結(jié)果：向所有利益相關(guān)方報告測量與分析活動的結(jié)果[1,4]。

實現(xiàn)該專用實踐可通過評審測試報告方式，在一份有效的測試報告已存儲足夠的測試數(shù)據(jù)，應(yīng)及時、有效的向利益相關(guān)方通報測量與分析過程的結(jié)果，以支持決策并幫助采取糾正措施。

綜上所述，對任何測量數(shù)據(jù)需要經(jīng)過采集、分析、存儲和交流4 個過程。下面以覆蓋率為例，通過LDRA Testbed 測試工具進行分析。表5 為某產(chǎn)品部分源代碼。

通過盡可能多的設(shè)計測試用例，可實現(xiàn)源代碼的語句覆蓋（Statement Coverage）、分支覆蓋或判定覆蓋（Brach/Decision Coverage）以及修正條件判定覆蓋（Modifiеd Condition/Dеcision Coverage，簡稱MC/DC）均達(dá)到100%的覆蓋率，如圖3 所示。

本案例中有邏輯判斷語句while((val1 < 0.0) && (val2 > 0.0))，存在MC/DC 覆蓋率。若記(val1 < 0.0)為條件C1，(val2 > 0.0)為條件C2。該邏輯判斷語句共存在4 種真值情況，要實現(xiàn)MC/DC 的覆蓋率100%的要求，只需滿足C1 和C2 條件。從圖中可看出滿足條件C1 需要設(shè)計1 和3 兩種情形，滿足條件C2 需要設(shè)計1 和2，綜合兩個條件，只需設(shè)計3 個用例分別滿足1、2 和3 的邏輯取值情況即能實現(xiàn)該語句的MC/DC 覆蓋率100%。

按照以上分析設(shè)計用例并執(zhí)行，通過查看動態(tài)覆蓋分析報告，即可看到如圖5 實現(xiàn)情況，表明已滿足條件C1 和條件C2。

通過以上方法，設(shè)計用例實現(xiàn)對所有被測函數(shù)的覆蓋率。若存在無法達(dá)到100%的應(yīng)給出合理說明，最后統(tǒng)計所有文件的每一個函數(shù)的覆蓋率情況，形成軟件測試報告。

4 結(jié)束語

本文首先介紹了GJB5000A 的相關(guān)背景及軟件測試的一般過程。然后對MA 過程域的各專用目標(biāo)和專用實踐如何在軟件測試中的實施展開了詳細(xì)討論。對軟件工程化在軟件測試中的推進工作有指導(dǎo)作用，為提高組織的測量和分析能力提供依據(jù)。