1.3 自动化测试分层

基于金字塔模型，自动化测试领域也逐步细分，即分为单元自动化测试、接口自动化测试和UI自动化测试。本节我们来看看这3种自动化测试的概念。

（1）单元自动化测试

单元自动化测试指对软件中最小的可测试单元进行检查和验证，调用被测服务的类或方法，根据类或方法的参数，传入相应的数据，得到返回结果，最终断言返回的结果是否符合预期，如果符合则测试成功，如果不符合则测试失败。所以单元自动化测试关注的是代码的实现与逻辑。单元自动化测试是最基本的测试之一，也是测试中的最小单元，它的对象是函数，可以包含输入输出，针对的是函数功能或者函数内部的代码逻辑，并不包含业务逻辑。该类测试一般由研发人员完成，需要借助单元测试框架，如Java的JUnit、TestNG，Python的unittest、Pytest，等等。

（2）接口自动化测试

接口自动化测试主要验证模块间的调用返回，以及不同系统、服务间的数据交换。接口自动化测试一般在业务逻辑层进行。该测试根据接口文档是RESTful调用（一种基于REST架构风格的远程调用方式）还是远程过程调用（Remote Procedure Call，RPC）被测试的接口，构造相应的请求数据，得到返回值，从而判断测试成功还是失败。不管向接口输入的参数是怎样的，我们都将得到一个结果，最终断言返回的结果是否符合预期，如果符合则测试成功，如果不符合则测试失败。所以，接口测试关注的是数据。常见的接口测试工具有Postman、JMeter、LoadRunner等。

（3）UI自动化测试

UI层是用户使用产品的入口，产品的所有功能通过这一层提供给用户，目前测试工作大多集中在这一层，这种测试更贴近用户的行为，如模拟用户单击某个按钮或在文本框里输入某些字符等。比如用户在登录界面输入用户名和密码后单击确认按钮，有时可能用户看到登录成功了，但UI自动化测试脚本并不知道刚才的单击有没有生效。如果要找“证据”，登录成功后页面右上角显示的“欢迎，×××”，就是登录成功的有力“证据”。当UI自动化测试脚本测试到登录成功后，就会去获取测试数据进行断言，断言返回的结果是否符合预期，如果符合则测试成功，如果不符合则测试失败。所以，UI自动化测试的关注点是用户操作行为，以及UI上各种组件是否可用。常见的UI测试工具有UFT、Selenium、Appium等。

知识扩展： 自动化测试分层占比。

每种自动化测试都有自己的侧重和优劣势，如果要在团队或项目中推进自动化测试工作，我们应该如何制定相对合理的自动化测试策略呢？让我们来看一看图1-4。

图1-4透露了以下信息。

● 层级越往上，测试执行速度越慢（乌龟表示慢）；层级越往下，测试执行速度越快（兔子表示快）。

● 层级越往上，测试成本越高（需要更多的执行时间，且在用例执行失败时，获得的信息越模糊，越难跟踪）；层级越往下，测试成本越低。

● 层级越往上，越接近质量保证（Quality Assurance，QA）要求、产品人员、最终用户；层级越往下，越接近开发人员（Developer，DEV）。

● 层级越往上，业务属性越强；层级越往下，技术属性越强。

按照金字塔模型和投入产出比，我们得知层级越往下回报率越高，所以成熟的团队应该大量使用单元测试和接口测试来覆盖产品提供的基本逻辑和功能，使用少量的UI自动化测试来进行前端界面的功能验证。

都说业内最佳实践看Google，据了解，Google的自动化测试分层投入占比是单元测试占70%，接口测试占20%，UI自动化测试占10%。

虽然UI自动化测试不应该过多投入，但限于企业发展现状、项目类型、测试人员技能储备等各种因素，UI自动化测试是众多项目组最先开展，也是见效最快的一种选择。另外，UI自动化测试还具备单元和接口自动化测试所不具备的优势，比如单元测试验证代码处理的正确性，接口测试验证数据返回的正确性，但是前端（Web端或App端）结果展示是否正确，只能依靠UI自动化测试来验证。所以单元自动化测试、接口自动化测试和UI自动化测试不是“非此即彼”的关系，它们有各自擅长的领域，千万别被某些所谓的“大咖”忽悠，形成低层优于高层的错误观念。

关于自动化测试开展原则，笔者整理了“附录A”供大家参考。 a3FMbW7p0f6akJtdVLE+PFnQnc08mZ0YNs0t1lkAOvqViKXgXcicvRyHzCg4E1Kc