嵌入式系统下如何提高单元测试有效性的分析研究

开篇：润墨网以专业的文秘视角，为您筛选了一篇嵌入式系统下如何提高单元测试有效性的分析研究范文，如需获取更多写作素材，在线客服老师一对一协助。欢迎您的阅读与分享！

摘要：有效的单元测试可以极大地提高软件质量，减少开发和维护阶段的工作量，同时也可以间接提高客户对产品的满意度。但是在嵌入式系统中，由于运行环境和测试工具有效性的限制，开发人员很难有效地实施单元测试，导致很多未经测试的代码直接进入产品，直接后果就是质量下降，降低产品的竞争力。该文引入了一种基于自动测试脚本的单元测试流程，实践证明该流程能有效提高软件质量，同时降低成本。

关键词：单元测试；嵌入式系统；自动测试工具

中图分类号：TP311 文献标识码：A 文章编号：1009-3044（2013）35-8113-03

近几年来，单元测试技术已被软件开发人员应用得十分广泛，研究表明该技术已经成为最流行的测试技术之一。随着测试标准的引入和测试技术的发展，测试操作可以通过测试脚本来实现。在一个项目中，测试脚本可以与测试用例相结合，测试用例则可以通过测试用例集来管理，这种方式贯穿于整个项目过程中，甚至可以在后续项目中重用。通过运行测试脚本可以得到代码覆盖率等数据，这些数据为改进测试用例提供了根据，并且可以指导开发工作。目前已有一些商用的测试工具，比如Visual Test， C++ Test，这些工具实现了单元测试框架。

然而，嵌入式系统的单元测试不同于桌面应用系统的单元测试，难度也更大。目前应用于嵌入式系统中的单元测试可分为两种：运行在目标机上的单元测试和运行在仿真环境下的单元测试。由于目标机中有实时中断、多任务调度等，因此它能为单元测试提供更为真实的测试环境，但同时它也需要开发人员花大量的时间搭建测试环境。而仿真环境下的单元测试主要用于测试系统功能，并且环境相对来说要容易搭建，但它的缺点是它需要随着软硬件的升级而不断的调整。

在嵌入式系统中，由于开发环境的限制，加上缺乏有效的单元测试工具，所以开发者很难进行全面和有效地执行单元测试，只能通过单步调试，断言等手工方式来做有限的单元测试，而且这些手工的单元测试方式没有合适的流程去管理，也没有进入和退出单元测试阶段的标准。

这篇文章提出了一种嵌入式系统下基于自动单元测试工具的单元测试框架。这个框架极大地改善了单元测试效率，主要体现在以下的四个方面：①功能选择策略②定义了单元测试的进入和退出标准③单元测试用例和单元测试用例集的管理④代码覆盖率分析。这种框架已经在基于Linux平台的手机应用Email项目中得到了应用，并发挥了很好的效果，极大的降低了开发成本、有效的缩短了项目开发周期。同时，客户的满意度也非常高。

1 传统的单元测试流程

1所示为传统开发过程中的单元测试流程。当代码准备好后，单元测试就开始了。首先，开发人员要设计测试用例，同时需要搭建测试环境，然后开发人员开始在不同的测试环境（目标机和仿真环境）中运行，并收集运行过程中的输出结果加以分析，以确定是不是所有的测试用例都通过。

由于嵌入式系统的特性，开发人员需要花费大量精力在搭建测试环境上，并且分析测试结果也需要花费很多时间。此外，开发人员也没有办法去评估单元测试的代码覆盖率，因此这种方式不能保证项目的质量。

另外，重用在软件项目开发中经常被使用，因为它能给项目带来很多益处，比较缩短开发周期，降低开发成本等。但是，在传统的单元测试中，开发人员无法重用测试用例，每一次重用都需要花费同样的时间和精力去重新测试。

从很多已经完成项目的历史数据来看，大约30%到40%的问题是属于逻辑问题，而这些问题应该是能在单元测试阶段就可以发现的。随着开发过程的进行，越在后面阶段发现问题，去解决这个问题需要花费的代价（时间和人力）就越大。而且一旦交付给客户后，如果再出现问题，可能需要付出召回等措施，这也会影响到产品的品牌。因此，一个有效的单元测试是非常必要的。

