接口自动化测试的三个阶段

测试环境中，保证新增接口功能正确性，原有接口的回归（保证原有接口不被修改“坏”）；

生产环境中，保证接口层面服务可用，功能的正确性（保证服务挂掉时，及时发现）

1）如果项目完全没有UI前端页面，则应该尽可能多的自动化接口测试(人工接口测试或自动化结果判断可以使用人工辅助)；

2）如果项目含有UI前端页面，则应该尽可能多的自动化接口测试(人工接口测试或自动化结果判断可以使用人工辅助)；配合前端页面测试，回归P1/P2接口；

3）对于业务交互检查场景特别复杂的场景，可以使用脚本实现(ps: 此时脚本和业务关联比较紧密，不太适合把相关的脚本做成框架)。

总之，应该根据自身项目的特点来评判自动化的程度，使得自动化能更好结合手工测试，来完成质量保障。

1）功能同时可手工和自动化测试时，自动化只是用来节省人力和时间；

2）功能更适用使用自动化来测试时，自动化可以弥补手工测试的不足；

3）功能只能被人工来测试时(例如页面UI检查)，自动化就显得有些[了力不从心]了。

该阶段主要是保证功能提供的正确性。所谓正确性，是指返回的数据正确，功能正确。
阶段特点：对接口进行最为详细的检查（接口返回json的正确性），QA对系统的熟悉程度和对接口的熟悉程度，以及测试本身的经验直接影响该阶段测试的深度。
阶段目标：测试阶段，直接使用接口脚本/手工检查接口正确性；生产阶段定时对线上接口进行检查（注意：由于是对接口的详细检查，该阶段设置的定时任务不易太频繁，否则接口稍有变动，或者接口功能不稳定，就会报错）

难点和关键点：自动化脚本主要依赖于QA对系统的熟悉程度和对接口的熟悉程度，很可能由于用例设计问题，导致监控线上接口时

不能发现问题

实现难易程度：⭐️⭐️⭐️⭐️⭐️

脚本变动频度：⭐️⭐️⭐️⭐️⭐️

脚本定时频度：⭐️⭐️⭐️

该阶段主要是保证数据提供的正确性。所谓正确性，是指返回的数据正确。
阶段特点：对接口返回的数据的检查（接口返回json的数据正确性），检查方法通常有两种：直接查询DB，拼SQL对比检查；和上一版本的接口返回的json进行对比（此时需要保证2个版本的接口除代码分支外，其他配置，DB等等完全相同）
阶段目标：测试阶段，直接diff 此次修改分支和线上分支分别返回json（检查方法：同样条件下，如果返回的json完全一致，说明接口数据正确；否则需要重新查看不同是否在允许的范围内）

难点和关键点：自动化脚本主要依赖于2个json 对比接口的封装，可以忽略某些参数的对比，或者可以只对比某些参数。

实现难易程度：⭐️⭐️⭐️⭐️

脚本变动频度：⭐️⭐️⭐️⭐️

脚本定时频度：⭐️⭐️⭐️

该阶段主要是保证线上接口的可用性。即，如果接口返回非200时，可以及时发现。
阶段特点：该阶段属于接口的监控。可以根据监控定时的频繁程度，决定接口检查的详细程度（一般来说，监控跑的越频繁，接口检查的详细程度随之下降。否则，如果接口变动比较频繁，或者接口不稳定，会频繁报警）。
阶段目标：监控线上接口的可用性，保证服务突然挂掉时，可以及时监控到（当然，如果线上原有接口几乎不变，并且接口功能稳定，可以将第一阶段的接口自动化脚本用于此阶段）。

难点和关键点：接口检查的详细程度取决于监控定时的频繁程度要求，以及线上接口的稳定性

实现难易程度：⭐️⭐️⭐️⭐️

脚本变动频度：⭐️⭐️⭐️⭐️

脚本定时频度：⭐️⭐️⭐️⭐️⭐️

感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：