CN103729286B - 用于嵌入式设备的自动化测试平台 - Google Patents

Abstract

本发明公开了一种用于嵌入式设备的自动化测试平台，包括多个子系统，该多个子系统之间采用全息树实现通信和数据共享，该多个子系统包括一脚本子系统、一仪器子系统、一用户子系统、一日志子系统和一显示子系统，该脚本子系统用于执行测试脚本、收集测试结果，生成原始的日志节点以及根据测试结果构建和维护该脚本/日志子树；该仪器子系统用于维护该仪器子树以及同步远程仪器信息；该用户子系统用于完成该用户子树的构建以及持续更新；该日志子系统用于根据该脚本日志子树构建一独立于该全息树的纯日志树；该显示子系统用于读取该全息树中的各个子树以完成相应子系统的界面的构建。本发明所创建的平台在路由交换设备测试领域具有很好的通用性。

Description

用于嵌入式设备的自动化测试平台

技术领域

本发明涉及一种用于嵌入式设备的自动化测试平台，特别是涉及一种针对路由交换设备的自动化测试平台。

背景技术

如今测试软件所面临的主要挑战是：客户希望更多的软件功能，更快的交付速度，更便宜的造价成本，同时，也希望更好的软件质量，即使不能超过他们的期望，但至少要达到预期。

这意味着软件测试团队责任重大，更多的功能意味着每个测试的软件基线更大、更复杂，所以，对于一次产品开发需要交付更多的测试用例，但是“更快的交付速度”的需求，使得测试部门没有更多的时间完成所有测试。为了加快测试的进程，倘若投入更多的人力，例如增加测试工程师的数量，那样将会不可避免地增加测试成本。

另据，NIST(美国国家标准与技术研究院，National Institute of StandardsandTechnology)的报告“《软件测试基础设施不足的经济影响》，2002.5”估算，每年软件错误造成的经济损失将达到约59.5亿美元。

所以发展自动化测试非常必要。但是，一个行之有效的自动化测试需要一个平台作为依托。由于自动化测试会与被测试产品有很强的关联性，所以，目前还没有高度通用的平台出现，每个公司的标准都各有不同。

发明内容

本发明要解决的技术问题是为了克服现有技术中测试用例较多时无法避免成本的增加、自动化测试通用性较差的缺陷，提供一种通用性较强的用于嵌入式设备的自动化测试平台。

本发明是通过下述技术方案来解决上述技术问题的：

一种用于嵌入式设备的自动化测试平台，其特点在于，该自动化测试平台包括多个子系统，该多个子系统之间采用一全息树实现通信和数据共享，该全息树采用XML DOM的数据结构，多个子系统包括一脚本子系统、一仪器子系统、一用户子系统、一日志子系统和一显示子系统，该全息树包括脚本/日志子树、仪器子树、用户子树，其中，

该脚本子系统用于执行测试脚本、收集测试结果，生成原始的日志节点以及根据测试结果构建和维护该脚本/日志子树；

该仪器子系统用于维护该仪器子树以及同步远程仪器信息；

该用户子系统用于完成该用户子树的构建以及持续更新，为其它子系统(脚本子系统、仪器子系统、日志子系统和显示子系统)提供正确实时的用户状态信息并保证数据同步；

该日志子系统用于根据该脚本/日志子树构建一独立于该全息树的纯日志树，并且根据该纯日志树进行测试结果统计以及将统计结果写入该纯日志树的统计节点；

该显示子系统用于读取该全息树中的各个子树以完成相应子系统的界面的构建。

从静态的观点来看，本发明的主要内容是一棵“全息树”。所谓“全息树”，顾名思义，首先是用一个树型的数据结构作为基本支撑。具体实施上，我们选择W3C(万维网联盟)的扩展标记语言的文档对象模型(XML DOM)作为“全息树”的数据结构实体。其上承载的信息组织方式则是本设计的重点——亦即，“全息”的实现方式。

