在接口自动化测试过程中，如何开展接口自动化测试？单个模块和多个模块关联又怎么去做测试？

(一)接口自动化如何开展？

0、调研、前提准备和思考

a)前提：

1、正式设计用例的时候，结合postman/jmeter这样的工具

2、去设计不同的测试数据，发起请求，查看响应结果与设计是否一致

3、(要走一遍手工测试的) -- 发现的bug

b)用例的存储方式:

1、excel表格 - 配置json路径

2、json文件 - 请求参数比较多，写在json文件里

3、yaml文件 - httprunner3.0

4、数据库 - 创建表格

c) 自动化覆盖率怎么样

覆盖率：功能上/手工用例覆盖率 - 30% - 90%

1、你做这个项目的接口自动化多久了？

2、系统大不大？是否复杂？

3、覆盖率用例多少条？遇到什么困难(及解决方案)？

1、需求分析

了解项目的业务功能，bug较多的模块，比较稳定接口有哪些，核心功能有哪些

2、 了解接口

2.1 抓包看接口

2.2 通过接口文档了解

3、自动化框架、工具的选择

3.1 工作的可扩展性以及扩展语言 + 选几个复杂的接口试用

3.2 框架结构的比较

3.3 规范命名

4、写接口用例

4.1 写接口用例脚本

• 1、核心业务的先走 - 用户使用率最高
• 2、用例优先级 - 常用的功能场景/必填参数
• 3、参数的格式有效性-后端没有做校验
• 4、正常用例先设计、异常场景(全面)

4.2 尽早加入jenkins集成

4.3 定期汇报进度

4.4 测试报告，自动发送报告、分析用例失败原因

4.5 记录接口自动化开始到当前的bug

4.6 异常处理情况

5、持久化层构造

1、数据库直接插入数据

6、维护阶段

1、开发修改接口，测试同步修改接口脚本

2、新增接口，同步新增接口用例

3、脚本、日常框架优化

4、配置文件持续更新

(二)单个模块怎么去做测试的呢？

单模块测试：在测试工作中主要用于检查单个业务功能的接口实现，或者调试测试数据。

第一步：梳理上下游调用链

1）为什么要梳理上下游调用链？

目前互联网产品的后端服务，基本上都是分布式部署 的，一个接口可能会调用其他接口，也有可能被其他接口调用，接口与接口之间，具有千丝万缕的依赖关系。

如果只是单独的调调参数，就希望把接口测试做好，显然是不可能的。（开发自己都能调（tiao）接口参数，还要测试做什么？）

2）怎么梳理上下游调用链？

1、看项目wiki、产品文档和开发文档

2、看开发写的代码，阅读代码

3、梳理出上下游调用关系，手绘一份系统流程图，如果还有不明确的地方，可以找PM、开发沟通确认

第二步：编写接口测试用例

如果说要做接口自动化，接口测试用例也是很有帮助的。

这里给出一个接口测试用例的案例：

第三步：测试接口文档&调试接口

在项目开发之初，前端开发和后端开发会共同去约定一套接口规范，然后由后端开发去编写接口文档，然后前后端就可以按照约定去进行协同开发。

接口文档的管理和编辑有多种方式：

• 有的团队习惯用wiki或者在线文档去编写接口文档；
• 有的团队喜欢用专业的接口文档工具，比如：Swagger、Yapi等去生成接口文档。

测试接口文档可以参考以下测试点：

1. 确保开发必须提供接口文档。如果开发没有写接口文档的习惯，应push开发去写接口文档。
2. 检查接口文档的格式内容等是否完备，包括：URL、请求方法、Header、入参、返回值、示例Demo等。
3. 检查接口设计是否符合公司规范。包括接口命名、接口格式、字段命名、字段类型、响应状态码、接口容错、字段是否冗余、接口是否鉴权、是否做版本区分等等。

当后端开发完成接口的开发工作时，我们就可以提前开始对接口进行初步测试了。

步骤如下：

1. 把后端代码部署到测试环境上。
2. 通过postman或swagger去对接口文档提到的接口进行测试。

