自动化测试-在软件测试中，自动化测试指的是使用独立于待测软件的其他软件来自动执行测试、比较实际结果与预期并生成测试报告这一过程。

自动化测试

在软件测试中，自动化测试指的是使用独立于待测软件的其他软件来自动执行测试、比较实际结果与预期并生成测试报告这一过程。 在测试流程已经确定后，测试自动化可以自动执行的一些重复但必要测试工作。也可以完成手动测试几乎不可能完成的测试。对于持续交付和持续集成的开发方式而言，测试自动化是至关重要的。

软件开发

核心行动

过程 需求 设计 工程 构造 测试 侦错 部署 维护

范式与模式

原型设计 净室 增量建模 瀑布模型 敏捷软件开发 螺旋模型

方法论与框架

快速应用程序开发 DevOps 极限编程 团队软件流程 个人软件程序 动态系统开发方法 MSF Scrum 广告牌 V模型 FDD MDD 迭代式开发 精实开发 统一流程

支持行为

配置管理 文档 质量保证 项目管理 用户体验

实践

ATDD 行为驱动开发 持续整合 持续交付 领域驱动设计 结对编程 站会 测试驱动开发

工具

编译程序 侦错器 性能分析 GUI设计器 建模 集成开发环境 组建自动化 发布自动化 测试

标准与知识体系

能力成熟度模型集成 IEEE标准 ISO 9001 ISO/IEC标准 SWEBOK 项目管理知识体系 BABOK

随着软件系统规模的日益扩大，以及应用领域的不断拓展，对软件系统的测试也变得更加困难和复杂，传统的人工测试的局限性也越来越明显。自动化软件测试技术可以克服传统测试技术的许多问题。自动化测试所依据的是一套严密的测试法则和评估标准，具有完整的自动测试过程。因此，它可以避免测试人员惯性思维所导致的测试疏漏，也可减少由于手工测试中繁复的重复工作所导致的人为差错。

概述

自动化测试的意义和优点

自动化测试（尤其是单元测试的自动化），是极限编程和敏捷软件开发的一个关键特征，这也被称为测试驱动开发（TDD）。单元测试的用例可以在代码编写完成之前就设计好，并作为功能的一种定义形式存在。随着新的代码不断完成编写，单元测试随之进行，缺陷被不断找出，因而代码也不断得到改进。 由于开发人员能够及时发现缺陷然后立即作出改变，修复的代价大大减小，这种不断发展的开发方式被认为比瀑布模型这类开发结束再测试的方式更为可靠。

使用单元测试框架（如JUnit、NUnit等“xUnit”类型测试框架）执行自动化测试是目前软件开发行业的大趋势。单元测试框架的应用使得各部分代码开发完成后立即进行相关单元测试来验证它们是否如预期在运行成为可能。

手工完成一些软件测试的工作(例如大量的低级接口的回归测试)十分艰苦耗时，而且寻找某些种类的缺陷时效率并不高，因而测试自动化，提供一种完成这类工作的有效方法。

一旦自动化测试方法开发完成，日后的测试工作将可以高效循环完成。很多时候这是针对软件产品进行长期回归测试的高效方法。毕竟，早期一个微小的补丁中引入的回归问题可能在日后导致巨大的损失。

自动化测试的局限性

尽管长期来看（尤其是针对回归问题的）自动化测试，可以带来开支上的节省，将所有测试短期内全部自动化还是可能产生巨大的开销，通常情况下业内采用手工测试和自动化测试相结合的方法完成测试工作。

尽管测试“自动化”了，但测试结果分析、测试脚本维护和编写仍然需要人力投入。

对于测试用例的要求

需要被自动化的测试用例大多是待测产品中每次修改代码都需要进行回归测试的重要部分。对这样的部分采取自动化测试手段后能大大减小手工测试消耗的人力物力。

对于测试人员的要求

由于在自动化测试中的测试用例和输出结果都由代码构成，测试工程师（或软件质量保证人员）必须具备软件编码的能力。不过某些测试自动化工具支持通过关键词指定测试步骤，因而免除了程序编写的过程，对测试人员而言也就不再要求他们掌握编程技术了。

对于团队的要求

自动化测什么，什么时候可以自动化，团队是否真的需要自动化——这三个问题是一个测试（或开发）团队必须做出的关键决断。来自52名从业者和26名学者的研究与评论中共同指出测试自动化应考虑五个关键因素：

被测系统、测试的数量和种类、测试的工具、人和组织的工作重心、交叉因素。

在上述研究中最常提及的独立因素是：

回归测试的必要性、经济因素、被测系统成熟度。

自动化测试的分类

测试自动化有许多途径，下面列出一些广泛应用的一般方法：