全息树，作为整个系统数据结构的骨架，支撑整个系统测试数据的存储。简单地说，任意时刻，当你将“全息树”存档，重新打开时，系统状态就会回到这一时刻，这有点像给系统拍摄的照片。

在这棵XML树(即全息树)上，主要包含几个子树，分别是：脚本/日志子树，用户子树，仪器子树(包含对测试仪器的常用设定)。这些子树又分别对应着动态的子系统，分别是：脚本子系统，日志子系统(内含统计子系统)，用户子系统和仪器子系统。

宏观上来看，整个平台是一个个系统模组拼接而成的。它们之间的无缝合作，在于他们使用“全息树”作为通信和数据共享的平台。目前该系统之间都是串行的任务协作机制，当一个子系统对“全息树”进行读写时，不会有另一个子系统对其进行读写。所以没有增加监视器系统来控制读写冲突。

目前的平台系统是一个事件驱动型系统，基于Tk(Tk是Tcl“图形工具箱”的扩展)设计的GUI(图形用户界面，Graphical User Interface)提供的鼠标或键盘事件进行系统任务。

优选地，该脚本/日志子树包括一控制节点，该控制节点用于表示测试标记和同步标记，该测试标记表示待测试的测试脚本，该同步标记用于不同窗口之间的同步更新。

该脚本/日志子树优势在于输入脚本存储位置自由，且脚本隶属关系层次分明。

优选地，该脚本/日志子树包括一类型节点，用于表示被测脚本文件夹中的主脚本。

优选地，该脚本/日志子树包括日志节点，该日志节点表示日志的原始记录。

优选地，该用户子树包括一全局节点，该全局节点表示测试中全局变量的设置。

优选地，该仪器子树中记录仪器信息，该仪器为自动化测试中的测试仪器。

在符合本领域常识的基础上，上述各优选条件，可任意组合，即得本发明各较佳实例。

本发明的积极进步效果在于：本发明所创建的平台在路由交换设备测试领域具有很好的通用性。

而且，作为一个自动化测试平台来讲，本发明所提及的架构具备的优势是：

1、良好的可扩展性——本平台将脚本子系统、仪器子系统、用户子系统和日志子系统全部有机集成在一棵树型数据结构上(即该全息树)，每一个子系统都是一棵子树，随需要可以摘除和添加具有很高的灵活性；

2、良好的跨平台能力——可以支持Windows、Mac OS、UNIX(一种多任务操作系统，支持多种处理器架构)、Linux平台应用(上述这些均为现今常用的操作系统)；

3、较少的脚本开发限制——为开发者减轻负担，缩短学习周期；本发明是一个脚本的批处理系统，并且没有对脚本编写设置特定的库作为API(Application ProgrammingInterface，应用程序编程接口)，所以不需要额外的API使用培训；

4、不限制脚本存放位置——本设计充分考虑了尽可能给脚本开发者自由的原则。从而对于脚本的位置并没有特别的限制；

5、便于数据统计——为结果统计的实现，提供良好的数据结构基础。

附图说明

图1为本发明的自动化测试平台的结构框图。

图2为本发明的显示子系统的工作流程图。

图3为本发明的用户子系统的工作流程图。

图4为本发明的仪器子系统的工作流程图。

图5为本发明的脚本子系统的工作流程图。

图6为本发明的日志子系统的工作流程图。

具体实施方式

下面通过实施例的方式进一步说明本发明，但并不因此将本发明限制在所述的实施例范围之中。

参考图1，本发明所述的用于嵌入式设备的自动化测试平台，包括多个子系统，该多个子系统之间采用一全息树6实现通信和数据共享，该全息树采用XML DOM的数据结构，多个子系统包括一脚本子系统1、一仪器子系统2、一用户子系统3、一日志子系统4和一显示子系统5，该全息树6包括脚本/日志子树、仪器子树、用户子树，其中，该脚本子系统1用于执行测试脚本、收集测试结果，生成原始的日志节点以及根据测试结果构建和维护该脚本/日志子树；