第四步：前端接口测试&Mock数据（接口层面的测试）

前面的步骤只是利用测试工具去发起网络请求，来模拟接口调用。

但在真实的场景下，搜索网关的接口实际上是提供给 APP/WEB/小程序 进行调用的。

我们同样也需要关注前端调用过程是否是正常的。（需要等待前端开发完毕，才能介入测试）

可以利用Charles来对前端发送的请求进行抓包，

1. 验证前端调用接口的传参是否正确；
2. 验证后端的接口响应是否符合预期；
3. 前端拿到数据之后，交互和UI展示是否正确。

当有些数据有多种状态，并且数据比较难以构造时，我们可以通过Mock数据去进行测试。

常见的Mock数据的方式有：

1. 用 Fiddler 或者 Charles 去篡改请求和响应。
2. 如果是PHP或者Python等动态语言，可以直接在后端代码里面去更改条件。
3. 数据库中去修改数据。
4. 用专业的Mock工具去构造数据，如：EasyMock、TestableMock、Mockjs等。

比较快速的方式，当然是直接用Charles去模拟。

第五步：后端接口测试&业务逻辑覆盖（看日志、看代码）

看日志

业务测试过程中，我们需要时刻关注后端日志状态。

有时候接口响应数据是正常的，但是后端日志可能正在报错，

看代码

推荐大家在做接口测试的时候，一定要去阅读开发的源码。

阅读源码可以对业务逻辑实现了解更加深入。

如果代码量很大怎么办？

告诉大家一个小诀窍：当开发提交代码之后，我们可以在Gitlab上看他的Commit记录，或者将他的开发分支和生产环境的分支做个diff，这样就能知道他改了哪些地方。

第六步：接口性能调优（Arthas）

排查过程 ：

（1）先在APP上尝试复现

（2）通过Arthas的trace逐步去排查接口响应慢的原因：

进入Arthas命令行

java -jar arthas-boot.jar

trace 接口调用的方法

trace 类名 方法名 

第七步：接口版本控制&diffy

一般接口都会区分版本，如果接口不是很规范，或者改了一些通用的逻辑，这个时候就需要对老版本进行一次回归测试。

最笨的方法就是拿新老版本的两个app对比测试。我们也可以用diffy这个工具来做回归测试。

第八步：开始做接口自动化

接口自动化一般常用于进行线上巡检回归、提测冒烟测试等场景。

实现接口自动化，采用一下方式：

coding：

python+pytest+requests，目前采用这种方式去做。（小而美，方便定制化）

(三)多个模块关联怎么去做测试的呢？

模块关联：是指将两个及以上相关API的出入参以参数化的形式达成动态关联，以实现整个事务的测试覆盖，达到基础的工具接口自动化测试。

第一步：梳理上下游调用链

1）为什么要梳理上下游调用链？

目前互联网产品的后端服务，基本上都是分布式部署 的，一个接口可能会调用其他接口，也有可能被其他接口调用，接口与接口之间，具有千丝万缕的依赖关系。

如果只是单独的调调参数，就希望把接口测试做好，显然是不可能的。（开发自己都能调（tiao）接口参数，还要测试做什么？）

2）怎么梳理上下游调用链？

1、看项目wiki、产品文档和开发文档

2、看开发写的代码，阅读代码

3、梳理出上下游调用关系，手绘一份系统流程图，如果还有不明确的地方，可以找PM、开发沟通确认

第二步：编写接口测试用例

如果说要做接口自动化，接口测试用例也是很有帮助的。

这里给出一个接口测试用例的案例：

第三步：测试接口文档&调试接口

在项目开发之初，前端开发和后端开发会共同去约定一套接口规范，然后由后端开发去编写接口文档，然后前后端就可以按照约定去进行协同开发。

接口文档的管理和编辑有多种方式：

• 有的团队习惯用wiki或者在线文档去编写接口文档；
• 有的团队喜欢用专业的接口文档工具，比如：Swagger、Yapi等去生成接口文档。

测试接口文档可以参考以下测试点：

