什么是 SOA 测试？教程与示例

什么是 SOA 测试？

SOA（面向服务 Archi结构）测试 是对 SOA 架构风格的测试，在这种风格中，应用程序组件被设计成通过通信协议（通常是通过网络）进行通信。

什么是SOA？

SOA 是一种将业务应用程序和流程集成在一起以满足业务需求的方法。

In 软件工程SOA 为业务流程提供了敏捷性和灵活性。对流程或应用程序的更改可以针对特定组件，而不会影响整个系统。

在SOA领域工作的软件开发人员要么开发程序模块，要么购买名为“程序块”的程序。 服务.

什么是服务？

下图显示了一个作为服务发布的支付网关，多个电子商务网站可以调用该服务。

• 服务可以是应用程序或业务流程的功能单元，可以被任何其他应用程序或流程重用或重复使用。（例如，在上图中，支付网关就是一个可以被任何电子商务网站重用的服务。每当需要进行支付时，电子商务网站都会调用或请求支付网关服务。支付在网关上完成后，会将响应发送回电子商务网站。）
• 服务易于组装，并且易于重新配置组件。
• 服务可以比作积木。它们可以构建任何所需的应用程序，而且从应用程序或业务流程中添加或移除它们都很容易。
• 服务的定义更多地取决于它们所执行的业务功能，而不是代码块。

Web服务

大多数 SOA 服务都以 Web 服务的形式公开，因此在测试层之前，有必要先明确 Web 服务调用的机制。

Web服务 是可通过网络访问的独立应用程序组件。

它们可以在网络上发布、查找和使用，并通过互联网进行通信。以下流程图展示了服务提供商、注册机构和消费者之间的交互方式。

• 服务提供商将服务发布到互联网上。
• 客户端在 Web 服务注册表中搜索特定的 Web 服务。
• A URL 和 wsdl 返回所需的 Web 服务。使用 WSDL 和 URL服务提供商和请求者之间的通信是通过 SOAP 消息进行的。
• 当消费者调用网络服务时，会与提供商建立HTTP连接。
• 创建一个 SOAP 消息，指示提供者调用所需的 Web 服务逻辑。
• 从提供商处收到的响应是嵌入在 HTTP 响应中的 SOAP 消息。此 HTTP 响应是客户端应用程序可以理解的数据格式。

例如：

下面的屏幕截图显示的是由外部服务提供的天气预报，并嵌入在搜索引擎主页中。

网站首页和搜索引擎都会显示每日天气预报。与其从头开始编写天气预报部分的代码，不如从供应商那里购买天气预报服务并将其集成到页面中。

SOA 测试层

SOA 由多种技术构成，基于 SOA 构建的应用程序包含各种松耦合的服务。下图展示了测试计划需要涵盖的三层结构。

SOA测试应重点关注3个系统层。

服务层

这一层由系统公开的服务组成，这些服务源自业务功能。

例如，考虑一个包含以下内容的健康网站：

• 重量 TracKER
• 血糖 TracKER
• 血压 TracKER

Trackers 显示相应的数据及其录入日期。服务层包含从数据库获取相应数据的各种服务：

• 重量 Tracker 服务
• 血糖 Tracker 服务
• 血压 Tracker 服务
• 登录服务

过程层

流程层由流程组成，流程是构成单一功能的各项服务的集合。

这些过程可能是用户界面的一部分（例如搜索引擎），也可能是从数据库中提取数据的 ETL 工具的一部分。

本层的主要重点是用户界面和流程。权重用户界面 tracker及其与数据库的集成是主要关注点。

以下功能需要考虑：

• 添加新数据
• 编辑现有数据
• 创建一个新的 tracKER
• 删除数据

消费者层

这一层主要由用户界面组成，如下图所示。

基于这些层次，SOA应用程序的测试分为三个级别：

• 服务水平
• 接口级别
• 端到端级别

这两个方向有所不同：测试设计采用自顶向下的方法，而测试执行采用自底向上的方法。

SOA 测试策略

测试计划方法

• SOA测试人员应该了解应用程序的完整架构。
• 该应用程序需要分解为独立的服务（具有自己的请求和响应结构，并且不依赖任何其他服务来形成响应的服务）。
• 应用程序结构需要重新组织成三个组成部分——数据、服务和前端应用程序。
• 需要仔细分析所有组成部分，并制定业务场景。
• 业务场景应分为通用场景和特定应用场景。
• A 可追溯性矩阵 应该准备好，并且所有测试用例都应该是 trac适用于商业场景。

测试执行方法

• 每个服务组件都应该进行测试。
• 整合测试 应该对服务组件进行检查，以验证通过服务的数据流和数据完整性。
• 系统测试 应该对整个模型进行验证，以确认前端应用程序和数据库之间的数据流。
• 性能测试 应进行微调和最佳性能。

SOA 测试方法

1）基于业务场景的数据驱动测试

• 应该分析与该系统相关的各种业务方面。
• 应根据应用程序的各种 Web 服务的集成以及 Web 服务与应用程序的集成来制定方案。
• 数据设置应根据上述场景进行。
• 数据设置也应涵盖端到端场景。

