良好的 API 测试是技术企业结构的一部分，无论该公司是一家精益求精的初创公司，还是一家知名的财富 500 强企业。 全面的 API 测试 不会凭空发生。这是管理决策的结果。 API 测试的质量取决于那些负责为客户开发 API 的经理的思想和行动质量。没有哪位经理有一天一觉醒来服用了一颗药丸，从而产生了创建有效 API 测试的愿景。大多数人不得不通过艰难的方式学习。这些是他们的故事。
Mervine：开发人员有责任确保他或她的代码有效
Joshua Mervine 是一位经验丰富的技术专家，曾在技术领域的许多大公司担任过重要的行政和技术职位，例如 YellowPages.com 和 EarthLink 等。目前，Joshua 是云应用程序提供商 Heroku 的服务可靠性工程师。 Heroku 支持 Citrix、Macy's 和 Toyota 等客户的关键任务应用程序。 Heroku 是黄金时段的技术，需要在全球范围内全天候 24/7 启动和活跃。
在谈到 API 测试的管理时，Joshua 的基本立场是：开发人员有责任确保 他或她的代码能够正常工作 。
在我看来，当谈到 API 测试的管理时，首要任务是开发人员负责确保他或她的代码在单元测试级别工作并且代码被充分覆盖。开发人员真正拥有他们的代码并对其负责。 …这包括设置一切，确保它正在运行并在出现故障时快速响应。
关于责任，我可能要补充的另一件事是所有权，我在上面多次提到过。开发人员对他们的代码（也就是说，设计、PM、QA 等）拥有的越多，他们可能生成的代码质量就越高。当你介绍其他所有者时，你就引入了责任的抽象。这就是开源如此有效的原因。开发人员真正拥有他们的工作。
Roodyn：Neil 博士的 3 个秘诀
自从有网络以来， Neil Roodyn 博士 就一直在网络上工作。他曾在 Microsoft 从事 Tablet PC 方面的工作，并且是该公司的区域总监。他的公司 nsquared 是为企业制作协作工具的领导者。在软件开发界被亲切地称为 Neil 博士，他的公司拥有多种产品，其中一般测试，尤其是 API 测试是公司成功的关键部分。尼尔博士说如下：
我们与微软等大型软件公司合作，帮助定义他们的 API，我们还生产了一些我们自己的应用程序和服务，这些应用程序和服务具有供开发人员插入的接口。我们有一些我们使用的“技巧”：
- 自动化测试，针对您能想到的所有内容，然后再考虑更多。这将帮助您防止大多数向后竞争问题
- 拥有一组测试工具应用程序，使您的 API 符合要求并确保它们按预期工作。
- 在您的应用程序中使用您自己的 API；不要使用后门或“黑客”来绕过您自己产品中的 API
Mays：提前思考并为测试而构建
Steve Mays 是金融服务行业提供商 Trizic 的首席技术官。 Steve 有着令人印象深刻的工作经历，可以追溯到 NeXT 和 Broderbund。在 API 测试管理方面，他深谙此道。史蒂夫的口头禅是超前思考：
确保您提前考虑并为测试而构建。
这是我在 NeXT 学到的概念。不要手动编写代码/记录您的 API。不要等到应用层完成，因为其他人会等着你。不要制作单一的 API 头；制作模块化/自注册路由服务（API 可以像 SOA）。了解如何在 Node.JS 技术中使用现代框架/组合来使您的 Java 项目飞速发展。然后教团队使用所有这些工具。这一切都很难。不过，最后一块是最糟糕的。
Neale：API 应该直接验证并包含在集成测试中
Bennett Neale 在洛杉矶地区的许多大公司担任咨询 CTO。他是 Edmunds.com 的系统架构师，Edmunds.com 是世界上最大的汽车网站之一。他是一个敢于直言不讳的高管，一个身处战壕的人。他的观点是真实的：
…我之前咨询过的大多数项目都需要 API 开发。通常，它们是“内部”API，用于实现子系统之间的解耦。例如，使用 REST API 的 React 或 Ember 编写的 Web 应用程序的前端，以及将单体系统分解为子系统以迁移到微服务架构的过程。由于消耗 Twitter 数据，我有一个项目每天将达到数百万，但这是一个不同的野兽。体育、旅游和游戏
[管理] 政策是 API 应直接验证并包含在集成测试中。每个项目/功能必须满足许多需求，例如 SLA 和安全性。
该过程通常是创建单元测试、集成测试套件、负载测试等以生成基线，然后进行优化，无论是在软件级别还是在扩展硬件方面。
当被问及大多数公司在 API 测试方面犯的最大错误时：
无法预见系统故障，您的架构的某些部分会出现故障的情况。例如，如果您的应用程序或数据库层集群中的其中一台服务器发生故障，或者如果它们仅在 50% 的时间内响应，会发生什么情况？
这些很难测试，因为它们大多是手动的，所以很多时候都会检查它们。
那么让我们来谈谈当你没有正确测试时会发生什么。
Clark：您无法测试未发现的端点。
Matthew Clark 是 Indeed.com 的产品经理。在 Indeed.com 工作之前，Matt 是一家为全球铸造行业提供服务的主要供应商的产品开发副总裁。马特回顾了他当时面临的挑战。
我们的大多数 Web 服务端点都没有发布在任何类型的文档中。它们甚至几乎没有记录在代码中。有人尝试在 wiki (MediaWiki) 上手动记录较新的代码，但文档的采用和发现率一直很低。最近，一些新的独立服务生成了文档，这很值得一看。
[没有] 没有，API 测试政策生效。 UI 测试“证明”API 至少可以解决预期的行为，但几乎所有 API 测试都是通过浏览器进行的
当被问及缺乏测试政策对公司有何影响时，他回答说：
我们已经看到了诸如脏数据之类的经典问题。但核心问题是对我们现有的所有端点缺乏理解或欣赏，这导致了重复代码和扼杀了创造力。
在以不同方式做事方面，马特说：
我将使用发现项目启动 UI 测试策略以识别所有端点。即使有一个带有用于“记录”的是/否列的简单列表，也将是一个很好的基础。所有 API 或 Web 服务端点的绝对规模将为引起人们的关注奠定良好的基础。遗留代码没有免费通行证。我实际上会鼓励团队从最老的或最少使用的软件开始，然后继续前进。
您无法测试未发现的端点。
经销商：花钱
让我把我的帽子扔进戒指。我从事技术游戏已经超过 25 年了。我管理过团队和部门。我已经放弃了大量的代码。我测试的 API 比我的份额还多。这是我学到的重要教训：在一天结束时，一切都归结为预算。
获得胜任的 API 测试文化并不神奇。你必须花钱。对我来说，好的 API 测试是关于你的公司愿意在工具和教育上花多少钱。如果你有每年 200 万美元的技术工资单，平均约有 20 名经理和工程师，并且你每年在工具和教育上花费 50,000 美元，你可能有点轻。这 5 万美元仅占您劳动力成本的 2.5%。我？我通常会选择大约 10%，如果不是更多的话。诚然，金钱买不来智慧，但可以买到大量的效率和劳动力节省。
我之前工作过的一家公司的 CEO 有一种非常直接的方式来说明显而易见的事情。直到今天我还记得他说过的话：
我永远不希望你来找我说我们失败是因为我们没有花足够的钱。
没有比这更简单的了。花钱。
把它们放在一起
上述专家所表达的经验归结为以下几个基本点：
- 开发人员对代码负责
- 自动化你能想到的一切
- 使用你的 API（我，吃你自己的狗粮。）
- 提前思考并构建测试
- 测试 SLA 和已建立的安全策略
- 了解所有端点
- 花钱
是的，上面的要点中有很多常识。但更重要的是智慧，智慧是随着时间的推移，通过磨难和磨难而获得的。
智慧生活在那个从重大错误和凌晨 3 点的电话中吸取教训的地方。
你不能直接为自己购买智慧。你必须获得它。当然，你可以收买智者的忠告。但大多数时候，那些真正聪明的人会免费赠送它。您需要做的就是注意。
请记住，良好的 API 测试 = 良好的 API 管理。
Bob Reselman (@reselbob) 是全国知名的执行软件开发人员和技术作家。 Bob 的作品出现在 ITWorld、CodeGuru、Developer.com、DevX 和 InformIT 上。 Bob 喜欢阅读读者的意见和评论。可以通过 reselbob@gmail.com 联系到他。
