（计算机应用技术专业论文）基于mmi的嵌入式软件自动化测试平台设计与实现.pdf

摘要 摘要 软件测试是为了提高和保证软件质量的一个环节。在软件测试过程中，特别 是黑盒测试中，存在着许多重复性的工作，也导致软件效率的低下。因此，在软 件测试过程的各个阶段，人w j i 进了各种各样的测试工具，来提高软件测试的效 率。软件测试自动化理论也就因此而产生，软件自动化测试工具的研究和开发也 逐渐的成为了热门的话题。 对桌面软件的测试，现在已经有很多系统的、完整的、成熟的自动化测试理 论、方法和工具。但在嵌入式系统黑盒测试自动化领域，行之有效的理论方法很 少。现有自动化测试工具要么覆盖的测试范围很窄，要么实现困难，成本昂贵。 针对这一状况，本文提出了一种纯软件实现的嵌入式系统黑盒自动化测试方 法，该方法不需要任何硬件设备的辅助，只需在被测软件中加入少量测试代码， 并结合相关的调试协议和运行在p c 上的信息解析器就可帮你完成大部分的测试 工作。非常适合具有人机交互界面( m m i ) 的嵌入式系统的黑盒测试。 根据这种嵌入式软件自动化测试方法，本文还实现了一个嵌入式软件的黑盒 测试平台，从自动化测试的脚本技术、人机界面的获取及解析，自动化比较、脚 本生成、测试管理等多方面阐述了平台的实现过程。平台具有很强的灵活性，能 适用于各种具有人机交互界面的嵌入式系统的黑盒测试。 关键字：自动化测试，嵌入式系统，人机界面，黑盒测试，测试平台 a b s t r a e t a b s t r a c t s o f t w a r et e s tp l a y sak e yr o l ei ne n s u r i n ga n di m p r o v i n gt h eq u a l i t yo fs o f t w a r e a l o to fr e p e a t e dw o r kr e s u l t si nl o we f f i c i e n c yi nt h ep r o c e s so fs o f t w a r et e s t e s p e c i a l l y i nb l a c kb o xt e s t h o w e v e r , a l lk i n d so ft e s tt o m sa r ei n t r o d u c e di n t ot h ep r o c e s so f s o f t w a r et e s t , w h i c hc a ne n h a n c et h ee f f i c i e n c y s ot h et h e o r yo fs o f t w a r ea u t o t e s t b r i n go u t s t u d ya n dd e v e l o p m e n to fs o f t w a r ea u t o - t e s tt o o lb e c o m e sm o r ea n dm o r e p o p u l a r 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 ea u t o m a t i o nt e s tt h e o r y , m e t h o da n dt o o l sa b o u td e s kt o ps o f t w a r e b u tw h e ni tr e f e r st oe m b e d d e ds y s t e mt 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 t h ec 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 e m e t h o dt ot e s te m b e d d e ds y s t e ma u t o m a t i c a l l y y o uo n l ys h o u l da d df e w e rs t u b si nt e s t o b j e c t t h ei 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 ep a r s e rr u no np cc a l lh e l py o u c o m p l e t em o s to ft h et e s tw o r k t h i sm e t h o di ss u i t a b l ef o rt h ee m b e d d e ds y s t e mw i t h m m i ( v l m i ：m a n u a lm a c h i n ei n t e r f a c e ) t h i sa r t i c l ec o m p l e t e sa l la u t o m a t i o nt e s tp l a t f o r mf o r t h eb l a c kb o xt e s to f e m b e d d e ds y s t e mb a s e do i lt h et e s tm e t h o dm e n t i o n e da b o v e i tr e p r e s e n tt h ec o m p l e t e p r o c e s sf r o ms e v e r a la s p e c t ss u c ha ss c r i p tt e d m o l o g yo fa u t o m a t i o nt e s t ，c o m p a r i s o n t e c h n o l o g yo f a u t o m a t i o nt c s t s c r i p tg e n e r a t i o na n d t e s tm a n a g e m e n t t h i sp l a t f o r mh a s s t r o n gf l e x i b i l i t ya n di ts u i t a b l ef o rt h eb l a c kb o x t e s to f e m b e d d e ds y s t e mw i t hm m l k e yw o r d s ：a u t o m a t i o nt e s t ；e m b e d d e ds y s t e m ；m m i ；b l a c k - b o xt e s t ；t e s t p i a t f o r m 硕士论文修改提纲 姓名林健学号2 0 0 4 2 0 6 0 3 0 2 9 硕士论文基于m m i 的嵌入式软件自动化测试平台设计与实现的修改如下： 1 修改了参考文献的排列顺序 2 第1 页增加上标【1 6 】【2 5 】，第2 页增加上标【4 】【1 7 】【1 8 】【2 0 】【2 2 】，第3 页增加上 标【1 】【1 7 】，第4 页增加上标f 1 】【3 5 】【1 0 】，第5 页增加上标1 1 1 1 0 1 1 1 1 1 1 1 3 2 3 ， 第6 页增加上标【9 】1 1 1 1 1 1 8 2 4 1 ，第8 页增加上标【1 1 】【1 8 】，第9 页增加上标【3 】 1 2 0 1 1 2 7 ，第1 2 页增加上标【1 2 】【2 7 】，第1 3 页增加上标【9 】【1 8 】，第2 5 页增加 上标【1 2 】，第2 8 页增加上标【2 】 1 5 】，第2 9 页增加上标 1 4 】，第3 2 页增加上 标【6 】 7 1 1 8 2 1 ，第3 5 页增加上标【1 9 】，第3 7 页增加上标【1 9 】，第3 8 页增加 上标【2 6 】，第4 5 页增加上标【2 8 】。 新糊 答辩委员会主席： 2 0 0 7 年3 月2 7 日 独创性声明 本人声明所呈交的学位论文是本人在导师指导下进行的研究工作 及取得的研究成果。据我所知，除了文中特别加以标注和致谢的地方 外，论文中不包含其他人已经发表或撰写过的研究成果，也不包含为 获得电子科技大学或其它教育机构的学位或证书而使用过的材料。与 我一同工作的同志对本研究所做的任何贡献均己在论文中作了明确的 说明并表示谢意。 签名：匙尘菱 日期：j 。年i z 月r 日 关于论文使用授权的说明 本学位论文作者完全了解电子科技大学有关保留、使用学位论文 的规定，有权保留并向国家有关部门或机构送交论文的复印件和磁盘， 允许论文被查阅和借阅。本人授权电子科技大学可以将学位论文的全 部或部分内容编入有关数据库进行检索，可以采用影印、缩印或扫描 等复制手段保存、汇编学位论文。 ( 保密的学位论文在解密后应遵守此规定) 签名： 机使 导师签名 日期：j o 。多年2 月s ，日 第一章引言 第一章引言 1 1 软件测试概述及回归测试背景 软件测试是软件开发过程的重要组成部分，是用来确认一个程序的品质或性 能是否符合开发之前所提出的一些要求。进行软件测试的主要目的是发现软件中 的错误，然后修改错误，最终来提高软件的质量。 一般来说，软件开发过程分为需求分析、设计、编码、测试、维护几个阶段。 从测试方法上分，软件测试包括白盒测试和黑盒测试。从测试阶段上分，测试包 含单元测试御n i tt , s o 、集成测试( i n t e g r a t e dt e s t ) 和系统测试( s y s t e mt e s t ) 。从其它 角度又可把测试分为回归测试，压力测试等等【1 6 l f 吲。大量统计资料表明，软件测 试的工作量往往占软件开发总工作量的4 0 以上，在极端情况，测试那种关系人 的生命安全的软件所花费的成本，可能相当于软件工程其它开发步骤总成本的三 倍到五倍。 现在软件系统日益复杂，版本更新越来越快，生命周期也越来越长。怎么来 保证在长长的生命周期里，不断改变软件的结构、用户的需求而不影响到软件的 质量呢? 那就是不停的回归测试。回归测试用来验证程序修改或者版本更新以后， 以前正确的功能和其它指标仍旧正确，它在软件生命周期中扮演着重要的角色。 回归测试在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都 会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试 进行的更加频繁，而在极限编程方法中，更是要求每天都进行若干次回归测试。 在项目处于维护期间，需要对系统更新已有功能，增加新的功能。回归测试在整 个更新中几乎是占据了6 0 的时间。 由于回归测试大部分是做以前做过的、重复的工作，所以测试人员在做回归 测试时往往觉得枯燥乏味，不能保证测试的完备性，最终导致软件质量的下降。 为了提高测试的效率和正确性，人们提出让机器代替人来完成回归测试。 1 2 自动化测试兴起 软件自动化测试是相对手工测试而存在的，主要是通过所开发的软件测试工 电子科技大学硕士论文 具、脚本等来实现，具有良好的可操作性、可重复性和高效率等特点。 软件测试自动化实现的基础是可以通过设计的特殊程序模拟测试人员对计算 机的操作过程、操作行为，或者类似于编译系统那样对计算机程序进行检查。软 件测试自动化实现的原理和方法主要有：直接对代码进行静态和动态分析、测试 过程的捕获和回放、测试脚本技术、虚拟用户技术和测试管理技术【4 】【2 0 1 。 软件测试自动化通常借助测试工具进行。测试工具可以进行部分的测试设计、 实现、执行和比较的工作。部分的测试工具可以实现测试用例的自动生成，但通 常的工作方式为人工设计测试用例，使用工具进行用例的执行和比较。如果采用 自动比较技术，还可以自动完成测试用例执行结果的判断，从而避免人工比对存 在的疏漏问题。 自动化测试与传统的测试方法相比，具有以下优点【4 1 【1 7 】例： 1 缩短软件开发测试周期，可以让产品更快投放市场。 2 测试效率高，充分利用硬件资源。 3 节省人力资源，降低测试成本。 4 增强测试的稳定性和可靠性。 5 提高软件测试的准确度和精确度，增加软件信任度。 6 软件测试工具使测试工作相对比较容易，但能产生更高质量的测试结果。 7 手工不能做的事情，自动化测试能做，如负载、性能测试。 1 3 桌面软件自动化测试 桌面软件的自动化测试近年来得到了飞速的发展，一些测试理论和大量的测 试工具相继登台。在过去的日子中，自动化的测试工具只是被看作是一种捕获和 回放的工具。当前这个神话仍然在很多测试人员的思想中。而事实上自动化测试 已经远不止捕获和回放这么简单了。按照成熟度自动化的测试可以被划分为5 个 级别【1 8 l 【冽。 1 捕获和回放： 2 捕获、编辑和回放 3 编程和回放 4 数据驱动的测试 5 使用动作词的测试自动化 现在流行的桌面软件的自动化测试工具主要包括两类；一类是基于g u i 的自 动化测试 2 第一章引言 此类工具主要用于软件的黑盒测试，典型的代表有w i n r u n n e r , r a t i o n a l r o b o r t 等等；一类是依据开发语言的特性，通过分析源代码的关键字来自动生成 测试脚本，最大的覆盖源码的各个分支。该类工具主要是用于软件的白盒测试， 典型的代表有c + + t e s t e r ，c o d et e s t e r 等等【1 7 1 。 1 4 嵌入式软件自动化测试背景 在桌面软件的测试领域，针对不同类别测试的各种自动化测试方法，各种自 动化测试工具百花齐放。在嵌入式软件测试领域，针对百盒测试的自动化测试方 法、自动化测试工具已有相对成熟的产品，如：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 】；但针对黑盒测试的成熟的自动化 测试理论、自动化测试方法、自动化测试工具却鲜见。现阶段基本上还是停留在 钡4 试人员根据需求文档，先用自然语言写好测试用例。再用手工操作嵌入式设备， 用眼睛观察用户界面信息，用耳朵听系统发出的声音。整个测试过程非常缓慢而 且由于人为疏忽容易导致错误。已有的方法需要大量的硬件设备辅助，结构复杂， 工具本身的出错概率就很高；也没有有效的工具为测试人员录制测试脚本，测试 人员还是用手工去准备测试脚本。 1 5 本课题研究和开发的内容 本课题提出一种纯软件实现的用于嵌入式软件的自动化测试方法。非常适合 具有人机接口( m m i ) 的嵌入式软件的黑盒测试。该方法只需在被测软件中加入 少量的测试桩，再结合安装在p c 上的相应软件模块就能分析出系统软件的正确 性。根据该方法，本文还实现了一套自动化测试的系统测试平台，能胜任各种具 有人机接口的嵌入式软件的黑盒测试，并提出了一系列的嵌入式软件系统测试的 自动化测试理论。 论文共分为六章，首先概述了当前软件自动化测试的理论以及自动化的现状。 第二章介绍了现在嵌入式软件黑盒测试的自动化测试现状。第三章介绍了一种基 于m m i 的嵌入式系统自动化测试方法及实现细节。第四章讲述了嵌入式系统自动 化测试平台的实现。第五章举例了一个简单的测试实例以及对测试平台的分析。 最后对本文作了简短总结并对以后的工作提出了展望。 3 电子科技大学硕士论文 第二章嵌入式软件测试及黑盒自动化测试方法分析 2 1 嵌入式软件测试概述 一般来说，软件测试有7 个基本阶段，即单元或模块测试、集成测试、外部 功能测试、回归测试、系统测试、验收测试、安装测试。嵌入式软件测试在4 个 阶段上进行，即模块测试、集成测试、系统测试、硬件软件集成测试。前3 个阶 段适用于任何软件的测试，硬件软件集成测试阶段是嵌入式软件所特有的，目的 是验证嵌入式软件与其所控制的硬件设备能否正确地交互【1 】【3 l 。 嵌入式系统不同于桌面系统，他具有自身的特性如：实时性( r e a l t i m i n g ) ， 内存不丰富，i o 通道少，开发工具昂贵，并且与硬件紧密相关c p u 种类繁多， 对输入输出有诸多限制和特殊性等等。这些特性使得嵌入式软件的开发和测试与 一般商用软件的开发和测试策略有了很大的不同，现在也没有现成的通用测试工 具，一般都是自己开发测试平台。 由于嵌入式系统的自身特点，嵌入式软件测试具有以下影响因素【3 1 【5 1 1 1 0 1 ： 1 1 应用、开发与运行平台独立分开。 开发平台复杂多样。 3 1 硬件资源、时间严格受限制。 4 ) 软硬件开发并行，模块化和层次化交替结合。 研缺乏可视化编程模式。 软件品质要求与认证标准因业务变化在不断升级。 嵌入式软件测试面临以下挑战： 1 1 测试工具很原始或根本没有。 2 ) 硬件指令流水线、动态重定位代码、高速缓存等技术的引入，导致难以使 用工具模拟，难以做到测试自动化。 3 1 错误定位往往需要花费很多时间。 无法确认并评估测试有效性和测试充分性 嵌入式软件测试使用有效的测试策略非常重要，它可以使开发效率最大化， 避免目标系统的瓶颈，使用在线仿真器节省昂贵的目标资源。自从出现高级语言， 开发环境与最终运行环境通常都是存在差异的，嵌人式系统更是如此。开发环境 4 第二章嵌入式软件测试及黑盒自动化测试方法分析 被认为是主机平台，软件运行环境为目标平台。相应的测试策略为主机环境测试 或主机目标系统间交叉测试。 2 2 嵌入式软件测试工具的基本实现方法 2 2 1 纯软件方法 采用软件打点技术【l 】【捌l 。在被测试代码中插入些函数，用这些函数来完成 数据的c o d e & d e c o d e ，并上传数据到目标系统共享内存中。同时在目标系统中运行 一个预处理任务( 新增t a s k 或p r o c e s s ) ，完成被测系统中采集数据的预处理，将处 理后数据通过工具支持的通信方式上传到主机系统。测试开发要求做测试脚本或 测试函数序列，插入桩函数和预处理任务等工作。显然测试过程需要借助目标系 统c p u ，跟踪当前运行时状态，也同时增加了目标系统负荷。 矛盾：代码覆盖分析时，打点太多时将影响目标系统运行，不能对内存动态 分配进行跟踪所插入函数需要完成数据c o d e & d e c o d e 和缓存，难以确保任务优先 级别所造成的测试精确度。新增t a s k 或p r o c e s s 需要占用c p u 处理时间、共享内存 和通信端口来完成采集的数据处理，造成目标系统测试不精确。 2 2 2 纯硬件方法 以逻辑分析仪为例，逻辑分析仪通过在运行时总线指令周期上跟踪，并以一 定频率进行采样，分析范围有限，抽样结果得出的性能分析将对精确度产生影响。 据统计c o d e t e s t 同时针对1 2 8 0 0 0 个函数做性能分析能得到一个精确结果。 代码覆盖度分析时，硬件工具从系统总线捕获数据时，若c a c h e 开启，指令往 往支持预取技术，从外存中读取代码到一级c a c h e ，逻辑分析仪确在总线上跟踪到 代码被读取，则报告该代码已经被执行，实际被送到c a c h e 中代码可能并没有命中。 若为了避免这种误差情形，关闭c a c h e ，则系统测试并不真实，也往往造成系统根 本无法正常工作。 仿真器通常采用内存标记技术，仿真器关心c p u 从外存代码段读取数据的情 况，性能分析通过仿真器时间系统以抽样方式进行，其结果不精确。 纯硬件工具根本不具有对内存分配进行分析和检查的能【1 0 j 【1 1 l 。 5 电子科技大学硕士论文 2 3 嵌入式软件的黑盒测试 黑盒测试在某些情况下也称为功能测试。这类测试方法根据软件的用途和外 部特征查找软件缺陷，不需要了解程序的内部结构。黑盒测试最大的优势在于不 依赖代码，而是从实际使用的角度进行测试，通过黑盒测试可以发现白盒测试发 现不了的问题。 因为黑盒测试与需求紧密相关，需求规格说明的质量会直接影响测试的结果， 黑盒测试只能限制在需求的范围内进行。在进行嵌入式软件黑盒测试时，要把系 统的预期用途作为重要依据，根据需求中对负载、定时、性能的要求，判断软件 是否满足这些需求规范。为了保证正确地测试，还须要检验软硬件之间的接口。 嵌入式软件黑盒测试的一个重要方面是极限测试。在使用环境中，通常要求嵌入 式软件的失效过程要平稳，所以，黑盒测试不仅要检查软件工作过程，也要检查 软件换效过程1 9 】。 目前，测试人员基本上还是用手工的方式来进行嵌入式软件的黑盒测试。每 当软件更新以后，又不得不对软件进行回归测试以保证软件的正确性。在以往的 嵌入式系统中上层功能模块相对简单，黑盒测试所需要的工作量相对较小，用手 工测试来做黑盒测试所占用的时间与整个项目的开发周期相比，只是较小的一快， 还是可行的。但随着嵌入式应用的越来越深入广泛，嵌入式软件的复杂度也越来 越高，功能越来越丰富，具有复杂人机接口( m m d 的系统越来越多。由于软件 复杂度的增加，软件的被测功能模块也随之不断增加，回归测试次数明显增多， 黑盒测试的工作量成指数级增长。如果我们还是用手工的方式来做黑盒测试的话， 那么项目开发的很大一部分时间都要花在黑盒测试上，尤其是在后期的维护过程 中，大部分的时间都被回归测试所占据。 为了减少黑盒测试的所占据的时间，人们提出了让机器代替人自动的对嵌入 式软件进行黑盒测试。 2 4 现有的黑盒测试的自动化测试方法分析 现在有公司开发专用的测试机器来代替人工测试，使用机械手操作嵌入式产 品，使用照相机，录音机获取用户界面信息，再把这些信息和正确值进行比较。 整个测试过程分为测试准备和实际测试两个阶段【l l 】【1 8 】1 2 4 1 。 在测试准备阶段，首先编写好机械手的控制程序，机械手根据控制程序控制 6 第二章嵌入式软件测试及黑盒自动化测试方法分析 其移动的幅度和方向，模拟人工操作嵌入式系统。当起完成一次操作以后，测试 系统配备的专用照相机会拍照记录下本次操作后被测系统的界面的显示信息。测 试系统配备的录音设备也会记录下各种声音信息。当一系列相关操作完成以后， 机械手控制程序中的操作信息，相机拍摄的界面显示信息，录音设备记录的声音 信息共同组成了回放的脚本。整个过程也称为脚本的录制过程。当然，整个测试 准备阶段不仅仅是录制测试脚本，还应准备测试脚本对应的配置文件，脚本执行 的初始状态等。录制过程如图2 1 所示。 图2 - 1 脚本录制过程 在回放阶段，机械手根据脚本中的控制信息，重复在录制阶段的动作。相应 的专用照相机会拍照记录下本次操作后被钡4 系统界面的显示信息。录音设备也会 记录下各种声音信息。最后把各种信息与脚本中的期望值进行比较，如果相同则 被测软件正确。反之则错误。回放的过程如图2 - 2 所示。 7 电子科技大学硕士论文 图2 - 2 回放过程 嚣 这种方法非常逼真的模拟了用户如何使用产品，不需要在对被测产品内增加 硬件或软件模块，对产品的性能没有任何影响。他在回归测试中能很好的代替人 来完成工作。但是它也有如下的缺点【1 1 】【1 8 l ： 1 它的测试的准备工作量很大。如我们在前面的测试准备阶段讲到的。在录 制脚本的之前，我们要编写专门的程序来控制机械手的移动方向，距离。 如果系统的功能相对较多的话，测试的准备时间会很长。 2 只能用于回归测试。由于在测试之前必须录制测试脚本，而测试脚本是通 过照相器材和录音器材来记录的。如果增加新的功能，新功能的正确界面 显示还没有形成，那么就不能用照相器材和录音器材来记录信息，生成脚 本了。 3 系统本身复杂。系统设计到机械工程、图形图像解析、语音识别，复杂度 很高。自身出错的概率很大。如果测试系统发现了错误也很难验证究竟是 被测系统的错误还是测试系统的错误。 4 不能给出详细的出错信息。由于测试系统是依靠图像识别技术和语音识别 技术来识别界面信息的正确性，故它只能识别出某步操作是否正确，而不 能识别出具体错在什么地方。从而不能帮助开发人员迅速找到错误的原 因。 5 价格太昂贵。该测试系统需要大量的硬件和软件支撑。开发困难，价格非 常昂贵，非一般的公司能承受得起，一台这样的机器要好几百万美金。 如何得到一套对嵌入式软件黑盒测试行之有效的自动化方法，一直是自动化 测试人员努力的目标。 第三章基于m m i 的嵌入式软件自动化测试方法 第三章基于m m i 的嵌入式软件自动化测试方法 为了弥补上述方法的不足，提出一种基于m m i 的，纯软件实现的自动化测试 方法1 2 7 1 。m m i ：m a n u a lm a c h i n ei n t e r f a c e ( 人机接口) 。现在具有人机接口的嵌入 式系统越来越多，如：文曲星、对讲机、手机等等，而且是功能越来越丰富，上 层逻辑越来越复杂。这对该方法提供了广大的应用前景。 3 1 基本原理 人t n 试嵌入式软件的过程：按某某按钮，旋转某个转轴后，看输出屏幕， 指示灯的状态，听系统发出的声音，来判断当前的系统是否运行正确。 本文提到的自动化测试方法是通过用通俗易懂的脚本语言来记录人工操作和 人工操作后正确的人机接口信息。完成脚本编写后，让p c 机运行这些脚本，用脚 本解释器把它解释成嵌入式系统能够识别的各种命令。使用串口或u s b 口发送给 嵌入式系统，并接受系统返回的人机接口信息。最后p c 将这些信息和脚本中编写 好的期望值进行比较。如果相同，则系统软件正确，反之则错误。为了让嵌入式 系统能够识别、处理我们的控制命令，能够返回我们感兴趣的人机接口信息，需 要在嵌入式系统中加入测试代码去完成上面两个任务。整个测试过程与上一章讲 到的方法一样，也分为脚本生成和脚本回放两个阶段。 在脚本生成阶段有两种方法生成脚本 3 1 1 2 0 1 。 一、录制脚本：( 1 ) 操作p c 机上的嵌入式系统模拟界面，由p c 机将操作步 骤转化成测试脚本，再将脚本通过脚本解析器转换成嵌入式系统能识别的控制命 令发送给嵌入式系统。嵌入式系统接收到该命令后，通过事先嵌在系统里的测试 代码把控制命令转化成系统能识别的用户输入，从而达到模拟人工操作的目的。 ( 2 ) 在嵌入式系统响应了控制命令，状态变换后，由p c 机发送获取人机接口信 息的命令，从嵌入式系统中取得人机接口信息，通过p c 的解析后，转换成信息脚 本。信息脚本保存某步操作后的人机接口信息的正确值。录制脚本的过程如图3 - 1 所示。 9 电子科技大学硕士论文 包 图3 - 1 录制脚本过程 二、手工写脚本：根据定义好的脚本语言规则，由测试人员手工输入控制命 令和正确的人机接口信息。 脚本回放阶段刚开始和录制阶段一样，先把控制脚本解释成相应的命令( 控 制命令) 发送给嵌入式系统。然后发命令获得人机接口信息并解析它。最后把得 到的人机接口信息和信息脚本中的正确值进行自动化比较。如果一致，则被测系 统的软件正确，否则错误。回放过程如图3 2 所示。 篇缀滋黟 越魅幽罗篓蠹盏忿镕菇麓舞蕊貔， 图3 - 2 回放过程 包 第三章基于m m i 的嵌入式软件自动化测试方法 3 2 可行性分析 评价一种方法是否可行应从技术和商业价值这两个层面来看。技术上可行是 前提，如果只是一味的吹嘘其先进性，但却又没法子实现，那等于白谈。商业价 值上可行，是指使用了该方法后，是否显著的提高了生产效率，是否给使用者带 来的商业价值，带来了盈利。如果在其身上投入了许多，却没得到相应的回报， 那么谁也不会使用它。 3 2 1 技术可行性分析 本文的嵌入式自动化测试方法的核心是用软件来模拟人工输入，并从嵌入式 系统中获取人机接口信息传回给p c 做分析。只要能实现模拟人工输入，能获得人 机接口信息，能将这些信息传输回p c 从技术上来说就是可行的。 现在的嵌入式系统大多都有方便开发人员调试的接口，查看系统内部的信息。 一些嵌入式系统在系统内部也能模拟人工按键。把人机接口信息传回给p c 和模拟 人工输入都已不是技术问题。而对于人机接口信息，总有一些缓存存储它们以便 定时的刷新到屏幕。只要我们设法获取到这些存储缓存，就能抓住人机接口信息 并把他们发送给p c 。总的来说该方法在技术上是可行的。 3 2 2 商业价值可行性分析 随着嵌入式技术的发展，现在依靠重用底层的协议驱动模块，更改上层的应 用逻辑而形成不同的嵌入式产品的现象已不少见。对于这种情况，底层的协议驱 动模块不用花很多的精力去进行测试，大量的精力应当放在上层的应用逻辑模块 的测试工作上。这样黑盒测试在整个测试时间中占有很大的比重。使用自动化的 黑盒测试技术可以成倍的提高测试效率，最终形成盈利。嵌入式软件共用底层模 块如图3 3 所示。 圈 系统a i 应用逻辑b - _ 驱动协议g l 应用逻辑z l 驱动协议g 系统b系统z 图3 - 3 共用底层模块 1 1 电子科技大学硕士论文 随着嵌入式技术的发展，嵌入式系统越来越复杂，开发周期越来越长，功能 越来越多。由于功能的多样化，整个开发过程被分为很多的小阶段，每个阶段完 成一部分工作。这就要求在测试本阶段的功能时，还要去回归测试上一阶段完成 的功能。开发过程往前走一步，回归测试的量也就增加一截。这个雪球如此滚下 去，到接近最后完成时，回归测试的工作量是相当可观的。使用自动化的黑盒测 试技术，可以让机器代替人去做这些烦琐的事情，不但提高了测试效率，而且还 提高了软件的质量。回归测试工作量的演进过程如图3 ，4 所示。 卧昏豳日 图3 - 4 回归测试量 综上所述，该方法在技术上和商业价值上都是可行的。故我们可以继续研究 下去。那么在何处嵌入测试代码能达到模拟人工输入，返回人机接口信息的目的? 怎么定义、获取人机接口信息? 怎么定义脚本语言? 采用什么样的自动化比较技 术呢? 在随后的小节中，会有细致的分析。 3 3 内嵌测试代码 为什么要嵌入测试代码? 因为基于m m i 的自动化钡9 试方法需要模拟人工的输 入和返回人机接口信息，需要对控制命令解析、处理的模拟人工输入模块，需要 返回人机接口信息的模块。但是嵌入式软件本身可能并没有处理模拟人工输入的 模块，更没有返回人机接口信息的模块。所以我们只有自己在嵌入式软件内部加 入这些功能。 3 3 1 模拟人工输入模块 模拟人工输入模块主要是对p c 送来的控制命令进行解析，并把解析结果传给 系统的用户输入处理模块【1 2 1 1 2 7 1 。嵌入式系统处理用户操作的一般原理是，先通过 中断或者轮询获得硬件的状态，再结合相应的参数判断出用户具体的操作。( 如： 第三章基于m m 的嵌入式软件自动化测试方法 要判定长按还是短按，则需要记录按住的时间，把时间参数与按键状态结合起来) 最后把用户操作对应的m 通过消息发送到用户输入的消息队列，等待被处理。嵌 入式系统用户操作检测过程如下图3 - 5 所示。 捌翳缀麟斟嘲瑚嘲_ 曩硬件电路，矿i i 中断、轮询信息b 鬣瓿删# 女“女瓣簿7l _ j 图3 - 5 嵌入式系统用户操作检测 模拟人工输入可以不管它的底层硬件的中断、轮询和其它辅助参数，直接把 最后的用户操作对应d ，通过p c 端发送过来，放到用户的消息队列中。模拟人 工输入的原理如图3 - 6 所示。 震啼腻篇净孵癯l 图3 6 模拟人工输入方法 至于人机接口信息的定义、获取，会有专门的小节来讲述。 3 3 2 内嵌测试代码的原则 由于嵌入式系统是一个资源相对缺乏的系统，不能在系统中随意占用资源， 造成系统资源紧缺。也不能随意修改系统的原代码，随意修改会给被测系统带来 很大的影响。所以内嵌的测试代码必须有它的约束条件 9 1 1 堋 原则一、内嵌测试代码要求完全为增量代码，不影响原代码的执行流程，不 电子科技大学硕士论文 修改原内存变量的值。增量代码就是只能在原有代码的基础之上增加新的代码， 而不能对原来的某一行代码进行任何修改、删减。所有的测试代码都必须拥有自 己的内存变量，依靠原来变量来存储或者暂时存储跟测试有关的信息，都有可能 导致原变量被修改引起程序错误。例如有如下代码段： s e g l ： a = b + c ： d = c + b ： 你可以把它修改成： a = b + c ： f = c ： d = c + b ： 而不能修改成： a = b + d ： b = c ： d = c + b ： 允许，加入一行新的代码 不允许，这里把c 用d 替换 不允许，修改了原内存变量的值 也不能修改成： a = b + c ： 不允许，删掉了d = c + b ； 原n - 、加入的测试代码应尽可能少的占用系统资源，如系统的r a m ，r o m 。 这样做的目的是尽可能的降低对被测系统的影响，让被测系统在加入了测试代码 以后，其行为与没加入代码之前完全一样。 原则三、p c 能做的事情就一定不能让嵌入式系统来做。例如：有的系统是通 过交替的显示两个不同的缓冲b u f f e r 来形成闪烁字符串的效果。但如果两个缓冲 b u f f e r 的内容被赋成一样的值的话，那么最后的效果仍然是一个没有闪烁的字符 串。所以说判断字符串是否闪烁还要做进一步的分析。这个分析可以由嵌入式系 统来完成，也可以由p c 来完成。可能你会说就只是判断两个缓冲的内容是否相同， 要不了很多处理时间。请注意我这里只是举的一个简单的例子，试想如果你还要 判断它是全部闪烁还是部分闪烁，如果是部分闪烁，求出部分闪烁的内容。这种 情况就复杂了，要做很多工作，占用处理器时间。 不难看出上面的三个原则都有一个总的目的，减少内嵌代码对被测试的嵌入 式系统的影响。内嵌测试代码用来完成模拟人工输入和获取人机交互界面信息的 任务，它是整个测试系统的核心。由于该部分测试代码位于被测软件内部，为了 不让测试代码给被测软件带来负面的影响，这部分代码要求完全为增量代码，不 1 4 第三章基于m m i 的嵌入式软件自动化测试方法 影响原代码的执行流程，不修改原内存变量的值，所有的测试代码都必须拥有自 己的内存变量，并应满足执行效率快，不影响整个系统性能，占有r o m 空间小等 苛刻要求。 综上所述，现在的嵌入式系统功能越来越强大，内部结构也越来越复杂，几 乎所有的系统都遵从了软件分层的观点。在很多层中都可以嵌入代码已达到我们 的测试目的，那么在哪一层中嵌入测试代码是一个很难选择的问题。由于每一个 系统实现的差异性，每一个系统的插入位置可能都不一样，不过有一个统一的原 则可以用来衡量你选择的正确性，那就是：用最少的代码，最少的性能消耗完成 所有的工作。经验表明在检钡4 硬件中断的上层插入代码来模拟用户输入，在显示 驱动层中截获人机交互界面信息是一个不错的选择。 3 4 人机接口的定义及获取 嵌入式系统的人机接口给人以友好的提示，来表明系统现在处于什么样的状 态。对于系统测试人员来说，系统软件是否运行正常也主要通过人机接口来判断。 自动化测试工具要实现它的目标，则必须具有自动识别人杌接口，判定人机接口 是否正确的功能。那么怎么识别人机接口? 怎么来判定它是否正确? 这是本测试 方法的一大难点。 3 4 1 人机接口包含的内容 现在嵌入式系统的人机接口多种多样，有的复杂，有的简单。复杂的系统包 括声音，显示灯，l c d 等，这类系统以小灵通，手机为代表，而有的系统可能就 只有l e d 指示灯，如上网的调制解调器。所以从大的方面来分，嵌入式系统的人 机接口主要包括l e d 指示灯、l i c d 和系统发出的声音。其中l c d 又是最复杂， 也是最重要的一个模块。 l e d 指示灯通常用来标识系统处于某种大的状态。用它的开、关、闪烁以及 不同的颜色，组成不同的形状来区分不同的系统状态。因此，要核查一个l e d 的 显示是否正确，则需要记录它的开、关状态，它的颜色，亮度等级，是否闪烁等。 l c d 最能精确的反映出系统所处的状态，它同时也是最难以核实，捕获的。 l c d 通过字符串，图形来区分不同的系统状态。其中字符串具有字体、颜色、位 置等属性，图形具有大小，位置等属性。详细的属性说明如表3 - 1 所示： 电子科技大学硕士论文 表3 - 1 详细的属性说明 属性名字符串图形 字符串所占的屏幕大小，以图形所占的屏幕大小，以象素 大小象素为单位为单位 颜色 字符串所占在屏幕上显示的无此属性 颜色 字符串的左上角在屏幕中的图形的左上角在屏幕中的位 位置 位置，以象素为单位置，以象素为单位 字符串在屏幕上的显示层 图形在屏幕上的显示层次，确 次，确定是否被其它东西覆定是否被其它东西覆盖 层次 盖 光栅操作决定源象素和目标像素的叠决定源象素和目标像素的叠加 加方式方式 是否闪烁字符串是否闪烁图形串是否闪烁 可能有人会问，通过字符串的大小，颜色，位置不就能完全的确定一个字符 串的显示信息了吗? 为什么还要加入层次，光栅操作等属性呢? 这是由本文提到 的基于m m i 的自动化测试方法的基本原理决定的，具体原因我会在以后的章节里 讲到。 3 4 2l e d 和声音信息的获取 在嵌入式系统中每个声音一般都有一个唯一的i d ( 作为该声音的标识) 和固 定的音频编码。当要发某种声音时，系统调用发声函数将该声音的i d 放入到请求 队列，然后由请求队列的服务函数处理该请求。服务函数通过d 获取声音的音频 编码，再将音频编码传送给语音芯片就完成了整个发声的操作。我们可以在嵌入 式软件中嵌入代码将当前声音的m 或者语音编码截获后，发送给p c 。只要语音 芯片工作正常，我们就认为p c 得到的声音就是当前实际发声的声音。发送语音编 码给p c 从原理上讲比发送i d 要好，因为它避开了m 到语音编码之间的影射。但 是有的声音语音编码很大( 如一首歌曲) ，要完整的将编码发送到p c 需要很长的 时间，这是不合实际的。所以，发送声音在嵌入式系统中的i d 是唯一可行的方法。 获取声音的原理如图3 7 所示。 第三章基于m m i 的嵌入式软件自动化测试方法 麓熬熬零 蓥瓣巴夕 图3 - 7 获取声音原理图 l e d 也是通过一定的编码来控制其开关、闪烁。它的运行流程与声音的发生 过程类似，先把d 影射到l e d 的编码，再把这些编码发送给l e d 控制器，最后 l e d 控制器控制l e d 的发光状态。那么我们要截获l e d 的发光信息就可以参考 截获声音信息的方法。不同的是，把m 和编码发送给p c 都是可行的，因为l e d 的控制编码一般都很短。 大多数的嵌入式系统都会把当前应该显示的l e d 的m 存放在一个全局的缓 冲区里，以便由系统的定时刷新函数刷新到l e d 。这种系统获取它i d 就非常的容 易了。l e d 的截获原理如图3 8 所示。 搿鬻谬 k 您；翻 图3 - 8 l e d 的截获原理图 由此可见对声音和l e d 的截获非常的简单，那么获取人机接口的难点在哪 呢? 对l c d 显示界面的截获是获取人机接口信息的难点。 3 4 3l c d 显示界面的截获 前面我们已经提到了对l c d 的截获是难点，l c d 能够显示文本、图形和控件， 并具有许多其它的属性。截获i e d 显示界面的方法主要有两种：直接法( 点阵法) 和间接法。 1 7 电子科技大学硕士论文 3 4 3 1 点阵法 不论是字符串还是图形，最后在屏幕上的显示都是以点阵来构成的。因此如 果我们把这些点阵信息传送给p c ，p c 不就知道嵌入式系统屏幕上显示的是什么了 吗? 点阵法就是将被测系统的l c d 上实际显示的点阵信息传送给p c 保存下来， 以此来获得被测系统的显示内容。 点阵信息为马上传给l c d 显示的信息，它在整个显示流程中位于最下层。点 阵信息不需要其它底层软件对它进行任何的加工操作，其几乎完整的代表了实际 屏幕上的显示信息。故采用此方法截获的显示信息可靠性非常的高，不会由于底 层软件的缺陷而导致截获的信息与实际显示的不一致。由于嵌入式系统内部有专 门的缓存来存储点阵信息，内嵌的测试代码可以非常的简单，对被测系统的影响 也会降到最小。在实际的回放操作中，测试系统不会把点阵信息进行迸一步的解 析来提取具体的显示信息( 如实际显示的字符串，图形等) ，而是直接把以前保存 的正确的点阵信息与最新采集到的信息直接进行比较。这样自动化比较的逻辑非 常简单，可靠性也非常的高。这是点阵法的两个突出优点。 点阵法也有它的缺陷：由于无法从点阵信息中获取具体的显示信息，在被测 系统出现错误时，测试系统只能分析出该屏幕出错了，但不能明确的指出什么地 方错了，正确的值是多少。这样就不利于测试人员分析出错的原因。光依靠点阵 也不能判断闪烁的图元。 点阵法的另一个致命缺点是：如果屏幕的分辨率很大或者要求显示的颜色数 目很大时，会导致点阵信息很大，p c 端不便存储。例如一个嵌入式系统的屏幕分 辨率是2 4 0 3 2 0 ，可以显示的颜色为6 5 5 3 6 色。推算出一个像素需要1 0 9 e 6 5 5 3 6 = 1 6 个b i t 位来表示( 既两个字节) 。要存储整个屏幕所需的空间是2 4 0 x 3 2 0 2 = 1 5 3 6 m b 。假设整个测试过程中需要存储1 0 0 0 屏点阵信息，那么就要1 5 2 6 x 1 0 0 0 = 1 5 g b 的空间来存储。可能你会说1 5 g b 对现在的硬盘来说已经不算什么了，可 你试想如果屏幕分辨率增大，显示的颜色数目增加，需要存储的屏数增加，这些 都会对存储空间的需要带来爆炸式的增长。看来储存空间的限制的确给点阵法的 使用带来很大的麻烦。 虽然点阵法有它的缺点，但对于具有简单色彩显示，分辨率不是很高的系统 来说，点阵法受存储空间限制的缺点已不是问题。相反，其对被测系统影响小， 获得的显示信息准确度高，解析比较容易等优点大大的吸引了此类嵌入式系统采 用它。我们在来看一个例子：系统的屏幕分辨率是1 0 0 x 5 0 ，可以显示的颜色为 1 8 第三章基于m i v l 的嵌入式软件自动化测试方法 黑白两色。这样的系统存储一个屏幕