自动化测试

自动化测试（精选十篇）

自动化测试 篇1

上面提到的模糊测试的研究重点主要集中在模糊器的设计与实现上,几乎没有涉及到错误定位的技术。基于频谱的错误定位方法是基于实际执行的动态错误定位技术的具体应用。Harrold等人证实了程序频谱与程序行为之间的关系,论证了通过研究运行失败测试用例得到的频谱信息与运行成功测试用例得到的频谱信息之间的差异性可为定位出错语句提供帮助[6]。该文调研了模糊测试技术和自动化错误定位技术的研究进展;第2节论述了自动化错误挖掘与定位技术可行性,并解释本文技术的动机;第3节介绍自动化错误挖掘与定位技术的实现方法;模型的实现将在第4节给出;第5节总结并展望未来的研究方向。

1 研究动机

在软件的生命周期中,软件的维护成本所占比例特别大,所以一个好的软件测试方法是非常必要的。一种优秀的测试方法可以发现软件中存在的大部分漏洞,从而可以降低软件的维护成本,提高软件的质量。模糊测试是1989年由Bartoon Miller教授首先提出的,并通过模糊测试在UNIX存在的大量漏洞。在1999年Oulu大学开发PROTOS测试集,这标志着模糊测试发展历程的一个重要里程碑。2002年PROTOS开始成熟,在2004年文件模糊测试开始兴起,AxtiveX模糊测试在2006年开始流行。到目前为止模糊测试取得了一定的发展,已经是软件漏洞挖掘中不可或缺的技术,但是这项技术仍然不是特别成熟[3]。图1给出了模糊测试的过程。

软件错误定位技术是通过运行测试用例得到程序的各条语句被测试用例覆盖的信息,然后利用覆盖信息计算出程序中语句的出错可疑度[7]。在实际的测试过程中,有很多情况是测试用例导致程序的崩溃,程序崩溃时寄存器中的信息也是非常重要的。所以利用程序的覆盖信息与程序崩溃是寄存器存储的信息共同来定位程序的出错信息可以提高定位的精度和速度。利用GCC中的GCOV命令可以收集C程序的运行的详细信息,包括覆盖率、代码的执行路径、程序的执行结果等信息。利用GDB调试器可以查看程序运行时CPU寄存器的状态。

随着计算机的不断发展,程序的代码越来越庞大,基于源代码审核的白盒测试需要大量的人力和时间,这会大大增加软件开发的成本。软件测试的自动化是未来软件测试发展的主要方向,通过把模糊测试技术和软件错误定位技术结合起来,可以实现软件测试的自动化,提高软件维护的效率。

2 自动化错误挖掘与定位技术

在这一节将介绍自动化错误挖掘与定位技术的总体结构,以及对结构中各主要模块的功能与实现。

2.1 自动化错误挖掘与定位技术的总体结构

为了实现软件测试的自动化,所提出的解决方案由一下几个模块组成:模糊器模块,测试结果记录模块,错误位置分析模块。图2为自动化错误挖掘与定位技术的流程图。

2.2 模糊器模块

模糊器模块的主要作用是生成测试用例,并把测试用例提交给被测软件,是模糊测试的核心结构。模糊测试可分为两类[8]:基于变异的模糊测试和基于生成的模糊测试。对于不同的测试目标有不同的模糊器,其中主要的分类有:

1) 环境变量和参数。测试对象主要是命令行参数和环境变量,主要的模糊器是iFuzz。

2) Web应用程序和服务器。针对Web服务器的存在漏洞的模糊器有Dave Aitel开发的SPIKE和WebScarab。

3) 文件格式。针对特定的文件格式,用于挖掘客户端文件解析漏洞,主要的模糊器有notSPIKEfile、SPIKEfile和FileFuzz。

4) 网络协议。通过特定的Socket形式将变异或者含有错误的数据包发送给目标程序,相应的模糊器有SPIKE和ProtoFuzz。

此外对于特定的测试目标,我们也可以手动构造模糊器,在构造模糊器时要充分考虑程序中可能存在的问题,例如:拒绝服务、整数处理问题、简单的栈和堆溢出、格式化字符串和目录遍历等。对于不同的问题确定模糊器不同的用例生成规约。例如,对于整数处理问题,我们可以设计这样的用例规约:生成边界值附近的测试用例0,-1,1,2,3,0XFFFFFFFF-1,0XFFFFFFFF-2等测试用例。此外,我们还可以直接在网上下载有用的工具和库,具体请查看文献[12]。

2.3 测试结果记录模块

我们的目标是实现软件测试的自动化,所以就不能依赖人工识别错误。为了实现这个目标,我们需要一种可靠的,可编程的方法。有一种方法是检查程序的返回代码[9],在现在的UNIX和Linux系统中,如果一个应用程序因为一个为处理的信号而中止,那么Shell的返回代码将等于128加上该信号数字。可以利用这个值来判断不同的错误。还有就是把应用程序连接到调试器,错误处理机制将阻止由模糊测试所导致的许多错误的明显标记,但是这些错误一般可以通过使用一个调试器来发现。在Linux操作系统中,GDB就是一个特别好的调试器,一般来说,GDB主要帮助你完成下面四个方面的功能:1)启动你的程序,可以按照你的自定义的要求随心所欲的运行程序;2)可让被调试的程序在你所指定的调置的断点处停住;3)当程序被停住时,可以检查此时你的程序中所发生的事;4)动态的改变你程序的执行环境。对于有些应用程序,我们也可以通过见识其运行日志带识别程序的运行结果。

测试用例执行路径是用于错误定位分析的主要数据,检测程序的主要方法是在程序的源代码中进行插桩,根据程序的执行结果来得到一个测试用例的执行路径。但是这种方法是基于语句的,在前期对源代码的处理中费时费力,效率低下。在这里提出了一种新的插桩策略,在程序运行的时候,有很多语句块只要语句块的第一条指令被执行,其后面的所有语句都会被执行,把这样的代码块称为基本块。在插桩时以基本块为单位,这样可以减少前期的准备工作,又可以提高程序的运行效率。

对于每个测试用例的结果都进行保存,用于最后的定位分析。我们把用例执行的相关信息保存到数据库中,其中数据库有三个标,分别用为:

1) 代码表(codes),用来存储程序的源代码;

2) 用例执行信息表(info),用来存储用例执行的各种信息,主要用,测试用例、执行路径、执行结果等;

3) 异常表(abnormal),存储导致程序出现异常时CUP各寄存器以及堆栈中的信息。

下面是记录模块的结构图。

2.4 错误位置分析模块

错误位置分析模块的功能是根据数据库中的测试数据计算可能出错或存在漏洞的语句。因为数据库中记录了每条测试用例的执行路径和执行结果。可以利用数据库强大的数据处理能力,计算出错路径中每条语句的可疑度,其计算公式如公式(1):

其中,TFi(S)经过语句S出错(错误类型为i)的测试用例个数,TP(S)是正常经过语句S的测试用例数。最后得到的结果为一系列语句可疑度的列表,其中可疑度最大的,出错的可能性也最大。

3模型实现与实验

实验模型是建立在ubuntu 13.04操作系统上,应用的开发语言是Python 2.7.4,数据库是Mysql Server 5.5.31。在实验模型中主要用到的软件有GCov 4.7.3和GNU gdb (GDB) 7.5.91.20130417-cvs-ubuntu。GCov用于收集用例执行路径,Gdb用于查看测试软件的执行细节。实验用的目标程序是从SIR[10](http://sir.unl.edu)网站上下载的grep。实验中数据库表结构如下表。

通过简单的模拟实验,验证了该方法在软件测试中代码覆盖率、漏洞定位准确性有明显的提高,并且为发现的漏洞提供了相应的信息。并且在整个软件测试过程中,需要人干预的地方很少,基本实现了从用例生成、错误检测和错误定位的自动化。

4 总结与展望

本文中提到的软件测试方法实现了软件测试中用例生成、测试与错误定位分析的自动化,提高了软件测试的效率,加快了软件开发的周期,降低了软件维护的成本。同时该方法也存在一定的局限性,不能测试出软件中存在的逻辑错误,也不能能验证软件功能的完整,只对软件中存在其他错误(非法引用、堆栈溢出、格式化字符串等)有效。

在以后的研究中,应探索新的软件错误定位的方法和技术。可以从一下几个方面展开研究:

1) 利用动态的二进制插桩。在软件测试中,有很多错误不能直接被发现,例如:函数的堆栈溢出,如果溢出只是覆盖了函数中的一些变量,没有覆盖函数的返回地址,即EIP的值。这种情况程序是不会报错的,根据程序的运行结果很难定位错误。所以利用动态二进制插桩来实时监控程序的运行状态是一个不错的研究方向。

2) 利用人工只能,实现软件错误定位与自动修复。随着计算机技术的发展,软件规模越来越大,Binkley估计到2025年人们开发的代码将达到万亿行[11]。面对数量庞大的代码,数据挖掘、机器学习等人工智能技术将会在故障定位方面得到很好的应用。

摘要：为了解决在大规模软件测试中,人工的软件测试费时费力而且测试效果差的问题,该文提出了一种基于模糊测试技术和路径覆盖分析方法的软件测试方法。该测试方法可以自动完成用例生成、用例运行、收集目标程序信息和计算可疑语句的可疑度。通过实验,该方法在不降低代码覆盖率和错误发现率的情况下,缩短了软件测试的时间。

