软件自动化测试技术研究

摘要：软件测试作为软件开发的一个重要环节，对提高和保障软件质量起到关键作用。该文从软件自动化测试的设计原则、自动化测试框架的选择和自动化测试用例的生成等几个方面出发对软件测试自动化技术加以探讨，其目的是为企业实施自动化测试过程提供参考。

关键词：软件测试；自动化；框架；测试用例

中图分类号：TP311 文献标识码：A 文章编号：1009-3044（2013）12-2923-03

软件测试作为软件质量保障的重要手段，其存在于软件开发生命周期的每一个过程。在整个软件项目的开发过程中，测试人员必须对所开发的软件进行不断测试，以保证软件的正常运行。统计数据表明：软件项目中超过一半的预算投入到软件测试中，所以软件测试代价高昂。缺陷发现的越晚，修正缺陷的代价也越高，给企业造成的损失也越大。

随着软件规模的增加，测试工作量的增大，需要投入大量的人力，原本的手工测试逐渐暴露出诸多缺陷，例如，覆盖率量化困难、重复测试效率低下、不一致性和可靠性低、依赖人力资源等。软件自动化测试技术正是在这种情况下产生的。其根本目标是使所有的测试行为包括测试用例的设计、驱动、结果检查、缺陷定位和移除等都尽可能实现自动化。事实证明，正确、合理的实施自动化测试，能够对软件生命周期的各个阶段进行快速、全面的测试，提高软件测试效率，保证软件的质量，节约软件的开发成本，缩短软件的开发测试周期。但实际上，并非所有的自动化测试技术都可以达到测试活动的预期目标，诸多软件开发机构在实施软件自动化测试的过程中通常存在无法正确找准测试自动化的切入点、程序开发过程和测试自动化过程相互独立、软件测试脚本的质量低劣、测试自动化过程对测试用例的依赖程度过高等方面的负担造成工期延误和成本浪费，甚至最终被完全放弃等问题。

自动化测试技术要想有效地解决测试质量与效率、降低测试自动化的投入、提高其产出等问题间的矛盾，必须形成一套系统的自动化测试体系，在质量保障方面有所作为。因此，深入研究软件自动化测试技术和方法，保障软件质量，已经成为国内外软件行业和相关机构的研究热点。

1 自动化测试的设计原则

软件自动化测试是相对于手工测试而存在的，自动化测试可以被理解为使用一个商业通用测试自动化工具编写一个软件来发现其他软件的缺陷。开发测试脚本以执行键盘、鼠标动作和后台进程并验证应用程序响应和行为。一个良好的自动化测试体系在设计时，需满足以下条件：可维护性 - 使测试更新跟上软件升级的步伐；高效性-实现效率最大化；可靠性 - 使测试结果准确而且可重现；兼容性-允许测试用例为不同的测试目标而以不同的方式组合；可用性-测试人员或用户容易掌握定制或更改测试用例的方法；健壮性-可以处理意外情况而不退出或终止；可移植性 - 测试脚本可以在不同环境中运行测试。

2 自动化测试框架的选取

自动化测试框架是一组自动化测试的规范、测试脚本的基础代码，以及测试思想、惯例的集合。自动化测试框架的好坏对自动化测试的成功有直接影响。目前业界公认的自动化测试框架，主要有四种：数据驱动框架、测试脚本模块化框架、测试库架构框架和关键词驱动框架。

1）数据驱动框架

测试驱动引擎从数据文件读取输入数据，通过变量的参数化，将测试数据传入测试脚本，不同的数据文件对应不同的测试用例，数据驱动脚本将测试脚本（执行步骤）和数据分离，将测试输入数据存储在独立的数据文件中，而不是直接存储在脚本中[1]。在脚本中引入变量，执行时通过变量来读取数据文件中的数据。通过数据驱动脚本，同一个脚本可以测试不同的输入数据，提高了脚本的重用率和可维护性。其缺点是初始建立的开销较大，由被测试应用程序的变化所导致的工作量在所有架构中是最多的，因此维护成本是相当高的。

2）测试脚本模块化框架

测试脚本模块化框架的测试脚本中包含了各功能点的控件识别和业务逻辑操作，其中包含调用外部测试数据。框架结构如图1所示。图中箭头方向代表的是调用关系。负责自动化测试脚本维护的开发工程师必须了解自动化编程和业务逻辑。负责为花测试数据的工作由测试工程师完成。它的优点是控件和业务逻辑一旦发生变化，底层的测试脚本就要进行修改和维护（这比没有任何抽象封装的自动化测试程序稍好一点）。缺点是几乎所有大的变更导致的工作量都要交给自动化测试开发工程师来完成；控件识别和业务逻辑本身属于不同的领域，

没有很好进行抽象封装。

3）测试库构架框架

