自动化测试

自动化测试（精选12篇）

自动化测试 篇1

在自动化测试领域中,传统的自动化测试脚本的开发一般有两种方法。第一种方法是通过手工运行一次测试,同时使用自动化测试工具的录制功能,把所进行的操作记录下来,生成测试脚本。这种技术生成的脚本回放成功率比较低,后期维护也比较困难。第二种方法是编写测试框架,对测试需要的基础操作提供接口供调用,测试人员根据用例操作需求,手工编写调用接口的自动化测试脚本,这种方法对测试人员的代码水平要求很高。

目前自动化测试中,测试小组成员编写完用例以后,还需要脚本开发人员单独编写一条针对此用例的自动化测试脚本,然后使用自动化测试工具运行脚本进行测试。当测试用例变更后,还需要重新编写这条测试脚本,资源耗费比较大。测试用例和测试脚本之间的维护比较复杂。

1 实施过程

1.1 项目介绍

针对现有技术中的缺陷,本想法要解决的技术问题是:如何将测试用例自动地转化为自动化测试脚本,以减少自动化测试脚本的代码量、资源消耗及测试用例和测试脚本之间的维护。

为解决上述技术问题,我和小组人员不断的摸索以及通过实际工作中多次测试和联调,探索出一种只要被测产品中没有产生新的控件类型,就不需要修改自动化测试脚本的解决办法。通过在实际项目中多次试验,本控件类型在测试用例中可以任意制定被测产品的流程,不会局限某个系统、某个产品。

根据多次实验结果得出一种自动化测试方法,包括如下步骤:

步骤1:定义控件属性与预置测试脚本代码之间的对应关系。本环节是通过设置的相应的对应关系,在前期就降低控件的可变化性。

步骤2:读入测试用例的测试数据,其中,所述测试数据包括控件属性。

该数据从项目实际运营过程中获取,保证能够在测试过程中发现更多的问题,确保一旦正式发布后在实际运行过程中避免出现类似错误。

步骤3:针对读入的控制属性,查找到对应的预置测试脚本代码;大多数自动化测试并没有这一步骤,通过读入控件属性,可以降低代码的重复性,是本设计特有的环节。

步骤4:根据预置测试脚本代码形成自动化测试脚本代码;

步骤5:将预置测试脚本代码添加到编写的自动化测试代码框架中,形成自动化测试脚本代码,执行自动化测试脚本代码,其中,自动化测试脚本代码用于模拟手动执行测试用例中各个控件类型的动作。

以上二分部主要由软件自动完成,无需手动进行,这也就是自动化测试的魅力所在,可以在很大程度上降低人力手动操作的时间,腾出更多时间去完成其他事情,增加工作效率。

2 附图说明

2.1 测试流程

为了将思想的其它特征、目的和优点更明显展示出来:通过阅读参照图1附图将会更直观。

2.2 解决办法

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

每个项目都需要人员的配合。需要需求人员、产品开发人员和自动化测试脚本代码开发人员共同配合,产生控件ID与被测系统映射表、控件类型与代码映射表,例如表1和表2所示,其中,控件ID与被测系统映射表记录了控件名称、测试用例中控件ID、被测系统中的控件ID之间的映射关系,控件类型与代码映射表记录了控件类型、测试用例中控件类型、被测产品中控件类型、测试脚本中控件类型的映射关系。

本方案的方法和系统可以连接测试用例管理工具,读取测试用例,通过解析模块解析测试用例信息,生成脚本可读的信息,然后根据测试用例中的控件ID在控件ID与被测系统映射表中查找对应被测模块,最后确定被测模块;我的主要想法还是根据测试用例中的控件类型在控件类型与代码映射表中查找对应的测试脚本代码,执行自动化测试脚本来最终产生测试结果。具体步骤如图1所示,包括:

步骤1:我们要先读取用户编写的测试用例,例如可以连接测试用例管理工具,从存储有用户编写测试用例的测试用例管理工具中读取,测试用例中的控件类型和操作命令、自动化测试脚本中的控件类型和操作命令、被测试系统中控件类型和操作命令三者一致,测试用例中的控件ID与被测系统的控件ID一致。

步骤2:解析测试用例信息,生成脚本可读的信息。

步骤3:根据测试用例中的控件ID在控件ID与被测系统映射表中查找对应被测模块。具体地,根据测试用例中的控件ID,在控件ID与被测系统映射表中,首先查找到对应的被测系统中的控件ID,然后根据该被测系统中的控件ID再查找到对应的被测模块,其中,所述被测模块是被测系统的某个测试单元,例如,一个文本框、一个多选框、一个单选框等。

本组成员在项目中反复实践发现了一致性的关键点。目前很多自动化测试都是由于忽略了一致性才导致脚本可用性降低从而人为的增加了测试的工作量,说是实现了自动化测试,反而却是增加成本。

步骤4:根据测试用例中的控件类型在控件类型与代码映射表中查找对应的自动化测试脚本代码。具体为,根据测试用例中的控件类型,在控件类型与代码映射表中,首先查找到对应的测试脚本中控件类型,然后根据该测试脚本中控件类型再查找到对应的自动化测试脚本代码。

步骤5:执行步骤4的控件类型对应的自动化测试脚本代码,该自动化测试脚本代码用于模拟手动执行通过步骤3查找到的被测模块的控件类型的动作。

步骤6:输出自动化测试脚本代码产生的实际结果。

步骤7:比较自动化测试脚本代码产生的实际结果与测试用例中的预期结果是否一致,如果一致说明测试通过;如果不一致说明测试不通,并且指出不通过的原因

使用本方案的方法,即使当测试用例变更后,测试人员只需按照关键字规范,手工修改一次测试用例即可。

下面对本方案的一个优选具体实施方式进行描述,在本具体实施方式中,包括以下步骤:

Step1:需求人员、产品开发人员和自动化测试脚本代码开发人员共同定义好被测产品中控件类型与控件的ID,产生相应的映射表,标准控件的使用标准定义。

共同定义是非常重要的,针对不同项目,前期应把控件类型和id定义成标准,并在开发过程中使用统一标准。

Step2:产品开发人员和自动化测试脚本代码开发人员根据映射表为被测产品的每个控件设置控件类型、控件ID。

Step3:定义测试用例内容以及格式;测试用例内容包含:控件类型、控件ID等;测试用例的格式如:(系统模块名称,控件类型,控件ID,输入内容,操作命令,预期输出,时间输出,测试结果)。

Step4:执行自动化测试脚本代码,包括如下子步骤:

Step4.1:读取用户编写的测试用例,所述测试用例中的控件类型和操作命令、自动化测试脚本中控件类型和操作命令、被测试系统中控件类型和操作命令三者一致,测试用例中的控件ID与被测系统的控件ID一致。例如,可以首先连接存储有用户编写的测试用例的测试用例管理工具,然后从测试用例管理工具中读取测试用例。

Step4.2:解析测试用例信息,生成脚本可读的信息。

Step4.3:根据测试用例中的控件ID在控件ID与被测系统映射表中查找对应被测模块。

Step4.4:根据测试用例中的控件类型在控件类型与代码映射表中查找对应的测试脚本代码。

Step4.5:执行自动化测试脚本代码,这段自动化测试脚本代码是模拟手动执行测试用例中各种控件类型的动作。

Step4.6:输出自动化测试脚本代码产生的实际结果。

Step4.7:比较自动化测试脚本代码产生的实际结果与测试用例中的预期结果是否一致,如果一致说明测试通过;如果不一致说明测试不通,并且指出不通过的原因。

其中,Step4是自动化测试一个控件过程,在自动化测试脚本代码中,分别实现模拟手动执行每个控件类型的动作,并且使每一个控件类型的动作成为一个独立的模块,根据控件类型可以查找到对应的测试脚本代码。脚本代码可以重复利用,只要被测产品中没有产生新的控件类型,就不需要修改自动化测试脚本。测试用例中可以任意制定被测产品的流程,不会局限某个系统、某个产品。

其实优选具体实施方式和之前介绍的没什么区别,这里要说的是不管哪种方案要强调的是测试用例中的控件类型和操作命令、自动化测试脚本中的控件类型和操作命令、被测试系统中控件类型和操作命令三者一致,这个是本文的重点,也是提出本方法的关键。

3 结论

根据本方案提供的一种自动化测试系统,所述自动化测试系统用于执行上述的自动化测试方法。

通过控件ID与被测系统映射表中的映射关系、控件类型与被测系统映射表中的映射关系、控件类型与代码映射表中的映射关系这种方法实现了测试用例到自动化测试脚本的自动转化,进而提高代码重复利用率、缩小了代码量、提高了自动化测试的效率,降低了资源消耗和维护复杂度,达到了前期需要目的。该方法不局限于某一个系统,要做的就是一致性,而该一致性需要团队的合作。

自动化测试 篇2

学习工作内容

在如下的案件流程中：

1.自动化开发平台_数字法院3.4_民事_中院_一审案件_走审查走审批_全子表流程

2.自动化开发平台_数字法院3.4_民事_中院_二审案件_走审查走审批_全子表流程

3.自动化开发平台_数字法院3.4_民事_中院_公示催告案件_走审查走审批_全子表流程

4.自动化开发平台_数字法院3.4_民事_中院_申请支付令审查案件_走审查走审批__全子表流程

5.自动化开发平台_数字法院3.4_民事_中院_民事再审案件_走审查走审批_全子表流程

添加新案件来源的模块到流程中；

添加新法标_接待新案件模块到流程中； 添加新结案方式到配置中；

添加完之后将各个案件流程跑通；

准备工作：登录自动化平台点击客户端下载“页面元素抓取工具”，运行自动化平台最好使用“猎豹浏览器”，因为IE用于抓取页面信息，区别于自动化测试平台登录，这样截取的页面信息比较准确。

