CN111190812A

CN111190812A - 基于嵌入式设备的自动化测试框架

Info

Publication number: CN111190812A
Application number: CN201911288952.7A
Authority: CN
Inventors: 张庆松; 赵福梅
Original assignee: CETC 32 Research Institute
Current assignee: CETC 32 Research Institute
Priority date: 2019-12-12
Filing date: 2019-12-12
Publication date: 2020-05-22
Anticipated expiration: 2039-12-12
Also published as: CN111190812B

Abstract

本发明提供了一种基于嵌入式设备的自动化测试框架，包括：调用模块：作为整个自动化测试框架的引擎，驱动所有其他模块，首先部署测试参数，调用测试用例以及逻辑关系，运行测试用例，产生测试数据，测试报告，邮件以及日志；数据包收发模块：对测试仪器的API接口进行重新封装，构造需要的通信协议包，并定义发送、接收和解析各通信协议包函数，方便测试用例中进行调用；会话模块：在测试过程中，向待测设备传送需要的操作命令，实现与待测设备之间的交互。本发明在设计上，框架系统突破了传统自动化测试方法，采用分层设计思想，将框架设计模块与测试脚本的业务模块分离，这大大方便后期新功能测试的代码维护。

Description

基于嵌入式设备的自动化测试框架

技术领域

本发明涉及自动化测试技术领域，具体地，涉及一种基于嵌入式设备的自动化测试框架。

背景技术

自动化测试在软件发展日新月异的今天，已成为软件测试领域里一个越来越被认可的趋势和潮流。很多有一定规模的企业都已经在团队内部组建自己的自动化团队，来创建自动化测试框架，并将其运用实际的软件测试工作中，同时还将其技能作为人才能力考核的一项重要标准，如规模较大的企业，国外的谷歌，微软，IBM，国内的华为，中兴，联想等都已有较成熟的自动化测试框架。

自动化测试框架是把以人为驱动的测试行为转化为机器执行软件程序的一种过程，软件测试自动化的研究领域主要集中在软件测试流程的自动化管理以及测试用例的自动化执行，与手工测试相比，自动化测试的优势尤为突出。首先自动化测试框架可以提高测试效率，使测试人员更加专注于新的测试模块的建立和开发及维护，从而提高测试的覆盖率，其次，自动化测试框架有利于测试资产的数字化管理，使得测试资产在整个测试生命周期过程中可以得到极大的复用，这个优点在功能测试和回归测试中表现的更加明显，另外，测试流程自动化管理可以使企业的测试活动开展更加过程化、标准化，减少手工测试的随机性，这也是CMMI流程所提倡的活动过程，自动化测试框架的主要思想是把测试脚本进行抽象化，使得测试脚本重复使用率更高，各模块之间结构更清晰，更易于后期维护；同时，让非技术人员或完全不懂测试脚本的新员工在不完全不了解测试脚本的情况下，也能够运用自动化测试工具进行自动化测试，或者建立自动化测试计划，促使整个测试项目快速进行。

1)框架系统突破了传统自动化测试方法，采用分层设计思想，将框架设计模块与测试脚本的业务模块分离

2)在框架开发过程中将很多重复使用的冗余代码做成通用模块，使得代码结构优化，性能提升。

3)本测试框架开发了非常灵活，人性化的GUI设计，可以十分方便测试人员配置测试套件

4)自动化测试框架在设计之初充分考虑今后的扩展性问题，遵循软件设计原则：模块的高内聚和低耦合，充分考虑框架的扩展性接口，提供邮件服务器连接的接口，实现测试状态的邮件实时通知，提供BUG数据库连接接口，实现BUG的自动提交。

5)自动化测试框架捕捉当前自动化测试中的关键问题，充分利用现有资源并将其整合到框架中，比如，可以用版本控制工具ClearCase，VSS等来对脚本进行版本控制，用版本管理工具来进行BUG的提交，跟踪管理。

如今的软件产品，功能繁多，流程复杂，相对应的软件测试工作也随之复加。且测试中的许多操作过程都是重复性的、非智力性的和非创造性的，同时，重复的过程越精确越容易复现出缺陷，这样的重复性工作，计算机就比人更适合去完成，总结手工测试的不足之处如下：

1.手工测试很难做到覆盖所有代码路径的测试情况。

2.在软件开发的不同阶段，都需要简单的功能测试，这些功能测试用例具有一定的机械性、重复性，而且工作量相对较大，周期较短。

3.许多死锁、资源冲突、多线程，内存泄露等有关的缺陷，通过手工测试很难捕捉到。

4.进行系统压力、性能测试时，需要模拟大量数据或大量并发用户同时对系统进行操作，读写数据等应用场合时，很难通过于工测试来进行实际测试。

5.在对系统进行稳定性及可靠性测试时，需要长时间模拟系统运行，来验证系统是否能够长时间稳定运行，这也是手工测试很难模拟的。

6.在整个项目时间很紧迫的情况下，如需要1个人在2天内执行完上千个测试用例，这个也是手工测试无法实现的。

正是手工测试在上面情况下碰到种种问题，从自动化测试框架可以解决以上手工测试所无法解决的种种弊端，自动化测试是相对手工测试而存在的，主要是通过所开发的软件测试工具、测试脚本等来实现测试用例的执行，具有良好的可操作性、可重复性及高效率等特点。其主要好处有：

