专家笔记：如何利用ETest制作标准化的测试工装页面

测试是保证重要资产设备质量和可靠性的重要手段。行之有效的测试工装已成为提升产品测试效率、保证测试质量的必备要素，是各装备行业保障产品开发与交付的关键。

为了方便学习，小编为大家奉上凯云科技专家笔记，手把手教您从0开始开始搭建测试工装页面~

01

 ETest简介 

ETest作为一款自动化测试平台开发工具，具有测试环境拓扑描述、测试监控、测试脚本开发、测试数据设计、测试执行数据采集与展示、测试结果分析等功能，基于该开发工具可以完成半实物仿真测试软件的开发与部署。

该产品是由凯云科技率先在行业内推出的国产自主可控半实物仿真测试开发平台，有效打破了国内该领域长期由进口软件LabView、DSpace等产品垄断的格局。ETest可广泛应用于航空航天、武器装备、工业控制、汽车电子、仪器仪表等各行业测试工装、测试仪器等设备的研发。具有应用范围广、实时性强、开发效率高、使用简单、易于扩展、国产自主等特点，支持各种国产CPU＋国产操作系统的部署方案，同时兼容Windows、linux、Mac等多种操作系统。

02

 需求分析 

对于如下图所示的连接关系拓扑，“设备A”与“设备B”之间通过RS232接口进行通信，“设备A”发送的报文，自然就是“设备B”需要接收的，“设备B”发送的报文自然也就是“设备A”需要接收的。

“设备A”与“设备B”均是“系统S”的组成部分，为了对系统S中的各个设备进行有效的测试，需要分别对A进行单独测试，也要对B进行单独测试，然后将“设备A”与“设备B”连成“系统S”，进行“系统S”的功能、性能测试等。

之所以要进行“设备A”与“设备B”的分别独立测试，可能的原因包括：

（1）“设备A”、“设备B”由不同的厂家研制，不可能等到集成时再进行测试与试验；

（2）“设备A”或“设备B”逻辑处理均十分复杂，测试与试验需要的触发条件或测试环境均需要有良好的可控性，可以方便地进行各种容错性测试；

（3）“设备A”或“设备B”不仅是“系统S”的组成部分，可能还是“系统T”的组成部分，也就需要分别对“设备A”和“设备B”进行独立验证。

03

 ETest设计原理 

在对“设备A”进行测试时，自然就需要模拟“设备B”向“设备A”发送报文，然后模拟的“设备B”也需要接收“设备A”发出的报文，对其进行解析和判断。

同理，在对“设备B”进行测试时，则需要模拟“设备A”向“设备B”发送报文，然后从模拟的“设备A”也需要接收“设备B”发出的报文，对其进行解析和判断。

ETest作为一款自动化测试平台开发工具，所承担的角色就是作为测试设备，模拟“设备A”或“设备B”，并在模拟设备的基础上，加入故障注入能力和测试处理逻辑。

3.1测试环境的描述

ETest中测试环境的描述包括了设备、连接拓扑和通信协议。设备目录下可以包含组成系统的所有设备；连接拓扑可以通过设备组成连接拓扑，可以有多个连接拓扑，用于实现对系统中的不同设备进行分别测试。

上图给出了对“设备B”进行测试的连接拓扑，在该连接拓扑中“设备B”作为被测设备，“设备A”就作为了仿真测试设备。

同理，对“设备A”进行测试的连接拓扑就需要另外建立，形成如下的连接拓扑，在该连接拓扑中“设备A”作为被测设备，“设备B”则变为了仿真测试设备。

“设备A”与“设备B”之间互传的协议包括三条，分别是AtoB01、AtoB02、BtoA00，如下图所示。

测试环境构建完成后，需要开发测试程序和测试用例，测试程序也就是我们俗称的测试脚本，而测试用例则是测试程序所使用的网络变量或测试数据变量。除了开发测试程序和测试用例外，想要形成专业化的测试工装，则需要利用ETest开发出测试用的UI页面。

