最近，小编身边有人提出一个问题：
背景
公司的接口自动化是从开发提测的时候开始用例设计开发的（因为我们公司没有接口文档，只能等开发完成后自己抓包），也就是接口自动化开发和功能测试是同时进行的，等功能测试快结束之后接口自动化开发才结束。这样的情况导致接口自动化只能用作回归，开发也不太认可自动化接口的测试结果。我们自动化部门也觉得耗费了半天时间但是没有太大的成果。
问题
接口自动化什么时间介入比较好？我看了好多文章，目前有接口规范的有在接口规范定好之后介入的，有在前后端联调的时候进行的（这种方式也是我们公司有可能实现的）
前期是先进行单接口测试然后再根据每个场景使用接口进行组装吗？目前我们公司直接进行的业务流测试，没有进行单接口测试。哪种方式比较合理？
能说下大家所在公司的接口自动化整个流程是什么样的吗？
观点一
接口文档，很重要，如果没有接口文档，前端是怎么对接的？
接口测试，不同公司，执行情况可能不同；
第一种，接口开发完，交给测试进行接口测试，后面，前端就可以直接使用接口，测试等功能稳定后，再进行接口自动化；后端开发完，会有接口出来，单接口，测完，会进行业务测试，就涉及到多接口。
第二种，接口开发完，后端自己测试，并通知前端，前端跟后端进行联调对接，直到接口符合前端需求，前端开发完功能后，测试人员进行功能测试，同时进行接口自动化；
你可能是属于第二种，在你项目的功能开发完，其实，接口已经对接完了，所以，接口自动化，只是起到一个冒烟测试的作用吧。
我们都是用 postman 或者 jmeter；
单接口：针对单个接口，进行测试，主要是参数校验，数据校核，比如，用户管理，单接口，就有，新增用户，删除用户，修改用户；
多接口：针对多个单接口，进行串联测试，比如：新增用户之后，修改这个用户，再删除这个用户，还可以给这个用户设置角色，设置职位，设置密码，，这些都是属于业务测试，也就是多接口测试，主要就是会对同一条业务数据，进行多接口串联测试；
使用 jmeter 或者 postman 就能够实现了，并且这两个工具，都可以做自动化。
观点二
我们是接口自动化由开发实现（在联调完毕后），实现测试左移，如果我们介入的话最少也要在提测之后才能介入时间会过晚。
针对第二点，很少会针对单一接口进行测试，都是先梳理好自动化测试场景评审完毕后，根据场景来组合接口测试。
观点三
1.什么时候介入，对于没有特别规范的接口文档输出的或者接口变更比较频繁的，实践出来比较好的时间点是在开发集成的后半段介入，在开发转内测前完成效果较佳。集成后半段基本该改的接口会改的差不多，变更不会那么大，接口文档可以通过工具类生成，因为有代码了。
2.单接口的测试建议可以工具化实现或者由开发实现，测试重点做场景化接口测试。
其他观点
1.接口自动化本身定位就偏向用于回归测试吧，功能测试过程中单接口测试才是重点，在开发环境通过接口自动化来验收本身就是一个成本不低的做法，个人看法。
2.第一次完整的接口测试有用，测试过的接口再做接口自动化没有意义，但是接口自动化升级改造为压力测试就有用了
3.在明确业务后进行；根据实际情况，我们就是先单接口，再流程；和功能测试一样，没啥特别流程。
4.自动化测试本来的定位就是偏向于回归和历史版本的验证。 跟随迭代进程，可以做接口测试 而不是接口自动化测试。 承对于不稳定功能的自动化落地成本太高了
5.怎么使用，主要取决于你们的使用，接口测试包含输入参数的测试、字段必填的测试、多接口等等，如果用来回归，那偏向多接口，如果是保证测试左移，那就要设计更多的用例。
最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！
