导航接收机数据处理软件可测性设计与实现＊

靖守让，向 为，雍少为

（国防科技大学电子科学与工程学院 卫星导航定位研发中心，湖南 长沙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.