接口测试精品(七篇)

序论：写作是一种深度的自我表达。它要求我们深入探索自己的思想和情感，挖掘那些隐藏在内心深处的真相，好投稿为您带来了七篇接口测试范文，愿它们成为您写作过程中的灵感催化剂，助力您的创作。

篇(1)

关键词： 模型检验；接口变异；切片技术；功能依赖图

中图分类号：TP311 文献标识码：A 文章编号：1009-3044（2015）02-0211-04

Abstract：Motivated by compressing the model of component through slicing technique， this paper employs the interactive relationship of the components. Then it proposes a method of constructing a function dependence graph for component system， which is made of a test driver node and some extended component nodes. Finally， by an example， it demonstrates that this method could not only decrease the size of the state space and increase the efficiency for testing generation， but also guarantee the comprehension and the validity of the interface testing for JavaBean components while applying the method of interface mutation testing based on model checking.

Key words： model checking； interface mutation； slicing technique； function dependence graph

模型检验技术作为一种形式化验证方法，以其自动化程度高的特点已经广泛应用于计算机硬件、通信协议的分析与验证等许多领域，它通过穷尽地搜索有限状态系统的状态空间，从而判定系统（模型）的每一个状态是否满足给定的性质，并且总会以“是”或“否”为结果而终止[1]。目前，利用模型检验技术进行测试用例生成的研究也十分活跃，并且也取得了一定的研究成果[2]。同时，随着程序模型检验工具的诞生，一些将变异测试方法与程序模型检验工具相结合并生成测试用例的研究工作也得到了一定进展[3]。

尽管模型检验技术在自动化方面具有许多优点，但它是采用穷尽搜索系统空间的方法对所给定的性质进行验证，因此，对并发系统而言，其状态数往往随并发分量的增加呈指数增长，这样就产生了“状态空间爆炸”（state-explosion）问题[1]。对于基于模型检验的变异测试来说，当对非等价变异体采用“搜索所有的反例路径”的策略进行验证，以及对等价变异体进行验证时，都必须通过搜索整个系统的状态空间才能够进行判定，所以这样就影响了模型检验的验证效率。

因此，为了压缩系统状态空间的数量，本文将通过建立构件系统的功能依赖图，然后运用切片技术[4]对其进行切片。最后，本文将以Java PathFinder作为模型检验工具，采用基于模型检验技术的接口变异测试方法[5]对JavaBean构件进行接口变异测试，并对所切片效果进行验证。图1给出了该方法的测试用例生成框架。

1 构件系统的功能依赖图

S.Horwitz等人通过引入系统依赖图（System Dependence Graph，SDG）的概念表示了具有多个过程的程序依赖图[6]，但是使用该方法就必须知道每一个过程内部的具体细节信息，因此这种方法并不适用于在源码未知情况下的构件化软件切片；虽然文献[7]提出了一种能够对由构件所组成的系统进行切片的方法，但是这种方法却只考虑了构件之间接口的交互关系而忽略了构件在系统中的状态。因此，本文以文献[8]所提出的构件之间接口的交互关系为基础，在细化了构件之间的接互图后，使其能够在清晰描述源码未知情况下被测试构件的状态和接口函数之间的关系的同时，也能够使切片技术适用于对被测试构件系统的接口调用关系模型的状态空间的压缩。

1.1 功能依赖图的组成

本文以该被测试构件的接口规约说明为依据，通过测试驱动程序对被测试构件，或者是将该被测试构件和与之相关的构件关联后进行建模，从而建立被测试构件的接口调用关系模型。通过这个构件系统的接口调用关系模型，被测试构件所具备的相关功能会在利用模型检验技术进行验证的过程中表现出来。因此，将细化后的构件之间的接互关系称之为构件系统的功能依赖图（Function Dependence Graph，FDG），并且该图是由测试驱动节点（Test Driver Node）和构件节点（Component Node）两种类型的节点所组成。

测试驱动节点是由被测试构件的测试驱动程序所虚拟出来的一个节点，它是整个构件系统的主体框架。从切片技术的观点来分析，该节点实际上就是它所代表的测试驱动程序的过程依赖图[3]（Process Dependence Graph）。

构件节点实际上在代表被测试构件的同时，也可以代表与被测试构件相关联的构件。为了能够应用切片技术对其进行切片，需要通过添加一些辅助接点对构件节点及辅助边对其进行细化。这里通过定义一个五元组C = 来描述一个构件节点，具体如图2所示。

1） 构造函数辅助节点（Construction Assistant Node）的集合Con

对于JavaBean构件来说，为了体现面向对象的特征，在构件节点中应该添加与之相关的所有构造函数的构造函数辅助节点（Conk表示构件中第k个构造函数）。辅助节点实际上就是该构件的入口节点。

2） 状态辅助节点（State Assistant Node）的集合S

由于在代码未知情况下的构件接口测试是一种黑盒测试，因此，还必须在构件节点中添加表示构件状态的状态辅助节点（Si表示构件中第i个状态）。

3） 接口函数辅助节点（Interface Function Assistant Node）的集合I

在构件节点中添加表示该构件所包含的所有接口函数的接口函数辅助节点（Im表示构件中第m个接口函数）。

4） 输入参数辅助节点（Input Parameter Assistant Node）的集合p

对于每一个包含输入参数的接口函数应该在其所对应的接口函数辅助节点中添加表示该接口函数中所有参数的输入参数辅助节点（pn表示该接口函数中的第n个参数）。

5） 辅助节点之间辅助边（Assistant Edge）的集合E

为了能够体现出上述辅助节点之间的内在关系并使切片技术能够适用于构件节点，还必须根据构件的规约说明在辅助接点之间添加相应的边。首先，由于通过构造函数在实例化一个构件的时候，与该构件相关的状态和接口调用函数也会被创建，因此，就必须在构造函数辅助节点和状态辅助节点以及构造函数辅助节点和接口函数辅助节点之间添加一条控制依赖边；其次，根据构件的接口规约说明，应该在具有控制依赖关系的接口函数之间添加能够代表它们之间控制依赖关系的控制依赖边；最后，由于构件相关的状态信息是通过与之相关的构件接口函数进行改变的，所以需要在接口函数辅助节点和状态辅助节点之间添加一条控制依赖边，同时，构件的状态信息也需要通过接口函数向外界进行表现，因此，还应该在状态辅助节点和与之相关接口函数辅助节点之间添加一条数据依赖边。综上所述，构件节点之间辅助边的集合E是控制依赖边Ec和数据依赖边Ed的并集，即：E = Ec U Ed。

1.2 功能依赖图的建立及其切片

在明确了构件系统的功能依赖图的组成后，就应该根据测试驱动程序将测试驱动节点和构件节点进行关联，从而建立整个构件系统的功能依赖图，它主要包括建立测试驱动程序的过程依赖图和确立该过程依赖图与构件节点之间关联关系两个主要步骤。

文献[9]给出了建立测试驱动程序过程依赖图的具体方法和步骤，故本文在此不作熬述。

