API代表应用程序编程接口。它是一个通用的软件实用程序，它接受输入参数并根据特定的业务逻辑提供所需的输出。当我们讨论API开发时，这样的过程需要在安全性，业务逻辑处理，有效的输入数据参数，数据类型等方面进行严格的测试。如果没有对任何API进行彻底的测试，那么这样的API将有许多问题，这些问题可能导致合作伙伴应用程序出现故障，甚至在其整个生命周期内出现安全漏洞。
为了彻底进行API测试，我们将讨论在API测试期间经常发生的9个常见错误。我们不仅要讨论这些错误，还要提供简单的解决方案，以帮助改进API测试方法、运行状况和测试结果。
1、错误的条目：
通常可以观察到，当使用一组必需的输入参数对API进行单独测试时，它工作得很好，但是当与合作伙伴集成时，它开始出现行为错误和故障。这是因为伙伴可能正在为某些必需字段发送'NULL'值，这些值在集成模式下可能难以弄清楚。
它有一个简单的解决方案，即在测试期间，当API接收到“NULL”或错误条目作为输入参数时，我们应该有测试用例来覆盖它的行为。API应向合作伙伴发送响应，并返回适当的错误消息，其中可以声明来自合作伙伴应用程序的输入数据不正确且API正常运行。
2、无效响应：
API响应可能像HTTP 200一样成功，或者像404（即找不到资源）那样失败。有时，从API返回的格式不能被合作伙伴应用程序消化（处理），因为它可能会在字段数量上存在差异。
测试的解决方案非常简单，响应中的字段数量应该明确定义成功和失败响应消息，并应在所有类型的API响应中一致地测试。
3、缓存API响应：
API充当一个黑盒，接受输入参数并针对所触发的所需业务功能提供响应。合作伙伴应用程序可以选择缓存来自API的相同重复输入参数集的输出响应。现在，如果对于相同的输入参数，API的输出经常发生更改，那么伙伴应用程序的缓存输出结果将过时，并传递不正确的信息。
它有一个简单的解决方案，尽管API按预期工作，但是合作伙伴应用程序必须决定它们需要缓存什么结果，不需要缓存什么结果。如果结果像实时数据一样经常从API更改，则不应执行缓存；但如果有产品图像、描述等不希望经常更改的结果，则可以在合作伙伴应用程序中缓存。
4、处理False Negative（错误否定）回应：
通过HTTP将响应返回为200时的API被视为成功，但此类响应也可能具有空值，这是False Negative（错误否定）的情况。虽然合作伙伴应用程序会将这样的响应读取为成功，但是响应中的那些NULL值对它们有意义吗？这是针对False Negative需要实际测试覆盖的地方。
5、团队沟通失败：
随着API基于用户体验和业务变化而增长，API维护变得非常重要。这是需要最佳团队沟通的地方。不应该发生API更改，并且已经开始影响所有合作伙伴应用程序的情况。任何对API或合作伙伴应用程序的更改都应该得到良好的沟通、实现、集成和测试。此外，标准接口API文档的版本应动态更新，以避免开发人员的任何不良开发实践。
6、非标准编码方法：
API开发团队应在输入参数和输出响应参数方面就特定的标准方法达成一致，任何与该标准的偏差都将直接导致API拒绝输入（或合作伙伴应用程序响应）。有时开发人员接受空白null作为输入或输出，这可能会导致长期问题。应明确定义数据类型（强制或非强制）、范围、阈值等，测试应根据此类标准对API进行测试，任何与此类标准的偏差都不应以任何方式被接受。
7、确保字符集：
API应为输入和输出参数指定接受的字符集，如ASCII，Unicode等。这是为了确保合作伙伴应用程序正在与约定字符集的API交互，并且在约定范围之外接收到的任何字符都会导致直接拒绝。此外，如英语、法语、西班牙语等作为回应的语言应事先达成一致。我们的测试用例应该对商定的字符集和语言的所有这些要求覆盖完全。
8、API与合作伙伴应用的兼容性
建立API时要牢记合作伙伴应用程序的兼容性。除了添加到API或合作伙伴应用程序中的新功能之外，任何来自API端或合作伙伴应用程序端的发布都应针对所有现有测试用例进行回归测试。换句话说，API或合作伙伴应用程序的所有版本都应始终满足兼容性标准。
9、运用你的测试技巧：
API可能有许多隐藏的问题，通过一个经验丰富的测试团队所拥有的测试技能，这些问题实际上可以被发现。建议测试人员执行异常场景测试，以捕获传统测试实践无法捕获的缺陷。测试人员可以通过Monkey测试来破坏API，这将为开发人员编写一个非常健壮和智能的高效API提供很大的空间。
结论
在API测试中，如果没有很好的编码和测试，任何API都不可避免地存在缺陷。它要求测试人员设计有效的测试用例，避免本文中讨论的常见错误，并利用他们的测试技能，以便为生产提供一个高效、测试良好的最终产品。
译文，自《Common Errors Made During API Testing》一文