最近在公司推接口测试，读了社区里很多精华帖，加上自己的实践，有些迷惑想看看大家是如何思考的？
- 接口测试的被测对象是「接口」还是「后端服务」？
——问题来源于 @chenhengjie123 大佬的 7 年前的帖子《接口测试的一些感悟》的观点，其中提到：
Updated 2015.11.30
今天和 Monkey 以及公司另一位有做过 api 测试的同事交流了一下，发现了一个最根本的问题： 我的用例设计有问题这个讲概念比较难说清楚，还是以上面提到的发表朋友圈作为例子。
假设我要验证发表朋友圈的 接口，它的工作流程如下：
上传图片，服务器返回这些图片的 url
发表朋友圈，包含朋友圈文字内容和各个图片 url 两个主要字段。服务器只会返回是否成功以及这条朋友圈的 id
我设计的正常发朋友圈的用例如下：用上传图片接口上传图片，验证图片是否上传成功，各 url 对应文件的 md5 是否和我本地上传的图片的 md5 吻合。
用发本地圈接口发本地圈，其中图片 url 来自第一步的返回值
用查看本地圈接口查看发出的本地圈，检查它的内容、图片是否正确。
咋看之下好像没啥问题（相信做过 api 测试的童鞋已经看出问题了），但其实这个用例本身存在一个严重的问题： 接口成为了手段，验证点其实是功能。
「但其实这个用例本身存在一个严重的问题： 接口成为了手段，验证点其实是功能。」让我觉得十分疑惑，因为这正是我当前对手动接口测试执行的认知：接口是工具，是完成测试的媒介。验证的是「该接口相关的后端服务」，接口只是「后端提供的"对外交互"服务」的一部分。
上述问题的答案直接影响后续用例设计的思路和测试范围。如果我认知有问题，求骂醒
2.中小企业测试流程中，建议对新接口安排手工接口测试环节吗？在什么阶段介入比较好？
本人当前的情况：
- 公司产品是一款 App，内容向，GET 方法的接口多，少量 POST
- 准备在新功能后端开发完成后，前后端联调前开展接口测试，目的是提前发现问题和增加测试深度
- 接口用例多数是业务相关，出于业务实际情况，设计的参数类和安全类较少
目前测下来，发现较多的问题是因为后端接口变更、文档没更新导致的不一致，很少逻辑 Bug。测试精力投入却不少。还和后面同事进行的 gui 层的业务测试重合，感觉投入产出比很低。初步怀疑问题出现在：
- 测试介入环节太早，接口设计还没排版下来。考虑在联调之后，客户端提测前进行接口测试？
- 目标不够聚焦？测试用例设计的场景很全，应该挑其中重要 + 客户端无法触及的点来做，尽量减少重复测试
- 或者在当前的资源配置下没有新功能接口测试的必要？是否改变方向，做接口自动化回归（目的就变了）
3.现在大家任职的公司都有做新功能接口测试吗？ 目的是什么？效果好吗？如果好的话，是怎么做的？
感谢
额，我这个文章已经比较老了，没想到还这么多人看。
我当时的文字描述可能有点引起误解了，我当时的误区是：想通过接口自动化测试这个方式，去做非常详细的后端服务测试，甚至包括上传后存储的图片内容对不对这种级别的校验。而实际上，对于这个功能，用接口自动化去测试，相比直接人工做接口测试（上传一个图片后，直接打开返回值里的 url ，人工确认一下两个是否一致），性价比比较低。这个并不代表接口测试，就不用去测试后端服务的功能哈。
所以对于标题里的问题，我的观点是：测试的是后端服务。
然后对于第二个点，，你现在的现状其实对让接口测试产生比较明显的收益是不利的：
1、接口设计频繁变更，意味着很难并行，只能等开发功能都联调完毕，设计不再改后再开始开展。而一般调好后客户端其实都差不多可以提测了，这时候做单独的接口测试不如直接做客户端整体集成测试性价比高。除非测试团队后端和客户端是分开的，后端测试团队专职做接口测试。
2、一般对于新接口的测试，核心的目的应该是在接口设计稳定的前提下，提前测试确认后端服务提供的功能正确，减少联调期间由于服务端接口功能问题引起联调不通，问题排查时两端都得排查的高成本。如果没有接口设计相对稳定这个前提，而是一旦联调接口设计就各种改甚至推倒重来，那接口测试很难发挥威力。
建议先想办法提高团队对接口设计质量把控的能力，让接口设计能尽量稳定下来，而不是一到实现或者联调层面就各种修改吧。
额，我这个文章已经比较老了，没想到还这么多人看。
我当时的文字描述可能有点引起误解了，我当时的误区是：想通过接口自动化测试这个方式，去做非常详细的后端服务测试，甚至包括上传后存储的图片内容对不对这种级别的校验。而实际上，对于这个功能，用接口自动化去测试，相比直接人工做接口测试（上传一个图片后，直接打开返回值里的 url ，人工确认一下两个是否一致），性价比比较低。这个并不代表接口测试，就不用去测试后端服务的功能哈。
所以对于标题里的问题，我的观点是：测试的是后端服务。
然后对于第二个点，，你现在的现状其实对让接口测试产生比较明显的收益是不利的：
1、接口设计频繁变更，意味着很难并行，只能等开发功能都联调完毕，设计不再改后再开始开展。而一般调好后客户端其实都差不多可以提测了，这时候做单独的接口测试不如直接做客户端整体集成测试性价比高。除非测试团队后端和客户端是分开的，后端测试团队专职做接口测试。
2、一般对于新接口的测试，核心的目的应该是在接口设计稳定的前提下，提前测试确认后端服务提供的功能正确，减少联调期间由于服务端接口功能问题引起联调不通，问题排查时两端都得排查的高成本。如果没有接口设计相对稳定这个前提，而是一旦联调接口设计就各种改甚至推倒重来，那接口测试很难发挥威力。
建议先想办法提高团队对接口设计质量把控的能力，让接口设计能尽量稳定下来，而不是一到实现或者联调层面就各种修改吧。
你们这种情况做做接口自动化回归就行，变来变去成本太大。
我一直觉得，只有当环境趋于稳定时，自动化才是有意义的。大面积的维护代码是件很痛苦的事。。。
1、你面对的不是接口，而是接口背后的服务或平台。只关心接口（出参 入参）本身，不去深入了解接口背后的技术实现逻辑、方案以及数据流，是不可能设计出有深度有质量的测试用例的。不少人甚至市面上一些文章都认为 接口测试就是发送请求，验证响应，再发送请求，验证响应......这是一种严重的误导
2、从 bug 数量上，服务端测试发现的问题肯定是不如前端交互和 UI 的；但从 bug 价值上，绝对是优于前端的
3、其他的问题，如接口变化频繁、什么时候介入... 这些都是考验 lead 管理智慧的问题
4、最后再说一句：没有一支强悍的服务端测试团队，测试是很难跟其它团队抗衡的。
3.现在大家任职的公司都有做新功能接口测试吗？ 目的是什么？效果好吗？如果好的话，是怎么做的？
有做
目的是发现后端问题
效果上, 可以说有的问题功能测试没有可能发现, 比如涉及概率或是复杂数值部分, 参数合法验证, 异常情况的判断
做法, 这边是小公司, 测试给了足够大的权限, 可以说和开发一样, 直接有源码可以用, 编写测试方法测试
1：关于老是接口变更，如果接口是基于 swagger 的还好，可以有技术手段，同步到接口测试用例中
2：接口最好是基于录制来生成，省些事
3：维护接口的成本高，如果支持断言，参数提取拖拉，再加上有调用链，还是方便多了
不过不稳定期，不要忙着上接口，相对稳定了，再来做接口测试，维护量小得多
可以看看我写的这个https://testerhome.com/topics/30495 ，里面有些东东，可能有些用
我反倒觉得，自动化远远不是以自动化程序的方式去测试现有的接口，而是自动化所能解决的痛点。
自动化也不是局限于写接口自动化脚本。
对于现在的你或你们公司而言，能够通过 “自动化” 解决接口频繁变动带来的测试成本才是痛点，你能解决这个痛点才是价值。