1. 确保开发必须提供接口文档。如果开发没有写接口文档的习惯，应push开发去写接口文档。
2. 检查接口文档的格式内容等是否完备，包括：URL、请求方法、Header、入参、返回值、示例Demo等。
3. 检查接口设计是否符合公司规范。包括接口命名、接口格式、字段命名、字段类型、响应状态码、接口容错、字段是否冗余、接口是否鉴权、是否做版本区分等等。

当后端开发完成接口的开发工作时，我们就可以提前开始对接口进行初步测试了。

步骤如下：

1. 把后端代码部署到测试环境上。
2. 通过postman或swagger去对接口文档提到的接口进行测试。

第四步：接口场景化设计

背景：现有平台对单服务单接口自动化测试流程相对成熟，而对于复杂的跨服务的自动化用例配置的需求反馈日益增多，所以，增加对于复杂测试场景的支持

什么样的用例适合场景化

也可称为业务流，例如：举个电商类case，下单购买-支付-验证支付状态-查看权限-退款-验证退款状态

1. 无论是否跨应用，步骤有前后有强依赖关系
2. 核心兜底业务场景，比如，下单-支付-履约-退款

基于以上背景，此次项目对应的功能点如下：

• 增加【场景集】概念，等同于原有的【项目】
• 增加【测试场景】概念，与原有的【用例集】类似
• 触发关联的测试场景

第五步：前端接口测试&Mock数据（接口层面的测试）

前面的步骤只是利用测试工具去发起网络请求，来模拟接口调用。

但在真实的场景下，搜索网关的接口实际上是提供给 APP/WEB/小程序 进行调用的。

我们同样也需要关注前端调用过程是否是正常的。（需要等待前端开发完毕，才能介入测试）

可以利用Charles来对前端发送的请求进行抓包，

1. 验证前端调用接口的传参是否正确；
2. 验证后端的接口响应是否符合预期；
3. 前端拿到数据之后，交互和UI展示是否正确。

当有些数据有多种状态，并且数据比较难以构造时，我们可以通过Mock数据去进行测试。

常见的Mock数据的方式有：

1. 用 Fiddler 或者 Charles 去篡改请求和响应。
2. 如果是PHP或者Python等动态语言，可以直接在后端代码里面去更改条件。
3. 数据库中去修改数据。
4. 用专业的Mock工具去构造数据，如：EasyMock、TestableMock、Mockjs等。

比较快速的方式，当然是直接用Charles去模拟。

第六步：后端接口测试&业务逻辑覆盖（看日志、看代码）

看日志

业务测试过程中，我们需要时刻关注后端日志状态。

有时候接口响应数据是正常的，但是后端日志可能正在报错，

看代码

推荐大家在做接口测试的时候，一定要去阅读开发的源码。

阅读源码可以对业务逻辑实现了解更加深入。

如果代码量很大怎么办？

告诉大家一个小诀窍：当开发提交代码之后，我们可以在Gitlab上看他的Commit记录，或者将他的开发分支和生产环境的分支做个diff，这样就能知道他改了哪些地方。

第七步：接口性能调优（Arthas）

排查过程 ：

（1）先在APP上尝试复现

（2）通过Arthas的trace逐步去排查接口响应慢的原因：

进入Arthas命令行

java -jar arthas-boot.jar

trace 接口调用的方法

trace 类名 方法名 

第八步：接口异常机制（Chaosblade）

因为接口依赖的服务很多，经常需要调用其他接口。假如依赖的服务出现了异常，我们就需要考虑我们的接口是不是做了容错处理，或者是降级处理。

可以用Chaosblade去注入异常。（非必须，但有更好）

第九步：接口版本控制&diffy

一般接口都会区分版本，如果接口不是很规范，或者改了一些通用的逻辑，这个时候就需要对老版本进行一次回归测试。

最笨的方法就是拿新老版本的两个app对比测试。我们也可以用diffy这个工具来做回归测试。

第十步：开始做接口自动化

接口自动化一般常用于进行线上巡检回归、提测冒烟测试等场景。

实现接口自动化，采用一下方式：

coding：

python+pytest+requests，目前采用这种方式去做。（小而美，方便定制化）