1.缩短软件开发测试周期，提高产品质量，可以让产品更快投放市场。

2.测试效率大大提高，可以充分利用软硬件资源，尤其在回归测试汇中，特别在软件版本修改比较频繁时，效果尤为突出，回归测试的的执行步骤与测试用例是早先设计好的，测试结果的期望值也是完全可以预料的，只要执行自动化测试软件就可以在较短时间内实现一次或多次回归测试。

3.大大节省人力资源，降低测试成本，在较少的时间内执行更多的测试用例，使繁琐的测试简单化，同事也可以提高测试人员的工作积极性，将测试技术人员解脱出来并投入更多精力来设计更完善的测试用例。

4.通过自动化测试框架增强对产品的稳定性和可靠性的测试力度。

5.提高软件测试的准确度和精确度，增加软件产品在客户心目中的信任度。

6.自动化测试框架的应用使测试工作相对比较容易，但却能保证更高质量的软件产品。

7.自动化测试框架可以执行手工无法进行的一些测试场景，如压力、性能，稳定性，可靠性测试。

针对上述现有技术中的缺陷，本发明要解决的技术问题体现在以下几点：

1)支持多操作系统平台，自动化测试框架应支持多种操作系统平台，如常见的Windows,Linux,Unix等操作系统。

层次化，模块化设计

2)自动化测试框架应层次明确，模块独立，平台模块和测试用例的业务模块相互独立，需要新增测试用例或修改测试用例时，不需要改动平台模块的代码。

3)灵活执行测试用例

在不同测试阶段，我们需要构造不同测试套件来调用测试用例。比如：

在测试用例全覆盖阶段(TCFP)执行所有的单独的测试用例。

在健全测试(Sanity Test)或冒烟测试(Smoke test)阶段批量执行部分测试用例。

在回归测试阶段(Regression Test)只执行失败的测试用例

4)可扩展性

自动化测试框架应支持不同的待测设备，要考虑后续新产品的扩展，做到可以支持各种同类型的嵌入式通信设备。只有充分考虑到后续的扩展性才能在尽可能的减少对测试平台模块的维护工作，减少开发资源和成本，同时，在有新功能开发需求时，自动化测试框架不受任何影响，只要增加相应业务模块的测试脚本就可以了。

5)操作简单，界面友好

为测试工程师提供简单易用的操作界面，只需要简单的测试环境配置就可以执行测试用例的自动化测试，在完全无外界干预的情况下，执行单个或多个测试用例，并进行全程测试日志的记录跟踪，并将执行结果和期望结果进行对比分析和统计，生成测试报告。

6)调用测试仪API接口

调用网络分析仪应用接口实现收发包及分析验证测试,实现对网络分析仪的自动化控制，提高开发和测试效率。

7)实现交互式嵌入式设备的功性能在无人干预情况下的自动化测试，对嵌入式设备进行协议一致性等功能性测试。

8)通过调用层驱动自动化测试过程，调用层读取测试环境的配置文件中的参数以及测试套件，再通过测试套件的实际逻辑解析出所有测试用例，并进行测试用例的执行，测试用例可以调用测试仪器的API接口以及Lib库进行测试用例的设计及验证，执行完测试用例后，对生成测试报告，并打印测试过程中的所有日志信息。

9)动化测试框架捕捉当前自动化测试中的关键问题，充分利用现有资源并将其整合到框架中，比如，可以用版本控制工具ClearCase，VSS等来对脚本进行版本控制，用版本管理工具来进行BUG的提交，跟踪管理。

10)动化测试框架在设计之初充分考虑今后的扩展性问题，遵循软件设计原则：模块的高内聚和低耦合，充分考虑框架的扩展性接口，比如连接测试用例数据库，从而自动获取测试用例套件及用例，提供邮件服务器连接的接口，实现测试状态的邮件实时通知，提供BUG数据库连接接口，实现BUG的自动提交等等。

相关检索结果1：

申请(专利)号:10.16520/j.cnki.1000-8519.2018.08.035

名称：一种基于RobotFramework的嵌入式软件自动化测试框架

摘要:在嵌入式软件开发过程中,对于复杂的大规模嵌入式软件,其生命周期长,在软件变更后,需要持续多轮回归测试。为了支持对变更后的嵌入式软件进行充分验证,提升嵌入式软件回归测试的效率,本文给出了一种基于Robot Framework的嵌入式软件的自动化框架,描述了自动化测试框架的功能划分及测试过程。

技术要点比较：

1.《基于嵌入式设备的自动化测试框架的设计与实现》自动化框架软件通过调用层驱动自动化测试过程，调用层读取测试环境的配置文件中的参数以及测试套件，再通过测试套件的实际逻辑解析出所有测试用例，并进行测试用例的执行，测试用例可以调用测试仪器的API接口以及Lib库进行测试用例的设计及验证，执行完测试用例后，生成测试报告，并打印测试过程中的所有日志信息。

2.《基于嵌入式设备的自动化测试框架的设计与实现》可以通过多种方式登录嵌入式设备，相对嵌入式网络通信产品而言，登陆到待测设备的操作方式主要包括WEB，CLI，Telnel,Serial(串口)等等，在测试框架中可以对这些常用登陆方式进行封装，在此，我们将与待测设备之间的命令消息交互过程，称之为会话(Session)；在测试过程中，我们只需要向待测设备传送需要的操作命令就可以实现与待测设备之间的交互。

