自动化测试
自动化测试范文第1篇
关健词：自动化测试；手动测试；优势；误区；困难
中图分类号：TP39 文献标识码：A 文章编号：1007-9599 （2012） 17-0000-02
如今自动化测试以其执行速度快，结果反馈迅速的最大优点获得了业界的广泛认可，尤其在如今需求快速变化的今天，大家对于自动化测试的需求和渴望更是到了一个空前的地步。诚然，自动化测试受到大家的追捧是有充分的理由，因为相对于人工测试，它有着不少的优势。我们且来看看。
1 自动化测试的优势
1.1 对程序的回归测试更方便
回归测试可能是自动化测试最主要的任务，特别是在程序修改比较频繁时，效果是非常明显的。由于回归测试的动作和用例是完全设计好的，测试期望的结果也是完全可以预料的，将回归测试自动运行，可以极大提高测试效率，缩短回归测试时间。
1.2 可运行更多更繁琐的测试
自动化的一个明显的好处是可以在较少的时间内运行更多的测试。而且人工测试在面对多轮重复执行时，测试人员往往会趋于倦怠，而这将对产品的测试质量带来其他的损害
1.3 可以执行一些手工测试困难或不可能进行的测试
比如，对于大量用户的测试，不可能同时让足够多的测试人员同时进行测试，但是却可以通过自动化测试模拟同时有许多用户，从而达到测试的目的。
1.4 更好地利用资源
将繁琐的任务自动化，可以提高准确性和测试人员的积极性，将测试技术人员解脱出来投入更多精力设计更好的测试用例。有些测试不适合于自动测试，仅适合于手工测试，将可自动测试的测试自动化后，可以让测试人员专注于手工测试部分，提高手工测试的效率。
1.5 测试具有一致性和可重复性
由于测试是自动执行的，每次测试的结果和执行的内容的一致性是可以得到保障的，这样使测试结果具有可对比性，并且达到测试的可重复的效果。
1.6 测试的复用性
由于自动测试通常采用脚本技术，这样就有可能只需要做少量的甚至不做修改，实现在不同的测试过程中使用相同的用例。
1.7 增加软件信任度
由于测试是自动执行的，所以不存在执行过程中的疏忽和错误，完全取决于测试的设计质量。一旦软件通过了强有力的自动测试后，软件的信任度自然会增加。
因为自动化测试现在如旋风之势席卷而上，特别是全球风靡于敏捷开发之后，更是把自动化测试提高到了一个史无前例的高度。而且人工测试具有更敏锐的观察力，能从一个稍纵即逝的小异常中挖掘出大问题。
另外有些测试是必然需要人工干预的，如冷启动机器，如需要人的感官去体验的。那么如果真的需要追求100%的自动化测试覆盖率，我们唯一的选择就是牺牲这部分的测试案例来成全100%，这对于测试覆盖率也是很大的一个损失。
而从投入产出比的角度来看，以目前对各组织的统计而言，60%是一个比较合理的值，如果要高于这个值，那么付出的人力将是成倍增长的。在我们的组织中一度自动化测试覆盖率的要求是95%，曾经我们也勉强达到，但是投入的代价是不可维续的。所以我们过后调整了我们的合理期望值。比如说在比较简单的功能性测试中自动化测试是比较容易的，但如果是涉及模块和网元很多的系统测试或互通性测试中就显得相当的力不从心了。
2 自动化测试是适用于任何情况的
2.1 自动化测试是适用于任何产品的
并不是所有的产品都适用于自动化测试的，如果这个产品只会做有限的几轮测试，接着就不会再有持续的开发。那么就没必要使用自动化测试，因为这样的投入产出比比较低。毕竟在开发自动化测试阶段需要耗费大量的人力物力。对于决定自动化一个测试用例的一般规则是这个测试用例必须被运行 4 次以上。这个数字是基于用户对测试工具有良好的技能并且有一个良好的测试框架的。如果情况不是这样的话，整个数字能够是 10-20次或者更高。
再者如果变化比较大的话也不适用自动化测试。国内多数软件公司是针对最终用户进行项目开发—工程性质的软件，而不是产品开发。项目开发周期短，不同的用户需求不一样，而且在整个开发过程中需求和用户界面变动较大，这种情况下就不适合自动化测试，对于不停变化的需求和界面，可能修改和录制脚本的工作量大大超过测试实施的工作量，运用测试工具不但不能减轻工作量，反而加重了测试人员的负担。
2.2 自动化测试是适用于任何测试阶段的
版本经理通常认为自动化测试能运用于任何阶段的万能钥匙，但事实上从本人的经验来看，自动化测试适用于回归测试，但不适用于新功能的测试。首先因为新功能刚递交之时稳定性是不可保证的。而自动化测试对于其不稳定性是相当敏感的，所以通常都无法正常的运行完测试，也无法达到我们尽快得到结果的预期。其次在新功能刚递交时其期望结果是不可预知的，这对于自动化测试脚本的编写带来了极大的不确定性。最后在新功能递交阶段是需要我们发现大量问题的时候，而自动化测试无法担此重任。
2.3 自动化测试是适用于任何组织的
在最初尝试自动化测试的时候，是需要投入相当的人力和物力去选择自动化工具，构建自动化测试的框架，做必要的技能培训，摸索编写自动化测试的脚本，如果一个组织无力承负这样的代价，那么是不适合自动化的，否则只能是半途而废的下场。
即使我们澄清了这些误区，我们对于自动化测试有了一个比较清晰的认识，也对其有了一个正确的期望，但实际在推行的过程中我们还是会遇到不少的困难，而困难主要来自于以下几个方面。
3 自动化测试推广中的困难
3.1 来自于测试人员的不接受
因为测试人员是自动化测试的主体，他们承担着转型的重要职责，所以他们的接受与否对于工作的展开是尤为重要的。但作为一个新生事物，通常是不太容易被接受的，尤其是在大家觉得原有的模式很舒服很习惯的情况下。所以在最初的阶段完全是强推。而经过一年的努力，当作年终总结时，所有的测试人员都说那年最艰难的是自动化测试，感触最深的是自动化测试，从中学到最多是是自动化测试，而且发现自动化测试的确帮了很大的忙。
3.2 来自于测试人员技术上的不足
测试人员很多都不具有编程的经验，但自动化测试脚本的编写还是需要一定的编程功底，如果组织中专门有一个具有编程功底的团队能开发自动化测试的工具，并且根据手动的测试案例编写自动化测试的脚本，那状况可能会好些。但目前更多的组织是需要人人能编写自动化脚本的。而在我们的转型中我们经历了三个阶段，基本完成了能力的建设。第一阶段以能用为目的，专门有人提供所需的函数，测试人员只需调用这些函数完成自动化测试的目的，不需要考虑程序的可移植性，可复用性。第二个阶段每个人会写一些自己所需要的函数，并且具有良好的移植性和灵活性。第三个阶段每个人会写能为他人复用的函数并且遵循制定的规范。这样的转型虽然慢但却是比较稳妥的方式。
3.3 来自于组织内其他人员的阻挠
自动化测试范文第2篇
软件定义的模块化测试系统成为行业主流技术
当今的电子产品(例如iPhone)不但集成越来越多的功能，而且越来越依重于通过软件去定义产品功能。同样，在产品设计和客户需求日益复杂的今天，用于测试测量的仪器系统也越来越突出软件定义的作用。通过软件定义硬件的功能，用户能够更快更灵活地配置测试系统，并满足不断改变的测试需求，例如，同一个数字化仪可以实现示波器，频谱分析仪和视频分析仪等不同的功能。此外，通过软件还可以自定义更加友好的人机界面。
同时，为了实现对电子产品所集成的多种功能进行测试，同时也为了达到更好的灵活性和可升级性，测试系统正逐渐朝着模块化、小体积的方向发展，也就是将复杂的测试系统简化成模块化的硬件和软件去逐一实现，需要增加测试项目时只需增加相应的功能模块即可满足未来的升级需求。
基于这两个发展方向，以软件为核心的模块化仪器技术应运而生，并成为测试测量行业最重要的发展趋势和主流技术。相比于传统仪器固定的功能配置和只是对“测试结果”的呈现，以软件为核心的模块化仪器技术赋予用户更多自定义的测量功能。基于商业的高速总线(例如PxI／PxI Express)可以确保大量原始数据的传输；一旦获取了原始数据，就能发挥软件的强大功能，对原始测量数据进行自定义处理、分析、显示、报告生成或数据存储。例如，利用软件配置模块化射频仪器，井结合自定义的软件调制与解调，就能在同样的硬件平台上实现多种无线协议的测试，这也正体现了我们所说的软件无线电的概念。
以软件为核心的模块化仪器五层架构
具体而言，一个细化的以软件为核心的模块化测试系统架构如图1所示。
现在许多企业都以该架构为标准构建测试系统。
・结构层次五：系统管理软件
系统管理软件层位于五层架构的最高层。对于一个自动化测试系统，有些测试任务会根据待测设备(DUT)的不同而不同，如仪器配置、结果分析等；而有些对于所有的待测设备则是通用的，如测试流程的管理、测试报告的生成等。测试管理软件的作用就是将通用任务分离出来，通过专业的软件服务创建测试流程、集成报告生成和数据库管理等功能。专业测试管理软件(例如NI TestStand)除提供上述功能外，还内建了并行和自动协调测试工具，可以帮助用户大幅提升测试效率，增加系统吞吐量。
结构层次四：应用开发软件
应用开发软件在测试架构中扮演着承上启下的作用。系统开发者需要借助它实现具体的测量应用程序、向最终用户显示必要的信息以及连接其他应用程序；同时测试开发软件需要通过设备驱动程序与I／O连接。不仅如此，用于开发测量应用的软件，还需要集成强大的数据分析和再现功能，并且是具有长生命周期的主流软件。NI的图形化的编程软件LabVIEw为用户提供了高效而直观的测试测量应用程序开发工具，满足所有上述需求。对于习惯于文本编程的用户，基于ANSI C的LabWindows／CVI和基于Microsoft Visual Studio的Measurement Studio也是不错的选择。
结构层次三：系统服务和驱动
系统服务和驱动层是连接软件开发环境和硬件设备的纽带。除了起到设备驱动的作用，这一层应该包含更多关于硬件配置管理、诊断测试等功能。例如，NI Measurement andAutomation Exployer(MAX)软件可以帮助开发者对所有的NI硬件和通过总线相连的众多传统仪器进行统一的自动检测和配置。系统服务和驱动还通过应用编程接口(API)提供了对应用开发软件层的集成，这样开发者可以很容易的实现设备的编程，从而提高开发效率，减少维护成本。
结构层次二：处理总线平台
仪器总线种类很多，每一种都有其适合的应用，例如，GPIB总线目前还是最常见的台式仪器控制总线；LAN／LXI总线特别适合于分布式的系统。为了发挥不同总线的优势，达到系统性能的最优化，许多测试应用都基于混合总线测试系统。作为一个开放的、基于PC技术的测试测量平台，PXI和PXIExpress提供了业界最好的数据带宽性能和背板集成的定时和同步功能，以其作为核心总线不会成为整个混合系统的传输瓶颈。同时PXI和PXI ExpressNl有和多种其他总线互连的软硬件接口支持，使其成为混合总线测试平台核心总线的理想选择。
结构层次一：仪器和设备I／O
作为系统架构的最底层，仪器和设备I／O层将直接接触到实际的物理信号，完成信号调理、A／D和D／A转换等工作。模块化的I／0主要是基于PxI和PXI Express,总线的仪器，现在，有超过70家厂商提供超过1500种的PxI模块化仪器，其中包括Agilent、Rhode＆Schwarz，Keithley和NI在内的众多知名公司，产品覆盖从数字化仪、信号发生、RF、电源到开关模块等各种I／O模块。基于模块化的软件架构和PXI／PXI Express为核心的控制模块，用户还可以轻松地集成基于GPlB、usB、LA N／LX I等总线的传统仪器，保护原有投资价值。
自动化测试范文第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篇
【关键词】软件自动化测试；测试工具；应用
1.软件自动化测试的定义
软件自动化测试目前存在两种定义，第一，在不需要人的干预的情况下，运用自动化的测试工具进行自行测试。第二，对测试的执行使用软件来进行控制，主要包括测试预期输出和实际输出的效果的对比，测试是否已构建了前提条件等。第一种定义更着重于强调“自动化的测试工具”，要求在测试的过程中，不需要人的干预，只需软件进行运行。而第二种属于广义上的定义，它只是涉及软件，而非自动化的测试工具，并非绝对意义上的软件自动化测试工具。
2.软件自动化测试优点
2.1提高了测试效率
在软件测试中对于回归测试中的动作和用例是已经完全设计好的，同时可以完全预知测试期望和结果，从而可以极大提高测试效率，缩短回归测试时间。
2.2可以运行更多更繁琐的测试
许多不可能同时让足够多的测试人员同时进行测试的大量用户测试，实行自动化测试可模拟出同一时间的许多用户，更好的利用资源，同时达到测试的目的。
2.3具有一致性和可重复性
由于测试是自动执行的，每次测试的结果和执行的内容的一致性是可以得到保障的，从而达到测试的可重复效果。自动化测试还存在着复用性的优点，自动测试通常采用脚本技术，只需要对脚本做少量的甚至不做修改，实现在不同的测试过程中使用相同的用例。
3.软件自动化测试工具的分类
3.1白盒测试工具
白盒测试主要是从程序的内部结构出发设计测试用例，对程序所有逻辑路径进行测试，通过在不同点检查程序的状态，确定实际的状态，来测试产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作。其对应的测试工具也主要是直接对代码进行分析，针对程序代码、程序结构、对象、类层次等进行测试，测试中发现的缺陷可以定位到代码行、具体的某个变量。软件自动化测试中对白盒测试工具的选择主要应依据该工具对开发语言的支持力度、对嵌入式操作系统的支持力度、代码的覆盖深度及测试的可视化。
白盒测试工具可进一步细分为静态测试工具和动态测试工具。静态测试工具是不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。具有代表性的静态测试工具有Gimpel公司的PC－lint和Compuare的DevPartner Studio中的CodeRe view。动态测试工具需要实际运行被测系统，并设置断点，向代码生成的可执行文件插入一些监测代码，监测断点这一时刻程序运行的数据。具有代表性的动态测试工具有IBM－Rational公司的Purify，Pure Coverage，Quan lify和Compuare公司的Error Detect，Cover
age Analysis，PerformanceAnalysis。
3.2黑盒测试工具
黑盒测试是在已知产品所应具有的功能的情况下，通过测试来检测每个功能能否正常使用的测试工具。其基本工作原理是利用脚本的录制和回放，模拟用户的操作，然后将被测系统的输出记录下来同预先给定的标准结果比较。测试时完全不考虑程序内部结构和内部特性，它只检查程序功能是否按照需求规格说明书的规定正常使用，主要用于软件确认测试。黑盒测试工具的代表有IBMRational的TeamTest、Robot， Compuware公司的QA Center，MI公司的WinRunner等工具。
3.3对数据生成进行检测的工具
测试数据生成工具主要应用在测试的前端，为测试过程准备大量的可用数据。并且通过转化、析取、变换或捕捉现有数据作为依据，自动为测试程序生成可靠的测试数据。同时，可以通过配置工具配置数据生成的规则，并且有一个自动配置引擎，可以根据已经存在的数据库自动生成配置文件。目前典型的测试数据生成工具有：Bender＆Associates公司提供的功能测试数据生成工具SoftTest；Interna
tionalSoftwareAutomation公司提供的Panoram aC／C＋＋测试数据生成工具。
3.4对管理进行测试的工具
测试管理工具是指用工具对软件的整个测试输入、执行过程和测试结果进行管理的过程。测试管理工具通过一个中央数据仓库，实现测试人员、开发人员或其他IT人员在异地进行信息交流。从测试需求管理到测试计划、测试日程安排、测试执行到出错后的错误跟踪，实现了全过程的自动化管理，提高回归测试的效率、大幅提升测试时间、测试质量、用例复用、需求覆盖等。测试管理工具的代表有Mercury Interactive公司的TestDirector、IBM－Ra tional公司的ClearQuest。
4.软件自动化测试工具的实施程序
软件自动化测试在本质上与软件开发过程是一样的，都是通过自动化测试工具来实现。具体过程如下：
4.1分析进行测试的需求
不同的人员进行软件自动化测试时的目的往往是不一样的，比如测试人员、开发管理者等在进行测试时会存在安全测试、功能测试以及性能测试等方面的差异。此外，不同的测试工具具有不同的测试功能，所以，在进行测试之前，应对测试方案进行调查，收集需求，以选择适当的测试工具。
4.2对测试用例进行认真设计
测试用例主要是指关于测试目标的一系列测试，它有一定的顺序要求。在设计测试用例时应对测试时的输入值、标准结果、输出值等信息进行规划。
4.3对测试脚本进行编写
编写测试脚本的过程实际上是对具体的测试用例脚本进行转化，依据测试设计时的需要生成测试脚本，对于一些高度自动化的测试工具，则可以依据以前软件的运行情况来对测试用例进行自动录制。
4.4对实施过程进行测试
对实施过程进行自动化测试主要是依靠一定的测试支持系统进行自动化的控制和调度测试的过程。
4.5生成准确的软件测试报告
根据测试结果的分析，及时发现出现在产品中的问题的实质，找出解决对策，从而准确评估产品的质量，实现产品质量的提升。
5.结束语
目前软件技术得到了突飞猛进的发展，规模也日益增大，同时软件的复杂程度不断增加，要想提高软件自动化测试程度，就必须达到软件自动化测试工具的准确使用。目前自动化测试工具的种类非常多，我们在选择自动化测试工具时，要综合考虑各方面的因素，只有这样才能使得测试的质量和效率不断提高，降低测试所需要的成本，从而促进软件开发工作的快速发展。 [科]
【参考文献】
［1］黄茂生.软件自动化测试工具的评估与选择[J].电子质量,2007(12).
［2］李理,刘军.软件测试工具的选择和使用[J].警察技术,2006(4).
自动化测试范文第5篇
测试自动化的目标是对被测试系统进行自动测试，提高测试的效率和客观性。自动化测试过程中主要涉及的内容有下面几个方面。自动测试输入：工具录制测试者所做的所有操作,并将这些操作写成工具可以识别的脚本。测试脚本技术：用于自动测试过程中存放测试步骤、测试数据等相关内容。测试结果的自动比较：将预期输出与程序运行过程中的实际输出进行比较。自动测试执行：工具读取脚本并执行脚本命令，可以重复测试者的操作。在执行脚本过程中可以完成测试结果的自动比较。
2自动化测试系统的设计
通过对低速无线传感器网络协议的深入研究，分析软件测试、通信协议测试和自动测试等相关理论知识，本文提出将通信协议测试和自动测试相结合的方法，实现对测试过程自动执行和测试结果的自动分析，是本系统的创新点。如图2所示，虚线框内测试步骤可以实现测试的自动执行，其中可视化用例设计器、测试用例生成器完成测试用例的自动生成工作，测试用例的自动生成是测试自动执行的关键部分。测试结果分析器则对测试结果进行自动分析。测试用例的设计和生成是协议测试的关键和难点，如何生成最能发现被测协议存在问题的测试用例，如何用最少的测试用例实现足够大的覆盖率，是协议一致性测试的目标和难点。本文提出利用测试用例的自动生成来解决这一问题。测试用例自动生成主要依靠测试用例自动生成器是来完成，是实现测试自动执行的核心。其体系结构如图3所示，其中用例设计描述是文本文件，描述测试用例的特性，选择的算法不同，描述方式也会有所不同。如采用“基于形式规格说明的方法”用Z，VDM，OBJ，LARCH等语言描述，采用“组合覆盖方法”则用XML脚本描述，因为XML脚本的可扩展性比较强，所以在目前的自动化测试系统中得到较多的使用。算法适配器为算法提供接口，向上提供算法支持服务给描述解析器，向下兼容多种算法，兼容多种算法能增强体系结构的扩展性和适用范围。描述解析器在算法适配器基础上分析用例设计描述，将用例描述转换成用例生成器可识别的内部描述形式，并传递给用例生成器。用例生成器获得来自描述解析器的内部描述，根据描述自动生成可执行测试用例。可执行的测试用例支持多种形式存储，如内存存储、文本存储、数据库存储等，具体的存储格式随着测试执行的需求变化。
3一致性自动化测试系统的实现
为了验证体系结构的适用性和有效性，搭建了基于MicrosoftVS2010、SQLServe2005、“分类树方法”、GDI+(GraphicsDeviceInterface)来实现无线传感器网络协议一致性测试的自动化系统。其中GDI+完成系统中的可视化用例设计器工作，它是一个语法可控制的、可视化、图形化的编辑器，帮助我们更加有效地使用分类树方法进行测试用例的设计。分类树方法是黑盒测试中的一种部分测试方法，是一种有效的功能测试方法。分类树方法的基本思想是：首先逐层划分测试对象的输入域，然后将划分的独立的类结合为无冗余的测试用例，这些测试用例覆盖了整个输入数据域。算法适配器、描述解析器、用例生成器、分类树方法均使用MicrosoftVS2010实现。SQLServer2005降低了管理数据基础设施和发送观察和信息给所有用户的成本，并具有可信任，高效，智能的特点。因此本文将测试系统及被测试网络信息存储在SQLServer2005数据库中，用来在自动执行测试用例时调用并存放测试结果信息。自动化测试系统在实际应用时，首先用GDI+构建测试用例设计，也就是生成XML语言描述的用例说明，然后描述解析器解析该用例说明并生成测试用例模板（系统内部格式），由用例生成器生成可执行的测试用例，调用SQLServer2005中存放的测试网络信息和测试配置信息执行测试用例并生成测试报告。本系统中人工只参与第一步，即用GDI+技术构建测试用例设计，其余部分均自动完成，提高了测试工作的效率和客观性。该实现已应用于国家科技重大专项“信息汇聚传感器网络综合测试与验证评估环境”中，限于篇幅测试过程不再赘述，经过测试发现了一些隐藏的无线传感器网络协议一致性测试问题，提高了一致性测试有效性和客观性，也证明了本文所提出的一致性测试自动化方法的有效性和实用性。
4结语