本文的研究重点在于对构件的接口进行测试，因此，对被测试构件系统的功能依赖图的建立主要就体现在确立测试驱动程序的过程依赖图和构件节点之间的关系之上，这些关系主要包括了如下四个方面：

1） 测试驱动程序对构件的实例化

在测试驱动程序中需要通过构造函数对JavaBean构件进行实例化。这样，就必须添加一条描述测试驱动程序对构件进行实例化的控制依赖边。

2） 测试驱动程序对构件中接口函数的调用

对构件中接口函数的每一次调用，需要添加一条描述测试驱动程序对接口函数进行调用的接口函数调用边。

3） 测试驱动程序对构件中接口函数的参数输入

对于拥有输入参数的接口函数来说，测试驱动程序在对其进行调用时，对于每一个输入参数都需要添加一条描述测试驱动程序在对其进行调用时的参数输入边。

4） 构件中接口函数对测试驱动程序的响应

对接口函数的调用实际上相当于对构件中相关功能进行了一次使用，因此，构件就必须向外界产生这个调用的一个响应，这样，就必须添加一条描述构件中接口函数响应的边。

本文以三角形问题的JavaBean构件为例进行研究，表1给出了三角形问题构件中的接口函数及接口函数所对应的状态。

在依据三角形问题构件的接口规约说明建立测试驱动程序后，图3给出了其构件系统的功能依赖图。图中右侧部分是测试驱动程序节点，它是由被测试构件的测试驱动程序所建立的过程依赖图组成的[5]；图中左侧部分是三角形问题构件的构件节点，该节点中的S1、S2和S3分别代表了构件中的三个状态：bTriangle、 bRight和tType。由于三个接口函数的输入参数都是三个整形变量，因此，为了便于观察，在具体作图的过程中将输入参数a、b、c三个节点视为一个节点。

建立构件系统的功能依赖图后，就可以运用切片技术对其进行切片。在基于模型检验技术的变异测试方法的测试用例的生成过程中，是通过引入断言违背机制将原有模型和变异模型结合并对构件的状态进行判定从而诱发错误生成并得到反例路径。因此，为了能够找到导致这个断言违背所产生错误的原因，就必须找到在这个断言违背之前，系统模型中哪些语句或者是哪个谓词表达式影响了所关注的这个断言违背，并且它们是如何传播到这个地方。这样在对功能依赖图进行切片时，就可以采用文献[6]中所提出的后向切片准则和两步图的可达性算法对构件系统的功能依赖图进行切片。

2 实验结果和分析

2.1 实验对象说明及实验结果

本节以三角形问题构件中反应三角形类型的状态“tType”作为兴趣点，对其构件系统的功能依赖图进行切片试验。图4所得到的即为切片后的三角形问题构件系统的功能依赖图。

在利用基于模型检验的接口变异测试方法对构件系统进行验证并生成测试用例时，为了能够体现出构件系统模型中存在的“状态空间爆炸”问题以及通过切片技术对系统的状态空间进行压缩后的效果，首先选择三角形问题构件的接口函数TriType（int a， int b， int c）的等价变异体TriType（int c， int b， int a）作为研究对象，并将三边的输入域划分为5组进行对比分析。

表2给出了在上述实验条件下，JPF对切片前后的构件系统在模型验证后所得到的状态数，它是由JPF统计信息中“state”里面的“new”与“visited”相加所得到的。

对表2进行分析可知：

首先，除去最后一行对压缩率的分析外，表格中的每一行都反应出随着三角形三边输入域的增加，整个模型检验过程所耗费的时间以及在验证过程中所产生的状态数都在以指数形式增加，这就体现了在本章最开始所提到的“状态空间爆炸”问题。

其次，表格中的每一列说明了在对构件接口调用关系模型运用切片技术后，模型检验工具在验证过程中所耗费的时间有了一定的减少，而且在整个验证过程中系统模型所产生的状态空间的数量也得到了压缩，模型检验的验证效率得到了提高。

再次，由于上述五组实验只改变了三角形问题构件的输入域，对于构件系统模型本身并没有进行改变，因此，在使用相同的切片准则并运用切片技术对构件系统的功能依赖图进行切片后，所得到的系统模型的状态空间压缩率在效果上基本是相同的。

最后。上述五组实验的验证结果都没有检验出任何反例路径，因此，切片技术的运用并不会影响“基于模型检验技术的接口变异测试方法”对等价变异体的正确判定。

2.2 统计分析

在上一小节中，通过利用JPF对同一个等价变异体TriType（int c， int b， int a）的五组不同输入域的检验，说明了运用切片技术对构件系统中单个接口函数的等价变异体进行压缩后，依然能够通过“基于模型检验技术的接口变异测试方法”对等价变异体进行有效地判定。但是，当同一个构件中所有不同的接口函数在分别运用切片技术对构件系统模型进行压缩后，上述实验结果并不能够说明切片技术对整个构件系统的验证以及对接口测试用例生成所产生的影响。因此，本小节将就这一问题作进一步的讨论。

这里，分别以三角形问题构件中的三个状态属性作为兴趣点对构件系统进行切片，然后三个接口函数的非等价变异体对切片后的构件系统模型进行变异并验证。表4给出了三个接口函数在切片前后进行变异并生成测试用例的相关验证信息，为了能够达到对系统模型状态空间进行穷尽搜索以及对非等价变异体生成所有测试用例的目的，这里将JPF中的搜索配置策略设置为“搜索显示多条反例路径”。同样地，表3所产生的状态数也是由统计信息“states”中“new”与“visited”相加得到的。

通过对表3可以发现：

首先，对于每一个需要验证的系统模型来说，在运用切片技术对系统模型进行切片之后，都能够达到压缩系统模型状态空间数量，并提高验证效率的目的。

其次，表中的数据以及实际的实验结果说明，切片后的系统模型在验证后所产生的反例路径与切片之前所产生的反例路径是相同的，因此，切片前后所产生的测试用例也是一样的。

最后，尽管切片技术是对构件系统的功能依赖图进行切片，但其实质上是对构件系统的状态空间进行缩减。由于三角形构件系统中仅由一个三角形构件组成，因此其状态空间是由三边的输入域所确定，这样，表中三组实验所对应的切片前的构件系统模型在验证后所产生的状态空间总数是一样的；同时，对于每一个切片后的构件系统模型来说，其状态空间是由三角形构件中的一个状态所决定的，而该状态又是由相同的输入域确定，因此在切片后，构件系统模型的状态空间总数也是一样的。综上所述，三组实验的状态空间压缩率也是相同的。

3 结束语

目前，基于模型检验的测试用例生成技术作为一种新兴的软件测试方法已经得到了测试人员的广泛关注，但是由于模型检验技术中所存在的“状态空间爆炸”问题会使得验证的效率较为低下，因此，本文主要讲解了运用切片技术对系统模型进行切片从而达到压缩系统模型状态空间，并提高验证效率的目的。