（laxt地址:http://172.16.60.244:8088/laxt(登录用户:lijh 密码:123)审判系统:http://172.16.60.244:8484/spxt 自动化平台地址:http://172.16.31.100/atdp/login.do 登录用户:wanghuanren 密码:wanghuanren）

操作过程

这几个案件的自动化流程是用于新案件类型的，所以需要添加“新案件来源”“新结案方式”“新法标_接待新案件模块”到每个案件流程中，使得新案件流程能够对应新修改的页面走通流程。

1.在每个案件流程中的模块都是添加好函数的模块，在这次操作中，基本不需要修改模块里的函数；

2.需要加进去新案件来源的参数值，是在“新法标_新案件来源_公用”模块中。参数值来源于laxt页面上的下拉框的值；

3.新结案方式的配置是在“配置”中，先数据后控件： 数据配置，先找到“小节”，选择哪个小节，需要去流程模块的最后阶段“子表通用”的结案项之上的“批量赋值”中看，其参数就是小节，或者带有结案字样的模块，看到是“结案”上有一个为批量赋值那一项中的参数值就是了。

然后就是控件，控件的话需要的页面抓取工具，抓取结案方式的那个html id到参数值。

遇到的问题：在实际操作中，批量赋值中没有小节名，现在需要在配置中在增加一个小节。在“配置”中点击批量获取，调用抓取工具，在NP的spxt的结案页面上选择一个框就能够获取到一个小节的页面信息，注意将结案页面上必填项都填上，抓取后的小节信息中关于日期的都修改为{今天}，就完成了一个结案信息的小节。

在执行时如果有连接服务器一直处于连接状态的话，就直接在服务器：172.16.31.105上进行执行。（从101到120都是可用的服务器：Microadministrator/ceshi1）

步骤：将要执行的流程名字放在服务器的：D:自动化开发平台自动化开发平台配置

中的测试控制.ini下的第三行：当前流程=?的后面

点击开始的自动化平台远程助手，【调试模式】，再运行QTP。就可以执行自动化了。

电气自动化设备可靠性测试分析 篇3

关键字：电气自动化设备;测试方法;可靠性

中图分类号：TM76 文献标识码：A

由于电控及自动化设备特殊性，产量小品种多。对其进行试验室测试有一定的困难，所以采用现场测试比较实际，但现场测试也有缺点。所以，搞一些试验室测试并且通过对试验室测试所获得的可靠性数据与现场可靠性所获得数据进行比较，更准确地判定设备的可靠性程度。在测试过程中需按照流程操作、及时保养，才会有满意的成果及可靠性测试结果。现场可靠性测试实验室我国电控设备未来的发展方向，现场可靠性试验也非常适合我国电控自动化设备的发展。

1.电气控制设备的可靠性现状

控制设备可靠性指标低与工作环境、使用及维护不当有相当大的关系，电气设备所处的工作环境多种多样，影响控制设备可靠性的因素有气候条件。机械作用力和电磁干扰，气候条件中温度、湿度、气压、大气污染等因素，能使控制设备的电气性能下降，温升过高，运动不灵活，结构损坏，直至瘫痪，不能正常工作。目前元器件生产厂家众多，质量有好有坏，因此控制设备可靠性指标偏低，在小企业中，管理体系缺陷，零部件进厂检查不能得到有效实行，同时，市场中的恶性竞争，导致元器件价格相对低廉，企业不顾质量的采购，使得控制设备可靠性指标偏低，使用寿命大打折扣。

2.电气设备可靠性测试方法分析

2.1 试验室的测试方法

由于在试验室内有非常优异的工作、试验条件，所以我们可以通过模拟的方法，将实际的使用条件模拟出来，再进行试验，通过累计失效数以及时间等数据，来得到需要的可靠性指标，这就是试验室的可靠性试验。通过试验室试验的方法，我们得到的试验结果与实际结果更加贴近，但是这种方法存在一定的局限性，那就是投资过大，需要大量的资金、设备以及专业技术人员，因此要尽量考虑成本因素，选择是否使用此种方法，总体来说，这种试验室的测试方法比较适用于大规模的生产。

2.2 保证试验方法

该方法是在产品出厂前将产品在规定条件下进行无故障的工作试验，俗称烤机，我们研究的电控设备通常由大量的元器件组成，它的故障模式是一种不以某几种故障为主的、随机的、多样化的形式显现出来的，因此它的故障服从指数分布，也就是说它的失效率具有随着时间变化的特性。我们在试验室内对出厂前的产品进行烤机，实际上就是对产品的早期失效进行测试考核。通过对产品的改进，使失效率达到某项规定指标后再出厂。这项试验主要是一种可靠性保证试验，而且所需时间长，对大量生产的产品来说，它只能用于设备的样本，对小量、大系统生产的产品来说，它可用于所有产品。这种试验方法对电路复杂、可靠性要求较高、台数少的电控及自动化设备比较适用。

2.3 现场试验方法

通过对设备在使用现场进行的可靠性测试记录各种可靠性数据，然后根据数理统计，参照不同的试验数据来研究出正确的方式，保证自动化设备的性能的到很好的发挥。其特点是使用的试验设备较少，工作环境与现场情况基本相同，所测试的数据能够真实反映电控设备在实际使用情况下的可靠性，维护性等参数，其工作效率高。但其遇到受控条件下也难以进行试验，容易被外界因素干扰。现场测试主要是一下几点：测试设备一直运行，在线测试;停机测试时，电控设备需中止运行;在特别设计的试验设备上进行试验，进行脱机测试，将测试部件移除现场。这三中测试方法各有各的特点，要依据实际情况来确定是哪一种测试方法。现场测试由于其设备的难以安装和连接，这也是现场测试的一大缺点。

3.可靠性测试方法的选择对策

3.1 场地的选择

如何对可靠性测试的方法进行选择，对于可靠性测试来说具有非常重要的作用。一般来说，可以从实验产品、实验环境、实验场地、实验程序等方面入手，进行推测。场地选择之前需要对相关环境进行一定程度的了解，选择的同时要遵循一定的原则。如果是对正常使用状况下的可靠性进行测试，需要选择较为特殊典型的工作场地，如果是为了能够提供可比性比较可靠的资料，需要选择有近似实验或者有相同条件的场地。

3.2 实验产品选择

实验产品的选择同样需要遵循一定原则，对于产品来说需要有一定的典型性。其涵盖的品种要多，矿井提升电动设备、纺织机电控制设备、造纸机电设备等。同时，产品需要用中小型和大型设备，不仅要有简短运行的设备还要有连续运行的设备。在进行测试之前需要对测试程序进行规划，保证现场测试人员能够严格依据规定好的程序进行测试内容的实施。

3.3 实验环境的选择

因为电器自动化设备一般情况差异比较大，在对实验环境测试的时候要选择环境不过度恶劣的地区，保证测试结果的公平性。实验检测的组织工作，这个环节在实验工作中非常重要，主要是对各个场地进行组织管理的工作，肩负着对相关实验数据的确定、整理、收集，对实验工作的协调、相关检测人员的选定，可靠性设备检测工程师、制造师的选择等工作，所以在进行可靠性测试方法选择的时候，要着重考虑这方面的方法，促进可靠性检测结果的客观性。

4.结束语

综上所述，在保证满足产品的需要时，按最经济的生产方法设计元器件及部件。根据电控设备中电路的性能的要求和工作环境条件来选取合适的元器件，元器件等部件其技术条件、技术性能、质量等，都必须满足设备工作和环境的要求，同时优先选择品质好的，质量可靠并稳定的，有发展前途的标准元器件。在设备设计阶段，进行精密的可靠性计算，从而找出正确的设计方法。控制设备的温度，使其工作在适宜的温度下，由于温度对设备的可靠性也具有一定的影响，所以设备的温度及设备所损耗的功率也是可靠性所要考虑的一个部分及条件。

参考文献：

[1]李兵. 电气自动化的初步探讨[J]. 科技传播.2014

自动化测试 篇4

针对现有多元化移动通信业务的测试, 包括语音业务和数据业务等, 除了一些通用的测试工具外, 很多公司都有内部的自动化测试工具。很多测试工具都是基于TTCN-3 (测试及测试控制表示法) 开发的, 比如TREX、Broad Bit、TAU Teste、Open TTCN3 等。TTCN-3 是由ETSI (欧洲电信标准化组织) 制定和推行的测试专用语言, 是全球各大通信设备厂商的主流测试语言。而项目组移动通信业务的自动化测试则引入了持续集成 (continuous integration, 简称“CI”) 系统。

目前, 全球80%以上的软件项目采用的是持续集成。持续集成是一种软件开发实践, 每次集成都通过自动化的构建 (包括编译、发布、自动化测试) 来验证, 从而尽快发现集成错误。谷歌作为当前科技领头羊, 率先在内部推行并使用了持续集成模式。在其内部的持续集成系统中, 数以亿计的构建动作会发起几百万次的自动化测试, 开辟了快速开发领域的测试新模式。

Jenkins作为开源集成测试软件的典型代表, 可以用来搭建企业持续集成自动化测试项目平台, 对移动通信业务进行自动化测试。

1 基于Jenkins搭建CI自动化测试平台

1.1 CI自动化测试平台框架

移动通信业务的CI自动化测试平台框架如图1 所示。该测试平台主要包括Jenkins、CIS-RC (Continuous Integration Server Remote Control) 、Control Unit和L1 (Layer 1) 物理层测试平台。

Jenkins和CIS-RC安装在Windows PC上, 而Control Unit、Linalfs、KSIM等测试工具则安装在Linux PC上, 相关移动通信业务的自动化测试也均是在Linux PC上完成的。Windows PC和Linux PC之间通过TCP连接, 进行工具调用、结果传输等。

Jenkins是一个配置简单、使用方便的持续集成服务器, 在CI自动化测试平台中起着指挥的作用。通过执行命令, Jenkins可以调用一些工具, 比如CIS-RC和L1 Wait And Check Result File。在Jenkins上, 相关人员可以根据不同的测试平台构建不同的项目来触发各类移动通信业务的自动化测试。