所有的针对测试系统本身的控件识别和支持的操作将被封装在测试库中；通过测试脚本调用测试库的同时传递外部的测试数据；自动化测试开发工程师在编写测试库的同时（无需了解业务），还需要负责控件的变更和维护；对业务比较熟悉的自动化测试开发工程师编写测试脚本，并负责业务逻辑的变更和维护；测试工程师则只需要维护测试数据（无需了解自动化开发）。框架结构如图2所示。其优点是在被测试系统中，无论是哪一层的变化，其需要的变更维护工作只需要交给相应人员即可；这从根本上实现了控件识别操作和业务逻辑的抽象分离。其缺点是由变更引起的工作量还是附加在自动化测试开发工程师身上。

4）关键词驱动框架

关键词驱动框架是数据驱动框架的一种改进类型。在该框架中，需要定义关键词表格，关键词表格一般存储在测试数据库、Excel或文件中，表格一般包括所需要的所有对象、操作和测试数据。编写驱动代码读取表格数据，分析测试对象、测试操作和测试数据。关键词驱动的主要思想是：脚本与数据分离、界面元素名与测试内部对象名分离、测试描述与具体实现细节分离[2]。关键词驱动模式具有以下优点：在同一个特定格式的数据表中就可以实现测试步骤、测试数据以及验证结果的编写；独立于测试脚本语言开发测试用例；所需脚本数量是随着软件的规模而不是测试的数量而变化的；可以用于工具无关的方法实现测试；实现测试的方法可以剪裁适合测试者而不是测试工具。

3 自动化测试用例的生成

自动化测试中，自动化测试用例是重中之重，一个设计优秀的自动化测试用例能在很大程度上决定自动化测试是否成功。自动化测试用例应用脚本技术进行用例解析，是针对自动化测试框架的，在进行设计时应满足两个原则[3]：①选择操作过程相同的一些测试需求，来组成用例场景，使用测试用例结构化指导测试脚本的结构化。②场景包含的用例不能太多，当一个场景包含的用例数量较多时，可以考虑对场景进行分拆。

1）自动化测试用例要素分析

在设计自动化测试用例时，除了必须包含测试目标、测试前提条件、测试环境要求、测试类别、测试用例标识、测试操作ID、测试操作描述、测试操作路径、测试输入数据和期望结果等元素，对必填元素在编写结束后必须进行判空校验，以确保测试用例自动执行时的有效性。

设计测试用例时，首先要保证测试用例名称能唯一标识某一个用例，例如“新用户注册”。在自动化测试底层会一般是通过添加ID来控制用例的唯一性，但是在界面上显示时，一般通过醒目的信息提示等手段对唯一性进行控制。其次，每一个测试活动通常存在前提条件。一个测试用例往往是另外一个用例执行的前提。正常情况下在执行登陆操作之前，用户需要进行注册操作。所以把新用户注册用例作为用户登陆用例的前提。另外，因为测试用例已经存在于测试用例库，所以要想使计算机能够知道在执行该用例之前，必须先执行某一个用例，那么就需要在相关用例之间建立前置关联关系。最后，测试步骤的操作过程在自动化测试过程中实际分为操作步骤、控件和数据三个关键词段[4]。操作步骤就是用户的操作顺序。在测试过程中，测试人员主要对控件实施某种行为，例如：用户进行注册时，是在注册页面中输入用户名、密码以及各种其他信息，然后点击“注册”按钮，这是针对文本框和按钮等控件进行操作。而数据主要是用户在这些控件上所填充的输入内容。在自动化测试来说，标识控件的可以通过对象本身以及该对象的属性来进行描述。

2）测试用例的粒度设计

测试用例的粒度因为有很多与之相关的因素，包括项目的质量、时间以及用户要求等等，在整个软件测试领域目前还没有统一定论。测试用例的粒度决定了用例模型级的复杂度，也决定了每一个用例内部的复杂度。应该视软件的具体情况来把握各个层次的复杂度，在尽可能保证整个用例模型的易理解性前提下决定用例的大小和数目[4]。在进行用例粒度设计时应注意以下问题：第一，一个用例不能对多个功能点进行校验，尽量保证每个用例验证功能点单一化；第二，在设计用例步骤时，不应涵盖步骤之间的相互跳转操作。

4 结束语

随着软件规模的的日益庞大，实施软件测试的成本也越来越高。将自动化软件测试技术引入到软件开发的整个过程，不仅可以缩短软件开发周期，让产品更快投放市场，能够提高软件测试的准确度和精确度，增加软件的可信任度，另外还能增强测试的稳定性和可靠性。自动化测试包含的内容有方方面面，这里只是对其中的一部分进行研究。对于自动化测试，我们除了要建立一个正确的认识观之外，还应该力求在自动化测试领域不断创新，制定出更系统的自动化测试体系，为软件质量保驾护航。

参考文献：

[1] 刘旭.软件测试自动化的测试研究[J].煤炭技术，2012（7）：168-169.

[2] 黄威.关键词驱动的测试自动化框架模型与系统实现[J].计算机技术与发展，2012（4）：57-60.

[3] 李翼，陈创.计算机软件测试技术浅谈[J].计算机光盘软件与应用，2012（11）：113-115.

[4] 郭德红.自动化测试的测试用例设计[J].价值工程，2012（20）：195-197.