3.2ETest的绑定和运行机制

要想按照测试需求在测试环境基础上组织好测试程序、测试用例、界面UI，就必须首先理解ETest中测试程序、测试用例、界面UI以及测试环境的关联绑定和运行机制。

在ETest中，测试程序是运行在测试执行引擎上的，测试执行引擎执行时可以向控制台输出调试信息，控制台通过交互命令在测试执行时调用测试程序中的函数或使用临时编写的脚本，向测试执行引擎进行命令交互，以应对测试过程中的命令突发情况。

在ETest要达到测试能在测试执行引擎上有序进行，必须建立测试程序与连接拓扑的绑定关系，测试程序只有绑定到连接拓扑中，才能使得所编写的测试程序与测试环境相连起来。一个测试程序只能绑定到一个连接拓扑中，测试程序绑定连接拓扑后，就说明该测试程序是针对怎样的测试环境进行的，实现了测试程序与测试环境分离，测试程序不再需要与测试环境紧密耦合在一个，而是通过这种绑定关系联系在一起。也就确保了测试程序能够运行在测试环境拓扑所对应的硬件设备中。

连接拓扑中包含了测试设备与被测件之间的连接关系，测试设备也就是这里看到的虚拟设备，在绘制图形时会指明该测试设备有哪些接口通道，通道的类型是什么样的。虚拟的测试设备需要将接口通道绑定到具体的硬件板卡上，硬件板卡通过与被测件相连，则建立了ETest与被测系统之间的通信与信号连接通道。

在利用ETest设计测试监控页面时，在监控页面中包含有面板、面板上有组件，监控界面需要绑定到测试用例数据上，绑定上之后监控界面就能具有测试项目的执行能力，因为测试用例数据又绑定在测试程序上。

在ETest中，设计了网络变量，用于在各个执行器之间或执行器与监控界面共享网络数据，网络变量的设计使得测试程序的开发不用考虑各个执行器之间的通信，通过网络变量巧妙地解决了多执行器分布式环境下变量定义的问题，在测试程序中可以如同测试程序中定义的变量一样使用网络变量，这极大地方便了多执行器之间的协同。

监控页面中的每个组件都会绑定一个网络变量，也会绑定一个动作响应函数，动作响应函数可传递网络变量作为响应参数，这样前端的监控页面就可以从组件中读取出网络变量值，并把网络变量值作为动作响应函数的参数值传递入响应函数中，在响应函数中就可以使用传入的网络变量了。响应函数是测试程序的一部分，在测试程序中既有界面组件的响应函数，也会有一些测试与仿真逻辑所需要的一些函数。

3.3绑定操作与关系分析

现在我们看看在ETest中实现如何这种绑定，测试程序绑定连接拓扑，如下操作是测试程序向连接拓扑的绑定。

以下操作是测试用例向测试程序的绑定。

而在测试的UI页面上，UI组件绑定测试用例中的网络变量、绑定测试脚本中的响应函数如下图。

测试UI页面与测试用例之间的绑定则通过执行配置实现。

下面我们分析一下测试用例、测试程序、页面、连接拓扑之间的绑定关系，如下图所示。

一个UI页面可以绑定多个用例，一个用例只能绑定一个程序，一个程序只能绑定一个连接拓扑。

关于UI页面的绑定对应关系，可以得到以下结论

（1）一个UI页面可以绑定多个用例

（2）一个UI页面可以绑定多个程序

（3）一个UI页面可以绑定多个连接拓扑

关于用例的绑定对应关系，可以得到如下结论：

（1）一个用例只能绑定一个程序

（2）一个用例只能绑定一个连接拓扑

（3）一个用例可以绑定多个UI页面

关于程序的绑定关系，可以得到如下结论：

（1）一个程序只能绑定一个连接拓扑

（2）一个程序可以绑定多个用例

（3）一个程序可以绑定多个UI页面

3.4UI页面的标准化设计

