彩票走势图

应用程序编程接口（API）是应用程序的服务层。它们连接数据层和表示层（UI），并驱动用户与应用程序交互的方式。

如果API无法正确响应用户活动，则说明该应用程序已损坏。开发人员和测试人员有责任确保所连接的API在其应用程序中正常工作。

API测试对于识别应用程序多层中的缺陷并确保无缝的客户体验是必不可少的。 API测试包括：

• 服务测试
• 合同测试
• 组件测试
• 场景测试
• 负载/性能测试
• 安全测试
• 全渠道测试

执行API测试具有挑战性，因为它需要一种技术方法来针对各种消息格式和协议设计测试用例。它还需要了解组织的业务规则，以一起正确使用正确的API。尝试使用手动方法测试API非常耗时，并且可能导致测试推迟到开发周期的后期。

自动化的API测试使您能够对应用程序进行防弹防御。它可以尽早发现错误，评估构建的强度，并导致更快的软件发布。由于API测试可以自动化并且可以连续运行，因此您可以确保应用程序符合业务期望，同时还可以验证功能准确性。

自动化API测试的利弊

有了正确的API测试工具和流程，您的团队将获得自动化的所有好处。没有它们，API测试会很快变得不堪重负。

优点

• 提供端到端方案的可维护的自动化。
• 打开开发人员与测试之间的沟通渠道。
• 减少诊断和修复时间。

缺点

• 测试人员不知道如何测试API或如何使用API。
• 需要专业技能和工具才能获得全面的测试范围。
• 没有人愿意这样做。

您可以通过将高级测试技术集成到现有测试中来克服这些挑战。首先，让我们看一下API测试的创建。

创建API测试的挑战

建立API测试自动化实践的最大挑战之一就是创建API测试。适当的测试提出了入门（或扩展现有的API测试套件）的障碍。

此问题的一部分是纯粹基于技术知识或书面API规范（如果存在）编写API测试所需的领域知识。这不是测试人员的常用领域。大多数具备必要知识的开发人员都不会参与此级别的测试。他们在其他地方有优先事项。

考虑两种互补的方法：

• 自上而下的方法。测试方案是根据常规应用程序的使用和测试创建的。
• 自下而上的方法。测试基于设计意图。

结合使用自顶向下和自底向上方法进行API测试创建

大多数应用程序提供并使用多个API。有些是众所周知的。有些甚至可能被记录在案。引擎盖下通常有很多活动部件，因此开始进行API测试非常困难。

在自上而下的方法中，API交互是通过工具自动化发现的，这是通常使用和集成测试的一部分。

另一个攻击角度是自下而上的方法，是根据设计意图创建API测试。它通常是组件测试的一部分，并借助工具进行辅助。

自上而下（集成测试）和自下而上（组件测试）方法的结合克服了测试创建的障碍，并增加了API测试的覆盖范围。请参见下图。

按用途创建API测试

捕获API测试方案的最佳方法之一是在生产和测试中都使用产品的现有用法。利用智能记录和回放功能，可以创建可重复使用的测试和方案。

使用SOAtest Smart API Test Generator等工具，您可以记录在应用程序内部发生的API交互。该工具使用机器学习将复杂的流量组织成API使用模式。这样就可以使用现有的手动测试来创建一套API测试，以使用UI提取、过滤和创建API测试方案。

然后，SOAtest使用AI来识别模式并建立数据关系以创建API测试模板。您可以修改和重复使用带有变体的模板。这些测试可用于安全性和性能测试。更重要的是，这些测试一旦创建，便会与UI和基础应用程序分离，并且其依赖关系可以仅通过API测试来行使。

将API流量记录和分析到测试场景中，可以扩展到使用Selenium等工具进行的自动化UI测试。发起API调用的应用程序的任何使用，无论是手动还是自动的，都可以用来创建API测试。也可以将录制的方案与可追溯性要求相关联。

记录后，可以在SOAtest中对这些方案进行调查和修改，如下所示。

SOAtest检测各种API调用和发生的数据交互。然后可以根据需要修改方案和数据有效载荷。一旦理解了模式，就可以将断言插入场景中以验证正确的值和行为。

完全基于现有测试技术创建即用型API测试套件的能力可以快速创建具有重用和扩展功能的测试。这是通过API测试的最大障碍之一的捷径。

通过（服务）设计创建API测试

