自动化测试范例

自动化测试范例篇1

　　Mercury QuickTest Professional为每一个重要软件应用和环境提供功能和回归测试自动化的行业最佳解决方案。

　　QuickTest Professional是新一代自动化测试解决方案，采用了关键词驱动（Keyword-Driven）测试的理念，能完全简化测试的创建和维护工作。QuickTest关键词驱动方式独有之处在于，测试自动化专家可以通过一个整合的脚本和纠错环境，拥有对基础测试脚本和对象属性的完全访问权限，这些脚本和纠错环境与关键词视图（Keyword View）可以互为同步。

　　QuickTest Professional同时满足了技术型和非技术型用户的需求，让各个公司有能力部署更高质量的应用，同时部署的速度更快，费用更低，风险也更小。

　　QuickTest Professional和我们新的测试自动化系统Mercury Business Process Testing的紧密结合，可以将非技术型的业务专家（SME， Subject-Matter Experts）引入质量流程，这一意义重大的引入可以将IT和业务更好地融合，最终建立起更出色的应用。

　　有了该产品，QA机构可以获取多方面的优势：

　　用最少的培训赋予整个小组创建成熟测试方案的能力；确保跨所有环境、数据包和业务流程的正确功能点；为开发人员全面记录和复制缺陷，使他们能更快地修复缺陷，满足最后上线期限；对不断变化的应用和环境展开便捷的回归测试；成为帮助整个机构实现高质量产品和服务、提高总收入和收益率的关键角色。

　　易操作

　　QuickTest Professional易于操作，即使是初级的测试人员也能在短时间内对其驾轻就熟。您可以使用无需脚本的关键词视图来表现测试的每个步骤，仅由此就可创建一个测试。您还可以通过QuickTest Professional所集成的录制能力来捕获测试步骤。该产品用简单的英语以文档形式记录每个步骤，并通过活动屏幕将文档与一个集成截屏相结合。

　　传统的脚本记录工具所生产的脚本不易修改。与此不同的是，QuickTest Professional的关键词驱动方式能让您便捷地插入、修改、数据驱动（data-drive）和移除测试步骤。

　　功能测试

　　那些在Mercury WinRunner测试工具上投入大量资金，并想转入Mercury QuickTest Professional的用户，可以使用Mercury Functional Testing来实现这种转变。Mercury Functional Testing将QuickTest Professional和WinRunner结合成一种集成产品，它不仅可以使用WinRunner脚本，也可以使用QuickTest Professional脚本，使测试资源得到极大地利用。质量工程师可以使用Mercury Functional Testing来创建“复合脚本”测试。Mercury Functional Testing是WinRunner和QuickTest Professional的集成，产品间可以相互调用脚本。

　　质量中心的组成部分

　　Mercury QuickTest Professional是Mercury质量中心（Mercury Quality Center）的组成部分之一，Mercury质量中心集成了一整套软件、服务和最佳实践，用于自动化关键质量活动，包括需求管理、测试管理、缺陷管理、功能测试

　　和业务流程测试。

　　特点和优势

　　・具有行业领先的便于使用的特性，以及支持提前配置环境的功能，确保了快速的投资回报。

　　・可独立运行，也可以同Mercury Business Process Testing和Mercury质量中心集成。

自动化测试范例篇2

　　关键词：软件测试；自动化测试；“猴子”测试

　　中图分类号：TP302 文献标识码：A 文章编号：16727800（2013）009001504

　　作者简介：鲜征征（1977-），女， 广东金融学院计算机科学与技术系讲师，研究方向为软件开发、软件测试、数据挖掘。

　　0引言

　　软件测试是使用人工或自动化手段来运行、检测软件系统的过程，是软件开发必不可少的环节和软件工程实践的重要组成部分，自动化测试是软件测试发展的必然结果。成功实施自动化测试的关键是选用适合自己测试项目的自动化测试工具，然而，不管选用何种测试工具，都会带来相应的测试成本：商业测试工具昂贵，开源测试工具虽然免费，但却拥有较高的使用成本，且免费的测试工具性能比较单一，无法支持整个自动化测试的实施，有时，即使在付出了相应的测试成本后，测试效果依然不如人意。

　　因此，开发适合自己项目的特定的测试工具将是一种行之有效的解决方案。其中“猴子”自动化测试工具也正是在这样的背景中提出的。由于项目资源投入有限，大型而通用的测试工具的开发和维护需要耗费项目组不少的资源，而具有简单功能的“笨猴子”的开发成本相对于收益是可以接受的。本文将在分析自动化测试的主要技术后给出一个“猴子”自动化测试工具的设计步骤和实现的关键技术，其中的方法可以为将来设计功能更强大的“猴子”测试工具奠定一定的基础。

　　1自动化测试技术

　　1.1自动化测试优势

　　针对手工测试，自动化测试有着很强的优势，即借助计算机的计算能力可以重复、不知疲倦地运行，对数据能进行精确的、大批量的比较，而且不会出错。因此，自动化测试适宜用在需要重复执行机械化的界面操作、计算、数值比较、搜索等方面。应该充分利用自动化测试工具的高效率来帮助测试人员完成一些基本测试用例的执行，从而实现更加快速的回归测试，并提高测试的覆盖率。虽然，自动化测试的目的是帮助人工，但是手工测试仍有很多不可替代的地方，例如很多数据的正确性、界面是否美观、业务逻辑的满足程度等都离不开测试人员的人工判断。因此，为了让软件测试更加顺利和取得更好的效果，通常是自动化测试和人工测试相结合，让其充分发挥各自的优势。