3.《基于嵌入式设备的自动化测试框架的设计与实现》本自动化测试框架中提供常用协议栈的数据包，方便在进行协议一致性测试时的调用，对网络通信设备的自动化测试过程中，经常需要发送接收数据流，进行协议一致性验证。

4.《基于嵌入式设备的自动化测试框架的设计与实现》引入了分层设计思想，极大了便利了以后自动化框架的业务更新维护，大致可分为4层：调用层，GUI层(图形用户界面)，参数层，通用模块层,将平台模块和业务模块独立开来，平台模块包括TCL/TK库、Expect库(TCL扩展库，用以实现自动交互功能的套件)、SmartBits库(网络分析仪)、通用函数库(公共函数)、GUI模块、会话模块、日志模块、待测设备及系统参数、测试报告模块、邮件模块等；业务模块及测试用例库，包括业务逻辑，测试数据，调用网络分析仪收发数据包，并分析测试结果。

5.《基于嵌入式设备的自动化测试框架的设计与实现》自动化测试框架通过测试仪器商提供的API接口调用网络测试分析仪器，并对API接口进行了2次封装，极大的方便在后续设计测试用例时进行调用。

6.本测试框架开发了非常灵活，人性化的GUI设计，可以十分方便测试人员配置测试套件，选择在本次测试流程中需要执行的测试用例，以及需要选择的功能参数等。

7.自动化测试框架在设计之初充分考虑今后的扩展性问题，遵循软件设计原则：模块的高内聚和低耦合，充分考虑框架的扩展性接口，比如连接测试用例数据库，从而自动获取测试用例套件及用例，提供邮件服务器连接的接口，实现测试状态的邮件实时通知，提供BUG数据库连接接口，实现BUG的自动提交等等。

8.自动化测试框架捕捉当前自动化测试中的关键问题，充分利用现有资源并将其整合到框架中，比如，可以用版本控制工具ClearCase，VSS等来对脚本进行版本控制，用版本管理工具来进行BUG的提交，跟踪管理，自动化框架着重实现无人值守的执行测试用例，生成测试分析报告等问题。

发明内容

针对现有技术中的缺陷，本发明的目的是提供一种基于嵌入式设备的自动化测试框架。

根据本发明提供的一种基于嵌入式设备的自动化测试框架，包括：

调用模块：作为整个自动化测试框架的引擎，驱动所有其他模块，首先部署测试参数，调用测试用例以及逻辑关系，运行测试用例，产生测试数据，测试报告，邮件以及日志；

数据包收发模块：对测试仪器的API接口进行重新封装，构造需要的通信协议包，并定义发送、接收和解析各通信协议包函数，方便测试用例中进行调用；

会话模块：在测试过程中，向待测设备传送需要的操作命令，实现与待测设备之间的交互；

日志模块：跟踪每条测试命令与待测设备的交互信息记录，记录系统在执行测试命令后的执行情况并返回结果；

测试报告模块：在执行完自动化测试脚本后，自动生成一份清晰明了测试统计结果给相关人员；

邮件发送模块：在自动化测试框架执行完成后将测试报告和测试日志以附件的方式发送给测试人员及指定的抄送人员；

测试环境参数模块：读取测试环境中配置的参数，包括待测设备的地址，端口等属性，测试仪器的地址以及端口；

测试用例模块：包括所有功性能测试脚本。

优选地，所述API接口：

在对网络通信设备的自动化测试过程中，需要发送接收数据流，进行协议一致性验证，需要调用测试仪器商提供的API接口进行数据发送和接收。

优选地，所述功性能测试脚本包括：

IGMP、QoS以及VLAN协议栈的测试集

优选地，所述调用模块包括：

main.tcl函数模块：判断自动化测试框架的运行环境，并调用gui.tcl函数模块；

gui.tcl函数模块：设计用户对测试拓扑环境的配置界面，包括待测设备，测试仪器的物理地址及拓扑端口，相应测试模块的参数种类选择。

main_exec.tcl函数模块：调用测试仪表lib库，并对测试仪表进行预设置，远程登陆(telnet)到待测设备系统。

优选地，包括：

调用层；包括主函数和图形用户界面；

测试用例层；包括业务上的功能性能测试用例以及测试数据；

参数层；包括待测设备所构建的测试环境中的各种参数；

通用模块层：包括与业务模块相对独立的各通用公共模块。

优选地，所述调用层：

调度测试用例库中的测试用例套件并进行依次执行，同时调用各测试用例下的配置文件。

优选地，所述参数层包括：待测设备的IP地址、待测设备的收发数据包端口号、测试仪器IP地址、测试仪器的收发数据包端口号以及软件版本信息。

优选地，通过调用层驱动自动化测试过程，调用层读取测试环境的配置文件中的参数以及测试套件，再通过测试套件的实际逻辑解析出所有测试用例，并进行测试用例的执行，测试用例可以调用测试仪器的API接口以及Lib库进行测试用例的设计及验证，执行完测试用例后，对生成测试报告，并打印测试过程中的所有日志信息；

优选地，所述测试套件是指将一类或具有相同测试特点的测试用例集合在一起。