CIS-RC在CI自动化测试平台中相当于客户端。Jenkins要想调用CIS-RC, 可以通过两个参数, 分别是XML文件名称和XSD文件名称。XML文件和XSD文件中包含了一些设置和命令, 其中, XML文件包含了关于Control Unit、脚本序列 (script sequence, 简称“ssq”) 和结果文件的相关信息, 而XSD文件则描述了Control Unit与CIS-RC之间的连接。

Control Unit相当于TCP服务器, 同时控制着L1 物理层测试工具, 包括KSIM、Linalfs等。移动通信业务测试是在L1 测试平台上进行的, Control Unit会对测试过程和结果进行评估, 我们可以在log窗口和单独的统计窗口中观察自动化测试相关的log信息和测试结果。

1.2 L1 物理层测试平台

L1 物理层测试平台是基于RRH (Remote Radio Head, 射频拉远头) 建立的。Linalfs和KSIM等移动通信业务测试工具在平台上执行脚本命令, 并在工具测试界面上返回测试结果。测试工具均采用脚本的方式运行, 脚本语言为自定义关键字的形式, 无需动态编译, 可以直接运行。这样不仅节省了测试时间, 而且还便于测试用例的构造。

RRH是用于移动宽带网络基站中的新技术设备, 可以提升既有讯号的传输效率, 并在更容易建置的网络架构下扩大其网络覆盖率。RRH技术的特点是可以将基站分成无线基带控制 (Radio Server) 和射频拉远两部分。使用RRH技术可以灵活、有效地根据不同环境构建各种构造的网络。

除了RRH, L1 测试平台还包括SUMX、RF回环盒、衰减器、合路器和电缆等。这些部件通过一定的连接方式共同构成了L1 物理层测试平台, 如图2 所示。

2 移动通信业务自动化测试实例

2.1 测试目的

移动通信业务的测试包含了语音业务测试和数据业务测试等。以GSM基本业务测试为例, 在初始化不同GSM载波、Abis接口和PA数的情况下, 对物理层GSM基本业务进行了自动化测试, 以检测接收机的质量, 例如接收信号的能力、抗各种干扰的能力以及抗各种无线环境的能力等。

GSM语音业务包含全速率语音业务和半速率语音业务。采用FR和HR编码的语音业务, 在不同编码方案、时隙和信道配置下, 验证系统是否支持FR和HR编码的移动用户主叫业务功能和被叫业务功能。测试通过表示呼叫成功, 主被叫语音正常。

GSM数据业务也包含全速率数据业务和半速率数据业务。在不同编码方案、时隙和信道配置下, 测试短消息业务, 验证系统是否支持移动用户发送和接收短消息业务。测试通过表示在空闲和通话状态下, MSA短消息发送成功, MSB能正确接收和显示短消息。

2.2 测试脚本

GSM业务信道 (TCH) 携载编码语音或用户数据, 有两类TCH, 分别是全速率业务信道 (TCH/F) 和半速率业务信道 (TCH/H) 。在进行具体业务测试之前, 需要对GSM载波、Abis接口和PA数进行初始化配置。其初始化配置脚本如表1 所示, GSM基本语音业务和数据业务的测试脚本如表2 所示。

2.3 测试流程

在CI自动化测试平台上进行GSM基本业务自动化测试时, 将初始化脚本、语音, 数据业务测试脚本和测试过程中需要用的所有其他脚本和参数均按执行顺序集成到SSQ脚本序列中, 然后在SSQ脚本序列执行过程中再去调用具体的scr脚本。

在初始化1 个和2 个GSM载波、Abis接口为1 的情况下, 将GSM语音业务和数据业务在不同编码方案、时隙和信道配置下的所有测试集成到一个Jenkins job中, 新建一个job, 并进行相关配置, 如图3 所示。

为避免一个job执行的测试脚本命令过多, 一般将完整业务的自动化测试分为多个job来执行, 比如将初始化1 个和2 个GSM载波、Abis接口为1 作为一个job, 将初始化1 个和2 个GSM载波、Abis接口为2 作为一个job。以此类推, 在初始化所有GSM载波、Abis接口和PA数的情况下将完整业务的自动化测试分为6个job来执行。相关人员只需要在job配置项中选择上一个执行以及下一个执行的job, 即可按顺序执行6 个job。

新建并配置完成Job后, 在第一个job处点击“Build Now”开始自动化测试。在点击“Build Now”之前, 要确保CIS-RC和Control Unit已经开始运行。

Jenkins执行job首先调用CIS-RC, CIS-RC读取相应job的XML文件, 并参照XSD文件对其进行验证, 然后新建一个针对测试环境下应用Control Unit的TCP连接向Control Unit发送XML命令, Control Unit根据接收到的XML命令打开测试工具Linalfs、Ksim等, 并执行相关的SSQ脚本序列, 最后待测试结束后将测试结果返回CIS-RC和Jenkins中。

Control Unit执行SSQ脚本序列的过程如图4 所示。我们可以从Control Unit的log窗口看到整个测试的执行过程, 从Linalfs和Ksim界面看到正在执行的语音或数据业务的case, 从Running Test界面看到当前正在执行的scr脚本和整个测试进程。

2.4 测试结果

在GSM基本业务测试过程中, 一个case的结果是否通过主要看Linalfs测试结果界面上显示的接收机的质量和帧误率, 然后参考表3 作出评判。在测试语音业务时, 测试通过表示呼叫成功, 主被叫语音正常。在测试数据业务时, 测试通过表示在空闲和通话状态下, MSA短消息发送成功, MSB能正确接收和显示短消息。

Control Unit会对每个case的测试结果进行自动判断并记录。测试结束后, Control Unit关闭相关测试工具, 将测试结果反馈给CIS-RC, 并在相应目录下生成XML结果文件。在XML结果文件中, “Status=OK”表示所有语音和数据业务case均通过测试。除了XML结果文件, 可以在Jenkins界面的Console Output上直接看到测试结果, 如图5 所示。Console Output显示为绿球, 并且“Finished:SUCCESS”也表示测试通过, 即在初始化所有GSM载波、Abis接口和PA数的情况下, GSM语音业务和数据业务在不同编码方案、时隙和信道配置下均能正常工作。

3 结束语

软件持续集成和自动化测试的引入在一定程度上解决了通信产品在软件系统开发过程中的测试难题, 避免了手动测试的大量人力投入, 提高了测试的质量和研发速度, 具有重要的现实意义。

本文基于Jenkins搭建了企业持续集成自动化测试平台, 并将所有流程都集成到Jenkins持续集成平台上, 实现了移动通信业务的自动化测试。其中, 还具体介绍了CI自动化测试平台的总体框架以及各模块功能的构成和模块之间的关系, 并以GSM基本业务测试为例, 介绍了整体的测试流程和测试输出结果, 最终使持续集成与自动化测试在项目中得以顺利应用, 达到了项目组预期的效果。

摘要：随着移动通信业务测试需求的增加, 为保证通信产品的质量和研发速度, 利用Jenkins搭建了企业持续集成自动化测试平台, 用于移动通信业务的自动化测试。介绍了持续集成自动化测试平台的总体框架和各模块构成, 并以GSM基本语音和数据业务测试为例, 给出了平台测试流程和测试输出结果, 最终使持续集成与自动化测试在项目中顺利应用。此平台在实际项目的应用中取得了显著效果, 提高了测试工作的效率。

关键词：Jenkins,移动通信,通信业务,自动化测试平台

参考文献

[1]刘昶.LTE语音测试解决方案[J].电信网技术, 2013 (03) .

[2]董宏成, 张宁, 李小文.基于TTCN-3的RRM小区重选过程一致性测试[J].电信科学, 2013 (4) .

[3]陈刚, 羌铃铃.持续集成在项目中的分析与研究[J].电脑编程技巧与维护, 2011, 24.

[4]邢晓伟.持续集成在软件开发过程中的应用[J].金陵科技学院学报, 2014, 04.

[5]James W, Jason A, Jeff C.Google软件测试之道[M].黄利, 李中杰, 薛明, 译.北京:人民邮电出版社, 2012.

自动化测试 篇5

经过我上网搜索，知道了测试中有85%的缺陷是归功于手工测试，而只有15%的缺陷归功于自动化测试（注意：这个标准并不是随便说的，而是由自动化测试专家共同总结得出的一组数据结论）。而且在这15%中，大约只有0.1%不到的缺陷属于新缺陷。的确，自动化测试几乎是无法发现新缺陷的，自动化测试大多是用来发现曾经发现过的缺陷在每个版本下有没有重新出现。自动化测试更适合缺陷预防而不是发现更多缺陷。自动化测试最大的用途就是回归……再回归。而对于我们手机软件测试，用自动化测试更是少的可怜。

自动化测试对测试工程师来说必须有一定的开发技术背景，开发技术越高则写出来的脚本质量也就越高、越有技术性和想象力。所以对于我们现在必须要把程序语言（脚本代码）学习好，有个良好语言的基础，是自动化测试必不可少的条件之一；

其实每一个测试工具能真正地被使用在真实的项目中并驾驭项目的，也没有听说过有一个自动化测试工具能做到适合每一个项目。就拿最近我研究的三大免费自动化测试软件：winrunner,QTP,Loadrunner;我发现其实他们并不是很适合测试我们现在所开发的软件（飘信），飘信是一款基于手机平台的软件，在这样的要求下，我们最好而且我觉得最基本的自动化测试就是工程师第一轮的自测，这样是最节约成本的；我尝试使用winrunner进行测试，这是一款自动化黑盒测试工具，其实在一些很简单的window平台下的软件是可以进行测试的，但是它们对自行开发组件、非Windows标准组件和特有组件的支持很差，容易导致整个测试过程的失败。而且提供的这种基于GUI对象和位图的测试方式，对于具有复杂交互功能的软件而言，他的测试所花的时间和精力不如人工在机器上进行测试的精确并且周到。对于GUI和位图，在这方面我们的这款软件更不需要也不值得花费这么长的精力纠结于在这方面的测试。WinRunner提供了GUI Map的自动学习功能，但这种学习过程在某些情形下与测试过程不能取得一致，达不到理想的效果。因此，仅依赖GUI对象和位图并不能提供足够强大的功能，也不能满足飘信测试的需求；

