背景
公司的接口自动化是从开发提测的时候开始用例设计开发的（因为我们公司没有接口文档，只能等开发完成后自己抓包），也就是接口自动化开发和功能测试是同时进行的，等功能测试快结束之后接口自动化开发才结束。这样的情况导致接口自动化只能用作回归，开发也不太认可自动化接口的测试结果。我们自动化部门也觉得耗费了半天时间但是没有太大的成果。
问题
- 接口自动化什么时间介入比较好？ 我看了好多文章，目前有接口规范的有在接口规范定好之后介入的，有在前后端联调的时候进行的（这种方式也是我们公司有可能实现的）
- 前期是先进行单接口测试然后再根据每个场景使用接口进行组装吗？ 目前我们公司直接进行的业务流测试，没有进行单接口测试。哪种方式比较合理？
- 能说下大家所在公司的接口自动化整个流程是什么样的吗？
我们是接口自动化由开发实现（在联调完毕后），实现测试左移，如果我们介入的话最少也要在提测之后才能介入时间会过晚
针对第二点，很少会针对单一接口进行测试，都是先梳理好自动化测试场景评审完毕后，根据场景来组合接口测试
接口文档，很重要，如果没有接口文档，前端是怎么对接的？
接口测试，不同公司，执行情况可能不同；
第一种，接口开发完，交给测试进行接口测试，后面，前端就可以直接使用接口，测试等功能稳定后，再进行接口自动化；
第二种，接口开发完，后端自己测试，并通知前端，前端跟后端进行联调对接，直到接口符合前端需求，前端开发完功能后，测试人员进行功能测试，同时进行接口自动化；
你可能是属于第二种，在你项目的功能开发完，其实，接口已经对接完了，所以，接口自动化，只是起到一个冒烟测试的作用吧。
我们公司的接口 无法落地 只能自己业务 写写单接口...
我觉得前后端分离 如果是后端先完成，那么接口测试的意义比较大，测试左移提前发现错误
如果是联调后的接口 我不知道有啥意义呢 望各位指点..
小鸭子嘎嘎
回复
我目前感觉如果没有规范的接口文档的话可以和前端同时介入，因为他们联调的时候也需要沟通接口规范。这样感觉可以用更少的沟通去得到信息，现在我们有问题问开发，他们都很忙~总觉得我们耽误他们的时间
sir
回复
那你们流程就是开发完成之后自己进行单个接口的测试，然后等提测之后你们在进行自动化测试场景的开发吗？那你们的接口测试和场景开发是在一个平台吗？
接口自动化本身定位就偏向用于回归测试吧，功能测试过程中单接口测试才是重点，在开发环境通过接口自动化来验收本身就是一个成本不低的做法，个人看法。
第一次完整的接口测试有用，测试过的接口再做接口自动化没有意义，但是接口自动化升级改造为压力测试就有用了
小鸭子嘎嘎
回复
那麻烦再问一下您这边的单接口测试和多接口测试是在一个平台上吗？多接口测试的时候是对之前的单接口进行组装还是重新开发？单接口测试是使用的工具还是脚本还是自己的测试平台？
- 在明确业务后进行
- 根据实际情况，我们就是先单接口，再流程
- 和功能测试一样，没啥特别流程
xufei
回复
我们都是用 postman 或者 jmeter；
单接口：针对单个接口，进行测试，主要是参数校验，数据校核，比如，用户管理，单接口，就有，新增用户，删除用户，修改用户；
多接口：针对多个单接口，进行串联测试，比如：新增用户之后，修改这个用户，再删除这个用户，还可以给这个用户设置角色，设置职位，设置密码，，这些都是属于业务测试，也就是多接口测试，主要就是会对同一条业务数据，进行多接口串联测试；
使用 jmeter 或者 postman 就能够实现了，并且这两个工具，都可以做自动化。
1、什么时候介入，对于没有特别规范的接口文档输出的或者接口变更比较频繁的，实践出来比较好的时间点是在开发集成的后半段介入，在开发转内测前完成效果较佳。集成后半段基本该改的接口会改的差不多，变更不会那么大，接口文档可以通过工具类生成，因为有代码了。
2、单接口的测试建议可以工具化实现或者由开发实现，测试重点做场景化接口测试。
这边是只做业务流接口自动化，接口文档不齐，都是自己抓包。新增功能功能上线后，排期去写。
自动化测试本来的定位就是偏向于回归和历史版本的验证。 跟随迭代进程，可以做接口测试 而不是接口自动化测试。 承对于不稳定功能的自动化落地成本太高了
怎么使用，主要取决于你们的使用，接口测试包含输入参数的测试、字段必填的测试、多接口等等，如果用来回归，那偏向多接口，如果是保证测试左移，那就要设计更多的用例
小鸭子嘎嘎
回复
你好，我一直有个疑问，在单接口测试时，像你说的比如删除用户接口。要测试这个接口，依然要调用新增用户接口来生成用户 id，这样的话不也是多接口串联测试吗。那为什么要把多接口场景测试单独抽出来？