• 基于图形用户交互界面测试（GUI Based Testing）。基于用户界面（GUI）的测试使用能够产生图形用户界面操作（如出表点击、键盘输入等）的测试框架，模拟用户动作来以观察、验证程序是否正确的响应。
• 接口测试（又称基于API的测试，API Based Testing）。接口测试指的是通过调用接口（API）绕过GUI，，以应用到验证的行为进行测试。通常API动绕过测试的应用程序的用户界面。它也可以测试公共的接口，以类、模块或图书馆都经过测试，有各种各样的输入参数来验证返回的结果是正确的。

接口测试

条目：接口测试

接口测试是被广泛使用的软件测试方法之一，它使软件测试工程师能够忽略GUI的影响，对软件功能本身进行测试。它是程序逻辑测试中非常关键的一步。通常情况下在开发的早期阶段，接口测试就会开始执行来确保代码始终是准确无误的。

接口测试也作为集成测试的一部分，用于判断系统是否满足功能、可靠性、性能表现和安全性的要求。 由于接口测试不使用GUI，它主要通过字符方式与测试者进行交互。

图形用户界面(GUI)测试

许多测试自动化工具提供记录与回放宏的功能，这允许用户记录他们在交互式用户界面上进行的鼠标点击、键盘输入等操作。这样在之后的测试当中，播放宏便可以自动测试这些交互，与正常情况下的交互反馈进行对比便可完成针对GUI的测试工作。这种方法几乎不要求用户具有软件开发经验，并且可以应用于几乎任何具有GUI的应用程序。然而，这些特点也带来了一些可靠性和维护性问题：任何按钮的重命名或是移动都会让宏出现错误，用户便需要重新录制宏。

这类工具有一种用于测试网站的变种，其“界面”不是应用程序而是网页，由于网页依赖HTML渲染器展示用户界面，因此这类变种不再关注操作本身，而是代为渲染HTML并监听DOM事件来完成宏的记录与回放。在这里，"接口"的网页。然而，这一框架利用了完全不同的技术，因为它是渲染HTML并听事件，而不是操作系统的活动。无头浏览器（一种没有用户界面的浏览器，专用于网页功能性测试）或Selenium Web Driver通常用于网站的测试工作。

持续测试

持续测试指的是在软件开发过程中自动对即将发布的软件版本，通过软件输送管道，自动的执行测试并给出即时反馈，依次降低软件缺陷带来的业务风险。

自动化测试框架

测试自动化框架是一个为特定产品设置一系列特定自动化规则执行测试的集成系统。这套系统的整合（测试用的）函数库、测试数据集、对象细节（元数据）和各种可重用模块。将这些模块按照测试需求组合起来便可以得到一个完整的，针对特定功能或应用场景的测试用例。测试框架为自动化测试提供基础，并简化了自动化测试的工作流程。

几种常用的框架/脚本模式

1. 线性测试（尤其是测试工具自动生成的宏类脚本）
2. 结构化测试（使用控制分支结构，如：if-else、switch、for、while等）
3. 数据驱动测试
4. 关键字驱动测试
5. 基于模型的测试
6. 代码驱动的测试
7. 行为驱动开发
8. 混合模式（混合使用多种模式）
9. 敏捷开发自动化测试框架

测试框架的功能

1. 定义软件预期的表现（定义正确输出）
2. 针对待测试程序的生命周期创建运行钩子，或直接驱动待测程序
3. 执行测试
4. 报告结果

自动化测试接口

自动化测试接口是自动化测试框架中，为不同测试工具提供统一工作空间的平台。其目标是尽可能减少将业务指标映射成测试步骤这一过程中产生的代码量。自动化测试接口被设计用于改善测试脚本的维护效率和灵活性。

自动化测试框架的接口模型

自动化测试接口包括以下核心模块：

• 接口引擎
• 接口环境
• 对象库

接口引擎

接口引擎建立在接口环境之上，包括一个语法分析器和一个测试运行程序。

语法分析器用于将来自对象库的文件解析成测试脚本语言可用的形式，之后由测试运行程序执行。

对象库

对象库是使用测试工具，针对待测UI或应用程序创建的全部测试数据、宏对象的集合。

自动化框架和测试工具的区别

测试工具是专门针对一些特殊应用场景设计的，它们在自动化测试过程中完成一部份工作。自动化框架则不执行特定任务，而作为基础设施，为不同工具提供统一平台，并让它们工作在同一个模式下，以便自动化测试工程师开展工作。

有许多不同种类的框架，会依照测试或开发的架构来进行分类，有以下这些分类：

1. 数据驱动测试
2. 模块驱动测试
3. 关键词驱动测试
4. 混合测试
5. 基于模型的测试
6. 程序驱动测试
7. 行为驱动开发

自动化测试在行业中的现状

