基于嵌入式软件的自动化框架结构研究

李亚伟 万海涛

（北京赛迪软件测评工程技术中心有限公司 北京市 100048）

目前大部分软件开发环境都缺乏整合性的软件测试工具的辅助，或测试工具仅局限于程序中的特定部分，无法有较完整的测试管理提供一套软件测试的整合环境，嵌入式系统通常比一般桌面型电脑的软硬件的资源限制多，因此，在测试嵌入式软件时，测试者需花费更多的心力来测试及改进嵌入式软件的质量[1]。此外，传统的单元测试工具主要针对单一平台，并且使用人工输入或自动产生的方法产生测试用例及测试数据；但是自动产生测试用例的方法仍然需要加强，因为大多数的单元测试(unit test)工具都只会自动产生测试用例的程序框架，或只能支持原生的数据类型，使得测试工程师需要手动在产生的程序框架内编写测试代码及输入测试数据，人工产生测试用例[2]。然而，测试工作往往需要重复多次的测试动作，造成工作量的负担，且以手动输入测试数据进行测试既没有效率，对被测软件本身也是一种变更，容易出错，也很难提升测试的覆盖率[3]。在测试执行性能部分，测试工程师很难得知软件在嵌入式平台上实际执行的状况，所以执行性能测试也较为困难。为了降低嵌入式平台执行测试负荷及减少测试工程师的负担，本研究建构了一个支持交叉测试的自动化测试工具，其主要区分为功能性测试，包含单元测试、覆盖率测试，和并行程序的性能测试。

1 测试软件框架

1.1 系统整体框架

宿主机和目标机的测试框架是面向嵌入式系统设计的一种测试方法。在这个框架下，宿主机(Host)和目标机(Target)之间通过串行通信(Serial Communication)进行交互，利用开发板的JTAG(Joint Test Action Group)接口进行实时调试。该测试框架由以下几部分组成：

（1）联机调试：使用JTAG 接口将宿主机和目标机连接起来，进行联机调试。此时，目标机运行实际代码，而宿主机则控制测试过程并收集测试结果。

（2）异常处理：当测试过程中出现异常时，需要及时排查，找到问题所在，分析原因并进行修复。

（3）结果分析：分析测试结果，得出测试结论，并对测试程序进行优化和改进。

宿主机和目标机的测试框架具有高效、准确、可重复性强等特点，在嵌入式系统的开发和测试中得到广泛运用。

宿主机本文使用X86 平台，目标机为ARM11 MPCore平台。宿主机中本文使用的开源库包含了GCOV、Cppunit、Jfreechart、Pin tool、TBB。

1.2 系统核心算法

TBB pipeline 可以让使用者去决定并行化的程度，此为pipeline token 数，对于选择一个正确的pipeline token 数需要经验的累积，若所设定的token 数太小则会限制并行的程度，而token 数太大则会耗费不必要的资源[4]。一般若要找出最佳的pipeline token 数量，测试工程师需要多次手动修改pipeline token 的参数，对此我们提出自动建议一个合适的pipeline token 数量，节省使用者花费额外的时间在测试 pipeline 并行化的效率，并能更精准的提升并行程序的性能[5]。

测试工程师需先选取包含TBB pipeline 函数源代码，本研究将自动测试程序片段来获取性能信息，如图1 所示，包含了TBB 所提供的timer 来获取pipeline 程序执行时间及取代原程序pipeline 执行的参数(ppline.run(int))使其能代入自动产生的管道令牌号测试用例（pipeline token number test case），最后再借由宿主机-目标机机制来实现自动化测试。当程序执行完，在宿主机会显示出执行时间的分布图及CPU 每个核心的使用率，最后我们将会自动分析所收集的测试数据，提供测试工程师一个建议并行化门槛值范围，使pipeline 并行程序达到较好的性能[6]。

图1：测试代码至TBB 并行程序

经过我们多次的分析，我们发现测量token 数量对于程序执行时间的分布大都如图2 所示，因此我们以五个token 数为单位，计算其平均值，并找出一个建议的token 数范围，测量的token 数为1～10，我们取token 数1～5 执行时间的平均值为17.6 毫秒，token 数2～6 执行时间的平均值为12.4 毫秒，以此类推，当我们发现下一次的平均值大于目前的平均值(Token No. 4～8 的执行时间为12.4 毫秒大于Token No. 3～7 的执行时间为11.8 毫秒)，我们所建议的token 数为3～7。

图2：TBB 性能测量时间分布范例

2 测试软件验证

本实验将以TBB pipeline 实现图像处理程序，并使用4 个CPU core 执行，预处理的图像大小为128*128 像素，共执行10 种不同的图像处理主要工作为以不同的算法达到图像的边缘化(gradient、laplacian、Prewitt)、去噪音(smooth、median)、去除图像不连续的接点(erosion/dilation)、细线化(thinning)、旋转(rotation)及二值化(threshold)；在pipeline 中需循序处理的包含读取图像、输出图像，可并行处理的为gradient、laplacian、Prewitt、thinning、smooth、median、erosion、dilation、rotation、threshold，测量的stage 数量为1～12，在此我们去比较1～12 stage 的执行时间，并测量出一个建议的pipeline token 数[7]。

图3、表1 为1-12 个stage 分别输入1-12 个token数的执行时间，由此可以看出，当使用1 个stage 时效率最差，其次为使用2 个stage，且当 stage 的数量大于3 时，程序所执行的时间都是差不多的。

表1：TBB pipeline 1～12 stage 执行时间

图3：TBB pipeline 1 ～12 stage 性能测量

由于本实验其中包含图像的输入及输出，因此只使用1 个stage 及2 个stage 执行pipeline，为循序执行，导致执行的时间较慢，如图3，而其它stage 数执行的时间的差距不大，表2 为本实验针对 stage1 至stage12所建议的token 数。

表2：TBB pipeline 1～12 stage 建议的token 数

本文的实验结果说明了我们所开发的系统是可运作的，而且由于自动及半自动的产生测试数据，自动的产生测试用例及测试驱动的机制，且测试都以可视化界面表现测试结果，能方便并减轻使用者的负担。实验说明了在程序执行时可动态监控CPU 使用率，使得测试工程师容易得知软件在嵌入式板上执行的性能，更容易去改进软件性能，最后实验为测试 TBB 并行化的效率，让测试工程师得知一个建议的token 数，使得测试工程师不需花额外时间测试TBB pipeline 并行化的效率。

3 总结

本研究建构了一个支持嵌入式软件开发的自动化测试环境系统，此系统能根据分析源代码后的信息，能够产生测试用例、测试驱动及支持自动产生元类型，结构类型和对象类型的测试数据，但对于C/C++模板(template)类型、指标类型尚未完全支持。本系统能提供单元测试、覆盖测试及并行程序(TBB)性能测量及监控，测试结果也能以可视化图形显示。此外，我们在ARM11 的多核平台上做实际的测试，在实验中，我们针对C/C++数据结构范例程序进行测试，测试结果呈现我们所发展的系统是可运作的；实验为TBB pipeline 并行效率自动化测试，可使测试工程师不需花额外的时间手动输入测试数据来测试TBB pipeline 效率，利用我们所开发出来的系统，来减少测试的负担并增加测试的效率。