指揮自動化信息系統軟件鑒定測評情況分析與建議

劉軍

關鍵詞 大型指揮自動化信息系統 鑒定測評 分析

1概述

大型指揮自動化信息系統作為情報支持的主要裝備，具有以下特征：（1）信息處理數據量大，速度快。在指揮自動化系統中，各個分系統和數據處理組合之間采用了數字化的數據交換方式，并且最快的每幾秒甚至幾毫秒交換一次數據，每次達數百個字節，要求處理的數據量很大;（2）控制復雜性高，系統包括多個分系統及其組合或設備，有很多狀態量和數據量，并且其周期不盡相同，系統軟件要對它們進行統一管理，邏輯關系非常復雜;（3）實時性要求強，各個分系統和數據處理組合之間的數據交換周期是不同的，指控計算機按照統一的時序來協調分系統的工作，實現多個設備的同步。一旦在實時性方面出現錯誤，就會造成整個系統的失敗;（4）可靠性要求高，系統很小的失誤可能引起重大損失。所以，系統中指揮控制系統的仿真與測試是非常重要的，在飛行試驗前要對指揮自動化系統進行大量的測試和驗證工作。

針對本類軟件，目前已開展了不少的鑒定測評工作，從頂層的管理要求上與嵌入式軟件系統沒有區別。本文根據前期工程實踐情況，將指揮自動化信息系統軟件鑒定測評工作中的經驗、存在的問題和建議進行總結。

2軟件特點

大型指揮自動化信息系統軟件主要特點包括：（1）多為非嵌入式軟件，使用多任務操作系統、Oracle數據庫等基礎商用軟件，硬件設備也多采用商用服務器、工作站等，大型指揮自動化信息系統作為裝備，多以軟件系統的形式進行軟件鑒定;（2）規模巨大，一般在幾十萬甚至上百萬行，而對于如此巨大的軟件系統軟件的需求分析、設計文檔內容相對單一，對之前研制的項目進行過統計匯總，發現有的軟件需求文檔的描寫力度是平均每條軟件需求對應一萬行左右的程序;（3）系統職責分層、數據分布處理，往往將系統劃分為分系統、子系統以及配置項等，不同的配置項部署于支持層、傳輸層、應用層等，處于不同層次的配置項行使的職責不同，支持層、傳輸層等配置項的功能在系統中對用戶不可見，應用層配置項的功能需要經由支持層、傳輸層的功能協助完成;（4）體系結構構成的成分較復雜，有通用配置項/ 構件、系統共用配置項/ 構件等，這些配置項/ 構件的開發單位、技術狀態和主管研制部門不同，技術和管理性因素都很多，不完全受控于系統鑒定;（5）人機交互多，系統的可用性、易用性必須符合用戶的使用習慣和使用需要，受人員影響很大，是使用需求驅動的軟件系統。

3鑒定測評情況分析

3.1研制過程分析

過程控制：針對此類軟件系統，主管機關一直強調其為“永遠不交鑰匙的系統”，顧名思義，該系統無論是鑒定過程中，還是鑒定交付之后，需要研制單位永遠無條件的給予技術支持和維護。這種觀念本身是正確的，軟件裝備研制的目的是讓用戶用好裝備，滿足其使用需求是軟件裝備的最終目標。但是，有些研制單位卻因此產生誤解，認為軟件即使交給用戶隊也可以隨時更改，不用控制版本，導致研制過程不規范，同時給測評過程帶來了巨大的困難。

軟件重用：由于此類軟件系統功能需求多，程序規模大，因此研制單位在軟件需求分析和開發中，一般會選擇較為成熟的軟件構件或商用軟件進行重用集成，以期降低研制成本，提高軟件的可靠度，但會造成3 個問題。一是對重用的軟件/ 構件是否適用于本系統，調研不充分，集成后（有時到交付階段）發現此類問題但又難于更改;二是重用或購買的軟件/ 構件有缺陷無人維護;三是此類軟件/ 構件的問題在某個分系統中暴露和更改后，沒有同步更改到其他分系統。

