SOA测试

Question

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

Answer 1

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

• 除非您对业务本身进行大量更改，否则所提供的服务不应从模块的修订版更改为修订版。

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

• 理想情况下，正在使用的服务由目录提供，而不是硬编码到模块中;如果这有，那么测试系统的部件 - 一些模块，但不是全部 - 也变得更容易。

修改

• 并且，正如其他人所指出的那样，您需要测试与规范的一致性，而不是系统的当前组件是否相互协作。例如，Internet Explorer可能会显示网页，但仍不符合规范，因此无法与其他浏览器一起使用。当你进入SOA时，你希望能够无可替代地替换服务的提供者。

Answer 2

通常，SOA服务测试是黑盒，您只使用已发布的WSDL协定，但有时需要在数据库中进行直接验证，尤其是在没有功能（操作）的情况下可以用来进行验证。

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

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

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

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

Answer 3

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

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

通过服务，您还需要关注网络问题。使传统测试在网络中投入大量流量，然后关闭以查看其工作原理。

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

Answer 4

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

服务的定义应该导致使用Mock框架来验证您的服务消费者，而不依赖于提供者的实现。

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

Answer 5

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

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

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

Answer 6

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