标题命名有些大，可以做且需要做的方向与内容，其实远不止下述提及。本质上应包含多个维度，如运营、管理、技术等诸多内容。文章内容仅以些许细点方向描述之，理想模式即 DevOPS + 合格管理

    目的：编码完即测试完（至少大幅降低滞后性，可容忍2-3个工作日的差别）；需能减少编码工作量且大幅增加开发效率，同时还需要能提升系统质量。

    1. 研发流程明确（尤其需求得可控）
    2. 接口管理系统与测试平台的明确
    3. 前后端并行(分裂型)开发（需要有一定编码的人力资源，更重要的是技术团队同时要求了前端开发者需要较好的综合能力）
      mock 引入
    4. 自动化
      主要有以下两个层面，产出收益较明显
    • 自动化打包与发布
    • 接口自动化测试（这里主要考虑怎样减少维护成本——维护场景化是代价特别高的，做产品则代价也只相对小一点。考虑能否从工业自动化中抽象出模式来）
    • 业务数据工厂
    • 监控与问题追踪

    接口文档管理系统与接口测试平台的方案选型与对比：

    • swagger2 + postman / advanced rest client 之流
      • 优点：对于开发者友好，轻量级
      • 缺点：postman 在团队协同时，有较高付费，不适用于中大型团队；且需改造
    • swagger2 + 自研接口测试平台（与 swagger 的 yaml / json 文件对接）
      • 优点：对于开发者友好，轻量级
      • 缺点：Swagger有一定侵入，且不一定贴合开发侧的上层设计规范（但可改造）
    • 代码生成器/接口文档生成器 + 自研接口测试平台 (PaaS)
      • 优点：文档维护量小，对于开发者友好；适合不同的角色开展工作，能贴合研发过程
      • 缺点：文档不通用，贴合于开发侧的上层设计规范
    • eolinker 平台(PaaS)
      • 优点：通用，维护成本高
      • 缺点：定制化难以有效或快速支持
    • apidoc 组件
    • 阿里的 Rap2
      • 优点：有 mock 支持
      • 缺点：纯开发者思维，对研发过程没有太多价值
    • 其他方式如 soapUI、jmeter、fiddler 等SaaS，或自开发 SaaS
      • 团队协作的支持不友好，极易有较高负债


    • 优雅实现
      • 非侵入式的探针技术(如CGLib、ASM、Java agent等) + 自研平台

    这里着重讲上述情况，在绝大多数团队中必然会踩到的坑，遇到的问题且最终导致流产的现象如下：

    1. 开发维护工程的文档不及时
    2. 测试人员维护开发工程的接口文档有严重滞后性
    3. 测试人员因为开发工程的分散性(如工程服务以分布式或伪分布式实现)，难以维护文档
    4. 开发岗与测试岗本身关注的视角不一致。前者面向领域或模块集成；而后者通常面向E2E表现，是系统级的
    5. 测试对工具、框架的选型或实现(比如做了个玩具工程，不适用于企业级)，导致最终难以为继