什么是 SOA 测试?教程与示例
什么是 SOA 测试?
SOA(面向服务 Archi架构 (tecture) 测试是对 SOA 架构风格的测试,其中应用程序组件被设计为通过通信协议(通常通过网络)进行通信。
什么是SOA?
SOA 是一种将业务应用程序和流程集成在一起以满足业务需求的方法。
在软件工程中,SOA 为业务流程提供了敏捷性和灵活性。对流程或应用程序的更改可以针对特定组件,而不会影响整个系统。
SOA 中的软件开发人员要么开发要么购买称为 服务。
什么是服务?
- 服务可以是应用程序或业务流程的功能单元,可以被任何其他应用程序或流程重用或重复使用。(例如,在上图中,支付网关是一种可以被任何电子商务网站重用的服务。每当需要付款时,电子商务网站就会调用/请求支付网关服务。在网关上付款后,会向电子商务网站发送响应)
- 服务易于组装,并且易于重新配置组件。
- 服务可以比作积木。它们可以构建任何所需的应用程序。在应用程序或业务流程中添加和删除它们很容易。
- 服务更多地是通过其执行的业务功能而不是代码块来定义的。
Web服务
Web 服务是独立的应用程序组件,可通过 Web 访问。
它们可以在网络上发布、查找和使用,并且可以通过互联网进行交流。
- 服务提供商将服务发布到互联网上。
- 客户端从 Web 服务注册表中搜索特定的 Web 服务
- 返回所需 Web 服务的 URL 和 WSDL。使用 WSDL 和 URL,服务提供者和请求者之间的通信通过 SOAP 消息进行。
- 当消费者调用 Web 服务时,将与提供者建立 HTTP 连接。
创建 SOAP 消息来指示提供商调用所需的 Web 服务逻辑。 - 从提供商收到的响应是 SOAP 消息,它将嵌入到 HTTP 响应中。此 HTTP 响应是消费者应用程序可以理解的数据格式。
例如:
网站和搜索引擎的主页显示每日天气预报。无需编写所有天气预报部分的代码,只需从供应商处购买天气预报服务并将其集成到页面中即可。
SOA 测试
SOA 包含多种技术,使用 SOA 构建的应用程序具有多种松散耦合的服务。
SOA 测试应重点关注 3 个系统层
服务层
该层由服务、系统暴露的服务以及业务功能派生的服务组成。
例如 -
考虑一个健康网站,其中包括
- 体重追踪器
- 血糖追踪器
- 血压追踪器
跟踪器显示相应的数据和输入日期。服务层由从数据库获取相应数据的服务组成——
- 体重追踪服务
- 血糖追踪服务
- 血压追踪服务
- 登录服务
过程层
流程层由流程、服务集合等组成,它们是单一功能的一部分。
这些过程可能是用户界面的一部分(例如搜索引擎),也可能是 ETL 工具的一部分(用于从数据库获取数据)。
该层的主要焦点是用户界面和流程。
体重跟踪器的用户界面及其与数据库的集成是主要关注点。
以下功能值得考虑
- 添加新数据
- 编辑现有数据
- 创建新的追踪器
- 删除数据
消费者层
该层主要由用户界面组成。
基于该层,SOA应用程序的测试分为三个级别。
- 服务水平
- 接口级别
- 端到端级别
- 测试设计采用自上而下的方法。
- 测试执行采用自下而上的方法。
SOA 测试策略
测试规划方法,
- SOA 测试人员应该了解应用程序的完整架构。
- 应用程序需要分解为独立的服务(Service,具有自己的请求和响应结构,并且不依赖于任何其他服务来形成响应)。
- 应用程序结构需要重新组织为三个组件——数据、服务和前端应用程序。
- 需要仔细分析所有组件,并制定业务场景。
- 业务场景应该分为通用场景和特定应用场景。
- A 可追溯性矩阵 做好准备工作,所有测试用例都要追溯到业务场景。
测试执行方法
- 每个服务组件都应该进行测试。
- 整合测试 应该对服务组件进行检查,以验证通过服务的数据流和数据完整性。
- 系统测试 应该对完整模型进行验证,以验证前端应用程序和数据库之间的数据流。
- 性能测试 应进行微调和最佳性能。
SOA 测试方法
1)基于业务场景驱动的数据测试,
- 应该分析与系统相关的各个业务方面。
- 应基于以下方面的整合来制定方案
- 套装 Web服务 应用程序
- Web 服务和应用程序。
- 数据设置应根据上述场景进行。
- 应进行数据设置以覆盖端到端场景。
2)存根
- 将创建虚拟接口来测试服务。
- 可以通过这些接口提供各种输入,并可验证输出。
- 当应用程序使用未经测试的外部服务(第三方服务)的接口时,可以在集成测试期间创建存根。
3)回归测试
- 迭代测试 在多次发布时应对应用程序进行定期维护,以保证系统的稳定性和可用性。
- 我们将创建一个全面的回归测试套件,涵盖构成应用程序重要部分的服务。
- 该测试套件可以在项目的多个版本中重复使用。
4)服务水平测试
服务级别测试包括测试组件的功能、安全性、性能和互操作性。
每个服务都需要首先进行独立测试。
5)功能测试
应该对每个服务进行功能测试,以
- 确保服务对每个请求提供正确的响应。
- 对于包含无效数据、坏数据等的请求,会收到正确的错误。
- 检查服务在运行时必须执行的每个操作的每个请求和响应。
- 当服务器、客户端或网络级别发生错误时验证故障消息。
- 验证收到的响应是否具有正确的格式。
- 验证响应中收到的数据是否与请求的数据相对应。
6)安全测试
Web 服务的安全测试是 SOA 应用程序服务级别测试期间的一个重要方面;这可确保应用程序的安全。
测试期间需要涵盖以下因素:
- Web服务应遵循WS-Security测试所定义的行业标准。
- 安全措施应当完美无缺。
- 数据加密和 Digi文件上的签名
- 认证与授权
- SQL 注入、恶意软件、XSS、CSRF 和其他漏洞都需要在 XML 上进行测试。
- 拒绝服务攻击
7)性能测试
由于服务可重复使用且多个应用程序可能使用相同的服务,因此需要对服务进行性能测试。
测试期间考虑以下因素:
- 需要在高负载下测试服务的性能和功能。
- 需要比较服务在单独工作时和在应用程序内结合工作时的性能。
- 应进行服务负载测试
- 验证响应时间
- 检查瓶颈
- 验证 CPU 和内存的利用率
- 预测可扩展性
8)集成级别测试
- 服务级别测试仅确保单个服务的正常运行,但不能保证耦合组件的正常运行。
- 集成测试主要关注接口。
- 此阶段涵盖了所有可能的业务场景。
- 在此阶段,应再次进行应用程序的非功能测试。安全性、合规性和性能测试可确保系统各方面的可用性和稳定性。
- 应该测试通信和网络协议以验证服务之间数据通信的一致性。
9)端到端测试
此阶段确保应用程序在功能和非功能上都符合业务需求。
确保在端到端测试期间测试以下项目
- 集成后所有服务均按预期运行
- 异常处理
- 应用程序的用户界面
- 所有组件之间的正确数据流
- 业务流程
SOA 测试中的挑战
- 缺乏服务接口
- 测试过程跨越多个系统,因此产生复杂的数据需求
- 应用程序是各种组件的集合,这些组件往往会发生变化。回归测试的需求更为频繁。
- 由于多层架构,很难隔离缺陷。
- 由于服务将在不同的接口中使用,因此很难预测负载,从而使性能测试规划变得繁琐。
- SOA 是异构技术的集合。测试 SOA 应用程序需要具备不同技能的人员,这反过来又增加了规划和执行成本。
- 由于应用程序是多种服务的集成,因此安全测试也存在一些问题。身份验证和授权的验证相当困难。
SOA 测试工具
市场上有许多 SOA 测试工具可帮助测试人员测试 SOA 应用程序。以下是一些流行的 SOA 测试工具:
1)SOAP用户界面
“SOAP UI” 是一个开源的服务和功能测试工具 API测试.
- 桌面应用程序
- 支持多种协议 – SOAP、REST、HTTP、JMS、AMF、JDBC
- 可以开发、检查和调用 Web 服务。
- 也可以用于负载测试, 自动化测试以及安全测试
- 存根可以通过 MockServices 创建
- 可以通过其 Web 服务客户端自动生成 Web 服务请求和测试。
- 具有内置报告工具
- 由 SmartBear 开发
2)iTKO LISA
“LISA”是一个为SOA等分布式系统提供功能测试解决方案的产品套件。
- 还可以用于回归、集成、负载和性能测试。
- 由 iTKO (CA Technologies) 开发
- 可用于设计和执行测试。
3)惠普服务测试
“Service Test”是一款功能测试工具,支持UI和共享服务测试。
- 服务的功能和性能测试都可以通过单个脚本完成。
- 与 HP QC 集成。
- 可以管理海量的服务和数据。
- 通过模拟 JEE、AXIS 和 DotNet 客户端环境支持互操作性测试。
- 由 HP 开发。
4)Parasoft SOA 测试
SOA Test 是针对API和API应用程序测试而开发的测试和分析工具套件。
- 支持 Web 服务、REST、JSON、MQ、JMS、TIBCO、HTTP、XML 技术。
- 可以进行功能、单元、集成、回归、安全性、互操作性、合规性和性能测试。
- 可以使用 Parasoft Virtualize 创建存根,它比 SOAP UI 更智能。
- 由 ParaSoft 开发
SOA 测试用例
考虑一个电子商务网站,它包含以下功能和子功能:
订单处理
PHASE 1
在 SOA 测试的第一阶段,即测试策略阶段,应用程序被分解为服务和业务功能。
下面让我们考虑一下应用程序中的服务。
- 创建订单
- 检查客户状态
- 更改订单状态
- 查看订单状态
- 检查库存
业务功能与网站功能相同。
请注意: 测试策略文档将包含需要测试的服务和功能的列表。
PHASE 2
测试规划阶段。为每个级别编写测试用例。
- 端到端级别。针对每个业务用例和流程编写测试用例。以下是测试用例的示例
- 与活跃用户创建订单。
- 与不活跃用户创建订单。
- 创建一个订单,其中可用产品的数量为订单数量 < 可用数量。
- 创建一个订单,其中可用产品的数量为订单数量 > 可用数量。
- 创建包含多件商品的订单
- 彻底取消订单。
- 部分取消订单。
- 集成级别。编写测试用例是为了集成数据库和用户界面。以下是示例测试用例。
- 创建包含单个商品的新订单。验证该订单是否已在数据库中创建。
- 创建包含单个商品的新订单。验证订单计算的价格是否正确。
- 创建包含单个商品的新订单。验证可用商品的数量是否少于订单金额。
- 验证UI上显示的订单状态是否与数据库中的状态相同。
- 取消订单并验证订单状态是否在数据库上修改。
- 对于首次付款,请验证在 UI 上输入的付款详细信息是否保存在数据库中。
- 对于退回付款,请验证数据库上的付款详细信息是否显示在 UI 上。
- 服务级别。每项服务都针对所有数据条件进行测试。
下面举几个例子。
序号 | 订单详细信息 | 订单条件 |
---|---|---|
1 | 创建订单。商品数量 = 1 | 订单数量 < 数据库数量 |
2 | 创建订单。商品数量 > 1 | 订单数量 < 数据库数量。 |
3 | 创建订单商品数量 = 1 | 订单数量 > 数据库数量 |
4 | 查看订单状态 | 数据库状态 = 活动 |
5 | 查看订单状态 | 数据库状态 = 已发货 |
6 | 查看订单状态 | 数据库状态 = 已取消 |
7 | 查看订单状态 | 订单 ID = 无效 |
8 | 检查产品可用性 | 产品数量 >0 |
9 | 检查产品可用性 | 产品数量 =0 |
10 | 检查产品可用性 | 产品 ID = 无效 |
第 3 阶段 - 测试执行
测试执行采用自下而上的方法,即首先进行服务级别测试,然后进行集成级别测试,最后进行 端到端测试.
1)服务水平
让我们考虑一下 索阿普伊 工具被视为用于测试应用程序。
- wsdl 和URL浏览到SOAP的测试窗口中。
每个服务的请求将显示在请求窗口中。
通过根据服务级别测试用例修改数据,为每个测试用例创建请求。
测试用例 | 请求 | 预期响应 |
---|---|---|
创建订单。商品数量 = 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)端到端级别
业务流程和用例在用户界面上执行。
- 创建包含多件商品的订单 –
- 用户打开一个网站。
- 去下订单。
- 查询有效产品和数量并将其添加到购物车。
- 添加其他有效产品和有效数量并保存订单。通过新的付款方式付款并下订单。
- 应显示“订单成功下单”的消息。
- 测试人员应验证整个流程是否完成且数据是否出现偏差。
结语
通过制定正确的测试、资源、工具和合规性策略来提供良好的服务,SOA 测试可以提供完整且完美测试的应用程序。