API测试期间经常发生的常见错误

多测师12

　　API代表应用程序编程接口。它是通用的软件实用程序，可以接受输入参数并根据特定的业务逻辑提供所需的输出。当我们谈论API开发时，该过程需要在安全性，业务逻辑处理，有效的输入数据参数，数据类型等方面进行严格的测试。如果未对任何API进行彻底的测试，则该API将存在缺陷。问题以及这些问题可能导致合作伙伴应用程序出现故障，甚至可能导致整个生命周期中的安全漏洞。
　　API测试期间经常发生的9个常见错误：
　　行为不当：
　　通常会观察到，当使用一组必需的输入参数对API进行单独测试时，API可以正常工作;但与合作伙伴(例如web前端)集成时，API会开始出现异常和故障。这是因为合作伙伴可能正在为某些必填字段发送“ NULL”值，这在集成模式下可能很难弄清楚。它有一个简单的解决方案，即在测试期间，我们应该具有测试用例来涵盖当API收到“ NULL”或错误的条目作为输入参数时的行为。API应该使用适当的错误消息将响应发送回合作伙伴，在该错误消息中，API可以指出来自合作伙伴应用程序的输入数据不正确并且API可以正常工作。
　　无效的回应：
　　API响应可能像HTTP 200代码一样成功，也可能像404这样失败，即找不到资源。有时，从API返回的格式对于伙伴应用程序来说是不可消化的，因为它的字段数可能有所不同。测试解决方案非常简单，应明确定义成功和失败响应消息的响应字段数，并应在所有类型的API响应中进行一致的测试。


　　​
　　缓存API响应：
　　API充当黑匣子，接受输入参数并针对触发的所需业务功能提供响应。合作伙伴应用程序可以选择为相同的重复输入参数集缓存来自API的输出响应。现在，如果对于相同的输入参数，API的输出频繁变化，则在伙伴应用程序处缓存的输出结果将过时并传达不正确的信息。它有一个简单的解决方案，尽管API可以按预期工作，但是合作伙伴应用程序必须决定他们需要缓存什么结果，什么不需要缓存。如果结果像实时数据一样频繁地从API更改，则不应该进行缓存，但是如果预期不会频繁更改的任何结果(例如产品图像，说明等)可以缓存在合作伙伴应用程序中。
　　处理错误的负面回应：
　　当HTTP通过200返回响应时，API被认为是成功的，但这种响应也可能具有NULL值，这是False Negatives的情况。尽管合作伙伴应用程序将读取成功等响应，但是响应中的那些NULL值对它们有意义吗?这是要求实际测试覆盖率以防止误报的地方。
　　团队沟通失败：
　　随着API根据用户体验和业务变化而增长，API维护变得非常重要。这是需要最佳团队沟通的地方。不会发生API更改，它已经开始影响所有合作伙伴应用程序。对API或合作伙伴应用程序的任何形式的更改都应进行良好的沟通，实施，集成和测试。此外，应不时更新标准接口API文档的版本，以避免开发人员的任何不良开发实践。
　　非标准编码方式：
　　API开发团队应该在输入参数和输出响应参数方面就特定的标准方法达成一致，并且任何与该标准的偏差都应直接导致API拒绝输入或合作伙伴应用程序拒绝。有时，开发人员接受空白或null作为输入或输出伙伴，这可能会导致长期问题。应当明确定义数据类型，强制性或非强制性，范围，阈值等，并且测试应针对此类标准对API进行测试，并且以任何方式完全不接受与此类标准的任何偏差。
　　确保字符集：
　　API应该为输入和输出参数指定可接受的字符集，例如ASCII，Unicode等。这是为了确保合作伙伴应用程序正在与API交互以获取约定的字符集，并且接收到超出约定范围的任何字符，从而导致直接拒绝。另外，应事先同意使用英语，法语，西班牙语等语言作为回应。我们的测试用例应满足对字符集和语言的所有此类要求。
　　API与合作伙伴应用程序的兼容性：
　　建立API时要牢记合作伙伴应用程序的兼容性。来自API端或合作伙伴应用程序端的任何发行版都应在添加到API或合作伙伴应用程序的新功能之上，针对所有现有测试用例进行回归测试。换句话说，API或合作伙伴应用程序的所有发行版都应始终符合兼容性标准。
　　使用您的测试技能：
　　API可能有许多隐藏的问题，这些问题实际上可以通过经验丰富的测试团队拥有的测试技能来揭示。建议测试人员执行负面方案，以发现传统测试实践无法发现的缺陷。测试人员可以进行猴子测试来破坏API，这将为开发人员提供很大的空间来编写高效，强大且智能的API。
　　结论：
　　在API测试中，如果没有正确编码和测试，则对于任何API都是不可避免的缺陷。它要求测试人员设计高效的测试用例，避免本文所述的常见错误，并利用他们的测试技能，以便为生产提供高效且经过良好测试的最终产品。