接口自动化涉及功能
1.接口功能及异常组合情况
https://testerhome.com/topics/7260 这篇文章来看，已经很复杂了，是否需要设计成如此复杂的方式。接口测试过程中例如一个输入参数字段值为 0 到 10 的范围，那接口测试时需要组合的就有 0、10、9、-1、” 0”、11、””、null 等接口测试用例组合，那么，是否需要全部考虑到，各大公司做的接口自动化框架，满足了哪些业务场景，做到哪种程度？
2.host 切换。
测试用例的执行的环境配置，例如可能在公司内存在测试环境、线上环境、运营环境 (配置各种运营需求或数据需求)
(1) 开发需求比较多时，例如，接口需要先在测试和运营环境配置 host，并且接口开发、测试通过，然后部署到线上环境，需要保证 host 切换 (在接口未上线前)。
(2) 灵活配置 host，验证某些模块或功能回归正常。
3.关于公共模块的设计 (登录请求或者多请求下的接口设计)。
(1) 公共模块设计会有类似登录请求，使用登录请求响应中的 token 作为下一个请求的入参再进行请求，然后验证请求回来的响应的正确性。多接口请求方式，层次最好能深入几层？或者说如何能更加灵活的进行多接口配置等。
(2) 公共模块可能还涉及到对每个接口是否 200，返回的 json 的公共结构是否正常；还有一些加密算法、md5 校验，json 结构中 result 字段的格式结构、字段 key 的公共校验。
(3) 每个接口请求的 log 记录、请求时间记录、测试结果记录等。
4.关于入参数据或数据准备设计思路 (如何更方便)。
根据https://testerhome.com/topics/4773 中介绍的数据管理策略，分为 databasefile 注解的属性 -- 作用域的设计方式，分为 method 和 class 的作用范围。测试思路类似 appium 编写脚本时的 setUp 和 tearDown，在 setUp 中定义好作用域的范围，然后在执行脚本时如果是 method 方式的，只有这个测试方法内可以使用；如果是 class 作用域，其实就相当于这个 suite 或 class 类可以使用这些数据。
(1) 思路很不错，可以使用 testng 带的注解作用域方式来实现和使用。
(2) 对于数据来源思路，可以从数据库中保存然后取出，根据场景业务，制定测试数据场景是否可行？测试中的 post 数据会修改服务端的状态，在每次测试之前，是否可以编写一个 shell 脚本，先去执行服务端创建的测试数据删除操作 (根据测试账号，测试分类等进行相应删除)？希望各位大神给点提示，和思路。
5.接口相应校验 (数据库校验、只校验字段格式)。
(1) 接口公共模块校验 (上边所说的公共模块设计)。
(2) 对于较长的 json 格式，可以将请求接口 request、响应的 response 对应关系保存到数据库中，在接口自动化测试时根据请求接口，查询对应 response 是否正确，这种校验方式类似 rest-assured 中的 json schema 校验方式，可以根据场景进行定义。
最好的方式是从数据库取出数据，进行字段校验。但问题也有：如果自动化执行时连接的是线上数据库，是否会影响线上，那么我自己 copy 一份线上数据库是否可行，而且还涉及到测试过程中要和开发的数据库保持一致等问题。这块的问题不太了解，希望大神们指点一二，谢谢。
那接口测试时需要组合的就有 0、10、9、-1、” 0”、11、””、null 等接口测试用例组合
比如 Google 地图 API 这种在互联网上公开的接口，能做到这些算合格。一个内部管理系统能做到就很优秀了。
我见识少，接触过的公司，能做到一个接口有一条正向用例的就很少了。
用 TestNG 的话，就是写 JAVA 咯，用 JDBC 写 SQL 或者 ORM 框架也行，比用 Shell 好一些吧。
不过需要在 Host 切换、token 、数据恢复上花很多心思，说明在环境治理上还很原始。这些问题会影响交付过程中的方方面面，并不是接口测试时才会面临的问题。
见过最好的项目，没有数据恢复的说法，因为每次测试执行都在新环境上。测试代码里也不需要准备数据，因为维护了有一个包含测试数据的镜像。测试环境包含了三方服务（包括单点登录）的 Mock 服务，所以测试代码里也不需要这些东西。
关于第一个问题，接口测试要做到什么程度，也是我一直以来的困惑。
如果简单的说凭经验肯定是不行的，或者说根据实际情况我是不行的。
问题在于，在一般的情况下，接口自动化测试用例，要做到什么程度？
或者说：从多细的地方开始划断，该手工测试的归手工测试，该自动化的归自动化？
期待有大牛来根据实际的案例讲解一下自己的经验。
我以我的理解，尝试逐一回答你的问题：
我认为的【接口测试】是通过接口调用来实现业务逻辑的测试，而不是
接口连通性测试。但可惜的是，很多人是在做后面这些工作。
所以你不能问是不是要把 1 到 10 到验证一遍，而是要看这些值在业务上是否有具体的语义。所谓的host 切换，我的理解是要让用例执行在多个环境下，我不清楚目前你们怎么做的。但是我们的接口用例实现层跟环境是解耦的，用例逻辑本身不用关注执行在什么环境中。
其实跟第二点很像，用例层根本不用去关心 token 怎么获取、签名是如何生成，重点永远是业务逻辑，那么这些行为在哪里去实现呢？ 封装到框架的接口层
特殊的测试数据我们在本地保存一份，没有特殊性的数据实时从数据库中获取，这是我们的思路。
其实第一个问题的回答中提到了，关键在于你们的接口测试要解决什么：连通性？还是业务逻辑校验。如果是前者，我没什么可说的。如果是业务逻辑，那么关键字段的正确性必须是要校验的。
以我的理解，尝试回答下你的问题
- 各种异常参数，实际测试的是系统健壮性。建议更多地从业务场景去考虑参数组合，用例会更有效。
- host 切换，一般是框架层面设计的时候做好，用例永远只会从框架取环境设置。我们目前的做法是在命令行加了一个环境的参数，换个参数就切换环境了。
- 公共模块这个，通过框架的接口层完成。例如 rest-assured 通过 filter 可以完成你说的加解密或者自动加字段，用例不需要关心。（当然 filter 也是写接口测试的同学来写的，项目强相关）
最后两个 @jacexh 已经说得很不错了。至于线上数据问题，线上是不可能跑全量测试环境的用例的，需要另外有一个用例集，主要进行查询类接口的测试。
接口分级就好 功能 - 流程 - 性能 - 监控 看测试策略的不同来进行颗粒度的划分
陈小憩
回复
以前用虚拟机是利用快照和镜像。之后数据库在 Docker 容器里，准备好数据之后 ``
执行
# 准备数据
docker commit api-test init:1
# 执行测试
docker run --name api-test init:1
begin api-test
# 执行测试
docker run --name api-test init:1
begin api-test
# 追加测试数据
docker commit api-test init:2
# 执行测试
docker run --name api-test init:2
begin api-test
Mock 自己也写过、也用过现有工具、也用过在线服务。
一个技术方案是在很多因素影响下产生的：组织结构、要达到的效果、人员技术能力、硬件资源、投入时间……