本篇内容是基于 4 月 19 日极狐 GitLab 举办的江狐会第十九期「研发团队的全生命周期治理实际」线下分享会中，Apifox 产品与经营 VP 张路宇所分享的《API 测试经济学与 API First 践行》课题内容整顿公布。
大家好，我先简略自我介绍一下。我是 Apifox 产品与经营的负责人张路宇，过来在 CODING 做了四年，接触很多各式各样的企业。尤其是 CODING 自身有用户根底，我大略接触过近 100 万的开发者团队，国内各式各样的都见过。那么我明天聊的话题是 《API 测试经济学与 API First 的实际》，从 4 个方面开展，别离是自动化测试伎俩的 ROI、做 API 测试的挑战、API First 理念以及最初简略聊聊 Apifox 这个产品。
自动化测试伎俩的投入产出比
首先咱们来聊 自动化测试 这个话题。
国内的状况，我过来见过的任何团队，包含我供职过的团队，都是每过半年或一年，就要静止式的搞一次自动化测试。说白了就是某个事搞得不好，或者说间断性的遇到一些问题，或者老板感觉哪里可能有点问题，就会搞一次。然而如果回顾来看，真正能把这件事搞好的团队不多。
这是 JetBrains 去年的开发者生态报告，能够看到近 50% 的团队感觉自动化测试的笼罩只有一些成果；但 79% 的受访者示意自动化测试十分有用。第二个图是统计我的项目中的测试类型，绝大多数是单元测试，其余的类型绝对比拟少，且辅助数据显示，85% 的单元测试开发者本人写的。
从这份统计中咱们能看到，自动化测试总体覆盖率还不高，而且这还是海内的数据，国内就更不用说了。当一个组织要去考量做自动化测试的时候，须要沉着思考四个因素：老本、覆盖率、效应及人员程度。这四个必须联合到一块能力做好。
1. 单元测试
各种软件工程的学术研究都认为 单元测试是总体上收益最高的一种形式 。它惟一的问题是 对开发人员的程度要求比拟高 。但我看到实在的状况是， 国内产品整体的迭代节奏是不平衡的。个别如果有一个两周的迭代，可能前七八天在干活，最初几天疯狂修 bug 和测试。这个节奏很难做自动化测试。
2. UI 自动化测试
UI 自动化测试是很多人都感觉应该做的事，但我感觉这件事不太好做。比如说腾讯外部有个 UI 的自动化测试工具，很多年前用的。只有极少数 to C 产品在用 ，比方 QQ 这样产品体量十分大的产品是必须要用。那为什么腾讯这样的大公司的其余产品不晓得做 UI 自动化测试？有两个起因，第一是 国内产品的 UI 变度十分高 。第二是因为 UI 变度很高导致 自动化测试用例保护起来十分艰难，基本上是牵一动员全身。
我认为 UI 自动化测试老本是较高的，覆盖范围尽管好，但 总体效率低，所以我不太倡议大家去做 UI 自动化测试。
3. API ⾃动化测试
第三个是 API 自动化测试。API 在这几个环节中绝对效益较高，老本较低的。尤其是 API 的定义，测试过程你可能在开发环境做了，只有前面有一般的工作人员上就能做，对人员程度要求绝对较好，我感觉总体来说应该是一个 比拟平衡 的形式。
这个经典的测试金字塔是 20 年前 Mike Cohn 提出的，它的核心理念是，如果从收益和效率下来谈，单元测试是老本最低、效益最高的；而越往上，像端到端包含 UI 策动和人工策动，老本是十分高的，然而效率没有那么快。
API 测试是属于单元测试和端到端两头的一个比拟平衡的点，它是绝对黑盒的，也就是说并不一定要开发人员能力做，其余的内部人员能也能做。这个波及到国内和海内团队的人员配比。海内当初的状况，比方硅谷公司，总体来说测试人越来越少，基本上是测试左移，把大部分精力放在研发上；但国内状况是，测试很边缘，数量很多，然而可能也帮不上忙，还占了一个地位。
如果就算一笔账的话你会发现：人工测试的人员耗费者比拟大；UI 测试的个人员耗费只须要一两个人，然而工夫比拟长；API 的人员耗费如果只算测试，其实是起码的；而单元测试是开发人员在做。
国内当初的状况是黑盒测试比拟多，但它是不太能复用的。可能单元测试和 API 测试还比拟能复用，其余都没法复用。
API 测试笼罩的劣势和挑战
方才简略的论证了四种自动化测试伎俩中 API 测试是比拟均衡的、值得去做的。接下来剖析一下可能遇到的挑战和收益。
API 自动化测试的劣势
首先就是 覆盖范围广，你能够通过比拟快的执行效率，把它集成到 CI 上，几分钟就能实现残缺的一次回归测试。
第二个劣势是 初建成本低。即便你是静止式搞一波，也不须要很长时间。一个团队可能 2-3 周就能把整个的体系建起来，只不过选用什么工具和形式去测是值得做抉择的。
还有一个十分适合的起因，就是 对 AI 原生敌对。API 的定义，无论是代码层面，还是 Swagger 的 OAS 规范，总体上是申明式的货色。而最近通过对 GPT 等模型测试结果显示 80% 的用例是能够通过 AI 去霎时实现设计的。这老本并不高，相当于提前用自然语言写好需要，给 AI 提供上下文就能够主动实现 80% 的内容，最初只需稍作批改调整就能够间接用了。
API 自动化测试的挑战
然而，也面临一些挑战。第一是 变更保护老本很高 ，方才说静止式搞一波很容易，但搞完后过段时间可能不保护了，有很多这样的状况；第二是 接口依赖问题，实质的问题是 API 的频繁变更导致的用例的保护老本变高。
这是去年对 1,000 多万开发测试人员进行“测试胜利所需的重要技能”的调研数据，结果显示最重要的是 API 测试能力。
左侧是去年海内开发人员的另外一个数据，测试人员用过最多的框架是 Postman 和 JUnit。Postman 是 API 调试工具，调试也是测试的重要环节。右侧数据是对于“开发者认为改良 API 品质的措施”的调研，排名第一的是“写一个比拟好的 API 文档”，认为这个对前面的流程有帮忙。这个调研后果反映了 API 当初的设计、定义和测试环节是断层的，是个痛点。
联合两份数据咱们能够看到，测试人员用最多是 Postman，测试人员认为改良 API 品质措施最重要的是提供一份好的文档，但 Postman 是没有很好解决这个问题，它没有提供一个好的 API 文档。
API First 理念实际
所以 接口继续迭代，如何显著升高 API 测试用例的保护老本 ，是咱们面临的一个外围问题。业界先进团队是如何解决这个问题的？其实就是 API First，契约优先 这个理念。
API First 是让技术研发团队在开发过程把 API 当做优先思考事项的一种策略实际。在晚期就把所有精力投入到 API 后期的探讨。它与传统代码优先模式最显著的差别是，当 API 实现了优先定义和申明之后，所有的团队成员能够 提前进入到沟通之中 ，前后端人员和测试人员能够 实现异步或并行的开发模式，而不必过来那种后端组织前端，前端组织测试的形式。这是 API 测试一个外围。
另外，API First 有一个契约优先的概念。它有一套外围的标准，在这套标准上申明式的去发明 API。Swagger 也是有契约优先的理念在其中的，但这种和 API First 还是有区别的。Swagger 是先写代码，而后在下面套 Swagger 的定义，通过正文把它生成一个 Swagger 文档。但 API First 是 先通过 Swagger 或者其余自然语言去刻画实现接口定义，通过它去生成 API 的调用代码、服务代码和测试代码的框架，最初只需补充逻辑就实现了。
这两个调研结果显示 40% 以上的后端开发人员每周超过 20 个小时的工夫在 API 的开发流动上，有 75% 的团队认为 API First 的投入是十分值得，能够让他们工作更开心，防止有效沟通浪费时间，进步开发品质。
如果你的团队想要实现 API First，须要哪些研发流动和工具？第一个环节是 API 设计 ，目前用的较多的形式可能是在 word、XMind、飞书下来做提前设计，但 API First 能够应用 Swagger，但 Swagger 在第一环节不太敌对，更适宜 第二环节契约定义和文档 。 第三个是 Mock，你的 API 定义完后，线上会生成一份 Mock 好的接口，前端人员就能够开始联调了，后端人员也能够独自写他的代码，是并行的，测试人员能够提前针对这个 API 定义去做测试用例的设计，并提前查看逻辑问题。第四步就是开发 ，这个环节用的最多的是调试工具是 Postman， 第五就是集成测试，能够用 Swagger 或 JUnit。
从这五个环节能看到一些共性。第一，从第一个环节到第五环节，都存在围绕 API 定义的契约，但这 数据在工具定义上是不通用的 ，从上游到上游始终要扭转。第二， 工具存在断层，从第一个环节到第五环节的数据全副是断裂的，这是一个外围问题。所以你的团队如果是 API First，在实践上会存在一些艰难，这也是为什么咱们会去做 Apifox 这个产品。
Apifox 利用与劣势
Apifox 最早是两年前由咱们老板 Jesse 一手开办，最开始是在社区上流传，总体一片好评，有十分高的广度，所以起初才把这个产品做成了公司。
最早的时候，Apifox 与 Postman 有些相似，是一个调试工具，然而当初 Apifox 的产品状态曾经产生了扭转，是一个 API First 的原生实际，一站式笼罩 API 设计、开发和测试 。Apifox 的外围就是解决了目前市面上没有解决的问题—— 实现多种角色 API 设计者、开发者、测试者在一套工具和数据下来进行协同，尤其是后面说到的 API 定义局部。
Apifox 当初笼罩的性能比拟多，你的 API 设计能够在 Apifox 下来做可视化设计，也反对从 Swagger 导入，还能够通过咱们的 IDEA 插件从代码生成接口文档，甚至将来能够会从仓库搬进 Apifox。所以 API 定义搬运到 Apifox 上不是问题。
第二，Apifox 提供了 Mock 性能，这可能是国内最好的调试体验。国内有些 API 设计不是很标准，比方一些银行的接口不是 RESTful 标准，如果用 Postman 这种工具不太好调，因为它可能报错说 URL 已存在，毕竟不是为国内环境设计的，但 Apifox 对这种状况有很好的兼容，同时咱们简直反对所有的 API 协定，除了 HTTP 之外还反对 Dubbo 和 gRPC。咱们心愿与 API 无关生态游上的人员都在能 Apifox 下来做开发。
咱们有两个比拟受欢迎的外围性能。
第一个就是 API 文档，能够通过 Swagger 或者可视化设计一键失去一个界面粗劣、能够分享给外部、也能够公布到内部站点的 API 文档。同时 API 调用者和阅读者能够间接在下面进行 API 的调试。
第二个是 自动化测试 ，与市面上其余工具的区别是，如果 API 设计者定义完接口后，他的 API 的定义能够沿用到上游。举个例子，比方后端架构师做了 API 设计后给前端，前端在调的时候就会留下许多痕迹，都会保留到平台上，而后再到上游的时候，API 设计者和测试者就能够沿用后面其他人用过的所有货色。这意味着第一个环节定义完之后，到最初一步到测试者，他简直是不须要去定义 API 用例了，他真正实现了契约优先。咱们的自动化测试编排里不须要写 API 申请，而是间接从原先的 API 定义中拿数据。如果你的上游也在平台上，那就意味着他那边变更后，你这里也会主动变更。这个就是咱们去贯彻 API First 理念的一个外围形式， 让所有的这个角色设计、调试、联调、测试四种角色在一套数据同一套平台下来实现信息的共享和协同。
以上就是我明天分享的全部内容，感激大家凝听。