与现有技术相比，本发明具有如下的有益效果：

1)本发明在设计上，框架系统突破了传统自动化测试方法，采用分层设计思想，将框架设计模块与测试脚本的业务模块分离，这大大方便后期新功能测试的代码维护。

2)针对通信产品测试特点，在框架开发过程中将很多重复使用的冗余代码做成通用模块，使得代码结构优化，性能提升，如会话模块中的Telnet会话，Console口会话，Command会话等，使得业务模块中的测试脚本开发更加简化，测试脚本中的测试操作只需要通过发起相应的会话，就能方便地执行相应的测试操作。

3)本测试框架开发了非常灵活，人性化的GUI设计，可以十分方便测试人员配置测试套件，选择在本次测试流程中需要执行的测试用例，以及需要选择的功能参数等。

4)自动化测试框架在设计之初充分考虑今后的扩展性问题，遵循软件设计原则：模块的高内聚和低耦合，充分考虑框架的扩展性接口，比如连接测试用例数据库，从而自动获取测试用例套件及用例，提供邮件服务器连接的接口，实现测试状态的邮件实时通知，提供BUG数据库连接接口，实现BUG的自动提交等等。

5)自动化测试框架捕捉当前自动化测试中的关键问题，充分利用现有资源并将其整合到框架中，比如，可以用版本控制工具ClearCase，VSS等来对脚本进行版本控制，用版本管理工具来进行BUG的提交，跟踪管理，自动化框架着重实现无人值守的执行测试用例，生成测试分析报告等问题。

4)成效上，自动化测试框架优势也是非常明显的，下面分别对几个版本在回归测试中使用该自动化测试框架的测试效率进行对比分析，如下表，我们分别通过普通的手工测试和运用自动化测试分别对待测产品的其中三个功能进行了对比测试，EACL功能，VLAN功能，QoS功能，如果通过手工测试的话，分别需要480分钟,960分钟，1200分钟；如果使用自动化测试框架进行测试的话，仅仅分别需要10分钟，20分钟，30分钟，我们知道，现在的通信网络产品，功能越来越多，测试对象也随之越来越复杂，BUG的大量出现导致版本的频繁修改，这就需要大量的人力花费在测试过程中，如果所有的工作都局限于手工测试，这就很难在规定的项目计划时间内完成测试任务，因为测试部门的员工数目是有限的，工作时间是有限的，要想在规定的计划时间里完成测试用例的执行，自动化测试显得不可或缺，它的出现极大的缩短测试时间，从下表来看，自动化测试的时间差不多只占手工测试的1/40～1/50左右，而且自动化测试可以安排在工作之余的时间，如晚上或周末等时间，综上所述，随着待测产品的功能的不断叠加，修改版本的不断增加，自动化测试效率越趋明显。

表1测试效率对比表

另外，通过表2，我们再通过BUG数量的比较来分析手动测试和自动化测试对测试效率的影响，从下表可以看出，我们就同一版本同一产品功能进行对比测试，在版本3.11.3.6中，通过手工测试，EACL，VLAN，QoS功能分别被发现有7,4,9个BUG，而通过自动化测试，这三个功能分别被发现有10,6,9个BUG，为什么自动化测试经常比手工测试发现更多的BUG呢，分析如下：由于软件版本的较高频率的更新，测试人员经常会麻痹大意，自认为有些功能在上个版本中已经多次重复测试过，所以这是简单验证或者直接跳过这些测试用例，这就使得测试用例的执行率大大折扣，无法保证测试的覆盖率，但自动化测试却能不折不扣的保证测试用例的覆盖率，众所皆知，软件测试覆盖率是用来判断测试是否进行充分的重要依据。测试覆盖可分为逻辑覆盖、功能覆盖以及需求覆盖等；逻辑覆盖又可分为语句覆盖、路径覆盖、条件覆盖、判断覆盖等；从自动化测试实施应用来看，由于自动化测试的测试用例的脚本都是和手工测试一一对应的，这就使得自动化测试能很好地保证测试过程的完整性，减少人工测试的随意性，从而提高产品质量。

表2测试BUG数量对比表

由此可见，自动化的尽早引入对测试效率的帮助越大，总结如下：

(1)提高产品质量而减少测试成本

随着在自动化测试框架下进行的测试次数的增加，自动化测试的优势越明显，相比手工测试，成本越低，从长远来看，自动化测试的成本远低于手工测试。

(2)减少测试时间，缩短测试周期

从以上两表可见，手工与自动化测试同时测试所花费时间周期来看，引入自动化测试框架下的测试次数越多，测试效率越明显，这样使得整个项目效率更高。

(3)加快产品投入市场时间

从快速投入市场产品的价值来说，自动化测试使产品价值更大化。以达到更好的投入回报率。

(4)提前发现BUG，减少维护成本

从软件开发行业标准看，缺陷被发现得越晚，修复缺陷的费用越高。手工由测试由于周期时间较长，很多BUG只能被较晚发现，而自动化测试由于周期较短，效率很高，BUG会被很快的发现，可见自动化测试的引入得越早，产品的缺陷能够越早地被发现并得到修复，这就大大的减少了维护以及修复成本。

附图说明

通过阅读参照以下附图对非限制性实施例所作的详细描述，本发明的其它特征、目的和优点将会变得更明显：