　　1.2自动化测试工具选择

　　自动化测试工具可以将复杂的测试工作自动化或半自动化， 减少测试工作量， 提高测试工作效率、减少测试开销， 所以需要选择一个合适的且满足企业信息系统工程环境的自动化测试工具。从开发成本来说，自动化测试工具分为商业、开源和自制的测试工具。根据测试方法的不同，自动化测试工具分为白盒测试工具、黑盒测试工具和测试管理工具。工具和软件开发过程中相关活动的关系如图1所示。

　　（1）商业测试工具。目前很多软件公司都具有一套自动化测试工具。白盒测试工具的代表有：Telelogic公司的Logiscope，PR公司的PRQA，Compuware公司的DevPartner，Rational公司的Purify，其中前两个是静态测试工具，后两个是动态测试工具。黑盒测试工具的代表有：Rational公司的TeamTest和Robot，Compuware公司的QACenter，Mercury Interactive的WinRunner、LoadRunner 和QTP等。测试管理工具的代表有Rational公司的TeamManager、Compuware公司的TrackRecord等。除此之外，还有专用于性能测试的工具有Radview公司的WebLoad，Microsoft公司的WebStress等工具，针对数据库测试的TestBytes对应用性能进行优化的EcoScope等工具。

　　虽然，很多大型软件公司都有一套自动化测试工具，但没有一种通用的测试工具可以找到任何软件中的所有Bug。应该根据被测软件的特性来进行合理的选择，此外，上述的测试工具价格都相对较高，从整个软件开发的成本来说也是需要考虑的。

　　（2）开源测试工具。开源测试工具作为开源软件的重要组成部分，但开源并不意味着完全免费，开源测试工具同样需要考虑使用成本。开源测试工具相对于商业测试工具的优势：相对成本较低，可以根据实际需求对其进行个性化改造。引入开源测试工具也需要考虑成本、选型等问题。

　　常见的测试管理类开源测试工具有：Bugzilla、Mantis、BugFree。单元测试类开源测试工具有：Nunit、Nmock等。性能测试类开源测试工具有：Jmeter、TestMaker等。自动化功能测试类开源测试工具有：Abbot Java GUI Test Framework、White、Watir等。

　　（3）自制测试工具。目前，很多软件测试组织其实都已经具备了自己动手开发测试工具的条件。自己动手开发测试工具的优势主要有：购买成本为0；可以有针对性地开发自己需要的那部分功能；可以自己定制需要的功能，随时修改，实现个性化；可扩展性好，可以随时增加新功能；可以充分利用项目组熟悉的语言来开发，从而利用自己的技术优势；可以使用自己熟悉的脚本语言，从而不必使用商业工具提供的“厂商脚本语言”。

　　虽然，自制测试工具有很多好处，但是也必须考虑随之而来的成本问题。自制测试工具开发的成本主要是指开发时间、人员和维护方面的成本，还需考虑测试工具的实用性，不需要做一个大而全的、面面俱到的工具。因此，通常应当将自制测试工具最好定位在辅助测试、用于解决专门的问题、迫切的问题。在商用工具价格昂贵、开源测试工具也不适用的时候，可以考虑自制测试工具。本文下一章节将着重介绍一个“猴子”测试工具的设计与开发的关键技术。

　　2“猴子”测试工具设计与实现

　　2.1“猴子”测试技术的概念

　　所谓的猴子测试（Monkey Test），即搞怪测试、随机测试，通俗来讲是一种系统对信号因子输入稳健性的测试方法，一般用于计算机软件程序这样的逻辑严密性要求较高的系统。测试者可以进行各种稀奇古怪的操作模式，用以测试软件的稳定度。该测试技术泛指任何形式的，不需要任何人工干预的，随机进行的自动化测试。这种类型的工具之所以称为“猴子”是源于“无限猴子定理”，即“让一只猴子一直在打字机上按键，最终能完成莎士比亚的全部工作”。由于系统的“可重复性”以及系统输入因子“有限性”和“单纯性”，“猴子”测试被广泛用于软件Bug测试。

　　根据“猴子”测试的原理，有很多可以实现“猴子”测试的方法，一个简单的实现方式是一个能随机产生鼠标点击和键盘输入来模拟用户操作的“猴子”测试工具。 而复杂的实现方式是实现一个“聪明”的“猴子”，构建聪明“猴子”测试工具需要开发和测试资源，而最昂贵的代价是创建模型或状态表[2]。

　　2.2“猴子”测试工具开发使用的技术

　　一个“猴子”测试工具的开发主要是语言的选择和接口驱动的设计。本文基于对被测软件（C#语言开发的软件）的考虑，故选用了 C#语言。“猴子”测试工具的实现原理是利用产生鼠标点击和键盘输入事件来模拟用户操作，而Windows GUI 驱动是直接驱动Windows底层的API完成查找GUI控件、驱动鼠标和键盘操作的方式实现对软件的测试。故可以利用Windows系统提供的Windows API完成工具的实现。

　　2.3“猴子”测试工具的具体实现