自动化测试经验分享 篇2

以前我时常反思，测试组的工作多吗？我的回答是多。测试小组的工作成果的好坏和工作任务的多少成正比吗？最终的回答却并非成正比。我们的测试工作成果往往并不理想，甚至是差。那么为什么事倍功半？这问题很难找到清晰的答案。

参与了外部培训之后，发现了自己在对测试的工作有了新层次的理解。对之前工作成果差的问题思考也有了新的方向。“测试的最高境界是找出所有BUG吗？不是，测试的最高境界是不需要进行测试。为什么不需要进行测试？是因为所有的问题都已经在软件各阶段中介入的测试工作中给预防解决了。由此引申，测试的定位并不是找出BUG，而是预防BUG。” 这是我培训报告中的一部分。如果测试的出发点只为是发现BUG，那么测试工作将会如何？辛苦的发现了一个BUG，之后开发针对性的修正了这个BUG，再回重新测试的过程，又会有多少人会重新被卷入，又会有多少BUG因此而产生，又需要花费多少时间，答案可想而知。这就是我们忙又不见成果的主要原因。所以改善这个问题的出发点就是改变对测试工作的认识——测试的目标并不是为了找出BUG，而是预防BUG的出现。

如何理解正确的测试目标是预防BUG的出现。首先可以从软件测试的阶段划分来看。软件测试的阶段划分为需求、设计、编码、测试、验收。但按此划分来定位测试是错误的。假如在编码阶段完成后测试出的BUG属于设计问题（这也是我们测试工作中经常遇到的情况），那么我们已经编码完成的产品就要面临着伤筋动骨的修改，这样的修改会带出多少个新的BUG出现？为这个修改我们又要重复的测试我们的新提交版本多少次？想必都有很深刻及惨痛的答案了。由此可以说明需求设计阶段的测试比编码阶段测试重要的多。在需求上出现的BUG就很有可能足以推翻整个产品。那么如果在需求设计阶段测试人员就能发现产品设计的BUG，那么就可以避免了因此而衍生的产品BUG，达到预防BUG这种测试理念的目标。

那么又如何能做好以预防BUG为目标的测试工作。“测试工作不只是一种技术，也不仅是一种活动。测试工作的成功也不能取决于测试成果，测试的BUG越多并不能证明测试工作做的好，所以由此引申，测试工作要站在团队的高度来开展，在团队中做好测试，而不是在测试小组中做好测试。”这是我培训报告中的另一部分。要做好以预防BUG为目标的测试工作，首先要尽早的参与到项目中，其次就是需要各部门及小组的大力支持，与业务、项目、代码人员共同形成团队，在团队中影响其他小组提高产品质量，更好的完成以预防产品出现BUG为目标的测试活动。

总结来看，我个人觉得拥有这样的测试理念可以解开我们的疑惑，带领我们走出目前的困境。

二、自动化测试迷失

随着工作、发展、提高等等多方面的需要，我接到了开展自动化测试的研究工作。概念上来说自动化测试是一种测试度量体系。现实点来说，自动化测试可以为我们自动、无误的运作完成大量且需要重复执行的测试用例。这是多么让人振奋的概念。甚至可以解开我上文所提到的有关测试工作的困惑。我很兴奋的去展开研究目前最流行的自动化测试工具之一QTP。甚至设计出了管理中心的三个重要功能的自动化测试脚本，并且运行无误在自动化测试讨论会上兴奋的向大家演示。之后还用工具按键精灵设计出了前端的A类测试用于实际的测试。但很让人沮丧的是最终这些脚本全被遗弃在电脑硬盘的角落，再也没派上用场。为什么？因为他们维护起来很困难，因为他们编写它们的时间与实现的价值并没有超过手工测试。这就是自动化测试吗？怎么不可行啊，我有点不太相信这种结局，所以我再一次困惑了。

外部培训的老师这样告诉我们：“我们并没有理性的看待自动化测试，自动化测试并不是我们看上去的那样美。首先自动化测试能直接的节约成本、让测试人员变轻松的想法是一个误区。因为原本用于手工测试的时间用来编写及维护测试脚本了，而完善的自动化测试脚本编写或维护的时间很可能会超过手工测试的时间。再者自动化测试脚本用例是测试人员所编写，自动化测试只能是沿着该测试人员的“足迹”前进。所以用自动代测试来发现更多软件产品问题的想法也是一个误区。其次并不是所有的测试都能自动化，测试的自动化也不一定是解决问题的最佳手段。”

听完这些，原本困惑的我又多了份惊讶，一方面惊叹产述的这些状况与我之前的自动化测试的试行失败是相近的。另一方面又猜疑这自动化测试该不会像共产主义社会那般吧！随着培训内容的展开，我终于解开了困惑，何为理性的看待自动化测试。

“如同不能指望原始社会拥有了汽车就能进入现代社会一样，自动化测试工具永远都不能主导测试实现自动化”（出自国信培训文档）。我们错误的把自动化测试看成了一种测试工具或测试手段。自动化测试是一种理念，它要发挥它真正的作用就需要这种理念转变为一种体系——自动化测试体系。

“引入自动化测试的前提是已经建立了合适的自动化测试体系，如果没有这些，而片面的追求自动化，无异于缘木求鱼。自动化测试体系是指能够适用某种环境的测试工具、过程、人员结构、方法的综合，运用于整个项目团队”。回到我之前的对QTP研究失败的原因，首先我开始就觉得因为研发的设计、编码实现并没有考虑到自动化，而导致自动化脚本的编写非常吃力。比如产品页面项目的命名不规范，导致自动化测试工具很难捕捉这些页面对像。其次就是测试脚本的方向迷失，我在研究QTP的时候就发现了这个问题。随着我一点点的在编写着脚本，我不断的发现自己在的测试脚本的编写方向上出现了迷失。这段脚本我编写的目标本来是功能测试，但随着我的补充却接近于开发级的单元测试。而另一段本属于功能性测试的脚本，因为功能的重点需要，我又补充了部分脚本导致整个测试脚本测试目标变成了完整关联性测试。而做为单元测试的脚本却并没有在开发的角度上来设计，根本做不到函数、类等代码级的测试，根本不能达到要求。做为完整性测试的脚本也无法模拟接口功能中几何倍数级的各种条件输入对应的输出测试。而功能测试脚本算是硕果仅存，但随着开发对产品的代码大规模调整（这些调整当然不会考虑对已经实现的脚本的影响）而直接“报废”。如果需要脚本继续工作，那么就要花时间来修改调整它。这些脚本的结局又再一次可想而知了。

所以首先我们要理性的看待自动化测试，不要片面的去追求它。对不同的项目要开展不同自动化策略。参考如下

（1）评审项目中特定的部分作为应用自动化的候选对像。

（2）从项目中高度冗余的任务或场景重点考虑自动化。

（3）将乏味且人工容易出错的工作重点考虑自动化。

（4）将回归测试经常需要“照顾”到的部分重点考虑自动化。

（5）自动化开始时要首先关注开发成熟、理解透彻、相对稳定的且不易变的部分优先考虑自动化

软件测试自动化框架 篇3

自动化测试在过去的20年中已经有了很大的发展。最初的测试工具只提供了简单的捕捉／回放功能：记录并播放键盘按键，然后捕捉和比较屏幕。这些测试方法虽然最容易应用，但是几乎不可能维护。录制回放工具最终被功能和灵活性更强的测试脚本工具代替。

但是，脚本工具也有自己的问题。他们实现起来需要很强的开发技术和经验，同时，不确定它们是一定可以维护的。更糟糕的是高度个性化的脚本工具技术．加上没有什么文档记录，最后的结果经常是重写包含成千上万行代码的脚本库，成本开销巨大。

后来，一种新的自动化测试产品——自动化测试框架出现了，它可以减少实现和维护的成本，使测试人员可以把精力集中在应用程序的测试用例设计上，而不是开发测试。

常用的自动化测试框架

所谓自动化测试框架，是由一些假设，概念和为自动化测试提供支持的实践组成的集合。接下来将描述一下几种比较常用的自动化测试框架：

1．录制／回放的神话

每一家自动化测试工具厂商都会宣传，他们的工具非常容易使用，没有技术背景的测试人员只要简单录制测试的操作过程，然后播放录制好的测试脚本，就可以轻松自动化所有的测试。这样的说法是非常不负责的。

现在我们来分析一下自动化测试不能单单只依靠录制／回放来完成的原因。

通过录制建立的脚本，基本上都是用脚本语言以硬编码的方式编写的，当应用程序变动时，这些硬编码也随之需要更改。因此，维护这些录制好的脚本，成本是非常高的，高到几乎不能接受。

所有的测试脚本都必须是在应用程序可以正确执行时才能录制，如果在录制过程中发现缺陷，测试人员必须向缺陷管理机制报告，等到该缺陷修正了，整个录制脚本的动作才能继续下去。在这样的情况下，如果仅仅依靠录制脚本来进行测试，效率是十分低下的。

同时，这些录制好的脚本不是非常可靠，甚至在应用程序完全没有变动的情况下直接播放，也可能因为一些意外状况而无法执行。如果录制脚本时测试人员使用了错误的脚本语言，则脚本就必须重新录制。

