伺服軟件開發(fā)方測試技術(shù)的應用

丁懷龍 劉海山 樊茜 焦震 宋茜

摘 要隨著航天事業(yè)的快速發(fā)展，嵌入式軟件的應用越來越廣泛，同時也面臨著開發(fā)質(zhì)量低下、低層次問題頻出等急待解決的問題，如何確保其質(zhì)量成為迫切需要解決的問題。本文在深入分析當前嵌入式軟件特點及測試現(xiàn)狀的基礎上，結(jié)合多年的軟件測試經(jīng)驗，對軟件開發(fā)方測試技術(shù)進行了深入的研究并取得了較好的應用成果，對于提高航天軟件測試水平具有較高的參考價值。

【關鍵詞】DSP 嵌入式軟件 開發(fā)方測試

隨著航天型號的不斷發(fā)展，軟件的重要性越發(fā)突出，已經(jīng)成為航天工程中的重要組成部分，成為我國躋身航天強國的關鍵因素，如何確保航天軟件質(zhì)量是軟件研制過程中的一項艱巨而緊迫的任務，因此必須要對其進行嚴格的測試。

軟件測試是軟件工程中的重要環(huán)節(jié)，是提高軟件質(zhì)量，降低軟件項目風險的有效手段之一，為了降低軟件在研制過程中的風險，提高代碼質(zhì)量，在軟件投入運行之前，如何有效的開展軟件開發(fā)方測試是當前研究的熱點，因此一套行之有效的開發(fā)方測試技術(shù)能夠有效提升測試效率，提高軟件的可靠性、健壯程度，從而降低軟件缺陷，提高軟件質(zhì)量。

1 伺服軟件概述和開發(fā)方測試現(xiàn)狀

1.1 嵌入式伺服軟件特點

嵌入式伺服軟件實時性越來越強，復雜度越來越高，軟件分布在不同的硬件平臺下，代碼量越來越大，軟件本身是伺服系統(tǒng)的一個核心部分，一個微小錯誤都可能影響伺服系統(tǒng)正常運行。

1.2 開發(fā)方測試現(xiàn)狀分析

靜態(tài)分析主要采用人工測試的方式，測試工具閑置一旁，不能被充分利用，單一的分析工具不能夠檢測所有缺陷問題；代碼走查只注重代碼審查，忽視文檔的正確性，導致需求與代碼設計過程反復；

單元測試過程未缺少信息化管理手段，不能對測試問題進行統(tǒng)計、分析和處理，造成測試寶貴資源的嚴重浪費，不能對測試用例進行有效管理，自動化程度較低，導致測試工作重復，測試效率低下；配置項測試過程中未能搭建真實測試環(huán)境，測試的有效性覆蓋不全面，測試的創(chuàng)新性發(fā)展不迅速；軟件測試相關標準不健全，體系建設不完善；軟件測試人員水平參差不齊，測試過程缺少專業(yè)指導書；

2 開發(fā)方測試策略

2.1 靜態(tài)分析

依據(jù)嵌入式伺服軟件特點，對GJB5369規(guī)則集進行了適應性修改，形成了伺服軟件規(guī)則集，多個測試工具交叉使用，主要包括：Testbed、Klocwork10、QAC/QAC++，測試內(nèi)容更全面，涵蓋了代碼的規(guī)則檢查、質(zhì)量度量、缺陷檢測、內(nèi)存分析、安全檢查。

2.2 代碼走查

代碼走查實施過程主要包括：

2.2.1 策劃階段

策劃過程在靜態(tài)分析之后，保障代碼中無設計規(guī)則問題，確保代碼及設計文檔來源于受控庫且軟件無編譯錯誤問題，成立代碼走查小組，組長1人，走查專家5人及以上。

2.2.2 代碼走查

根據(jù)走查專家所在領域及專業(yè)為每個人分配不同的任務，對相應的模塊和文檔進行走查，不但要檢查軟件設計本身的缺陷還要檢查任務書與需求的一致性、需求與軟件的一致性、軟件與設計說明的一致性。

2.2.3 會議討論

對走查出的代碼和文檔問題在會上進行討論，完善軟件和文檔的設計工作。

2.2.4 生成報告

按照體系文件要求將發(fā)現(xiàn)的問題形成報告，并進行受控，對報告中的問題進行復查，真正實現(xiàn)閉環(huán)管理。

2.3 單元測試

