SOA测试

Question

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

Answer 1

您必须记住的是，在有许多依赖项的环境中，必须映射所有依赖项，并且必须测试所有路径。

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

对于服务，您还需要注意网络问题。进行传统测试，在网络中放置大量流量，然后关闭以查看其工作方式。

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

Answer 2

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

• 所提供的服务不应该随着模块的不同版本而改变，除非您正在对业务本身进行广泛的更改。
• 模块不应该关心它的客户端是谁，这使得使用的服务是由目录提供的，而不是硬编码到模块中；如果这一点成立，那么测试系统的某些部分--某些模块，而不是所有模块--也会变得容易得多。

编辑：

，

• ，以及，正如其他人所指出的，你需要测试是否符合规范，而不是如果系统的当前组件彼此协同工作的话。例如，一个网页可能可以在Internet Explorer上显示，但仍然不符合规范，因此无法在其他浏览器上使用。当您转向面向服务架构时，您希望能够无缝地替换服务的提供者。

Answer 3

通常，SOA服务测试是黑盒，在这种情况下，您只需考虑已发布的WSDL契约，但是，有时有必要在数据库中进行直接验证，特别是在没有可用于进行验证的功能(操作)的情况下。

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

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

• 不兼容的语法：新的contract版本可以有新的元素，但不能有新的必需元素，因为这会破坏老的客户端，这种问题通常可以通过运行使用当前和新的contracts.
• validation抽象实现的自动化测试来避免:通常，<>e114规范模型 (xml Schema)与多个服务共享，以避免类型转换并提供公共的业务语言，它们通常不具有所有服务操作所需的所有验证。然后，在服务实现中直接完成必要的验证逻辑。如果新版本的服务实现了一组新的验证，而这些验证不在已发布的合同中，则必须通知客户端并测试方案。

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