继续说QTP和loadrunner这两款现今最流行的自动化测试软件，我在研究过程中发现，这两款软件在使用方面确实是异曲同工，他们都需要编写测试脚本，这一项要求对于我们这边的测试团队是有很大的要求的，因为我们这款飘信软件是在各个平台开发的，所以需要研究的语言就要很多种，我的想法是这两款软件是作为测试人员必须要学习的测试工具，就拿测试这个行业来说他们是你必备的，但是在我们这边作为测试工具估计要很长时间的学习，而且自学会要更长的时间，我建议大家有时间的时候学习或者互相研究比较好，但现在按照我们团队的状况使用这两款软件作为自动化测试工具可能有点问题；

再说一个大家都知道的Android SDK这款软件吧，我在eclipse的基础上，进行测试，我觉得还不如就是用手机连接电脑用eclipse直接测试来的方便，在这上面你先要搭配android使用环境，用logcat记录使用情况，与人工测试并无很大的差异，人工可能更方便快捷； android在eclipse中使用Android Test Project是可以进行白盒测试，可是其中仍需要输入android一些测试代码，但是这个我个人觉得这个白盒测试是可以学习的，所以要加强学习，最好让开发人员教导，因为这个应该是他们进行自测的一种测试方法。

我现在在等待一款android自动化测试软件，叫做：AndroidRobot，它正处于试用期，我建议大家也可以看看这款软件的介绍，很适合飘信这款软件的使用！

以上就是我这些天对手机测试自动化的研究与总结，我会继续学习和研究，从而找出更优秀的测试软件符合我们现在的飘信团队测试需要！报告人:xxxx

自动化测试 篇6

关键词：电气自动化 可靠性测试 设备

在20世纪50年代“自动化”一词被提出，电力、电机等产品的出现催生了电气自动化，而继电器和接触器的出现及应用使得机器可以按照人的意志和设定来完成事先安排好的判断和逻辑功能，促使了电气自动化的发展变革；在20世纪60年代，现代控制理论的提出和计算机的应用推进了自动控制和信息处理的结合进程，自动化进入综合自动化阶段，可以实现生产过程控制与管理的有效优化，电气自动化得到了质的飞跃；在20世纪70年代，随着通讯、IT、微电子等技术的快速发展，自动化对象逐渐延伸为大型复杂的系统，出现许多问题难以借助现代控制理论予以解决，通过研究这些问题使自动化理论和手段实现了革新，产生了综合利用系统工程、计算机、人工智能、通信技术等高新技术，应用于复杂系统的高级自动化系统，促进了电气自动化的快速发展；从20世纪80年代开始，电气自动化得到快速发展，目前已经较为成熟，电气自动化已是高新技术的重要组成部分，在工业、国防、医学、农业等领域得到了广泛的应用，极大地促进了人工智能、航空航天、交通、制造技术等诸多领域技术的发展，对国民经济的发展起到了重要的作用。

1、电气自动化控制设备可靠性测试的方式

要对电气自动化控制设备的可靠性进行定量的评价，必须通过相应的测试方式来进行有效的测试。而当前我国对于电气自动化控制设备可靠性测试的方式主要有三种，即实验室测试、保证实验及现场测试。

1.1实验室测试

实验室测试，顾名思义就是在实验室内进行的测试，这种测试方式是依照规定，利用某一可控的条件或者是环境条件，模拟设备使用过程中的使用条件，使被测试的设备可以如同在使用现场中遇到的应力一样进行试验，然后将累计的失效数与时间等数据经过数理统计，进而得出设备的可靠性指标。这是一种模拟的可靠性较高的试验，但这种方式很容易受到测试条件的限制。

1.2保证试验

保证试验是设备在出厂之前所进行的一种无故障性质的测试，又被成为“烤机”。这种测试方式主要是对设备可靠性进行保障的试验，需要的时间较长，对于那些大量生产的设备而言，只能通过对设备样品进行试验的方式来进行检测；另外，该方式在那些电路相对复杂、可靠性要求相对较高且生产数量又不是很多的自动化设备的测试实验中比较适用。

1.3现场测试

现场测试的方式就是在使用现场对电气自动化控制设备所进行的可靠性的测试，通过对各种可靠性数据的记录、统计及分析，得出设备可靠性运行的基本指标。现场测试可以分为三种情况，一种是在线的测试，测试的过程中，设备不需要停止运行；一种是停机的测试，测试过程中，设备需要停止运行；另外一种就是脱机的测试，也就是将被测试的设备或者是部件从系统运行现场去除，放到某一专用的测试设备上进行测试。尽管这一方式的工作环境相对真实，且需要测试设备的数量也比较少，得到的数据可以较为准确的反映出设备的可靠性，但测试过程中各种外界因素并不可控，实验条件在再现性上相对较差。三种不同的测试方式在具体的应用中各有优劣，这就要求电力系统在对电气自动化控制设备进行可靠性测试的时候，需要依照实际条件选择合理的测试方式，并对测试的相关问题进行严格的规范。

2、电气自动化控制设备可靠性测试方法的选择

可靠性测试方法选择的主要角度有：试验环境、试验场地、试验产品和试验测试程序这四个方面。

2.1试验环境。试验环境的选择对试验的效果来说是十分重要的。电控产品不论是在工艺上、规格上还是质量上，差异都很大。因此要根据被试产品的具体情况来选择与之相应的试验环境，以保证试验的客观性。

2.2试验场地。场地的选择也是有规则可循的。如果对产品的可靠性水平有较高的、严格的要求或者产品的实际应用环境较为恶劣时，要选择最严格的试验场地。如果是为了测定一般正常使用条件下的可靠性水平，则应选择工作环境最为典型的试验场地。如果是为了提供可靠的可比性资料，则应选择与实际工作环境相同或近似的试验条件的场地。

2.3试验产品。试验产品的首要要求是要有典型性。电控产品种类繁多、性质多样。因此在进行试验时一定要充分了解产品的相关信息，选取具有典型性和代表性的试验产品进行测试，这样才能保证试验的效果，实现试验目的。

2.4试验的测试程序。一个统一的、科学合理的试验程序是必不可少的，而且在实际试验中，试验人员要严格按程序进行试验。具体来说，一个统一的测试程序要包含以下重要因素：试验起始结束时间、时间间隔的确定、数据的采集、各种性能指标的记录、保障情况的记录、保障的排除等，并且这些要素都要有严格规范，以保证测试的准确性和可信性。

3、结论

随着电气自动化控制系统在我国电力系统当中应用的不断深入与发展，保证电气自动化控制设备运行的可靠性与稳定性可以说是一项重要的工作。

我们一方面要根据电控产品实际情况来选择可行的、高效的试验方法。另一方面，同时也是较为重要的一个方面，即我们要在我国电气自动化发展进程中，不断地完善和创新电控设备可靠性测试的方法，更要切实保证电气自动化控制设备可以安全、稳定的运行，对其可靠性进行系统全面的测试，找到影響其运行可靠性的因素是尤为必要的。但要保证设备可靠性测试的最终结果，必须做好测试方式的选择，注意测试中的各个环节，将我国的电气自动化推向一个新的发展进程。

参考文献：

[1]许卫国，关于电气自动化设备可靠性测试方法的探讨[J].科技传播，010（07）：50-51.

[2]张宏喜.如何对电气自动化控制设备进行可靠性测试[J].价值工程，2011（06）.

[3]吴钰琳，基于MTBF电气自动化控制设备可靠性测试的改进[J].硅谷，2009（12）：27-28.

[4]朱爱珠，黄菊红，徐平原.浅谈电气自动化控制设备的可靠性测试[J].科技资讯，2011（08）.

敏捷中自动化测试策略 篇7

自动化测试是我们应用在敏捷中的类似万能的法宝。但是世界上没有万能的东西。这个就需要我们深刻理解自动化测试, 并且有好的测试策略来应用在自动化测试中。

1 自动化测试中人员的选配

我们的测试团队中, 人员的选配是, 有专门的测试人员, 但是开发人员也会在时间不够的情况下, 加入测试的队伍。在一个敏捷的团队中, 测试人员一般也是具有一定的编程能力的, 当与开发人员沟通一个BUG的时候, 能理解开发人员的话, 沟通更加顺畅。并且在项目需要的情况下, 也会加入开发的队伍中。

2 可以和不可以自动化的测试

2.1 可以自动化的测试

当代码改变, 有新的代码迁入迁出的时候, 这个时候, 需要触发自动化构建。我们通常使用Jenkins这样的持续集成工具, 用于做重复的工作。

自动化单元测试, 我们通常应用junit的单元测试工具, 进行TDD (测试驱动开发) 。

在UI比较稳定的情况下, 做GUI测试。

在回归的时候, 做功能性测试。

在接口测试, 我们可以用Excel, 把测试数据放入其中, 并且跟实际数据进行比较。

负载测试, 我们就必须用自动化了。因为手工测试肯定不准确。我们可以找一些开源的工具来测试。

2.2 不可以自动化的测试

对于可用性测试和探索性测试, 我们需要手工去执行。

3 自动化测试应用的时机

3.1 自动化测试的应用的原因

手动测试的时间远远大于自动化测试。一些重复性的工作最好应用自动化测试。回归测试的时候需要自动化。自动化可以发现手动中一些发现不了的BUG, 比如内存泄露。

3.2 自动化测试的应用的不同部分