內部測試情況參差不齊：研制階段過程中對軟件的內部測試不充分，有時僅在研制開始階段進行了測試，且測試僅做到大功能的覆蓋，后續軟件更改后未進行測試，許多問題留到了鑒定階段。

軟件的文檔質量一般不高，往往軟件功能和設計等技術內容高度概括。一是出于對本單位軟件知識產權的保護，擔心文檔寫得太細或涉及軟件算法會泄露單位的核心技術;二是受時間、進度的限制，軟件文檔跟不上軟件更新的速度，只能先更改軟件文檔在升級文檔，因此常出現文文不一致、文實不相符的情況[1] 。

3.2鑒定測評過程分析

時間因素與節奏：鑒定測試是軟件系統交付之前的重要質量保障環境之一，軟件測評質量和進度受到研制進度的影響。理論上進入設計鑒定階段的一個重要標志是軟件技術狀態固化，由于指揮自動化信息系統使用需求驅動和“不交鑰匙”的特點，技術狀態固化幾乎不可能。根據用戶需求軟件的功能、界面和操作流程處于一個始終變化的狀態，軟件的更改會包含測試中發現問題和用戶使用的要求，這就給鑒定測評工作帶來了巨大的挑戰和制約。

測試策略方面：由于指揮自動化系統往往由多個配置項組成，在有限的測試時間內如何突出重點提高測試質量是很重要的測試策略問題，如果按照對裝備軟件的測試策略，過分強調配置項測試的測試級別問題，會忽略本類系統的結構特點。針對系統中多數軟件配置項不能單獨運行實現系統功能的情況，對配置項之間組合能力的驗證不充分，容易造成“只見樹木不見森林”的問題。

測試環境方面：測試環境多是以系統集成聯試為目的開發的，難以支持軟件的有些接口測試、甚至部分軟件的功能測試，相應的測試用例只能通過代碼審查加以驗證。此外，指揮自動化信息系統測試環境難于與實裝環境完全一致，測評單位甚至研制單位都不能準確獲得網絡拓撲結構、電磁干擾情況等信息，受資金限制，研制單位也很難提供與實裝一致的高配置服務器等設備，只能按研制方和測試方現有條件和理解在盡可能最相似環境中進行測試。

文檔質量和人員配合方面：由于研制單位軟件需求過于粗放，對軟件測試的充分性依賴于軟件測試人員的溝通能力、系統理解能力和對背景的了解程度，同時依賴測試人員的責任心。

4過程改進建議

通過指揮自動化信息系統的鑒定測評工作，本文主要從測評的角度和對研制過程改進的引導方面提出以下建議。

4.1多層次、多途徑控制軟件的質量

（1）引導研制單位加強內部測試，加大內部測試的檢查/ 評審力度，內部測試以軟件單元和配置項測試為重點，測試功能、接口、邊界乃至性能等方面的正確性，盡可能暴露軟件問題，這部分工作在后期系統集成后不易暴露，帶來的影響和更改風險很大;提交評測時，應出具內部測試報告。

（2）建議主管機關適當調整鑒定測評與用戶試驗試用嚴格分開的程序，采用鑒定測評與用戶試驗試用迭代前進的工作方式。由于“軟件裝備”人機交互量大、使用需求驅動軟件需求、在用戶的使用中系統不斷成熟，而軟件鑒定測評解決軟件與研制總要求的符合性問題，用戶試用可解決“軟件裝備”可用性、易用性問題，因此建議在軟件鑒定測評后研制單位解決主要問題，即可提交用戶試驗試用，在用戶提出更改意見后，更改程序并進行回歸測試，如此幾輪，可將問題逐步收斂，最終滿足鑒定測評的要求，基本達到滿足用戶使用要求的目標[2] 。

4.2加強實驗驗證平臺和測試環境建設

