導航接收機數據處理軟件可測性設計與實現＊

靖守讓，向 為，雍少為

（國防科技大學電子科學與工程學院 衛星導航定位研發中心，湖南 長沙410073）

0 引 言

導航接收機是用于接收、處理、解碼星基導航信號的應用終端，它為用戶提供全天候的實時導航、測距、測速等功能，在車載、艦載、機載、彈載高動態應用、弱信號檢測、強干擾抑制等軍事和民用導航通信領域發揮著重要作用[1－2]。隨著我國導航定位技術的發展，接收機種類不斷增多，且功能日趨復雜，相應的導航接收機數據處理軟件（以下簡稱接收機軟件）的規模和復雜度也隨之增加。測試問題日益凸顯，提高測試效率越來越重要，軟件可測性設計是提高軟件測試效率的關鍵手段。

軟件測試是查找軟件設計錯誤、運行故障的重要手段，為保證軟件質量，就必須保證軟件測試的覆蓋率和有效性，提高測試效率。為提高軟件測試的效率，可以采取以下兩種手段，一是選擇有非常強的故障揭示能力的測試用例來進行測試；另一種方法是軟件進行初期規劃和設計是，采用可測性設計方法，提高軟件可測性，為后期測試提供便捷的條件[4]。顯然后一種方法更加可行、有效。

國內外一些學者對軟件可測性進行了深入研究[3－8]。軟件可測性是軟件在特定的輸入分布下進行隨機黑盒測試時暴露故障的能力，是軟件固有的品質特性[5]，是在一定時間和成本的前提下，進行測試設計、測試執行并以此發現故障、定位故障并隔離故障的能力特性。簡而言之，軟件可測性就是一個程序能夠被測試的容易程度。軟件的可測性特征一般包括可操作性、可觀察性、可控制性、可分解性、簡單性、穩定性、易理解性等。軟件可測性設計也體現了軟件測試的一個發展趨勢：軟件測試向軟件開發前期發展，逐漸擴展到整個軟件生命周期的各個階段。結合軟件接收機軟件的特點，探討軟件可測性設計問題，提出接收機軟件可測性的幾種具體的設計方法。

1 可測性方法設計

一般來說，軟件生命周期包括可行性分析與項目開發計劃、需求分析、設計、編碼、測試、維護幾個階段，設計階段又可以根據層次劃分為結構設計階段、模塊設計階段以及單元設計階段。但各個階段并不是完全獨立的，在需求分析、設計階段都要考慮到軟件的可測性設計，以便于軟件測試。以接收機軟件為例，在需求分析階段，軟件可測性需求分析作為軟件需求分析的一項重要內容加以分析、討論，提出軟件可測性設計規劃，以及不同階段實現軟件可測性的實現方法；在結構設計階段，通過建立多層次的軟件體系結構來提高可測性；在模塊設計階段，每個功能模塊對應到不同的任務實現，降低任務之間耦合程度，以降低測試復雜度；在單元測試階段，可以為每個單元設計內嵌的狀態輸出，測試時可以根據狀態輸出判斷程序的邏輯和運行結果。另外，在每個功能模塊和單元模塊中內置任務調度記錄，形成任務調度流程，可在測試時觀察軟件運行狀況；一般接收機軟件應用于嵌入式系統，嵌入式系統大多存在調試測試困難的問題，可將代碼分類處理，創建軟件測試平臺，將與硬件無關或關聯很小代碼在軟件測試平臺測試通過后再移植到硬件平臺。

1.1 可測試體系結構

接收機軟件體系結構設計時接收機軟件設計的第一步，并為以后的設計和實施提供指導、控制、管理的依據。通過建立層次分明、便于測試的體系結構將極大的提高接收機軟件的可測性。本文中將接收機軟件體系結構設計為分層結構和管道過濾器結構想結合的模式，如圖1、圖2所示。