该仪器子系统2用于维护该仪器子树以及同步远程仪器信息；

该用户子系统3用于完成该用户子树的构建以及持续更新，为其它子系统提供正确实时的用户状态信息并保证数据同步；

该日志子系统4用于根据该脚本/日志子树构建一独立于该全息树的纯日志树，并且根据该纯日志树进行测试结果统计以及将统计结果写入该纯日志树的统计节点；

该显示子系统5用于读取该全息树中的各个子树以完成相应子系统的界面的构建。

其中，该脚本/日志子树包括一控制节点，该控制节点用于表示测试标记和同步标记，该测试标记表示待测试的测试脚本，该同步标记用于不同窗口之间的同步更新。

具体来说，该脚本/日志子树包括一类型节点，用于表示被测脚本文件夹中的主脚本。

其中，该脚本/日志子树包括日志节点，该日志节点表示日志的原始记录。

其中，该用户子树包括一全局节点，该全局节点表示测试中全局变量的设置。

其中，该仪器子树中记录仪器信息，该仪器为自动化测试中的测试仪器。

下面，以下文所述的一个全息树的示例，详细介绍本发明的技术方案。如下文所示，是脚本子树的一个示例，之所以采用这样的样式，是具有以下两点优势：

输入脚本存储位置自由——脚本子树，继承了脚本文件在磁盘文件系统中的父子关系。本发明利用这种天然的关系，使得作为系统输入的测试脚本可以存放在测试PC的任意硬盘位置上。不必放在某个特定的文件夹位置，为用户个人自由提供了空间。

脚本隶属关系层次分明——这个是为系统显示模块考虑的。因为在批量进行脚本测试的时候，会遇到这样两种情景：

a)哪个脚本在运行——往往会搞不清楚到底是那个项目的脚本在运行，但是，我们又恰前需要知道当前是那个项目的脚本在测试；

b)需要的项目脚本在哪——当我们需要确定一个项目和脚本的关系是，显示上必须一目了然，最好的显示方式是以项目名为文件夹名，并且将脚本文件夹放入其内。例如，假设有一个脚本S1属于某个项目P1,那么用户可以建立一个名字为P1的文件夹，然后将脚本文件夹S1包含其中即可。在本设计中，这样的层次很容易识别。当然，这部分涉及到GUI的设计便利性考虑。

鉴于这些实际的应用需求，最终选定了这种格式作为脚本树的结构。

先看最外层的<File></File>节点(即控制节点)，这个节点实际代表脚本集合依附于脚本的日志集。从本设计中来看，它就是我们前面提到的“脚本/日志子树”的树根。

在往下一层看，这一层就是具体对于与系统中的文件夹或者文件的节点了。理论上来讲，我们的设计支持“项目/子项目/…/脚本”这样的任意多级项目结构。

该控制节点的作用有以下两个方面：

测试标记——为主控程序提供测试必要性指示,即只有值为1的脚本是需要被测试的。

同步标记——为显示模块的不同窗口之间同步，提供同步机制。当用户在配置中删减或者增加了脚本时，当前主界面必须又一个同步机制，而通过遍历树的这个标志，就可以对主界面窗口正确更新。而主控程序正式通过这个标志来感知用户变更的。

除了，“控制节点”之外，本设计的亮点还有一个“类型节点”——<type></type>。系统会检查type(类型)为file(文件)的<File></File>节点，如果其名称为“MAIN.tcl”，那么他将会被系统认为是被测脚本文件夹中的主脚本。测试结果会写成一个<log>节点(日志节点)，并将这个<log><log>节点，挂载在改其下，作为日志原始记录。这就是为什么把脚本子树和日志子树合称为“脚本/日志子树”。

它只是原始记录，并不包含统计结果，而这个结果在另外一棵树上，这就引出了这个<log>的另一种意义：作为日志子系统的数据基石。在这个系统的构建子系统的作用下，会将“纯日志树”，从“脚本/日志子树”中分离出来；进一步，通过统计子系统，将统计结果计算出来，并且挂载到“纯日志树”中。

