1、软件测试计划与测试用例在嵌入系统中的应用 X黄清清 1) ,2) 许宏斌 1)(西安交通大学电信学院 1) 西安 710049) (上海船舶电子设备研究所 2) 上海 200025)摘 要 :软件测试计划和测试用例是软件系统测试的重要环节 ,嵌入系统的特色对测试计划和测试用例提出了新的要求。介绍了嵌入系统的特点及其对测试技术和测试用例的影响 ,对相关树模型和测试技术在嵌入系统中的应用进行了详细的描述。关键词 :嵌入系统 ;测试用例 ;测试技术 ;相关树模型中图分类号 : TP31Applications of Test Plan and Test Case in Embedded System
2、sHuang qingqing1) ,2) Xu hongbin1)(Xi an Jiao - tong University1) , Xi an 710049)(Shanghai Marine Electronic Equipment Research Institute2) ,Shanghai 200025)Abstract :Test plan and test case play a key role in software system testing. The characteristics of embedded systems have aspecial effect on s
3、oftware test sectors. Thispaper describes how embedded systems affect testing process and technologies. Furthermore , dependency tree model and applications of testing techniques in embedded systems are studied in detail.Key words :embedded system , test case , test technology , dependency tree mode
4、lClass number :TP311 引言软件测试是软件生存期中的一个重要环节 ,是依据被试软件系统的研制任务书和技术规格书 ,在软件投入运行前 ,对软件整体功能和性能的综合测试与评估 ,是软件质量保证的基础。而嵌入式实时系统所具有的主机 目标机环境 ,为软件测试带来了复杂性 ,并提出了更高的要求。本文就软件测试方法、测试用例及其在嵌入系统中的应用 ,提出有益的探讨。2 测试周期与测试方法传统的软件测试策略 ,往往将软件测试定位在软件开发的最后阶段 ,即遵循所谓的瀑布模型 ,直接反映了对软件测试的重视程度不够 ,如图 1 (A)所示。其缺点是显而易见的 ,尤其对出现了面向对象和多线程设计方
5、法的今天 ,更显得力不从心。现代的软件测试策略 ,则采用双 V 模型 1 ,如图 1(B)所示 ,体现了软件测试的重要地位 ,它贯穿了软件开发的全过程。在双 V 模型中 ,首先 ,根据用户对软件系统的功能需求 ,定义并完善测试需求 ,作为整个测试的标准 ;其次 ,在测试计划阶段 ,通过收集并组织测试计划信息 ,将软件西化为可检验的测试需求 ,最终建立测试计划 ,其测试考虑的内容主要包括 :功能测试、性能测试、用户界面、疲劳测试、可靠性测试、安全测试、移植测试及恢复测试等 ;第三 ,在测试设计阶段 ,要确定测试过程 ,并选择适当的测试用例 ,将组织测试过程信息传递给测试开发人员 ;最后 ,在测试
6、开发与测试执行阶段 ,通过开发可重复使用的自动测试 ,维护测试过程中对缺陷的跟踪 ,利用单元测试、集成测试、系统测试及回归测试等技术 ,最终实现对测试结果的分析和评估。95总第 145 期2005 年第 1 期 舰 船 电 子 工 程Ship Electronic Engineering Vol. 25 No. 1X 收稿日期 :2004 年 4 月 14 日 ,修回日期 :2004 年 5 月 13 日 1995-2005 Tsinghua Tongfang Optical Disc Co., Ltd. All rights reserved.图 1 软件测试模型3 测试计划与测试用例3.
7、1 测试计划为了使软件测试系统化 ,让所有参与人员和单位之间具有共同的认知 ,制定一个好的测试计划就变得非常重要了。测试计划一般有三种模式 ,即 :单一测试计划 ( Simple Test Plan) 、框架测试计划(Master Test Plan) 及详细测试计划 (Detail TestPlan) 。所谓单一测试计划 ,就是将测试计划的所有相关内容 ,都记录在同一文件中。其优点是便于管理。但对于由多人或多个单位联合开发的软件系统而言 ,其内容的高度集中 ,就显得非常复杂了。框架测试计划与详细测试计划的结合 ,就非常适合大型软件的开发环境。框架测试计划对软件测试进行阶段划分 ,并对各阶段测
8、试目标和策略进行规定 ;而详细测试计划则对每阶段的测试内容和方法进行详细的描述。ANSI/ IEEE 829 对测试计划的内容进行了标准的定义 ,主要包括如下 16 个方面 :测试计划标识 一个唯一的标识符号测试计划简介 测试条目和功能、各条目的历史记录、与其它相关文件和测试计划的关联等测试条目 测试条目及其版本、与其它相关文件 (需求规范、设计规范、用户指南、操作指南、安装指南 )和缺陷报告的关联等被测试功能 软件所有功能、相关功能的组合及其与测试设计规范关联不被测试的功能 不测试的所有功能及其组合、不测试的原因采用的测试方法 测试方法概述、与功能和功能组合相关的特定测试方法、测试的限制条件
9、(测试环境和测试期限 )等条目测试通过或失败的标准测试中断和恢复测试的标准测试结束所要提交的文档 测试计划、测试设计、测试用例、测试过程、测试条目传送报告、测试记录、测试总结报告、测试工具等测试准备工作 为准备测试和执行测试所必须的准备工作、需要的特殊技能等环境因素 硬件环境、通信环境、软件环境、测试工具、安全性要求等责任划分 负责管理、设计、准备、执行、监控、检查、问题解决的相关人员和工作组参与人员与培训计划 参与人员必须具备的技能、培训计划等测试日程表潜在的问题和风险测试计划的审核 审核人的名字和职务、签名、日期3. 2 测试用例设计测试用例就是针对特定功能或组合功能设计测试方案 ,并编写
10、成文档。测试用例的选择既要有一般情况 ,也应有极限情况以及最大和最小的边界值情况。因为测试的目的是暴露应用软件中隐藏的缺陷 ,所以在设计选取测试用例和数据时要考虑那些易于发现缺陷的测试用例和数据 ,结合复杂的运行环境 ,在所有可能的输入条件和输出条件中确定测试数据 ,来检查应用软件是否都能产生正确的输出。一个典型的测试用例应该包括下列详细信息 :测试用例标识 一个唯一的标识号测试用例描述 对测试用例进行简单的06 黄清清等 :软件测试计划与测试用例在嵌入系统中的应用 总第 145 期 1995-2005 Tsinghua Tongfang Optical Disc Co., Ltd. All
11、rights reserved.说明修改记录 对该测试用例的建立和修改进行记录 (日期和人名等 )被测试功能测试环境与条件测试用例的执行 对执行步骤的详细描述测试输入期待的结果 对被测试功能的期待结果实际的结果 通过或失败、对实际结果的详细描述测试结果评估当测试用例对多个期待结果进行测试时 ,它就会变得非常复杂。一个好的测试用例应该具有如下特点 :有效地发现被测系统的缺陷无二义性复杂度适中在确定测试用例集时 ,对测试用例进行可理解、规范化的描述就显得非常重要了 ,统一模型语言 (UML) 是常用的规范语言。此外 ,为了优化测试用例集 ,相关树 (Dependency Tree) 模型是个较好的
12、方法 ,下一节再做详细介绍。4 测试技术在嵌入系统中的应用4. 1 嵌入系统的特点嵌入系统存在于我们日常生活中无所不在的“智能设备”中 :手中的移动电话、无线基础网络、掌上电脑、传递电子邮件的互联网路由器、家庭影院系统、航空控制中心及其监控的飞机等 ,这些设施价值的百分之九十体现在其软件。大多数嵌入系统多是“实时的” (“实时的”与“嵌入的”通常可交换使用 ) 。一个实时系统 ,其操作的正确性不仅体现在其逻辑操作的正确性 ,而且体现在是否在规定时间内完成操作。如果时间约束不能被满足 ,系统失败就出现了。对某些安全性要求极高的系统而言 ,失败是不可接受的。因此 ,对嵌入系统来说 ,时间约束测试与
13、功能测试同样重要。尽管嵌入系统测试规程与其它应用的测试有类似之处 ,但仍具有其固有的特色。如 :开发平台与应用平台分离应用平台繁多 ,导致众多的交叉开发环境广泛的应用体系结构、多种实施用例并存应用平台受资源和响应时间的约束此外 ,嵌入系统的实时操作系统一般包括以下基本模块 :初始化管理、任务管理、时间管理、定时管理、中断管理、任务间的通信 / 同步 / 互斥管理及内存管理等。这些问题对嵌入系统的测试有很大影响 ,也说明了为什么嵌入系统的测试是非常困难的 ,仍然是目前该行业的难点之一。最近研究 R1 表明 ,超过 50 %的嵌入系统开发项目比计划延迟数月 ;仅44 %的设计满足了既定功能和性能的
14、 20 % ;超过50 %的开发精力花费在测试上。4. 2 嵌入系统的测试方法嵌入式操作系统的测试一般有两种方案 :插桩 (stub)在目标操作系统和测试程序内分别加入某些功能模块 ,二者互通信息来进行测试。这一方案的实质是用软件接管目标系统的全部异常处理 (ex2ception handler)及部分中断处理 ,在其中插入调试端口通信模块 ,与主机的调试器交互。片上调试 (On Chip Debugging)及 EmbeddedPowerPC Background Debug Mode 片上调试是在处理器内部嵌入额外的控制模块 ,当满足了一定的触发条件时进入某种特殊状态。在该状态下 ,测试程
15、序停止运行 ,主机的调试器可以通过处理器外部特设的通信接口访问各种资源 (寄存器、存储器等 ) 并执行指令。 EPBDM 的运作相当于用处理器内嵌的调试模块接管中断及异常处理。4. 3 一个通用的嵌入系统测试用例4. 3. 1 被测试颗粒与测控点任何测试首先要做的是确定其测试颗粒( GuT) 。颗粒度非常好地表示了不同规模的测试元素 ,从简单的一行代码到复杂的分布系统。这一步包含了利用桩函数或适配器将被测颗粒与其环境进行隔离。桩函数是对颗粒与其环境间双向交互进行仿真的一段代码程序。然后 ,建立测试驱动 ,它仿真被测试颗粒的输入和获取其相应的输出 ,并与既定的响应结果进行比较。适配器使得GuT
16、可以被测试驱动激励。激励与检测都遵循 GuT 的指定门径 ,即所谓测控点 ( PCO) 。测控点可以在 GuT 的边界 ,也可以在 GuT 的部。下面列出一个 C 函数颗粒的测控点的例子 :观测点在颗粒内 函数某特定代码行的覆盖观测点在颗粒边界 函数返回的参数162005 年第 1 期 舰 船 电 子 工 程 1995-2005 Tsinghua Tongfang Optical Disc Co., Ltd. All rights reserved.控制点在颗粒内 局部变量的改变控制点在颗粒边界 具有真实参数的函数调用4. 3. 2 测试用例描述描述一个测试用例 ,至少必须确定以下两点 :相应
17、的测控点 这取决于测试的目的 ,例如 ,功能测试、结构测试及负荷测试等。测试方法 发送什么信息或输入参数、期待的输出及其事件顺序、采用的测试手段 (白箱测试或黑箱测试 )等。4. 3. 3 启动并执行测试用例完成对测试用例的描述后 ,接下来就要将测试案例转换并集成为测试驱动和桩函数。这个过程可以通过人工编程实现 ,也可以利用自动测试工具完成。执行测试用例时 ,通过观测点对测试结果进行监测。当观测点在被测颗粒边界时 ,典型的观测信息包括 :函数返回的参数或接收到的消息、全局变量的值及信息的顺序和时间等 ;当观测点在被测颗粒内部时 ,典型的观测信息包括 :原代码覆盖率、已执行的逻辑分支的控制路由、
18、 GuT 各部分之间不同时刻信息交换的信息流程及资源使用情况 (如GuT 各部分花费的时间、管理的内存池及处理性能 )等。4. 3. 4 对嵌入系统测试的步骤建议根据 GuT 的类型和测试目标 ,如 :功能测试、性能测试及可靠性测试等 ,以下六个测试阶段是完全必要的 :单元测试、集成测试、确认测试、系统单元测试、系统集成测试及系统确认测试。单元测试 此时的 GuT 可以是一个隔离的 C 函数或一个隔离的 C + + 类。根据 GuT 的目的 ,测试用例一般包括 :对函数的参数值进行大范围应用的精确数据测试和事件序列的情景测试。观测点就是返回的参数值、对象特征评估及原代码覆盖等。白箱测试方法常用
19、于单元测试 ,这也意味着测试人员必须对 GuT 的内涵非常了解。所以 ,单元测试应该是开发者的责任。集成测试 该阶段的 GuT 是一个函数集或一个类族。集成测试的主要目的是验证接口。这里采用与单元测试相同的控制点 (精确数据处理的主函数调用或方法遍历序列 ) ,而观测点则注重各基本颗粒间信息交互的流程。该阶段仍采用白箱测试 ,因此 ,软件集成测试也是开发人员的责任。确认测试 GuT 是组件中所有的用户代码。这是软件集成测试的最后一步 ,使用的测试用例是模仿最终用户的情景而与内部的实施细节无关。观测点包括对资源利用的评估 ,因为 GuT 是整个系统的一个重要部分。同样 ,该阶段仍采用白箱测试 ,
20、软件确认测试仍是开发人员的责任。系统单元测试 GuT 是系统的所有组件 ,包括确认测试阶段的用户代码以及所有与实时操作系统 (RTOS)和平台相关的部分。如 :任务管理机制、通信及中断等。控制点协议已不再是函数调用或方法遍历 ,而是利用 RTOS 消息队列进行的消息发送 / 接收。从现在开始 ,测试用例通常可以 :将 GuT 置于需要的初始状态、按序列生成消息案例、通过与 (1)期待消息以及 (2)时间约束的比较实现对接收消息的确认。黑箱测试在该阶段将被采用 ,只要求对 GuT 的接口进行充分的了解。根据组织结构 ,系统单元测试或是开发人员的义务 ,或是专门的系统集成部门的义务。系统集成测试
21、此时 , GuT 可以是单个节点的一组组件 ,或系统中所有节点 ,甚至一组分布式的节点。观控点是 RTOS 与网络通信协议的混合 ,如 :RTOS 事件和网络消息等。对于系统集成而言 ,重点是对各种接口的确认。通常采用黑箱测试方法 ,是系统集成部门的义务。系统确认测试 GuT 是完整的嵌入系统。该阶段的目标主要包括如下几个 :满足终端用户的功能需求、进行最后的非功能测试 (如 :负荷与强壮性测试 ) 、保证与其它连接设备的互操作性等。常采用黑箱测试方法。测试人员应将重点放在经常出现和危害性大的用例上。4. 4 相关树 (Dependency Tree)模型为了有效地组织测试用例集 ,实现对软件
22、系统的测试 ,相关树模型是个很好的辅助手段。相关树模型的目的就是在相同的测试环境和测试环境的各个阶段 ,充分利用阶段性的硬件和软件环境 ,对测试用例进行完全的执行 ,达到快速、可重复的测试用例执行和测试结果监测。图 2 是以对交换设备为例的测试用例集相关树模型。利用相关树模型 ,可以使多个测试用例在相同的阶段性测试环境下 ,进行重复的执行。如在路由交换的阶段性测试环境下 ,测试用例 1、测试用例 2及测试用例 3 都可以在相同的路由交换测试阶段 ,利用同样的测试环境 ,分别重复性地进行测试用例执行。相关树模型带来的好处主要有 :将多个测试用例或情景关联在同一个节点(测试环境 )下。26 黄清清
23、等 :软件测试计划与测试用例在嵌入系统中的应用 总第 145 期 1995-2005 Tsinghua Tongfang Optical Disc Co., Ltd. All rights reserved.图 2 测试用例集的相关树模型将节点与特定的测试环境相关联 ,使其下的测试用例共享这一特定的测试环境 ,尤其是共享同一物理配置的测试环境。测试用例的执行可以从某节点 (阶段 ) 开始 ,灵活性提高。从某节点 (阶段 ) ,执行其下的所有测试用例。为今后系统升级的测试 ,奠定测试用例集的基础。4. 5 嵌入系统的特性对测试过程和工具的影响4. 5. 1 系统具有不同的开发环境与应用环境大部分
24、嵌入系统 ,其开发环境与最终的应用环境是完全不同的。最终的目标平台是优化定制的 ,它不必具有某些部件 (如 ,键盘、网络、磁盘等 ) ,而开发环境必须有这些部件。面对这种双平台问题 ,测试工具必须具有从开发环境对目标环境的高效透明的访问能力。事实上 ,必须将这种访问复杂性屏蔽起来 ,使用户无法察觉。这种复杂性包括测试用例信息的下载、对测试运行的远端监控 (启动、同步及停止 ) 、测试结果及加载观测等。4. 5. 2 大量繁多的运行平台和交叉开发环境运行平台从基于 8 位微处理机的小系统 ,到基于网络的分布式大系统。由于芯片和厂家繁多 ,所有这些平台多需要不同的开发工具。同一个嵌入系统中采用多种
25、平台的情况也越来越普遍。一般地说 ,这种开发环境就是所谓的“交叉开发环境”。繁多的运行平台也就意味着相应众多的开发工具 ,例如 ,编译器、连接器、装载器及纠错环境等。这就要求测试工具具有高效的原代码封装技术 ,使得在交叉开发环境中实现对原代码的观测点技术 ;此外 ,为开发人员提供一个集成开发环境IDE 的需求也非常高 ;最后 ,因计算机芯片技术的快速发展 ,新的运行环境及与之相关的开发工具也层出不穷 ,所以 ,测试技术就必须高度灵活 ,以便及时地适应这些新的系统结构。4. 5. 3 运行平台上资源和时间的约束嵌入系统对于其上运行的应用而言 ,其可用资源是有限的。对小型平台更是这样 :可用的 R
26、AM 不超过 1 Kb、J TA G探头、仿真器或串行链路是与开发环境的唯一连接 ,甚至微处理器仅能处理应用。这就对测试工具提出了各种需求 : (1)将测试数据置于开发环境 ,并通过链路将数据发送过去 ,如此的性能通常是无法忍受的 ;(2)由测试驱动将测试数据在目标环境中进行翻译 ; (3)将测试必要环境嵌入到目标环境 ,这是通过将事先转换为应用编程语言 ( C、 C + + 或 Ada) 在测试环境用交叉编译器进行编译 ;然后 ,将这个目标文件联接到应用中而实现的。综上所述 ,尽管交叉开发环境正变得更加友好 ,但目前大部分商用嵌入系统仍给我们在开发与测试过程中带来头疼的问题。5 结束语制定一
27、个好的测试计划和测试用例 ,是保证嵌入系统顺利测试的基础。相关树模型是制定测试用例集的手段之一。嵌入系统的测试仍是业界关注的焦点 ,在实际特定嵌入系统的测试中 ,都各有特色。参 考 文 献1 黄清清 ,软件测试与测试方法浅析 J .舰船电子工程 ,2004 , (1)2 Thane , H. Monitoring , Testing and Debugging ofDistributed Real - Time Systems D . KTH , Stockholm ,Sweden , 20003 Braberman , V and Felder , M. Testing Timing Be2
28、haviors of Real Time SoftwareJ . Quality Week 1997 :1431444 Braberman , V and Felder , M. Verification of Real -Time Design : Combining Scheduling Theory with AutomaticFormal Verification J . Software Engineering , 1999 : 4945105 Peter , D. K. and Parnas , D. L . Requirements -based Monitors for Real - Time Systems C. ISSTA 2000362005 年第 1 期 舰 船 电 子 工 程 1995-2005 Tsinghua Tongfang Optical Disc Co., Ltd. All rights reserved.