　　（1）功能简述。该“猴子”测试工具主要功能：随机点击界面，输入随机字符和键盘按键，对于某些类型（按钮、可编辑框等）的控件做出特定的动作，监视被测试程序的进程信息，能识别出程序是否出现异常，持续记录内存和CPU使用情况，方便发现是否存在内存泄漏问题，持续截屏，方便追溯和问题定位。

　　（2）设计原理。“猴子”测试的工作原理是利用测试工具随机产生键盘敲击和鼠标单击事件。因此，利用Windows系统的本机原生函数实现对键盘输入，鼠标点击的模拟，从而创建一个”猴子”进行简单测试。

　　（3）设计流程。本文的“猴子”测试工具的设计流程如图2所示。

　　在设计过程中，鼠标操作功能和截屏功能是开发的难点，“猴子”动作规则的设计则是整个工具的核心。

　　（4）具体实现。

　　界面设计：“猴子”工具的界面主要包含Bug报告存储地址选择、源字符集、被测程序选择、测试时间间隔选择等。作为一个运用于软件开发过程中以测试相对应的项目而实现的辅小工具，其界面的实现不需要太复杂的功能。

　　实现鼠标操作功能主要有以下步骤：

　　首先，引入鼠标触发事件的函数。该函数原型为：

　　public static extern void mouse_event（int dwFlags， int dx， int dy， int cButtons， int dwExtraInfo）；

　　其次，设计鼠标相关操作的类MouseAPI，该类定义了鼠标的各种操作，考虑到篇幅有限，这里仅列出该类的主要函数原型及功能说明，如表1所示。

　　（6）“猴子”动作规则。将该工具之所以用“猴子”来命名，最关键的是它具有猴子天性好动的特性，“猴子”的动作规则主要包含：随机完成鼠标移动和键盘输入、具备一些智能、连续不断地完成一些指定动作。

　　“猴子”随机完成鼠标移动和键盘输入实现分析：首先获取某个范围内是随机数，然后通过其得到一个当前屏幕中任何一个点的坐标，接着实现鼠标的随机移动。最后使用将指定的字符串数组中某个字符串以键盘输入的方式发送给应用程序。

　　让“猴子”具备一些智能实现分析：首先将获取光标所在点的窗口类的类名与指定的控件类类名进行比较，进而判断当前鼠标点击的控件，然后做出相应的动作。使用雷同的方法，“猴子”可以识别出按钮控件、静态控件，如标签、出错提示对话框等控件并做出相对应的动作。

　　让“猴子”连续不断地完成一些指定的动作的实现分析：为使“猴子”能连续不断地完成指定动作，利用Timer控件实现一个计时器，然后通过一个按钮来控制定时器的启动和停止。而“猴子”工作时的所有动作规则都被封装于Timer控件的Tick时间中，这样，在每一个指定的时间段，“猴子”便会执行一次指定动作。

　　3实验及结果分析

　　（1）被测对象的选择。为了有效地完成对“猴子”测试工具的有效性检查，被测对象的选择应该是拥有可编辑控件和若干按钮控件的小型软件。本次测试选了一个仅具有加、减、乘、除的简单计算器。

　　（2） 实验过程。整个实验过程分为如下步骤进行：①设置测试报告存储的位置；②设置键盘输入的字符集。指定字符集所在的文本文件的位置，指定键盘输入的字符串；③指定被测程序；④根据测试的需要，设置“猴子”操作程序的时间间隔；⑤启动被测程序；⑥开始“猴子”测试。

　　（3）测试结果及分析。考虑到篇幅有限，这里仅给出部分测试结果，分别如图3、图4、图5所示。

　　通过对实现的“猴子”测试工具的实验，该工具达到预期效果，可以实现一定的自动化测试。“猴子”测试工具开始工作后，“猴子”每隔一段指定的时间就会随机点击被测程序主界面，并在识别到可编辑控件时会随机键入某些字符串，字符串是事先准备好的字符集文本文件中的一部分字符。在连续进行的多次试验中，基本上，在“猴子”进行操作了若干有限步操作后，被测程序的bug便将会被检查出来。当测试进行了一段时间，被测程序的大部分Bug便会被找出并纠正。这之后，再进行“猴子”测试时，Bug的发现变得越来越困难。

　　4结语

　　软件测试是软件工程实践中的重要组成部分，自动化测试是软件测试发展的大方向。软件自动化测试实施的关键是自动化工具的选用，而当所有的工具都不适用，或自己开发一个跟项目相适应的工具比应用现有的工具更

　　能节约成本时，自制一个自动化测试工具便也是一种可供选择的方法。本文设计的“猴子”测试工具是对应于简单的软件进行测试“猴子”原型，针对具体的项目程序的环境，可以进一步完善“猴子”，使其更加智能，从而能发现更多的Bug。

　　参考文献：

　　[1]张建，徐宝文。软件测试专辑前言[J]。计算机学报，2011（6）。

　　[2]陈技能。软件测试技术大全[M]。北京：人民邮电出版社，2011.

　　[3]胡铮。软件自动化测试工具实用技术[M]。北京：科学出版社，2011.

　　[4]JAMES BENDER，JEFF MCWHERTER。C#测试驱动开发[M]。北京：清华大学出版社，2012.

　　[5]徐进。自动化软件测试的分析[J]。信息技术，2010（3）

　　[6]单锦辉，姜瑛，孙萍。软件测试研究进展[J]。北京大学学报：自然科学版，2005（1）。

