3

SOA 测试与传统的应用程序测试有何不同

4

6 回答 6

2

由于每个“服务提供者”都应该有一个标准的、面向业务的接口（通常由 WSDL 技术提供），因此以下属性可能会有所不同：

  • 所提供的服务不应该随着模块的修订而改变，除非您对业务本身进行广泛的更改。

  • 一个模块不应该关心它的客户是谁，这使得模块测试更容易。

  • 理想情况下，所使用的服务由目录提供，而不是硬编码到模块中；如果这成立，那么测试系统的某些部分——一些模块但不是全部——也变得容易得多。

编辑：

  • 而且，正如其他人指出的那样，您需要测试是否符合规范，而不是系统的现有组件是否相互配合。例如，一个网页可能在 Internet Explorer 上显示正常，但仍不符合规范，因此无法与其他浏览器一起使用。当您使用 SOA 时，您希望能够无缝地替换服务提供者。
于 2009-07-16T13:09:37.910 回答
1

通常 SOA 服务测试是黑盒的，您使用时只考虑已发布的 WSDL 契约，然而，有时需要在数据库中进行直接验证，特别是当没有可用于进行验证的能力（操作）时。

此外，由于现代 SOA 平台通常与其他服务实现共享资源，因此模拟大于或等于生产量的处理负载并评估内存、处理和 I/O 消耗的影响非常重要，以避免对服务产生负面影响已经部署。

最复杂的问题与合约和实现的演变有关，关于如何在不破坏现有客户端的情况下实现新功能，这可能特别麻烦，因为存在语法和语义问题，例如：

  • 语法不兼容：新合约版本可以有新元素，但不能有新的必需元素，因为这会破坏旧客户端，这种问题通常可以通过运行当前和新合约实现的自动化测试来避免。
  • 验证抽象：通常，规范模型（xml 模式）与多个服务共享，以避免类型转换并提供通用的业务语言，它们通常不具备所有服务操作所需的所有验证。然后，必要的验证逻辑直接在服务实现中完成。如果新版本的服务实现了一组未在已发布合同中的新验证，则必须通知客户端并测试场景。

我常用的工具是：SOAP UI和JMeter，并使用内部开发的框架创建自定义自动化测试。

于 2012-08-08T13:28:54.520 回答
0

您必须记住的想法是，在存在大量依赖项的环境中，您必须映射所有依赖项并且必须测试所有路径。

拥有服务，它们必须与很多客户端一起使用，因此每个客户端都应该遵循测试用例。

有了服务，还需要注意网络问题。进行传统测试，将大量流量放入网络并关闭以查看其工作原理。

除此之外，拥有服务不需要其他类型的不同方法。只需控制所有输入和输出。

于 2009-07-16T13:24:20.127 回答
0

很少（有价值的？）建议：

服务的定义应该导致使用 M​​ock 框架，在不依赖提供者的实现的情况下验证您的服务消费者。

检查消费者的健壮性：当消息丢失、服务提供者不可用时会发生什么。

于 2009-07-16T13:45:27.883 回答
0

SOA 测试可以定义为传统测试的扩展。

与传统应用程序类似，我们首先对组件进行单元测试，然后是组件级功能测试，然后是模块级，然后是端到端应用程序测试，我们有服务（有时是一组组件组合在一起以实现特定任务) 级别单元测试，然后是功能测试，然后是流程（复合服务或业务流程）级别测试、端到端集成测试等。

由于进程驻留在不同类型的服务中，其中一些服务可能是包装器，一些服务也可能具有通信约束、负载约束、服务级别协议，所有这些都使测试过程复杂化，应该考虑这些问题来制定测试策略。

于 2011-09-09T12:43:01.010 回答
0

Soa 测试只是确保所有独立服务都以预期的方式运行，同时始终遵守这些服务建立的输入和输出契约。我发现了一个有趣的 SOA 测试工具，它是免费的SOArite。

于 2014-12-02T06:30:21.597 回答