作为一个QA，自动化测试自然是属于职责内的一个核心技能，而我们在聊自动化时，通常说的，到底是什么呢？
个人认为，自动化其实是包括三个层次概念的：工具、框架、体系。
工具篇:
自动化测试工具是聊自动化时大家关注最多的内容，比如做Mobile测试时的Appium、Detox，做Web测试时的Selenium、Cypress，做API测试时的POSTMAN、Rest-Assured。
这些工具的统一作用，就是模仿了终端的操作，比如做GUI时，可以模仿用户点击按钮、跳转网页、输入内容等，做API测试时，可以发送一个HTTP请求、模仿安全认证，诸如此类。
这些工具根据被测对象、语言的不同有很多不同的选择，并没有一个标准答案，所以可以根据项目的技术栈、成熟度等，做出自己的判断。
但当我们真的为项目引入某一个工具时，我们会发现，仅仅有工具是不够的。
框架篇：
工具可以帮助我们自动的完成某个设计好的Case，但当我们想要去自动化执行时，就会遇到各种各样的问题：
我的用例包含多个步骤，要有严格的执行顺序；
我的所有用例都依赖于登录用例，只有登录成功后才能执行；
我的测试数据需要在测试执行前导入，执行后清除；
我的用例太多单机执行太慢，我需要多设备分布式执行；
我需要管理不同的设备，在不同的设备上都跑一下看看兼容性；
我需要有一个漂亮的统计报表来反馈自动化测试结果给BOSS；
... ...
实际上，当用例变多，环境变复杂，框架反而是比工具更难落地的一个部分。我们很可能需要将各种包组合起来来完成我们需要的测试框架：管理测试用例、执行测试用例、测试数据管理、断言、logging、分布式管理、设备管理、生成测试报告......
常见的框架有Unittest、Pytest、TestNG、Junit，它们可以帮助启动测试，确定用例的执行顺序，提供断言、log和简单的报告样式等，我们可以基于这些框架做自己的二次开发，比如增加Selenium Grid做分布式用例执行，用Chai去美化报告，使用opencv库加上图像识别功能等等。此外，如果采用PageObject模式，PageObject的设计和管理也可算作框架的一部分。
现在也有很多工具已经将工具和框架整合，如Cypress、Testcafe、Airtest，都提供了一站式的自动化测试体验，大家可以自行尝试一下。
体系篇：
工具+框架，足够支持我们完成某一层的自动化测试，但是针对一个产品的自动化测试，通常需要一个包含不同粒度的自动化测试体系来支撑。那么我们又要说到测试金字塔了。
测试金字塔基于成本和快速响应的目的，将测试活动进行了层级的区分，通常包括了单元测试，服务(API)测试，UI测试，各层级的投入有高到低，呈金字塔状。
测试金字塔是做测试分层比较通用的一个模型，绝对不是万能模型。如果把自动化的重心放在单元测试，这样可以采用测试金字塔模型，如果将重心放在服务间的集成测试上，这样整个体系可能看起来像个蜂巢，但将自动化的重心放在UI自动化上不是推荐的模式，UI自动化响应慢、执行慢、失误率高、变更频繁的因素会导致其很难管理。
实施篇:
这篇文章到此也就讲完了想讲的东西，自底向上的讨论了自动化测试的三层含义是，从工具 -> 框架 -> 体系，但在具体实施时，我们会从体系开始，自顶向下的来做设计和实施，这也是我们制定测试策略时的主要内容。