根据Practitest组织2018年收集，来自80多个国家的QA专业人士提供，约1,500份回复报告统计显示，高达76%的受访者执行自动化测试或负责编写自动化测试脚本。有85.5%的受访企业采用了各类自动化测试方法，其中75%的企业利用自动化测试方法执行回归测试，43%的企业将自动化测试和持续集成、持续开发方法结合使用，有3%的公司甚至将90%的测试工作自动化进行。

就薪资水平看，有着一到两年工作经历的测试工程师在西方国家能够拿到40k左右的年薪。具备自动化能力的工程师的年薪普遍更高。

另见

• 模糊测试
• 软件测试
• 系统测试
• 单元测试
• 自动化测试框架

参考文献

1. 1. ^  Kolawa, Adam; Huizinga, Dorota. . Wiley-IEEE Computer Society Press. 2007: 74. ISBN 978-0-470-04212-0.
   2. ^  徐进. . 《信息技术》: 152-155页.
   3. ^  金虎. . 《四川大学》.
   4. ^  Learning Test-Driven Development by Counting Lines; Bas Vodde & Lasse Koskela; IEEE Software Vol. 24, Issue 3, 2007
   5. ^  李刚毅， 金蓓弘. (pdf). 计算机应用研究. 2006. （原始内容存档 (PDF)于2019-07-19）.
   6. ^  Brian Marick. . StickyMinds.com. [2009-08-20]. （原始内容存档于2013-07-30）.
   7. ^  Garousi, Vahid; Mäntylä, Mika V. . Information and Software Technology. 2016-08-01, 76: 92–117. doi:10.1016/j.infsof.2016.04.015.
   8. ^  李涛. . 四川大学硕士学位论文. 2005.
   9. ^  Produce Better Software by Using a Layered Testing Strategy （页面存档备份，存于）, by Sean Kenefick, Gartner January 7, 2014
   10. ^  Testing APIs protects applications and reputations （页面存档备份，存于）, by Amy Reichert, SearchSoftwareQuality March 2015
   11. ^  All About API Testing: An Interview with Jonathan Cooper （页面存档备份，存于）, by Cameron Philipp-Edmonds, Stickyminds August 19, 2014
   12. ^  Headless Testing with Browsers; GUI and Headless Browser Testing - Travis CI （页面存档备份，存于）
   13. ^  Headless Testing with PhantomJS;Headless Testing with PhantomJS （页面存档备份，存于）
   14. ^  Automated User Interface Testing; Automated User Interface Testing · Devbridge （页面存档备份，存于）
   15. ^  Part of the Pipeline: Why Continuous Testing Is Essential （页面存档备份，存于）, by Adam Auerbach, TechWell Insights August 2015
   16. ^  The Relationship between Risk and Continuous Testing: An Interview with Wayne Ariola （页面存档备份，存于）, by Cameron Philipp-Edmonds, Stickyminds December 2015
   17. ^  . [2010-09-26]. （原始内容存档于2020-06-18）.
   18. ^  (PDF). [2011-12-11]. （原始内容 (PDF)存档于2012-04-26）.
   19. ^  . www.51testing.com. [2019-07-19]. （原始内容存档于2019-07-19）.
   20. ^  practitest.com. (PDF): 10, 21, 22. 2018 [2019-07-17]. （原始内容存档 (PDF)于2021-02-25）.

注释

• Elfriede Dustin; et al. . Addison Wesley. 1999. ISBN 978-0-201-43287-9.
• Elfriede Dustin; et al. . Addison Wesley. 2009. ISBN 978-0-321-58051-1.
• Mark Fewster & Dorothy Graham. . ACM Press/Addison-Wesley. 1999. ISBN 978-0-201-33140-0.
• Roman Savenkov: How to Become a Software Tester. Roman Savenkov Consulting, 2008, ISBN 978-0-615-23372-7
• Hong Zhu; et al. . ACM Press. 2008 [2019-07-17]. ISBN 978-1-60558-030-2. （原始内容存档于2020-02-19）.
• Mosley, Daniel J.; Posey, Bruce. . 2002. ISBN 978-0130084682.
• Hayes, Linda G., "Automated Testing Handbook", Software Testing Institute, 2nd Edition, March 2004
• Kaner, Cem, "Architectures of Test Automation （页面存档备份，存于）", August 2000

外部链接

• Practical Experience in Automated Testing （页面存档备份，存于）
• Test Automation: Delivering Business Value
• Test Automation Snake Oil （页面存档备份，存于） by James Bach
• When Should a Test Be Automated? by Brian Marick
• Guidelines for Test Automation framework
• Advanced Test Automation （页面存档备份，存于）
• Success Factors for Keyword Driven Testing by Hans Buwalda
• Automation That Learns: Making Your Computer Work for You （页面存档备份，存于） by Jeremy Carey-Dressler
• Automation Testing Resources & Best Practices （页面存档备份，存于） by Joe Colantonio

This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.