接口自动化测试的几个阶段
原文地址http://blog.csdn.net/huazhongkejidaxuezpp/article/details/52825364
根本目标
测试环境中，保证新增接口功能正确性，原有接口的回归（保证原有接口不被修改“坏”）；
生产环境中，保证接口层面服务可用，功能的正确性（保证服务挂掉时，及时发现）
接口自动化的程度
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时，可以及时发现。
- 阶段特点：该阶段属于接口的监控。可以根据监控定时的频繁程度，决定接口检查的详细程度（一般来说，监控跑的越频繁，接口检查的详细程度随之下降。否则，如果接口变动比较频繁，或者接口不稳定，会频繁报警）。
- 阶段目标： 监控线上接口的可用性，保证服务突然挂掉时，可以及时监控到（当然，如果线上原有接口几乎不变，并且接口功能稳定，可以将第一阶段的接口自动化脚本用于此阶段）。
难点和关键点：接口检查的详细程度取决于 监控定时的频繁程度要求，以及线上接口的稳定性
实现难易程度：⭐️⭐️⭐️⭐️
脚本变动频度：⭐️⭐️⭐️⭐️
脚本定时频度：⭐️⭐️⭐️⭐️⭐️