在一个敏捷的团队中, 测试可以有自动和手动测试, 比如功能测试。必须手动的测试, 比如探索性测试。必须自动化的测试, 比如单元测试, 性能和压力等。

3.3 自动化测试的应用不同时机

初始的投入, 对于自动化测试来说, 是很大的投资。我们首先评价我们已经已有的工具, 看其价值, 和应用的复杂度。一般来说一些开源工具, 也可以满足我们的需要。而且这样的投入一般是有意义的。

对于变化非常频繁的代码。我们可以根据功能和目的去组织代码。

如果开始自动化呢?并不是非要股买昂贵的商业工具。一般来说, 自动化开始于单元测试, 这样收益是很大的。接着开展可以用于自动化的测试, 我们可以选择一些开源工具。我们并且用一些自动化的构建工具, 比如JENKINS等。我们可以选择开源的功能性验证工具, 比如selenium等。

4 组织测试

在敏捷开发中, 高效的沟通同样也适用于自动化测试。因为在迭代开发中, 当我们用自动化工具发现昨天的测试用例, 今天的版本失败了。我们就必须立刻去找开发沟通。看是, 更改那些地方了, 需求是不是有变化了。以便, 我们的自动化测试, 适应迭代的变化。

在整个团队中, 开发会更多的考虑代码的可测性, 有的时候, 还会给测试人员提供一定的接口, 来实现自动化测试。

工具的选择很重要。在我们的测试团队, 我们有TC, 但是selenium对功能性的验证测试, 有很大的好处, 又比TC好学。就用selenium了。对于开源工具很多都是比较好上手。但是, 对于商业工具, 虽然感觉上很好。但是, 在我们实际的应用的时候, 发现, 难学, 代码维护繁杂。如果, 我们有商业工具的专家, 那么用商业工具, 更能保证项目的质量。

5 结束语

自动化测试策略的应用, 对于我们实现自动化, 是必须经历的过程。好的而自动化测试是质量保证的利器。

参考文献

[1]Sehwaber K, Beedle M.Agile Software Development With Scrum[M].[S.1.]:Prentice Hall, 2001.

[2]Jonathan Rasmusson.敏捷武士看敏捷高手交付卓越软件.李忠利, 译.人民邮电出版社.2012

[3]Lisa Crispin, Janet Gregory, 著.敏捷软件测试:测试人员与敏捷团队的时间指南.孙伟峰, 崔康, 译.清华大学出版社.2010

[4]Martin R G.敏捷软件开发一原则、模式与实践[M].邓辉, 译.北京:清华大学出版社, 2003.

[5]Kniberg H.硝烟中的Scrum和xP一我们如何实施Serum[M].李剑, 译.北京:清华大学出版社, 2011.

[6]Mike Cohn.用户故事及敏捷方法.清华大学出版社.2010

谈软件测试自动化 篇8

信息技术的飞速发展, 使软件产品应用到社会的各个领域, 软件产品的质量自然成为人们共同关注的焦点。不论软件的生产者还是软件的使用者, 均生存在竞争的环境中, 软件开发商为了占有市场, 必须把产品质量作为企业的重要目标之一, 以免在激烈的竞争中被淘汰出局。用户为了保证自己业务的顺利完成, 当然希望选用优质的软件。质量不佳的软件产品不仅会使开发商的维护费用和用户的使用成本大幅增加, 还可能造成灾难性的后果 (如民航订票系统、银行结算系统、证券交易系统、自动飞行控制软件、军事防御和核电站安全控制系统等) 。

为了解决这一问题, 人们在开发过程中使用了很多方法, 力图通过严谨的开发过程保证软件的质量。这些努力当然是创造高质量软件产品的有效方法。但对软件进行测试仍然是保证软件质量最重要和最有效的方法。

软件测试的目的, 第一是确认软件的质量, 其一方面是确认软件做了你所期望的事情, 另一方面是确认软件以正确的方式来做了这个事件。第二是提供信息, 比如提供给开发人员或程序经理的反馈信息, 为风险评估所准备的信息。第三软件测试不仅是在测试软件产品的本身, 而且还包括软件开发的过程。如果一个软件产品开发完成之后发现了很多问题, 这说明此软件开发过程很可能是有缺陷的。因此软件测试的第三个目的是保证整个软件开发过程是高质量的。

进入上世纪90年代, 软件行业开始迅猛发展, 软件的规模变的非常大, 在一些大型软件开发过程中, 测试活动需要花费大量的时间和成本, 而当时测试的手段几乎完全都是手工测试,

u_longipaddr;/*IP地址*/

u_longmask;/*屏蔽码*/

struct accstdinfo next;/*指向标准访问列表项的指针*/

};

ACC_STD_INFO acc_std_list[100];/*标准访

问列表数组*/

第二, CACHE的数据结构。

为了提高查表的效率, 采用CACHE方式, 每次查表先查CACHE寻找匹配。

struct accstdcache

{

u_longsrc_addr;/*数据包的原地址*/

u_longmask;/*屏蔽码*/

struct accstdcache*next;/*指向标准访问列CACHE表项的指针*/

}

typedef struct accstdcache*ACC_STD_CACHE;

第三, 配置命令。测试的效率非常低;并且随着软件复杂度的提高, 出现了很多通过手工方式无法完成测试的情况, 于是, 很多测试实践者开始尝试开发商业的测试工具来支持测试, 辅助测试人员完成某一类型或某一领域内的测试工作, 而测试工具也逐渐盛行起来。通过运用测试工具, 可以达到提高测试效率的目的。测试工具的发展, 大大提高了软件测试的自动化程度, 让测试人员从繁琐和重复的测试活动中解脱出来, 专心从事有意义的测试设计等活动。采用自动比较技术, 还可以自动完成测试用例执行结果的判断, 从而避免人工比对存在的疏漏问题。设计良好的自动化测试, 在某些情况下可以实现“夜间测试”和“无人测试”。在大多数情况下, 软件测试自动化可以减少开支, 增加有限时间内可执行的测试, 在执行相同数量测试时节约测试时间。而测试工具的选择和推广也越来越受到重视。对测试工具能够发挥的作用, 大家都已经了解并认可了, 但是很多引入自动化测试工具的软件公司并没有能够让测试自动化发挥应有的作用。主要存在以下问题:

1过高的期望

没有建立一个正确的软件测试自动化的观念, 或操之过急, 或认为测试自动化可以代替手工测试, 或认为测试自动化可以发现大量新缺陷, 或不够重视而不愿在初期投入比较大的开支等。多数情况下, 对软件测试自动化存在过于乐观的态度、过高的期望, 人们都期望通过这种测试自动化的方案能解决目前遇到的所有问题。

2缺乏专业的测试人才

有些软件公司舍得花几十万元去买测试工具软件, 但缺乏具有良好素质、经验的测试人

(1) 建立标准访问列表或删除标准访问列表

(2) 将标准访问列表应用于接口酬冬访问列表从接口中移走

(3) 显示标准访问列表

3.3 Cisco路由器访问控制的实例分析

下面列举了一些重要的访问列表控制实例:

(1) 防范IP欺骗和欺骗路由器

将访问列表1用于wan连接ip access-group 1in;将访间列表2用于以太网接口, 连接ip accessgroup 2 out。

(2) 阻击来自远程特定IP地址的访问:access-

(3) 保护内部特定主机:access-list 101 deny ip

才。软件测试自动化并不是简简单单地使用测试工具, 还需要有良好的测试流程、全面的测试用例等来配合脚本的编写, 这就要求测试人员不仅熟悉产品的特性和应用领域、熟悉测试流程, 而且很好地掌握测试技术和编程技术。

3测试工具本身的问题

一般不会对自动测试脚本再做大规模的测试, 所以自动测试脚本的质量往往依赖于TA工程师 (测试自动化工程师) 的经验和工作态度, 如果自动测试工具不能提供一种机制来保证脚本的质量, 那将直接影响到测试结果的正确性。

4盲目引入测试工具

有一点很明确, 不同的测试工具面向不同的测试目的、具有各自的特点和适用范围, 所以不是任何一个优秀的测试工具都能适应不同公司的需求。

5没有良好的使用测试工具的环境

建立良好的测试工具应用环境, 需要测试流程和管理机制做相适应的变化, 也只有这样, 测试工具才能真正发挥其作用。

6其它问题

软件测试自动化所需要的测试脚本其维护量很大, 而且软件产品本身代码的改变也需要遵守一定的规则, 从而保证良好的测试脚本使用重复性, 也就是说测试自动化和软件产品本身不能分离。其次, 提供软件测试工具的第三方厂家, 对客户的应用缺乏足够理解, 很难提供强有力的技术支持和具体问题的解决能力。也就是说, 软件测试工具和被测试对象-软件产品或系统的互操作性会存在或多或少问题, 加之技术环境的不断变化, 所有这些对测试自动化的应用推广和深入, 都带来很大的影响。

(4) 保护内部所有主机的重要端口, 如果保护用于文件和打印共享的端口, 应阻止进入网络的135、137、138、139的TCPT和UDP端口。

(5) 阻止外部网络用ping来探测网络, 可以用:

阻止外部网络用traceroute来探测网络, 可以

用:access-list 102 denyicmp anyanytime-exceed-

参考文献

[1]夏亮.强化Cisco路由器的安全配置[J].软件导刊, 2008 (6) 。

[2]赵清源.试论路由器的安全配置与安全维护[J]电脑与电信, 2008年 (3) 。

[3]房莉.Cisco路由器的安全与加固[J].黑龙江科技信息, 2007年 (22) 。

[4]马素刚.路由器安全访问策略设计与实现》, 《西安邮电学院学报》, 2007年 (5) 。

[5]王云.路由器访问列表与网络安全[J].陕西气象, 2006年 (4) 。

存储过程自动化测试的实现 篇9

关键词：存储过程,自动化测试,测试用例,Junit框架,XML

