也许SOA 已死,也许它渴望着避风港,但确定的是在好的SOA 是由什么构成这个问题上依然充满了未知。很多供应商提供了SOA 工具,表明看来是否采用SOA 取决于你现在所处的阶段,但实际上这只是他们兜售工具的一种手段而已。就像 IBM 所说的这样:
你的公司对面向服务的架构(SOA)是什么立场?你是否清楚当前 SOA 的成熟度和改进的可能性?IBM SOA 资产工具可以帮助你充分利用 SOA 的价值,因为其目标就是不断改进公司的成熟度级别。
然而一旦采用了 SOA(无论使用到何种程度),你都需要对其进行测试。还好那些向你兜售工具的供应商也提供了相应的解决方案,但好的 SOA 测试工具是由什么构成的呢,你是否已经被绑定到特定的 SOA 基础设施上了呢?这就是 Eric Roch 所提出的问题。他给出了一些选择标准:
- 感知测试的接口:用于测试的标准化接口和消息
- 基于消息的测试自动化:对测试脚本的记录、重放和管理
- 虚拟化:模拟虚拟的服务供应商和消费者的能力
- 模仿:作为衰退测试的一部分而模仿应用的能力
- 负载测试:进行负载测试的能力
- 验证:组件(消息)与应用(数据存储)级别上的验证功能
- 组件:支持 Java 与 / 或.NET 组件
- 自省:支持 WSDL 与 XML 以生成数据和运行测试
- 管理:管理测试用例、脚本、数据与结果
- 安全:SSL、WS security 联盟、数字签名
- 符合工业的数据格式:如 EDI、HL7 等
- 持续测试:自动构建、部署与测试
几年前, InfoWorld 曾报道过几个基于 SOAP 的测试工具:
基本说来,测试基于 SOAP 的 Web Service 涉及到三个步骤:构建 SOAP 请求、提交请求并解析相应。听起来很简单,实则不然。有效的 SOAP 测试工具不能仅仅以对用户友好的方式来构建请求,它还必须能够让用户以真实的序列组织并安排请求,提供改变请求输入值的方式并智能的调整请求以将 Web Service 暴露给参差不齐的使用场景。简言之,工具应该可以在最接近真实世界的情况下运行。
尽管工业界已经认识到Web Service 仅仅是SOA 的一个方面,但不可否认的是现在的大多数工具都认为SOA 就是SOAP 和WSDL。
你有中意的SOA 测试工具么?对Eric 的标准有什么不同意见?你知道有哪些好工具能跨越不同的实现技术么?
查看英文原文: Which SOA Testing Tool?
评论