2 基于自动单元测试工具的测试框架

2.1基本框架

本文在传统的单元测试流程的基础上提出一种新的单元测试流程，如图2所示，它可以改善上文中所提到的传统测试流程的不足。新流程极大地提高了以下四个方面： ①定义了功能选择策略，利用最少的资源获得最好的质量；②定义了单元测试的进入和退出标准，把单元测试标准化。③提供了测试用例和测试用例集的管理机制，提高重用的能力。④引入了一个自动单元测试工具，以减少搭建环境和运行测试的代价。

在新的流程中增加了代码覆盖率。借助自动测试工具，在所有测试用例都运行完后，会得到一份关于代码覆盖率的报告，包括代码行覆盖率，路径覆盖率，分支覆盖率等。传统的测试流程只能得到一部分这样的数据，而且需要人工去统计。并且通过对测试用例的管理也实现了重用。

2.2测试功能选择策略

因为单元测试是一种代码逻辑驱动的测试方法，所以理解代码能够有效地进行单元测试。为了更好地进行单元测试，应该从代码分析开始着手，根据代码逻辑和实现来选择相应的测试功能并设计合理的代码覆盖率目标。

新的单元测试流程定义了进入和退出单元测试的标准。进入的基本标准是：代码已经经过团队的检查，一致认为可以开始单元测试。退出的标准包含三个方面：①所有的单元测试用例必须都已执行完毕；②单元测试期间发现的错误需要记录下来，并且与之相关的代码错误应该得到正确地修改；③单元测试报告中应该包含代码覆盖率，并达到之前设定的目标。

利用单元测试工具，可以采用测试脚本来描述测试行为。一个测试用例对应一个脚本，包括全局变量、临时变量以及测试对象所需的类的初始化信息。测试用例由相应的测试项目管理和保存。当代码发生改变，仅仅需要改变对应的测试用例以实现重用。

基于CppUnit框架的自动单元测试工具可以在目标机和仿真环境中运行，并提供了脚本语言的开发接口用于开发者编写可运行的测试用例和测试用例集以及基于代码覆盖率的分析结果。

3 有效性评估

在新的单元测试流程中，重点是测试用例的设计。通过设计更多的测试用例来达到更高的代码覆盖率，这会在很大程度上项目的质量，缩短项目周期。

通过对Email项目的实践应用，并对比同平台的其他项目的实际数据可以得到图3关于在不同开发阶段软件缺陷的分布图。在采用新流程的Email项目中，更多的问题在单元测试就被发现并解决，因而大大降低了开发成本，缩短了开发周期。

4 结束语

没有自动测试和代码覆盖率的数据，就没有办法保证单元测试是否有效。更重要的是现在的单元测试工具已经实现了重复测试，却还没有解决连续测试的问题。如果软件架构通过增量模式进行连续的调整，代码和测试用例就也需要同步进行调整。单元测试的趋势会从单一的静态测试发展为动态的连续测试。

本文提出的新的单元测试流程致力于提高软件项目质量，降低成本。通过使用自动单元测试工具和对传统单元测试流程四个方面的提高，新的单元测试流程有效的实现了上述目标。

虽然嵌入式系统是我们讨论的重点，但是新的单元测试流程也同样适用于普通平台的单元测试，差别只是选择不同的自动测试工具来满足不同的平台。

参考文献：

[1] C. Pacheco， M. D. Ernst. Eclat. Automatic generation and classification of test inputs. In Proc. 19th ECOOP， pages 504-527， July 2005.

[2] Torkar， R. & Mankefors， S. “A survey on testing and reuse”， SwSTE’03， November 2003.

[3] T. Xie and D. Notkin. Tool-assisted unit test selection based on operational violations. In Proc. 18th IEEE ASE， pages 40-48， 2003.

[4] M. Harder， J. Mellen， and M. D. Ernst. Improving test suites via operational abstraction. In Proc. 25th ICSE， pages 60-71， 2003.