软件测试是保证软件质量的重要手段,软件测试在整个项目开发中所占的比重也越来越大。随着软件规模的扩大和软件复杂性的提高,软件测试技术不断发展,自动化测试技术得到广泛应用,并逐渐成为软件测试发展的方向。单元测试是软件开发过程中要进行的最基本的测试活动,是确保其他测试能够顺利进行的基础。随着增量开发模式和重构技术的发展,软件自动化测试工具JUnit也随之产生。目前Junit已经成为Java程序单元测试框架的标准,已有多种对其进行扩展的自动化测试工具[1]。

存储过程被广泛应用在各种与数据库相关的应用系统中。在开发阶段,对存储过程进行测试是必不可少的工作。通常的测试过程是由测试人员通过命令窗口执行命令,再将命令窗口中的结果信息拷贝下来,保存到一个文件里,在以后再进行分析或者比较。测试工作也可以使用类似Rapid SQL等图形化的工具来辅助做一些工作,但能完成的测试工作量较少。这种大部分依靠手工进行的存储过程的单元测试存在很多缺点,如测试效率低,无法重用,无法进行自动化的回归测试,没有直观的测试结果,需要程序员手工整理测试结果并生成测试报告。针对这些问题,本文在Eclipse中利用Junit测试框架来实现存储过程测试的自动化。

1 Juit的框架结构

Junit是Erich Gamma和Kent Beck编写的一个回归测试框架,它是一个Java程序自动测试的框架[2],用在软件测试的单元测试阶段,即Java对象类的功能测试。JUnit共有七个包,核心的包就是junit.framework和junit.runner。Framework包中包含了Junit测试类所需的所有基类,它是整个Junit的基础框架[3],负责整个测试对象的构架,Runner则负责测试驱动。JUnit框架中主要有以下几个对象类[4,5]:

1)Assert类,它提供在编写测试时要用到的所有assert方法。

当条件成立时assert方法保持沉默,但若条件不成立就抛出异常。Assert类是TestCase的父类。

2)TestCase类

客户测试类所要继承的类,负责测试时对客户类进行初始化,以及测试方法调用。类中的主要方法有:setUp()用于如变量赋值等测试的结果处理,tearDown()用于如文件关闭等测试的结束处理,run()测试实例的执行,并把测试结果放入测试结果对象TestResult中。

3)TestResult类

负责收集TestCase所执行的结果。一般来说,用户不需要对TestResult进行操作,测试结果由系统提供的测试工具自动输出。

4)TestSuite类

TestSuite对象是测试实例的集合,负责包装和运行所有的TestCase。

2 存储过程测试代码的自动生成

Junit测试的实现流程就是继承TestCase类,然后重载它的一些重要方法,如setUp()、tearDown(),最后将这些对象组装到一个Testsuite对象中,交由TestRunner来运行。为了利用JUnit带来的高效率,首先需要改变被测存储过程的调用方式,即从手工调用改为使用JDBC来调用,把一个个存储过程的调用写成Java代码,以后需要进行回归测试时,只需要运行这些Java测试代码就可以了。但是直接使用JUnit,也会是一个烦琐的过程,因为必须在每段测试代码中编写连接数据库的代码和调用存储过程时的一大堆参数设置的代码。对于存储过程测试来说,这些代码就显得非常累赘了,于是设想把这些操作封装为一个公用的类,只需要在测试代码中提供数据库连接信息、存储过程名字和参数值就可以了,其他的工作由这个公用的类来处理。因此在实现存储过程测试代码的自动生成过程中,首先必须要解决如何获得存储过程名和存储过程参数以及在生成的测试代码中如何运行存储过程,下面分别进行讨论。

2.1 存储过程名和参数的获取

在存储过程测试代码生成过程中,第一个问题是要针对哪些存储过程生成测试代码。获取存储过程名可以有两种方式,其一是由用户手动指定,其二是将储过程名称保存在文件中,由系统自动从文件中分析出存储过程名称。这样的文件可以是一个定义了Java常量的.java文件,也可以是一个.properties文件。文件中可用"="来定义存储过程,系统将自动把"="右边的部分识别为存储过程的名称。

要为存储过程自动生成测试代码,有一个前提条件是被测试的存储过程已经在数据库中创建。作为数据库的对象,存储过程的名称、参数等信息也都有相应的数据字典表存放。只要知道存储过程的名字,可以查询数据字典来获取存储过程的参数信息,如参数名称、数据类型、长度、出入参类型等。因此,在测试代码生成过程中可以根据存储过程的名称查询数据库的系统表来获取参数信息,例如DB2的SYSCAT.ROUTINEPARMS表,Oracle的USER_ARGUMENTS表或者SQLServer的SYSCOLUMNS表等。

2.2 测试代码中存储过程的运行

在已经生成的测试代码中,如果将大批的数据库操作写在测试代码中显然是不合适的,这样会造成代码的混乱和维护困难。因此考虑封装一个类,用它专门来运行存储过程,它提供了以下主要方法:

1)SPProcesss(DBInfoObject dbConfig),构造函数,根据传入的数据库配置信息,建立数据库连接,初始化运行环境;2)getSP-ParmList(String routineSchema,String routineName)根据存储过程模式和存储过程名获取参数列表;3)runStoredProcedure(StoredProcedureInfo spInfo)运行存储过程,存储过程信息包含在名为StoredProcedureInfo的类中。4)String(getDurationTime)获取存储过程运行时间;5)object getReturnedObject(int parmIndex)获取存储过程输出参数的值。

其中的StoredProcedureInfo是记录存储过程信息的类,包括存储过程名、存储过程参数列表等。因此,只需要首先创建存储过程信息,然后调用runStoredProcedure方法即可运行存储过程。而这部分代码也是自动生成的,程序员真正需要做的就是修改调用参数的值。

3 改进的Junit框架

采用Junit作为单元测试工具有许多优点,但也存在着不足。在实际的单元测试中,发现JUnit产生的测试代码量是庞大的。为了提高测试代码的复用,文献[6]提出了一种改进的自动化单元测试框架。该框架设计的核心是实现测试用例与测试代码的分离,运用XML文件作为测试数据存储的容器,把每个测试用例中的数据装入到对应的JavaBean中,最后构建一个JavaBean对象为元素的ArraList来存储所有的测试用例。测试执行时,测试代码只需要从ArrayList里面取得测试用例的数据,测试代码仅仅完成验证任务。这样,如果测试用例增加了,只需修改相应的XML文件,而不必再修改测试代码,就可完成相应的测试。

借鉴文献[6]的方法,本文将测试用例和测试结果都存储为XML文档,使用方法writeToFile(String fileName,String time,ArrayLis testResultList)将测试结果保存在XML文件中,测试结果可以包括存储过程运行的时间、返回的记录数、调用的参数列表或者出错信息等。选择把测试结果保存为XML的一个重要原因是通过简单的XML编程即可实现对历次的测试结果的比较分析。其实现方法就是将测试结果的XML文件命名为TestCaseName_年_月_日_时_分_秒.xml,每次运行测试例后,都生成一个具有时间戳的测试结果文件,例如:

testSP_2009_10_18_17_27_00.xml

testSP_2009_10_18_17_30_00.xml

testSP_2009_10_18_17_32_00.xml

通过比较这三个文件中同一个存储过程的运行耗时、返回记录数等指标就能知道这次的测试结果比上次是否有所改进,或者系统在不同时间点的性能变化情况。

有了JUnit测试代码之后,在Eclipse中,左键双击将要运行的Java文件,选择Run As->JUnit Test就可以在工作环境中运行测试文件了。运行完毕后,会生成一个XML文件,再配合以XSL样式文件,就可以在浏览器中看到美观的测试报告了。

4 结束语

Junit和Eclipse两种软件的源代码都能从网上免费获得,利用Junit基于XML存储测试数据和测试结果的新测试框架真正提高了测试效率,简化了测试步骤,从根本上提高了测试代码的重用性。利用JUnit实现了以往存储过程测试中很难进行的回归测试,利用XML技术实现了测试数据和测试代码分离,提高了测试效率,为开发人员提供了直观的测试结果。

现有的测试框架可以扩展到Cactus(Apache Software开发的用来对服务器上的Java代码进行测试的框架)框架上,实现从浏览器进行存储过程测试用例的调用执行,可以克服因为开发和生产环境之间可能存在的网络、安全等因素而影响测试准确性的问题。

参考文献

[1]余波,王树林,张大方.基于Junit自动生成类测试案例框架的实现[J].计算机工程与应用,2006,42(1):89-91.

[2]王东刚.软件测试与JUnit实践[M].北京:人民邮电出版社,2004.

[3]孔亮亮,殷兆麟.Java类测试工具Junit的分析与扩展[J].计算机工程与设计,2005,26(12):3413-3415.

[4]何成万,余秋惠.用JUnit实现Java程序自动测试[J].计算机应用,2002,22(3):93-94.

[5]王聪.基于JUnit框架的软件测试[J].湖北汽车工业学院学报,2007,21(1):43-46.

自动化测试 篇10

1.1 背景描述

在集成测试的过程中, 枯燥繁琐的回归测试一直是一件让测试人员头疼的事情, 特别是在版本不断升级的情况下, 回归案例数量将形成一定的规模, 甚至喧宾夺主, 占据极大的项目投入比例。

计算机的应运而生, 就是为了让机器代替人工, 避免重复、繁琐的人工操作, 提高效率, 而回归测试能否也让机器来代劳, 实现测试的自动化, 这是一个值得深究的问题。

以上两个表格是筛选的项目, 在项目开展过程中, 回归案例不断累积, 在稳定后, 回归案例的比重明显上升。

设想案例总数不断放大, 则回归案例数将是一个令人瞠目结舌的数字。

1.2 问题提出

如何创建一套适合我们的自动化测试体系, 应用到实际的项目中, 以节省回归测试所带来的可避免的人力精力的投入。

2 解决过程

