最近在公司推接口测试，读了社区里很多精华帖，加上自己的实践，有些迷惑想看看大家是如何思考的？

1. 接口测试的被测对象是「接口」还是「后端服务」？
   ——问题来源于 @chenhengjie123 大佬的 7 年前的帖子《接口测试的一些感悟》的观点，其中提到：

Updated 2015.11.30
今天和 Monkey 以及公司另一位有做过 api 测试的同事交流了一下，发现了一个最根本的问题： 我的用例设计有问题

这个讲概念比较难说清楚，还是以上面提到的发表朋友圈作为例子。

假设我要验证发表朋友圈的 接口，它的工作流程如下：

上传图片，服务器返回这些图片的 url
发表朋友圈，包含朋友圈文字内容和各个图片 url 两个主要字段。服务器只会返回是否成功以及这条朋友圈的 id
我设计的正常发朋友圈的用例如下：

用上传图片接口上传图片，验证图片是否上传成功，各 url 对应文件的 md5 是否和我本地上传的图片的 md5 吻合。
用发本地圈接口发本地圈，其中图片 url 来自第一步的返回值
用查看本地圈接口查看发出的本地圈，检查它的内容、图片是否正确。
咋看之下好像没啥问题（相信做过 api 测试的童鞋已经看出问题了），但其实这个用例本身存在一个严重的问题： 接口成为了手段，验证点其实是功能。

「但其实这个用例本身存在一个严重的问题： 接口成为了手段，验证点其实是功能。」让我觉得十分疑惑，因为这正是我当前对手动接口测试执行的认知：接口是工具，是完成测试的媒介。验证的是「该接口相关的后端服务」，接口只是「后端提供的"对外交互"服务」的一部分。

上述问题的答案直接影响后续用例设计的思路和测试范围。如果我认知有问题，求骂醒

2.中小企业测试流程中，建议对新接口安排手工接口测试环节吗？在什么阶段介入比较好？
本人当前的情况：

• 公司产品是一款 App，内容向，GET 方法的接口多，少量 POST
• 准备在新功能后端开发完成后，前后端联调前开展接口测试，目的是提前发现问题和增加测试深度
• 接口用例多数是业务相关，出于业务实际情况，设计的参数类和安全类较少

目前测下来，发现较多的问题是因为后端接口变更、文档没更新导致的不一致，很少逻辑 Bug。测试精力投入却不少。还和后面同事进行的 gui 层的业务测试重合，感觉投入产出比很低。初步怀疑问题出现在：

• 测试介入环节太早，接口设计还没排版下来。考虑在联调之后，客户端提测前进行接口测试？
• 目标不够聚焦？测试用例设计的场景很全，应该挑其中重要 + 客户端无法触及的点来做，尽量减少重复测试
• 或者在当前的资源配置下没有新功能接口测试的必要？是否改变方向，做接口自动化回归（目的就变了）

3.现在大家任职的公司都有做新功能接口测试吗？ 目的是什么？效果好吗？如果好的话，是怎么做的？

感谢