1. 专栏目的

很久之前就有开一个接口自动化专栏的想法，得益于我在前东家有丰富的服务端测试经验，推动了团队同学向自动化测试转型。 详情可以看我的另一篇文章。https://testerhome.com/topics/29777
接口测试也是每个测试同学都必须掌握的测试技术，而想更近一层，接口自动化测试也是必途之径。
希望通过这个专栏，能让大家对接口自动化测试有新的认识，每人都能开发出适用于自己团队的接口自动化测试框架。

2.如何进行接口测试？

2.1 接口测试工具介绍

我第一次接触接口测试并非来源于项目需要，而是来源于团队 KPI 需要。当时校招刚入职没多久，团队内部有测试相关知识与技能培训，测试技能更多的是测试工具的使用，而我接触的第一个测试工具就是 JMeter-一款 Java 开发的 开源接口/性能测试工具。还记得我同事通过一个 word 文档给我介绍 JMeter 的一些常用组件，然后就给我安排上了一个任务 - 将团队 xx 平台接口代码覆盖率提升至 40% 以上。当时还不知道代码覆盖率是什么，但是只晓得通过 JMeter 开发更多单接口/业务场景组合的用例就是了，于是乎就开始通过针对单接口的入参类型、边界、是否必传做各种组合，而场景组合用力 就根据 业务流做接口间的笛卡尔积。

2.2 接口用例三要素

一个完整的接口用例，必须包含测试数据、HTTP 请求、断言。

1. 测试数据：测试用例都是数据驱动的，接口测试属于黑盒测试范畴，所以输入决定输出。而数据不仅仅要包含正向的，也要包含反向和异常的数据。
2. HTTP 请求：包含接口名、域名、请求体、请求头内容
3. 断言：怎么确定你的测试用例是通过的还是不通过的呢，断言就显得至关重要。断言内容就是你要的预期结果。断言包含对接口响应内容做断言、也包含对落 DB 的数据做断言。 下面我简单介绍一下 JMeter 常用组件。主要分为三大类：预值类、测试类、后置类。

2.3 JMeter 组件介绍

预值类

蓝色圈内属于预置类组件。何为预置，可以理解为测试用例 run 之前需要准备的工作内容，例如查询 SQL 前需要先进行数据库连接；调用接口前需要准备好接口参数等。

1. JDBC Connection Configuration 数据库连接组件，可以进行数据库配置，配置信息如下。重要内容有连接池。
2. HTTP Header Manager 大家都知道，HTTP 请求头比较重要的几个内容，如 content-type、cookie、user-agent，针对同一个项目下的 API 请求头基本上是一致的，可以将所有接口的请求头定义到一个模板中。而这个组件就是这样的作用。
3. HTTP Request Defaults
   同样一个系统下所有接口的域名是一致的，所以域名信息也可以定义到模板，供所有接口使用。
4. User Parameters 前文说到测试用例三要素，其中重要的就是数据，而我们在测试过程中，有些数据可以供所有接口使用，抑或是多个接口需使用相同的一个变量值（例如 cookie），这样的话，我们就可以将这个变量值参数化，定义到这个组件，供所有接口调用。

测试类

1. HTTP Request 组装/发送 http 请求的组件，包含请求方法、请求体、协议类型、接口路径等
2. JDBC Request 发起 SQL 操作的组件

后置类

1. JSON Extractor http 响应成功后（一般响应体是 Json 结构），我们需要对其响应内容做断言，则这个组件可以提取出我们需要的信息。
2. Regular Expression Extractor 当然除了第一种方法提取信息，也可以使用正则表达式来提取我们想要的内容。
3. Response Assertion 这个就是断言组件，可以将我们的预期结果放到组件里。
4. Debug Sampler 这个组件是辅助我们开发用例的，在我们调试用例时候，可以通过此组件查看用例执行过程定义的所有变量值。
5. View Results Tree 这个组件的作用和上一个是一样的，但是这个让我们获取的信息更多，例如请求体、响应体内容都可以在结果树中看到。 当然，本文重点不是介绍 JMeter，只是强烈建议刚接触接口测试的同学学会使用这个工具。更简单的意思就是学会了这个工具的使用就掌握了如何编写接口测试用例。工具让抽象的测试用例通过它提供的各个组件给实例化，让你能看得见。同样，postman 也是一款优秀的接口测试工具，但是 JMeter 更适合自动化，还能根据自己的需求扩展自己想要的 JMeter 插件，而 postman 更多用于单接口调试。

3.为什么接口测试更适合自动化实现？

大家都知道分层测试理论，从金字塔自底向上看，相同投入成本下边际收益是越来越低的，而越是金字塔底部越适合自动实现。在《Google 软件测试之道》一书中有介绍到 Google 70% 的自动化测试工作集中于单元测试，20% 集中于接口测试，剩下 10% 才是 UI 测试。虽然很多公司没有谷歌的工程师文化，但是我们能晓得标杆公司对于对于单测和接口测试的重视程度。
而界面相比于接口，变动更频繁，用例的开发和维护成本相当高，非常不利于自动化实现，而接口层面，接口契约一般变化不大，更多的是接口输出可能变化比较多，所以我们开发好的自动化用例维护成本相对较低。

4.为什么需要自动化测试框架？

这些年工作经验让我明白一个道理，即使开源工具能够拿来即用，但是这些工具往往满足不了更多的测试诉求。

1. 测试工具开发的测试用例往往不易于维护，试想一下当你维护 JMeter 生成的各种 JMX 文件场景。
2. 大量的测试用例可重用性差，例如登陆模块，每个接口调用前都要获取 cookie，而登陆则是前置模块，使用 JMeter 开发用例需要每个 JMX 文件都要包含登陆，重复度太高。
3. 无法满足自动化平台诉求，短期内确实可以快速实现自动化，但是这些工具对于平台非自动化能力的拓展成本较高，毕竟改动开源工具的成本比自研高很多。
4. 使用开源工具不利于提升团队在自动化技术方面的成长。自动化能力的提升离不开编程能力的提升，使用开源工具能提升工具学习使用能力，最终你的成长无外乎又掌握了一个测试工具的使用。
5. 无法最大化提升自己解决问题的能力。