综上所述，通过录制的方式来建立自动化测试脚本的方式看似容易，但实际上会遇到下列问题：①测试人员大多不具备技术背景，难以完全掌握测试工具；②应用程序必须达到一定的稳定性，才能开始录制测试脚本；③录制的测试脚本与测试数据耦合得太紧密；④维护自动化测试脚本的成本非常高。

因此，仅仅依靠录制／回放来完成自动化测试是远远不够的，我们应找到一种能解决上述问题并能很好地执行自动化测试的方法。

2.数据驱动的自动化测试框架

数据驱动的自动化测试是针对上述开发与测试之间紧密耦合问题提出的测试方法。通过建立测试与开发定义的软件元数据的关联——元数据映射表．在测试与开发之间建立松耦合关系。不论测试人员修改测试脚本，还是开发人员修改软件，只需要修改元数据映射表，既可以满足测试与开发同步进行。这样，可以减少测试脚本调试的工作量，更好的实现自动化测试。

什么是数据驱动的自动化测试框架

数据驱动的自动化测试框架是这样的一个框架，从某个数据文件(例如ODBC源文件、Excel文件、Csv文件、ADO对象文件等)中读取输入，输出的测试数据，然后通过变量传入事先录制好的或手工编写的测试脚本中。其中，这些变量被用作传递(输入／输出)用来验证应用程序的测试数据。在这个过程中，数据文件的读取、测试状态和所有测试信息都被编写进测试脚本里；测试数据只包含在数据文件中，而不是脚本里，测试脚本只是一个“驱动”，或者说是一个传送数据的机制。

数据驱动脚本

数据驱动脚本就是那些和应用程序相关联的脚本。这些脚本通过录制或手工编写写进自动化工具私有的语言．然后对其中的变量赋予合适的数值，作为测试数据的输入。这些变量作为一些关键应用程序输入的媒介．使脚本能通过外部的数据来驱动应用程序。

1)可变数据，硬编码组件标志

这些数据驱动的脚本经常包含硬编码的数据．有时是一些窗口组件中非常脆弱的识别字符串。出现这种情况时，脚本很容易由于程序的更改而失去作用。

2)高度技术化的、重复的测试设计

数据驱动脚本的另一个共同特点就是，所有在测试设计上所作的努力最终都体现在自动化工具的脚本语言中，或者复制到手工和自动化测试脚本中。这意味着每个和自动化测试开发或执行有关的人必须对测试环境和自动化工具的编程语言非常精通。

优点与缺点

1)优点：①在应用程序开发的同时就可以同步建立测试脚本，而且当应用功能变动时，只需要修改业务功能部分的脚本；②利用模型化的设计，避免重复的脚本，减少建立或维护脚本的成本；③测试输入数据，验证数据和预期的测试结果与脚本分开．存放在另外的数据文件里．利于测试人员修改和维护；④透过判断功能回传值是“True”或“Fslse”，可作错误处理，增加了测试脚本的健壮性；⑤自动化测试开发人员创建数据驱动的测试过程．测试员创建测试数据；⑥在测试的过程中收集测试结果，并在输入数据的语境中表示测试结果，这样可以简化手工结果分析。

2)缺点：①对自动化测试工具里的脚本语言必须非常精通；②每个脚本都会对应多个数据文件，这些数据文件需要根据脚本的功能类别存放在各自的目录中，增加了使用的复杂性；③测试人员除了需要根据具体测试数据维护相应的测试计划，还要将这些数据写入各个需求不同的数据文件中；④在编辑数据文件时，必须注意测试脚本所要求的传输格式，否则会在处理脚本时产生错误。如由专门的技术人员对其进行维护，依赖于数据驱动脚本的自动化测试框架实现起来更简单、快捷。但是，维护工作困难，而且还需要保持这种数据驱动的模式，这样，即便长时间的维持也会导致失败。

3．关键字驱动的自动化测试

关键字驱动的自动化测试(也称为表驱动测试自动化)，是数据驱动自动化测试的变种，可支持由不同序列或多个不同路径组成的测试。它是一种独立于应用程序的自动化框架，在处理自动化测试的同时也要适合手工测试。关键字驱动的自动化测试框架建立在数据驱动手段之上，表中包含指令(关键词)，而不只是数据。这些测试被开发成使用关键宇的数据表，它们独立于执行测试的自动化工具。关键字驱动的自动化测试是对数据驱动的自动化测试的有效改进和补充。

关键字驱动的自动化测试的整个过程所包含的功能都是由关键字驱动的，关键字控制了整个测试过程。下面以“Post

a Payment”为例．说明这种自动化测试方法是如何运作的(表1)。

上表的COLUMN1里的每一个关键字都与一个应用脚本有关，而其他栏标识的是该脚本所要传入的参数。事实上，按照这个表格里所描述的测试用例．测试人员也可以手工实行这个测试用例。

图1以表1所描述的测试用例为例，说明了整个关键字驱动的自动化测试的运作机制：

1)测试人员会以ExceI表格建立如表1所示的测试数据文件，如KeyWord_Web．xls；

2)会有一个驱动测试脚本启动整个测试的进行，包含一些初始化的工作，如Driver脚本；

3)Controller脚本包含负责解析整个测试数据文件的关键字，以便决定运行哪一个应用脚本；

4)应用脚本实际执行每个测试动作，并使用表1中其他栏里的参数，执行完后将结果回传给Controller脚本，当Con-troller脚本执行到最后一行，整个测试用例结束执行。

需要注意的是，虽然这种自动化测试方法同时适合手工和自动执行，但并不意味着只要应用程序准备好可以执行，这些测试就能自动地执行。表1中的记录很容易被测试人员理解和执行，但是，除非我们提供给它，自动化框架不知道记录中对象的任何信息。

优劣分析

关键字驱动的自动化测试框架是一种截然不同的思想，它把传统测试脚本中变化的与不变的东西进行了分离，这种分离使得分工更明确，并且避免了它们相互之间的影响。 这种模型的开发和实现与传统的测试流程相比可能是困难的，最耗时的，因为，我们正在努力地将我们的测试和自动化工具以及应用程序本身的变化完全隔离开来。为了实现这个目标，最重要的是要增强自动化工具所提供的组件功能，例如，错误纠正、避免和数据同步。但是这样的投资是一次性的，一旦开发结束并投入使用，它给我们带来的效益是巨大的，是自动化测试框架中最容易维护和使用的，而且可以反复运用于各种应用中，长期发挥作用。

另外，现在已经有一些符合需求的商业化产品可供使用，减少了实现这种框架的困难。利用关键字驱动的自动化测试框架，测试人员不需要录制测试脚本，而是设计测试脚本。

4．混合的自动化测试框架

结合以上几种自动化测试框架的比较，目前最为成功的自动化测试框架应是综合使用数据驱动和关键字驱动的自动化测试框架：以数据驱动的脚本作为输入，通过关键字驱动框架的处理得到测试结果，完成自动化测试过程。这样可以使数据驱动的脚本利用关键字驱动框架通常所提供的库和工具。这些框架工具可以使数据驱动的脚本更为紧凑，而且也不容易失败。

关键字驱动的自动化测试框架模型

下面将介绍一种以关键字驱动自动化测试框架思想为指导的自动化测试实现方案——关键字驱动的自动化测试模型，它是由SAS Institute的Carl Nagle开发的。图2描述了该测试模型的结构。

这个模型主要由核心数据驱动引擎、组件函数、支持库和应用映射表组成。自动化测试首先由初始脚本开始执行，这个脚本把高层测试表传递给高层驱动器，高层驱动器在处理这些表的过程中．遇到中层测试表后就调用中层驱动器，中层驱动器处理中层表时也作类似的处理。当低层驱动器处理低层表时，它尝试着使应用与测试保持同步。当低层驱动器遇到对某一个组件的低层关键字组件时，它判断这个组件的类型并调用相应的组件函数模块来处理这个指令操作。所有这些元素都要依靠映射表中的信息，它是自动化测试模型和被测应用程序的桥梁。

应用映射表

应用映射表是自动化测试模型中最关键的组件之一。在进行测试设计之前，测试人员首先对应用中的每一个对象定义一套命名规范，并利用映射表把这些名字和自动化工具识别的对象名联系起来，使工具能准确地定位和操纵对象。我们的测试脚本只需进行单点维护。在上面的例子中，如果按钮的名字或显示文字发生了变化，那么脚本中所有涉及这些名字的地方都要进行修改。如果我们建立这样一个映射．用逻辑对象SavePushButton表示真实的确认保存的按钮对象，那么这个例子就可以写成“Click SavePushButton”。当按钮的名字或显示文字改变时，只需要快速修改一下映射表中对应的识别方法就可以了，而不用修改脚本(表2)

组件函数

组件函数是实现用户对界面对象操作指令的函数，一个组件对象的类型对应一个组件函数库。例如对于一个文本框对象．测试人员可能会对它执行多种操作：输入文本、验证文本框的值、验证文本框的某些属性等，实现这些操作行为的函数就被放在文本框的组件函数库中。一般的测试工具都提供了这样的函数，而我们可以在其中加入额外的代码来检测错误、纠正错误和帮助同步，这类代码是实现无人职守的自动化测试所必需的。

