接口功能测试，包含功能

那前端的功能如何保证呢？我们公司前端问题其实比较多，不能保证功能没有问题了，这条用例就放弃

后端主逻辑，先保证逻辑没有问题

理是这个理，但是对于功能测试的同学，该有的工作量还是有的，并不能节省对应的工作量，所以我的定位是不是不应该这样定位

接口自动化主要是为了回归测试用的，顺带在测试过程中可以提前发现一些业务逻辑的问题。但是就发现 bug 数量来说，还是要功能测试的时候发现的比较多，这个时候可以反过来再去补充接口用例覆盖。
我是这样理解的。

个人理解，先接口测试后可以减少功能测试时后端大部分逻辑问题，提早的介入接口测试也能让后面功能走的很流畅些，对功能测试还是会时间周期会减少些

这个怎么说呢，我觉得这个取决于你们的产品是否真的做到了前后端分离。 如果你们测试的工作没有前后端分离， 接口测试依然是压在功能测试人员， 那我个人认为大面积铺开接口测试确实不值得。 都不如写主流程的 UI 自动化来的好。

前后端分离就是前端和后端各自有自己的迭代周期和提测时间， 各自分开的。 这时候的接口测试也是会加入到持续集成中来的，可以做到尽早的发现 bug。 而不是等前后端都联调完了， 交给前端测试人员的时候才跑的。 这样才会更有效果。

接口自动化测试不是为了发现问题，是为了验证已覆盖的场景是否 ok，发现 bug 只是额外的产出，要把接口自动化持续运行起来才会产生价值

首先接口测试就是功能测试。你想想对不对，涉及到性能吗？涉及到安全吗？功能测试分手工执行和自动执行。（当然，我不喜欢聊概念）
第二：接口覆盖率没有意义！！！应该关注的是代码覆盖率。（动态插桩，检测开发的代码，有哪些是被执行过的。不了解的，可以先去了解下这个）
功能测试，接口测试，UI 测试，最终都是想提高本次增量代码或全量代码的代码覆盖率。
只有开发写的所有代码，都被我们用例覆盖了，就几乎没有漏测的情况。
自动化，手工，只是执行的方式

其实你不用在意到底是怎么定位了，因为好多高位的人其实也不知道。只是说出来糊弄人而已

赞同楼上孙高飞的回答。分层测试也要建立在具体架构和研发流程上。。。不要盲目的做。
另外有些接口拆的过于细了，你可以做按功能来的接口集成测试。
正常情况下，接口测试做完，你业务逻辑应该是差不多都覆盖到了，前端只负责展示。

只有前端功能测试，没有后端接口/服务测试的团队，搞不好质量
只有后端接口/服务测试，没有前端功能测试的团队，质量不好搞

不太认可楼上 “只有开发写的所有代码，都被我们用例覆盖了，就几乎没有漏测的情况”，具体不细说。

楼主提到的疑惑，看起来组内是分为了做接口测试和做功能测试两部分，“所以要从功能组的同学那边借资源一块编写，前期给他们培训，然后脚本编写，花了挺多资源的，但是结果好像并没有太大的产出，对于功能的同学而言，该执行的用例还是需要执行，并没有减少他们的工作量，反正增加了许多”，分成接口和功能两部分的情况下，我觉得这样借资源的处理确实是对功能测试同事没有太大益处。
一、接口功能测试。我觉得接口层的功能测试主要是去覆盖到一些前端不能触发的场景，测功能的同事可以重心放在验证客户端可触发的测试场景。举个例子，一个购买接口，功能测试同事测试点都是能从客户端触发的，余额足的时候购买余额不足的时候购买...接口测试同事可以验证修改商品 id 成已购买的 id、修改 id 成特殊符号...
二、接口自动化测试。我觉得这个是用来确认每一次代码修改后新旧接口逻辑正确性的一种方式，并不能帮助前端做什么，毕竟前端也有自己的自动化。
PS.我感觉既然内部已经接口测试&功能测试划分比较开的话，就尽量还是不要让功能测试的同学去支援接口测试吧..除非功能测试的时候接口测试同学也去支援了，不然多少有点心里不平衡鸭。而且如果做接口测试的同事水平已经到达测试开发水准的话，写脚本效率应该大大高于功能测试同事，从个人心态、脚本效率、代码质量几方面考虑，感觉都是让接口测试同事亲力亲为合适点。

