1. 第一个可以写一个通用检查方法。
2. 第二个是接口集成测试。

1. 根据实际需要来
2. 内部接口能集成测试就集成测试，外部接口可以考虑 mock 辅助

第一个问题：首先要弄清项目做接口自动化的目的，我项目主要是作为回归测试的手段，只需要保证接口在正常传参的情况下，返回的 code 跟 data 与预期一致就可以；所以我是校验了 response 以及状态码。
第二个问题：会有需要一些内部接口不会在 API 中给出，怎么定义内部接口？不太清楚，不过可以参考恒温的意见，看着也没啥问题

谢谢，请问保证接口在正常传参的情况下的意思是，测试时输入值只需要考虑改变 body 或者 param 的值吗，还是只测试成功的情况，不测试失败的情况？

可是失败的情况也是有可能的，比如，登录密码错误

请问集成测试的意思是 不放入接口自动化测试的用例中吗

以下均为个人观点哈

• 第一个问题，要看你的被测系统是怎么实现这类错误的。

比如 url 错误返回 404，大部分情况是 web 框架（如 springmvc）就自动返回的，开发啥都不用写，或者写一次就可以永久使用。这种个人觉得不需要测试

但也有的 url 是直接通配符匹配后，在具体开发写的业务逻辑里面进一步处理的（比如 path 参数，/user/{userId}/info这类，实际 url 会是 /user/1/info，也会是 /user/2/info），那就要测试 url 里面 userId 存在、不存在 2 种场景。

一般异常场景，会区分为业务逻辑异常/非业务逻辑异常。非业务逻辑异常主要是由框架直接校验的（如某某参数不能为空，swagger 或者 jsr303 注解，controller 定义接口的时候就可以一并完成校验了），这类抽查或者通过 review 代码确认有没有问题，更高效；业务逻辑异常则是具体的内部逻辑，这部分一般会是复杂度比较高的，做接口测试会更高效。

• 第二种问题，要看实际业务系统里面，要调用这个接口的服务/客户端，是怎么拿到这个 api 不会给出的值的？

如果拿的方式是找后端拿（比如不走 api 取，但是走 mq 取，甚至直接查库），那你就找后端拿

如果拿的方式是本身自己内置（比如本身有字典表或者对应常量），那就直接写死在你代码里

至于你说的 “自己写一个 mock 的接口” ，不是很明白。你还是把你的完整场景说清楚吧，现在说一半不说一半，看不大懂。

正解

1.如果判断为不为空是开发自己写的 ，比如写了一个 check 函数（在第一行），那这个情况是业务逻辑？

2.我的意思是，比如说 a 接口是 api 文档中没有的，但是可能 api 文档中存在的 b 接口的请求参数是 a 接口的返回值，那这个情况我是否需要自己写一个 a 接口，但是内部逻辑是自己来定义，类似于 callback。

借口咨询一下为什么我的账号不能发帖。 @ 恒温 @chenhengjie123

发帖提示什么？

访问被拒绝，你可能没有权限或未登录。

1、这种算是业务逻辑。因为不能保障和看到的接口文档强一致，不过这类逻辑如果是非常简单的，也建议直接 review 代码。个人觉得，不是很值得为了一个超简单且不怎么改的业务逻辑，去维护一个用例。

2、这种我理解就是多接口调用测试用例了，也就是上面很多同学说的接口集成测试，或者叫流程型用例（对比单接口用例）。一般做法是在 setup 里面调了 A 接口后，从 A 接口的返回值提取需要的参数。然后在 test 方法里把参数带上去请求 B 接口。

PS：你这种不是 callback 吧？个人理解的 callback 是被调用方在完成自己需要做的东西后，主动发起某个调用方明确要求的操作，主要用于异步非阻塞型任务。你这个 B 接口要 A 接口返回值，前提是 A 接口已经有返回，所以是同步阻塞型的

比如金融业务里常见的付款，A 系统调用 B 系统提供的付款接口，并要求在 B 系统处理完毕后给某个指定的 url 发一个请求，表示处理完毕。B 系统会在收到后立即放到一个类似队列的位置缓存，然后返回已收到（此时还没开始处理），此时这个 api 调用已经结束了。接下来 B 会做一系列操作（比如请求第三方等），全部操作完毕后，再调用最前面 A 系统给的一个指定 url，通知自己已经处理完毕。这个在最后主动调用 A 系统给的 url，我理解才是 api callback 。

同步异步、阻塞非阻塞的解释，建议看这篇文章，讲得非常清晰：https://mp.weixin.qq.com/s/CvImJ5Ab1J7KiKAhV0BuAQ

看一下社区置顶帖，需要跟微信绑定实名认证

你这是面试被问了吗？

谢谢。
请问接口测试的返回结果需要再一次通过数据库查询校验吗？

比如：访问了查询的接口，返回值为：'totalPages': 194, 'currentPage': 0, 'totalElements': 9677, 'elements': [.....],这些值需要去数据库查询是否正确吗，还是只需要确认大致的正确就行，比如分页逻辑是否正确等。**

我目前还没有比较好的校验手段，只能去看分页逻辑是否正确。

再比如，增加的接口，需要去数据库校验是否数据库真的增加成功了吗？**

我目前是这么做的：在增加前，使用查询接口，查询不到准备增加的数据，增加后，再使用查询接口，查询到了增加的数据，但是我看到有人是校验的数据库，所以比较疑惑。

有两种方式。

一种是你说的，去查询数据库。
另一种也是你目前在做的，使用查询接口。

两种都可以，相对来说查询数据库会更自由（因为系统可能没提供查询接口，或者部分内部字段客户端/前端用不到，查询接口不会暴露出来）。不过如果查询接口可以满足，用查询接口是最好的，后续有线上接口拨测需要的时候，可以直接复用（运维是不大可能为了这个，给你开线上数据库的权限的）

至于分页这个，抽验几个点就可以了：
1、总页数对不对
2、改变当前页数，数据是否有对应变化

实际开发写代码实现分页逻辑，这方面都有对应的库（可以百度下 mysql 分页查询），库的写法对了就很稳了，配置不对上面两个数据其中一个基本都会出问题，也很容易发现。

https://www.cnblogs.com/fnng/p/7494682.html

真的学到了很多，非常的谢谢你

谢谢！

客气啦，这些我也是和其他人交流 + 自己实践学到的，后面可以来社区多分享交流。

有条件查询数据库的，还是建议通过查询数据库进行校验
1、有些入库字段查询接口是不会返回的
2、查询接口返回的数据是经过处理的，比如枚举，比如兜底逻辑，这些都是经常出现问题的
所以数据库入库校验非常有必要的，当然没条件，只能通过查询接口了，建议跟开发一起确认好字段入库情况。

第二个点认同。

这个我觉得这个看实际需要把，各有各的道理。如果很关注入库正确性，最好是查下数据库。