您可能会想，“我们不知道API的设计。其中大多数都没有记录！”在大多数情况下，这是正确的。但是，仍然可以通过查看应用程序中显式或隐式的服务定义和协定，将现有信息中的API测试组合在一起，以帮助从下至上扩展API测试的覆盖范围。

就API规范而言，大多数服务在swagger文档或WSDL中都有定义。SOAtest可以阅读这些定义并创建API测试方案模板。它包括定义中所有客户端的测试用例。您可以编辑和操作模板以创建有意义的API测试。

SOAtest提供了许多用于从模板创建无脚本测试的选项，包括基于随机数的参数化数据或先前的测试结果，如下例所示。

通过使用简单的复制和粘贴技术，无脚本的测试创建以及灵活的测试数据管理，SOAtest提供了一种构建测试套件的简便方法。这并不是要取代自上而下的方法，而是要对其进行补充。如果手动或UI测试缺少API的重要部分（由覆盖结果告知），则自下而上的方法将填补这些空白。但是，如果不了解覆盖范围，就很难确定要测试的内容和缺少的内容。

了解测试范围

覆盖范围取决于上下文，意味着几件事。通常，它是代码、API和要求范围。您需要了解所有这些内容，以清晰了解测试工作的完成程度。

• 单元测试——关注的是代码覆盖率。有多少代码具有与执行相关的测试？
• API——重要的是要知道要测试哪些，以及每个API的使用程度。
• 需求——每个需求都必须进行测试，以证明其正确实施。

这些重叠的问题在项目生命周期的不同时间都很重要。例如，如果您要跟踪的是API测试覆盖率，则重要的是要确保测试充分覆盖了API，并在缺少的地方进行现有测试。最好的方式是从服务定义中进行查看，如下图所示。

SOAtest跟踪执行的每个测试以及涵盖的API：完全、部分或根本不包括。知道缺少哪些测试，可以让我们根据服务定义进行自下而上的测试，或者在可能的情况下基于新的基于UI的测试。它还指出测试失败的地方（红色），将我们的注意力转移到需要更新或植入中有问题的测试。

Parasoft DTP（开发测试平台）充当各种测试实践结果的中央存储库和枢纽，并根据不同类型的覆盖范围提供了项目所在位置的高级视图，如以下仪表板所示。

此视图合并了静态代码分析、单元测试、API以及手动和自动UI测试的汇总结果。这是测试金字塔的全部色域。它从各个方面提供了完整的覆盖范围：API、需求和代码覆盖范围。

从JIRA中保存的用户故事的角度考虑需求范围。功能测试仪表板（如下所示）包括JIRA Story Status小部件，这是跟踪需求覆盖率的一种方法。

更仔细地查看JIRA状态，鼠标悬停信息指示通过、未通过、未完成或未通过测试的测试数量。

您可以在详细的可跟踪性报告中进一步深入了解，以找出缺少哪些需求，未通过其测试等等。

您可以通过深入研究可追溯性报告来进一步调查，以了解哪些测试正在影响这个故事。

此外，您可以根据需要将此覆盖范围链接到API和代码覆盖范围。您可以从此处导航至API测试，以确定需要进行哪些更改以及需要进行哪些其他测试。这种全面的汇总视图提供了最完整的测试状态信息。随着开发人员聚集在一个完整的应用程序上，随着时间的推移，测试覆盖率“增长”，新的代码被API和为相关需求创建的单元测试“覆盖”。

总结

API测试的重要性已为软件开发组织所认可，但是他们经常难以充分采用该实践。努力的一部分是建立一组测试，因为手动测试的创建很复杂并且需要熟悉的技术知识。甚至采用API测试的团队也面临着增加其API测试覆盖面的挑战，因为其中许多没有记录在案。

诸如SOAtest之类的高级功能测试工具可以基于分析手动测试和常规应用程序使用中的使用行为，使用自上而下的方法来帮助自动化API测试创建。这种智能的测试生成功能可帮助团队快速，轻松地根据现有实践创建测试。

使用SOAtest自动化可以同时采用互补的自下而上的方法，以根据服务定义构建无脚本测试。随着完整的覆盖率分析，您可以使用自上而下和自下而上的技术随着时间的推移来扩展API测试的覆盖率。由于API测试的工作水平远低于UI测试，因此您可以放心，所构建的一致而全面的测试将持续很长时间。