全网最全，接口自动化测试怎么做的？精通接口自动化测试详解

一、前言

接口通俗来讲就是前端和后段之间传输数据的桥梁，注意：不是每一个项目都有接口，一些大型项目是前后端分离的，那么他们怎么实现数据的传递和返回呢？在通俗来讲就是前端和后段都有一个模拟参数数据

二、接口自动化测试的 "能 "

1、接口自动化的目标

• 用于项目的 API 层的 HTTP 接口的功能逻辑验证
• 减少手工测试的工作（回归验证；跨模块的验证）
• 实现手工验证不能做的验证（如接口涉及大量数据的排序比较）
• 手工很难充分验证的功能逻辑（如接口的功能验证涉及大量的数据）

P.S. 实际项目中，接口自动化的根本目的是什么？
个人认为是定时跑时，能监控接口，当接口功能失常时，可以及时发现，即发现 Bug。因此，可以使用代码覆盖率来评估接口自动化的完整性，但更重要的是发现问题

2、接口自动化 Case 用例设计原则

切记：

• 不要为了做自动化而做自动化，做的首要目标是问题出现时，能第一时间发现
• 自动化中的代码覆盖率统计可以作为参考，但不能一开始就为了提高覆盖率，陷入 Case 设计之中

注意：好的接口自动化 Case 设计，依赖于 Case 设计者的功能理解程度（手工测试的功力）+ 功能覆盖点

原则：

1.将手工测试点转换为自动化用例
Case 设计注意：验证用例通过的标准—参考一个功能点容易出问题的地方。或者说，一个用例的通过说明此功能点一定没问题；反之，一定有问题。

2.覆盖手工测试不易检查／太浪费时间的检查
比如：

• 一个 HTTP 接口设计大量的数据比较的时候
• 接口的 json 返回不能直接检查功能点是否正确（需要调用另一个接口的 json 来间接验证时）
• 一个接口的 json 返回需要和其他模块的接口联合” 互相验证 “（需要调用其他模块的接口的 json，两个 json 相互来验证彼此的正确性）

3.“边缘性” 的功能检查 这里主要指的是回归验证
如果系统涉及边缘性的功能验证，把此类功能设计层自动化用例

4.接口验证的程度
接口的验证：即判断一个接口是否正常的标准。注意：接口参数”合理地“组合

5.DB 数据更新检查
（如果有必要）注意从接口的角度检查 DB 数据的更新：

• 其他系统的数据更新到待测系统 DB 中的数据
• 每天待测系统由于用户操作更新到 DB 中的数据

6.接口自动化的数据准备
关于是否需要为接口自动化，特意在 DB 中准备需要的数据，适需要程度而定。原则：除非必须，否则不用准备。如果不准备数据，无法完成对接口的验证，则自己准备数据即可

注意：一旦自己准备数据，评估对其他功能验证的影响。确保 DB 中数据量和真实性（模拟的数据需要充足，并且不能和真实数据差异性过大）

3、接口自动化用例定时跑

自动化一般会选择每天定时跑。这里需要注意的一点就是定时跑的时间选择

时间选择上注意几点：
1）在线上跑时，注意对线上接口的影响（一般要求：线上的回归验证可以随时跑）

2）如果要检查 DB 数据更新的有关逻辑，注意数据的稳定性 (如用户量少的时候)

3）在测试时（非生产环境），接口涉及读，写 DB，考虑是否需要定时跑

三、接口自动化测试的 "不能 "

首先，接口自动化不是万能的，总有覆盖不到的时候。知道自动化的”不能“之处，才能更好配合手工测试出问题

自动化的 ”不能“ 之处如下：
1）HTTP 接口突然出现压力问题（前期的压测）

2）Web 层面的手动测试 (新功能上线后，对原有功能回归时，仍需要接口自动化验证接口，手工测试 Web 页面功能)

3）异常情况（如需要第三方 API 挂掉／超时的场景）

1、接口自动化之难点

1）实现变动 vs 维护的工作量 vs 检查的详细程度

检查详细程度：自己和自己比；自己和同类接口同一指标比较（因为口径不一致，或者内部实现变化，需要后续维护）

经验：自己和自己比，扩展和兼容性比较好（动态参数 + 完成功能检查）；而自己和别的接口比 看需求而定（接口提测前后 数据准确性检查比较参考）；

P.S. 小的点，执行时间和执行频率

用途：发现功能失常，功能不可用；

2）接口监控 —— 执行时间和执行频率

• 检查详细程度 vs 执行时间和执行频率 (只能和自己)
• 检查详细程度 vs 经常频繁报警（一个接口怎样算是正常的，返回非200+功能正常）

3）数据报表
数据的正确性：统计口径（业务方的口径+多个接口／模块口径的差异后导致业务方不一致）

2、接口自动化之痛点

痛点当然源自难点：

• 当接口本身实现频繁变动、对接口的检查太过详细、开发修复缓慢时，那么不停的报警将会来了
• 不合理的自动化设计及维护方案，造成自动化成本大于自动化收益时，接口自动化就变得无足轻重了

实际项目中的体会是：为了自动化而自动化。特别测试场景过于复杂时，当自动化实现成本远大于手工测试成本时，就没有必要非去自动化测试了

相对于UI自动化而言，接口自动化具有更大的价值

为了优化转化路径或者提升用户体验，APP/web界面的按钮控件和布局几乎每个版本都会发生一次变化，导致自动化的代码频繁变更，没有起到减少工作量的效果

而接口一旦研发完成，后期重构/大幅度修改的频率则比较低.因而做接口自动化性价比还是很高的，对于迭代版本旧有功能的回归，beta测试，线上回归都能起到事半功倍的作用

---