先来看一般的功能测试如何进行：设计并编写用例文档，描述测试步骤和预期结果；测试人员根据测试用例描述按步骤操作，然后判断实际结果与预期是否一致。如果一致，测试通过；如果不符，测试失败。
自动化测试要做的事情与功能测试是一致的。分层理论和自动化测试方法结合，出现了三个层面的自动化：单元测试自动化、接口测试自动化和UI测试自动化。当然，不同层面的自动化关注点是不一样的。所以，从测试的行为本质上来看，功能测试与单元自动化测试、接口自动化测试和UI自动化测试并没有区别。唯一的区别是，一个由人来执行，一个由代码或工具执行。
2.4 自动化测试分层1)单元自动化测试
单元测试自动化，指对软件中最小的可测试单元进行检查和验证，调用被测服务的类或方法，根据类或方法的参数，传入相应的数据，得到一个返回结果，最终断言返回的结果是否符合预期。如果相等，测试通过；如果不相等，测试失败。
所以，单元测试关注的是代码的实现与逻辑。单元测试是最基本的测试，也是测试中的最小单元，它的对象是函数对象，也可以包含输入输出，针对的是函数功能或者函数内部的代码逻辑，并不包含业务逻辑。
该类测试一般由研发人员完成，需要借助单元测试框架，如java的Junit、TestNG，python的unittest等。
2)接口自动化测试
接口自动化测试，主要验证模块间的调用返回以及不同系统、服务间的数据交换。接口测试自动化一般在业务逻辑层进行测试。根据接口文档是RESTful还是RPC？调用被测试的接口，构造相应的请求数据，得到返回值，是成功或者失败。不管输入的参数是怎样的，我们都将得到一个结果，最终断言返回的结果是否等于预期结果。如果相等，测试通过；如果不相等，测试失败。
所以，接口测试关注的是数据。只要数据正确了，功能就做成大半，剩下的无非是如何把这些数据展示在页面上。
常见的接口测试工具有postman、jmeter、loadrunner等。
3)集成（UI）自动化测试
UI层是用户使用产品的入口，所有功能通过这一层提供给用户，目前测试工作大多集中在这一层，这种测试更贴近用户的行为，模拟用户点击了某个按钮、在输入框里输入了某些指令。有时可能用户看到登录成功了，但UI自动化并不知道它刚才的点击有没有生效。所以要找“证据”，比如登录成功后页面右上角会显示“欢迎，xxx”，这就是登录成功的有力“证据”。当UI自动化登录成功后，就去获取这个数据进行断言，断言如果相等，测试通过；如果不相等，测试失败。
所以，UI自动化的关注点用户操作形为，以及UI上各种组件是否可用。常见的测试工具有UFT、Robot Framework、Selenium、Appium等。
4)分层占比最佳实践
每种自动化测试都有自己的侧重和优劣势，在实际工作中不可能做到均分，因此我们需要制定合理的测试策略对其进行组织和分配，包括每部分测试投入多少、测试用例比例是多少等。
测试金字塔还有另一个维度的信息，如上图所示。
越往上，越接近QA、业务/最终用户，越往下，越接近开发；
越往上，测试执行越慢，越往下，测试执行越快；
越往上，测试成本越高（越耗时，失败时的信息越模糊，越难跟踪），越往下，测试成本越低。
按照测试金字塔模型以及投入/产出比，我们得知越向下回报率越高，所以应该使用大量的单元测试和全面的接口测试来覆盖产品提供的基本逻辑和功能，使用少量的集成（UI）测试来进行前端界面的功能验证。
都说业内最佳实践看Google，Google的自动化分层投入占比是：单元测试（Unit）：占比70%；接口测试（Service）：占比20%；集成测试（UI）：占比10%.
三、自动化测试最佳实践对现阶段公司大部分团队来说，更符合实际测试模式是纺锤模型。新项目中，可能由于时限原因或者开发人员习惯问题，一开始并没有把单元测试准备得很完善；而某些遗留老项目，可能原本就没有多少单元测试。
在上述情况下，一般的做法是先将重心放在中间层的测试上，原因有以下两点：
第一，中间层投入产出比较高，可以实现较高的自动化率；