本文是作者学习自动化策略之后的学习总结，如果觉得这篇文章能解决你现在对于自动化策略的迷惑，或许本文可以给你一个方向。
一、测试自动化的原因
提到自动化大家会问为什么要自动化，接触过敏捷的应该知道，敏捷的成功离不开自动化，除了这个原因之外，还有其他的理由：
1.手动测试需要太长时间
2.手动过程容易出错
3.自动化让测试工程师有时间做更有价值的工作
4.自动化的回归测试提供了安全网
5.自动化测试能较早且频繁地提供反馈
6.驱动编码的测试和实例可以做更多的事情
7.自动化的投资回报率高
这里我就不一一详细赘余。总之，产品需要自动化来提供安全网，提供基本的反馈，保持技术债务的最小化并帮助驱动编码，而且将回归测试和单调乏味的手动测试自动化，可以让团队有时间做更重要的工作，例如探索性测试。
二、测试自动化的敏捷方法
首先我们通过敏捷测试象限来看下自动化测试的分类：
可以看到，象限一和象限二标记为使用自动化。在第四象限中，从技术视角来看，用于评价产品性能、安全、非功能性测试通常也需要自动化工具，而且有些情况也只能自动化。工具对于某些测试来说还是有用的，比如说，自动化可以创建好测试数据和用户场景并对日志进行分析。
象限有助于我们了解所需的工具，但各个层次上有这么多的自动化工具，我们该怎么选择呢？因此有必要了解不同类型的测试所适用的地方以及如何组织这些测试，为了快速、频繁的交付有价值的产品，自动化需要有较高的ROI（投入产出比），测试金字塔可以帮助我们优化对测试策略的设计。
敏捷测试自动化金字塔展示了3个不同的自动化层次。最下面那一层是基础，也是ROI最高的。
中间一层包含了支持团队的自动化业务测试，旨在验证系统“在做正确的事情”，这些测试大部分运行在API层，因为可以绕过展现层，所以编写和维护自动化的代价并不高。所以现在越来越多的测试工程师不断充实中间层的测试覆盖率。
顶层很少使用自动化，自动化测试的ROI最低，不稳定的因素太多。比如，仅仅重命名HTML元素就会导致测试脚本失败，而且运行测试的速度可能会达到几十分钟，有些团队也就仅仅维护一套e2e测试。
三、哪些测试可以自动化
1.持续集成、构建与部署
自动化集成部署过程会加快测试的速度并减少错误，参与过流水线类似项目的小伙伴应该能体会到其中的方便之处。大多数敏捷团队发现构建时间超过8-10分钟就没法工作了，测试人员也无法对新增的功能代码进行快速反馈。
2.单元与组件测试
开发人员的自动化单元测试显然是非常重要的，通过TDD可设计出高质量、健壮的代码。常用的是对应开发语言的xUnit
3.API或web Services测试
这是介于单元测试和展现层测试之间的，前面提到API类的自动化测试ROI也是比较高的，通过自动化我们可以快速给团队提出反馈。比较好用的框架有go4api，python+requests，RESTassured等等
4.GUI测试
虽然说GUI自动化测试的ROI不高，但是在团队人员和时间充足而且页面变化很多的情况下是可以做GUI自动化测试的。比较好用的是工具有cypress、selenium等
5、性能测试
这类测试只能通过自动化脚本或者工具完成，手工测试通常都不可行，也不准确。如果有大量的数据量，不使用工具或者脚本是很难模拟出符合期望的场景的。
6.创建数据
如果需要频繁而且创造不同类型的数据的时候，那么请将该过程自动化。
清理数据与创建数据同等重要。创建数据的自动化应该也可以清理测试数据，这样就不会影响到其他测试，也能保证可以反复运行同样的测试。这里大家可以想一下，怎么可以创建出对于系统来说每一天都是最新的数据呢？
四、什么测试不应该自动化
一些测试需要人的聪明才智以及发散思维和敏感特质，可用性测试与探索性测试就属于此类。不需要自动化的有一次性测试与那些永远不会失败的测试。
1.可用性测试
观察用户的使用体会、根据经验将其记录在案并评判结果是可用性测试人员的工作，记录用户的行为则有助于可用性测试。
2.永远不会失败的测试
举个例子来理解，假设有一个表单，里面需要输入地址，难道我们还需要写一个自动化测试来验证是否需要填第二个地址吗？
如果正在测试的是一个非常重要的系统（会带来巨大利益损失或者关乎生命的），即便是小小的回归测试失败也是非常严重的，那么请使用风险分析来决定需要自动化哪些测试。
五、从哪里开始自动化策略
1.考虑多层方法的时候
根据自动化测试金字塔的每一层去考虑。
2.在思考测试设计的时候
在思考测试设计、选择哪种方法、考虑用户界面的时候要用公平的态度去处理，要找到“它会发现我们需要知道的缺陷并且维护代价也很低”和“这是我们所能找到的最优雅的工具”之间的平衡点。
六、选择正确的工具
这要根据自己的系统特性以及团队成员所拥有的技术进行综合考虑，比如：一个小程序和一个web系统所用的工具和框架是有很大区别的。所以团队中应为工具评估、搭建测试流程和体验不同的测试方法预留一些时间。
七、将敏捷法则应用到测试自动化上
我们应做到：
1.保持简单
2.迭代式反馈
3.整体团队运作方案
4.花时间做正确的事情
5.边做边学
八、为测试提供数据
无论使用何种工具进行自动化，测试都需要数据才能进行，在理想情况下，我们需要与产品数据匹配的真实数据。
1.数据生成工具
不管是自己写一个脚本还是用什么工具，数据生成这一步是测试自动化过程中必不可少的。
2.避免访问数据库
我们应该都知道，涉及到对数据库的操作，量级一旦上去都会给我们的自动化运行速度造成一定的速率影响。如果能做到将数据运行在内存中，而不会存储到数据，显然速率就不会受到数据库的干扰。
3.如果数据库访问不可避免
如果是典型数据：那我们可以设计子数据库，种子数据代表了真实的产品数据，由于它只是少量的，因此每次自动化测试套件可以快速重建这些数据。
如果是类产品数据：那我们可以用统一的模版来创造。
如果是做数据迁移的测试：这就需要用真实的数据库进行测试。
九、评估自动化工具
选择自动化工具的第一步是制作一份该工具需要实现的功能列表，接下来看看如何决策：
1.确定自动化工具的需求
2.一次一个工具
3.适用于敏捷的工具
这些工具应该：
1⃣️可以通过测试优先的方式迅速启动测试自动化
2⃣️分离测试与实现细节
3⃣️支持并鼓励对测试自动化的代码部分应该应用良好的编程实践
4⃣️支持通过真正的IDE和语言编写测试自动化代码
5⃣️鼓励协作
十、管理自动化测试
需做到：
1.组织测试
这个组织可以是一张脑图，也可以是一个系统流程图或是时序图等等，总之要站在系统整体的角度去组织成一个测试整体。
2.组织测试结果
我们做了前面这么多的测试自动化的付出，最后无非想要的就是一个测试结果，一份简洁、易懂、形象的测试报告就显得尤其重要，可以借助一些工具也可以自己给自己的测试自动化后面补充一个结果组织。
总之，一个好的自动化测试策略需要：
1.使用敏捷测试象限来辅助确定哪里需要测试自动化以及何时需要。
2.测试自动化金字塔可以帮助团队在能够带来回报的测试自动化上作出正确的投资。
3.重复的任务、持续集成与构建过程、单元测试、功能测试、性能测试和数据创造都可以进行自动化。
4.可用性测试、探索性测试，需要人类关键思考和观察的则无法自动化。
5.在开发自动化策略时，从最痛苦之处开始，考虑多层方法，争取持续的回查来改进策略。
6.在决定自动化的目标时请考虑风险和ROI。
7.使用能让测试独立、可重复运行和尽可能快速执行的测试数据。
8.不要畏惧自动化测试。