自动化测试的发展前景

自动化测试的发展前景（推荐8篇）

自动化测试的发展前景 篇1

1、软件测试自动化简介

谈到自动化测试，一般就会提到测试工具。许多人觉得使用测试工具就是实现了测试自动化，这种理解是不对的，至少是片面的。的确，测试工具的使用是自动化测试的一部分工作，但“用测试工具进行测试”不等于“自动化测试”。

自动化为测试而存在的，所以自动化测试的真正含义可以理解为“一切可以由测试是相对手计算机系统自动完成的测试任务都已经由计算机系统或软件工具、程序来承担并自动执行”。它包含了下列3层含义：

“一切”，不仅仅指测试执行的工作——对被测试的对象进行验证，还包括测试的其它工作，如缺陷管理、测试管理、环境安装、设置和维护等。

“可以”，意味着某些工作无法由系统自动完成，如脚本的开发、测试用例的设计，需要创造性，其工作需要手工处理。

即使由系统进行自动化测试，还少不了人的干预，包括事先安排自动化测试任务、测试结果分析、调试测试脚本等。

严格意义上，“自动化测试(Automated Testing)”不等于“测试自动化(Test Automation)”。自动化测试，模拟手工测试步骤，通过执行程序语言编制的测试脚本自动地测试软件，自动地实施软件的单元测试、功能测试、负载测试或性能测试等。自动化测试集中体现在实际测试执行(test execution)的过程，也就是由手工逐个地运行测试用例的操作过程被测试工具自动执行的过程所代替。自动化测试，强调借助工具(不仅仅是工具，有时包括策略和工件)来完成测试的执行，也就是用工具来帮助或辅助测试，这个执行过程可能是全自动的，也可能是半自动的。