針對嵌入式伺服軟件代碼量大、相似度高的特點，設計并實現(xiàn)單元測試用例的自動化生成及管理系統(tǒng)，使得單元測試的自動化程度顯著提高、測試用例全面、規(guī)范，不僅提高了單元測試效率和測試質(zhì)量，同時也提高了對測試用例的復用率，節(jié)省人力成本，系統(tǒng)結(jié)構(gòu)圖如圖1所示。

2.4 配置項測試

根據(jù)硬件產(chǎn)品特點和現(xiàn)有條件搭建測試平臺，目前主要為半實物仿真測試平臺；配置項測試采取動靜態(tài)結(jié)合的方式，測試人員除了進行功能、性能、接口等的測試，還要進行靜態(tài)分析、代碼審查、覆蓋率、強度測試等；提交的被測件必須是經(jīng)過前一級測試修改后的版本，且出自受控庫。

測試過程除基本的測試技術(shù)及方法外我們還運用了自己的創(chuàng)新技術(shù)：

2.4.1 雙冗余總線虛擬測試技術(shù)

使用虛擬仿真測試軟件模擬真實總線上的數(shù)據(jù)傳輸，實現(xiàn)各種指令的輸入、故障的注入、遙測數(shù)據(jù)的接收和顯示、狀態(tài)信息的查詢、參數(shù)的下載等。

2.4.2 故障模擬注入技術(shù)

利用需求所要求的基本數(shù)據(jù)類型和數(shù)據(jù)值進行測試，以測試軟件在正常條件下的能力，還重點對軟件的安全性、可靠性進行測試，防止因軟件的容錯機制、邊界和異常數(shù)據(jù)處理的不完善造成系統(tǒng)崩潰，主要包括軟件故障注入、硬件故障注入，數(shù)據(jù)故障注入，操作故障注入。

半實物仿真測試環(huán)境如圖2所示。

2.5 制定專業(yè)軟件測試標準

統(tǒng)一的標準規(guī)范是確保軟件測試工作正規(guī)、有序、有效開展的根木保證。針對當前軟件的特點，制定切實、有效的標準，包括：體系標準建設、軟件測試的相關標準、軟件測試專業(yè)指導書等，來指導、規(guī)范、約束測試人員開展工作，才能保證各類復雜軟件測試的正確性和充分性，同時改進軟件驗證流程，有效提高軟件測試的質(zhì)量，具體的驗證流程如圖3所示。

3 結(jié)果分析

在開展開發(fā)方測試的初期由于軟件數(shù)量較少、測試能力較低，發(fā)現(xiàn)的問題數(shù)量相對較少，到2013年軟件任務數(shù)量急劇增加，軟件測試能力有所提高，發(fā)現(xiàn)的問題數(shù)量也明顯增多，經(jīng)過最近幾年的努力，軟件問題數(shù)量呈下降趨勢，軟件質(zhì)量明顯提升，應用效果顯著，具體數(shù)據(jù)如圖4所示。

對幾年來所有被測軟件的各類型測試的測試BUG數(shù)量進行統(tǒng)計，可以看出軟件代碼走查發(fā)現(xiàn)的問題最多，經(jīng)過代碼走查和單元測試后，在配置項測試時發(fā)現(xiàn)的相對較少，由此也可看出，代碼走查環(huán)節(jié)非常有效、非常重要，應高度重視，參考數(shù)據(jù)如圖5所示。

4 結(jié)束語

本文對航天伺服軟件開發(fā)方測試技術(shù)進行了全面、深入研究，總結(jié)出了一套有效的測試流程和思路，有利于提高軟件研制進度和伺服軟件設計質(zhì)量，有效減少了航天伺服軟件在測試過程中的錯誤遺漏，對伺服軟件非常適用，未出現(xiàn)外場質(zhì)量問題。軟件開發(fā)方測試也需要不斷改進和日趨完善，因此，必須盡快改進和完善嵌入式軟件測試體系建設和測試流程管理，加強軟件測試人員隊伍的建設，加大先進軟件測試技術(shù)和工具的應用，有效提高軟件測試的技術(shù)能力和管理水平，只有掌握了正確的測試流程和測試方法，才能達到事半功倍的效果。

參考文獻

[1]周濤.航天型號軟件測試[M].宇航出版社，1999.

[2]李霽.軟件測試行業(yè)發(fā)展對策研究[J].軟件導刊，2010，9（03）：35-37.

[3]朱少民.全程軟件測試[M].北京：電子工業(yè)出版社，2007.

作者簡介

丁懷龍（1979-），男，碩士學位。計算機應用技術(shù)專業(yè)，工程師，主要從事軟件測試方面的研究。

作者單位

北京精密機電控制設備研究所 北京市 100076