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

(一)如何进行接口自动化？

0、研究、前提准备和思考a)前提:1、在正式设计用例时，结合postman/jmeter等工具2、设计不同的测试数据，发起请求，检查响应结果是否与设计一致3、(手工测试) -- 发现bugb)用例的存储方法:1、excel表格 - 配置json路径2、json文件 - 请求参数较多，写在json文件中的3、yaml文件 - httpruner3.04、数据库 - 创建表格c) 如何覆盖自动化覆盖率：功能/手动用例覆盖率 - 30% - 90%1、你做这个项目的界面自动化多久了？2、系统大吗？2、系统大吗？复杂吗？3、覆盖率用例是多少？遇到什么困难(及解决方案)？

1、需求分析了解项目的业务功能，bug多的模块，接口稳定，核心功能是什么

2、 了解接口2.1 抓包看接口2.2 了解接口文档

3、3.1选择自动化框架和工具 工作的可扩展性和语言的扩展性 + 3.2试用几个复杂的接口 3.3.3框架结构的比较 规范命名

4、写接口用例4.1 写界面用例脚本

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

4.2 尽快加入jenkins集成4.3 定期报告进度4.4 测试报告自动发送报告，分析用例失败的原因 从记录接口自动化到当前bug4.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测试接口文档中提到的接口。

前一步只是使用测试工具来启动网络请求，以模拟接口调用。

但在真实场景中，搜索网关的界面实际上是提供的 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，这样我们就可以知道他改变了什么。

排查过程 ：(1)尝试在APP上复制(2)通过Arthastrace逐步调查界面响应缓慢的原因:进入Arthas命令行

java -jar arthas-boot.jar

trace 接口调用方法

trace 类名 方法名

一般接口会区分版本。如果接口不是很标准化，或者改变了一些通用逻辑，此时需要对旧版本进行回归测试。

最愚蠢的方法是比较新旧版本的两个应用程序。我们也可以使用dify工具进行回归测试。

接口自动化通常用于在线检查回归、烟雾测试等场景。

实现界面自动化，采用以下方式：

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. 核心业务场景，如订单-支付-履约-退款

基于上述背景，本项目对应的功能点如下：

• 增加[场景集]的概念相当于原始的[项目]
• 添加[测试场景]的概念类似于原来的[用例集]
• 触发相关测试场景

前一步只是使用测试工具来启动网络请求，以模拟接口调用。

但在真实场景中，搜索网关的界面实际上是提供的 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，这样我们就可以知道他改变了什么。

排查过程 ：(1)尝试在APP上复制(2)通过Arthastrace逐步调查界面响应缓慢的原因:进入Arthas命令行

java -jar arthas-boot.jar

trace 接口调用方法

trace 类名 方法名

由于接口依赖于许多服务，因此通常需要调用其他接口。如果所依赖的服务异常，我们需要考虑我们的接口是否容错或降级。

Chaosblade可以用来注入异常。(不必要，但更好)

一般接口会区分版本。如果接口不是很标准化，或者改变了一些通用逻辑，此时需要对旧版本进行回归测试。

最愚蠢的方法是比较新旧版本的两个应用程序。我们也可以使用dify工具进行回归测试。

接口自动化通常用于在线检查回归、烟雾测试等场景。

实现界面自动化，采用以下方式：

coding：

python+pytest+requests，这样做是目前使用的。(小而美，便于定制)

更多的技术文章