需要特别之处的是：这里提到的一个关键词是“纯日志树”而不是“纯日志子树”。原因，从XML DOM的角度来看。它并不是“全息树”的一棵子树，而是由“全息树”转换而来的(这里所说的转换动作是有日志子系统完成的，“纯日志树”是指由“全息树”通过日志子系统的构建子系统映射出来的全新的树)。它是日志子系统的数据存取的真正数据基础。

接着，介绍该用户子树。用户子树包含了用户的自定义习惯设定，例如包括被测软件(Application Under Test)版本号，被测设备(Device Under Test)硬件识别SN号码(序列号)，表示重测模式，上次运行结束时GUI窗口中最后一条记录的序列号，是否显示启动提示框的标记，系统启动时的配置信息加载方式和批处理测试全局变量设置等。

这棵子树的设计意义，在于：

√为系统配置信息持久性提供支持；

√为用户子系统提供运行时支持。

在用户子树的设计中，需要介绍一下“global(全局)”节点，它为用户自定义变量提供数据持久性支持的，其它的节点都是用于对系统自身数据持久性提供支持的。

有这样一种需求情境“当用户进行一个批处理测试操作的时候，往往会有一些固定的全局性环境变量。他们希望将这些变量保存在系统中，以便于同步全局测试环境。”例如，现在有一个批处理测试任务。其中有个全局的ip地址(所谓IP地址就是给每个连接在因特网上的主机分配的一个32比特地址)，它是这个批次的脚本需要的公共参数，用户在编写脚本的时候，会反复使用它。那么这个ip变量就很适合作为全局变量存在于系统中。然后，程序员就可以只要包含一个公共的“头文件”就可以引用这些变量了。

给这个“头文件”取个固定的名称，例如“global.tcl”(假设使用Tcl作为脚本开发语言)，相应地，为了持久性的需要，系统应该为这个global.tcl提供一个“数据存储筐”。这个筐就是用户子树中的“global”节点。如您所见，在这个节点中包含了很多“var”节点(表示一个变量)，每个“var”节点，包含两个子节点，分别为“name”——表示变量名，和“value”——表示变量值。

该用户子树中还可包括一个“toplimit”节点，其为一个人为限制表示默认可添加的最多变量数目。这个值不是个强制值可以根据需要修改。

用户子系统会根据“global”这个节点的信息，形成“global.tcl”的最终内容。

接下来介绍该仪器子树，为什么需要仪器子树？因为自动化测试中会涉及到各种各样的仪器，每一台仪器的信息理应保留在我们的“全息树”中。因为，仪器本身是测试系统的一部分(这里的仪器，不是确指某种特定的仪器设备。而是对测试中可能用到的所有仪器设备的共性的抽象概念。反映在仪器子树中的是它的具体表现。不同的仪器虽然各有特性，但是从平台的角度来看，为了便于统一管理，我们将所有仪器的共性抽象出来，并尽可能地体现各仪器的个性。可以理解为一个通用的仪器模型。它的具体形象就是仪器子树所呈现的结构)。

仪器子树的树根由四部分构成：

√仪器类型——“type(类型)”节点，这个节点为仪器子系统提供支持，帮助仪器子系统选择合适的数据处理方式，来获取参数并用以设置对应的仪器设备。

√仪器名称——“instrumentname”节点，表示仪器在公司中的唯一识别号。

√连接设置——“connectset”节点，这个是任何一台仪器都有的部分；

√属性——“attributes”节点，这个节点之所以不作具象的限定，是因为不同“仪器类型”的测试设备在自身属性上面会有相当大的差异。甚至在设计思想上也会有很大的差异。仪器子系统会根据相应的“仪器类型”，选择合适的“属性”处理方式。

仪器子树体现的是系统对于测试仪器的数据抽象模型，它的意义是：

√为系统提供持久性数据支持；

√为仪器子系统提供运行时数据支持。

以上是从静态的视角来描述的系统特性。