由于“设备A”与 “设备B”相连交互，各自展现的UI界面实际上是相同，因为无论是发送还是接收，都要按照字段解析显示在页面组件上，如下图所示。

这个页面设计，不考虑谁向谁发的问题，可以选择测试设备；如果选择了测试设备为“设备A”，则就是“设备A”向“设备B”发送报文，从“设备B”中接收数据；如果选择了测试设备为“设备B”，则就是“设备B”向“设备A”发送报文，从“设备A”中接收数据。

对于“设备A”作被测设备的需求来讲，需要这个UI页面；对于“设备B”作被测设备的需求来讲，也需要这个UI页面。

这个UI页面对于“设备A”与“设备B”之间传输的每条协议。均有组包、发送与解包、接收的操作，也具有使用“接收处理”自动从测试设备接收报文并显示的功能。

04

 ETest中的UI页面实现  

4.1UI页面设计的困境

3.4节中描述的UI页面显然可以用于“设备A”的测试，也可以用于“设备B”的测试。UI页面要用于“设备A”的测试就需要绑定“设备A”的连接拓扑，也需要绑定“设备B”的连接拓扑。

根据上一节的结论，在ETest中是支持这样做的。我们再进一步分析，就发现要这么支持，必然只能形成如下图所示的绑定关系。

要实现上述绑定关系所决定测试需求，自然我们就需要两套用例和程序，来使得UI支持对“设备A”和“设备B”的测试。

而我们知道，对于用例和程序来讲，如果以通信协议为中心，则无非就是协议的发送、接收和判断，以协议为中心来规划测试程序和测试程序，也比较自然，我们只有一套用例和程序，想要既支持对“设备A”的测试，也要支持对“设备A”的测试。按照上述绑定关系，显然是无法做到的，怎么办呢？

4.2解决途径

我们只有一套用例和程序，要实现出如下图所示的连接拓扑绑定关系。

自然就需要在UI页面上可以动态选定连接拓扑，因此我们专门在UI页面上放置了一个通用的面板，这个面板可以应用于所有的UI页面中，在该面板上具有测试设备的选择下拉框，选择测试设备后，执行“确定”按钮操作，如下图所示。

由于目前程序到连接拓扑的绑定为静态绑定，绑定后才下传到执行器进行绑定的解析。因此，我们在执行确定时，判断连接拓扑中是否允许这样的测试设备选择，如果选择的测试设备与连接拓扑不符，则提示“测试设备与测试环境不匹配”，需要重新选择，确保测试设备与测试环境匹配，如图所示。

当看到测试设备与测试环境不匹配的提示后，我们需要重新选择正确的测试设备。

通过上述途径，可以实现一套UI页面、一套测试程序、一套测试用例，测试系统中不同测试设备的功能。

4.3匹配的判定

在测试程序中，需要编写选择测试设备的响应函数，这个响应函数需要遍历环境拓扑中的devices集合，devices集合中包含当前连接拓扑中的全部测试设备描述对象，不包含被测设备对象，因此如果将被测设备设置为当前连接拓扑中的测试设备时，自然是无法在devices集合中找到的。见下面的响应函数Lua脚本。

注释掉的脚本语句中，不能直接使用被测设备devices.***.TaskManagerRS232，会导致执行器出错。

因此，我们遍历devices，用通道的名称与预制的设备通道名称进行匹配，匹配后将通道赋值给一个全局的通道对象TestDeviceRS232，在程序的所有处理函数中均用这个通道对象进行处理，这样就可以实现测试程序与通道对象的松耦合，有利于测试程序的复用和移植。

05

 最后启示 

使用ETest时，需要深刻地理解ETest中的绑定关系，为了实现更加通用化的测试程序、UI页面、测试用例，就需要利用好ETest中的绑定关系原理，简化测试设计工作。进一步，ETest在接口开放上，可以开放出更多的内部接口，用于在测试程序中使用，实现更加灵活的测试程序开发。对于ETest专业级的用户，则可以实现更加高级的应用。