接收機軟件體系結構分為三層：系統軟件層，數據處理層和用戶應用層。每一層又可以細化為多個層，不同種類接收機的嵌入的硬件平臺、操作系統各不相同，可以在系統軟件操作系統層通過修改BSP文件來解決；接口的不同可以通過在系統軟件的端口驅動層增刪驅動程序來解決；數據處理層主要功能是接收前端電文、偽距等數據信息，進行信息處理，解算出用戶位置、速度信息并傳輸至用戶應用層；用戶應用層可以根據用戶需求增刪定位顯示、用戶導航、坐標轉換等功能。這樣，需求變化引起的改動僅僅是模塊的增加和刪除，并可限制在一個層內，不影響其他層。

信息處理作為接收機軟件最重要的一部分，可以用管道過濾器模型來構造，包括協議轉換過濾器、電文解析過濾器、衛星PVT解算過濾器、數據預處理過濾器、導航定位解算過濾器。協議轉換過濾器根據接口數據通信協議設計，將數據格式轉換為所需數據格式；電文解析過濾器主要通過對數據的比特操作得到衛星星歷、歷書等參數；衛星PVT解算過濾器通過衛星星歷參數計算衛星位置；數據預處理過濾器主要包括電離層修正、對流程修正等預處理操作；導航定位解算過濾器通過衛星位置、衛星速度、衛星觀測偽距等信息解算出用戶位置、速度信息。具體實現整個過程可以構建一個結構體作為過各濾器數據的輸入、輸出，統一輸入輸出數據流結構，如此一來，各功能過濾器結構一致，可形成公用模板，如圖3，所不同的僅為對結構體數據流的具體操作不同。因此，信息處理層各模塊測試也可以形成公用測試模板，提高模塊測試效率，同時，管道過濾器模型具有低耦合、高內聚的特點便于軟件功能模塊進行單元測試；管道過濾器模型接口清晰，便于測試時接口故障的排查。

圖3 管道過濾器模板結構

將分層模型和管道過濾器模型相結合應用于接收機軟件體系結構，結構清晰，并可將接收機軟件劃分為不同層次、不同功能的模塊，降低模塊間耦合，便于接收機軟件的具體實現，也便于軟件軟件測試時發現問題、定位問題，提高了接收機軟件的可測性。

1.2 軟件運行環境模擬

接收機軟件一般應用于嵌入式平臺，而軟件在嵌入式平臺上測試比較困難，難以做到測試的可操作性、可觀察性、可控制性、可分解性。而接收機軟件體系結構設計以分層結構和管道過濾器相結合，層次分明，可以在計算機上搭建軟件測試平臺，將與硬件無關聯或是關聯很小的功能模塊放到軟件平臺測試，待測試無誤后再移植到硬件平臺。這樣不僅可以較容易的實現軟件測試的可操作性、可觀察性、可控制性、可分解性等特征，大大提高了軟件測試效率。

在接收機軟件中，信息處理模塊與硬件平臺基本沒有關聯，可以搭建一個軟件測試平臺，測試信息處理模塊中的各項功能和整體功能。信息處理模塊的主要功能是通過數據通信層從前端得到衛星電文、偽距信息等數據，通過一系列數據處理解算得到用戶位置、速度信息。因此，可以將電文和偽距信息保存至文件，通過數據回放的方式測試信息處理模塊，實現信息處理功能集成測試，還可對信息處理功能下屬功能模塊、函數進行單元測試。信息處理軟件測試平臺主界面如圖4。

圖4 信息處理軟件測試平臺主界面

在信息處理軟件運行環境模擬平臺上可以簡單方便的添加、運行測試代碼，實現了測試的可操作性和可控制性；通過調試信息窗口和顯示控件可以方便的觀察軟件運行狀態和結果，實現了測試的可觀察性；實現對信息處理功能的集成測試，還可對信息處理功能下屬功能模塊、函數進行單元測試，實現了測試的可分解性。