图1为本发明提供的自动化测试框架层次架构示意图。

图2为本发明提供的自动化框架软件流程示意图。

图3为本发明提供的自动化测试框架软件功能模块示意图。

图4为本发明提供的EACL业务模块测试流程示意图。

图5为本发明提供的自动化测试流程示意图。

具体实施方式

下面结合具体实施例对本发明进行详细说明。以下实施例将有助于本领域的技术人员进一步理解本发明，但不以任何形式限制本发明。应当指出的是，对本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变化和改进。这些都属于本发明的保护范围。

测试用例模块：包括所有功性能测试脚本。

具体地，所述API接口：

具体地，所述功性能测试脚本包括：

IGMP、QoS以及VLAN协议栈的测试集

具体地，所述调用模块包括：

具体地，包括：

调用层；包括主函数和图形用户界面；

参数层；包括待测设备所构建的测试环境中的各种参数；

通用模块层：包括与业务模块相对独立的各通用公共模块。

具体地，所述调用层：

具体地，所述参数层包括：待测设备的IP地址、待测设备的收发数据包端口号、测试仪器IP地址、测试仪器的收发数据包端口号以及软件版本信息。

具体地，通过调用层驱动自动化测试过程，调用层读取测试环境的配置文件中的参数以及测试套件，再通过测试套件的实际逻辑解析出所有测试用例，并进行测试用例的执行，测试用例可以调用测试仪器的API接口以及Lib库进行测试用例的设计及验证，执行完测试用例后，对生成测试报告，并打印测试过程中的所有日志信息；

具体地，所述测试套件是指将一类或具有相同测试特点的测试用例集合在一起。

下面通过优选例，对本发明进行更为具体地说明。

优选例1：

一、框架体系分析：

分层设计

为了以后自动化框架的业务更新维护，自动测试框架的开发采用了分层的思想，大致可分为4层：调用层，测试用例层，参数层，通用模块层,设计时将框架中的平台模块和业务模块独立开来，其中平台模块包括TCL/TK库、Expect库(TCL扩展库，用以实现自动交互功能的套件)、SmartBits库(网络分析仪)、通用函数库(公共函数)、GUI模块、会话模块、日志模块、待测设备及系统参数、测试报告模块、邮件模块等；业务模块包括测试用例库、业务逻辑、测试数据、以及网络分析仪收发的数据包等。

Automaion Test Lab自动化测试框架层次架构图如图1所示。

调用层：

调度层主要包括主函数，图形用户界面，其作用是调度测试用例库中的测试用例套件并进行依次执行，可以单独执行一个测试用例，或同时选择多个测试用例依次执行，同时调用各测试用例下的配置文件(config.conf，测试数据)

测试用例层

此自动化测试框架适用与常见的嵌入式通信设备的交互式测试，本文针对EPON系统(OLT+ONU)进行测试用例脚本的设计，测试套件是将一类或具有相同测试特点的测试用例集合在一起，测试用例主要包括功能测试和性能测试，测试用例脚本通过调用参数层和操作层的函数来实现对各测试用例的执行和分析，在测试用例的执行过程中，由于测试环境或程序逻辑等常见问题，可能会出现一些非预期的异常错误，导致程序中断，如：测试过程中网络异常中断，待测设备断电重启或异常或待测设备自身的BUG等，这就需要自动化测试框架支持异常处理机制，在遇到以上异常情况时，自动化测试框架能终止或跳过当前测试步骤或测试用例，继续执行后续有测试条件的测试用例，并在测试报告中打印出现异常的测试报告。

参数层

本层主要包括待测设备所构建的测试环境中的各种参数，如待测设备的IP地址，待测设备的收发数据包端口号，测试仪器IP地址，测试仪器的收发数据包端口号，软件版本信息。

通用模块层

本层主要包括与业务模块相对独立的各通用公共模块，不随产品业务需求的更新而改变，一般不用维护，其中包括：

会话模块：串口/Telnet方式登录交互

数据包收发模块：测试仪器构造各种协议包，发送，接受，并解析包文

日志模块：测试过程中与CLI交互的所有log记录。

测试报告：框架自动生成包括测试结果，测试人，测试时间等信息的报告。

邮件通知：框架自动将每次执行用例后的测试报告及日志文件作为附件发送给测试执行者本人及需要抄送的人。

Tcl/Tk库：Tcl/Tk脚本语言支持库。

Expect库：Tcl/Tk语言扩展库。

网络分析仪库：SmartBits(思博伦通信测试设备)测试脚本开发接口库。

通用函数库：错误处理函数，系统维护(系统版本升级，重启，重置等)，输入参数的有效性检查，SmartBits收发报文封装。

二、框架软件流程

自动化框架软件执行状态流程如图2，通过调用层驱动自动化测试过程，调用层读取测试环境的配置文件中的参数以及测试套件，再通过测试套件的实际逻辑解析出所有测试用例，并进行测试用例的执行，测试用例可以调用测试仪器的API接口以及Lib库进行测试用例的设计及验证，执行完测试用例后，对生成测试报告，并打印测试过程中的所有日志信息。

根据图3层次架构图，自动化测试框架大致由以下主要功能模块组成，其中包括：调用模块，会话模块，日志模块，测试报告模块，邮件发送模块，测试环境参数模块，测试用例模块。

