背景：
一、在敏捷研发流程里进行持续交付，不管是研发、测试小伙伴们对质量都要贡献自己的力量，尤其是测试同学，并发多个需求测试，在整个团队资源固定的前提下，测试资源成为交付的瓶颈。
二、接口测试背景：
开发 - 在公司研发脚手架里会集成 Swagger 类似的在线 APi 管理平台，如果传统的，一般是 word/execl 线下留存的文档；

测试- 1）基于在线 APi 管理平台、jemeter,postman 等工具来完成接口测试任务；2）基于接口测试平台，去填充接口测试案例
接口测试难度： 接口测试分为参数和业务逻辑验证，参数越多，验证的复杂度环比就会上升，对测试来说，有很大的复杂度，尤其是庞大的微服务下业务接口，让测试没有精力去维护，完善接口测试脚本

方案：测试圈里开始发起测试左移和右移的观点，我也非常同意这种思路。
今天分享下测试左移 - 接口测试左移如何展开，针对背景中描述的两块内容，我们提炼下，接口测试如果降低测试成本，要做哪些事情，谁负责去完善 ；
目前分工：
1、接口测试方案设计 -- 开发
2、接口测试定义 -- 开发
3、接口测试用例编写 -- 测试
4、接口测试用例执行 -- 测试
5、接口测试脚本编写/接口测试平台维护；--测试
6、接口测试回归；--测试；

左移后：
1、接口测试方案设计 -- 开发
2、接口测试定义 -- 开发
3、接口测试用例编写 -- 测试/开发
4、接口测试用例执行 -- 开发
5、接口测试脚本编写/接口测试平台维护；--开发编写、测试 check
6、接口测试回归；--开发

抛一个问题： 怎么支撑开发去完成一个接口测试呢？
1、敏捷团队去引导
2、测试框架支撑；

具体怎么操作：

提交发布流程：

测试接口标记

测试接口展示

以上流程，测试研发团队需要做哪些工作：
1、开发接口测试脚手架： 包含接口测试用例脚本自动生成；
2、测试脚本集成发布流程；
3、测试平台聚合可视化： 覆盖率，回归等等；

接口测试用例脚本生成下个时间再分享......

以上是个人观点，有任何疑问欢迎指正！！！