對于“軟件裝備”，研制方在立項研制之初就應該充分考慮試驗驗證平臺和測試環境的搭建，將之作為研制工作的一部分，并應該充分考慮經費投入。系統級測評環境構建應借助一定的實物設備，構建的半實物的系統級測試環境，對于指揮信息化裝備，也可構建全數字的系統級測試環境。構建的環境應苛刻或等效于實際使用環境，能夠支持系統邊界外異常數據的輸入能力，能夠模擬軟件運行極限狀態的外部環境條件，支撐全過程的軟件配置項之間交互數據的采集和重演。如圖1 所示，對于被測系統而言，構建系統測試的關鍵是外圍環境的模擬，如果外圍環境能以軟件模擬的方式實現的，盡量以運行軟件的方式實現;對于外圍實物難以直接模擬的，可以增加一層實物設備[3]。

4.3重視系統級測試，加大系統級測試和功能組合測試力度

鑒定測評工作應重點進行系統級測試，嚴格驗證“軟件裝備”對研制總要求的任務使命和任務功能等使用要求的滿足程度。其中，系統級測試是指將子系統、分系統乃至系統均作為獨立運行保障用戶使用的系統進行完整、全面的測試。經歷了軟件內部測試（單元測試、部件測試、配置項測試、系統聯試）、第三方評測，系統裝備是否還需要開展系統級測試？ 答案是肯定的，因為這些測試都不能替代系統級測試工作。據不完全統計，軟件質量問題中系統級問題占20%以上。事實上，一方面，系統級測試是對配置項測試的補充，可以發現配置項測試中遺漏的問題，另一方面，系統級測試可以發現配置項之間工作不協調的問題，是軟件測試中不可或缺的一部分。

4.4注重測試策略的實效性

由于“軟件裝備”規模巨大，進行全面的代碼審查不太現實，即使進行10%的代碼審查也要審查幾萬行或十幾萬行（不包括被審查范圍相關的程序量），審查規模過于龐大，帶來的開銷和時間周期對于鑒定工作均可能難以承受，因此建議不以代碼審查比例評價測試，關注代碼審查范圍的選擇原則和理由是否合理、充分。

“軟件裝備”需求復雜，制約功能的進入和狀態轉移的因素很多，有些和具體設備情況、用戶使用習慣等有關，需要通過數據庫或配置文件加以約束;軟件運行流程復雜，有些功能軟件運行路徑長，多個子系統或配置項配合才能完成一個測試用例，對整個系統來講可用較少的測試用例對軟件做較充分的驗證，有些功能軟件運行路徑短則需要大量的測試用例來覆蓋，因此每百行測試用例的個數不是衡量測試的唯一標準，應具體情況具體分析。

4.5重視用戶需求，加強需求管理

用戶需求驅動的模式決定了“軟件裝備”需求變化大的特點，建議加強需求評審和需求變更控制，尤其是在設計定型過程中嚴格控制需求變更，對需求改動量、變化內容進行分析;測試需求應根據軟件需求的變更及時更新，分析需求變更對已有需求的影響，及時調整測試內容;加強需求評審，一項需求改動應將與該需求相關的總體人員、軟件設計師、測試人員聚到一起，對需求進行評審并提交詳盡的軟件更改單，詳細描述更改原因、更改內容及影響域分析、驗證措施。

4.6嚴格控制重用/ 外購軟件質量

針對“軟件裝備”構成系統的成分較復雜的特點，建議研制單位在系統研制伊始應確保共用軟件配置項的質量，選擇已通過鑒定測評的成熟軟件，或安排專門的鑒定測評，共用軟件的質量風險應在鑒定測評開展之前排除，鑒定測評開展時研制主管部門和定辦協商明確鑒定測評的范圍，規定非測評范圍的軟件的使用原則和發現問題的處理方法和通報途徑;對于多個系統或子系統共用的構件/ 軟件，應嚴格配置管理和配管檢查機制，避免造成型號內版本不一致的情況。在嚴格配置管理的前提下，可在某個子系統中對共用的構件/ 軟件進行全面測試，其他子系統直接采信結果[4] 。

5結束語

軟件測試在保障軟件質量方面起發揮著重要作用，通過軟件測試發現并彌補的軟件缺陷非常多。在鑒定評測中若能從管理要求、測試技術、測試流程、測試策略等方面進行不斷改進與完善，必能更好保證鑒定測評的質量，從而為指揮自動化軟件質量提供更大保障。