来源：北京航空航天大学虚拟现实技术与系统国家重点实验室

    基于HLA的分布式虚拟仿真，是利用RTI将不同的局部虚拟仿真环境通过空间关联以构造大范围的虚拟仿真环境支持在不同地域的用户同时进入虚拟仿真环境并与之交互。目前，国内外一些RTI软件已经经过完整的测试成为仿真联盟开发的平台，国外有DMSO的RTI系列、Pitch公司的pRTI、MAK公司的MAK RTI，国内有国防科技大学的KD-RTI、StarLink以及北京航空航天大学的BH RTI等。

    目前现有的RTI的测试方法从思想上来说是一致的，即要全面覆盖标准规定的接口及异常。在接口规范的测试顺序与测试模型建立上，Margaret L. Loper把其分为两个阶段。如图1.1所示，在确保每个盟员SOM正确性的前提下，第一个阶段要进行软件的兼容性测试（Compliance Testing），主要工作是明确通用的HLA框架，特别是仿真系统所依赖的功能性元素、接口、设计规则是否能够满足数据交换的需求。第二个阶段被称为联盟测试（Federation Testing），主要是针对仿真能力进行的测试，即测试能否正确的理解数据并参与到联盟运行中来。

    在测试用例的组织上，DMSO发布了基于MSC（Message Sequence Chart）的组织方式。如图1.2所示，OR表示子序列之间是任选其一执行的，PARALLEL表示子序列之间是并行执行关系，而AND则表示子序列之间存在顺序依赖关系，必须按照图中所表示的先后关系执行。

    在基于HLA的仿真程序中，有些服务是必不可少的，如联盟管理服务等。特别是联盟管理服务中的创建、加入联盟等接口更是仿真活动所必需的。而有些服务，如时间管理、所有权管理、数据分发管理等服务在一次仿真中却不一定用到。因此在一致性测试中，盟员所执行的测试序列中必须包括该RTI声明能够支持的所有接口。该测试序列首先是基于接口之间依赖关系的一个主测试序列，然后根据接口的服务类型进一步有层次地组织。那些必不可少的接口在测试的主测试序列图中应当以AND方式组织，作为其它接口执行的前件，而那些互相没有依赖关系和互相为选择关系的接口就应分别以PARALLEL和OR的方式进行。图1.3是DMSO给出的以MSC形式表示的主测试序列，而其中呈并行关系的六大模块又由一系列子序列组成。

    从RTI测试者的角度出发，RTI功能测试过程为：首先，根据HLA标准，为RTI的每组服务设计一系列的测试流程和测试案例；然后编码进行测试，并对测试结果进行分析；最后根据测试结果来完善和验证RTI的服务功能。具体需要测试HLA定义的六组服务：联邦管理、声明管理、对象管理、所有权管理、时间管理和数据分发管理。目前DMSO提供的功能测试是基于“框架”结构的测试思想，使用一个通用的测试程序来测试接口功能，支持任意的数据交互文件，支持任意多的测试盟员，支持任意的RTI服务的调动序列。在实现测试时，采用菜单界面，将所有的RTI服务都包含在菜单响应函数中，测试时依次对每个接口服务功能进行测试。虽然在一定程度上缓解了人手工编写测试程序的麻烦，但是需要执行人工点击菜单、输入参数等操作，依然重复地测试每个接口功能，带来重复工作量。

    RTI性能测试主要是为了确保整个仿真系统开发的有效实施。在一定的测试配置条件下，在基本的网络测试的基础上，对于各种性能指标以及各种条件重复测试。性能测试的指标主要是时间延迟测试，吞吐量测试，消息丢失率测试。目前对RTI的性能测试都是通过编写测试程序的方法进行性能测试，测试数据以文本文件的方式输出，再通过观察、分析和计算得出最后的结果和对比的图表。但是RTI的开发是不断改进的过程，就需要一个完善，测试，再完善的过程，手动的测试和数据处理使得效率降低，有时会带来不必要的错误。

    现在RTI的规模测试主要是通过在广域网和局域网多台机器的配合，启动规模测试程序，不断的进行属性更新和发送交互来观察RTI运行的情况，而主要面对的就是多机控制和协同的问题，也会消耗大量的人力。

    综上，对RTI功能测试，由于DMSO HLA标准接口数目多，并且需要进行大量的重复测试，使得工作量冗余且繁琐，也会存在遗漏或错误造成不必要的复查和重新测试。RTI性能测试，手动测试对于单机多盟员测试时上述问题不明显，但对于多机多盟员测试时，不仅要在各主机上运行RTI软件和测试程序，还要有发送测试成员和接受测试成员，并且使得数据整理简便。规模测试时，对于多机的控制和协同的问题更加明显。