一文带你了解接口测试价值与体系

批处理任务编排
初学者容易误以为容器的任务只在于部署行为－－将软件在容器中部署以提供持续的服务。但其实容器也同样大量的被应用于批处理程序的运行上。比如测试行为是典型的批处理任务范畴， 它不提供持续稳定的服务， 它只是一段特定的程序，而一但这段测试程序结束后就应该销毁一切，包括执行环境和所占用的资源，容器对比于传统的虚拟机的优势也在于除了容器更加的轻量级外， 容器的创建和销毁都很方便，通过 K8S 的能力可以很方便的在需要时创建，结束时销毁回收资源以达到更好的资源利用率（就如上篇文章中介绍的 Jenkins 与 K8S 打通后的运作模式）。而现在准备的测试案例会更加特殊， 它需要重复运行 N 次，因为本次执行的是稳定性测试（也有人叫它浸泡测试或者长期高压测试），这种测试类型的特殊之处就在于它的目的是验证被测系统在长期的高压下是否仍能够提供稳定的服务。所以它的测试方式是长期的（1 天，1 周甚至更长时间）不间断的运行自动化测试。而自动化测试的数量是有限的，它不可能持续的运行那么长时间，所以才需要重复运行。在不改造测试框架的前提下 K8S 能通过什么样的方式来帮助完成这个测试需求。首先看一段 K8S 提交任务的配置文件。

如果把测试简单分为两类，那么就是客户端测试和服务端测试。移动端的测试包括 UI 测试，兼容性测试等，服务端测试包括接口测试。接口测试检查数据的交换，传递和控制管理过程，它绕过了客户端，直接对服务端进行测试。

接口测试的价值

服务端非常复杂，就像下图的阿里核心链路图，包含大约 150 个组件，组件与组件之间进行交互，形成了密集的后端网络。UI 测试无法覆盖这么复杂的组件交互网络，所以要绕过客户端，直接使用接口测试对服务端进行测试。

接口测试的体系

对行业的各种测试进行分层，越往上，发现 bug 的时间越晚，成本越高。接口测试（Service）相比 UI 测试，可以更早发现问题，更快的质量反馈；同理，单元测试（Unit&#x