按照层次划分：调用层，测试用例层，参数层，通用模块层，如图1，调用模块主要包括Main,GUI界面，测试用例层主要包括业务上的功能性能测试用例以及测试数据等。参数层包括测试测试配置时的系统参数，设备参数等。其他剩余的公共模块(框架本身的函数)称之为通用模块层(也可以叫平台模块)。自动化测试框架的设计就是包括这些所有模块的开发和集成。

调用模块作为整个自动化测试框架的引擎，驱动所有其他模块，首先部署测试参数，调用测试用例以及逻辑关系，运行测试用例，产生测试数据，测试报告，邮件，日志等。这里的平台模块指框架平台本身，除用例，引擎之外的其他模块。

三、调用模块设计

调用模块是整个自动化测试框架的核心引擎，在此测试框架中，调用模块主要由以下几个函数模块构成：

1.main.tcl

判断自动化测试框架的运行环境，Windows，Linux或Unix。

调用gui.tcl

2.gui.tcl

设计用户对测试拓扑环境的配置界面，包括待测设备，测试仪器的物理地址及拓扑端口，相应测试模块的参数种类选择。

makePage{page filePath wig}{}

设计TestLab模块配置框架

makeConfigPage{page frameWig{labtree""}{node""}}{}

设计Global Configuration模块配置框架

makeModuleConfig{page lab}{}

设计Module configuration配置框架

getSelectedModule{tree}{}

获得当前已被选择的模块参数。

populateTree{tree node}{}

生产当前最新的代码文档

showHelpWindow{path treeWidget}{}

调用测试用例，调用被选中的测试用例，生产测试套件。

makeMainExec{fileName}{}

source[file join\$labDir"$module"exec.tcl]

逐个执行测试用例并进行出错处理，即在遇到某个测试用例在执行过程中出现异常时候，跳过此用例，并记录测试结果，继续下一个测试用例的执行。

调用main_exec.tcl

3.main_exec.tcl

调用测试仪表lib库，并对测试仪表进行预设置(保留板卡等)。

远程登陆(telnet)到待测设备系统。

四、会话模块设计

相对嵌入式网络通信产品而言，登陆到待测设备的操作方式主要包括WEB，CLI，Telnel,Serial(串口)等等，在测试框架中可以对这些常用登陆方式进行封装，在此，我们将与待测设备之间的命令消息交互过程，称之为会话(Session)；在测试过程中，我们只需要向待测设备传送需要的操作命令就可以实现与待测设备之间的交互，主要的会话设计如下：

1.telnet.tcl

Telnet会话

Telnet是网络通信设备最常用的会话方式之一，Telnet会话库的封装，主要实现Session的一些属性操作，如回显设计，通道操作，传输系统命令等。

telnet_GetUserandPassPrompt{}{}

获得系统用户名，密码，端口等信息。

telnet_Open{ip username password args}{}

本会话利用TCL扩展包Expect进行系统交互，远程登录到待测设备，并对登录失败的几种情况做异常处理。

telnet_SendCommand{command args}{}

传输系统命令

telnet_Close{args}{}

telnet_ShowSession{}{}

2.shh.tcl

SSH会话驱动

SSH会话设计与Telnet会话类似。

3.console.tcl

Console口会话

Console口即平时常说的串口，是网络通信设备标准接口之一，自动化测试框架应能够通过串口对设备进行调试及控制，因此，框架需要对Console口进行封装。

五、数据包收发模块设计

在对网络通信设备的自动化测试过程中，经常需要发送接收数据流，进行协议一致性验证，所以需要调用测试仪器商提供的API接口进行数据发送和接收。本模块对这些API接口进行重新封装，方便测试用例中进行调用。

1.smb.tcl

测试仪器(SmartBits)端口物理属性配置，如：双工，自协商，启用/关闭端口等

smbIsPortGE{h s p}{}

smbIsPortActive{h s p}{}

smbEnableGeAutoNeg{h s p}{}

smbDisableGeAutoNeg{h s p}{}

测试仪器(SmartBits)端口发送数据包

smbGetPortTxRate{hub slot port}{}

smbGetPortRxRate{hub slot port}{}

smbGetPortTxPkt{hub slot port}{}

smbGetPortRxPkt{hub slot port}{}

smbSetSingleFlowAdv{h s p srcMac dstMac streamType args}{}

从测试仪器(SmartBits)端口读取数据包并对报文类型进行解析。

smbParseCaptureData{myData capData{capDataType decimal}}{}

利用测试仪器发送自定义数量的数据包

smbGetEnhancedCounter{h s p myCounter}{}

删除端口数据信息

smbClearCounters{hub slot port}{}

读取端口上发送和接收的数据包

smbShowStatistics{hub slot port}{}

六、测试环境参数模块设计

此模块主要读取测试环境中配置的参数，包括待测设备的地址，端口等属性，测试仪器的地址，端口等属性。

读取测试环境中配置的参数

readConfigPage{}{}

七、日志模块设计

系统日志模块主要是跟踪每条测试命令与待测设备的交互信息记录，记录系统在执行测试命令后的执行情况并返回结果，在执行完自动化测试脚本后，我们需要通过查看日志信息检测整个测试过程中出现的详细信息，以便帮助测试人员快速定位待测设备及系统的缺陷所在，当然也便于对测试脚本自身缺陷的调试，可见，系统日志可以跟踪整个测试过程。

