深度分享 | API 测试经济学与 API First 践行
本篇内容是基于 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 理念的一个核心方式，让所有的这个角色设计、调试、联调、测试四种角色在一套数据同一套平台上去完成信息的共享和协同。
以上就是我今天分享的全部内容，感谢大家聆听。