2）存根

• 创建虚拟接口是为了测试服务。
• 可以通过这些接口提供各种输入，并可验证输出。
• 当应用程序使用与未被测试的外部服务（第三方服务）的接口时，可以在集成测试期间创建存根。

3）回归测试

• 迭代测试 当有多个版本发布时，应该对应用程序进行维护，以确保系统的稳定性和可用性。
• 我们将创建一个全面的回归测试套件，涵盖构成应用程序重要部分的服务。
• 该测试套件可以在项目的多个版本中重复使用。

4）服务水平测试

服务级别测试包括对组件的功能、安全性、性能和互操作性进行测试。每项服务都需要先进行独立测试。

5）功能测试

功能测试 应在每项服务中执行以下操作：

• 确保服务对每个请求都能做出正确的响应。
• 确保对于包含无效或错误数据的请求，能够接收到正确的错误信息。
• 检查服务在运行时需要执行的每个操作的每个请求和响应。
• 当服务器、客户端或网络级别发生错误时，验证错误消息。
• 验证收到的响应是否具有正确的格式。
• 验证响应中收到的数据是否与请求的数据相符。

6）安全测试

在 SOA 应用程序的服务级别测试中，Web 服务的安全测试是一个重要的方面，因为它能确保应用程序的安全性。

测试期间需要涵盖以下因素：

• Web 服务应遵守 WS-Security 定义的行业标准。
• 安全措施应当完美无缺。
• 数据加密和文档数字签名。
• 身份验证和授权。
• 将在以下方面进行测试：SQL注入、恶意软件、XSS、CSRF和其他漏洞 XML.
• 拒绝服务攻击。

7）性能测试

需要对服务进行性能测试，因为服务是可重用的，并且多个应用程序可能使用同一服务。

测试期间考虑以下因素：

• 需要在高负载下测试服务的性能和功能。
• 需要比较该服务单独运行时和与应用程序集成运行时的性能。
• 负载测试 应执行服务测试，以验证响应时间、检查瓶颈、验证 CPU 和内存利用率，并预测可扩展性。

8）集成级别测试

• 服务级别测试确保各项服务单独正常运行；但它不能保证耦合组件的正常运行。
• 集成测试主要侧重于 接口.
• 此阶段涵盖了所有可能的业务场景。
• 在此阶段，应再次对应用程序进行非功能性测试。安全性、合规性和性能测试可确保系统在各个方面的可用性和稳定性。
• 应该测试通信和网络协议以验证服务之间数据通信的一致性。

9）端到端测试

此阶段确保应用程序在功能和非功能方面均符合业务需求。

以下项目保证在测试期间进行测试。 端到端测试:

• 集成后所有服务均按预期运行
• 异常处理
• 应用程序的用户界面
• 所有组件之间的正确数据流
• 业务流程

SOA测试中的挑战

应用这些方法很少是一帆风顺的，以下困难几乎在每个 SOA 项目中都会反复出现。

• 服务接口不足。
• 测试过程涉及多个系统，因此需要复杂的数据。
• 该应用程序由各种组件构成，这些组件往往会发生变化，因此需要更频繁地进行回归测试。
• 由于其多层结构，很难隔离缺陷。
• 由于一项服务被不同的接口使用，负载难以预测，这使得性能测试计划变得繁琐。
• SOA是由多种异构技术组成的集合体。测试SOA应用程序需要具备不同技能的人员，这反过来又会增加规划和执行成本。
• 由于该应用程序集成了多种服务，安全测试也面临着诸多难题。验证身份验证和授权十分困难。

SOA 测试工具

市面上有很多面向服务的架构（SOA）测试工具可以帮助测试人员测试SOA应用程序。以下是一些常用的SOA测试工具。

1) SoapUI

SoapUI 是一个用于服务和开源功能测试的工具 API测试.

• 桌面应用程序
• 支持多种协议——SOAP、REST、HTTP、JMS、AMF、JDBC
• 可以开发、检查和调用 Web 服务。
• 也可用于负载测试， 自动化测试以及安全测试
• 存根可以通过 MockServices 创建
• 通过其 Web 服务客户端，可以自动生成 Web 服务请求和测试。
• 内置报告工具
• 由 SmartBear 开发，该公司同时提供以下产品： 开放源码 SoapUI 分销和商业 ReadyAPI 版

2) 博通服务虚拟化（原 iTKO LISA）

LISA 是一套产品套件，为 SOA 等分布式系统提供功能测试解决方案。该产品最初由 iTKO 出售给 CA Technologies，如今以 Broadcom Service Virtualization 的名义销售。

• 也可用于回归测试、集成测试、负载测试和性能测试。
• 可用于设计和执行测试。

3) UFT 一（原惠普服务测试）

Service Test 是一款功能测试工具，支持 UI 测试和共享服务测试。其 API 测试功能已并入 Unified Functional Testing，后者目前由 [公司名称] 销售。 OpenText as UFT 一。

• 服务的功能测试和性能测试都可以通过单个脚本完成。
• 与 Quality Center 集成，现作为 OpenText ALM/质量中心。
• 可以管理海量的服务和数据。
• 通过模拟 JEE、AXIS 和 DotNet 客户端环境支持互操作性测试。