接下来，从动态视角来介绍子系统的运行机制及其协作。

宏观上来看，整个平台是一个个系统模组拼接而成的。它们之间的无缝合作，在于他们使用“全息树”作为通信和数据共享的平台。目前该系统之间都是串行的任务协作机制，当一个子系统对“全息树”进行读写时，不会有另一个子系统对其进行读写。所以没有增加监视器系统来控制读写冲突。

目前的平台系统是一个事件驱动型系统，基于Tk设计的GUI提供的鼠标或键盘事件进行系统任务。图1中箭头方向代表数据流向。从图中可以看出，“全息树”是各子系统的共享资源。共享规则如下：

√各子系统对全息树都有“读”取全部信息的权力；

√各子系统只能对自身的子树进行“写”操作。

接下来，详细介绍几个子系统。

显示子系统，负责界面管理。具体包括，平台界面的构建、删除和布局。

依据以上规则，由于它没有自己的子树，所以不能对全息树进行数据修改。从“全息树”的角度来看，它是最大的数据消费者(它不对全息树直接贡献信息，但是一直在获取信息。事实上，显示子系统是通过其他途径反馈信息的)，因为它需要读取“全息树”中的各个子树以完成相应子系统的界面的构建。

显示子系统的输出有两方面：GUI和用户输入的消息。

显示子系统通过自身构建的GUI接收用户输入，并通过自身接口部件，将输入信息正确地传递给其它几个子系统。从而由相应的子系统完成对全息树信息的更新。显示子系统的工作流程见图2，其中“加载模式”——是指平台为了实现持久性，而提供的一种对上次状态的恢复机制。具体情境是：每次平台启动时会提醒用户选择是否将上次的配置信息或者全部信息加载到本次测试中。用户有可能选择“不加载”、“加载配置”和“加载全息”这三种模式，此即所谓“加载模式”。

其中，“遗留全息树”是指上次执行系统结束时，默认保存的全息树的磁盘文件(或者是用户在上次系统执行过程中的某个时间点手动保存的一棵全息树文件)。由于相对于本次系统执行，它并不属于本次系统的全息树，但是它又对本次全息树的构建具有影响。

用户子系统，是一个收集用户自定义数据和习惯配置选项的系统。它通过显示系统获得用户输入，然后将这些输入经过加工以后存入用户子树，并且完成系统变更同步。

用户子树与用户子系统的关系为，对于用户子系统来说，用户子树是核心维护内容。从系统I/O(输入/输出)的角度来讲，用户子树即使用户子系统的输入，也是它的输出。如何理解这个问题，应该从用户子系统的核心功能来解释。用户子系统的核心功能是：“完成用户子树的构建并持续更新，为其它子系统提供正确实时的用户状态信息；并保证数据同步”这其中，体现了两点：

第一，构建和更新时，用户子树其实是用户子系统的输出，如图3所示。

第二，当保持数据同步时，用户子树是其输入。用户自定义数据会被测试脚本引用。所以，必须保持显示系统收到的数据与用户在系统外修改过的配置文件保持同步。

图3中，“一般数据”中的“一般”是相对用户子树而言的。“一般数据”就是指用户子树上面除了“global”节点之外的其他信息。“global”节点的特殊之处在于，它存储的数据会被测试脚本引用为公用信息。“外部文件”是指有“global”节点生成的供测试脚本加载的磁盘文件。

仪器子系统的主要工作是维护仪器子树。和远程仪器信息同步机制。

在第一个任务中，系统输入主要来自其他子系统对仪器配置修改意见反馈，输出则是同步更新的仪器子树；第二个任务中，系统输入主要来自于远程仪器的请求命令。

图4示出了仪器子系统的工作流程。其中，“远程服务器”是本平台仪器子系统的一部分。是自行创建的服务程序。这些程序负责在不同的PC(个人计算机)上完成特定的任务。它们总是从平台仪器子系统中获取指令并在其所属PC上完成指定动作。最后将工作结果返回平台仪器子系统。