　　[7]王雅文， 宫云战， 杨朝红。软件测试工具综述[J]。北京化工大学学报：自然科学版，2007（S1）。

　　[8]石红霞。软件测试运行规划及自动化测试工具的研究[D]。成都：成都理工大学，2011.

　　[9]宋洁。软件测试技术及自动测试工具的实现[D]。北京：北京邮电大学，2007.

　　[10]XIAO HUABO ， HUANG SHULI。 Research in test case method in software testing[C]。 ICEET2012， HongKong， 2012.

自动化测试范例篇3

　　摘 要 软件测试管理是为了使软件测试项目能够按照预定的成本、进度、质量顺利完成而对成本、人员、进度、质量、过程和风险等进行分析和管理的活动。测试管理关注人员、过程、产品三要素的互动和变化，测试过程和阶段的相互作用，测试与开发团队的相互关联与协调配合，为使这些过程能有序的进行，开发出适合自己项目组的测试管理工具是必需的，同时由于自动化测试的普及，如何将自动化测试融入进来也是一个挑战。本文描述了我们项目组开发的支持自动化测试的测试管理工具的结构和功能实现。 关键字 自动化测试；测试管理；软件测试 1 引言 为了保证软件产品的质量，需要对软件过程进行控制，同时也需要对软件产品本身进行检测，在目前形式化方法和程序正确性证明还无望成为使用性方法的情况下，软件测试在将来的相当长一段时间仍然将是软件质量保证的有效方法[1]。 软件测试管理就是通过一定的管理方法和工具来对整个软件测试过程进行监控，从而提高软件测试的绩效。由于软件测试管理的复杂性，没有特别的辅助工具，只是依靠人工处理是很麻烦甚至是不现实的。 对于测试工具的选择一般来说有自己开发、商业工具和开源工具三种选择。第三方工具包括已经成熟的商业软件和开放源代码的开源工具，它们都是经过证明的可以放心使用的工具，但是最主要的不足之处在于它们往往为了通用的考虑，按照自己的理解标准化了流程，并且价格不菲。但是对刚起步的中小企业来说，购买和使用这样的通用工具而只使用到其中一小部分功能，甚至有些有自己项目组特色的东西还得不到支持，往往不是最合理的选择。 随着近些年测试自动化的呼声越来越高，如何将自动化测试的效率提高到应有的水平，成了各个测试机构首要考虑的问题[2]。我们认为，先进的测试管理流程与一流的自动化测试工具包是实施自动化测试不可或缺的。为更好的对测试流程进行控制，使之能充分利用自动化测试带来的好处，现代测试管理系统应该能支持自动化测试。 结合公司的实际情况，我们选择了自己开发和开放源代码相结合的方式，并采用缺陷跟踪驱动测试的模型开发出了自动化测试管理系统atms(automatic testing and management system)来作为支持自动化测试的基础设施。 本文分析了atms的体系结构和各部分组成，并对其中一些关键技术进行了讨论。 2 体系结构 现在基于源代码的软件测试工具已经开始被业界广泛使用，以求提高软件的可重用性，可维护性等质量属性，由于本项目组的软件自动化测试才刚起步，atms应该能和以后可预期的测试过程的进一步完善和需求的变更同步，这样，atms在设计之初就应该有良好的可扩展性和可重复性。 atms在逻辑上采用了以中心数据库为核心的体系结构，atms目前分为测试文档管理系统、缺陷跟踪管理和自动化测试支持系统三大部分(体系结构图如图1所示)，为了降低它们之间的耦合性，它们都通过共同的中心数据库进行交互，以后要进行扩展的话只需要围绕中心数据库进行操作即可。 图1 3 测试文档管理系统 软件测试文档是指导和管理软件测试过程的重要依据，测试文档包括测试计划、测试进度、测试用例、缺陷管理文档、进度报告等。这里介绍atms中我们主要分为测试用例管理和测试文档管理(包括测试计划，测试进度等测试文件的模板)。 3.1 测试用例组成 atms中用例分为三个部分，用例逻辑、用例数据和用例代码。其中用例逻辑和用例数据是文本格式，由用例管理系统负责创建；用例代码由自动化支持系统在cppunit中创建，它是自动化运行的基础。它们的关系如图2所示。 图2 3.2 测试用例存储和执行结果 为更有效组织这些测试用例，采用测试用例数据库进行集中管理。这样就可以按照测试阶段和被测模块清晰地组织测试用例，并可以按照用户的不同查询条件显示不同的数据信息(如测试用例执行状态，执行结果，时间等)。 3.3 测试用例的维护 为保证测试用例库中测试用例的有效性，必须对测试用例库进行维护。包括如下四个方面： 删除过时的测试用例 因为需求的改变等原因可能使一个测试用例不再合适被测系统，这时就应该将其删除。 删除冗余的测试用例 如果存在两个或更多测试用例针对一组相同的输入和输出进行测试，那么就是冗余的，它们的存在会降低回归测试的效率，需要定期进行 添加新的测试用例 如果发现某个关键接口还没有被测试，就应该开发新的测试用例重新对其进行测试，并将新的测试用例合并到测试用例库中。 3.4 测试文档模板管理 为有效进行软件测试管理，在项目准备阶段创建测试过程中用到的各种管理模板，项目测试执行过程中填充和更新模板内容，这样可以保证不会遗漏重要测试内容并保持文档格式一致性。 目前atms中存在如下模板： 测试用例模板(测试用例逻辑部分) 每日进度模板 4 缺陷跟踪数据库 缺陷跟踪数据库dtd(defect tracking database)，是对软件缺陷进行系统管理和跟踪控制的数据库，它记录软件测试、缺陷修正和验证过程的全部缺陷的处理信息，atms中的测试是以它为驱动进行的。 atms中，对缺陷进行跟踪管理，确保每个被发现的缺陷都能够及时得到处理是测试工作的一项重要内容。每个bug都有它的生命周期，从被报告开始到被解决结束。在这个生命周期中它在不同状态中转换。在atms中，我们为缺陷设计了如下缺陷跟踪管理状态模型。 4.1 缺陷报告 标识一个缺陷的时候，能正确给它分配严重程度、可视性和优先级别是很重要的。其中严重程度标识了一个bug对系统执行的破坏度，可视性是哪个能观察到这个bug，优先级别标识bug何时修复。 表1、表2和表3分别标识了严重程度、可视性和优先级的可能值。 表1 严重程度 描述 0 待分配 1 致命---系统崩溃或者不可修复错误 2 严重---功能没有实现 3 一般---功能实现错误 4 轻微---文档/拼写错误 5 待观察----不能重现的错误 6 正常-----系统正确功能，非bug 表2 优先级 描述 0 待分配 1 必须马上修改 2 尽快修改 3 有空时修复 4 可修复可不修复 表3 可视性 描述 0 待分配 1 超过75%客户可能面对这个bug 2 25-74%客户可能面对这个bug 3 10-24%客户可能面对这个bug 4 低于10%客户可能面对这个bug