4) Parasoft SOAtest

Parasoft SOAtest 是一款专为 API 和 API 驱动型应用程序测试而开发的测试和分析工具套件。

• 支持 Web 服务、REST、JSON、MQ、JMS、TIBCO、HTTP 和 XML 技术。
• 可以进行功能测试、单元测试、集成测试、回归测试、安全测试、互操作性测试、合规性测试和性能测试。
• 可以使用以下方法创建存根 Parasoft Virtualize它们比……更强大 SoapUI 模拟服务。

SOA 测试用例

下面的示例将上述策略、方法和工具分阶段应用于单个电子商务网站。

考虑一个包含以下功能和子功能的电子商务网站。

订单处理

下图将订单处理分解为各个子功能，这些子功能最终会转化为服务。

PHASE 1

在 SOA 测试的第一阶段，即测试策略阶段，应用程序被分解为服务和业务功能。

让我们来看看应用程序中的以下服务。

• 创建订单
• 检查客户状态
• 更改订单状态
• 查看订单状态
• 检查库存

业务功能与网站功能相同。

注：测试策略文档将包含需要测试的服务和功能的列表。

PHASE 2

这是测试计划阶段。 测试用例 每个级别都有相应的教材。

端到端关卡。 每个业务用例和流程都编写了测试用例。以下是一些测试用例示例。

• 创建包含活跃用户的订单。
• 与不活跃用户创建订单。
• 创建订单，订单中需包含有现货的产品，但订单数量小于现有库存数量。
• 创建订单，订单中需包含有现货的产品，且订单数量大于现有库存数量。
• 创建包含多个商品的订单。
• 彻底取消订单。
• 部分取消订单。

整合程度。 编写测试用例是为了验证数据库和用户界面的集成。以下是一些测试用例示例。

• 创建包含单个商品的新订单。验证该订单是否已在数据库中创建。
• 创建包含单个商品的新订单。验证订单计算的价格是否正确。
• 创建一份包含单个商品的新订单。确认现有商品的数量已减少订单数量。
• 确认用户界面上显示的订单状态与数据库中的订单状态一致。
• 取消订单并验证订单状态是否在数据库上修改。
• 首次付款时，请确认在用户界面上输入的付款详情已保存到数据库中。
• 对于退回付款，请验证数据库上的付款详细信息是否显示在 UI 上。

服务水平。 每项服务都会针对所有数据条件进行测试。以下是一些示例。

序号	订单详细信息	订单条件
1	创建订单。商品数量 = 1	订单数量 < 数据库数量
2	创建订单。商品数量 > 1	订单数量 < 数据库中的数量
3	创建订单。商品数量 = 1	订单数量 > 数据库数量
4	查看订单状态	数据库状态 = 活动
5	查看订单状态	数据库状态 = 已发货
6	查看订单状态	数据库状态 = 已取消
7	查看订单状态	订单 ID = 无效
8	检查产品可用性	产品数量 >0
9	检查产品可用性	产品数量 =0
10	检查产品可用性	产品 ID = 无效

第三阶段——测试执行

测试执行采用自下而上的方法：首先进行服务级测试，然后进行集成级测试，最后进行端到端测试。

1）服务水平

让我们考虑一下…… SoapUI 该工具用于测试应用程序。WSDL 和 URL 浏览到测试窗口中 SoapUI每个服务的请求都会显示在请求窗口中。通过根据服务级别测试用例修改数据，即可为每个测试用例创建请求。

测试用例	请求	预期响应
创建订单。商品数量 = 1，订单数量 < 数据库中的数量。	x2 2	o3251成功的
创建订单。商品数量 > 1，订单数量 < 数据库中的数量。	y1 1 y2 3	o3251成功的
创建订单。商品数量 = 1，订单数量 > 数据库中的数量。	x23 200	无效的不成功
检查订单状态。数据库中的状态 = 有效	o9876	积极的成功的
查看订单状态。数据库中的状态 = 已发货	o9656	已发货成功的
检查订单状态。订单 ID = 无效	y5686	无效的不成功
查看产品库存。产品数量 >0	d34	三十四是的成功的
查询产品库存。产品数量 = 0	y34	0不成功的
请检查产品库存。产品 ID = 无效	斯德	不成功

2）集成度

集成级测试用例在用户界面和数据库上执行。创建一个包含单个商品的订单：

• 用户打开网站。
• 用户下单。
• 用户选择有效的产品和数量，并保存订单。
• 应显示“订单已成功提交”的消息。
• 用户打开数据库，检查订单详情是否与网站上输入的详情一致。

3）端到端级别

业务流程和用例均在用户界面上执行。创建包含多个商品的订单：

• 用户打开网站。
• 用户下单。
• 用户查询有效产品和数量，并将其添加到购物车。
• 添加其他有效商品及数量后，订单保存。通过新的支付方式完成付款，订单提交成功。
• 应显示“订单成功下单”的消息。
• 测试人员应验证整个流程是否顺利完成，且数据无偏差。

常见问题