%A
%A 1 概述
%A
%A 软件测试是很广的概念。从其贯穿软件生命周期全过程来看，测试可分为模块测试、集成测试、系统测试等阶段。测试还可分为静态检查和动态运行测试两大类。在动态运行测试中，又可有基于程序结构的白盒测试（或称为覆盖测试）和基于功能的黑盒测试。测试不仅关注程序的功能，还有性有测试、强度测试等等。
%A
%A 要达到比较好的测试效果，除了要有周全的测试计划、可控的测试过程、测试人员丰富的经验外，还需要借助一些行之有效的辅助工具，尤其在当今软件规模日益庞大、测试工作量成倍增加的情况下。对应上述的测试分类情况，测试工具可划分为：支持对程序源代码进行静态规则检查和质量评估的静态分析工具、支持对程序单元进行动态覆盖测试的工具、对软件系统的整体运行性能进行测试的工具。另外，还有一些特殊用途的或专用工具，如协议测试仪、内存检测工具等。这些工具都有较为成熟的商业化产品，也可通过自行开发的方式获得。
%A
%A 本文具体讨论了对一类特殊的系统软件――嵌入式实时操作系统――进行覆盖测试的情况。内容涉及对这类软件特性的研究、测试的难点和特点、对现有测试工具的适应性改造和测试实例说明。
%A
%A 2 软件覆盖测试
%A
%A 覆盖是一种白盒测试方法，测试人员必须拥有程序的规格说明和程序清单，以程序的内部结构为基础，来设计测试案例。其基本准则是则测试案例来尽可能多地覆盖程序的内部逻辑结构，发现其中的错误和问题。所以，覆盖测试一般应用在软件测试的早期，即单元测试阶段。
%A
%A 覆盖的几种方法或策略如表1所列。
%A
%A 表1 几种典型的覆盖策略
%A 覆盖策略         定 义
%A 语句覆盖         在制定测试案例时，使程序中的每个语句都至少执行1次。其缺点是不能发现某些逻辑错误
%A 判定覆盖         执行足够的测试案例，使得程序中每个判定都获得一次“真”值和“假”值，或者说使每一个分支都至少通过1次
%A 条件覆盖         执行足够的测试案例，使得判定中的每个条件获得各种可能的结果
%A 判定/条件覆盖         执行足够的测试案例，使得判定中的每个条件取得各种可能的值，并使得每个判定取得各种可能的结果
%A 条件组合覆盖         执行足够的测试案例，使得每个判定中的条件的各种组合都至少出现1次。其特点是覆盖较充分，满足条件组合覆盖的测试案例也一定满足判定覆盖、条件覆盖和判定/条件覆盖。
%A
%A 从以上简要介绍可看出，这几种覆盖策略的严格程序有如下趋势：
%A
%A 其它一些覆盖策略还包括：修改的条件/判断覆盖（通常简称为MCDC）、路径覆盖、函数覆盖、调用覆盖、线性代码顺序和跳转覆盖、数据流覆盖、目标代码分支覆盖、循环覆盖、关系操作符覆盖等。随着软件规模的增长，实现全面的覆盖所需的测试案例的数目也越来越庞大，因此根据被测软件对象的特点选择适当的覆盖策略是非常重要的；同时，要确定合理测试目标，达到100%的覆盖往往要付出很大的代价，应该同形式化评审等方法结合，以发现更多的软件故障。
%A
%A 3 覆盖测试工具
%A
%A 要取得较好的覆盖测试效果，需要借助一定的工具软件。这些工具软件一般具备如下的功能特点，可弥补人为测试的缺陷：
%A
%A ①分析软件内部结构，帮助制定覆盖策略及设计测试案例；
%A
%A ②与适当的编译器结合，对被测软件实施自动插装，以便在其运行过程中生成覆盖信息并收集这些信息；
%A
%A ③根据搜集的覆盖信息计算覆盖率，帮助测试人员找到未被覆盖的软件部位，以改进测试案例提高覆盖率。
%A
%A 在利用工具进行动态覆盖测试时，需要3个要素：测试用例、插装过的被测代码、搜集覆盖信息并进行分析的工具本身。代码插装由工具自动完成，通过执行测试用例，再由工具搜集覆盖信息并进行分析，就可以看到覆盖率指标了。图1展示实现覆盖测试的基本过程。
%A 4 嵌入式软件的覆盖测试原理
%A
%A 嵌入式软件的开发与通用软件很大的不同点在于，需要采用交叉开发的方式：开发工具运行在软硬件配置丰富的宿主机上，而嵌入式应用程序运行在软硬件资源相对缺乏的目标机上。对于这类软件的测试也存在着同样的问题：测试工具运行在宿主机上，测试所需要的信息在目标机上产生，并通过一定的物理/逻辑连接传输到缩主机上，由测试工具接收。因此，嵌入式软件测试的一个重要问题是建立宿主机与目标机之间的物理/逻辑连接，解决数据信息的传输问题。
%A
%A 嵌入式软件覆盖测试的基本原理如图2所示。
%A
%A 在目标机方，插装过的被测应用程序将覆盖信息发送到消息队列中，一个专门的任务负责在适当的时候将这些信息发送到宿主机方。缩主机方有专门的模块负责接收覆盖信息。并交给分析工具分析和在线动态显示覆盖率的增长情况。
%A
%A 支持嵌入式软件覆盖测试的工具应解决如下2方面的关键问题：
%A
%A *与嵌入式操作系统的结合覆盖测试工具与嵌入式操作系统的结合体现在3方面。首先，在目标机方，应用任务与专门负责收集/上传覆盖信息的任务是通过消息队列来传递数据的，该消息队列可使用嵌入式操作系统的相应机制实现。其次，这个专门任务也可以被看作一个特殊的应用任务，也必须有嵌入式操作系统的支持，因为任务管理是后者的基本功能之一。最后，目标机与宿主机之间的通信可以采用串口或以太网方式，对串口的驱动或网络协议均可使用嵌入式操作系统的相应程序组件。
%A
%A *与其它嵌入式交叉开发工具的关系
%A
%A 嵌入式应用程序的开发通常采用交叉开发方式，几乎所有的开发工具均要解决3部分的问题：宿主机部分的功能、目标机部分的功能、宿主机与目标机的连接问题。其中，宿主机与目标机的连接是个瓶颈，如果不同的工具要使用同一物理线路实现数据传输，则要解决对该物理线路（或者说硬件端口）的正确共享。比如在图3所示的环境中，宿主机方的各种工具通过统一的接口 ――目标服务器（target server）实现对通信线路的访问，目标机方的调试代理（debug agent）则是各种信息（调试信息、覆盖信息、时间信息、对象信息等）的收集与传递的核心。
%A
%A 5 Logiscope在嵌入式操作系统DeltaCORE测试中的应用
%A
%A Logiscope是Verilog公司的CASE产品，对软件的编码、测试、维护提供多方面的服务，并且支持嵌入式软件的覆盖测试。
%A
%A 5.1 测试前的准备
%A
%A 测试前的准备即为支持对DeltaCORE的测试所做的移植工作。
%A
%A 目前，Logiscope已经为一些成熟的商用嵌入式操作系统提供了支持，比如pSOS。DeltaCORE是我国自主开发的嵌入式强实时操作系统内核，为了利用Logiscope实现对 DeltaCORE的应用程序乃至DeltaCORE本身的测试，我们主要解决了第4节中描述的第1个关键问题。为了支持嵌入式程序的测试，Logiscope提供了运行在目标机方的程序代码（或称为目标机端的支持库），里面包含了：
%A
%A *1个用来收集和发送覆盖信息的主循环线程，该线程即是嵌入式应用中的特殊任务；
%A
%A *实现具体数据传输的函数，包括对串口或网络的驱动，它们将被上述线程调用；
%A
%A *插装函数的实现，这些函数被被测代码调用，向缓冲中放入覆盖消息块；
%A
%A *对缓冲信息队列的管理；
%A
%A *初始化代码。
%A
%A 例如，当被测程序运行进入到一条if(……)语句时，整个过程如图4所示。
%A
%A 为了支持对DeltaCORE的测试，将与这些机制相关的代码进行移植，包括以下几方面：
%A
%A *将收集和发送覆盖信息的主循环线程作为在目标机端运行的应用程序中的特殊任务；
%A
%A *对串口的驱动采用LambdaTOOL BSP（板级支持包）中的串口驱动代替，对网络的驱动，用DeltaCORE的配套组件DeltaNET中的驱动程序实现；
%A
%A *利用DeltaCORE的信箱机制实现消息队列的创建和管理，插装代码向这些信箱发送覆盖消息块；
%A
%A *在DetaCORE应用程序的根任务中调用Logiscope的初始化函数，达到创建特殊任务信箱的目的。
%A
%A 开发DeltaCORE应用程序时，我们使用了其配套开发工具LambdaTOOL。由于所使用的工具版本没有实现目标服务器（target server）的调试方式，因此对物理端口的使用采用的独占方式，即调试工具不能与其它工具共享同一端口。我们可以用网络试上载并启动目标应用程序，而通过串口传送覆盖信息。
%A
%A 5.2 对DeltaCORE的覆盖测试过程及结果
%A
%A 对于函数内部，Logiscope支持的覆盖策略有：
%A
%A *指令块IBs(Instruction Blocks)
%A
%A *判断到判断的路径DDPs(Decision-to-Decision Paths)
%A
%A *MCDC（Modified Condition/Decision）
%A
%A 在项目层次上支持的覆盖策略是：
%A
%A *过程到过程路径PPP（Procedure-to-Procedure Path）
%A
%A 在DeltaCORE的测试中，我们采用了较为常用的覆盖策略――判断到判断的路径，其含义是：DDP是一个指令序列，它的起点是函数或判断（if，while，……）的入口点，它的出口是下一个函数或判断的退出点，之间不能再有判断，比如在图5中包含了5个DDPs：
%A
%A 测试的具体过程是：
%A
%A ①利用插装分析器对DeltaCORE的源代码进行插装，并生成插装信息文件。
%A
%A ②将移植后的Logiscope目标机端程序与插装后的内核源代码一同编译链接成库，以替代原来的内核库，供应用程序使用。
%A
%A ③编写测试案例，从实现应用的角度使用DeltaCORE的各种系统功能调用，力求遍历内核函数所有的判定分支，并将这些案例编译成可执行程序。
%A
%A ④在宿主机端启动覆盖信息收集和分析程序，用LambdaTOOL的调试器下载并启动应用程序。DeltaCORE的覆盖信息被传递到宿主机上，分析程序动态显示覆盖率的增长情况，并将这些信息记录在一个文件中。
%A
%A ⑤应用程序执行完毕后，启动Logiscope的事后分析工具，将覆盖信息记录文件与插装信息文件（在源代码插装在生成的附属文件）进行比较，帮助测试人员清晰地了解每个被测函数内部的路径覆盖情况，借此可为测试案例的改进提供帮助。
%A
%A ⑥测试人员修改测试案例，并重新进行整个测试过程；各项测试的结果可以叠加，覆盖率将得到增长。
%A
%A 经过2个多月的时间，我们对DeltaCORE 1.1版本79个文件共计115个函数进行了覆盖测试，覆盖率已经达到了70.55%。编写测试用例89个，主要的60个API函数均已获得较高的覆盖，覆盖率达100%的约占51.3%。
%A
%A 6 小结
%A
%A 我们借助Logiscope工具对嵌入式实时操作系统DeltaCORE进行了覆盖测试，达到了较好的覆盖率；发现并处理了一些缺陷，提高了软件的质量和可靠性，但同时也存在不足之处：
%A
%A ①测试应好好规划，包括测试顺序的选择、测试案例的设计、测试文档的管理等等。
%A
%A ②由于该测试手段依赖于操作系统的有关机制，而被测对象又是操作系统本身，因此与这些机制有关的部分代码未被插装和测试，否则就会出错。比如，操作系统的初始化函数os_init，在这个函数运行完毕之前，操作系统的相应机制尚未建立起来，因此对它进行插装就会造成问题，不能正确地得到覆盖信息。又比如，出于效率方面的考虑，与系统时钟相关的部分函数未被插装，因为在程序运行过程中，时钟是最频繁产生的一种外部事件，如果插装，就会产生大量的覆盖信息，会对信息缓存、传递、收集和处理造成压力。另外，所用的工具不支持对汇编函数的插装和测试。综合上述各种原因，DeltaCORE 1.1的总体覆盖率还显得比较低，需要采用其它的方法来提高它。对于非操作系统组件及应用的测试，由于不存在操作系统本身的问题，因此可望达到较高的覆盖率。
%A
%A ③该方法不能用于时间性能测试。因此它属于纯软件的测试方式，大量数据信息的产生、传递与收集对被测程序的干扰大，只能做白盒性的功能结构验证。如果做性能测试，应采用某些软硬结合方式的工具，比如CodeTEST。
%A
%A 对嵌入式软件产品的测试是多方面的，除覆盖测试外，还有时间性能测试、内存使用测试与分析等，也是我们研究的重要课题。
%A