从实际出发, 分析实际需求, 制定开发计划, 并以SGW项目相关案例为实践。

2.1 情牵Python, 缘定Robot Framework

对于自动化测试的关注从未停止过, 而使用什么语言什么工具来实现自动化也是众说纷纭, 与编程语言一样, 合适的才会是最好的。但, 什么才是合适的, 我们需要什么。

通过分析得出, 对多进程的支持、能够获取程序调用输出相关信息、能够连接操作数据库等是我们所需要的, 而集以下优点于一身的python成为了我们的目前最合适的选择:

(1) 成型的体系和文档

(2) 有不断增加的支持库、不断增加的扩展模块

(3) 支持多进程、进程调用, 方法丰富且实用

(4) 语法清晰易懂

而基于python开发的自动化测试框架让使用python的决定更加坚定。

Robot Framework是基于python的, 可扩展的关键字驱动自动化测试框架, 用于实现端到端验收测试和验收测试驱动开发。能够用来分布式、异构应用, 但验证需要涉及到一些技术和接口。

2.2 制定命名规则、形成代码库

团队人员以亲身经历及自己的独到见解, 分析讨论了整个测试过程的一个流程分布, 明确地界定了整个测试过程, 此外, 针对同用户不同操作者使用问题展开进一步探讨, 应当保证整个测试过程的“清洁”, 即保证使用前, 所直接关系或间接关系到的进程全部处于未启动状态, 所涉及到的验证文档 (包括日志、数据库信息、临时文件) 必须为被清除状态, 所需要使用到的临时文件夹必须于生成临时文件前存在, 避免因此非测试因素导致的执行失败, 在使用后, 必须清除所有进程, 相关验证文档。以此两个增加的操作来保证环境的清洁, 保证复用性。

在资深开发人员的协助下, 充分结合测试组讨论结果, 制定了以下基类, 并规范了一系列命名规则。

(1) 根据案例测试流程, 分为六个阶段, 各个阶段有自己的库文件

(2) 通过组织调用各个库文件函数, 来实现各个步骤操作

(3) 各个步骤的代码组合形成了robot库文件

(4) 各个模块具体、明确, 利用robot关键字驱动

2.3 结构图

整体架构如图2所示。

通过分析案例, 将案例分为清理、初始化、启动、发包、验证、退出六个阶段, 将各种阶段操作再细化, 而后形成此案例的相关代码, 调用生成的代码库, 在Robot Framework下字符驱动, 结束测试后, 生成报告文档。

2.4 操作流程图

如图2-3所示, 在操作过程中, 首先, 判断环境上是否已经具备安装了Robot Framework框架、Python等;如果安装成功, 则对案例进行分析;分析完案例后, 判断是否已经上传基于Robot Framework自动化测试的基础库;如果已经上传到指定路径, 则根据分析案例结果, 对整个案例流程细分, 细分根据基类来执行, 并生成具体流程执行文件 (.py) ;通过编辑器创建具体案例, 并将生成的robot文件上传到后台环境;通过命令行输入, 字符驱动, 执行案例;通过Robot Framework执行结果字符数据和生成的结果文件来判断分析执行结果, 生成的结果文档可以作为结果判断的物理依据。

3 具体应用实现

以SGW项目作为实践, 实现了多个案例的自动化测试, 现列举部分实现:

执行结果:

以统计表的方式, 列举出每个案例执行情况及运行时间, 并以类进度条方式直观地体现整个测试结果。

测试报告日志, 详细记录了各种案例执行过程中的输出及报错, 能够很明确地定位执行过程中错误的地方, 有利于查找报错原因。

4 基于Robot Framework自动化测试可能存在问题及解决方案

(1) 结果是否准确

由于验证过程完全是通过代码来实现, 对于摸不到看不着的验证过程, 容易产生这样的质疑, 这样的结果是否可信。答案是肯定的, 不过前提是要将验证过程做到细致全面。

当前自动化采用的判断依据主要是数据库信息、日志文件、进程输出重定向文件、进程调用返回值及文件存在与否的判断, 基本上涵盖了人工测试所涉及到的各个点, 因此, 可以保证其准确性, 主要的难点在于, 如何合理规划验证过程。

(2) 目录如何规划

Robot Framework有自己有编辑器RIDE, 该编辑器可以创建相应的文件目录, 可以很好地来对整个自动化测试集进行管理。

(3) 如何体现测试结果

测试完成了, 那测试结果呢, 要怎么样才能查看到, 有没有细致的结果, 如果执行失败, 怎么样查看错误信息。

很幸运, Robot Framework执行后, 会生成三份文档, 分别为ouput.xml、report.html、log.html。

而其html格式的输出很人性化、直观地体现了测试结果。

(4) 怎样筛选回归案例

测试案例的规划与管理主要是按功能来分的, 当一个新的补丁需要进行回归时, 以字符驱动的后台测试集, 显然不可能像前台管理那样随心所欲地挑选案例进行回归, 此时, 是不是要去一个个地将回归案例挑选出来, 然后执行呢。

利用标签组合可以消除这样的疑虑, 标签是Robot Framework定义的用来标识每一个测试案例、测试套件属性的标识, 即用简单明了的关键字来标记这个测试案例、测试套件所具有的特性, 通过这样的标识组合, 可以筛选出我们所需要的已经标记的案例或测试套件, 能够灵活地筛选, 灵巧地确定我们所需要的案例。

除了通过标签来运行指定程序外, 其本身还可以运行测试集目录, 以下举例说明:

同时, 可以给案例贴上标签, 通过标签, 可以在整个测试集目录下去执行带有某些标签的案例。

通过字符驱动, 可以筛选出带有某些标签的案例,

摘要：基于RobotFramework的自动化测试以python语言为主, 通过字符驱动, 清晰的库代码结构、接口代码结构保证了其清晰明了直接的整体架构, 可实现的人工结果数据验证, 保证了其可信的验证, 完整清晰的报告文档、结果文档和输出文档保证了其详细的结果报告文档, 整体使用流程简单、操作使用方便, 有专门的编辑器RIDE (RobotFramework编辑器) , 管理编辑容易并且明晰, 可用tag对案例进行属性标识, 用字符组合驱动, 即可筛选需要的案例, 灵活驱动。测试自动化给予了计算机一种更加具体生动的诠释, 而通过验证, 证明其是可行、可靠、可信的。在整个体系更加成熟后, 通过对知识的探索与未知领域探究的拼搏所带来的工作效率、产品质量、经济效益的提高, 将会更加富有价值和意义。

软件开发中的自动化单元测试浅谈 篇11

关键词：单元测试；测试驱动开发；Stub；Mock

中图分类号：TP311.52

目前国内很多软件面临的现实问题是质量较差，潜在bug较多，系统不稳定性。这其中的主要原因在于对软件测试的重视程度不够，或者没有系统的测试管理方法。软件测试可分为单元测试、集成测试、系统测试、验收测试，其中单元测试一般由软件模块的开发人员来完成，是软件质量保证的第一道关口。本文将主要针对单元测试介绍的一些技巧和指导原则，以期能给广大一线开发人员以启发和指导，提高在软件开发过程中的效率和软件的质量。

1 单元测试技巧

1.1 使用TDD测试驱动开发

测试驱动开发[1]是由Kent Beck倡导的一种以测试为中心的开发方法，它要求在开始编程之前首先编写测试代码，然后只编写使测试通过的功能代码，通过这种方式以测试驱动开发。这种方法使得代码的设计思路清晰、代码整洁，保证了其做且只做应该做的事。Kent Beck团队为此开发的xUnit测试框架使得该方法的使用更加方便。

在TDD開发中遵循：不可运行->可运行->重构的一个反复过程。首先我们编写测试代码，这时的测试代码是不可运行的，甚至于连编译都通不过，然后我们写最少的代码尽快让测试通过，为了让测试尽快通过我们甚至可以采用一些看起来不合情理的方法，然后进行重构，消除重复设计，优化设计结构，如此反复进行最终得到我们所需的整洁可用的代码。在这种开发方式生成的代码具有高的可维护性和较高的质量保证。

1.2 Stub和Mock的应用

在单元测试中难免遇到一些模块依赖于其它模块，而这些其它的模块很可能并不在我们的控制范围内，它们的开发进度、特性、发布时机等都是未知的，这就可能减缓我们的开发进度，甚至可能会导致我们的测试无法进行。为了解决这类问题我们可以使用Stub和Mock技术，从而消除在测试过程中对第三方模块的依赖。Stub和Mock是两种不同的策略，在使用上是有所不同的，但在很多时候对同一个单位模块的测试我们既可以使用Stub也可以使用Mock，他们两者的不同主要在于Stub是状态验证的，Mock是行为验证的[2]，具体如何选择可参考文献[2]。对于Mock技术，目前有很多的开源框架可以供我们选择，比较流行的有easymock，jmockit。在Stub和Mock技术的使用时机上，建议尽可能使用真实对象，只有当使用真实对象不方面时考虑才考虑使用Stub或Mock技术。

1.3 MVC构架的测试

MVC框架的测试是一个使用Mock技术的好例子。由于目前在一些主流MVC框架（如：struts，spring mvc等）下编写的一些模块（如Struts框架下的Action）在运行的过程中要依赖第三方容器，这就给自动化的单元测试带来了很大麻烦，使得这种测试很难进行，为此可以使用Mock技术来解决这一问题。我们使用Mock对象模拟容器，在这个模拟容器下对软件进行自动化测试。由于这些容器的功能一般比较复杂，所以编写这样的Mock也并不是一件轻松的事情，所幸目前和这些MVC框架对应的一般都已经有了比较成熟的Mock测试框架，我们只需要进行简单的配置就可以使用，如Struts框架有StrutsTestCase框架，Spring mvc下有Spring test框架等。

1.4 数据库测试