创建日志

logCreateAndDir{logname}{}

捕获与设备之间的交互信息

glbLog{channelId str}{}

测试前实际时间

GenerateLogHeader{}{}

测试完成后实际时间

GenerateLogFooter{}{}

八、测试报告模块设计

测试报告模块主要是在执行完自动化测试脚本后，自动生成一份清晰明了测试统计结果给相关人员。

测试报告包括测试套件中包括的测试用例模块，测试用例被执行的时间，系统软件版本号，测试优先级，测试结果统计，测试人等。

在Tcl语言中插入HTML语言来实现测试报告。

九、邮件发送模块设计

邮件发送模块主要实现在自动化测试框架执行完成后第一时间将测试报告和测试日志以附件的方式发送给测试人员及制定的抄送人员。

这里的邮件发送模块，是指一轮测试执行完，邮件发送模块会自动将测试报告，日志发送给执行测试及之前配置中设定的相关人。

邮件发送模块包括两部分：1.获取配置文件中的相关信息，如收件人及地址等信息。

2.获取测试完成后的测试报告及日志等相关信息，并将此文本作为邮件附件发送之前获取到的收件人。

十、业务模块

以太网协议功能定义成自动化测试框架下的具体业务模块，主要包括以下基本模块：EACL,IGMP,IPAL,MEF,QOS,VLAN,RSTP/MSTP等

EACL模块实例分析：

介绍EACL之前，先介绍下什么是ACL,ACL(Access Control List)即访问控制列表，是交换机，路由器，接入网络设备接口的指令列表，用来控制特定端口进出的数据包，各网络设备间通信为了保证网络的安全性，需要通过一些安全策略来保障非授权用户只能访问某些特定的网络资源，从而达到对访问进行控制的目的。简而言之，ACL可以过滤网络中的流量，是控制访问的一种网络技术手段。

EACL(Enhanced ACL)即增强型ACL，用户可对进出方向的数据包按照源MAC地址、目的MAC地址、源IP地址，目的IP地址、以太网类型、源四层端口号、目的四层端口号、优先级、VLAN标签等制定匹配规则，对报文进行相应的分析处理，丢弃或接受的报文，我们也习惯称之为白名单列表或黑名单列表。

下面我们就以EPON系统中基于业务板卡的EACL包过滤功能为例，阐述EACL业务模块是怎样在Automaion Test Lab中被进行一步一步验证测试的。

EACL业务模块测试流程，如图4所示。

1)首先，在main.tcl主程序中调用EACL子模块，运行Automaion Test Lab。

2)EACL在日志模块生产系统日志文件。

3)对测试环境进行初始化，如创建VLAN，添加端口到VLAN中，删除系统中已经存在的EACL规则，以免冲突，验证ONU及端口状态，验证数据流是否能正常通过等。

4)执行测试用例，创建EACL规则。

5)将EACL规则绑定到指定板卡上实现包过滤。

6)调用网络测试分析仪接口发送数据流。

7)根据EACL匹配规则，使用网络分析仪分析接受的数据流是否符合EACL包过滤规则，即被EACL规则匹配的数据流是否因为被丢弃而未被接收到。

8)删除之前绑定的EACL规则，再次收发数据包，并通过网络分析仪分析接受的数据流是否符合EACL包过滤规则，即之前被EACL规则匹配的数据流是否因为EACL规则被删除而在接收端被正常接收到。

9)提交测试结果提交给测试报告模块。

十一、测试流程设计

测试框架各模块实现后，我们需要对各模块的功能进行验证，根据实际测试环境的需要，配置相关测试环境参数，以及获取测试过程中交互过程的日志信息，并按逐执行测试集中测试用例，如果测试脚本需要调用测试分析仪器，则需要按照测试用例中对报文的定义进行数据包的收发，并对数据包进行协议分析或对其他测试结果与测试用例的预期结果进行比对，分析测试结果是否正确，具体测试框架的测试流程如图5所示。

下面以EACL业务模块来具体介绍自动化测试流程：

1.首先配置OLT,ONU及Smrtbits测试仪的IP地址、端口号、本轮测试的测试集等参数，并按照EPON系统的实际测试用例搭建好测试拓扑图(详细测试拓扑图及测试环境配置见第五章第一节)。

2.配置好测试参数后，直接运行Automation Test Lab，测试框架自动生成测试交互过程的日志信息，日志内容包括用户登录成功与否，向EPON待测系统输入的相关命令，以及系统响应的交互信息。

3.Salira SVT Automation Test Lab调用并执行EACL测试脚本，测试脚本严格按照测试用例的内容进行测试执行，其中主要包括以下几个步骤：

1)脚本自动在EPON系统中创建需要的EACL规则。

2)将EACL规则绑定到指定的设备端口。

3)调用Smartbits的API接口，构造并发送测试用例里规定的协议数据包。

4)在Smartbits的接受端口上捕获接受到的数据包，并按照协议规定进行协议包数据分析。

5)用捕获并解析的结果与测试用例规定的预期结果进行比对，分析接受的数据流是否符合EACL包过滤规则。

4.对测试结果进行分析并统计，如符合包过滤规则，则此条测试用例通过，如不符合，则此条测试用例未通过，并将测试用例的执行结果在测试报告中进行统计记录。