　　4.2 缺陷处理 每当一个bug被处理完成的时候，atms将给它分配一个处理码，表4是系统所有结束码列表。 表 4 结束码 (解决途径) 解决 与否 详细描述 设计一部分 解决 非bug，是系统设计组成部分 不能修复 解决 由于时间，花费等别的限制暂时不解决 被报告人取消 解决 报告人认识不是bug，取消报告 延期 否 暂不修复，以后再修复 重复的 解决 和现存bug重复 已解决 解决 bug被修复 不可复现 否 开发人员不能复现这个bug，需要重新定义bug路径 需要更多信息 否 bug报告中信息不足 4.3　dtd的功能与组成 dtd的功能与组成如图3所示。

　　图3 缺陷跟踪系统模块组成图

　　各模块详细说明如下： 报告模块。用于软件测试人员向数据库报告新的缺陷。 权限控制模块。为测试人员、开发人员和项目管理人员分配不同的权限，如浏览、报告、修改、查询、统计、分析、删除、备份等。 分析模块。统计和分析满足条件的缺陷，输入分析结果；分析结果可以存成文件，可以包括数据、文字、表格和统计图形等内容。 备份模块。备份当前缺陷跟踪数据库的缺陷；全部备份或者备份满足条件的缺陷。 查询模块。根据查询条件，查找满足条件的缺陷；包括简单条件查询和复杂条件查询。 修改模块。用于开发人员和测试人员更新缺陷状态信息；开发人员验证报告的缺陷，修改缺陷，更新修改缺陷的信息；测试人员补充缺陷内容，验证和关闭修正的缺陷。 5 缺陷跟踪数据库的缺陷管理 缺陷跟踪数据库(dtd)是一种可以提高缺陷处理效率的工具，要充分发挥它的作用，需要对缺陷跟踪数据库进行有效的管理[3] 。 5.1 角色和权限划分 使用dtd的用户有多种类型，而且他们使用的目的关注的内容也各不相同，为更有效地对dtd中每个缺陷进行正确处理，保证缺陷处理的客观性和安全性，我们对不同的使用者分配不同的缺陷处理权限。 默认情况下，数据库有四个组，测试组、质量保证组、修正缺陷组、项目管理组。可以根据需要随时添加和减少这些组的成员。 各组对应权限如表5所示。专有权限是本组成员才有的权限，公共权限是每个使用缺陷数据库的人员都有的权限。 表5 5.2 缺陷数据分析和显示 本系统具有较为强大的数据统计分析能力，以基于缺陷跟踪数据库的bug信息作为分析的数据来源，以表格和图形的形式表现缺陷的分布情况，并且可以选择统计和分析的频率(每周或者每天)。目前实现的有如下三种。 (1)测试团队每天报告的新缺陷统计和分析。 (2)不同测试人员的缺陷数量统计。 (3)缺陷严重级别和缺陷类别统计与分析。 由于我们采用的是中心数据库的体系结构，当需要以别的方式体现缺陷的分布情况时只需要更改图的表示层就可以，而逻辑和数据库层无需更改。 6 自动化测试支持系统 自动化测试是管理和实施各种测试活动的一种方法，即测试用例的设计，测试脚本的开发和执行，并借助自动化工具来验证测试需求[4]。而缺陷回归是我们软件开发和缺陷管理中的主要问题，也是测试中不可避免的话题。对现有功能更新的同时，也影响原有的行为，这是造成bug的主要原因，避免这一问题的主要解决方法是构建自动化的测试，实现回归测试。 回归测试我们可以采用商业工具、开源工具和自己开发，考虑到开发周期和与本系统的兼容，我们在多种选择方案中选择了在atms中内嵌开源自动化测试工具cppunit[5]的方法来支持自动化测试，由于cppunit是个开放源代码的工具，这使得我们可以通过修改其源代码使之符合我们的需要，在本系统中，当每次cppunit自动化测试完成之后，我们加入引导，把相应的运行结果写入atms指定的中心数据库中，同时指示atms有新的数据更新。这样由于atms和cppunit共用相同的中心数据库，能够达成数据上的一致性，并完成所需交互。其数据流如图4所示。 图4 从图4可以看出，当做自动化测试的人员拿到需要自动化的用例的文本描述后，将其按照cppunit的规范写成可以在cppunit框架下运行的用例代码。然后和需要的用例数据一起通过cppunit自动运行，结果自己写到系统的中心数据库，这样，别的模块就能任意查询所需结果。 7 结束语 随着我国软件业的发展和各公司测试管理过程的进一步完善，作为软件质量保证的重要组成的软件测试也越来越受到重视，如何在软件开发项目中有序地管理和分析各种问题对质量控制和过程改进也将越来越重要。本系统支持缺陷驱动的测试过程，但是对自动化的支持还比较肤浅，只是在现有cppunit的基础上做了一些整合，这个是以后需要改进的地方。我们也相信，由于软件自动化测试能显著提高软件测试的有效性和效率，将在越来越多的软件测试管理工具中得到支持。 参考文献 [1] ron patton 著。软件测试。周予槟，姚静等译。机械工业出版社，2002 [2]崔启亮著。国际化软件测试。电子工业出版社 2006.4 [3]孙建。软件测试工具的研究与建立。浙江大学，2006 [4]sam guckenheimer。 the revolution in software testing。 rational software。 2002 [5]james newkirk robot c。 martin。 extreme programming in practice中文版。人民邮电出版，2002年6月出版