组件函数相当于在应用和自动化工具之间提供了一个隔离层．如果没有这个隔离层．自动化工具本身的改变或提高就会影响已有的脚本．但是有了组件函数，我们可以增加一对修补代码来适应这些变化，转移对测试的破坏。组件函数关键字和它们的参数构成自动化模型最低层的词库．了解了低层词库和映射表，就可以建立在它们基础之上的测试表。

测试表和核心数据驱动引擎

测试表分低层、中层和高层。低层测试表指定了测试的每一步指令的细节，这些指令都是直接作用在界面对象上的，是无法再细分的指令。中层测试表把低层测试表组装起来执行更多有用的任务。同一个低层表可以用于多个中层表，所以我们应该开发尽可能少的低层表，然后把它们按照不同的目的组装起来．实现最大的重用性。同样的，高层测试表把中层表组装起来，形成一个测试循环，每个循环都是完整的，可以定制不同类型和数量的测试。

例如打开网页、登录。关闭网页这3个动作可以用3个低层表来表示，每个表定义了实现相应动作的具体步骤，所以低层表又叫做步骤表。低层表中使用了映射表中定义的对象名．和由组件函数定义的低层关键字词库。表3是一个实现登录动作的低层表。而这个表示“登录”的低层表关键字很可能会出现在“验证错误登录”。“验证正确登录”、“验证空白登录”等中层表中，这些中层表合起来构成了“验证权限”高层表。

对应于以上这3个测试表．核心数据驱动引擎相应地分成了高层驱动器．中层驱动器和低层驱动器。高层驱动器读取高层表的每个记录，如果遇到中间表关键字。就把这个表传递给中层驱动器，依此类推，直至到达低层表，低层驱动器调用关键字词库中的低层指令所对应的组件函数来完成最后的执行。最后要说明的是这样一种层次结构并不是固定不变的．可以根据实际应用情况进行调整。

支持库

支持库是一些程序和工具，例如文件处理、字符串处理、缓；中处理、数据库访问、日志记录工具等，它们为自动化模型提供最基础的支持。

结语

软件自动化测试 篇4

关键词：软件测试自动化,引入条件,风险分析

1 概述

软件测试自动化, 从计算机这一庞大学科发展至今, 最根本的意义是解决手工劳动的复杂性, 成为替代某些重复性行为模式的最佳工具。

2 实施软件测试自动化的理由

(1) 提高测试效率和降低测试成本。

(2) 将重复性强的测试由手工转为可以独立开来自动实现的。

(3) 实现快速的回归测试, 提高新版本发布的速度和质量, 尤其是不能适应目前流行的迭代开发, 回归测试频度高、工作量大, 人工的测试很难对新的迭代版本作出快速评估。

(4) 自动测试可以避免人工测试容易犯的错误:错误测试、漏测试、多测试和重复测试等。

(5) 典型的应用, 例如多用户并发注册、并发交易请求和并发交易应答, 这种情况用人工测试几乎是办不到的, 而自动测试却很容易。

(6) 对于很常用的功能性边界测试测试, 人工测试非常耗费时间, 而自动测试很快且准确。

可以说, 实施测试自动化是软件行业一个不可逆转的趋势, 如果在这个领域走在了前列, 无论从企业的核心竞争力还是个人的工作技能来说, 都有巨大的优越性。

3 软件测试自动化的引入条件

自动化测试能大大降低手工测试工作, 但决不能完全取代手工测试。完全的自动化测试只是一个理论上的目标, 实际上想要达到100%的自动化测试, 不仅代价相当昂贵, 而且操作上也是几乎不可能实现。一般来说, 一个40-60%的利用自动化的程度已经是非常好的了, 达到这个级别以上将过大的增加测试相关的维护成本。

测试自动化的引入有一定的标准, 要经过综合的评估, 绝对不能理解成测试工具简单的录制与回放过程。实际上, 从实现成熟度来说, 自动化测试分五个级别, 如表1所示。

自动化测试能提高测试效率, 快速定位测试软件各版本中的功能与性能缺陷, 但不会创造性的发现测试脚本里没有设计的缺陷。测试工具不是人脑, 要求测试设计者将测试中各种分支路径的校验点进行定制, 没有定制完整, 即便事实上出错的地方, 测试工具也不会发觉。因此, 制订全面、系统的测试设计工作是相当重要的。

自动化测试能提高测试效率, 但对于周期短、时间紧迫的项目不宜采用自动化测试。推行自动化测试的前期工作相当庞大, 将企业级自动化测试框架应用到一个项目中也要评估其合适性, 因此决不能盲目的的应用到任何一个测试项目中, 尤其不适合周期短的项目, 因为很可能需要大量的测试框架的准备和实施而会被拖跨。

实施测试自动化必须进行多方面的培训, 包括测试流程、缺陷管理、人员安排、测试工具使用等。如果测试过程是不合理的, 引入自动化测试只会给项目团队带来更大的混乱。

那么应该具备什么样的条件才可以引入自动化测试呢, 才可以最大可能的减少引入风险, 并能够可持续性的开展下去呢?

(1) 从项目规模上来说, 没有严格限制。无论项目大小, 都需要提高测试效率, 希望测试工作标准化, 测试流程正规化, 测试代码重用化。所以第一要做到的, 就是从公司高层开始, 直到测试部门的任何一个普通工程师, 都要树立实施自动化测试的坚定决心, 不能抱着试试看的态度。一般来说, 一个这样的软件开发团队可以优先开展自动化测试工作:测试与开发人员比例合适, 比如1:3到1:5, 开发团队总人数不少于10个。

(2) 从公司的产品特征来说, 一般开发产品的项目实施自动化测试要比纯项目开发要优越些。但决不是说做纯项目开发不能实施自动化测试, 只要软件的开发流程、测试流程、缺陷管理流程规范了, 自动化测试自然水到渠成。

(3) 从测试人员个人素质和角色分配来说, 除了有高层重视外, 还应该有个具有良好自动化测试背景和丰富自动化测试经验的测试主管, 不仅在技术方面, 更重要的是在今后的自动化测试管理位置起着领导的作用。还要有几个出色的开发经验良好的测试人员, 当然也可以是开发工程师, 负责编写测试脚本、开发测试框架, 还有一些测试执行者, 他们要对软件产品业务逻辑相当熟练, 配合测试设计者完成设计工作, 并在执行自动测试时, 敏锐的分析和判断软件缺陷。

综合分析上述三个条件, 就可以决定是否推行自动化测试;但是为了减少实施风险, 还要预测到其他潜在的风险, 做好事先解决问题规避风险的思路。

4 对实施自动化测试的风险分析

资金风险, 虽然有些项目具备实施自动化测试的条件, 但还是要引入自动化测试后组织结构调整等方面的成本估算是很必要的。

自动化测试对软件功能类型的切入点的风险, 开发的产品业务和功能是否需要自动化测试?包括白盒自动化测试、功能自动化测试和性能自动化测试。

软件自动化测试切入方式的风险, 一定要将自动化测试与手工测试结合起来使用, 不合理的规划会造成工作事倍功半。首先, 对于自动化测试率的目标开始是20/80 (20%的自动化测试和80%的手工测试) , 当这些目标都实现了, 再将自动化测试率提高。

时间估算, 在评估完前面几项指标后, 需要估算实施测试自动化的时间周期, 以防止浪费不必要的时间, 减少在人员、资金、资源投入上的无端消耗。虽然到测试自动化步入正轨以后, 会起到事半功倍的效果, 但前期的投入巨大, 要全面考虑各种因素, 明确实施计划并按计划严格执行, 才能最大限度降低风险。

工作流程变更风险, 测试团队乃至整个开发组织实施测试自动化, 或多或少会因为适应测试工具的工作流程, 带来团队的测试流程、开发流程的相应变更, 而且, 如果变更不善, 会引起团队成员的诸多抱怨情绪;所以应该尽量减少这种变更, 并克服变更中可能存在的困难。

5 什么条件下使用自动化测试

一般在这样的条件下使用自动化测试:

(1) 具有良好定义的测试策略和测试计划 (知道要测试什么, 知道什么时候测试) 。

(2) 对于自动化测试你拥有一个能够被识别的测试框架和候选者。

(3) 能够确保多个测试运行的构建策略。

(4) 多平台环境需要被测试。

(5) 拥有运行测试的硬件。

(6) 拥有关注在自动化过程上的资源。

如下条件下是宜采用手工测试:

(1) 没有标准的测试过程。

(2) 没有一个测试什么、什么时候测试的清晰的蓝图。

(3) 在一个项目中, 测试责任人是一个新人, 并且还不是完全的理解方案的功能性和或者设计。

(4) 整个项目在时间的压力下。

(5) 在团队中没有资源或者具有自动化测试技能的人。

6 某软件公司实施软件测试自动化情况

某软件公司在ITS、GIMIS、HPC等项目中实施了自动化测试, 自动化测试比例较高 (如ITS自动化测试占65%, 手工测试占35%) , 经过多年来自动化测试的实施, 收效较好的原因主要有:

(1) 在测试工作本身流程上、组织结构上根据实际情况进行了多次有效的调整与改进, 甚至也包括需求、设计、开发、维护及配置管理等其他方面的进行了有机的配合。

