一种嵌入式信号处理软件构件测试框架

杨永国

摘要：为了缓解嵌入式信号处理软件构件人工测试的不足，设计一种自动化测试框架极为必要。基于此，本文从特征与主要流程入手，明确了嵌入式信号处理软件构件测试的内容，并依托三层体系架构完成嵌入式信号处理软件构件测试框架的设计，分析了测试框架中不同的功能单元。

关键词：嵌入式信号处理软件;构件测试;自动化测试

中图分类号：TP274.2 文献标识码：A 文章编号：1007-9416（2019）10-0184-02

0 引言

对于嵌入式系统来说，其主要被应用于特定的硬件设备上。由于有着更高的功能性与可靠性，因此在当前更加常用于雷达信号处理中。受到嵌入式系统自身特征的影响，对其展开测试工作具有较高的难度，传统的人工测试难以更好满足当前嵌入式系统的测试需求。以此，探究嵌入式系统自动化测试方法有着极高的现实价值。

1 嵌入式信号处理软件构件测试的简述

1.1 测试的特征分析

对于嵌入式信号处理软件构件测试来说，其特征主要如下：第一，在实际的测试中，必须要保证在实物板卡中展开。造这一情况的原因主要为多数硬件设备难以匹配上合适的模拟器，同时一些能够匹配上的模拟器无法满足实际要求的处理性能[1]。第二，软件单一测试中的测试数据量的最高可达到MB级。在这样的背景下，并不能直接展开测试数据值的直接输入，必须依赖仿真程序实现数据的产生。第三，硬件与测试的驱动程序必须维持在紧密耦合的状态。同时，测试的驱动程序必须要在与硬件库包交叉编译并形成可执行文件的条件下，才能够投入实际的运行。

1.2 测试的过程分析

在嵌入式信号处理软件构件测试的输入层面中，包含着待测构件、测试场景;在上位机层面中，包含着测试数据生成、预期结果生成、测试用例生成、结果验证、测试报告编写、测试结果上传等等，主要实现了对测试的设计、用例的生成与比较;在硬件设备层面，主要实现了测试过程的执行，并在网口的支持下与上位机层面实现连接。

对于嵌入式信号处理软件构件测试来说，其主要流程如下所示：依托待测构件的实际情况完成用例场景的测试，在形成测试输入数据、预期输出结果后，实现测试用例的生成;在测试用例的支持下展开测试驱动的编写，并在交叉编译后直接下载到硬件运行层面;测试完成后输出结果，并对比前期产生的预期输出，实现测试结果的形成与确认;依托测试结果输出嵌入式信号处理软件构件的测试报告。

2 嵌入式信号处理软件构件测试的框架设计

2.1 总体测试框架设计

在本研究中，主要使用三层体系架构完成嵌入式信号处理软件构件测试框架的设计。其中，主要将测试框架划分为数据访问层、业务逻辑层以及表示层[2]。在该测试框架的数据访问层中，包含着数据库的访问接口（与数据库进行连接）以及硬件通信接口（与硬件设备进行连接），主要与数据库、硬件设备建立起交互的关系，在相应接口的支持下，完成数据的上传与提取。在本测试框架的业务逻辑层中，包含着数据产生、测试执行以及结果验证单元，主要实现了预期结果、测试用例输入数据的生成。同时，在前期设置的测试步骤的支持下，实现驱动代码的生成，并交叉编译至硬件设备中展开运行。业务逻辑层还能够实现测试结果的接收，并在此基础上验证测试结果的正确性。对于本测试框架的表示层来说，包含着测试用例、测试报告以及系统日志单元，主要为用户提供了人机交互界面、数据输入与输出的接口。此时，用户可以完成测试用例的导入、下载测试结果，与此同时，还能够在实际的测试中展开测试过记录的实时性查询。

2.2 测试框架的具体单元设计

2.2.1 驱动调用单元

对测试执行过程展开描述的代码为测试驱动代码，其中，最为简单、常见的测试驱动代码为待测试构件的调用函数。对于嵌入式信号处理软件来说，其测试驱动的内容一般为固定内容，包括测试输入数据的载入、待测构件执行的调用、构件输出数据的保存。然而，上述操作内容均需要硬件地层函数的支持，因此在传统的嵌入式信号处理软件构件测试中更多的使用了人工编程的方法。

针对这一情况，在本次构件测试框架的驱动调用单元设计中，主要引入了一种自动生成测试驱动代码的方法。为了实现这一目标，需要依托不同的硬件平台完成硬件库、基础驱动程序模板的打包，并转化成基础镜像。在此基础上，引入了加载参数以及被调构件信息，并将其视为配置纳入驱动中。此时。测试框架可以依托硬件平台的不同类型，直接在基础鏡像库中提取与硬件平台相对应的驱动镜像，实现配置文件的生成。

2.2.2 数据产生单元

对于数据产生单元来说，主要实现了输入硬件设备中测试数据的生成，并为测试结果与预期结果的对比提供支持。由于上述两项功能的实现均需要仿真程序生成数据的支持，因此，在本单元设计主要因进入了测试用力表的解析，完成对仿真程序、相关参数的获取，最终实现测试数据的批量产生。

2.2.3 结果验证单元

在结果验证单元中，主要实现了测试用例表中的预期数据、实测结果的计算，并在此基础上形成测试结果，为后续嵌入式信号处理软件构件测试结果报告的生成提供支持。

2.2.4 报告编写单元

在报告编写单元中，包含着的标准的测试结果输出模板及文本转换工具，例如T4工具箱、mlreportgen库等等。该单元能够结合用户的实际选择完成文本模式的转换，并自动融入测试报告的编写中，最终生成标准的测试报告。

2.2.5 日志单元

对于该测试框架中的日志单元来说，主要实现了整个嵌入式信号处理软件构件测试过程的监控，并完成测试信息的保存，为用户排查测试问题提供了有力支撑。在日志单元的实际运行中，会对硬件设备、测试代理以及测试业务展开重点监测。其中，对硬件设备的监控需要依托硬件设备中额外设置的监控线路完成。在监控测试代理中，主要依托自动化测试工具检查点产生的检测结果完成。在监控测试业务中，主要利用了不同单元关键点的插桩所反馈的实时状态信息完成。

2.2.6 测试代理单元

测试框架与底层软硬件的接口为测试代理，该单元主要完成了访问数据库、下载数据、控制硬件设备上传数据等功能。在测试脚本的支持下，测试代理单元实现了与硬件设备的连接。在本测试框架中，主要使用了QTP脚本录制功能，控制上位机完成硬件设备中FTP的访问，最终完成清理、上传与下载数据。

在测试代理单元中，包含着能够连接数据库的标准接口，对测试业务访问数据库的实现提供支持。此时，测试驱动能够结合实际需求完成基础镜像库及报告模板的调取。

3 结语

综上所述，为了更好满足当前嵌入式系统的测试需求，设计一种嵌入式系统自动化测试方法极为必要。依托三层体系架构，实现了嵌入式信号处理软件构件测试框架的设计。在驱动调用单元、数据产生单元、结果验证单元、报告编写单元、日志单元、测试代理单元的支持下，该测试框架的可行性更高，且实现了对嵌入式系统的自动化分析，弥补了传统人工测试的不足。

参考文献

[1] 程知敬，张晋文，刘凤.一种嵌入式信号处理软件构件测试框架[J].现代雷达，2019，41（06）：82-85.

[2] 杨光.基于FPGA的嵌入式信号采集与显示系统的设计[J].电子技术与软件工程，2016（16）：200-201.