自动化测试范例篇4

　　自动化测试就是希望能够通过自动化测试工具或其他手段，按照测试工程师的预定计划进行自动的测试，其目的是降低测试的劳动量，达到提高软件质量的目的。涉及到测试流程、测试体系、自动化化编译、持续集成、自动测试系统以及自动化测试等方面。

　　一、 软件测试自动化的概念

　　软件测试自动化就是执行用某种程序设计语言编制的自动测试程序，控制被测软件的执行，模拟手工测试步骤，进行全自动或半自动测试。全自动测试指在自动测试过程中，根本不需要人工干预，由程序自动完成测试的全过程。半自动测试指在自动测试过程中，需要由手工输入测试脚本或选择测试路径，再由自动测试程序按照人工指定的要求完成自动测试。

　　为保证软件的质量，必须按照软件工程的方法，在软件生命周期的各个阶段进行有效的管理和度量，软件测试是软件生命周期的重要阶段。目前软件测试普遍采用传统的测试方法，即白盒测试和黑盒测试。在测试工具上大多采用手工测试，或编制一些简单的测试程序进行测试，既耗时间又不规范。更大的隐患在于当将软件分发给用户使用时，常常会发生问题，严重时导致系统瘫痪。自动测试技术目的在于消除手工测试中人为的错误，加快测试循环，有效利用资源，提高工作效率。同时，使测试具有一定的规范性，提高测试的可重复性。

　　二、软件测试与自动化的联系

　　测试是一种技术。根据IEEE的定义，软件测试是使用人工或自动手段来运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果和实际结果之间的差别，尽可能发现存在的缺陷。它的目标是以较少的测试用例、时间和人力找出软件中潜在的各种错误和缺陷，以确保系统的质量。

　　自动测试也是一门技术，但与测试技术有很大不同。自动化测试是利用策略、工具以及产出等，减少人工介入到非技术性、重复性、冗长的测试活动里，从而达到无人监守完成测试，并自动产生测试报告，分析测试结果等一系列活动。自动化测试的目标是对被测试系统进行自动测试。总的来说，自动化测试的目的就是用较少的开销，获得彻底的测试，并提高产品的质量。

　　软件测试是由一系列有序活动组成的，始于测试计划，着重测试开发。软件测试自动化是针对这一系列活动及其管理的自动化，包括软件测试过程规范管理的自动化和软件测试活动的自动化。

　　无论自动测试还是手工测试都不影响测试的有效性，即测试的有效性和测试方式无关。测试脚本的设计与选择和测试质量有着直接关系，好的测试脚本方案应该可以以有限的数量发现软件中的大部分缺陷。因此选择何种测试脚本进行测试十分重要。实验和经验表明随机选择测试脚本并不是测试的有效方法，好的测试方法应该是开发好的测试脚本。

　　什么样的测试脚本是好的测试案例？有四个特性可以描述测试脚本的质量，它们分别是有效性，可拓展性，经济性和可维护性。监测软件缺陷的有效性是最重要的一个方面。好的测试脚本应该是可拓展的。可拓展性的意思是，这个测试脚本可以测试多项内容，这样就有效减少了测试脚本的数量。另外还应从成本出发去衡量一个测试脚本的经济性，包括测试脚本的执行、分析和调试是否经济，以及测试案例的可维护性，即每次软件变更后修改测试脚本的成本。

　　通常对这四个方面要进行平衡。例如，一个测试脚本可以覆盖到很多的测试内容，但要其执行和调试的成本可能很大。可能在每次软件变更后需要对测试脚本进行大量的维护。一次高拓展性可能导致经济性和可维护性比较低。因此测试技术不仅要保证测试脚本具有发现缺陷的高可能性，而且还要保证测试脚本的经济性，避免过高的执行、分析和维护成本。

