文本
自动化意味着使用工具来更有效地执行特定的测试任务。因此，它不是手动测试还是自动测试，而是始终用来支持另一个。从开发人员和产品所有者到CTO，参与产品生命周期的每个人在开始讨论测试自动化时都应牢记这一点。 当实现自动化的想法穿过你的心，不要转移到如何部分马上; 相反，请关注为什么。为实现自动化而使用诸如以下参数的自动化
听起来不错，所以一定不错；
另一家公司的人已经在使用它；
我们可以通过自动化测试覆盖100％的功能；
类似的推理通常被误认为是采用自动化测试的绿灯。同时，学习测试自动化策略对于那些想要缩短软件交付周期并为QA工程师留下不那么单调的任务的人来说是一个好主意。 如果您尚未决定目标，那就花点时间。您可以阅读该文章，稍后再返回优点和缺点清单。
测试自动化策略是…
…质量保证团队在质量保证过程中应用自动化的方式。如果您开始分解测试自动化策略，将获得一系列元素，看起来像这样： 手动和自动测试计划； 测试环境，包括定义和描述；
测试用例;
自动化脚本；
测试数据;
检测结果;
执行日志。
具有成本效益的测试自动化策略意味着以结果为导向的方法，该方法可以帮助公司紧跟市场趋势并保持领先，或者至少实现其雄心勃勃的业务目标。 每个项目都有特定的测试自动化计划和策略。即使在测试类似产品时，某些方面也需要进行调整。您可以使用相同的模板来创建测试自动化策略，但最终版本至少会稍有不同。
逐步测试自动化策略
因此，您已经知道高效的自动化始于设定目标。让我具体说明一下。目标定义了从长远角度来看要实现的目标，例如：
更好的产品质量，从而提高用户满意度；
减少人力和测试时间；
提高测试效率，同时降低测试成本。
目标更像是“一次一步”。这些是您必须完成以实现目标的较小任务。测试自动化的目标包括：
更广泛的测试范围；
创建易于运行和维护的测试；
每次迭代后提高产品质量；
改进的稳定性和可靠性；
提高质量检查工程师的效率和更好的动力。
如果您想获得列表中每个项目的详细说明，可以在我们博客中有关自动化测试目标的文章中找到。现在，让我们继续进行逐步说明。
建立测试自动化策略
＃1。选择要自动化的东西 设置测试自动化是一个非常耗时的过程，因此请考虑从短期和长期的角度计划实现的目标。设定合理的期望。 另外，请记住，选择合适的测试用例开始并不意味着您应该永远使用它们。这些测试在此阶段应该符合您的业务目标，但是随着软件的发展它们变得无关紧要，这是可以的。 现在，请考虑重复进行测试的频率及其需要的工作范围。在理想情况下，您将选择至少满足以下几个条件的测试：
如果手动完成，则很耗时；
涉及大数据集；
涵盖稳定的软件组件；
需要在多个系统（浏览器，操作系统，硬件等）中进行检查；
平凡，不需要创造力；
具有清晰的通过/失败结果；
高度重复。
另一方面，某些测试不适合自动化。例如：
将执行一次的测试；
基于视觉的测试；
测试没有明显的通过/失败结果；
反自动化功能，例如CAPTCHA；
原始和不稳定的功能。
我不建议自动化这些东西。该过程将花费很多时间，运行测试后得到的结果将不准确。例如，UX测试需要明确的人工输入和估计。探索性测试依赖于QA工程师的知识，经验，甚至直觉和偶然性。显然，手动检查在这里更为合理。 ##确定测试方法
测试自动化方法定义了如何执行测试。一个积极的态度开始在SDLC的早期阶段测试设计过程。质量保证团队会在创建构建之前发现缺陷。在反应式方法中，测试在编码完成后开始。质量检查小组将检查应该准备发布的产品的初始版本。
自动测试的类型
测试方法还涵盖团队要执行的测试类型。自动化的最常见候选者是：
单元测试-由熟悉后端的开发团队对代码的最小功能元素进行检查。
组件测试-前端的测试团队分别检查每个对象或软件的一部分。
集成测试-检查单元组合的行为。
API测试-集成测试的一部分，重点放在API功能上。
兼容性测试-分析不同浏览器，操作系统，网络环境，硬件等中的软件行为。
冒烟测试-对旨在证明基本功能（安装，启动，注册等）有效的新版本的审查，以便团队可以继续测试其余功能。
GUI测试-旨在证明图形用户界面符合软件要求中规定的检查。
端到端测试-通过复制实际用户方案，从头到尾检查整个工作流程。
回归测试-一项旨在验证代码更改是否影响最新迭代之后未影响软件功能的部分的分析。
测试金字塔
测试金字塔是一项原则，可帮助您明智地选择自动化案例。单元测试涵盖了最低级别的软件代码，并且具有最高的投资回报率，因为它们有助于避免更严重的错误。因此，将这个级别自动化到最大是合理的。
优先考虑的是组件测试，集成测试和API测试。回归是自动化的又一候选，因为它涵盖了熟悉的功能，每次迭代后都需要进行修订。
然后才进行GUI测试。尽管非常常见，但GUI自动化非常不切实际。这些测试难以维护，价格昂贵，并且存在大量的误报与否定。
测试金字塔
传统方法提出了相反的建议：GUI的自动化程度更高，单元测试的自动化程度更低，而这并不总是有效的。
考虑以下因素来选择测试方法：
应用程序所基于的技术。应用规范会影响所需的测试类型以及以后的测试类型-平台和工具的选择。
团队角色。确保每个团队成员都知道自己的职责，并且有资格涵盖该项目质量保证的特定方面。
涉及的风险。为了消除最可能和最具破坏性的风险，您需要覆盖脆弱的区域。因此，您应该知道风险。创建一个文档，在其中记录以下参数：
风险等级-风险变为现实时的处理难度；
概率—风险变为现实的可能性；
缓解—采取措施解决风险；
成本估算-降低风险的成本。
选择一个自动化框架
测试自动化框架是一组详细的准则，编码标准，项目层次结构，报告机制等，它们为自动化测试脚本创建了一个支架。 简而言之，这是使测试自动化高效的一种做法。质量检查团队需要选择合适的框架来创建脚本，这些脚本具有更高的重用性，更易于移植和降低维护成本。 一些最受欢迎的做法是：
线性脚本；
依赖的架构；
模块化框架；
数据驱动的框架；
关键字驱动的框架；
混合框架。
测试自动化框架
记录和回放（也称为线性脚本，记录和回放）
它是所有框架中最简单的框架，它使质量检查工程师能够手动记录测试过程的每个步骤和验证参数，以便他们以后可以随时回放。 线性脚本是生成脚本的最快方法，甚至不需要自动化经验。缺点是重用少，维护困难。
结构化脚本（也：库体系结构，功能分解）
该框架采用使用记录和回放创建的脚本，将相似的脚本分组为函数，将其保存到库中，并在需要时调用。 库体系结构框架可确保更高的重用性，同时降低开发成本和维护工作量。另一方面，它还需要专业知识和更多计划。
模块化框架
测试自动化工程师将AUT（被测应用程序）划分为较小的组件（单元，功能，部分），并为每个组件创建一个脚本以进行隔离测试。分层组合这些脚本，可以创建用于更广泛测试运行的整体脚本。 由于数据是经过硬编码的，因此不能使用多个数据集，但是如果应用程序发生更改，则只需要修复单个测试脚本即可。
数据驱动框架
该框架将测试数据与脚本逻辑分开，并将其存储在外部。测试脚本使用此文件读取输入或输出参数。数据驱动的框架非常适合需要使用不同数据集多次测试同一功能的情况。因此，我们可以使用最少的脚本快速测试具有各种数据的方案。 设置数据驱动的框架非常耗时。对于熟练的测试自动化工程师来说，这是一项任务，它能够正确格式化数据并编写可利用此框架所有优点的脚本。
关键字驱动的框架
该框架主要用于GUI自动化，还意味着将测试数据与脚本分开存储。这些说明是按连续顺序（登录，单击等）描述操作的字词。 使用关键字驱动的框架，您将获得可重用的代码，以将其应用于可独立于AUT构建的多个测试脚本。设置还需要花费大量时间，并且需要付出很多努力才能保持秩序。如果应用程序很大，则证明安装成本高。然后，您可以使用这些脚本几年。
混合框架
每个框架都有其优点和缺点。当测试自动化工程师开始最大程度地发挥积极功能并最大程度减少负面影响时，他们可能会提出各种不同框架的组合，这些框架最适合特定项目。这种混合使混合框架成为敏捷和DevOps测试自动化策略的最常见选择。
分配专用资源
不要忘记，软件测试自动化是专门为其雇用的人员的任务。有些人试图使自动化成为手动质量检查工程师的兼职工作。但是，这些专家已经承担了其他任务，并且很可能缺乏设置自动化测试的技能。寻找具有脚本编写经验或至少具有相关知识的人员来负责此任务范围会更加有效。
选择测试工具
您要注意的第一件事是工具的普及程度，这不是错误。流行的工具通常被证明是可靠的，并在网上进行了广泛的讨论。自动化工程师可以在Web上找到许多有用的技巧和有趣的实践。
此外，要找到精通Selenium，Appium或Cucumber的QA工程师，要比最近才出现且看起来不错的工具容易。除了受欢迎程度外，还有其他要考虑的标准。
测试工具
技术栈：
该技术软件已构建。 被测系统的要求。 您熟悉的编程语言。
工具功能：
支持的操作系统，平台和环境（例如，自动浏览器测试，本机/混合应用程序测试等）。 跨平台测试支持。 复杂性与易用性。
预算：
您在寻找开源还是付费选择？
您是否正在寻找付费工具中的开发或运行时许可证？
您打算多久使用一次此工具？
价格合理吗？
经验表明，在开源工具上构建自定义框架是最佳选择。尝试几种解决方案。大多数软件都有免费试用期，因此您可以在购买许可证之前权衡商用工具的所有优缺点。
设计和运行测试
因此，您知道要自动化的内容，要应用的测试类型，要使用的框架和工具。现在是时候从安排过渡到实际工作并开始编写脚本了。这里有一些技巧可以帮助您：
概述日常工作和程序。
创建在多个项目中使用的测试用例模板。
在编写新的测试用例之前，记得检查类似的用例是否已经存在。
编写简洁且易于理解的测试，因为在将来，其他人也会使用它们。
使测试脚本尽可能的少，这样它们将容易理解和维护。
将大量测试分解成序列，逐个检查。它们越小，出错的概率就越小。
确保测试不依赖于UI。使用可能改变的UI元素和路径肯定会创建无用的脚本。
对如何解决失败的测试用例有一个清晰的计划(执行特性分析，只是向开发团队报告，等等)。
学习对测试用例进行优先排序。
保持脚本井井有条
有提供自动化软件测试服务经验的人承认，在维护阶段，事情往往会变得混乱。因此，最重要的是，根据测试的目的对测试进行分类，或者提出另一种分类，以便将来可以快速，轻松地找到相关案例。 不要忘记对新案例进行分类。审查并清理现有案例。它们中的许多并不能永远持续下去，这没关系。解决产品需求，以决定旧案例是否有效，应该使用还是不再适用。永远不要尝试重振无用的东西。
自动化测试：编写文档
文档管理与官僚主义无关，如果管理不当，则会造成延迟。相反，文档比内存更可靠，可以帮助您保持头脑清醒。那要放在纸上呢？ 概述工作范围，然后为每个任务设置里程碑和时间表。它将使每个团队成员都在同一页面上。 用流程，角色和技术记录自动化方法。当您需要澄清或解决难题时，它将成为您可以解决的一组准则。 概述自动化环境。在准备好发布之前，为软件创建流水线。 进行风险分析，为“万事大吉”方案做准备。风险始终存在，而忽略风险的可能性只是粗心大意。 创建执行计划以确保没有错误的测试。写下日常任务和程序。启动自动回归之前，请运行单独的测试。确保没有假结果。
敏捷项目的测试自动化策略
敏捷的测试自动化策略通常意味着一种主动的方法，并且倾向于自动化的单元测试。这些是使快速发布成为可能的基本条件。 除此之外，请考虑使用关键字驱动的自动化框架。如果选择与业务需求相关的词，则只要这些词与已知命令相对应，就可以使用脚本。关键字也可以成为混合框架的一部分，该混合框架使灵活性在敏捷SDLC中至关重要。 敏捷项目的自动化策略永远不会忽视单元和组件测试。一次测试一个小功能有助于从自动化中提取真正的价值。一方面，您可以在开发人员编写一段代码后立即为功能创建脚本。另一方面，将较小的部分编译成覆盖大部分功能的测试脚本有助于最大程度地减少途中的错误。
内部与外包测试自动化策略
内部团队和外包团队的质量检查自动化策略之间没有根本区别。在这两种情况下，您都需要确定要使用哪种测试方法和框架，选择自动化工具，并找到有资格的人员来处理任务。 区别在于管理工作的范围。当然，在任何情况下，项目所有者（或负责人）都必须管理该过程。而且，如果您正在阅读有关如何构建测试自动化策略的信息，则可能需要弄清楚有关它的一些信息。 在这两种情况下，您都需要从招聘过程开始。外包测试在这里可以节省时间。组建内部团队并不是一个快速的过程。希望您会找到合格的人员，他们熟悉测试自动化的最佳实践。 如果您选择QA外包，您将拥有一个功能齐全的团队，在软件测试自动化服务，成熟的自动化策略，喜欢的工具和测试脚本模板方面具有相关经验。 换句话说，内部团队至少在开始时就需要更多的参与和管理。使用外包的质量检查，您可以请求报告，指定您感兴趣的详细信息，而其余的则是他们要处理的任务。 拥有质量检查部门的公司通常决定使用内部质量检查资源和外包自动化来覆盖手动软件测试，因为这样做更具成本效益。有些人选择从外部团队开始，然后在任务流程稳定的情况下聘请自动化专家。
总结一下
实现测试自动化需要时间，精力和特定技能。自动化测试并不总是必不可少的。除非您定义明确的目标，否则它不会替代手动测试，也不会使项目受益。那么，如何利用所有人都在谈论的那些优势呢？ 知道为什么您确实需要QA自动化。保持合理的期望。从小处着手，并着眼于长远的眼光。如果结果不是即时的，请不要放弃自动化。但是最重要的是，仔细研究您的自动化策略。希望我能帮助您，至少有一点帮助。
author
石头 磊哥 seven 随便叫
company
thoughtworks
大家好，本人不才，目前依旧混迹于thoughtworks，做着一名看起来像全栈的QA，兴趣爱好前端，目前是thoughtworks 西安QA社区的leader，如果有兴趣分享话题，或者想加入tw，可以找我
roles
QA（营生） dev（front-end dev 兴趣爱好）
联系方式
如果想转载或者高薪挖我 请直接联系我 哈哈
wechat:
qileiwangnan
email:
qileilove@gmail.com