(2) 软件开发团队工作尤其注重以人为本, 项目团队一开始的组建就非常重视人员之间的配合、测试组织结构的设置, 每个角色都要将自己的责任完全担负起来, 减少和解决设计、开发和测试之间的矛盾。

(3) 项目管理部门对开展自动化测试的监督和评估起到了积极的作用, 也包括对项目测试的检查和人员的考核。将自动化测试全面深入地贯彻到测试工作中。

软件(自动化)测试工作总结 篇5

2012年自动化测试工作严格按照要求，保质保量完成客户指派的任务。截止目前，已完成话费收取、账单查询、产品变更、营销活动等137项关键业务测试用例、105个自动化回归测试场景设计，范围涵盖个人业务、家庭业务、集团业务、账务管理、营销活动及各类常用查询功能。陕西公司在大型版本上线时均进行关键业务自动化回归测试，降低了新版本上线风险，保证了新版本上线后关键业务和常用业务正常受理。累计已进行新需求上线前后回归测试68次，运行业务脚本13100余次，发现系统原有缺陷38个，新需求缺陷69个，进行业务规则梳理146个，为新需求影响范围分析提供了数据依据，较大程度的提高了上线成功率，降低了上线后系统的缺陷率，提高了系统的稳定性。

从2012年5月份入职到现在的多半年时间内，主要对系统，业务的深入理解，学习。对工作中所运用到得工具熟练掌握，每次上线都能按照要求，独立完成分配的任务。对自动化脚本进行重新整理改进，发现问题及时联系局方人员进行协商，处理。

主要工作内容是负责自动化测试这块，自动化测试的目的在于保障在新业务上线后，能正确的把控新上线内容对整个生产环境的影响。确保在新业务上线过程中，及早发现关键业务的情况，判断其是否受到影响，同时确定新上线业务是否满足要求，达到预期的功能目的。每次上线加班，严格按照要求进行测试，仔细记录测试中发现的BUG，当天寻找开发或相关负责人进行解决，每次按时到达工作现场，认真对待工作，至今没有由于个人原因出现严重过错。其他时间，对测试环境，测试数据和脚本进行维护，管理。领导每次分配的任务认真对待，按时保质完成。

工作中存在还需要以后改进的几点：

1、对业务的熟悉度更进一步了解，拓展。

2、对脚本进行改进，创新，能够更全面的覆盖测试面，争取最大限度的找出问题所在。

3、在测试工具，软件，脚本等方面进行创新，提高测试正确度，测试效率，真正达到自动化测试的目的。

通风机性能自动化测试系统研究 篇6

关键词：通风机 性能 自动化 测试系统

中图分类号：TP274 文献标识码：A 文章编号：1674-098X（2016）06（a）-0001-02

目前，国内很多相关的研究部门和人员已经开始对通风机所具有的性能进行测试和研究，并且开发出了相应的测试装置和测试技术。但是，在实际的应用过程中，还存在诸多问题，如对最终的测试结果分析不到位、访问功能过于单一等等。因此，为了进一步改善通风机所拥有的性能，提高其在实际生产运营中的性能和作用，笔者对其进行了较为详细地阐述和说明。

1 通风机测试系统的总体概述

1.1 测试系统的结构组成

通风机测试系统的结构一共分为两个部分，即硬件部分和软件部分。其中，硬件部分的构成主要包括的设备仪器有传感器、试验台、计算机、信号处理器以及输入输出设备等，如图1。在进行实验时，只需要调整相关设备便能够完成性能测试实验。而软件部分主要包括的是模块和用户界面。模块根据其功能与性能的不同，还可以将其分为处理、控制、采集、访问、绘制等模块，用以完成系统的测试与运行[1]。

1.2 测试系统的基本测试原理

对通风机的系统进行测试所采用的测试原理主要是：进行测试的测点转矩和转速等参数，利用相关的设备仪器能够将其转变成电信号，然后在对这些信号进行处理、传输等过程，将其输送到相应的电路当中。并在该电路中对信号进行采样、处理和转换之后，将最后所得到的数据信号输送到计算机中，从而使端口和计算机两者之间实现正常的通信，计算机也能够通过相应的操作，对模块进行调用并完成相应的工作[2]。

2 通风机测试系统的具体实验

2.1 硬件实验

在对测试系统的硬件进行实验时，所需要的传感器主要包括转速、扭矩、差压、压力4种传感器，使用种类如此多的传感器主要是为了使传感器在进行实验时，能够保障器具有良好的灵敏度和稳定性。

在具体实验过程中，应取通风机上的10个测试点，这样便能够对10种电路信号进行收集和传输，且还能够对信号进行过滤，从而满足实验的需求。接口电路所使用的则是一个具有多功能接口板，能够对数据信息进行采集和处理。

2.2 软件实验

基于Windows 7系统，应使用Visual basic 6.0作为测试系统的开发工具，并结合使用动画、菜单、图形等多种计算机软件技术，以完成用户界面的设计工作。当设计出的用户界面十分友好且易于操作，将会大大降低出现错误操作的几率，提高工作人员的效率。

控制模块的主要作用是用于控制整个系统。其所采取的控制形式是通过调用菜单中的各个模块，实现对各功能的控制，从而完成测试工作。

采集模块的主要作用是用于处理收集到的数据信息。在处理过程中，其所采用的是综合滤波的方式，对采集到的信息数据进行处理，从而形成最终的信息采集结果，再以表格的形式呈现在实验人员的面前。

访问模块的作用是用于访问数据库。工作人员可以通过利用数据库本身所具有的特征去创建数据库，然后采用通风机型等多种查询条件为主的查询方式对其进行访问。然后，再使用访问模块所具有数据源、记录源以及表格控件等特性显示出查询结果[3]。

绘制模块主要是用于曲线的绘制。其主要利用曲线坐标与鼠标位置间的关系，在图形上呈现出动态的分析结果。

3 通风机测试系统的分析

在对系统进行测试的过程中，难免会在很多环节出现一定的误差，这便需要工作人员对其进行误差分析。在分析误差时，需要对产生误差的原因、误差的大小与性质等方面进行综合分析，再将其进行合成误差估算。相关实验数据表明，在分析产生误差的因素时，如果忽略了测点的形状以及粗糙度等因素，则会使压强最终的测量结果产生2%的误差，转矩和转速的测量结果产生1.5%的误差。所进行合成误差估算产生的流量误差为1.25%，压强误差为2.5%，功率和效率产生的误差则为2.5%和5%。上述所得出的各项数据的误差值均为理论误差值。在具体测量的过程中，由于会受到其他外界因素的影响和误差之间相互抵消的关系，通常情况下实际误差值要比理论误差值偏小[4]。基于这种情况，暂且将手工测试所得到的最终结果视为真实数据信息，让两种测试方法所得出的结果进行比较，从而获得以下的结论：（1）产生的压力误差大约为1%；（2）功率误差则是0.7%；（3）效率的误差相对于其他误差较大，为2.2%。

4 通风机测试系统的最终结论

根据对系统进行测试所得出结果进行分析，能够得出以下几点结论：首先，该测试系统不仅具有良好的稳定性和合理的结构，操作还十分简便、功能也较为强大，能够用于对不同种类和规格的通风机进行实验，以判断其性能是否能够满足实际生产运行的需求。其次，使测试变得更加智能、数据更加准确，综合提高了系统测试的稳定性、可靠性以及测试效率。再次，工作人员对手工测试方法和自动测试方法进行实验研究，这两种测试方法所得出的最终实验研究结果基本相同。但，如果所使用的相关元器件具有很高的精度，那么自动测试方法所得出的实验结果将会更准确。最后，对于自动测试系统进行深入研究，得出更加完善的实验方法和系统，在日后对通过机进行调整时，能够实现在线调整。此种调整方法的应用具有很高的推广价值[5]。

5 结语

为了提高通风机的工作效率，增加其在运行过程中的稳定性和良好效率，应充分了解通风机的各种性能数据指标，确保其能够满足实际的生产运行需要。基于此，研究出新的性能测试系统具有重要的意义。该文所研究的测试系统，主要是以检验通风机的性能作为测试的最终目标，其具有较高的自动化，所得出的测试结果受到人为因素和外界因素的影响较小，具有良好的稳定性、可靠性以及准确性。

参考文献

[1]钟越波，张志新，李锡林，等.基于虚拟仪器的通风机性能测试系统[J].风机技术，2009，2（3）：49-51.

[2]桂艳，吴志涛.通风机性能参数自动采集与分析系统的研究与开发[J].机械设计与制造，2009，6（10）：83-85.

[3]陈玉，许德章，江本赤，等.通风机性能自动测试系统的研究[J].机械工程师，2006，4（8）：96-98.

自动化测试实现研究 篇7

关键词：自动化测试,实现,需求

软件测试一个特点是重复性,重复测试让我们产生厌倦心理,因此人们想到用工具来解决重复的问题。另外手工还存在精确性的问题,尤其是面对大量数据需要检查时候,人工的比较和搜索存在效率问题,易出错,覆盖面低。手工测试存在效率问题,这在软件产品的研发后期阶段尤其明显,随着功能日趋增多,需要检查的点和测试内容也越来越多,人工回归测试难度增大,很难在短时间完成大面积测试覆盖。当然,手工测试也有不可替代的地方,比如测试用例的设计,界面和用户体验性测试,正确性的检查,而自动化通过计算能力,不知疲倦地运行,对于数据能精确运行。因此,在需要重复执行界面操作、计算、数值比较、搜索等方面。我们需要充分利用自动化测试工具的高效率来帮助测试人员完成测试用例的执行,加快回归速度,提高测试覆盖率。