　　对于手动测试脚本来说，无论测试执行的次数是多少，其经济性和可修改性都不会发生变化。然而对于自动化系统测试来说，在该测试第一次被执行时，其经济性和可维护性都比手动测试脚本要低，但伴随着测试的持续反复执行，自动测试的经济性迅速增长，可维护性也伴随着提高，当一个测试需要被重复执行时，自动化系统测试开始显示它的价值。自动测试的方法越好，长期使用获得的收益越大。

　　三、 测试自动化的现状

　　目前对于软件自动化测试主要有如下几种方法：

　　1、手写静态测试自动化方法 该方法应用静态的测试脚本和固定的测试脚本在被测应用的GUI上运行。这种自动化实际上只是体现在测试执行过程中，并且脚本需要反复调试，健壮性差。

　　2、随机输入自动化测试方法 这种方法的原理是让计算机模拟真实用户去进行各种GUI操作，只不过是测试过程本身涉及的行为是随机产生的，顺序也是随机产生的，它虽然可以发现一些测试人员无法发现的缺陷，但机会是很偶然的，因为测试程序本身并不知道对于它所产生的每一步操作及被测软件系统应该是如何反应的。

　　3、基于捕获/回放（C/P）机制的测试自动化方法 这种方法的本质是由测试人员与包含被测GUI的软件系统进行交互，基于C/P的工具负责将交互过程的场景和GUI操作捕获，生成测试脚本，再将这些操作进行回放。其优点是脚本生成相对容易；但是缺点也很明显，交互过程对测试人员的操作要求极高，并且脚本的可重用性非常差，对于回归测试过程无法提供有效支持，这些缺点使得该方法无法完美解决GUI测试的主要问题。

　　4、基于模型描述的自动化方法 这种方法的关键是对被测系统的行为进行形式化表述，形成模型，然后采用有穷状态机FSM （ Finite State Machine）从模型中产生测试脚本。通过这种方法产生的测试脚本可以有效的测试系统的具体行为是否满足系统设计要求，同时可以根据测试标准有选择地进行测试脚本生成和运行，但是缺点在于目前的系统规模越来越大，对于系统行为的模型描述越来越困难。这也是为什么这种方法一直无法在业界推广的一个主要原因。

　　四、测试自动化的挑战

　　伴随着开发及软件所使用的技术的更新，软件测试正面临新的机遇与挑战，图形用户界面GUI、分布式处理和庞大的分散网络就是这些新技术的代表。

自动化测试范例篇5

　　关键词：软件技术；软件测试；自动化测试

　　软件的质量就是软件的生命。随着软件产品的应用范围越来越广、功能越来越复杂，软件质量的管理也越来越困难，虽然人们在进行软件开发的过程中使用了许多有效的分析、设计和实现方法，但仍然不能避免出现各种各样的错误，因此，采用更加切实有效的方法发现软件产品中的错误和缺陷将成为软件测试人员的首要任务。现阶段可以采用的软件测试方法包括人工测试和自动化测试，人工测试就是测试人员模拟用户对软件产品进行操作，从而发现软件的功能和性能与用户的需求不一致的地方，即软件缺陷。软件的自动化测试就是使用自动化测试工具或手段，按照测试工程师的预定计划自动实现多次重复测试，并分析测试结果。采用自动化的测试方法可以大幅度地提高测试的效率，具有良好的可操作性。

　　1.自动化测试方法

　　1.1最初的软件自动化测试技术

　　最初的软件自动化测试技术出现在20世纪90年代初期，主要采用硬件方式来录制键盘输入和操作过程，然后通过播放实现重复的测试过程，在一定程度上提高了测试的效率，但是不能实现检查点的功能，即不能针对某个功能点进行功能和属性的检查。在这种模式下，记录操作过程的脚本和所操作的数据是混在一起的，因此维护的成本很高。而且，一旦界面进行了简单的变化，从前的脚本就完全无法使用，必须重新录制，这种方式不但使脚本的使用率降低，而且也降低了整个测试工作的效率。

　　1.2基于数据驱动的自动化测试技术

　　在20世纪90年代后期，随着软件测试技术的不断发展，使得录制和播放测试脚本的功能由硬件实现转变为软件方式实现，并且增加了检查点的功能，即可以通过对某个功能实现所涉及的参数值或者属性值与预期值进行比对来判断该功能是否正确实现。

　　这种技术与最初的自动化测试不同的是可以实现从数据文件中读取数据，数据和操作过程脚本实现了分离，被称为基于数据驱动的自动化测试技术。它将输入数据、预期输出组织成表，表中的一行数据就对应着一次测试过程，测试时从表中一行一行的读取数据，然后通过变量的形式传入事先录制好的或者是手工编写的测试脚本中，这样利用相同的测试过程测试不同的输入、输出数据的组合。这种方法对于具有很多不同数据作为测试用例的被测系统来说是非常有效的。

　　1.3基于关键字驱动的自动化测试技术

　　基于关键字驱动的自动化测试技术的应用开始于2001年，是基于数据驱动测试技术的扩展，关键字驱动的自动化测试用自然语言来描述测试用例，将测试脚本抽象化，使不懂任何代码的非技术人员，也可以使用测试工具进行测试。基于关键字驱动的自动化测试用关键字组成测试的业务逻辑，其主要思想是：脚本和数据实现分离、测试描述与具体实现细节分离、界面元素名和测试内部对象名现分离。主要关键字包括：作对象（Item），操作（Operation）和价值（value），用面向对象形式可将其表现为Itern。Operation（Value）。