总结来说：接口测试 or 前端测试，目的都是为了保障整个产品质量，接口测试的存在是为了让前端测试减少工作量的说法我认为很不靠谱。各有各的意义，不冲突，是协作关系。

这个要项目是否前后端分离吧以及测试周期吧，很简单的一个现象，功能测试就 2 个测试人员，并且客服端跟服务端基本提测的时候，一起测试，这时难道还接口测试?都来不及了，先把功能搞定了，然后看接口文档，看相关的接口参数是否有测试到，然后接口测试，或者稳定了，再来接口自动化，记得软件测试的目的：是在一定的时间内尽可能的发现问题，来降低产品发布出去给客户造成损失~
功能测试跟接口测试两者是不冲突，具体要看适用的场景，冲突的是时间~

接口自动化的定位最大的价值是做回归测试跑流程，接口测试阶段其实就是在跑无 UI 界面的功能测试验证后端的业务逻辑，在接口测试中发现问题越多那么在功能测试层面测试同学可以更专注的测试前端功能工作量也相对的减少，我是这样理解的

一、接口功能测试。我觉得接口层的功能测试主要是去覆盖到一些前端不能触发的场景，测功能的同事可以重心放在验证客户端可触发的测试场景。举个例子，一个购买接口，功能测试同事测试点都是能从客户端触发的，余额足的时候购买余额不足的时候购买...接口测试同事可以验证修改商品 id 成已购买的 id、修改 id 成特殊符号...

以前觉得接口测试可以无限覆盖各种场景，但是后来发现业务不可能触发的场景，测试了没太大意义。 因为从用户角度出发，永远不可能用到这个场景，这些测试就是浪费。 ----个人建议。

举个例子吧，我这边的项目。
有个接口是用户提交身份认证，有一次测接口，我发现如果不带 headers 里的登录字段，提交一次认证时，该环境所有注册用户的身份认证都被改变到了。
如果这个问题发生在正式环境，有人恶意调接口去做了，影响面多大.....

当然，这种需要根据项目使用人群去决定要不要做，如果你的项目是面向用户，我认为这个是必须做，没时间另说。很多时候做一些安全等层面的测试不是在防常规用户，是在防一些不常规的用户带来的攻击。ps.内部人员用的接口我都是不单独做接口测试的，前端覆盖到啥就测啥。

我觉得接口自动化测试主要是用来快速回归的吧，一次编写，重复运行，可以快速发现开发改动的代码是否影响接口的响应准确性，如果功能测试有大把的时间测试，那还要这个干嘛，闲着也是闲着，测试下前端不好吗，另外接口测试可以构造一些特殊的请求，前端传参数都是不可信的

某一个天，懂点技术的来了，抓个包试几次就发现所以东西都能 1 分钱购买，或者可以负数购买的时候，你就不这么想了

因为从用户角度出发，永远不可能用到这个场景，这些测试就是浪费
也不完全是浪费，因为对一部分安全测试来说，就是绕过前端直接到后端，所以前后端分离的接口测试，在做后端接口自动化的时候，楼上提到的改数据验证前端无法验证的一些场景就显得尤为重要了。
其实还是要看项目具体要求，有些重视安全的就一定会找专门的安全测试团队来做这个。

同困惑 在公司不知道该怎么推接口自动化

比如，你知道苹果的识别输入吗？ 当你觉得你从用户角度出发，永远不可能用到这个场景时，人家通过识别输入在只能拉起数字键盘的输入框输入汉字。