1 自动化测试准备

在进行项目自动化测试之前,首先要考虑以下5个方面,其次是衡量项目开展自动化的一些条件。

(1)测试自动化类似于软件开发过程

录制/回放脚本开发方式是不可能应付所有自动化测试需求的,因此需要测试人员掌握必要的开发知识和代码。

(2)测试自动化是一个长期的过程

自动化测试只有长期多次运行才能体现出价值,同时需要考虑自动化测试维护成本。

(3)确保自动化测试的资源,包括人员和技能

最好有专门的自动化测试工程师来保证测试自动化持续,需要对项目负责,设计测试框架和脚本结构,解决各种测试脚本开发问题。

(4)循序渐进开展自动化测试

(5)确保测试过程的成熟度

2 自动化测试开展

自动化测试只有在多次运行后,才能体现出自动化的优势,只有不断地运行自动测试,才能有效预防缺陷,减轻测试人员手工的回归测试工作量,如果一个项目是短期的,则不适合开展,另外,不宜在一个进度非常紧迫的项目中开展自动化测试。

自动化测试不应该在界面尚未稳定的时候开始,但是此时可以着手准备自动化测试计划和准备工作,自动化测试工具评估使用。

首先分析项目的特点,软件系统采用的开发工具、语言、技术平台等,结合测试的类型,测试的要求,同时还要了解目前存在的各种测试工具的情况,根据选择的测试工具,进行试用,制订一份详细的测试工具使用计划。

3 自动化测试工具

软件测试可以按照自动化工具类型进行分类,软件自动化测试工具是实现软件自动化测试必不可少的关键,因此,选择一个优秀的、适合自己的测试项目的测试工具是实现成功自动化测试的第一步。

3.1 按用途分类

软件自动化测试工具按安装用途可分为

·测试管理工具

·自动化功能测试工具

·性能测试工具

·单元测试工具

·白盒测试工具

·测试用例设计工具

自动化测试工具可基于GUI层面进行测试,也可基于代码层面进行测试,只要实现了自动化执行测试用例,自动检测测试数据的测试工具,替代人工进行测试步骤的执行,从而验证应用程序是否满足了特定功能的测试工具。

3.2 基于代码层面的功能自动化测试工具

基于代码层面的功能自动化测试工具主要是一些单元测试工具,例如junit,这些工具直接访问被测试的应用程序的代码,对其中的类和函数进行调用,输入各种测试数据,检查函数的返回值,通过比较返回值与期待值是否一致来判断测试是否通过。

3.3 基于浏览器和DOM对象模型的功能自动化测试工具

例如selenium,这些测试工具直接访问Web浏览器,利用脚本语言操作浏览器和Web页面中包含的DOM对象,从而达到模拟用户控制浏览导航、页面元素的操作等效果,并直接获取DOM对象的属性,从而获得Web页面元素的各种属性,通过这些属性判断测试步骤结果是否正确。

3.4 基于GUI对象识别的测试工具

目前,大部分自动化功能测试工具,尤其是商业的测试工具,如QTP都是基于GUI对象识别技术来设计的,基于GUI层面的测试需要与各种节目元素打交道,而且不同的编程语言和开发工具在界面的表现、事件的响应上都略有不同。

QTP同样是通过查找应用程序界面中的各个控件的属性来判断是否与测试对象匹配,还可以根据控件的类型,把其拥有的可操作方法列举出来,针对不同平台和语言编写的控件,依据该控件与其他控件能区分的属性来判断其身份,例如控件的类名、控件的文本等。

QTP自动化测试工具是一种自动测试工具。使用QTP的目的是想用它来执行重复的手动测试,主要是用于回归测试和测试同一软件的新版本。因此在测试前要考虑好如何对应用程序进行测试,例如要测试哪些功能、操作步骤、输入数据和期望的输出数据等。Quick Test针对的是GUI应用程序,包括传统的Windows应用程序,以及现在越来越流行的Web应用。它可以覆盖绝大多数的软件开发技术,简单高效,并具备测试用例可重用的特点。其中包括:创建测试、插入检查点、检验数据、增强测试、运行测试、分析结果和维护测试等方面。

4 自动化测试基本流程

基本流程图如下。

4.1 制订测试计划

在展开自动化测试之前,我们需要做个测试计划,明确测试对象、测试目的、测试的项目内容、测试的方法、测试的进度要求,并确保测试所需的人力、硬件、数据等资源都准备充分。

4.2 分析测试需求

用例设计者根据测试计划和需求说明书,分析测试需求,设计测试需求树,以便用例设计时能够覆盖所有的需求点。一般来讲,基于Web功能测试需要覆盖以下几个方面:

(1)页面链接测试,确保各个链接正常;

(2)页面控件测试,确保各个控件可靠;

(3)页面功能测试,确保各项操作正常;

(4)数据处理测试,确保数据显示准确、处理精确可靠;

(5)模块业务逻辑测试,确保各个业务流程畅通。

4.3 设计测试用例

通过分析测试需求,设计出能够覆盖所有需求点的测试用例,形成专门的测试用例文档。由于不是所有的测试用例都能用自动化来执行,所以需要将能够执行自动化测试的用例汇总成自动化测试用例。必要时,要将登录系统的用户、密码、产品、客户等参数信息独立出来形成测试数据,便于脚本开发。

4.4 搭建测试环境

自动化测试人员在用例设计工作开展的同时即可着手搭建测试环境。因为自动化测试的脚本编写需要录制页面控件,添加对象。测试环境的搭建,包括被测系统的部署、测试硬件的调用、测试工具的安装盒设置、网络环境的布置等。

4.5 编写测试脚本

根据自动化测试用例和问题的难易程度,采取适当的脚本开发方法编写测试脚本。一般先通过录制的方式获取测试所需要的页面控件,然后再用结构化语句控制脚本的执行,插入检查点和异常判定反馈语句,将公共普遍的功能独立成共享脚本,必要时对数据进行参数化。当然还可以用其他高级功能编辑脚本。脚本编写好了之后,需要反复执行,不断调试,直到运行正常为止。脚本的编写和命名要符合管理规范,以便统一管理和维护。

4.6 分析测试结果、记录测试问题

应该及时分析自动化测试结果,建议测试人员每天抽出一定时间,对自动化测试结果进行分析,以便尽早地发现缺陷。如果采用开源自动化测试工具,建议对其进行二次开发,以便与测试部门选定的缺陷管理工具紧密结合。理想情况下,自动化测试案例运行失败后,自动化测试平台就会自动上报一个缺陷。测试人员只需每天抽出一点时间,确认这些自动上报的缺陷,是否是真实的系统缺陷。如果是系统缺陷就提交开发人员修复,如果不是系统缺陷,就检查自动化测试脚本或者测试环境。

4.7 跟踪测试BUG

测试记录的BUG要记录到缺陷管理工具中去,以便定期跟踪处理。开发人员修复后,需要对此问题执行回归测试,就是重复执行一次该问题对应的脚本,执行通过则关闭,否则继续修改。如果问题的修改方案与客户达成一致,但与原来的需求有所偏离,那么在回归测试前,还需要对脚本进行必要的修改和调试。

5 自动化测试架构

真正的自动化测试框架可以不是一个程序,它仅仅是一种思想和方法的集合,说白了,就是一个架构,它定义了几层架构,定义了各层互相通信的方式。通过这个架构我们才能在上面进行拓展我们的测试对象(核心体)、测试库(链接库)、测试用例集(各个windows进程)、测试用例(线程),而其之间通过参数的传递进行通信(即相当于系统中的消息传递)。

5.1 几种自动化测试框架思想

(1)模块化思想

就是将一个测试用例中的几个不同的测试点拆分并且将其单个点的测试步骤进行了封装,形成了一个模块。

例如:一个测试用例要对一个登录程序进行测试,其中包括:用户名输入、密码输入以及确定登录。

那么就可以将用户名输入、密码输入、确定登录、取消登录四个操作分别封装在四个不同的模块中。测试时,只需调用其模块即可。这样的话,当一个模块有变化,你只需单独维护那个模块即可,也可以根据模块的不同组合成不同的测试用例。

(2)库思想

就是模块化思想的升华,其为应用程序的测试创造了库文件(可以是APIs、DLLs等),这些库文件为一系列函数的集合。其与模块化思想不同的是,其拓展了接口思想,即可以通过接口去传递参数,而不是一个封死的模块,可以说是一个多了一个“门”的交互型模块。

例如:登录场景,只是将用户名输入、密码输入、确定登录、取消登录封装成一个库,这个库含有一个函数Login,这个函数Login接收两个参数“用户名、密码”,对输入不同的用户名和密码可以进行不同的测试用例。也可以用另外一个函数Cancle。

(3)数据驱动思想

就是变量不变的数据驱动结果,不同的数据导致了不同的结果的产生。而对于数据的导入,可以通过很多方式,例如:Excle表、XML(用在Web中)、数据库(DB)、CSV文件、TXT等都可以。

(4)关键字驱动思想