5.如测试集中还包括其他测试脚本，Salira SVT Automation Test Lab会继续调用他测试脚本逐个进行自动化测试，直到所有业务模块的测试脚本都被执行完毕，则自动化测试结束。

测试环境参数配置：

根据测试拓扑图搭建并配置好测试环境，如：待测设备及测试仪器的IP地址，待测设备及测试仪器的端口列表，待测测试用例的测试集等参数。

Salira SVT Automation Test Lab将测试环境参数和测试用例脚本分离，从而保证测试用例的独立性，从而减少后期的维护量。

测试过程日志处理：

Salira SVT Automation Test Lab测试框架开始运行后，调用层会调用业务模块(测试用例)，日志模块会根据版本信息全程自动记录整个交互过程，生成系统日志文件，为后期开发和测试人员对产品的BUG追溯及分析确认提供有效的信息依据。

测试用例脚本执行：

测试用例脚本被按照设计思路逐步执行，进行待测设备的协议验证，以太网常见功能，性能等测试。

Salira SVT Automation Test Lab详细的定义在测试过程中碰到各种情况的处理机制，如在某个测试用例由于测试设备状态异常无法执行某个测试用例时，继续执行剩余的测试用例，并记录此条错误信息；如在待测设备发生死机或异常重启时，中止并退出脚本测试，输入相关日志信息，提示待测设备异常死机或重启，等等。

数据包收发：

其中部分测试用例需要调用网络测试分析仪的API接口，通过对待测设备进行收发包分析测试，来进行业务功能模块的验证测试。

Salira SVT Automation Test Lab调用SmartBits测试仪API接口，来构造测试用例中定义的各种网络协议包，如VLAN,ACL,QoS,IGMP,STP等，发送到待测系统中，经待测系统对协议包的处理后，再从测试仪的接受端口进行协议包的分析工作，从而验证业务模块的功能是否正常以及性能是否达标。

测试结果分析：

Salira SVT Automation Test Lab分析实际测试结果是否符合测试用例的预期结果，并详细记录所有测试用例的执行结果，并对测试结果进行统计归类，最终生产清晰，有效的测试报告，测试报告包括测试套件中包括的测试用例模块，测试用例被执行的时间，系统软件版本号，测试优先级，测试结果统计，测试人等相关信息。

在本申请的描述中，需要理解的是，术语“上”、“下”、“前”、“后”、“左”、“右”、“竖直”、“水平”、“顶”、“底”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本申请和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本申请的限制。

本领域技术人员知道，除了以纯计算机可读程序代码方式实现本发明提供的系统、装置及其各个模块以外，完全可以通过将方法步骤进行逻辑编程来使得本发明提供的系统、装置及其各个模块以逻辑门、开关、专用集成电路、可编程逻辑控制器以及嵌入式微控制器等的形式来实现相同程序。所以，本发明提供的系统、装置及其各个模块可以被认为是一种硬件部件，而对其内包括的用于实现各种程序的模块也可以视为硬件部件内的结构；也可以将用于实现各种功能的模块视为既可以是实现方法的软件程序又可以是硬件部件内的结构。

以上对本发明的具体实施例进行了描述。需要理解的是，本发明并不局限于上述特定实施方式，本领域技术人员可以在权利要求的范围内做出各种变化或修改，这并不影响本发明的实质内容。在不冲突的情况下，本申请的实施例和实施例中的特征可以任意相互组合。

Claims

1.一种基于嵌入式设备的自动化测试框架，其特征在于，包括：

测试用例模块：包括所有功性能测试脚本。

2.根据权利要求1所述的基于嵌入式设备的自动化测试框架，其特征在于，所述API接口：

3.根据权利要求1所述的基于嵌入式设备的自动化测试框架，其特征在于，所述功性能测试脚本包括：

IGMP、QoS以及VLAN协议栈的测试集。

4.根据权利要求1所述的基于嵌入式设备的自动化测试框架，其特征在于，所述调用模块包括：

5.根据权利要求1所述的基于嵌入式设备的自动化测试框架，其特征在于，包括：

调用层；包括主函数和图形用户界面；

参数层；包括待测设备所构建的测试环境中的各种参数；

通用模块层：包括与业务模块相对独立的各通用公共模块。

6.根据权利要求5所述的基于嵌入式设备的自动化测试框架，其特征在于，所述调用层：

7.根据权利要求5所述的基于嵌入式设备的自动化测试框架，其特征在于，所述参数层包括：待测设备的IP地址、待测设备的收发数据包端口号、测试仪器IP地址、测试仪器的收发数据包端口号以及软件版本信息。

8.根据权利要求7所述的基于嵌入式设备的自动化测试框架，其特征在于，通过调用层驱动自动化测试过程，调用层读取测试环境的配置文件中的参数以及测试套件，再通过测试套件的实际逻辑解析出所有测试用例，并进行测试用例的执行，测试用例可以调用测试仪器的API接口以及Lib库进行测试用例的设计及验证，执行完测试用例后，对生成测试报告，并打印测试过程中的所有日志信息。

9.根据权利要求8所述的基于嵌入式设备的自动化测试框架，其特征在于，所述测试套件是指将一类或具有相同测试特点的测试用例集合在一起。