软件开发中比较流行分层架构，即将软件划分成多层，包括负责界面交互的表示层、负责处理业务逻辑的业务逻辑层、负责数据持久化的数据访问层。其中数据访问层中的DAO（数据访问对象）负责业务逻辑中对象的数据存取。数据的存取方案可以是多种多样的，但目前使用较多的还是关系型数据库。在这种关系型数据库做存储的系统中，DAO对象要负责和数据库管理系统进行交互。

单元测试中为依赖于外部系统的单元做测试是一件比较痛苦的事，为了消除这种依赖可以采用Stub或Mock技术，但如果要测试的对象就是DAO对象，这个问题就无法再回避。由于数据库是一个公共资源，如果测试过程中不加控制就很容易使其处于一种不可控的未知状态，使不同的测试之间相互干扰。为了在测试过程中始终保持数据库处于一种已知的可控状态，就要在DAO对象测试的过程中对测试数据库进行管理，为此在对DAO对象进行测试时要遵循以下过程：（1）对数据库当前状态进行备份；（2）为本测试准备数据；（3）进行测试；（4）将数据库恢复到测试前的状态。

目前比较成熟的数据库测试框架如：Dbunit，Unitils 等会提供的一些工具可以使我们更方便的完成数据库的备份恢复、测试数据的初始化等工作，从而使我们能够把更多的注意力集中在如何设计、编写单元测试和功能代码上来。

2 自动化单元测试中的一些原则

2.1 使得所用测试可以作为一个整体运行

自动化的单元测试要求我们将同一测试目的或同一测试环境下的所有测试用例组织成一个整体运行，以方便我们在重构或对程序修改时可以快速的对整个系统进行回归测试，可以使用xUnit框架下的testsuit将所有相关测试组织成一个测试套件。如果使用Maven开发则可以直接使用Maven提供的功能统一运行所有测试用例。

2.2 测试用例之间要做到相互隔离，避免存在相互干扰

保证各测试用例之间不产生相互干扰，这样可以方便我们在某一测试失败时快速定位问题所在。这就要求其一对于测试中公共资源的使用要特别小心，如果某测试用例对公共数据有影响，则要在测试执行前做好公共资源的备份，测试后做资源恢复，再者测试用例之间不能存在相互依赖关系，一个测试用例的成功与否不能依赖与另一个测试用例。

2.3 及时运行自动化的回归测试

对于每次重构或bug修复都要及时运行自动化的回归测试以保证此次修改没有将bug引入。无数经验证明在距离bug最近的地方发现并修复bug是代价最低的，同时及时的回归测试也可以给我们带来安全感，增强对程序的信心，提高代码的质量。

3 结束语

本文针对软件开发中的自动化单元测试，结合作者的实践经验，介绍了一些实用的测试技巧和测试基本原则。单元测试技巧部分主要介绍了一些目前业界在开发中最常使用的技术和框架，自动化测试原则部分则针对整个单元测试程序的编写和使用给出了作者的一些指导原则，通过这些方法和原则的使用以期能够帮助广大开发人员更好的做好单元测试，提高软件开发效率和软件质量。

参考文献：

[1]Kent Beck.孙平平，译.测试驱动开发[M].北京：中国电力出版社，2004.

[2]Martin Fowler.Mocks Aren't Stubs[OL].http：//martinfowler.com/articles/mocksArentStubs-.html，2007，01.

[3]Martin Fowler.王怀民，译.企业架构应用模式[M].北京：机械工业出版社，2004（07）：29-35.

作者简介：赵文杰（1979-），男，河南安阳人，助理工程师，硕士研究生，研究方向：软件工程。

Hadoop性能测试自动化研究 篇12

信息爆炸时代带来了信息数量的级数级增长,各行业也越来越认识到对大数据的掌控和分析能力会是未来竞争力的核心。行业决策也超越了以前依靠抽样调查的阶段,转而依靠大数据进行全面分析支持。

Apache Hadoop是对Google的GFS(Google File System)BigTable的一个开源实现,具有高扩展性、高效性、高容错性、低成本以及易于虚拟化等特性,是目前行业事实的应用标准[1]。Apache Hadoop大数据生态圈核心包括HDFS、Zookeeper、Yarn、Hbase、Hive、Impala等应用。

除功能外大数据平台性能处理能力是评测大数据平台的重要指标之一。目前,大数据平台性能测试存在的问题主要有:开源版本更换较快,需要频繁更换版本;测试条目较多,场景比较复杂、繁琐,手工操作容易出错或不准确;整个测试过程持续时间长。本文基于BigDataBench工具和Apache Hadoop2.5进行大数据平台性能测试自动化研究,尝试解决上述问题。

1 大数据平台性能测试内容

经典的大数据平台组件性能测试项主要包括HDFS的读写、Mapreduce的执行情况、NoSQL的数据库能力等[2],如表1所示。

以上测试项覆盖了I/O测试、I/O密集型、计算密集型及混合类型测试条目,涉及文本、图和表等输入数据。

2 大数据平台性能测试工具

在性能测试中,测试工具支持必不可少,目前除A-pache Hadoop自带工具外,还有企业或组织发布了第三方测试工具。一般测试工具包括测试数据生成、负载运行和报告生成三大功能。

2.1 Apache Hadoop自带工具

Apache Hadoop自带工具主要包括TestDFSIO、Sort和PE(PerformanceEvaluation),工具简单、易用。TestDFSIO主要用于HDFS基准性能测试,Sort工具用于Mapreduce负载,PerformanceEvaluation工具主要用于Hbase性能测试。

通过运行hadoop jar hadoop-test.jar即可查看所支持的测试项。通过运行hbase org.apache.hadoop.hbase.PerformanceEvaluation即可查看PE工具支持的测试项。

2.2 HiBench

HiBench是Intel发布的一个大数据性能测试套件,包括HDFS、Mapreduce、SQL、网页搜索以及机器学习等性能测试。支持的测试条目比较全面。

比如最常用的WordCount测试,通过以下命令即可完成测试:

2.3 YCSB

YCSB(Yahoo Cloud Serving Benchmark)是YAHOO发布的一款开源通用性能测试工具,适用于Hbase等NoSQL组件。YCSB在命令行中直接可以设置线程数、读写比例等,可以提供较为详细的测试结果。

2.4 BigDataBench

BigDataBench[3]是由中科院计算所研发的一款开源性能测试套件,是国内大数据组织大数据联盟(www.dca.org.cn)推荐的大数据性能测试工具。大数据联盟(DCA,Data Center Alliance)同时配套发布的还有大数据性能测试基准要求及方法[3]。

BigDataBench整合多种测试工具的优点,几乎覆盖所有组件,可以准备文本、图像、数据库等多种数据,实现端到端的性能测试[4]。

由于大数据联盟的权威性,几乎国内全部大数据厂商都遵循大数据联盟的测试工具及测试要求,并参加了大数据联盟组织的测试。本性能测试自动化系统也主要是基于BigDataBench工具。

3 大数据平台性能测试自动化实现

大数据平台性能测试自动化系统主要实现部署自动化,测试数据准备自动化,性能负载运行自动化以及数据展示自动化。

整个自动化测试过程主要包括版本部署、运行状态检查、数据准备、测试脚本运行、结果收集展示及环境清理几个步骤。

在自动化测试中,版本部署部分通过调用Node.js来模拟浏览器的相关操作。准备数据及运行脚本部分,通过调用预先编写的相关Shell脚本来按测试方案配置并运行BigDataBench的相关测试命令,同时采用Nmon工具来监控主机CPU和内存利用率以及I/O性能指标,通过Grafana展示结果数据[5,6]。具体流程如图1所示。

典型的运行测试负载脚本示例如下:

主机监控脚本实现示例如下:

最终通过Grafana系统展示测试结果,包括主机性能监控指标,各测试负载结果数据,各版本横向测试结果对比,效果如图2所示。

4 结语

本文在大数据平台研发过程中运用本系统来保障性能测试,取得了较好效果。首先确保了各版本性能测试环境、数据、方法和测试标准的一致性,并大幅提高了工作效率,同时做到7×24小时不间断运行。在实际应用中发现,原来需要4~5天的人工性能测试工作可以缩短到2天之内由测试自动化系统来完成。

由本性能自动化测试系统保障的大数据平台在大数据联盟组织的性能测试中,取得了排名前列的成绩。其中NoSQL测试项中的“Write”(读)操作和“Scan”(扫描)两项操作测试指标排名第一。

如何加强基本组件的性能测试,比如生成恰当的测试输入数据,实现应用端到端的测试,同时扩充Spark、Kafka、Storm等新增组件的性能测试套件并整合其它优秀性能测试工具,将是后续研究的方向。

摘要：目前,越来越多的行业认识到大数据会带来新一轮的革命,而Apache Hadoop项目则是目前大数据平台应用的事实标准。各行业在建设大数据平台时,除功能外,性能指标也是考虑的重要因素。目前大数据平台性能评测工具多样,测试过程耗时、繁琐。鉴于此,讨论建设基于BigDataBench的Hadoop2.5大数据平台性能测试自动化系统,既提高工作效率,又减少人为操作差异化化,实现版本间性能数据自动对比,保证了测试质量和数据准确性。同时对自动化测试工具的演进方向进行了规划。

关键词：Hadoop,大数据平台,自动化测试,性能测试

参考文献

[1]朱叶青,牛德姣,蔡涛,等.不同网络环境下大数据系统的测试与分析[J].江苏大学学报:自然科学版,2016(4):429-437.

[2]张新玲,颜秉珩.Hadoop平台基准性能测试研究[J].软件导刊,2015(1):30-32.

[3]陈凯,魏凯,周晓敏.大数据平台基准测试标准化思考[J].电信网技术,2013(2):14-17.

[4]詹剑锋,高婉铃,王磊,等.BigDataBench:开源的大数据系统评测基准[J].软件学报,2016(1):196-211.

[5]姜春宇,孟苗苗.大数据基准测试流程与测试工具[J].信息通信技术,2014(6):43-46.