测试分类

测试金字塔模型：

在这个金字塔模型中，界面测试、接口测试和单元测试，每一个阶段所占面积的大小，代表了它们在测试过程中的投入和工作量占比。

• 单元测试并非测试工程师的本职工作，它属于开发工程师的工作范筹。
  　　你可以看到，单元测试在测试过程中，占据了绝大部分的比重，这表示单元测试需要你投入更多的时间和人力成本。但是，单元测试并非测试工程师的本职工作，它属于开发工程师的工作范筹。说到这你可能会问了：“如果开发工程师从来不写单元测试怎么办？”毕竟大部分开发人员都不爱写测试。
  　　其实，我也会问自己这个问题。不可否认，开发工程师不只很少写单元测试，更很少写出好的单元测试代码，很多时候，工期的压力让他们放弃了单元测试。但是，一个产品的交付质量更多时候却是由测试工程师来保障的，面对这一实际现状，我们又该怎么办好呢？
  　　我们聪明的测试工程师提供了两种解决手段：一种是用一些智能化框架补充单元测试工作（如果你对智能化单元测试感兴趣，可以参考我在 2019 年 TiD 上的演讲内容 自动的自动化测试智能化一站式 API 测试服务；另外一种，就是加大我们自己主导的接口测试的工作投入比重，来弥补单元测试的不足，这样，上面那个金字塔模型就会逐渐演变成菱形模型。
   那之所以出现从“金字塔模型”到“棱形模型”这种变化，并不是有人刻意提高测试工程师在整个交付流程中的地位，这其实是随着工作的不断进行，逐渐形成的结果。在质量保障过程中，我们的测试工程师会不断增大接口测试的测试深度和测试广度，往下逐渐覆盖一些公共接口的单元测试内容，往上则逐渐覆盖应该由 UI 层保障的业务逻辑测试，这么做的主要目的，就是为了更好地完成质量保障工作，交付一个可靠的、高质量的项目。

接口

  所以我们可以看到，接口就是有特定输入和特定输出的一套逻辑处理单元，而它不用知道自身的内部实现逻辑，这也可以叫做接口的黑盒处理逻辑。
  接口的本质，它其实就是一种契约，遵循这样一种形式：在开发前期，我们约定接口会接收什么数据；在处理完成后，它又会返回什么数据。

• 常见的接口协议：
    HTTP 协议的接口、RESTful 格式的接口、WebService 的接口、RPC 协议的接口等。其实无论是哪一种形式的接口，它们都是通过某一种传输协议，在 Client 端和 Server 端之间来完成数据传递的。
• 假如你现在测试的，是 Web 端的极客时间，那么 Client 端就是浏览器，Server 端就是 Web 服务，那么浏览器和 Web 服务之间，就是通过 HTTP 协议传输的；
• 如果你测试的，是移动端的极客时间，那么 Client 端就是你的设备上安装的极客时间应用，Server 端就是 RESTful 格式的接口服务，那么极客时间的应用和 RESTful 格式的接口服务，就是通过 JSON 格式的数据来传递的。
    接口测试其实就是模拟调用方，比如 Client 端，通过接口通信来检测被测接口的正确性和容错性。
• 我现在所说的模拟调用方，并不是让你开发一个浏览器或者极客时间的手机应用，而是让你模拟这些客户端上的前端逻辑，调用 Server 端提供的接口，你完全可以借助一些工具或代码来完成这项工作。
  

1. 内部接口
   
2. 外部接口
   

接口测试的优点

1. 接口测试更容易和其他自动化系统相结合；
2. 相对于界面测试，接口测试可以更早开始，也可以测试一些界面测试无法测试的范围，因此它使“测试更早的投入”这句话变成现实；
3. 接口测试还可以保障系统的鲁棒性，使得被测系统更健壮。