本文以构件之间接口的交互关系为基础，通过扩展构件之间接互图后，提出了一种建立构件系统的功能依赖图的具体方法，然后运用切片算法实现了对其进行切片的目标。最后，本文通过基于模型检验的接口变异测试方法对三角形问题的JavaBean构件的实验说明：在运用切片技术对系统模型进行切片以后，达到了有效压缩系统状态空间数量并提高验证效率的目的，同时，不但可以对等价变异体模型进行正确地判定，而且对于非等价变异体模型来说还可以正确地生成测试用例。

参考文献：

[1] 林惠民， 张文辉. 模型检测：理论，言方法与应用[J]. 电子学报， 2002， 30（12A）： 1907-1912.

[2] 梁陈良， 聂长海， 徐宝文， 陈振宇. 一种基于模型检验的类测试用例生成方法[J]. 东南大学学报（自然科学版）， 2007， 37（5）： 776-781.

[3] W. Visser， C. Pasareanu， S. Khurshid. Test Input Generation with Java PathFinder[C]. Proceedings of ISSTA 2004， New York： ACM Press， July 2004， 97-107.

[4] 李必信. 程序切片技术及其应用[M]. 北京： 科学出版社， 2006： 3.

[5] 张K， 王[， 韩柯， 欧阳志强. 面向构件接口变异的模型检验技术研究[J]. 电脑知识与技术， 2010（6）： 1954-1956.

[6] Horwitz S B， et al. Interprocedural slicing using dependence graphs[J]. ACM Transactions on Programming Languages and Systems， 1990， 12（1）：26-60.

篇(2)

关键词：CBI联锁，OCS950系统，一致性测试

中图分类号：U231+.3 文献标识码：A

天津地铁2、3号线信号系统由通号集团总包，庞巴迪作为主要技术分包商，实现了一套完整的CITYFLO650基于无线通信技术的移动闭塞系统。其中，联锁系统作为最核心最基础的系统，使用庞巴迪EBILock 950 CBI联锁与OCS950目标控制器系统[1]。由于地铁2、3号线工期紧凑，给予信号系统安装调试期短，联锁调试显得尤为紧凑和重要。

1 联锁调试前的准备工作

（1）线缆绝缘测试

线缆绝缘测试主要包括：电源屏所有输出供电配线、组合柜到分线柜配线、分线柜至各控制单元配线、以及目标控制器（OBC机柜）到组合柜的配线等。测试要求依次完成各单元每一根线缆的线缆电阻、线间绝缘及线缆对地绝缘的测试。

（2）上电测试

天津地铁2、3号线采用综合UPS供电技术。对于OCS950系统OBC机柜，各模块供电后需要用安装有WinOC test 软件（庞巴迪系统专用）的测试笔记本（设置IP地址为 172.21.0.3）通过网线连接至OBC机柜CCME通信板，以观察各OC板的工作状态是否正常，确认所有供电单元上电正常[2]。

2 联锁测试流程及方法

联锁系统测试包括点对点的测试、轨旁信号设备单体调试、联锁室内外一致性测试三大部分。

2.1 点对点测试

点对点测试是为了确定目标控制器与组合继电器的一一对应关系是否正确，验证目标控制器驱动与采集是否正确。

点对点测试时连接测试笔记本（安装有WinOC test 软件）到目标控制柜，通过软件下发驱动信号，同时确认能够通过软件观察到采集状态的变化。使用DC24V电源端子线，根据各个组合采集电路图及配线图依次将需要测试的继电器驱起和驱落，观察测试笔记本软件内采集状态的变化是否正常。

2.2 轨旁单体测试

（1）信号机测试

信号机单体调试是使用点对点测试软件完成目标控制器对信号机单体设备点对点控制的调试，其中包括信号显示控制调试；信号机单体输入输出电压、电流测试；

① 连接测试笔记本到目标控制柜，通过点对点测试软件完成对信号机红（R）、绿（G）、黄（Y）、红黄（RY）、M红（MR）显示的驱动，并测量其对应信号显示的一次侧电压电流、二次侧电压、及二次侧设定电压值，保证其测量值在系统设计确定的范围内并尽可能趋于范围的中间值。

② 各信号显示电流测量范围如下(参考庞巴迪系统)：

当红黄同时点亮时,红灯和黄灯显示信号电流也要保持在上述范围内。

③ 2、3号线信号机的灯丝报警采用两级报警机制。灯丝报警仪检测作为一级报警，OCS内部板卡检测作为二级报警（降级报警）。对信号机进行降级测试，确定绿灯显示能降级为红灯，黄灯显示能降级为红灯，红黄显示能降级为红灯，M红灯降级为红灯，红灯降级后为灭灯状态。其一级报警设置原则为：M红灯LED灯短2束报警，其他颜色灯位LED灯断4束报警；二级报警设置原则为：黄灯降级报警电流下限为98mA，红灯降级报警电流下限为98mA，绿灯降级报警电流下限为100mA，M红灯降级报警电流下限为110 mA。

（2）转辙机测试

转辙机测试的目的是通过点对点测试软件完成目标控制器对转辙机单体设备点对点控制的测试，其中包括转辙机的定操、反操、定表、反表、失表示、转辙机动作电流、动作电压、动作时间、摩擦电流、摩擦电压及四开状态下的动作时间、4mm转辙机不锁闭失表示、2mm转辙机锁闭有表示等参数。

① 连接测试笔记本到目标控制柜，给转辙机设备上电，通过点对点测试软件对转辙机执行定操和反操命令确定转辙机动作方向是否正确，动作到位后定位和反位表示是否正确。

② 测量转辙机所有需要测量的参数如下：

道岔正常动作时：

动作电压380V±10%；

动作电流

道岔处于四开状态时：

动作电压380V±10%；

动作电流

动作时间

转辙机断表示测试；转辙机断遮断器测试；

道岔岔尖2mm锁闭、4mm不锁闭测试。

（3）PSD（屏蔽门）接口测试

PSD接口测试的目的是为了完成信号系统与屏蔽门系统的硬件接口的测试（如果测试过程中PSD不具备联机条件，本测试可使用封线假条件），为联调联试做准备[3]。

①将屏蔽门全部关闭，确认门控柜门关继电器吸起。在屏蔽门PSL盒激活互锁解除，确认门控柜门旁路继电器吸起，互锁解除恢复时确认门旁路继电器落下。在屏蔽门PSL盒激活本地控制，确认PLC采集到本地控制信号，本地控制恢复时确认PLC采集到的信号消失。

② 在门控柜激活开门信号和关门信号，确认屏蔽门相应的开起和关闭。

③ PSD测试中如果测试的是非集中站，同时需要集中站测试人员确认所测试的非集中站在集中站对应的复视继电器状态与非集中站是否一致。

（4）PEP（紧急停车按钮）接口测试

PEP接口测试是为了完成信号系统紧急停车控制功能的测试。测试中将站台和车控室所有紧急停车按钮恢复，由集中站测试人员确认对应的紧急停车继电器吸起，当按钮被按下时继电器落下，依次激活和恢复每一个紧急停车按钮，确认集中站继电器状态正确。

2.3 联锁室内外一致性测试

联锁室内外一致性测试是通过ATS软件完成ATS工作站站场表示及操作与室外轨旁设备的一致性测试[4]。

① 通过ATS工作站排列进路，开放每一架信号机的每个灯位显示，室内外人员一起校验实际与显示一致性，并通过联锁维护终端查看对应的参数是否正确。由室外人员设置信号机断束报警和断丝报警，然后通过灯丝报警仪设置各个信号机报警电流的上门限值和下门限值，同时确定ATS会有对应的报警显示。

② 通过ATS软件对转辙机进行定操和反操操作，室内外人员一起校验实际与显示一致性，并通过联锁维护终端查看对应的参数是否正确。然后由室外人员对转辙机断表示、断遮断器，确定ATS和联锁维护终端会有相应的报警显示，并且断遮断器时转辙机不能动作成功。

③ 轨旁人员对PSD进行开关门、互锁解除操作，确定屏蔽门状态和ATS、维护终端显示一致。

④ 轨旁人员对站台所有PEP按钮及车控制PEP按钮进行激活，取消激活操作，确定PEP激活状态和ATS、维护终端显示一致。

3 结束语

联锁系统调试是地铁信号系统建设开通的重要环节，联锁控制是关乎地铁安全运营的核心重点。本文介绍了整个联锁系统硬件控制部分的调试流程及方法，笔者根据实际经验概述了天津地铁2、3号线联锁系统调试的实现过程。

参考文献

[1] 天津地铁2号线 工程信号系统详细设计文件.第二册2010.10.

[2] 天津地铁 2&3 号线EBI Lock 950 系统接口.2012.2.

[3] 天津地铁 2&3 号线轨旁ATC系统．2012.1.

篇(3)

关键词：DSP；汇编语言；测试

中图分类号：TP313文献标识码：A文章编号：1009-3044(2008)23-963-02

DSP Assembly Language Software Testing Method

HU Qing-xia, LIU Qing-feng

(91413 Units, Qinhuangdao 066001,China)

Abstract: The in-depth analysis of the DSP assembly language software testing difficult, given the DSP assembly language software testing strategy, the DSP assembly language software is an important test of significance.

Key words: DSP; assembly language; test

1 引言

目前，DSP硬件系统已具有了很高的可靠性，但其软件系统，特别是用汇编语言设计编写的较为复杂的软件系统，可靠性总是难以得到保证，更是缺少完整的质量保证和评估体系，这已经成为DSP应用方面亟待解决的一个问题。对DSP汇编语言软件的测试与一般的软件测试不同，其自身的特点决定了测试面临的困难。本文首先对其测试难点进行分析，然后给出了DSP汇编语言软件的测试方法。

2 DSP汇编语言软件环境的复杂性分析

2.1 与硬件结合紧密，测试环境难以搭建和选择

汇编语言的程序是烧制到DSP芯片中运行的，DSP芯片种类繁多。这些芯片的外部管脚、内部存储器分配都各不相同 。在搭建宿主机测试环境时必须选择各种不同的相对应的芯片，然后配合仿真器与宿主机连接。这些硬件的配置本身就增加了测试难度，然而这些仿真环境总是和目标环境之间有着不小的差异,比如目标环境的中断难于模拟等。基于目标的测试消耗较多的经费和时间，而基于宿主的测试代价较小，但毕竟是在模拟环境中进行的。目前的趋势是把更多的测试转移到宿主环境中进行，但是，目标环境的复杂性和独特性不可能完全模拟。

2.2 I/O通道少，测试数据获取比较困难

在DSP汇编语言软件的测试中给主机上载测试数据是很困难的。目前主要是基于以下3 种方式：1）实际的物理通道；2）开发工具IDE的虚拟IO功能；3）直接读取内存区数据。第一种方式就是目标机和主机之间具备物理的通信方式，比如以太网、串口、并口、USB等。这种方式要求系统必须具备这种通信方式和通信软件，一般只适用于系统级的测试。第二种方式是借助开发工具，比如TI CCS，这种方式调试较为复杂也容易出错。第三种方式则是需要占用较多的内存资源。

2.3 实时性要求较强

DSP软件一般都用作控制系统的内核，所以有很高的实时性要求，而实时性的测试是一般的测试方法和测试工具都难以实现的。

2.4缺少相应测试工具

汇编语言结构和语法都比较繁琐和冗长，这首先使测试人员理解程序变得困难，又因为DSP芯片的多样性，使得开发针对DSP汇编语言软件的通用测试工具几乎是不可能的。因此，在测试时，只能够使用一些测试工具（比如覆盖率分析工具等），而把测试的重点放在人工的代码审查上面，这就要求测试人员要很熟悉相应芯片的用法并且还要与开发人员充分的沟通。

3 DSP汇编语言软件的测试策略

DSP汇编语言软件是最难测试的软件之一，必须制定有效的测试策略。在搭建测试环境时，要寻求宿主机与目标机之间的平衡，即要对目标环境和宿主环境的测试内容有所选择，在宿主环境中，可以进行逻辑或界面的测试、以及与硬件无关的测试。在模拟或宿主环境中的测试消耗时间通常相对较少，用调试工具可以更快地完成调试和测试任务。而中断测试、硬件接口测试、系统集成测试等必须要在目标环境中进行。而在测试环境搭建完成之后，考虑到重要性以及测试执行先后顺序，把整个测试依次分为以下几个不同阶段。

1）代码审查阶段。对于DSP汇编语言软件，代码审查是整个测试的重点，要占到整个测试周期的60%。同时，代码审查又是功能测试编写测试用例之前的必要步骤。代码审查最好是在开发环境中通过硬件仿真进行。

2）功能测试阶段。在功能测试阶段，采用功能分解法、等价类划分和猜错法等方法，根据软件需求规格说明中所规定的软件正式合格项设计并执行测试用例，以验证其功能是否满足需求规格说明的要求，并对其功能的适合性和准确性进行验证。对于DSP汇编语言软件系统，功能测试必须首先进行模块化处理，分离出每个模块的输入输出。

在设计功能测试用例时，也包括对边界值的测试，即对输入域(或输出域)的临界状态、数据结构、状态转换、功能界限等的边界或端点情况下的运行状态的测试。此外，设计功能测试用例时运用覆盖测试工具辅助测试用例的设计，以达到功能测试的充分性。

3）性能测试阶段。在DSP软件系统中，程序的性能是非常重要的，要严格根据需求中对负载、定时、性能的要求，判断软件是否满足这些需求规范。在使用环境中，软件的失效过程要平稳（电机运动惯性问题），所以，不仅要检查软件工作过程，也要检查软件失效过程。

可以使用测试工具CODETEST主要对DSP下行的伺服驱动器控制软件中有时间要求和数据处理精度要求的软件合格性项进行测试，并把重点放在测试其实际时间特性与实际数据处理精度上。时间特性主要包括以下几个：中断延迟时间、任务上下文切换时间、任务响应时间、任务创建/删除时间、交替信号量时间、取得/释放信号量时间、交替消息队列传输时间。

4）接口测试阶段。为了保证正确地测试，还须要检验软硬件之间的接口。对接口的测试主要利用各种不同类型接口的监视工具。比如对TMS320LF2407板汇编软件串口测试，可以使用串口监控器EtherPeek.NX，人工设置各软件从RS232串口接收的输入/输出，验证各软件对输入/输出的反应，并监控其输入/输出内容的格式与数据位是否与接口规范一致，验证各接口的正确性和一致性。

5）结构覆盖测试阶段。使用测试工具LDRA TestBed对被测软件程序进行插装。插装可以是在测试环境中嵌入硬件，也可以是在可执行代码中加入软件，也可以是二者相结合。基于测试用例，执行插装后的程序，提取语句/跳转覆盖信息，将程序的执行表现与编码意图进行比较，衡量软件测试工作的充分性。代码覆盖分析工具可能侵入代码的执行，影响实时代码的运行过程。基于硬件的代码覆盖分析工具的侵入程度要小一些，但是价格一般比较昂贵，而且限制被测代码的数量。

6）强度测试阶段。在模拟环境下，打开被测软件全部数据采集与数据通信通道，运行全部模拟外设，长时间运行功能测试和接口测试等相关测试用例，检测交流伺服驱动器控制软件在设计能力下的运行情况。

7 ）安全性测试阶段。采用人工测试的方法对被测软件进行安全性测试。检测用户是否能对被测软件进行灾难性操作，被测软件是否具有关键操作的安全性保护等功能。对于电机控制系统的DSP软件，主要检查过压、过流、低压、低流、断电、异常复位等灾难性操作。

8）可恢复性测试阶段。采用人工测试的方法对被测软件进行可恢复性测试。用人工干预的手段模拟硬件故障、链路故障、电源故障等，故意造成系统出现异常，并由此检查被测软件是否具有错误探测功能，在故障发生时能否保护正在运行的作业和系统状态。并检测被测软件在重启之后能否正常地继续进行工作，并不对系统造成损害。

9）回归测试阶段。对于在测试过程中发现的问题，开发方应及时对其进行修正。修正后由测试方通过回归测试进行确认。回归测试必须将所有功能测试、接口测试等测试用例重新执行一遍，以验证所有问题已经全部解决，并且没有引入新的问题。

4 结论

此方法研究在一定程度上减轻了DSP汇编语言软件的测试难点，对以后的测试实践有重要的参考意义。此策略的充分性和自动化程度是今后工作和研究的方向。

参考文献：

[1] 郑人杰.计算机软件测试技术[M].北京:清华大学出版社,1992.

篇(4)

关键词：物联网云计算平台；测评体系

中图分类号：F426.6

以云计算、物联网、下一代互联网为代表的新一轮信息技术革命，正在成为各国社会和经济发展共同关注的重点，当然，质量是其核心的竞争力。因此物联网云计算平台的测试策略的研究具有极其重要的意义。

1 物联网云计算平台的发展现状

物联网云计算平台是一种IT资源的集中管理与动态分配模式，即将各种IT基础设施集中到一个资源池中，并以按需服务的方式提供给终端用户，用户只需要一个简单PC或接入客户端（如Web），来获取云计算体系分配的资源或应用服务―――可能是一个虚拟的PC（远程桌面）或某个Web应用（Mail）。物联网通过物体与网络的统一，实现物体网络化。物联网云计算平台根据用户需求给用户分配资源，用户使用完成后，云管理又可以将其收回，重新放入到资源池中。

2 基于物联网云计算平台的软件测试注意事项

2.1 员工的专业知识应扎实

物联网云计算系统是新一代信息发展的重要体现，员工尤其应该与时俱进，深入了解物联网云计算平台的运作机理与自身的业务流程，熟练地掌控物联网云计算平台在运作中与自己业务的对应关系。使得这样的高科技平台能够娴熟地受到人为的操作。只有这样才能让平台进行高效的测试和执行。

2.2 降低测试对生产环境带来的风险

物联网云计算平台不同于传统的测试，只能通过现实的生产环境来进行测试。这样的特性，加大了测试的风险。因此，作为专业的测试人员应该要好好利用其它手段来有意识的规避这方面的问题。

2.3 对物联网云计算平台的性能测试重点关注

测试的目的是来验证物联网云计算平台在承担各种负载的情况时表现出来的服务性能。我们通过使用不同的测试用例、场景以及模拟边界、压力测试来测试相关性能。随着不断的使用，整个过程会消耗平台的运行能效。系统重新部署运作时，虚拟机的性能和效率也会打折扣。所有的这些结果导致测试人员必须采取合理的场景与脚本进行有效的测试。

2.4 对安全性、可靠性的测试加以关注

关于物联网云计算平台安全可靠性测试目前主要采用评估的方式，其过程是通过物联网云计算平台模型得到相关的安全可靠模型，通过模型分析对建立的安全可靠性进行直接评估。测试人员通过测试评估过程中产生的数据以及其他的测试评估结果进行全面统一的分析比较计算，构成关于物联网云计算平台的安全可靠性评价。对于测试的关注度还应考虑到物联网云计算平台的兼容性、容错性和可恢复性。

3 面向物联网云计算平台的质量测评体系的建立

质量测评体系对于一个组织系统或是一个产业的可持续发展具有很重大的作用。随着网络技术的发展，互联网技术的浪潮，以及各种新科技的发展，物联网云计算平台正在继续走向成熟，以物联网云计算平台为中心的时代即将到来。这就更需要质量测评体系的重度把关。质量，就是某种产品对需求的满足程度和特征的总和。面向物联网云计算平台的质量测评体系，决定了物联网的发展前途。

3.1 质量测评体系的认识

通过从基础的网络设备的建设，逐步推进，不断提高信息技术含量，从而带动国家的各方面发展，强化产业优势和国家竞争力；通过在人民大众的生活区域内建立职能网络，让大众随时的感受科技智慧的服务。根据物联网云计算平台管理运行机制的本质特点和目标，面向物联网云计算平台的质量测量体系指标应该当从整体质量评价的效果上来进行，从整体的角度实现物联网质量的提高，而不能只是看重某一个环节对现有的情况的影响。

随着物联网技术的发展，为了更加合理地显示出质量问题，就应该要考虑建立和其相对应的质量测评体系，并根据所建立的这个质量测评体系，对物联网进行评定。这个体系的指标有其自身的特点，其内容相比其他评价指标体系更为宽广。

为了建立有效的质量测评体系，应该参照以下几个原则。第一，要显出重点，对关键的影响因素要进行着重研究。第二，要采用能反映物联网运行流程的指标体系。第三，采用的指标体系不仅仅是反映物联网的某个点的情况，而是要考虑到全局。第四，要做到实时分析，实时评价，并作出相对应的方案条例。

3.2 面向物联网的质量测评体系的建立

质量测评体系的建立应该从以下三个方面入手：第一，确定测评原则，制定评定计划；第二，建立测评体系，开始测评工作；第三，质量综合评价，开展质量跟踪，提高质量。必须对物联网的质量进行测评，这样才能发现其不足，以完善其缺点来提高其服务质量。但是在研究具体的方法之前我们需要了解测评体系该如何建立，测评体系的特点。

确立测评体系的构建思路首先有利于我们可以迅速抓住体系构建的重点，并能顺清思路，根据物联网服务的特征，我们应该在面向物联网的质量测评体系的构建中遵循以下思想。

第一，重视信息共享，物联网的运行和市场都靠信息的共享，大量真实的信息，是这一个体系的核心。第二，选取关键性指标。物联网涉及的领域广，信息量大，如果从一个个普通的指标入手，不仅成本太大，而且不能发现影响其质量的关键性因素。第三，层次化。这样各个不同的指标就有可比性，能够产生有效的决策支撑，是一种重要的分析方法。第四，区分不同领域。物联网的领域广，不同的领域有不同的运转方式，因此要采用不同的测评指标。

4 物联网云计算平台的测试策略

4.1 熟悉物联网云计算平台的测试技术及测试需求

物联网云计算平台测试是一个复杂新型技术，这就需要相应的测试工程师对物联网云计算平台有着深刻的理解。比如像海量数据的管理、物联网云计算平台自身的管理以及资源调度、分布式的编程模式、虚拟化技术、存储模式等。工程师如果能对这些相关技术有着熟练的驾驭能力，那么才能精确地对物联网云计算平台测试的缺陷、漏洞和风险产生判断。

4.2 物联网云计算平台真实环境下的部署与测试

应用软件的测试必须是在真实环境下进行的测试。一般为了公司业务的正常运行，会部署出两套应用服务器便于测试和正式上线。并且让所有的软件在物联网云计算平台的基础上同步运行，这样才能保证测试环境的真实有效。

4.3 物联网云计算平台的其他物理接口测试

门户之类的其他系统运行在另外的物理服务器上，与管理系统运行在不同的两个系统中，这样使得接口测试非常重要。接口测试通常会选择标准Web服务测试。通过XML、SOAP、WSDL等一系列专业的服务测试，来测试它是不是合格。当完成接口测试的时候，同时也完成了物联网云计算平台的标准符合性测试。

4.4 对平台的安全性测试

不管是什么软件，关于软件的安全性考虑都是重点，像物联网云计算平台这么庞大的软件系统更是如此。如果系统本身安全性较低的话，单靠外部防护也无济于事。

4.5 对平台的兼容性测试

可以直接用不同的Windows操作系统来达到预想的目的，从而轻松完成系统的访问，并十分便捷地实现兼容性测试问题。

4.6 对平台的容错性能与可恢复性能的测试

检验一个系统的容错能力主要是看容错和可恢复性测试。根据测试结果便可对系统的容错性能有一定了解。主要针对物联网云计算平台故障和恢复测试、客服端的故障以及虚拟机的迁移等。

5 结束语

如今，物联网云计算平台作为新一代信息时代的代表早已到来。面向新一代信息技术应用的测评体系与测试策略的建立，一方面帮助中小企业交付高质量、高可靠的产品和系统；另一方面，推动中国高技术产业的发展，同时也对自己企业模式的转型和创新以及高效运营提供了先机。

参考文献：

[1]章泽昂，邬家炜.基于云计算的教育信息化平台的研究[J].中国远程教育，2010（06）.

[2]钱文静，邓仲华.云计算与信息资源共享管理[J].图书与情报，2009（04）.

[3]曹丽，姜毅，甘春梅，张一弛，陈桂强.云计算软件测试平台的构建[J].现代图书情报技术，2012（11）.

作者简介：刘雪（1981-），女，西安人，西安科技产业发展中心工程师，硕士，研究方向：质量管理及产业研究；王文斌（1972-），男，西安人，西安科技产业发展中心，高级工程师，博士，研究方向：产业研究。

篇(5)

1、引言

随着科学技术的进步及数字通信技术的不断发展，用户通信中越来越关注数据通信的安全性保密性。电话作为人们日常生活中的通信工具，除语音通话外，被广泛用来传真、上网及电话会议等，其数据传输的安全性和保密性越来越受到重视。偶尔的一点消息的外漏，都会引发公司巨大的经济损失。

普通电话线路接口为模拟接口，线路测试仪与交换机问的用户线路上传输的是话音模拟信号，频率较低（频率范围大致为300-3400Hz）。然而有些电话线路接口却为数字接口，此类接口虽然也使用普通的电话线，但用户线路上是将高速数字信号通过基带或幅频调制进行传输，频率较高（频率范围大致为16K-250KHz，如某军工用XXX话机）。目前，相关的线路测试设备不断涌现和换代，普通的电话线路测试仪仅适用于对普通电话业务的线路质量进行全程或区域测量，而对于上述数字类的接口线路，目前的普通线路测试仪就不能满足要求。专用的数字接口测试仪体积较大，不适于用户现场使用，而且测试程序繁琐价格昂贵。因此，本文提出了一种既适应模拟用户接口又适应数字用户接口的电话线路测试仪方法。

2、测试仪硬件结构

测试仪由单片机、FPGAI、LCD、时钟芯片、存储器芯片、Modem芯片1、Modem芯片2、保持电路等组成。测试仪采用单片机与FPGA作为其核心控制电路；存储芯片提供实时保存测试数据的功能；时钟芯片为测试仪提供测试时间；液晶显示用于显示测试的信息等；键盘来选择测试项目和查看测试信息等从而实现人机互动；串口芯片可与电脑通过串口线连接，从而把测试数据传送给上位机软件；配置ROM用来配置FPGA～E作；当电话线路接通后保持电路能够保持测试仪连接到电话线路上电话线路保持通路状态。系统的硬件结构如图1所示。

3、测试仪的测试功能

本测试仪能够实现模拟接口和数字接口的电话线路测试。其基本实现原理为Modem芯片1为低速调制解调芯片，主要实现模拟接口的电话线路测试；Modem芯片2为高速调制解调芯片，实现数字接口的电话线路测试。通过键盘选择相应的测试速率，单片机响应键盘操作并发送相应指令到FPGA，FPGA解析接收到的单片机指令通过控制Modem芯片1的工作来测试低速模拟接口线路或控制Modem芯片2来测试高速数字接口线路。

测试仪需要实现的测试功能有幅频衰耗测试、误码测试、相位抖动测试、串扰测试、信令测试和自检。

4、测试仪系统工作简介

测试仪是整个测试系统的核心，测试时测试系统由测试仪主机和测试仪从机两部测试仪配合使用。其测试连接图如图2所示。此种连接方式能够测试的功能有幅频衰减测试、误码测试、相位抖动测试、串扰测试及信令测试。

测试的基本方法为：预先拨号将电话接通，挂断电话（测试仪通过内置保持电路使被测试线路保持通畅），选择需要测试的功能，如幅频衰耗测试、误码测试等并设置其测试参数。此时，测试仪主机发送测试命令，测试仪从机接收测试数据并分析测试结果。每隔1秒，测试仪从机将测试结果发送至测试仪主机，测试完成，测试仪从机发送测试完成命令至测试仪主机。测试结果可以直接通过RS323串口传送到上位机，也可以保存测试结果待测试完成后利用上位机读取测试结果。停止测试，电话线路恢复通话功能。

自检测试为测试电话线路的各个组成部分是否连接正确，是测试仪工作是否正常的自我检测，不需要连接任何设备，工作原理如图3所示。

选择自检测试，并按0K键，单片机发送自检测试命令至FPGA，Flea分别发送命令至Modem芯片1和Modem芯片2，Modem芯片将FPGA发送的命令直接反馈到FPGA，FPGA再将接收到的命令发送至单片机，单片机将自检结果在液晶显示器显示。

为了测试仪使用灵活方便，本测试仪内部集成主、从两套系统，即其既可以当主机使用也可以当从机使用。其主、从模式转换原理图如图

4、所示

如图4所示测试仪初始默认状态为从机，只进行数据的接收与处理，当选择要测试项目并按OK键后，测试仪从默认的从机状态转换为主机状态，测试测试仪开始发送相应的测试数据。T秒后进行的测试项目完成，测试仪自动由主机状态回复到默认的从机状态。

5、测试仪系统测试结果

篇(6)

【关键词】软件测试；单元测试；用例；等价类

1.软件测试

软件测试是指利用相关测试工具，按照一定的测试方案和流程对软件系统的功能和性能进行测试，对可能出现的问题进行分析、评估，发现开发错误并跟踪，以确保所开发的软件满足用户需求。软件测试是保证软件质量的主要手段，是根据软件开发各阶段的规则说明和程序内部结构而精心设计的一批测试用例，并利用这些测试用例运行程序以发现软件是否存在错误的过程，软件测试的范围应当包括更广泛些，除了考虑正确性外，还应关心程序的效率、健壮性等因素。

软件测试过程包含单元测试、集成测试、确认测试和系统测试四个步骤：

（1）单元测试：对每一个程序单元进行独立测试，检查各程序模块是否正确地实现了预定的功能。

（2）集成测试：把已通过测试的模块组装起来，对软件体系构造的正确性进行测试。

（3）确认测试：检查已完成的软件系统是否已满足了需求规格说明中的各项需求，软件配置是否完全、正确。

（4）系统测试：将经过确认的软件系统置入实际的运行环境中，与其它系统成份结合在一起进行测试。

2.单元测试

单元测试又称模块测试，是以软件系统设计的最小单位——程序模块为对象，进行正确性检验的测试工作。单元测试常被看作编码的附属品，在代码被开发、编译调试、审查后，单元测试用例设计便开始了。进行充分的单元测试，是提高软件质量，降低研发成本的必由之路。几乎所有的开发人员都会对每一段代码做一定程度的单元测试。如果一个模块要完成多项功能，可以将该模块看成由几个小程序组成，对每个小程序分别进行单元测试。如果是关键模块，往往还要做性能测试。

单元测试以详细设计说明书和源程序清单为依据，常采用白盒测试的用例，辅之以黑盒测试的用例，以寻找模块内部可能存在的错误为目的，主要完成模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试等任务。

（1） 模块接口测试

单元测试开始时，要对通过被测模块的数据流进行测试。包括调用该模块的输入参数的正确性、调用其子模块时提供参数的正确性、全局变量的定义在各模块中是否一致等。

（2） 局部数据结构测试

包括数据类型的一致性、变量名、变量赋值、全局数据对模块影响的正确性等检验。

（3） 路径测试

对基本执行路径和循环进行测试，查找由于错误的计算、不正确的比较或不正常的控制流而导致的错误。

（4） 错误处理测试

检测对错误条件的响应是否正确，错误描述是否与实际的错误是否相符、是否能够对错误定位、是否易于理解等。

（5） 边界测试

通过设定边界值检测数据流、控制流中等于、大于或小于比较值时出错的可能性。

在面向过程编程时代，单元测试所说的单元一般是指函数，而在面向对象编程时代，单元测试所说的单元一般是指类。以类作为测试单位，测试的复杂度相对较高，所以目前通常采用的办法是为软件开发建立对应的测试工程，为每个类建立对应的测试类，为每个函数建立测试函数测试结构化的局部代码。

3.单元测试用例的设计

测试用例是指对某特定的软件系统进行测试任务的描述，它体现了测试的方案、方法和技术，包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。

测试用例的设计也就是测试需求细化的过程，测试需求分析和测试用例设计是密不可分的，前者是后者的依据，后者是前者的体现。测试用例的设计应与复审相结合，根据相关设计信息设计测试数据，以增大发现错误的可能性。

单元测试用例可以选取正确输入、边缘数据和错误输入作为测试数据。以系统用户注册模块中出生年、月、日的设置为例，通过等价类划分法设计测试用例。

在划分等价类时，我们将其划分为两类：1、有效等价类：是指输入完全满足程序输入的规范说明、合理的、有意义的输入数据所构成的集合。利用有效等价类可以检验程序是否满足规格说明书所规定的功能和性能。2、无效等价类：是指完全不满足程序输入的规格说明、不合理的、无意义的输入数据所构成的集合。使用无效等价类可以检验程序的容错性能。

篇(7)

1．1通信设备简介

本通信设备由信息处理模块、信号处理模块、收发信道模块及电源模块组成。每个模块具有独立结构件，插入到整机机箱，模块之间以高速接插件及射频接口互联，主要完成综合信息处理，调制解调信号处理，收发变频等功能。

1．2可测试性设计指导思想［4］

可测试性设计的主要内容是机内测试（BIT）设计和自动测试设备（ATE）设计。BIT是指系统或设备内部提供的检测和隔离故障的自动测试能力，ATE则是指自动进行功能或性能参数测试、评价性能下降程度或隔离故障的设备［5］。BIT的主要功能是把设备故障隔离到外场可更换单元（LRU）或外场可更换模块（LRM），ATE则进一步把LRU或LRM故障隔离到内场可更换单元（SRU）。产品的BIT设计和ATE设计应该从方案设计阶段就予以考虑，并且与产品同步研制。图1给出了测试性设计与设备方案设计的基本流程。

1．3BIT设计

作为一个整机设备，不仅要具备监控其内部各模板工作状态的能力，同时也要具备监控整机整体功能、性能的能力，这些在BIT设计时都要考虑到。本通信设备信息处理模块主要完成业务信息处理、数据组帧解帧、整机状态监控等功能，信号处理模块主要实现基带信号调制解调、A／D及D／A转换等功能，收发变频模块主要完成模拟信号上下变频、自动增益控制、提供参考时钟等功能，电源模块给各个模块提供直流稳压电源。根据图2所示的设备测试工作流程图，将BIT设计分为加电BIT、周期BIT、维护BIT。现在复杂数字系统的设计，有些数字芯片自身就具有状态监控的能力，只需控制电路上报这些状态即可。对于可编程逻辑器件（FPGA、CPLD等）和嵌入式微处理器（PowerPC、DSP等），可在程序设计时考虑加入多种监控手段，尽量把设备问题隔离到模块级。

1）加电BIT：加电BIT是设备刚上电时对自身健康状态进行检测，设备还没有进入正常工作状态。对于本设备，各模块分别将BIT信息上报信息处理模块，信息处理模块综合后上报显控终端。主要检测的信号有：串行通信总线功能是否正常、电源模块输出是否正常、频综是否锁定，系统时钟是否正常，内部ROM、RAM是否正常，微处理器PowerPC、可编程逻辑器件FPGA、数字信号处理器DSP等主要数字器件状态是否正常，微处理器中断响应是否正常等。如果时间允许的话，3）中维护BIT的（1）～（3）也可在加电BIT时实现，通过判断3种环路下接收机的锁定状态，实现对设备基本功能的快速检测。2）周期BIT：周期BIT指的是设备周期检查自身工作状态，并不影响正常工作。主要有性能检测和故障检测。周期BIT不仅包括启动BIT中与正常工作状态不冲突的状态检测部分，还有对设备工作时的性能状态监测，包括模块工作温度指示、发射状态、接收机锁定状态、接收端BUFFER状态、接收信号电平、接收信号信噪比（Eb／N0）、接收误码率及接收信号频偏等。3）维护BIT：加电BIT和周期BIT只能检测最基本的故障，当设备出现问题时往往需要维护BIT来进行故障检测和隔离，这个是本设备BIT设计的重点内容。维护BIT时设备工作在测试模式，不正常工作。本设备维护BIT主要通过图3所示的3条环路来实现，每个环路各有侧重点，主要内容如下：

（1）数据接口自环：如图3中的环路1所示，数据接口自环指的是显控终端控制信息处理模块将发送数据帧经过FIFO后的数据直接送到模块接收端，此方法主要测试发送数据组帧是否正确，发送FIFO以及接收BUFFER的工作状态是否正常，微处理器中断响应是否正常等，用于验证信息处理模块的数字接口功能是否正常。

（2）中频自环：图3环路2所示，中频自环指的是信号处理模块输出的中频调制信号直接送到接收端进行解调，通过观察接收锁定情况，可判断信号处理模块工作是否正常。此外，运用此方法可测试信号处理的调制、解调性能指标。显控终端控制信息处理模块使用伪随机码（PN码）填充数据帧，信号处理模块调制产生中频信号，接收端解调后将数据帧送回信息处理模块进行比对，可用于测试信号处理模块解调误码率，想办法从发射端叠加噪声，可同时测量解调门限及对应误码率，这个方法中频自环由模拟域开关切换，无需改变外部电缆连接。

（3）射频自环：如图3环路3所示，射频自环指的是收发信道的射频输出端直接送到射频输入端，通过观察接收锁定状态，验证收发信道模块是否工作正常。具体过程为发射端信号处理模块输出的中频信号经过收发信道模块后上变频到射频，射频信号在收发信道模块内部送到接收端下变频到中频后送回信号处理模块，同时验证收发变频模块和信号处理模块。此时仍可使用（2）中所介绍的误码率及解调门限测试方法，验证经过信道后信号处理模块的性能。一般在设计时，由于发射信号比较大，接收信号相对比较小，可通过将收发信道的发射端信号耦合出一路环回到接收端的方式，同样采用模拟开关切换，无需改变外部电缆连接。

（4）单载波测试模式：此模式控制信号处理调制端发射未经调制的单载波，主要用于测试载波的相位噪声，以及其他相关指标，如发射载波频率准确度、杂波抑制，谐波抑制等。此外，该模式可用于测量接收端载噪比（C／N0），因为单载波调制功率和调制信号的通道功率相当，通过标定接收端载噪比可算出接收端的解调信噪比Eb／N0，对整个通信系统的链路状况作出判断。

（5）发射端1，0调制模式：该模式控制调制器输出一个经过交替1，0，1，0序列调制后的载波，序列的符号速率为当前通信符号速率，这样将会在距离载波频率正负1／2符号速率的位置产生两个离散频谱，用于检测调制器的载波抑制。如果调制方式是OQPSK，将会出现一个频谱，适用于测量单边带载波抑制，对于确定调制器的幅度和相位准确度也非常有用。4）BIT信息管理：对于机载通信系统尤其是无人机系统，应该在设计时考虑将重要BIT信息下传至地面处理中心便于综合分析。一般应在系统中设置数据记录装置，记录全机各设备在飞行过程中上报的各类BIT信息，作为事后分析的依据。本设备的BIT信息上传给显控终端后存储在机载计算机的硬盘中。

1．4ATE设计

由于BIT设计受10％软硬件增量限制［6］，不可能将故障完全隔离，也很难达到较高的故障隔离率要求，因此必须借助ATE来共同完成故障诊断和隔离。ATE的出发点是在BIT将故障定位在LRU后，进一步将故障定位到SRU以及LRM。随着数字电子技术的不断进步，ATE向着通用化、小型化、标准化方向发展［7］。对于实际应用，ATE的这种设计要求是矛盾的，既要通用化又要小型化，最终只能折中考虑。本设备没有设计专用的整机ATE设备，而是设计了一个整机接口测试板和各个模块的离线测试夹具，相当于ATE的作用，分别用于原位测试和离线测试。1）原位测试：对于实际应用中，在某些情况下需要在问题出现时在线对故障进行定位，特别是对本电子通信设备，要完成相对复杂的综合信息处理、协议处理、调制解调信号处理，各个模块间存在较多交互，这样给离线检测带来较大困难。针对这种情况，本设备在设计时在机箱外面预留一个测试口，这个测试口为一个多芯接插件，将设备内部FPGA及DSP的JTAG下载调试口、PowerPC的网口及调试串口、模块内部的主要监控信号引出来，在出现问题时可原位在线测试，适用于设备的调试测试、综合故障分析以及程序升级。这个测试口引出后连接到接口测试板，测试板上集成上述各种测试口及主要监控信号，方便在不开设备机箱的情况下在线对设备故障进行检测和隔离。2）离线测试：问题隔离到一个单独模块后，为了进一步分析隔离故障，需要做一个针对单板测试的ATE。本设备各模块均做了一个专用测试模块，这个测试模块根据待测模块的内部软硬件架构、结构进行测试性设计，简称测试夹具。夹具实际也是一个PCB板卡，通过接插件和待测模块相连，完成待测模块的单板加电、单板测试验收及故障定位。这个测试夹具可模拟互联的其他模块的测试激励信号和响应信号，实现脱离仪器的单板全功能、性能测试。ATE作为对模块的测试分析与性能评估，其自身的状态必须保证，应在实验室用专业仪器对其状态进行全方位测试与验证，使其具有很高的可靠性，并应定期标校。

2测试结果

根据以上BIT和ATE设计对本通信设备进行了测试，部分测试结果如表1所示。

3结论