关键字驱动就是一种面向对象的思想,例如:QTP、RFT中,对象可以为一个数据或者一个关键字,对对象的抓取,可以将其测试对象封装为一个关键字,这样可以对其关键对象进行各种操作了,不同的对象可以驱动不同的测试流向与结果。

5.2 自动化测试发展

(1)第一代自动化测试,即自动化测试思想刚开始诞生时,依靠的是传统的“录制—回放”技术,这种技术与现在的工具的“录制—回放”思想不一样,其实就是一个“模拟”的过程,即模拟对PC的操作而形成的,其基于你对键盘的输入与对鼠标的操作,原理与按键精灵等类似,这种机制对环境的依赖性太强,对变化性太过敏感,因此不可能发展成一种规模。

(2)第二代自动化测试,即脚本化的自动化测试,利用脚本进行结构化的自动化测试,此可以应用于CLI与API的自动化测试,在此就开始集成了模块化与库思想。

(3)第三代自动化测试,开始产生了各种自动化测试思想,包括数据驱动与关键字驱动思想,其伴随着对象化思想的产生,也造就了现在一系列的自动化测试软件,其中都集成了这些思想,从这时候开始,自动化就开始实现了一定的规模,开始运用在各个行业,并且发展趋势越来越快。

5.3 构建自动化测试框架的策略

做一个自动化测试框架主要是从分层上去考虑,而不是简简单单地应用一种思想,它是各种思想的集合体。而其中,可以贯穿着自动化测试的各种思想,例如:对象层中有关键字的思想、可以将对象库标示在Excel表中进行管理,或者应用动态搜索的方式传递对象识别参数。tasks层中可以封装各种方法,形成一个大型的方法库,而每个方法中可以应用数据驱动的思想。

6 结论

自动化测试的优点是能够很快、很广泛地查找缺陷,同时可以做很多重复性的工作,自动化功能测试工具无须大量的软件测试人员手动地再次执行测试用例,极大地提高了工作效率。可以执行一些手工测试困难或不可能进行的测试。比如,对于大量用户的测试,不可能同时让足够多的测试人员同时进行测试,但是却可以通过自动化测试模拟同时有许多用户,从而达到测试的目的。更好地利用资源。将烦琐的任务自动化,可以提高准确性和测试人员的积极性,将测试技术人员解脱出来投入更多精力设计更好的测试用例。

参考文献

[1]张月亲.建立自动化测试系统的必要性[J].国外电子测量技术,2000(6).

[2]常征.功能测试中自动化测试框架的分析与应用[D].北京:北京林业大学,2007.

无人值守自动化测试研究 篇8

为了满足建设目标我们选用了自动化测试工具与测试管理工具相结合的方式完成。利用自动化测试工具录制脚本及执行自动化测试流程, 再利用测试管理工具对测试脚本、测试流程、测试内容、测试过程及缺陷进行统一管理, 在经过一些配置和实施, 最终实现无人值守自动化运行。

自动化测试工具针对功能测试和回归测试自动化提供了一套有效的解决方案, 适用于所有主流的软件应用程序和环境。自动化测试解决方案采用关键字驱动测试的概念, 大大简化了测试的创建和维护。自动化测试工具使用关键字驱动测试方法, 此方法的独特之处在于, 通过与关键字视图双向同步的集成的脚本和调试环境, 使我们能够以更快的速度、更低的成本和更低的风险来完成测试工作。

测试管理工具可以提供一种稳定一致的、可重复的流程来收集需求、规划和安排测试进度、分析测试结果、管理缺陷和问题, 从而能更迅捷、更有效地部署高质量的应用。这套管理工具是一款基于Web打造的工具, 可以提供需求管理, 测试案例和计划, 测试执行以及缺陷管理等功能。且无论在什么地方都可以帮助我们跨地域、跨机构地获取有益的信息。

使用测试管理工具可以有效地把测试工作管理起来, 让自动化测试真正运行起来, 也可以使我们的测试有据可依, 在测试管理工具中进行有效的配置甚至可以完成无人值守。

首先我们需要完善自己编写的自动化脚本。由于在自动化测试工具完成测试脚本编写、执行的过程中, 所测试的软件可能会发生非预期的错误, 例如UI报错、没有抓取对象的窗口提示等, 这些错误可能导致程序无法正常执行下去, 但是由于这些问题是未知且随地发生的, 而不是测试设计的检查点异常, 所以在自动化测试的角度无法确定测试失败的原因和步骤, 更无法实施Bug查找。为了解决这些问题, 我们需要自身的程序有着强大功能, 可以使用异常处理及场景恢复机制来保证测试的顺利进行。场景恢复存在的目的在于避免测试过程中因为异常而引起的中断。并不是所有测试脚本都需要场景恢复, 设计完美的测试脚本不仅可以让自动化测试过程更顺畅, 同时还能够捕获可能产生的程序缺陷。场景恢复函数是由几个函数组合而成的, 包含了日志函数、系统自动抓图函数、场景恢复调用的业务组件函数等。

异常处理流程如下:

启动程序执行测试集—->调出测试流程执行测试—->是否有异常:1.有, 捕获异常&调用场景恢复;2.没有, 执行下一个步骤。

其次使用测试管理工具管理自动化测试脚本并根据测试需要创建测试集, 使测试可以批量的进行。将已经编写好的测试脚本上传至自动化管理工具服务器并与相应的测试用例绑定。

最后, 可以生成一个测试集, 测试集里可以导入之前设计的测试用例, 如果导入的用例和脚本有过绑定, 则脚本也随之自动加载到测试集中, 只需要点击“执行”按钮, 自动化管理工具就会自动执行脚本, 开始测试了。等测试集中的测试用例全部运行完毕后, 自动化管理工具就会显示这些测试用例的运行结果并生成图表, 然后自动将缺陷提交到服务器中, 方便测试工程师了解自动化测试运行以及完成的情况乃至发现的缺陷情况。

软件测试自动化应用分析 篇9

软件测试是软件生命周期的一个重要阶段,测试质量的好坏,直接决定着软件产品能否稳定运行。软件测试中的自动化测试技术是目前有待进一步发展的技术,因为软件测试的工作量非常大(大约占总体开发时间的40%到50%),而其中又有大部分工作适合自动化,因此,测试的改进会对整个软件项目开发工作的成本、质量和周期带来非常明显的效果。

1 传统软件测试存在的问题

在软件开发过程中,首先要求我们通过测试验证所开发的软件在功能上满足需求分析中的描述,性能上满足客户要求的承载负荷和相应的响应时间、运算量要求;另一方面,工作人员还要在预算范围内尽早发布软件以便减少开支。

传统的软件测试流程一般是先在软件开发过程中进行少量的单元测试,然后在整个软件开发结束阶段,集中进行大量的测试,包括功能和性能的集成测试和系统测试[1]。由于软件项目越来越复杂,这种软件测试的流程给项目开发者带来以下问题:

1)项目进程较难把握

项目管理难度加大,许多的软件错误往往到了软件测试后期才被发现,此时解决问题耗费的代价很难估算,从而使项目进程无法控制,另外在软件设计过程中,相关人员无法准确了解软件的质量状况,无形中增大了项目管理和开发的难度。

2)项目风险较难控制

项目风险在开发的后期才能得以降低。通常在测试人员进行了系统测试以后,方能确定整个开发过程能否满足用户在系统功能、性能和可靠性方面的需求。

3)项目开发经费超出预期

在整个项目开发周期中,错误发现的越晚,修复成本越高,此时对问题解决地不及时将导致整个项目成本的快速增加。

2 软件自动化测试的分析

2.1 软件自动化测试的定义

目前,对于软件自动化测试的常规定义为“使用一种自动化测试工具来验证各种软件测试的需求,它包括测试活动的管理与实施。”

通常,我们所进行的自动化测试指的是自动化测试一个已经使用了正式的测验流程的手工过程[2]。

2.2 引入软件测试自动化的原因

通常,软件测试中有许多是重复性的、非智力性的和非创造性的操作,通过计算机就可以代替人工去完成这样的任务,使程序员从纷繁复杂的同一化工作中解脱出来,转而进行更深层次的项目测试工作。

软件自动化测试是基于手工测试而存在的,主要通过相应的软件测试工具、脚本等来实现,具有较好的可操作性、可重复性和高效率等特点。

自动化测试的测试效率高,成本低廉,可将重复性强的测试由手工转为计算机自动实现;非常适合快速的回归测试,改变人工测试很难对新的迭代版本作出快速评估的局面;避免人工测试容易犯的错误,并且对非常耗费时间的边界值测试,可以快速准确的进行对多用户的并发操作等人工测试很难实现的操作,自动测试很容易就可以完成。

因此,测试自动化的实施是软件测试行业一个发展方向,如果掌握了这个领域的先进技术,对于一个软件企业的核心竞争力和未来的发展,都有巨大的推动作用。

2.3 常见的软件自动化测试工具

2.4 测试脚本的设计

脚本是一组由测试工具执行的代码集合,可以通过录制测试的操作产生,然后再做修改,这样可以减少脚本编程的工作量。当然,也可以直接用脚本语言编写脚本。脚本技术可以分为线性脚本、结构化脚本、共享脚本、数据驱动脚本和关键字驱动脚本几类。编辑脚本的原则就是尽量覆盖更多的测试项,兼容性更强一些,使得测试新项目时能很容易继承和修改原有的脚本,减轻后续的工作量。

