(一)接口自动化如何开展？
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等去生成接口文档。
测试接口文档可以参考以下测试点：
- 确保开发必须提供接口文档。如果开发没有写接口文档的习惯，应push开发去写接口文档。
- 检查接口文档的格式内容等是否完备，包括：URL、请求方法、Header、入参、返回值、示例Demo等。
- 检查接口设计是否符合公司规范。包括接口命名、接口格式、字段命名、字段类型、响应状态码、接口容错、字段是否冗余、接口是否鉴权、是否做版本区分等等。
当后端开发完成接口的开发工作时，我们就可以提前开始对接口进行初步测试了。
步骤如下：
- 把后端代码部署到测试环境上。
- 通过postman或swagger去对接口文档提到的接口进行测试。
第四步：前端接口测试&Mock数据（接口层面的测试）
前面的步骤只是利用测试工具去发起网络请求，来模拟接口调用。
但在真实的场景下，搜索网关的接口实际上是提供给 APP/WEB/小程序 进行调用的。
我们同样也需要关注前端调用过程是否是正常的。（需要等待前端开发完毕，才能介入测试）
可以利用Charles来对前端发送的请求进行抓包，
- 验证前端调用接口的传参是否正确；
- 验证后端的接口响应是否符合预期；
- 前端拿到数据之后，交互和UI展示是否正确。
当有些数据有多种状态，并且数据比较难以构造时，我们可以通过Mock数据去进行测试。
常见的Mock数据的方式有：
- 用 Fiddler 或者 Charles 去篡改请求和响应。
- 如果是PHP或者Python等动态语言，可以直接在后端代码里面去更改条件。
- 数据库中去修改数据。
- 用专业的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等去生成接口文档。
测试接口文档可以参考以下测试点：
- 确保开发必须提供接口文档。如果开发没有写接口文档的习惯，应push开发去写接口文档。
- 检查接口文档的格式内容等是否完备，包括：URL、请求方法、Header、入参、返回值、示例Demo等。
- 检查接口设计是否符合公司规范。包括接口命名、接口格式、字段命名、字段类型、响应状态码、接口容错、字段是否冗余、接口是否鉴权、是否做版本区分等等。
当后端开发完成接口的开发工作时，我们就可以提前开始对接口进行初步测试了。
步骤如下：
- 把后端代码部署到测试环境上。
- 通过postman或swagger去对接口文档提到的接口进行测试。
第四步：接口场景化设计
背景：现有平台对单服务单接口自动化测试流程相对成熟，而对于复杂的跨服务的自动化用例配置的需求反馈日益增多，所以，增加对于复杂测试场景的支持
什么样的用例适合场景化
也可称为业务流，例如：举个电商类case，下单购买-支付-验证支付状态-查看权限-退款-验证退款状态
- 无论是否跨应用，步骤有前后有强依赖关系
- 核心兜底业务场景，比如，下单-支付-履约-退款
基于以上背景，此次项目对应的功能点如下：
- 增加【场景集】概念，等同于原有的【项目】
- 增加【测试场景】概念，与原有的【用例集】类似
- 触发关联的测试场景
第五步：前端接口测试&Mock数据（接口层面的测试）
前面的步骤只是利用测试工具去发起网络请求，来模拟接口调用。
但在真实的场景下，搜索网关的接口实际上是提供给 APP/WEB/小程序 进行调用的。
我们同样也需要关注前端调用过程是否是正常的。（需要等待前端开发完毕，才能介入测试）
可以利用Charles来对前端发送的请求进行抓包，
- 验证前端调用接口的传参是否正确；
- 验证后端的接口响应是否符合预期；
- 前端拿到数据之后，交互和UI展示是否正确。
当有些数据有多种状态，并且数据比较难以构造时，我们可以通过Mock数据去进行测试。
常见的Mock数据的方式有：
- 用 Fiddler 或者 Charles 去篡改请求和响应。
- 如果是PHP或者Python等动态语言，可以直接在后端代码里面去更改条件。
- 数据库中去修改数据。
- 用专业的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，目前采用这种方式去做。（小而美，方便定制化）