（计算机应用技术专业论文）面向嵌入式软件的自动化黑盒测试的研究.pdf

摘要 随着计算机硬件和软件技术的迅猛发展，嵌入式系统的硬件规模和性能得到 了极大的提高，相应的，嵌入式系统软件和应用软件的复杂性和规模也日益提高， 同时嵌入式系统的特殊性决定了运行在其上的系统和应用软件必须精简可靠，使 得软件的开发在整个嵌入式系统开发中的比重越来越高，软件的质量对整个产品 的质量起到了决定性的作用。因此我们迫切需要一种针对嵌入式领域的测试工具 来提高软件的质量和可靠性，缩短软件开发周期。 现在已经有很多成熟的嵌入式软件白盒自动化测试理论、方法和工具，能提 供源码分析，覆盖测试等功能，但是针对嵌入式软件的黑盒测试，行之有效的理 论方法却风毛麟角，并且现有自动化测试工具要么覆盖的测试范围很窄，要么实 现困难，成本昂贵。 针对这一现况，本文提出了一种纯软件实现的嵌入式软件测试方法。此方法 没有特殊的硬件要求，实现简单，借助现有的嵌入式开发平台，加入少量的插装 代码。结合运行在p c 上的客户端程序就能完成针对大部分嵌入式系统的黑盒测 试。 本文根据这一方法，结合自动化测试的实践过程，提出了一系列的自动化测 试理论，并解决了很多在自动化黑盒测试中经常遇到的问题，包括自动化测试用 例的组织和管理等等。使用这一方法实现的工具已在一大型项目中得到应用，并 取得了很好的效果。实践证明，它确实能完成大部分的黑盒测试。 关键字：自动化测试，嵌入式系统，黑盒测试，测试用例 a b s t r a c t w i t ht h er a p i dd e v e l o p m e n to fc o m p u t e rh a r d w a r et e c h n o l o g y , t h es c a l ea n d c a p a b i l i t yo fh a r d w a r eo fe m b e d d e ds y s t e mh a sb e e ng r e a t l yi m p r o v e d a c c o r d i n g l y , t h e c o m p l e x i t ya n d5 c a l eo fs y s t e ms o f t w a r ea n da p p l i c a t i o ns o f t w a r eo fe m b e d d e ds y s t e m a l s og r o wi n c r e a s i n g l y s i m u l t a n e o u s l yt h es p e c i a l i t yo fe m b e d d e ds y s t e ma s k sf o r e m b e d d e ds o f t w a r eb e i n gm o r es m a r ta n dr e l i a b l e t h e r ei sn od o u b tt h a tt h er & do f s o f t w a r e p l a y sam o r ea n dm o r ei m p o r t a n tr o l ei nr & d o ft h ew h o l ee m b e d d e d s y s t e m 珏eq u a l i t yo fs o f t w a r e1 , 1 a y sad e c i s i v ea n dr e l i a b i l i t yo fs o f t w a r ea n ds h o r t e nt h e d e v e l o p m e n tc y c l e r e c e n t l y , t h e r ea r ea l r e a d ym a n ys y s t e m a t i c , i n t e g r a t e da n dm a t u r ew h i t eb o x t e s t t h e o r y , m e t h o da n dt o o l sf o re m b e d d e ds y s t e m b u tw h e ni tr e f e r st ob l a c kb o xt e s t , b o t ht h et e s tt h e o r ya n dm e t h o di sl a c k i n g n cc u r r e n ta u t o m a t i o nt e s tt o o le t h e rh a s l i m i t e dt e s ts c o p eo ri sv e r ye x p e n s i v e t h i sa r t i c l er e f e r san e wp u r es o f t w a r e - d r i v em e t h o dt ot e s te m b e d d e ds y s t e m a u t o m a t i c a l l y t h e r ei sn os p e c i a lh a r d w a r er e q u k e m e n t ，i ti se a s yt oe x e c u t e w i t ht h e h e l po fe m b e d d e ds y s t e mp l a t f o r m ，y o uo n l yn e e da d df e w e rs t u b si nt e s to b i e c t t h e i n s e r tt e s ts t u b ，t h ed e b u gp r o t o c o la n dt h ec l i e n tm no np cc a n h e l py o uc o m p l e t em o s t o ft h eb l a c kb o xt e s tw o r k a c c o r d i n gt ot h i sm e t h o d , c o m b i n ew i t ht h ei m p l e m e n to fa u t o m a t i o nt e s ti nr e a l e n v i r o n m e n t , t h i sa r t i c l eb d n go u tas e r i e so ft h e o r ya b o u ta u t o m a t i o nt e s t ，a n dr e s o l v e m a n yk e yi s s u e s i n c l u d i n go r g a n i z a t i o na n dm a n a g e m e n to ft e s tc a s e at o o lw h i c hi s b u i l ta c c o r d i n gt ot h i sm e t h o dh a sb e e nu s e di nab i gp r o j e c t , a n di tb r i n g sb i gb e n e f i tt o t h ep r o j e c t f a c t sh a v ep r o v e dt h a tt h em e t h o dc a na c t u a l l yc o v e rm o s to ft h eb l a c kb o x t e s t k e y w o r d s ：a u t o m a t i o n t e s t ；e m b e d d e ds y s t e m ；b l a c k - b o x t e s t ；t e s t c a s e 图表索b 图表索引 表1 - 1 自动化测试收益比较5 图 1 分析测试工具的使用流程1 2 图2 - 2 嵌入式软件的分析测试原理图。1 3 图2 - 3 对程序进行插装的机会1 4 图2 _ 4 纯硬件方法脚本录制过程1 8 图2 - 5 纯硬件方法回放过程1 9 图3 - 1 手机来电状态转换简单示意图2 1 图3 - 2 录制脚本过程2 3 图3 3 脚本回放过程一2 4 图3 _ 4 期待出现的情况2 5 图3 - 5 实际出现的情况2 6 图3 _ 6 嵌入式系统层次结构简图。2 7 图3 - 7 嵌入式系统用户操作检测2 8 图3 - 8 模拟人工输入方法2 8 图3 9 获取声音原理图2 9 图3 1 0l c d 显示原理3 0 图3 1 1 点阵截取法示意图3 4 图3 - 1 2 理想的主动查询方式3 4 图3 - 1 3 非理想状态下的主动查询方式3 5 图3 1 4 超时重传3 6 图3 1 5 被动获取方式工作示意图3 7 图3 1 6 用被动获取方式检查时闻不确定状态示意图3 8 图3 1 7 使用主动请求方式检查时间不确定状态流程图4 0 图3 1 8 相对比较方式生成脚本示意图4 4 图3 1 9 相对比较方式执行脚本示意图4 5 图3 - 2 0 u n c h e c k 处理流程图4 6 图缸1 软件功能树一5 5 图4 - 2 从特定的路径得到的测试案例5 6 图4 3 节点的缺陷计数器。5 7 v 独创性声明 本人声明所呈交的学位论文是本人在导师指导下进行的研究工 作及取得的研究成果。据我所知，除了文中特别加以标注和致谢的地 方外，论文中不包含其他人已经发表或撰写过的研究成果，也不包含 为获得电子科技大学或其它教育机构的学位或证书而使用过的材料。 与我一同工作的同志对本研究所做的任何贡献均已在论文中作了明 确的说明并表示谢意。 签名；鳘：暨：日期：砷1 年口f 月以日 关于论文使用授权的说明 本学位论文作者完全了解电子科技大学有关保留、使用学位论文 的规定，有权保留并向国家有关部门或机构送交论文的复印件和磁 盘厂允许论文被查阅和借阅。本人授权电子科技大学可以将学位论文 的全部或部分内容编入有关数据库进行检索，可以采用影印、缩印或 扫描等复制手段保存、汇编学位论文。 ( 保密的学位论文在解密后应遵守此规定) 签名： 导f 旆答幺狡忽 导师签名：翌型竺 日期：御1 年o f 月巧日 第一章引言 1 1 软件测试概述 第一章引言 软件测试在软件生命周期中占据重要的地位，在传统的瀑布模型中，软件测 试阶段仅处于运行维护阶段之前，是软件产品交付用户使用之前保证软件质量的 重要手段。近来，软件工程界趋向于一种新的观点，即认为软件生命周期每一阶 段中都应包含测试，从而检验本阶段的成果是否接近预期的目标，尽可能早的发 现错误并加以修正，如果不在早期阶段进行测试，错误的延时扩散常常会导致最 后成品测试的巨大困难【3 j 。 事实上，对于软件来讲，不论采用什么技术和什么方法，软件中仍然会有错。 采用新的语言、先进的开发方式、完善的开发过程，可以减少错误的引入，但是 不可能完全杜绝软件中的错误，这些引入的错误需要测试来找出，软件中的错误 密度也需要测试来进行估计。测试是所有工程学科的基本组成单元，是软件开发 的重要部分。自有程序设计的那天起测试就一直伴随着。统计表明，在典型的软 件开发项目中，软件测试工作量往往占软件开发总工作量的4 0 以上。而在软件 开发的总成本中，用在测试上的开销要占3 0 到5 0 2 1 1 7 1 。如果把维护阶段也考 虑在内，讨论整个软件生存期时，测试的成本比例也许会有所降低，但实际上维 护工作相当于二次开发，乃至多次开发，其中登定还包含有许多测试工作。 1 2 回归测试的重要性及其策略 在软件生命周期中的任何一个阶段，只要软件发生了改变，就可能给该软件 带来问题。软件的改变可能是源于发现了错误并做了修改，也有可能是因为在集 成或维护阶段加入了新的模块。当软件中所含错误被发现时，如果错误跟踪与管 理系统不够完善，就可艟会遗漏对这些错误的修改；面开发者对错误理解的不够 透彻，也可能导致所做的修改只修正了错误的外在表现，而没有修复错误本身， 从而造成修改失败；修改还有可能产生副作用从而导致软件未被修改的部分产生 新的问题，使本来工作正常的功能产生错误。同样，在有新代码加入软件的时候， 除了新加入的代码中有可能含有错误外，新代码还有可能对原有的代码带来影响。 1 电子科技大学硕士学位论文 因此，每当软件发生变化时，我们就必须重新测试现有的功能，以便确定修改是 否达到了预期的目的，检查修改是否损害了原有的正常功能。同时，还需要补充 新的测试用例来测试新的或被修改了的功能。为了验证修改的正确性及其影响就 需要进行回归测试。 回归测试在软件生命周期中扮演着重要的角色，因忽视回归测试而造成严重 后果的例子不计其数，导致阿里亚娜5 型火箭发射失败的软件缺陷就是由于复用 的代码没有经过充分的回归测试造成的【3 吼。 回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很 大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭 代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极端编程方法中， 更是要求每天都进行若干次回归测试。因此，通过选择正确的回归测试策略来改 进回归测试的效率和有效性是非常有意义的。 对于一个软件开发项目来说，项目的测试组在实施测试的过程中会将所开发 的测试用例保存到“测试用例库”中，并对其进行维护和管理。当得到一个软件 的基线版本时，用于基线版本测试的所有测试用例就形成了基线测试用例库。在 需要进行回归测试的时候，就可以根据所选择的回归测试策略，从基线测试用例 库中提取合适的测试用例组成回归测试包，通过运行回归测试包来实现回归测试。 保存在基线测试用例库中的测试用例可能是自动测试脚本，也有可能是测试用例 的手工实现过程。这个过程需要时间、经费和人力来计划、实施和管理。为了在 给定的预算和进度下，尽可能有效率和有效力地进行回归测试，需要对测试用例 库进行维护并依据一定的策略选择相应的回归测试包m 【艟l 。 由于回归测试大部分是做以前做过的、重复的工作，所以测试人员在做回归 测试时往往觉得枯燥乏味，不能保证测试的完备性，最终导致软件质量的下降。 为了提高测试的效率和正确性，人们提出让机器代替人来完成回归测试。 1 3 自动化测试的意义 通常，软件测试的工作量很大( 据统计，测试会占用到4 0 的开发时间；一些 可靠性要求非常高的软件，测试时间甚至占到开发时间的6 0 1 。而测试中的许多 操作是重复性的，非智力性的和非创造性的，并要求做准确细致的工作，计算机 就最适合于代替人工去完成这样的任务。软件自动化测试是相对手工测试而存在 的，主要是通过所开发的软件测试工具，脚本等来实现，具有良好的可操作性， 2 第一章引言 可重复性和高效率等特点 3 1 。 软件测试自动化实现的基础是可以通过设计的特殊程序模拟测试人员对计算 机的操作过程、操作行为，或者类似于编译系统那样对计算机程序进行检查。软 件测试自动化实现的原理和方法主要有：直接对代码进行静态和动态分析、测试 过程的捕获和回放、测试脚本技术、虚拟用户技术和测试管理技术嘲。 软件测试自动化通常借助测试工具进行。测试工具可以进行部分的测试设计、 实现、执行和比较的工作。部分的测试工具可以实现测试用例的自动生成，但通 常的工作方式为人工设计测试用例，使用工具进行用例的执行和比较。如果采用 自动比较技术，还可以自动完成测试用例执行结果的判断，从而避免人工比对存 在的疏漏问题。 要理解为什么要进行自动化测试，可以从两个方面考虑： 一是手工测试的局限性； 二是软件自动化测试所带来的好处。 手工测试的局限性： 1 通过手工测试无法做到覆盖所有代码路径。 2 简单的功能性测试用例在每一轮测试中都不能少，而且具有一定的机械性，重复 性，工作量往往较大。 3 许多与时序，死锁，资源冲突，多线程等有关的错误，通过手工测试很难捕捉到。 4 进行系统负载，性能测试时，需要模拟大量数据或大量并发用户等各种应用场合 时，很难通过于工测试来进行。 5 进行系统可靠性测试时，需要模拟系统运行十年，几十年，以验证系统能否稳定 运行，这也是手工测试无法模拟的。 6 如果有大量( 几千) 的测试用例，需要在短时间内( 1 天) 完成，手工测试几乎不可能 做到。 软件自动化测试所带来的好处： 1 缩短软件开发测试周期，可以让产品更快投放市场。 2 测试效率高，充分利用硬件资源。 3 节省人力资源，降低测试成本。 4 增强测试的稳定性和可靠性。 5 提高软件测试的准确度和精确度，增加软件信任度。 6 软件测试工具使测试工作相对比较容易，但能产生更高质量的测试结果。 7 手工不能做的事情，自动化测试能做，如负载、性能测试。 3 电子科技大学硕士学位论文 1 4 自动化测试的投入和产出 测试自动化，对于系统性能测试、负载测试等效果是明显的，而且我们也不 得不为之。我们知道，没有测试工具进行负载模拟，要通过手工测试完成系统测 试任务，几乎是不可能的。但在功能测试中，情况就大不一样了。 手工测试在功能测试中的优势还是比较大的，工具本身并没有想象力和灵活 性，而人对界面美观性、逻辑合理性，容易作出判断。所以功能测试自动化主要 的应用在回归测试中，而且产品的界面( u i ) 和功能变化较大，自动化的脚本( s c r i p t ) 维护成本较大，投入和产出往往变成我们最关心的问题，在功能测试中实现测试 自动化究竟是否合算? 举个例子：假如一个功能测试用例，手工运行需要1 0 分钟，而为此测试用例 开发脚本需要4 个小时，即2 4 0 分钟，那么意味着这个测试脚本要被运行2 4 次收 回成本，如果在加上测试脚本的维护工作量( 1 0 ) ，需要重复运行4 0 一5 0 次， 才收回成本。如果在产品的一个版本中要进行2 - - 3 轮测试( 一般是需要的) ，这 个产品需要发布1 5 2 0 个版本才收回成本。所以业界常说，产品发布7 个版本才 收回成本【3 0 1 。 如何降低成本、可以相对增加产出或者说更快地收回成本? 关键是提高脚本 开发速度、提高脚本运行的稳定性和降低维护脚本的工作量，主要方法有： 一选择较好的、更适合的测试工具 一选择适宜自动化的模块 一尽量将脚本写成数据驱动的脚本，这一点很重要。 一多录制脚本，然后结构化脚本。我们知道，不是所有的模块都可以变为数据 驱动方式，这时就要抽象出脚本的结构，进行有效的组合，包括分层，形成有效 的层次性。 一测试和脚本开发合二为一，效率更明显 下表也部分说明了这个问题。对于表中列出的几种自动化测试方式，在后文会详 细介绍 3 0 1 1 4 1 1 。 4 第一章引言 表1 - 1 自动化测试收益比较 结构 成本收益净收益 n o a u t o m a t i o n000 r e c o r d i n g a n dp l a y b a c k 8 31 12 7 8 41 89 6 d a t a - d r i v e ns t r u c t u r eu s i n gd a t ap o o l s f r a m e w o r ks t r u c t u r e9 81 55 2 f r a m e w o r k d a t a - d r i v e n ( h y b r i d ) s l m c u l r e 1 1 61 97 4 f o c u s i n go nv i e w so ft h ea p p l i c a t i o na n d u s i n gd a t ap o o l s 1 5 嵌入式软件自动化测试背景 在嵌入式软件测试领域，针对白盒测试的自动化测试方法、自动化测试工具 已有相对成熟的产品，如：m mr a t i o n a l 的r t r t ，v e c t o r s o f t w a r e 的v e c t o r c a s t ， 领测科技的v c t e s t e r ；但针对黑盒测试的成熟的自动化颖试理论、自动化测试方法、 自动化测试工具却鲜见。现阶段基本上还是停留在测试人员根据需求文档，先用 自然语言写好测试用例。再用手工操作嵌入式设备，用眼睛观察用户界面信息， 用耳朵听系统发出的声音。整个测试过程非常缓慢而且由于人为疏忽容易导致错 误。已有的方法需要大量的硬件设备辅助，结构复杂，工具本身的出错概率就很 高；也没有有效的工具为测试人员录制测试脚本，测试人员还是用手工去准备测 试脚本。 1 6 本课题背景和研究的内容 作者在实习期间加入一个历时两年多的嵌入式软件开发项目，并和六个同事 一起负责做每个版本的回归测试，每周都会有一至两个版本需要测试，这是一个 非常繁杂和无聊的工作。一个偶然的机会得知在另一个分公司有一台自动化测试 设备，可以依靠机械臂和照相机来代替人操作和记录嵌入式设备的信息，我们就 有一个设想：能不能用纯软件的方法来完成这个自动化测试过程。于是，在不断 探索和5 个月的努力之后，终于提出并实现了一种纯软件实现的用于嵌入式软件 的自动化测试方法。非常适合具有人机接口的嵌入式软件的黑盒测试。该方法只 需在被测软件中加入少量的测试桩，再结合安装在p c 上的相应软件模块就能分析 出系统软件的正确性。我们在实现中解决了很多嵌入式软件自动化黑盒测试的难 5 电子科技大学硕士学位论文 题，并提出了一系列的相关理论。 1 7 论文的组织 论文共分为五章，首先概述了当前软件自动化测试的理论以及自动化的现状。 第二章介绍了现在嵌入式软件的黑盒自动化测试现状。第三章介绍了一种纯软件 实现的嵌入式系统自动化测试方法及实现细节。然后分析了自动化测试在具体应 用中会遇到的难题，并提出一系列的解决方案结合这个方法，实现了一个针对 对讲机进行功能测试的工具。第四章讲述了自动化测试的测试案例集的管理方法。 最后对本文作了简短总结并对以后的工作提出了展望。 6 第二章嵌入式软件自动化测试方法分析 第二章嵌入式软件自动化测试方法分析 2 1 嵌入式软件测试概述 嵌入式软件测试嵌入式测试或叫交叉测试( c r o s s - t e s t ) 的日的与非嵌入式软 件是相同的。但是，在嵌入式系统设计中，软件正越来越多地取代硬件，以降低 系统的成本，获得更大的灵活性，这就需要使用更好的测试方法和工具进行嵌入 式和实时软件的测试。 通常嵌入式系统对可靠性的要求比较高。嵌入式系统安全性的失效可能会导 致灾难性的后果，即使是非安全性系统，由于大批量生产也会导致严重的经济损 失。这就要求对嵌入式系统，包括嵌入式软件进行严格的测试、确认和验证。随 着越来越多的领域使用软件和微处理器控制各种嵌入式设备，对日益复杂的嵌入 式软件进行快速有效的测试愈加显得重要。 软件测试的目的是保证软件满足需求规格说明。系统失效是系统没有满足一 个或多个正式需求规范中所要求的需求项。嵌入式软件有其特殊的失效判定准则， 但是，嵌入式软件测试的目的与非嵌入式软件是相同的。在嵌入式系统设计中， 软件正越来越多地取代硬件，以降低系统的成本，获得更大的灵活性，这就需要 使用更好的测试方法和工具进行嵌入式和实时软件的测试。 一般来说，软件测试有7 个基本阶段，即单元或模块测试、集成测试、外部 功能测试、回归测试、系统测试、验收测试、安装测试。嵌入式软件测试在4 个 阶段上进行，即模块测试、集成测试、系统测试、硬伟，软件集成测试。前3 个阶 段适用于任何软件的测试，硬件软件集成测试阶段是嵌入式软件所特有的，目的 是验证嵌入式软件与其所控制的硬件设备能否正确地交互【4 胴。 嵌入式系统不同于桌面系统，他具有自身的特性如：实时性限e a l t i m i n g ) ，内 存不丰富，i o 通道少，开发工具昂贵，并且与硬件紧密相关c p u 种类繁多，对 输入输出有诸多限制和特殊性等等。这些特性使得嵌入式软件的开发和测试与一 般商用软件的开发和测试策略有了很大的不同，现在也没有现成的通用测试工具， 一般都是自己开发测试平台。 由于嵌入式系统的自身特点，嵌入式软件测试具有以下影响因素： 1 应用、开发与运行平台独立分开。 7 电子科技大学硕士学位论文 2 开发平台复杂多样。 3 硬件资源、时间严格受限制。 4 软硬件开发并行，模块化和层次化交替结合。 5 缺乏可视化编程模式。 6 软件品质要求与认证标准因业务变化在不断升级。 嵌入式软件测试面临以下挑战： 1 测试工具很原始或根本没有。 2 硬件指令流水线、动态重定位代码、高速缓存等技术的引入，导致难以使 用工具模拟，难以做到测试自动化。 3 错误定位往往需要花费很多时间。 4 无法确认并评估测试有效性和测试充分性。 嵌入式软件测试使用有效的测试策略非常重要，它可以使开发效率最大化， 避免目标系统的瓶颈，使用在线仿真器节省昂贵的目标资源。自从出现高级语言， 开发环境与最终运行环境通常都是存在差异的，嵌人式系统更是如此。开发环境 被认为是主机平台，软件运行环境为目标平台。相应的测试策略为主机环境测试 或主机目标系统间交叉测试【1 q m 。 2 2 嵌入式软件的测试方法 2 2 1 白盒测试与黑盒测试 一般来说，软件测试有两种基本的方式，即白盒测试方法与黑盒测试方法， 嵌入式软件测试也不例外。 白盒测试或基本代码的测试检查程序的内部设计。根据源代码的组织结构查 找软件缺陷，一股要求测试人员对软件的结构和作用有详细的了解，白盒测试与 代码覆盖率密切相关，可以在白盒测试的同时计算出测试的代码的覆盖率，保证 测试的充分性。把1 0 0 的代码都测试到几乎是不可能的，所以要选择最重要的代 码迸行白盒测试。由于严格的安全性和可靠性的要求，嵌入式软件测试同非嵌入 式软件测试相比，通常要求有更高的代码覆盖率。对于嵌入式软件，白盒测试一 般不必在目标硬件上进行，更为实际的方式是在开发环境中通过硬件仿真进行， 所以选取的测试工具应该支持在宿主环境中的测试。 黑盒测试在某些情况下也称为功能测试。这类测试方法根据软件的用途和外 8 第二章嵌入式软件自动化测试方法分析 部特征查找软件缺陷，不需要了解程序的内部结构黑盒测试最大的优势在于不 依赖代码，而是从实际使用的角度进行测试，通过黑盒测试可以发现白盒测试发 现不了的问题。因为黑盒测试与需求紧密相关，需求规格说明的质量会直接影响 测试的结果，黑盒测试只能限制在需求的范围内进行在进行嵌入式软件黑盒测 试时，要把系统的预期用途作为重要依据，根据需求中对负载、定时、性能的要 求，判断软件是否满足这些需求规范。为了保证正确地测试，还须要检验软硬件 之间的接口。嵌入式软件黑盒测试的一个重要方面是极限测试。在使用环境中， 通常要求嵌入式软件的失效过程要平稳，所以，黑盒测试不仅要检查软件工作过 程，也要检查软件失效过程i 4 l 。 目前，测试人员基本上还是用手工的方式来进行嵌入式软件的黑盒测试。每 当软件更新以后，又不得不对软件进行回归测试以保证软件的正确性。在以往的 嵌入式系统中上层功能模块相对简单，黑盒测试所需要的工作量相对较小，用手 工测试来做黑盒测试所占用的时间与整个项目的开发周期相比，只是较小的一块， 还是可行的。但随着嵌入式应用的越来越深入广泛，嵌入式软件的复杂度也越来 越高，功能越来越丰富，具有复杂人机接口的系统越来越多。由于软件复杂度的 增加，软件的被测功能模块也随之不断增加，回归测试次数明显增多，黑盒测试 的工作量成指数级增长。如果我们还是用手工的方式来做黑盒测试的话，那么项 目开发的很大一部分时间都要花在黑盒测试上，尤其是在后期的维护过程中，大 部分的时间都被回归测试所占据。 为了减少黑盒测试的所占据的时间，人们提出了让机器代替人自动的对嵌入 式软件进行黑盒测试。本课题就是解决如何使用工具完成嵌入式软件的黑盒测试。 2 2 2 目标环境测试和宿主环境测试 在嵌入式软件测试中，常常要在基于目标的测试和基于宿主的测试之间作出 折衷。基于目标的测试消耗较多的经费和时间，而基于宿主的测试代价较小，但 毕竟是在模拟环境中进行的。目前的趋势是把更多的测试转移到宿主环境中进行， 但是，目标环境的复杂性和独特性不可能完全模拟。 在两个环境中可以出现不同的软件缺陷，重要的是目标环境和宿主环境的测 试内容有所选择。在宿主环境中，可以进行逻辑或界面的测试、以及与硬件无关 的测试。在模拟或宿主环境中的测试消耗时间通常相对较少，用调试工具可以更 快地完成调试和测试任务。而与定时问题有关的白盒测试、中断测试、硬件接口 9 电子科技大学硕士学位论文 测试只能在目标环境中进行。在软件测试周期中，基于目标的测试是在较晚的“硬 件软件集成测试”阶段开始的，如果不更早地在模拟环境中进行白盒测试，而是 等到“硬件软件集成测试”阶段进行全部的白盒测试，将耗费更多的财力和人力 阁。 2 3 嵌入式软件的测试工具 用于辅助嵌入式软件测试的工具很多，下面对几类比较有用的有关嵌入式软 件的测试工具加以介绍和分析。 2 3 1 内存分析工具 在嵌入式系统中，内存约束通常是有限的。内存分析工具用来处理在动态内 存分配中存在的缺陷。当动态内存被错误地分配后，通常难以再现，可能导致的 失效难以追踪，使用内存分析工具可以避免这类缺陷进入功能测试阶段。目前有 两类内存分析工具软件和硬件的。基于软件的内存分析工具可能会对代码的 性能造成很大影响，从而严重影响实时操作；基于硬件的内存分析工具价格昂贵， 而且只能在工具所限定的运行环境中使用阁。 2 3 2 性能分析工具 在嵌入式系统中，程序的性能通常是非常重要的。经常会有这样的要求，在 特定时间内处理一个中断，或生成具有特定定时要求的一帧。开发人员面临的问 题是决定应该对哪一部分代码进行优化来改进性能，常常会花大量的时间去优化 那些对性能没有任何影响的代码。性能分析工具会提供有关的数据，说明执行时 间是如何消耗的，是什么时候消耗的，以及每个例程所用的时间。根据这些数据， 确定哪些例程消耗部分执行时间，从而可以决定如何优化软件，获得更好的时间 性能。对于大多数应用来说，大部分执行时间用在相对少量的代码上，费时的代 码估计占所有软件总量的5 2 0 【2 】。性能分析工具不仅能指出哪些例程花费时间， 而且与调试工具联合使用可以引导开发人员查看需要优化的特定函数，性能分析 工具还可以引导开发人员发现在系统调用中存在的错误以及程序结构上的缺陷同。 第二章嵌入式软件自动化测试方法分析 2 3 3 g u i 测试工具 很多嵌入式应用带有某种形式的图形用户界面进行交互，有些系统性能测试 是根据用户输入响应时间进行的。g l i i 测试工具可以作为脚本工具有开发环境中 运行测试用例，其功能包括对操作的记录和回放、抓取屏幕显示供以后分析和比 较、设置和管理测试过程。很多嵌入式设备没有g u i ，但常常可以对嵌入式设备 进行插装来运行g u i 测试脚本，虽然这种方式可能要求对被测代码进行更改，但 是节省了功能测试和回归测试的时间【5 j 。 2 3 4 覆盖分析工具 在进行白盒测试时，可以使用代码覆盖分析工具追踪哪些代码被执行过。分 析过程可以通过插装来完成，插装可以是在测试环境中嵌入硬件，也可以是在可 执行代码中加入软件，也可以是二者相结合。测试人员对结果数据加以总结，确 定哪些代码被执行过，哪些代码被巡漏了。覆盖分析工具一般会提供有关功能覆 盖、分支覆盖、条件覆盖的信息。对于嵌入式软件来说，代码覆盖分析工具可能 侵入代码的执行，影响实时代码的运行过程。基于硬件的代码覆盖分析工具的侵 入程度要小一些，但是价格一般比较昂贵，而且限制被测代码的数量例。 2 4 嵌入式软件测试工具实现方法 2 4 1 嵌入式软件测试工具的工作原理 对嵌入式系统进行功能和性能测试需要记录分析大量的数据，这通常是手工 方式所不能完成的，需要分析测试工具的支持。这些工具软件一般具备下面的功 能特点，可弥补人为测试的缺陷【4 】。 如图2 1 所示，这些分析测试工具的使用流程通常为： 1 对程序代码进行插装处理，得到插装过的可执行程序，同时得到一些 插装相关的源代码信息。 2 执行插装后的程序，分析测试工具收集程序的动态运行信息。 3 分析测试工具处理收集到的程序动态信息，并结合系统需求判断输出结果 的正确性。 1 1 电子科技大学硕士学位论文 图2 - 1 分析测试工具的使用流程 2 4 2 嵌入式测试工具的交叉运行环境 通用软件开发的开发环境和程序运行环境是相同的，程序动态信息的收集比 较简单，可以通过写数据文件将程序的动态信息保存下来，或通过管道通信等方 式直接将程序的动态信息发送给分析测试工具。嵌入式软件的开发与通用软件很 大的不同点在于，需要采用交叉开发的方式：开发工具运行在软硬件配置丰富的 宿主机上，而嵌入式应用程序运行在软硬件资源相对缺乏的目标机上。对于这类 软件的分析测试也存在着同样的问题：测试工具运行在宿主机上，分析测试工具 所需要的程序动态信息在目标机上产生，所以必须通过一定的物理，逻辑连接传输 到缩主机上，由测试工具接收。因此，嵌入式软件分析测试工具的一个重要问题 是建立宿主机与目标机之间的物理逻辑连接，解决数据信息的传输问题，嵌入式 分析测试工具与单机环境的分析测试工具的最大区别也在于此，这也是嵌入式分 析测试工具的技术先进性、易用性的主要体现。嵌入式环境下软件分析测试的程 序动态信息收集原理如图2 _ 2 所示【4 】。 第二章嵌入式软件自动化测试方法分析 图2 - 2 嵌入式软件的分析测试原理图 在目标机方，插装过的被测应用程序将动态信息发送到消息队列中，一个专 门的任务负责在适当的时候将这些信息发送到宿主机方。宿主机方有专门的模块 负责接收这些信息。并交给分析工具的数据处理部分进行分析和在线动态显示。 2 4 3 嵌入式测试工具对待测程序的插装 决大多数分析测试工具通过对被测程序代码进行修改，使之能够记录程序的 运行情况。这个修改过程通常是向被测程序代码中的适当位置添加少量的代码， 这个修改过程称为插装。插装的代码应不影响程序的运行逻辑，即插装前后的程 序代码在逻辑上是等价的。只是插装后的程序由于要执行插装代码以收集程序运 行信息，致使插装后的程序比未进行插装时运行得慢一些。 代码插装能够在程序创建的任一阶段进行( 参见图2 - 3 ) ，这些插装策略大致可 以分为3 种：可执行文件产生后进行插装，链接过程中进行插装，或者在对源代 码进行编译处理的某一阶段进行插装 1 7 1 。虽然在不同阶段进行插装所面临的具体 问题各不相同，但在各阶段进行插装的步骤是相同的。总的来说，代码插装有下 面4 个步骤： 对待插装的代码进行分析 在适当的位置，添加插装代码 重新安排代码，使插装代码与原代码有机结合 电子科技大学硕士学位论文 重新构建可执行程序 7 修改编译器 篓二巍。i 赫。勰 7 修改汇编器 修改库文件， 运行对修改可执行文件 、 图2 - 3 对程序进行插装的机会 2 4 4 嵌入式测试工具收集动态信息的方法 根据嵌入式测试工具采集数据方式的不同，嵌入式测试工具又可分为以下几 种： 运行在目标板上的纯软件工具 纯硬件工具 硬件辅助支持的软件工具 2 4 4 1 运行在目标板上的纯软件工具 纯软件的测试工具采用的是软件打点技术，在被测代码中插装一些代码，用 这些代码来完成数据的生成，并上传数据到目标系统的共享内存中。同时在目标 系统中运行一个预处理任务，完成这些数据的预处理，并将处理后的数据通过目 标机的网口或串口上送到主机平台，这一切都需借助于用户的目标处理器完成。 通过以上过程，测试者便得以知道程序当前的运行状态。 这种测试工具的主要优点是无需额外的硬件支持，实现比较简单，便于移植， 因而在嵌入式开发环境中得到了广泛的应用。但由于插入插桩函数和预处理任务 的存在，使系统的代码增大，更严重的是这些代码会对系统的运行效率有很大的 1 4 第二章嵌入式软件自动化测试方法分析 影响。函数本身要有它的实现过程，它要完成数据的生成和暂存，而且这些函数 在它的实现过程中还可能被其他优先级更高的中断程序所中断，预处理任务需要 占用目标系统c p u 处理时间、共享内存和通信通道完成数据的处理、数据的上送。 由于这些弊端的存在，当采用纯软件测试工具对目标系统进行测试时，目标系统 是在一种不真实的环境下运行的，所捕获的数据也是不够精确【4 】。 另外，这种运行在目标板上的纯软件工具由于数据的采集和上传都是借助于 用户的目标处理器完成，数据采集和上传通常借助操作系统的相关机制实现，所 以在设计过程中这种纯软件工具需要解决好下面2 方面的问题。 与嵌入式操作系统的结合：首先，在目标机方，应用任务与专门负责收集上 传覆盖信息的任务可以通过消息队列来传递数据的，而该消息队列可使用嵌入式 操作系统的相应机制实现。其次，这个专门任务也可以被看作一个特殊的应用任 务，也必须有嵌入式操作系统的支持，因为任务管理是后者的基本功能之一。最 后，目标机与宿主机之间的通信可以采用串口或以太网方式，对串口的驱动或网 络协议均可使用嵌入式操作系统的相应程序组件。 与其它嵌入式交叉开发工具的关系：嵌入式应用程序的开发通常采用交叉开 发方式，几乎所有的开发工具均要解决3 部分的问题：宿主机部分的功能、目标 机部分的功能、宿主机与目标机的连接问题。其中，宿主机与目标机的连接是个 瓶颈，如果不同的工具要使用同一物理线路实现数据传输，则要解决对该物理线 路( 或者说硬件端口) 的正确共享。宿主机方的各种工具通过统一的接口一目标服务 器( t a r g e ts c l v e r ) 实现对通信线路的访问，目标机方的调试代理( d e b u ga g e n t ) 贝t j 是各 种信息( 调试信息、覆盖信息、时间信息、对象信息等) 的收集与传递的核心。 2 4 4 2 纯硬件工具 纯硬件工具，如逻辑分析仪、仿真器等，通常用于嵌入式软件开发阶段，对 嵌入式应用系统进行硬件设计与软件调试工作，当这些工具用于嵌入式软件的分 析测试时他们也具有一定提高和优化系统性能指标的功能，但功能通常有限。 以逻辑分析仪为例，逻辑分析仪是通过监控系统在运行时总线上的指令周期， 并以一定的频率捕获这些信号，通过对捕获的信号进行分析来判断程序当前运行 的状况。由于它使用的是采样的方式，难免会遗失一些重要的信号；同时，分析 的范围也及其有限。当对程序做覆盖率分析时，因为硬件工具是从系统总线捕获 数据的，如当c a c h e 打开我们会采用指令预取技术，从外存中读入一段代码到一 级c a c h e 中，这时逻辑分析仪在总线上监视到这些代码被读取的信号，就会报告 电子科技大学硕士学位论文 这些代码己经被执行了，但实际上被送到c a c h e 中的代码可能根本没有被命中。 为了避免这种误差必须把c a c h e 关闭掉，而c a c h e 关掉就不是系统真实的运行环 境了，有时甚至会由于c a c h e 关闭而导致系统无法正常运行。 而仿真器通常采用内存标记技术，它所关心的也是处理器从外存的代码段读 取数据的情况。所以也无法在c a c h e 打开的方式下工作。而它的性能分析也是以 仿真器的时间系统以抽样的方式进行的，也无法时实对系统进行真实的分析。所 以所得出的结果也是不精确的【4 】。 另外纯硬件工具由于没有进行源代码分析，所以不能进行高级的覆盖测试。 2 4 4 3 硬件辅助的软件工具 为了克服存软件方式数据上传对目标系统的影响，一些嵌入式分析测试工具 采用硬件方式实现数据上传通路，很好地解决了这个问题，如a m c 公司 c o d f 【e s t 。 程序员编写的源代码首先会通过c o d e t e s t 的编译驱动器调用原编译器对进 行预编译，然后c o d e t e s t 的插桩器( 源代码分析程序) 对预编译了的源代码进行自 动的插桩，即在需要插桩的关键位置写入一条赋值语句f 如：a m cc t r t = 0 x 7 4 1 0 0 0 0 9 ) ， 并把插入的标记送入一个数据库文件中生成一个符号数据库暂存起来，以备为以 后分析时调用。然后，c o d e t e s t 的编译驱动器又会调用原编译器对插桩后的代码 进行编译生成可执行目标代码送到目标板上运行。当程序在目标系统运行到插桩 点的位置时，目标板的控制总线和地址总线上会出现相应的控制信号和地址信号。 当c o d e t e s t 的辅助硬件( 信号捕获探头) 从控制总线和地址总线上监视到符合以上 条件的信号时一，c o d et e s t 会主动地从数据总线上把数据捕获回来送到c o d e t e s t 的内存中暂存并对这些数据进行预处理，然后将预处理后的数据通过局域网 送到工作平台上。通过与前面生成的符号数据库中的数据进行比较，我们就此得 知当前程序的运行状态，借此完成对嵌入式软件的性能分析，高级覆盖率分析， 内存分析和大容量的代码跟踪。 由此可知，c o