3 软件自动化测试流程的改进

3.1 确定要测试的产品进行自动化测试的可行性

自动化测试能提高测试效率,但对于周期短、时间紧迫的项目不宜采用自动化测试。推行自动化测试的前期工作相当庞大,将企业级自动化测试框架应用到一个项目中也要评估其合适性,因此决不能盲目地应用到一个测试项目中,尤其不适合周期短的项目,因为非常可能需要大量的测试框架的准备和实施而会被拖跨。

比如进行一个单元测试自动化,如果开发了上百行的测试代码去测试一个代码行仅为10行的函数,我们先不考虑自动化测试开发之后的维护成本,但是至少可以有一个直观的认识:从手工测试向自动化测试的转变是要付出的成本的,而且这个投入要远比做一次手工测试的代价要高,所以必须首先要确定对一个软件项目进行自动化测试是否合适。

3.2 对测试的软件项目进行风险评估

资金风险,虽然有些项目具备实施自动化测试的条件,但还是要引入自动化测试后组织结构调整等方面的成本估算是很必要的。

切入方式的风险,一定要将自动化测试与手工测试结合起来使用,设计合理的配比使测试能够顺利进行。开始可以设置80%的测试采用手工测试,当这些目标都实现了,再将自动化测试率提高。

时间估算,在评估完前面几项指标后,需要估算实施测试自动化的时间周期,以防止浪费不必要的时间,减少在人员、资金、资源投入上的无端消耗。虽然到测试自动化步入正轨以后,会起到事半功倍的效果,但前期的投入巨大,要全面考虑各种因素,明确实施计划并按计划严格执行,才能最大限度降低风险。

工作流程变更风险,测试团队乃至整个开发组织实施测试自动化,或多或少会因为适应测试工具的工作流程,带来团队的测试流程、开发流程的相应变更,而且,如果变更不合理,会引起团队成员的诸多抱怨情绪,所以应该尽量减少这种变更,并克服变更中可能存在的困难。

3.3 制定周密的测试计划

测试计划包括测试环境的建立、确定测试策略、测试设计流程控制和容错处理等。

根据开发的软件项目特点,制定完善的计划,设计好测试的各个步骤,由于自动化测试对软件的设计质量要求比较高,另外对突发事件和不能由软件解决的问题就无能为力,所以事先应确定出现测试异常情况时解决问题的方案,能较快地将问题解决,减少不必要的开销。

3.4 结合手工测试和自动化测试两种方案

测试自动化可以带来非常明显的收益,但是不能完全依赖于自动测试,它只是测试工作的一部分,是对人工测试的一种补充。自动化测试绝不能代替手工测试,它们各有各自的特点,其测试对象和测试范围都不一样。根据报道,自动化测试只能发现15%的缺陷,而手工测试可以发现85%的缺陷。在进行自动化测试前,首先要建立一个对软件测试自动化的认识观。单元测试、集成测试、系统负载测试、性能测试、稳定性测试、可靠性测试等比较适合采用自动化测试。对于那种不稳定软件的测试、开发周期很短的软件、一次性的软件等不适合自动化测试。我们可以根据实际情况进行选择。多数情况下,手工测试和自动化测试应该相结合,以最有效的方法来完成测试任务。

自动化测试工具在进行功能测试时,其准确的含义是回归测试工具,这时工具不能发现更多的新问题,但可以保证对已经测试过部分的准确性和客观性。

3.5 总结软件自动化测试的过程

将整个测试过程进行记录,总结过程中的经验和教训,生成测试报告,找出解决同类问题的思路和方法,以便以后测试类似的软件项目时能重复利用前面取得的成果,如果有条件的话,在测试的基础上设计相关的测试模板,如果以后有类似架构的软件项目的话,可以沿用前面的这种模式进行测试,从而大大地提高测试的效率。

4 结束语

总之,软件项目的自动化测试在国内的发展还不是很成熟,没有真正地形成一整套合理有效的规范。在实际应用中,我们要结合传统的手工测试和自动化测试两种方法的特点,发挥它们的优势,让自动化测试策略及工具的实现成为测试人员手中的一件利器,把他们从枯燥的重复性工作中解脱出来,将更多精力和时间专注于需要智能判断的复杂工作和其他新的测试用例。另外,我们要避免将自动化测试和测试人员等同起来,不要对自动化测试要求过高。我们要对自动化测试树立一个正确的观感,清醒地认识到自动化测试是人工测试的有力补充,而无法取代测试人员的地位。任何单一的技术或操作方式上的进步,都不能独立地保证在短时间内大规模地提高软件的开发效率、稳定性和可维护性。自动化测试也是一个积累经验、循序渐进的过程,不能指望软件测试人员在短时间内能将所有测试实现自动化。成功的自动化测试需要制定相应的自动化测试计划,合理的自动化测试策略是自动化测试实施是否成功的第一步。只有充分考虑到自身实施自动化测试的风险、资源和目标后,才能制定出适合自己的自动化测试策略,并最终提高测试效率,降低测试成本。对每个有测试部门或从事测试业务的企业,都应该多借鉴国内外先进的测试经验,参考业界流行的行业标准,找到适合自己团队的测试方法和模式,创造更大的社会价值。

参考文献

[1]Elfriede Dustin Jeff Rashka John Paul.于秀山,胡兢玉,译.软件自动化测试:引入、管理与实施[M].电子工业出版社.

[2]干晓鸣.软件自动化测试的合理应用.计算机应用与软件.

[3]软件测试自动化技术.IBM Rational技术白皮书.

自动化环境实验测试系统 篇10

电子元器件或电子设备在研制及生产过程中, 为了证明其在不同的温度和压力条件下仍能具有同样的性能和达到相应的技术指标时, 都需要进行环境试验和性能测试。目前这些测试工作的进行基本靠手动操作, 然后再录入到计算机中进行分析处理。在测试的整个过程中人为操作繁杂, 耗时费力, 出错机率大, 且每次实验中可以测试的元器件设备数量较少;温度实验过程较长, 一般需不间断的持续几天或数周的时间。

莱诺斯科技 (北京) 有限公司研制出了一套高效的电子元器件和设备在高低温和热真空环境实验中的测试系统, 该测试系统可以根据用户的事先设定, 自动的调节高低温实验箱的温度, 并能够根据实验细则中的要求, 自动的对温箱里的电子元器件或设备进行性能和指标的测试, 提高了测试效率和测试质量, 真正实现了对元器件和设备的自动化测试。

2 自动化环境实验测试系统

自动化环境实验测试系统主要用于电子元器件或电子设备等产品在环境试验、性能指标测试、动态仿真、性能分析等多种试验任务中的自动化测试, 该系统包括硬件系统和软件系统两大部分。

(1) 硬件系统主要由自动化控制设备、温度控制设备、压力控制设备及配套的气路、电路等组成。

(2) 软件系统主要是一套自动化环境实验测试软件。该软件可以按照试验测试流程/步骤的要求, 自动控制环境实验测试系统的相关硬件设备, 完成对温度/压力的自动调节、测试仪表对被测件的自动测量、对环境实验状态和测试过程的自动监视、对测试数据的自动存储及对测试数据的自动分析比对等功能。

自动化环境实验测试系统实现的原理框图如图2所示。

(1) 自动化控制设备用于对压力控制设备、温度控制设备进行程序控制, 同时实现数据采集和参数拟合等功能。

(2) 温度控制设备由温度试验箱、信号处理卡、供电控制卡、电磁阀驱动控制卡等组成, 用于产生高精度的温度模拟环境, 同时管理试验产品的供电逻辑。

(3) 压力控制设备主要用于产生高精度的大气压力模拟环境。

3 软件系统主要的功能模块

(1) 实验环境状态自动调节设置模块;可以根据事先的约定, 自动调节设置实验中所需的环境状态, 比如温度高低, 压力大小等。

(2) 测试流程设计模块;用图形化的方式, 将客户传统的纸质文本测试细则填入到图形化的测试设计流程图中, 使客户能够直观的了解测试所需经历的步骤和过程。

(3) 测试自动执行模块;按照流程设计器里描述的设备调用、条件判读、循环逻辑等进行测试的自动执行。

(4) 测试组态监视模块;以图形界面的方式完成对测试过程各个环节的监视。

(5) 测试结果处理模块;提供测试数据的二次分析处理, 可进行趋势、极值等数据的分析。

(6) 测试结果报表模块;可以自动生成word、Excel为模板的测试报告。

(7) 测试数据分析评估模块;提供测试任务数据的分析模型工具, 用户可依据这些模型工具进行测试业务评估。

(8) 测试知识管理模块;包括测试方法库、测试拓扑结构库、组态图元库、判读报警算法库、被测件建模库、数据分析模型库等。

(9) 测试工作信息管理模块;提供测试人员调度、实验场地调度、测试设备调度、测试任务调度等功能。

摘要：高低温和热真空环境实验是为了证明电子元器件和设备在各种环境下仍能保持同样的性能和技术指标, 但在做这样的环境实验时, 需要很多人工的操作, 耗时费力。如何解决温度和压力按照测试的规范自动调节, 同时又能够对被测的元器件和设备进行自动化测试是很多用户普遍遇到的问题。本文提供了一种高效的解决上述问题的方法, 供大家实用时参考。