1.3 狀態序列編碼和消息日志

接收機軟件功能較復雜，任務運行狀態很多，集成測試時難以觀察各個任務運行狀態結果，出現故障難于定位。為了提高軟件可測性，便于觀察任務運行狀態以及便于發現問題、解決問題，在進行接收機軟件功能具體設計時，可以在每個任務執行結束時產生一個全局狀態碼，由狀態輸出口輸出。然后對各功能對應輸出的全局狀態碼進行編碼，由此形成狀態序列編碼，根據全局狀態序列就可以清晰的了解功能模塊運行的狀態。接收機軟件狀態序列編碼實現如圖5。

對每個功能模塊分配一段編碼段，新增模塊和函數在未使用的編碼段進行分配，便于接收機軟件功能模塊增刪。全局狀態碼序列不僅要記錄任務運行失敗情況，還要記錄任務成功情況，以便于確認任務執行情況，另外還可以形成狀態序列標準模板，將生成的狀態序列與標準模板相比對，可以清晰、快速的了解各功能模塊運行狀況。在集成測試階段，通過全局狀態碼序列便于故障定位，提高測試效率。

圖5 狀態序列編碼

通過狀態碼序列可以觀察、了解功能模塊的運行狀況，但無法觀察功能模塊以及整個軟件的流程和執行情況，這些問題可以通過添加消息日志，形成任務調度流程加以解決。具體做法是建立消息日志文件，在功能模塊、函數開始和結尾都添加相應的消息信息，如在函數開始添加“FunctionName＋＋”（FunctionName為函數實際函數名）、函數結束添加“FunctionName－”消息，當函數運行時，將消息存儲到消息日志中。通過消息日志中記錄的消息順序，梳理函數、功能模塊運行順序和包含關系，很容易形成任務調度流程圖。如此一來，就可以清晰的觀察、了解軟件運行流程和任務調度情況，且便于相關人員對整個軟件系統框架、流程的理解。

狀態序列編碼和消息日志作為通用性較強的軟件可測性設計方法運用于接收機軟件的具體實現中，極大的提高了接收機軟件測試的可觀察性和可理解性，便于軟件測試中故障的排查定位。

2 結 論

接收機軟件功能復雜、規模大，軟件質量和可靠性要求很高，需要提高軟件測試的效果和效率，因此軟件可測性設計顯得尤為重要。提出針對接收機軟件可測性設計的幾種方法，包括可測性體系結構設計、軟件運行環境模擬、狀態序列編碼和消息日志，并分別對這幾種方法進行了詳細的說明。上述方法，不僅適用于接收機軟件可測性設計，對其他軟件可測性設計也具有一定通用性。

[1]李 躍，邱致和.導航與定位[M].2版.北京：國防工業出版社，2008.

[2]James Bao－Yen T.Fundamentals of global positio－ning system receiver：A software approach [M].John Wiley＆Sons，2000.

[3]Yves L T，Chantal R.From hardware to software testability [C]／／ International Test Conference，Washangton，DC，VAS，1995：710－719.

[4]Jeffrey M V.Keith W M.Software testability：the new verification[J].IEEE Software.1995，12（3）：17－28.

[5]Jeffrey M V，Keith W M.Predicting where faults can hide from testing [J].IEEE Software，1991，8（2）：41－48.

[6]Fu Jiang ping，Liu Bin，Lu Min－yan.Present and future of software testability analysis[J]／／2010International Conference on Computer Application and System Modeling（OCCASM 2010），Taiyuan Shanxi，2010：279－284.

[7]Anthony L A，Nathan M，Richard J P，et al.A lean approach to designing for software testability [J].IEEE，2009.

[8]Tsai W T，Gao J，Wei Xiao，et al.Testability of software in service－oriented architecture[C]／／Proceedings of the 30thannual international computer software and application conference（COMPSAC’06），Chicago，IC，2006.