测试自动化的要求高得多，侧重说明将测试用自动化设计和实现的`过程，即所有的测试工作都能有计算机系统自动完成，包括：测试环境的搭建和设置，如上载安装包到服务器;脚本自动生成，如根据UML状态图、时序图等生成可运行的测试脚本;测试数据的自动产生，例如自动产生数据负载测试所需要的大量数据;测试操作步骤的自动执行，包括测试执行过程的控制;测试结果分析，实际输出和预期输出的自动对比分析;测试流程的自动处理，即测试工作流的自动实现，包括测试计划复审和批准、测试任务安排和执行、缺陷生命周期等流程的自动化处理。测试报告自动生成功能等。

这样，测试自动化意味着测试全过程的自动化和测试管理工作的完全自动化，是测试工程师所追求的一种理想境界，但是很难实现的。

自动化测试方案选择需要考虑的方面：

自动化测试和手工测试都不影响测试的有效性和仿效性，自动化测试只是对测试的经济性和修改性有影响，自动化测试通常要比手动测试经济得多，自动化测试的方法越好，长期使用获得的收益就越大。

2、采用什么样的自动化测试方案，需要考虑以下几个方面的因素

1)项目的影响：自动化测试能否帮助你的项目进度、覆盖率、风险，或者让开发更敏捷?

2)复杂度：自动化是否容易实现，包括数据和其他环境的影响。

3)时间：自动化测试的实现需要多少时间?

4)早期需求和代码的稳定性：需求或早期的代码是否能证明是在范围内变化的?

5)维护工作量：代码是否能长期保持相对稳定?功能特性是否会进化?

6)覆盖率：自动化测试能否覆盖程序的关键特性和功能?

7)资源：测试组是否拥有足够的人力资源、硬件资源和数据资源来运行自动化测试。

8)自动化测试的执行：负责执行自动化测试的小组是否拥有足够的技能和时间去运行自动化测试。

3、适合自动化测试的场景主要为

1)测试任务明确，不会频繁变动。2)每日构建后的测试验证。3)回归测试、压力测试、性能测试。4)软件系统界面稳定，改动较少。5)需要在多种平台上运行相同的测试案例、组合遍历型的测试、大量重复的测试任务。6)软件维护周期长。7)待测软件系统开发比较规范，能够保证系统的可测性。8)项目进度压力不大。9)具备大容量的自动化测试平台。10)测试人员具备较强的编程能力。

4、软件测试自动化的实施步骤

我们对自动化测试充满了希望，然而，自动化测试却经常带给我们沮丧和失望。虽然，自动化测试可以把我们从困难的环境中解放出来，在实施自动化测试解决问题的同时，又带来同样多的问题。本文介绍自动化测试的6个步骤：改进自动化测试过程，定义需求，验证概念，支持产品的可测试性，具有可延续性的设计(design for sustainability)，有计划的部署等。

首先了解下几个使自动化测试项目陷入困境的原因：

1)自动化测试时间不充足。

2)缺乏经验：尝试测试自己的程序的程序员经常采用自动化测试。由于缺乏经验，很难保证自动化测试的顺利开展。

3)更新换代频繁(High turnover)：当自动化测试更新换代频繁的时候，你就丧失了刚刚学习到的自动化测试经验。

4)不愿思考软件测试：很多人发现实现产品的自动化测试比测试本身更有趣。自动化工程师不参与到软件测试的具体活动中。

5)关注于技术：如何实现软件的自动化测试是个技术问题。不过，过多的关注如何实现自动化测试，导致忽略了自动化测试方案是否符合测试需要。

在自动化测试开发过程中遵守已经建立的软件开发规则，按照在软件开发项目中采用的标准步骤，实现测试自动化：

步骤一：改进软件测试过程。

采用列有产品特性的列表，然后对照列表检查。回归测试检查列表可以告诉应该测试哪些方面。在开始测试之前，需要完善回归测试检查表，并且确保已经采用了确定的的测试方法，指明测试中需要什么样的数据，并给出设计数据的完整方法。确认可以提供上面提到的文档后，需要明确测试设计的细节描述，还应该描述测试的预期结果。在开始更为完全意义上的测试自动化之前，必须已经完成了测试设计文档。测试设计是测试自动化最主要的测试需求说明。

步骤二：定义需求。

应该有一份自动化测试需求，用来描述需要测试什么。测试需求应该在测试设计阶段详细描述出来，自动化测试需求描述了自动化测试的目标。

步骤三：验证概念。

尽可能快地验证采用的测试工具和测试方法的可行性，站在产品的角度验证所测试的产品采用自动化测试的可行性。需要尽快地找出可行性问题的答案，需要确定你的测试工具和测试方法对于被测试的产品和测试人员是否合适。

验证概念的试验主要有：

回归测试：回归测试是最宜采用自动化测试的环节。

配置测试：你的软件支持多少种不同的平台?你打算在所有支持的平台上测试执行所有的测试用例吗?那么采用自动化测试是有帮助的。

测试环境建立：对于大量不同的测试用例，可能需要相同的测试环境搭建过程。在开展自动化测试执行之前，先把测试环境搭建实现自动化。

非GUI测试：实现命令行和API的测试自动化比GUI自动化测试容易的多。

步骤四：支持产品的可测试性。

软件产品一般会用到下面三种不同类别的接口：命令行接口(command line interfaces，缩写CLIs)、应用程序接口(API)、图形用户接口(GUI)。

无论你需要支持图形界面接口、命令行接口还是API接口，如果你尽可能早的在产品设计阶段提出产品的可测试性设计需求，你很可能成功。

步骤五：具有可延续性的设计。

自动化测试设计中考虑自动化在未来的可扩充性是很关键的，不过，自动化测试的完整性也是很重要的。把注意力放在通过设计保证测试的可延续性上，选择一个合适的测试体系架构，将进一步迈向成功的自动化测试。主要从以下几方面考虑，测试的可检视性、测试的可维护性、测试的完整性、测试的独立性、测试的可重复性。

步骤六：有计划的部署。

需要提供自动化测试程序的安装文档和使用文档，保证自动化测试程序容易安装和配置。

5、结束语

自动化测试的发展前景 篇2

软件测试是软件能否通向市场的最后也是最重要的一关,手工测试作为一种传统的测试方式,其特点就是简单。但存在很多问题,如大量重复性的工作导致成本较高,人员积极性下降,人员操作失误引起的输入错误等。

针对手工测试的缺点,自动化测试应运而生。但并不是所有的项目都适合引入自动化测试,也不是引入了自动化测试就会提高测试效率,降低测试成本。实际上自动化测试更需要开发和搭建测试框架,设计测试用例,这就意味着成本的投入。

1 自动化测试的设计原则

为了更好的体现自动化测试的优势,当进行自动化测试设计时,需要考虑到当前项目并计划到未来的项目。一个优秀的自动化测试设计,必须具备如下原则:(1)易于维护性-减少更新修改的工作量;(2)可靠性-测试结果精确,能够真实反映当前项目问题;(3)复用性-测试脚本可以复用,包括在未来的其他项目里。

自动化测试中,自动化测试用例是一个重点中的重点,如何设计自动化测试用例是决定自动化测试成败的关键。

2 自动化测试用例的设计

2.1 自动化测试用例设计特点

手工测试用例的执行实施是测试人员,在用例设计中所描述的行为主要使得测试人员能够按照测试设计者的思维去执行测试。自动化测试用例编写者是测试设计师而执行实施是计算机,自动化测试用例设计时必须满足如下两个原则:(1)测试用例能够体现测试设计师的设计思维,并且尽量提供便捷的方式编写用例,提高测试用例的编写效率;(2)测试用例能够被计算机所解析。自动化测试用例如果要被计算机所能解析,那么自动化测试用例必须有一套可以计算机识别解析的规则,并且需要涵盖测试用例需要填写的相关元素,尽量降低编写的荣誉和提升编写的效率。

2.2 手工测试用例要素

自动化测试所有活动都来源于手工测试活动,那么用例规则的提炼主要数据源将来源于现实工作中的测试用例。如表1所示手工测试用例。

传统手工测试用例一般涵盖元素:(1)测试用例名称:区分不同的测试用例。(2)测试前提条件:这个目的主要是标识执行这个测试用例的之前,必须要完成的事情,这个事情可以是一个测试用例,也可以是其他的事务,比如说环境重置、数据清理等等。可选项。(3)测试步骤ID:这个目的是标识测试操作的先后顺序。在一个用例中一般都是串行工作的,必需项。(4)测试的操作路径:这里主要描述系统的操作过程,使得被测系统进行到可以检测的位置或者检测状态,必需项。(5)测试数据:这里主要指的过程数据,即使得测试用例能够通过测试数据的驱动,使得被测系统进入到可检测的状态,可选项。(6)期望结果:系统进行到检测状态后,系统应展现的出来的行为而应该出现正确的结果,如果系统所展现的结果与期待结果不符,标识为系统的缺陷。必需项。

2.3 自动化测试用例要素分析

自动化测试用例设计之后是需要交给计算机来执行的,在设计自动化测试用例时,自动化测试用例编写时除了必须包含手工测试用例的这些元素,对必填的元素在编写结束后必须校验是否真的填写了相关数据,以保证测试用例在自动执行时的有效性。在编写的过程中,计算机很难解析现实生活中的自然语言,所以我们必须进一步分析设计规则,来实现这些元素的编写策略。

2.3.1 测试用例名称

在自动化测试用例中,必须校验测试用例名称是某一个用例的唯一标识,类似上面案例的“用户登陆”等,以保证计算机能够唯一的识别。一般在自动化测试底层再加上ID来控制用例的唯一性,但是在界面上显示时仍然需要进行唯一性的控制,避免测试用例编写的混乱。

2.3.2 测试的前置条件

在手工测试用例编写时,很多时候采取一些描述性的条件来表示相关的工作条件,例如:上面案例中描述的“必须注册了对应的用户名和密码”,但是计算机是处理这些自然语言。所以如何满足自动化测试解析的需要,又能满足用例编写的需要。这是测试前提条件的设计时必须关注的问题。从测试前提条件的分析,测试前提条件可以分成二种类型:(1)测试用例。即一个测试用例的前提条件是另外一个用例先被执行。例如上面的用户登陆用例,它的前提条件可能是一个“用户注册”的案例,当该用户名注册结束后,再执行用户登陆的案例。(2)事务操作。即可以执行某一个批处理操作,环境重置操作等等,比如说有时在执行一轮操作之后,所有的测试数据必须重置,因为这些数据可能是不可逆的行为。

用例之间的前置关联:不同的前置条件,对于设计者来说,将需要采取不同的策略来实现。测试用例之间的前置策略,因为测试用例已经存在于测试用例库,所以在这种测试前置条件中,只要将该用例与相关用例设置一个关联关系策略,使得计算机能够知道在执行该用例之前,必须先执行某一个用例。设计模式如图1所示。

为了满足该前置条件的需求,可以采取一个关联链表的模型来保存用例之间的关联关系,使得计算机通过这个关联模型来来控制用例之间驱动相关的运行逻辑。

用例之间的前置关系将交付给终端用户来完成设置,所以在用户设置的用例之间的前置关系时,必须控制用例之间的死循环模式,例如:

用例A--->用例B

用例B--->用例C

用例C--->用例A

那么最终将推出一个闭环的模式,从而导致计算机出现一个死循环过程中。

事务的前置:事务前置与用例前置的策略差异在于:(1)事务的表现行为不再是像用例这样的单一化的模式。事务可能是一个Shell、一个存储过程或者是一个外部程序。(2)事务作为前置条件,往往都针对某一个业务或者场景,或者多个场景。很少说仅仅针对某一个用例而言。

因为事务前置表现行为的多样化,那么将增加了存储或者执行这个前置任务的难度,例如:前置条件是需要执行一个或者多个存储过程,那么必须保存如下信息:(1)数据库类型;(2)连接模式以及连接信息(如:服务器名称、用户名、密码)。

不同的模式在实现的时候又需要考虑到不同的环境的条件,例如:(1)数据库它的数据库连接串格式差异、数据库连接所涉及到的第三方动态库之间的差异、数据库的执行SQL模式的差异等等;(2)执行Shell将需要分析服务器类型(linux、HP Unix、Sun)、以及他们的执行方式、获取执行成功与否的方式。

不同的被测系统所可能的产生的前置条件千差万别,该前置条件是选择由外部程序来实现,还是选择由自动化测试的驱动平台来实现,不同的选择所需要自动化驱动模式也可能完全的不同。

由于现实的工作中很难去预测企业的前置行为,完全由测试驱动平台来完成不太可能,一般建议把常用的前置条件归纳成一类接口,真正的实现有外部程序来控制,而自动化测试平台只是通过接口来获取执行的结果。如图2所示。

外部程序的输入输出约定:(1)是一个可执行的EXE文件程序,或者是批处理的程序;(2)执行结束后在文字模式下输出:“Result=成功”或者“Result=失败”的字样。自动化测试平台通过提供的接口调用外面可执行程序,根据返回的执行结果确定后续的自动执行策略。

2.3.3 测试步骤的操作过程

在手工测试用例中将操作过程分为了五个关键字段:步骤ID、路径、操作过程、输入数据、期待结果。这个五个字段主要目的是描述该用例如何进行操作,通过操作来判别该操作的结果是否能够满足期待的输出结果。

在自动化测试过程中归纳起来实际分为三个关键字段:步骤、控件、数据。在测试过程中,实际是测试人员在对控件串行的实施某个行为,例如:在IE浏览器中输入网址,实际是针对IE的网址的下拉列表框控件进行输入操作;输入用户名、密码,然后点击登陆按钮,那么测试人员是针对用户名框、密码框、登陆按钮进行操作。

而步骤ID是标识用户执行控件的操作顺序。而数据主要是针对这些控件的输入项,那么可以把用户每个操作归纳为如下的一个行为

ID控件操作(测试数据)--(可选)

在自动化测试来说,标识控件的可以通过对象、描述该对象的属性来进行。

而用户的行为可以用操作进行归纳,即用户对控件的操作策略,基本可以分为如下几种:输入、点击、滑动、选择、拖曳。

测试数据在某一个步骤中不是必须进行准备的,例如:点击登陆按钮,这个步骤将不涵盖任何测试数据,所以测试数据不是必须选项。

测试数据在现实的测试用例中,又分二种类型:(1)输入数据。即测试人员需要在被测系统输入的数据。(2)输出数据。即测试人员在被测系统中某一个区域内所获取的数据信息,这个信息可能是业务数据信息或者是控件特征信息。

测试数据在整个测试活动中占据了举足轻重的作用,也是决定着测试质量的一个关键环节,所以自动化测试活动中数据管理与控制也是自动化测试活动是否能够真正做到“自动运行、无人看守”的关键环节。

2.4 测试用例的粒度设计

测试用例的粒度的“粗”与“细”,在整个测试界都没有一个明确的定论,因为与之相关的取决于多种因素,例如:项目对质量的要求、时间的要求、用户的要求,作为公司管理者来说,希望用例的粒度越细越好,但是在现实工作过程中,时间和进度又是一个不可忽略的因素。所以手工用例编写主要思想是把待测的行为描述清晰,能够在不同的分支下,测试能够判断预期的结果与实际结果是否一致即可。

但是在自动化测试而言,所描述的用例每个步骤操作必须能够使得计算机能够解析,那么用例的行为必须要明确化。针对自动化测试案例来说,将不存在“粗”与“细”之分,自动化测试操作步骤的输入、输出或者检查模式必须具体化。而且不能遗漏上下步骤的之间的关联操作。这是自动化和手工用例的一个非常大的差异,而这个差异将会增加测试设计师很大的工作量来进行测试用例编写。自动化测试用例编写过程中,必须提供更好的策略来保障测试用例编写的效率来降低二者的差异。

自动化测试用例的粒度设计应保持如下原则:(1)每个用例验证功能点单一化,一个用例不能涵盖多个功能点的校验;(2)在用例的步骤设计中,不应涵盖步骤之间的相互跳转操作,例如:在某个操作输出值为A执行步骤N,输出值为B执行操作M。

2.5 如何提升用例编写效率

传统手工测试用例往往会忽略很多过程操作,直接把编写的关注点放在与检查相关的内容上。在自动化测试过程,需要一一描叙清楚过程操作,使得计算机能够按步骤去解析与执行到待测点,因为测试用例的编写工作更为繁琐。

如何提高用例编写的效率也是自动化测试用例设计的一个关键因素。从用例编写效率上可采取如下策略:

(1)用例手工编写与自动生成相结合的策略。很多测试工具提供了测试脚本录制的功能,实际也是测试用例编写工作。通过反编译自动化测试脚本而生成基本用例。从而提升用例的编写效率;

(2)提供便捷的用例编写操作。例如:用例之间的步骤的复制、位置移动、用例内部复制等等操作,来降低测试冗余的操作编写工作量;

(3)用例粒度可能进行细化,每个用例仅验证的为一个单一的功能点,尽量降低之间的冗余。然后通过用例的关联策略,使得计算机能够根据关联来组合用例,通过组合来验证各式各样的业务验证操作。

3 结束语

自动化测试本身来说,技术前瞻性是必须的,但对自动测试的定位很重要,定位、细节、技术缺一不可,必须把握相互之间的平衡。技术是基础,需要不断学习,却也不能忽略最重要的需求,在实现现有需求的同时,需要步步跟进,进行探索。自动化测试用例设计作为需求转化为技术的关键一环,更需要把握平衡,才能体现自动化测试的优势。

摘要：在自动化测试时的设计里需结合测试产品的新版本,设计出具有复用性的测试用例,使自动化测试的优势得到最佳体现。本文探讨了自动化测试用例设计的特点、原则,及各个元素的设计要点,为企业实施自动化测试过程中的测试用例的设计提供参考。

关键词：测试用例,前置条件,粒度设计

参考文献

[1]柳纯录.软件评测师教程[M].北京:清华大学出版社,2005.

[2]杨春.基于DotNet的自动化测试框架[J].电脑知识与术,2012第34期2012年12月.

[3]张斌.精通QTP与自动化测试框架设计实践[M].北京:人民邮电出版社,2010.

基于XML的软件自动化测试 篇3

关键词： 软件测试； 自动化； 自动化测试； 测试工具； 可扩展标记语言技术

中图分类号： TP 31文献标识码： Adoi： 10.3969/j.issn.10055630.2013.02.004

引言随着计算机应用日益普及和深化，用户对软件的需求越来越多，对软件要求也总是在不断变化[1]。AutoCAD产品在软件国际化的过程中，每次修改都需要对大量的测试用例进行反复测试，还要在不同语言版本的操作系统平台上测试，这就使得该项目的测试工作极为繁琐。软件自动化测试作为保证软件质量和可靠性的关键技术手段，正日益受到广泛的重视。但如何进行测试，如何提高测试的质量和效率，仍然是许多人深感困扰的问题[2]。根据对AutoCAD软件测试项目研究与实践的体会，介绍软件自动化测试技术的概述、基本过程和实现。结合实用的Silk Test工具以及可扩展标记语言技术（extensible markup language，XML），给出整个自动化测试框架。1自动化测试概述整个自动化测试平台包含两部分：测试平台和服务器平台。测试平台包含不同语言版本或者不同操作系统的平台；服务器平台主要含有源代码版本管理库和测试结果的关系数据库[3]。一个规范化的软件自动化测试过程通常包括以下几个基本的测试活动：（1）自动化测试用例选择对于Silk Test工具而言，它对Java的支持很好，所以如果是多模块、多软件测试，首先要尽量选择和Java相关的部分来设计用例[4]。（2）自动化测试环境准备开启windows远程控制，设置文件的扩展名可见，安装待测试AutoCAD系列产品，安装测试过程所需的自动化测试软件（Silk Test软件）等等一系列配置。光学仪器第35卷

第2期商林霞，等：基于XML的软件自动化测试

（3）自动化测试脚本开发Silk Test自动化测试工具支持简单的捕获同放功能，但是这并不是自动化测试。测试工具直接录制产生的脚本是不能直接使用的，所以对于利用Silk Test工具编写的脚本来说，通常是通过捕获对话框图形，抓到测试对象。然后利用Silk Test所提供的4Test语言来添加函数、控制结构等[5]。 （4）自动化测试报告生成分析脚本运行的结果是否符合要求，决定每个用例自动化测试是否通过。对测试结果进行分类整理，生成测试报告。对于不能通过的测试结果要进行分析、记录和通报，方便相关的测试人员和开发人员了解测试结果。2自动化测试系统过程为了取得自动化测试效率和效益的最大化，现选取当前最适合自动化的测试用例。例如自动化测试脚本编写异常复杂的用例、运行自动化测试脚本很难发现软件缺陷的用例等等，都可以不运用自图1自动化测试系统实现框图

Fig.1Automation testing system

realization block diagram动化测试，而运用手动测试代替。同时在两个测试版本的间歇进行新的脚本的开发，当有了一定数量的脚本之后，就让脚本运行起来，发挥作用[6]。现只要保证自动化运行的环境足够充足，那么每个测试版本所需的时间就会足够短，节省了大量的人力。软件自动化测试是一个极为复杂的过程。在不同的测试环境下，测试的流程也会有所不同。一般都要根据实际情况，制定相应的测试流程。从软件测试对象出发，软件自动化测试系统实现框图，如图1所示。对于不同语言版本的本地化测试，测试过程大体是相似的。首先根据AutoCAD软件的功能特征选择和设计测试用例，然后就是由测试用例编写测试脚本，接着就是将这些测试脚本作为输入运行程序，将通过测试得到的结果与先得到的英语版本的结果进行比较，最后就是将两者的比较结果写成测试报告，软件开发者根据测试报告再决定对软件如何处理[7]。3系统实现

3.1脚本生成根据测试设计中的每个测试用例，利用 Silk Test软件进行编程，完成自动化测试脚本。脚本编写完成，进行不断地调试，直至完成的脚本符合测试用例验证的要求。编程语言是4Test语言，整个脚本的思路是基于AutoCAD软件对话框对象来实现的。函数中执行图像录像功能的语句，把整个自动化测试的windows平台界面上的执行过程录制下来，方便判断软件是否存在缺陷。针对每个自动化测试的测试用例，编写测试脚本。每个测试用例都有数个测试确认点，测试脚本要保证每个测试确认点都能被执行自动化测试，生成测试结果。测试脚本程序示例如下：

3.2结果信息读取软件本地化测试的对象是本地化的软件，需要在本地语言的操作系统上进行。以Windows中文语言操作平台为例，用Silk Test工具运行该对话框对应的测试脚本，生成XML的结果信息文件，该XML记录了该对话框上的所有信息：文字信息、控件位置信息、控件属性信息。图2中所示的AutoCAD软件对话框的XML部分信息示例如下：

在获取对话框信息之后，接着就要进行XML结果的分析。读取XML文件信息的程序片段为：

其中，利用XPath的路径表达式来选取XML文档中的节点或者节点集[8]。如要读取出对话框的标题信息“选择样板”，则正确的XPath语句是“/DIALOG/CONTROL[1]/Texts_LIST/@Texts_00000”。类似地，对话框上各控件的位置、大小、属性等信息都可获取到。如图2中的截断错误，都用红色线框标示出来，提升了后期错误分析的效率。

3.3结果对比国际化软件自动化测试包括软件国际化测试和软件本地化测试。软件的国际化测试一般是英语版本的测试，必须在本地化测试之前进行。首先进行国际化软件测试有助于判断软件国际化的设计程度，确定软件支持的国家区域，以及本地化是否容易[9]。本地化测试过程中，以源程序软件结果（标准英语版本）作为本地化软件的主要参考。运行英语版本和本地化版本的结果比较程序，本地化版本对话框都将与标准英语版本对话框的各项信息进行对比。经对比本地化软件存在缺陷时有三大类情况：（1）本地化软件对话框的某项XML信息（控件的位置、大小、属性等）是空值；（2）本地化软件对话框的某项信息值的长度和标准英语版本的不一致；（3）本地化软件对话框的某项信息内容（控件的位置、大小、属性等）和标准英语版本的不一致。结果比较程序的部分示例：

3.4结果分析在实际的项目测试过程中，每一步都有很具体的内容。例如在报告测试结果的同时，实际上还包含了对测试结果的统计和分析，测试工程师通过对结果进行分析来判断是否存在缺陷，将缺陷上传至Test Desk网站进行管理。表1对话框界面的典型错误类型

Tab.1Typical error type of dialog user interface

错误类型说明对话框的外观显示不正确控件相互重叠对话框的内容显示不正确控件、文本字段截断对话框的命令响应不正确控件的热键相重复对话框的外观布局不正确控件的位置、大小对话框的文本内容不正确本地版本的文本未翻译

软件测试的目的是尽可能早和尽可能多地找出缺陷，然后软件开发人员根据测试报告确定缺陷[10]。在获取所有的软件对话框对比信息之后，总结出的典型错误类型如表1所示。实践证明，采用自动化测试大幅度地减少了测试难度，并且能够确保测试结果满足如下标准[11]：（1）所有的测试脚本都已经执行；（2）所有的变化都已经及时地作了重新测试；（3）通过重新运行测试脚本，所有发现的错误和缺陷都已经被纪录而且得到解决。 4结论软件测试结果决定着软件产品质量的好坏。要在最短时间内完成软件测试工作，需要认真分析需求和研究设计说明书，做好自动化测试的每一步工作（测试计划、测试用例设计、测试开发、测试执行和测试

自动化测试方法改进方案 篇4

自动化测试是测试领域中一个争议性比较大的区域，虽然它并不是一个新生的事物，但是至今仍没有一套比较完善的理论可以提供行之有效的方法，使之更好的为产品质量服务。各个研究机构和公司的专家提供了许多自动化测试的理论和模型，但是均没有形成通用理论，被大众广泛认可。

作者通过对安全产品进行自动化测试，从需求定义开始进行跟踪，涉及产品的设计与实现，对产品的接口、实现功能等进行自动化集成测试，采用测试代码和测试角本相结合的开发方式。作者总结了在工程中遇到的问题和实施中的成功之处，提出改进意见，对自动化测试人员具有较强的工程参考意义。

二、自动化测试简介

所谓自动化测试，就是充分利用测试理论和相关的工具，对产品进行自动化的测试，减轻甚至摆脱某些人工测试的繁重劳动，能够形成统一的测试报告并发布。

自动化测试涉及面很广，可以涉及单元测试、集成测试、系统测试、压力测试等诸多方面，针对不同的测试有不同的处理方法和工具。

经过实践，业界对自动化测试形成了一定的统一观点：

自动化测试不能代替手工测试;

自动化测试进行的是常规测试和回归测试，测试集覆盖率和BUG发现率均不高(这两组数据没有定论，根据测试系统的不同，数据会有所不同，但均低于50%，甚至低于30%)。

三、测试中的“人”

人永远是软件开发领域中的重要因素，不同的人掌握着不同的角色。充分调用不同角色的主动性，可以有效的提高自动化测试的效率。

1.领导支持

自动化测试是个系统工程，测试人员要制定合理完善的测试用例，需要得到需求、设计、开发等相关人员的配合。没有领导的鼎力支持，各方力量配合将会减弱，测试的实现目标将会大打折扣，测试工期也将无法保证。

因此从需求调研之初，就需要得到领导的大力支持，充分估计自动化测试所能达到的目标，制定良好的开发计划，如有可能，由项目经理直接进行领导，以期达到自动化测试的最优效果。

2.避免测试人员“挪作他用”

在许多公司，自动化测试均不是专职人员，经常是针对产品从研发、测试等部门抽调而来，因此他们原来都负担过别的工作。在自动化测试工作过程中，尽量不要由于其原工作问题，将自动化测试人员调回，更不能因为自动化测试在前期开发过程中收效甚微，在开发工期有限的情况下，暂时裁减开发人员。由于自动化测试工作量很大，从理解需求、设计用例、用例实现、测试驱动的设计与开发，到用例调试、用例的最终应用要经历比较长的工期，经常性的人员调动会导致工作情绪的波动和工作进度的滞后。

四、文档工作

在项目管理中，文档是软件工程各阶段的产品和依据，自动化测试当然也不能例外。

1.测试文档要及时

自动化测试与其说是一种任务，更不如说是一个公司知识库的积累过程，测试代码绝不是自动化测试的最终目的。

因此在测试开发过程中，要随时书写自动化测试的配套文档，并要根据需求和设计的变化，即时更新。文档包含自动化测试的设计、实现文档，测试集测试用例文档，测试驱动文档。测试文档的积累，也是对公司知识库的积累，减少将来进行同样开发的成本。

2.开发文档要完善

自动化测试的根本是文档，它依靠需求和设计文档来开发用例，而绝不是根据开发人员实际代码来进行的。因此在自动化测试开始工作之前，要准备好各种文档，包括需求、接口设计、数据库定义等，测试人员只有依据这些文档，才能制定合理的开发计划，开发出适合本系统的测试用例。

一定要避免由于工期等原因，产品的需求和设计文档跟不上，甚至编码前几天，需求设计才最终确定，在开发过程中也要避免频繁的更改需求和设计，其结果经常导致自动化测试人员开发测试用例“无依据”，常常要跟着开发人员跑，而不是跟着文档跑，期间的沟通要花费了大量的时间与精力。同时已经存在的文档如果经常发生变化，如果通知不及时，也会导致开发成本的加大。

通过自动化测试，可以达到检查开发文档，促使开发流程规范化的作用。

3.自动化测试报告清晰

自动化测试之所以在业界一直得以推崇，就是因为测试的自动化、报告的自动化，倘若缺少一份有效的自动化测试报告，即使有再全面的测试用例，别人也会对工作感觉很茫然，缺乏到工作的全面了解。

测试报告中，除有明确的统计数据(包括测试用例数据、通过率等)，还需求提供测试的跟踪信息、测试用例失败的原因分析。特别是由断言失败导致的失败原因分析，应具有很好的原因说明，良好的可读性，对问题有很好的描述与定位，可供自动测试人员、开发人员、设计人员和领导等多方人员阅读，对测试结果有很好的理解和定位。

自动化测试报告最好要做到妥善保存，利用测试报告可以跟踪项目进度，把握功能点的完成情况，同时也有利于BUG的回归查找。

五、方法的改进

在实施过程中，需要掌握不同的处理方法，应对处理各种实际问题，包括人员情绪。

1.沟通方式要完善

确认了自动化测试，就需要把自动化测试工作纳入到项目的统一安排之中，把自动化测试人员也做为需求、设计、开发的相关共利者，当发生改变时，要即时通知，以便修改测试用例，避免编码或设计已发生改变，而自动化测试还不知道，其结果将导致查找原因花费大量时间。

沟通也发生在人际关系的处理上。为充分理解需求与设计，自动化测试人员不可避免的要找设计人员沟通产品设计，有时还可能是频繁的询问，遇到设计人员工作重或心情不好，就有可能导致沟通上的困难或不充分。因此沟通需要技巧，测试人员需要耐心与细心，与开发人员保持好的关系，同时要尽量把问题一次沟通清楚，避免沟通不清导致测试用例返工，由此导致工作量的浪费。

对于基于组件的自动化测试，需要开发人员对功能充分的理解，明白自己开发的功能必须依靠什么组件，模块运行必要的支持组件。开发人员理解不充分，就会浪费测试代码的调试时间，直接影响最终的部署。

2.测试用例代码健壮性有待提高

测试用例的代码应具有很好的健壮性，理想的测试用例代码本身不会引入错误误报，断言错误时，只能是被测模块发生了失败。而在实际实施过程中，测试代码的健壮性很难保证，一方面由于测试用例代码编写人员本身编程水平不能保证，很可能产生代码上的BUG，另一方面由于需求和设计的变化，测试用例本身也要随时发生改变，测试用例更新不及时，就会导致被测模块的失败，因此及时沟通，及时更新用例代码，也是非常有必要。

3.避免测试驱动滞后

测试驱动是实现测试用例的根本，由于分工和涉足点不同，自动化测试人员只能完成很少一部分测试驱动，其它驱动由开发人员完成，测试人员只是负责定义驱动的输入输出接口。

但是开发人员有自己的任务，编写测试驱动势必增加其工作量，影响其原有工作的进行。为了自动化测试的正常进行，必须要与开发组领导进行充分的沟通，合理安排开发人员工作量，在不影响原有工作的基础之上完成测试驱动。

测试驱动实现的滞后，将影响测试用例的调试和最终部署，影响整体流程。

4.多种自动化测试工具的引入

一种产品可能会包含各种功能组件，比如数据库、界面、通信等各种操作，因此要引入不同的自动化测试工具，完成不同功能点的测试。如界面操作的角本录入WinRunner、压力测试工具LoadRunner等，各种工具的引入，可以使自动化测试的测试用例覆盖率扩大，使自动化测试更加深入和全面。

5.自动化测试工作的必要性

这一点也是最难处理的。自动化测试由于缺少成型的理论指导，常常导致没有达到理想的效果，使领导和开发人员怀疑其工作的必要性，同时也可能成为软件项目管理中的“鸡肋”。

如何考虑这个问题呢?是否有必要设置自动化测试这一环节呢?

要处理这种心理落差，就需要在开始工作之前，领导及相关人员确立切实可行的目标，考虑清楚自动化测试测试用例的覆盖范围、BUG率等，不要过于乐观的考虑自动化测试的工作成果。根据实际情况制定切实可靠的目标，使获得的回报更驱于理性。公司原有自动化测试的知识储备、自动化测试人力资源的部署、整体团队的配合等诸多因素都会影响工作的最终效果。

六、结束语

用友自动化测试面试题和部分答案 篇5

1、英文测试用例和测试计划的编写（用英语回答）

2、自动化测试工具各自的用途（用英语回答）

3、QTP实现功能测试的时候，当新版本的页面都改变了，应该如何解决？

去更改对象仓库的属性和更改对象仓库

4、QTP这个工具的优缺点？

QTP工具的优点：可以实现数据批量录入，回归测试，数据初始化

缺点：对于页面变更太大，对象仓库的更新将会更大一些

5、测试计划所包含的内容？以及测试计划中的测试进度表示如何设计的？

优点：项目中的测试范围，质量定义，工期安排，资源安排

缺点：将测试范围和测试周期用表格形式显示出来

6、如何设计测试计划与测试用例？

根据需求，及项目的成本预算

7、整个项目共有多少测试用例，其中有多少用例使用了QTP，都是什么类型的用例，使用使用自动化测试工具的用例所占所有测试用例的比例

400多个，都是功能方面的用例。50多个使用自动化测试工具

8、对于你来说，你认为是技术更重要一些，还是业务更重要一些？（业务搞不好，技术再强也没有用）

9、编过程序吗？用什么语言？

自动化测试的发展前景 篇6

所谓实验室测试指通过实验室对可靠性进行相关测试，此种方法是在早限定的条件环境下，通过某些模拟条件对设备使用的全过程中进行模拟，确保实验室内的设备在测试时与真正使用现场的应力完全相同，而后收集、分析累计的时间以及时效次数等数据，从而通过数学公式算出设备的可靠性水平。此种模拟试验的可靠性能较高，但是该试验的影响因素较多。

2.2保证试验

所谓保证试验指的是在出厂之前，对电气自动化控制设备采取的无故障测试。保证试验的测试目的是保障设备可靠性的试验，保证试验的测试时间非常长，对于批量生产的设备来说很难一一进行测试，只能通过抽查的方式进行检测。结合保证试验的特点，保证试验适合检测那些生产数量较少，但对可靠性能要求较高的自动化设备。

2.3现场测试

通信系统实施自动化测试的意义 篇7

自动化测试, 顾名思义, 就是让机器自动完成一些测试工作, 以减少人力的投入, 提高测试效率。但是要想真正的用好自动化测试, 就需要深刻的理解它的意义, 盲目的使用自动化测试, 不但可能提高不了效率, 还有可能降低效率, 甚至降低测试质量, 进而影响产品质量。

并不是所有的测试活动都适合使用自动化测试技术的。比如通信系统断电测试, 断电测试需要将电源开关断开, 然后再接通, 检查系统在突然断电后能否迅速恢复正常工作。手工测试时, 测试人员需要做的是断开系统电源开关, 然后再接通, 并检查系统运行情况。这样一个测试当然也可以自动化测试 (在当前技术下, 不能自动测试的功能还真不多) , 但它首先需要一个能自动通断的开关, 这在很多企业都是不具备的, 花费大量的精力准备这个条件, 将不会提升这个测试的效率, 反而使测试效率降低。

所以正确理解自动化测试, 是自动化测试成败的关键因素, 下面将对自动化测试的优势和局限性进行阐述, 希望对大家的自动化测试工作有所帮助。

一、自动化测试的优势

(1) 替代手工测试, 减少人力投入, 这个大家都非常熟悉的, 就不赘述了, 但一定要切记, 看到优势的同时, 也一定要注意局限性, 以免事倍功半。

(2) 自动化测试可以完成一些手工无法完成的测试内容。比如通信系统的固件版本兼容性测试。通信系统中各种版本不可能一次成型, 在整个开发和维护阶段会时有变更, 并且由于系统的模块化, 各种版本都将单独变动, 这就涉及到版本间的兼容性测试, 也就说, 在一个发生变化的版本发布前, 需要和其他版本进行联合测试, 以验证它们之间接口功能。这个测试看着容易, 做起来就麻烦了, 尤其已经使用了较长时间的系统。假设某系统有boot、epld、fpga和cpu运行版本四种版本 (绝大多数通信系统的版本种类都会超过这个) , 假设boot版本发生变更, 要发布新版本, 需要验证它和另外三种版本间的兼容性。假设epld、fpga和cpu版本各有三个版本在使用。这样, 兼容性测试要验证的boot版本和epld、fpga、cpu版本的组合数就是33=27次, 如果版本种类和数量更多, 组合数也将指数级的增长。这样的测试需要测试人员花费大量的时间重复的做, 很少有公司愿意安排这个时间, 也很少有测试人员能在这么枯燥的测试中不开小差, 所以这个测试的手工执行基本是不可靠的。使用自动化测试, 事情就变得简单多了, 工具往复的更换版本检查系统运行情况, 保证不会漏掉任何组合。

(3) 自动化测试的结果更加可控。同一个自动化测试用例, 无论执行多少次, 几乎都可以得到一致的测试质量, 不会像手工测试那个, 因人而异。比如上面提到的版本兼容性测试, 虽然方法很简单, 但如果使用手工测试, 也会因为测试人员的细心程度而得到不同的测试结果, 比如漏测了组合, 出现问题没有发现等。自动化测试则不会这样, 自动化测试会按着预定的路径, 一丝不苟的执行预定的检查, 所以得到的结果也是完全可控的。

(4) 优秀的测试思路可以发挥更大作用。由于自动化测试可以始终如一的往复执行, 优秀的测试思路一旦进入自动化测试用例, 就可以一遍又一遍的发挥作用, 就好像那些优秀的测试人员有分身术一样, 同时在不同的地方发挥着作用。所以我们在设计自动化测试用例时, 应该让更多的优秀测试人员加入进来, 设计出最优的测试用例。这样的自动化测试用例在回归测试时是非常有用的。

(5) 自动化测试可以充分利用工作外时间, 使时间和设备安排都更灵活。人总是要休息的, 但机器可以二十四小时运行, 使用自动化测试, 就可以将八小时外的时间利用起来, 这样测试工作安排起来将更灵活高效。

二、自动化测试的局限性

(1) 自动化测试用例开发投入的人力往往比手工用例设计多很多, 因为自动化测试用例需要好的思路, 还需要编写额外的工具。这也是不要盲目开展自动化的原因, 以免时间人力花进去了, 却没起到效果, 所以开展自动化测试之前, 一定要认真评估好自动化测试是否真的能提升测试效率。

(2) 自动化测试由机器完成, 它是不会主动思考的, 不会像人一样, 一边测试一边完善测试用例和方法, 主动地去发现bug。所以对一些不是很熟悉的功能最好不要采用自动化测试, 手工测试会得到更高的效率和更好的测试效果。自动化测试用例需要设计的非常完备, 一般最好经过评审。

(3) 自动化测试不会使测试覆盖达到百分之百。自动化的用例也是人设计的, 人总是会有思想盲区的, 不要盲目追求百分之百的覆盖率, 应该更加注重投入产出比。

自动化测试的发展前景 篇8

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

由于电气自动化控制设备的特殊性，使得电气控制行业的可靠性整体较为复杂，使得可靠性问题日渐突出。为了提高电气自动化控制设备的可靠性，国家相关电控配电部门提出了对电气自动化控制设备可靠性测试的方法，从而加强电气自动化控制设备的可靠性，获得高可靠性的产品。

1 提高电气自动化控制设备可靠性的意义

1.1 加强产品质量。在任何一个企业，唯有产品质量得到保证才能为企业赢得广阔的市场空间。在企业的自动化控制生产中，企业各个部门应该不断加强产品质量，赢得信誉保证，才能树立企业良好形象，提升企业竞争力。而电气自动化控制设备可靠性的提高是加强产品质量的关键。

1.2 提高产品的竞争力。随着我国社会不断进步，人们的生活水平不断提高，对产品可靠性的要求越来越高。只有具备良好可靠性的产品才能在激烈的市场竞争中占有一席之地，因此提高电气自动化控制设备的可靠性是非常重要的。

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

2.1 保证实验法。保证实验法是在企业产品出厂前，在一定的条件下对产品进行无故障工作试验，这就是通常说的“烤机”。一般情况下，保证实验法是以电气自动化控制设备为对象，由于该研究对象具有较多的元器件，使得其故障显示具有一定的随机性，且形式多种多样，可以说电气自动化控制设备保证实验法中，其故障服从于指数分布，其失效率在时间的变化下而发生改变。对产品进行“烤机”实质就是对产品的失效情况进行检测，并及时进行改进和完善，以确保所出厂产品质量符合相关的指标要求。如果产品是大批量生产，那么这种可靠性测试方式只能对产品的样本进行检测；生产量如果不大，可以将这种方法应用于所有的产品上。因此电气自动化控制设备可靠性保证实验法主要适用于对可靠性要求较高、电路相对复杂且数量不大的控制设备中。

2.2 现场测试法。现场测试法，顾名思义就是在现场对电气自动化控制设备的可靠性进行检测，并通过数理统计方法将检测后获得的数据进行计算，得出控制设备可靠性指标。现场测试法在进行可靠性试验时，直接就可以在实际中进行试验，并不需要太多的试验设备。往往这种测试方法所计算出的数据指标能较好的反映出设备的可靠性，提高了测试的准确性。同时现场测试法并不需要太多的资金投入，并且接受测试的产品也不会受到任何外观或者质量的影响，测试质量合格后可以直接出厂，对产品出厂效率具有积极的促进作用。

2.3 实验室测试法。所谓实验室测试法是在可控制环境或者环境条件下，通过对可靠性模拟进行测试，对设备运行现场使用条件进行模拟，以最接近设备运行现场所遇到的环境应力对设备进行检测，并将累计失效数量、时间等各种数据通过数理统计方法进行计算，从而获得设备可靠性相关指标。实验室测试法中实验条件对试验数据的控制性较高，一旦数据质量较高，就可以再现实验效果，以便对试验结果进行分析。但是通常试验条件都具有一定的局限性，在对实验所获得的数据进行分析时，难以与实际数据相对应。再加上实验室测试法的测试费用较高，且需要测试的产品量较大，因此在对电气自动化可靠设备进行实验室测试时，必须充分考虑需要进行可靠性实验产品的成本和产品的生产量。

3 对电气自动化控制设备可靠性测试建议

3.1 从产品研制-生产-出厂等环节都需要对产品进行可靠性测试，保证所有出厂的产品都符合相应的质量要求。在进行测试的过程中，需要按照产品研制和生产的进度以及测试相关要求，制定出一个科学、合理、统一、高效的测试计划，并将其纳入产品研制、生产与出厂的所有计划中。只有制定出综合的计划，才能对测试相关安排、实施进行统一的规划，实现良好的测试效果和经济效益。不同产品可靠性测试应该安排在产品最适合的阶段进行，比如可靠性增长测试在产品研制阶段进行；统计测试可以在产品设计、工艺变更时期进行；验收测试往往适用于成批产品生产验收阶段。

3.2 在进行电气自动化控制设备可靠性测试方式进行选择时，需要按照产品的组合层次设置不同的可靠性指标，从而确定适合的测试方法。如基本传统系统测试以考核平均故障间隔时间、现场数据为主，可以选用实验室测试法；电气控制单位测试以考核平均故障率为主，也可以选取实验室测试法；对于成套设备大系统，往往采用现场测试法。

3.3 在对电气自动化控制设备可靠性进行试验时，尽可能减小需要测试的数量以及费用，制定出高效益的测试方案。同时对现场数据进行规范化，根据企业具体情况制定出测试相关制度，统一记录表格，规范故障模式和分析方法，从而提高测试的规范性和准确性。

4 总结

随着电气自动化的不断发展，电气自动化控制设备的可靠性受到了各行各业的重视。因此企业应该从自身实际情况出发，制定出科学高效的测试方案，从而提高设备的可靠性，促进产品质量不断提升，这样才能使企业在激烈的竞争中立于不败之地。

参考文献：

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

[2]赵庆伟.电气自动化控制设备的可靠性分析[J].产业与科技论坛，2013，05：73-74.