前言

一转眼做技术也有 7、8 年时间，担任测试开发教学也有4个年头了。

因为常年帮助各个公司的测试同仁们解决问题，自然比待在某个固定的环境能接触到更多的实际案例，也能见到更多团队的痛点。同时又有时间去系统学习，完善自己的技术栈。

既然有这个优势，也有这个精力，那就去分享更多有价值的东西。行业整体技术提升了，大家都是受益者。这才是我们创建 **"片言"** 的初衷--更高效地帮助技术人员解决问题。

可以分享的内容实在太多，所以在想什么对大家最有

价值呢？越来越多的公司

开始注重服务端的测试。接口测试正是服务端最好的测试方式，也是我认为

所有的测试手段里性价比最高的一个。但是本次不讲基础，接口测试的基础知识大家可以参考我2019年的书

《接口测试最佳实践》

本篇系列连载

《高效接口测试》

更加贴合现在企业快速迭代下，对接口测试以及接口自动化测试的新需求。也可以当作去年那本书的下册！

废话不多说，先上目录：

1. 《更从容地应对接口变更：Swagger自动化解析》

2. 《更智能地模拟数据：如何开发好的Mock服务》

3. 《更快捷地测试无文档接口：使用MitmProxy自动化录制接口信息》

4. 《接口也能精准化测试：接口测试的代码覆盖率统计》

5. 《设计一个好的测试框架：如何深入理解测试框架4要素》

6. 《让接口工具更加人性化：接口自动化的关键字驱动》

正文

01 更从容地应对接口变更：Swagger自动化解析

1.1 什么是Swagger？它能干什么？

相信无论是前端还是后端开发，都或多或少地被接口文档折磨过。前端经常抱怨后端给的接口文档与实际情况不一致。后端又觉得编写及维护接口文档会耗费不少精力，经常来不及更新。测试人员吐槽待测试的接口调不通，每个参数是什么含义也不清楚。

那么能不能有一套规范，后端开发人员只要写了类似代码注释一样的东西，就可以自动生成接口文档呢？Swagger定义了这样一套注释的编写与文档展示的规范。再进一步，能不能只编写一个配置文件，比如：yaml、json。就可以生成一个在线的接口文档，发布到某个服务上提供给项目全体成员访问。接着我又提出了一个"过分"的需求，能不能再给我一个在线的接口调试页面--一个在线的Postman？Swagger衍生出来的一系列项目和工具，满足了我的全部需求。

但即便如此，对于许多开发来说，编写这个yml或json格式的描述文件，本身也是有一定负担的工作，特别是在后面持续迭代开发的时候，往往会忽略更新这个描述文件，直接更改代码。久而久之，这个描述文件也和实际项目渐行渐远，基于该描述文件生成的接口文档也失去了参考意义。

就在此时Java届服务端的大一统框架Spring，迅速将Swagger规范纳入自身的标准，建立了Spring-swagger项目，后面改成了现在的Springfox。通过在项目中引入Springfox，可以扫描相关的代码，生成该描述文件，进而生成与代码一致的接口文档和客户端代码。这种通过代直接码生成接口文档的形式，在后面需求持续迭代的项目中，显得尤为重要和高效。

```

总结：Swagger发展到今天，已经是一组工具包了。它可以集成到各种语言的开发框架中，比如Java、Python、PHP、Go现在全部支持。

后端开发人员更新接口代码后，Swagger相关工具会自动生成接口文档。项目组所有成员可以在线查看，手动点击调用并查看响应内容。

```

我们来看一个具体的例子：

```
http://49.232.147.132:8080/
```

我在上面的阿里云上部署了一个Java的 SpringBoot服务。这个服务是一套完整的商城后台管理系统接口。在该项目中，集成了Swagger模块生成在线接口文档。

大致的项目配置如下(如果你不是一个开发人员，可以不必深究)：

- 新增maven依赖

```
<!--swagger2-->
<dependency>
    <groupId>io.springfox</groupId>
    <artifactId>springfox-swagger2</artifactId>
    <version>2.8.0</version>
</dependency>
<dependency>
    <groupId>io.springfox</groupId>
    <artifactId>springfox-swagger-ui</artifactId>
    <version>2.8.0</version>
</dependency>
```

- 新建配置类

```
/**
 * Swagger2API文档的配置
 */
@Configuration
@EnableSwagger2
public class Swagger2Config {
    @Bean
    public Docket createRestApi(){
        return new Docket(DocumentationType.SWAGGER_2)
                .apiInfo(apiInfo())
                .select()
                .apis(RequestHandlerSelectors.basePackage("com.macro.mall.demo"))
                .paths(PathSelectors.any())
                .build();
    }
    private ApiInfo apiInfo() {
        return new ApiInfoBuilder()
                .title("SwaggerUI演示")
                .description("Demo模块")
                .contact("macro")
                .version("1.0")
                .build();
    }
}
```

- 在对应的controller类中，符合Swagger的编写规范

配置完毕后，在项目部署的端口后面，增加部分后缀。就可以查看接口在线文档，地址如下：

```
http://49.232.147.132:8080/swagger-ui.html
```

从上面的图中可以看出，对于一个典型的Java Web项目。每一个控制器（也就是Controller），你可以把它理解成一个子模块。每个模块中有不同的方法，每个方法其实就是我们平时测试的一个业务接口。

展开页面中的某个接口方法，可以看到该接口详细的信息。包括：响应的标准样例，每个请求参数的说明和参数类型，响应的常见错误码说明。点击最下方的 "try it out" 按钮，可以完成在线接口调用并在下方看到本次调用的具体响应数据。是不是比postman还要好用？只是没有自动化测试的功能。