脚本子系统则是整个平台的核心，如果没有这个子系统平台就失去了意义。它的作用是利用其它子系统提供的信息作为材料，执行真正的测试调度和原始结果生成的操作。日志子系统的工作将基于脚本子系统的工作成果。

在“全息树”中的“脚本/日志子树”是本子系统对应的子树，也就是说，脚本系统可以对这棵子树进行写操作。但是，稍后介绍的日志子系统则不能。日志子系统只能对脚本/日志子树进行“读”操作。这就是为什么说日志子系统的工作需要建立在脚本子系统的工作的基础至上。由于这棵子树是脚本子系统和日志子系统协作的基础数据结构，所以他的命名为“脚本、日志子树”。图5使出了该脚本子系统的工作流程。

脚本子系统的主要工作有：

构建和维护“脚本、日志子树”；

执行测试脚本；

收集测试结果，生成原始的日志节点(原始日志节点即是脚本/日志子树中的<log>节点)。

日志子系统负责系统中一切日志的维护工作。它的数据素材输入是脚本/日志子树。日志系统首先会读取“脚本/日志子树”中的原始Log信息。然后，构建一棵“纯日志树”。图6所示为该日志子系统的工作流程，日志子系统的工作内容主要有：

根据脚本子系统构建的“脚本/日志子树”构建一棵独立于“全息树”的“纯日志树”；

以纯日志树为依托，进行测试结果统计。并将统计结果写入纯日志树的统计节点；

存储日志到磁盘。

本发明所创建的平台在路由交换设备测试领域具有很好的通用性。

虽然以上描述了本发明的具体实施方式，但是本领域的技术人员应当理解，这些仅是举例说明，本发明的保护范围是由所附权利要求书限定的。本领域的技术人员在不背离本发明的原理和实质的前提下，可以对这些实施方式做出多种变更或修改，但这些变更和修改均落入本发明的保护范围。

Claims (6)

1.一种用于嵌入式设备的自动化测试平台，其特征在于，该自动化测试平台包括多个子系统，该多个子系统之间采用一全息树实现通信和数据共享，该全息树采用XML DOM的数据结构，该多个子系统包括一脚本子系统、一仪器子系统、一用户子系统、一日志子系统和一显示子系统，该全息树包括脚本/日志子树、仪器子树、用户子树，其中，

该脚本子系统用于执行测试脚本、收集测试结果，生成原始的日志节点以及根据测试结果构建和维护该脚本/日志子树；

该仪器子系统用于维护该仪器子树以及同步远程仪器信息；

该用户子系统用于完成该用户子树的构建以及持续更新，为其它子系统提供正确实时的用户状态信息并保证数据同步；

该日志子系统用于根据该脚本/日志子树构建一独立于该全息树的纯日志树，并且根据该纯日志树进行测试结果统计以及将统计结果写入该纯日志树的统计节点；

该显示子系统用于读取该全息树中的各个子树以完成相应子系统的界面的构建；

全息树，是用一个树型的数据结构作为基本支撑，作为整个系统数据结构的骨架，支撑整个系统测试数据的存储。

2.如权利要求1所述的自动化测试平台，其特征在于，该脚本/日志子树包括一控制节点，该控制节点用于表示测试标记和同步标记，该测试标记表示待测试的测试脚本，该同步标记用于不同窗口之间的同步更新。

3.如权利要求1所述的自动化测试平台，其特征在于，该脚本/日志子树包括一类型节点，用于表示被测脚本文件夹中的主脚本。

4.如权利要求1所述的自动化测试平台，其特征在于，该脚本/日志子树包括日志节点，该日志节点表示日志的原始记录。

5.如权利要求1-4中任意一项所述的自动化测试平台，其特征在于，该用户子树包括一全局节点，该全局节点表示测试中全局变量的设置。

6.如权利要求1-4中任意一项所述的自动化测试平台，其特征在于，该仪器子树中记录仪器信息，该仪器为自动化测试中的测试仪器。