　　1.4基于领域驱动的自动化测试技术

　　基于领域驱动的自动化测试是在关键字驱动测试的基础上发展而来的，主要特点是：从领域模型出发，使用被测软件产品的领域语言描述测试用例，进行建模，并对测试用例和领域关键字进行分析、设计、开发和组织管理，从而进行有效的测试。领域驱动的自动化测试优点如下：（1）测试用例用领域语言描述，易于理解：（2）测试用例可以通过将领域关键字和设置参数进行组合来得到；（3）当被测软件产品的实现方式发生变化时，可以更新领域驱动测试库以适应新的变化，测试用例不需要做任何修改。

　　1.5基于功能驱动的自动化测试技术

　　基于功能驱动的自动化测试技术首先将整个系统划分为多个独立的模块，在执行自动化测试时首先要实现每个模块的自动化测试，每个模块都是一个可实现的测试载体，每个测试体被实现为一个包含测试信息的测试函数，代表着一个独立的测试用例，并可以根据需要调用代表一个独立功能模块的应用模块，读取驱动这些应用所需的测试数据。在应用模块中封装着所有对系统界面的操作和输入。由于应用模块代表独立的功能，所以对其进行维护也相对独立。

　　由于在整个基于功能驱动的自动化测试中，所有与被测软件系统有关的操作及属性，都被封装在每个应用模块脚本中，当系统界面变化以后，只需去修改被影响的应用模块的脚本，其他脚本可以保持稳定。

　　1.6基于指令驱动的自动化测试技术

　　基于指令驱动的自动化测试是基于数据驱动自动化测试技术的改进，其整个过程所包含的功能都是由指令驱动的，可以支持由不同序列或多个不同路径组成的测试。指令驱动的自动化测试建立在数据驱动自动化测试方法之上，但是表中存放的不是数据，而是指令，其独立于执行测试的自动化工具，是对数据驱动的自动化测试的有效改进，也是到目前为止，被学术界认为是比较理想的自动化测试。

　　2.使用自动化测试的误区

　　软件的自动化测试技术具有良好的可重复性和高效率等优点，但也有一些局限性，下面来分析一下人们在使用自动化测试的过程中存在的一些误区。

　　2.1采用自动化测试能够完全取代手工测试

　　在很多情形下，软件系统的测试过程必须由人来进行控制，只有当上一个步骤执行完毕，才可以根据执行结果判定下面如何执行，或是输入哪些测试数据，这样的决策必须由人来做出，机器是无法完成的，所以不能期望在所有的情况下都使用自动化测试来取代手工测试。

　　2.2能够对易用性方面的属性进行测试

　　因为工具本身不具有审美观和想象力，所以对于一些界面美观和易用性方面的测试无法作出判断，也就无法实现自动化测试。

　　2.3只要使用自动化测试就能缩短测试时间、提高测试效率

　　要采用自动化的测试方法，必须在测试执行之前花费更多的时间搭建测试环境、录制脚本、建立数据表格并输入数据等等，与采用手工测试相比，要花费5～10倍的时间来开发一个自动化测试用例。因此如果不能增加~外的资源和时间，不可能进行大量的投入来搭建自动化测试框架，对于规模较小，测试用例较少的被测软件系统来说采用自动化测试反而会增加测试时间、降低效率。

　　自动化测试工具采用图形化界面，操作容易掌握，对测试人员的技术要求不高。“录制/回放”的方法操作简单容易掌握，但是并不能实现有效的、长期的自动化测试，要想根据被测系统的特点来创建有效的自动化测试脚本，测试人员必须能够熟练掌握脚本语言，可以对脚本进行编辑和优化，最理想的测试人员是既有编程经验，又有测试经验。测试过程中，测试人员要对测试脚本库中的脚本实时进行维护。

　　3.不适合自动化测试的情况

　　软件的自动化测试技术虽然具有较好的可重复性、高效率等优点，但是并不适合测试所有类型的软件产品。以下情况不适合采用自动化测试方法。

　　定制型软件项目：有些项目是根据客户要求定制的，其维护阶段是由客户自己承担的，而且有些定制型项目采用的开发语言、运行环境也是客户方特别要求的，这就使得公司里对这个项目所积累的测试信息很少，所以这样的项目不适合做自动化测试。

　　周期很短的项目：如果项目的开发周期短，那么测试周期就短，就不值得花费精力去投资自动化测试，即使有足够的时间和资源搭建好测试环境，建立好测试脚本，但是不能得到充分的重复利用，也是不可取的。

　　业务规则复杂的软件产品：如果被测软件系统具有复杂的业务规则，有很多逻辑关系、运算关系，那么就必须由人来参与，工具就很难实现测试。

　　易用性、美观性和声音等方面的测试：与人的感受、感官和体验有关的测试，包括系统界面的美观性、声音的效果、系统的易用性的测试只能由人来实现，机器是无法完成的。

　　很少运行的软件系统：采用自动化的测试技术就是让软件不厌其烦地反复运行，以此来提高测试效率，很少运行的软件使用自动化测试就是一种浪费。

爱可网分享地址：http://www.ik35.com/wm/97135.html