【IT168 技术文章】

    原文：

    Three open source Web service testing tools get high marks - Capable soapUI, TestMaker, and WebInject toolsets shine once you conquer their learning curves

    - Rick Grehan

    由于IT界对Web services的持续关注和偏爱，以及越来越多的Web-service构建工具的出现，Web service变得更加容易创建 – 并且，很容易一团糟。

    Web service其实就是一些暴露给网络（不管是内网还是外网）的程序的集合。而一个Web service的错误可能激怒的不仅仅是监视和维护着服务器的经理和管理员，还有调用了你的Web service的客户。要么把你的Web service做好，要么等着两边的指责。

    在本文中，我会分析3款声称能验证你的Web services的正确性的工具：soapUI、TestMaker和WebInject。三款都是开源的，能免费下载并整合到你的下一个Web services项目中去。

    需要注意的是：在使用这些工具之前你应该理解SOAP和HTTP协议。有些商业产品提供的是SOAP的“伪代码”。把那些难于阅读的XML翻译成易读的伪代码，能帮助新手和有经验的SOAP用户明白某个SOAP请求和响应之间发生的事情。这三款开源的Web service测试工具需要额外的工作，我推荐中等级别的开发人员使用，学习曲线会适当地比商业产品的长。

    SoapUI1.6 

    我用的是1.6版本的soapUI，一款从Eviware而来的基于Java的工具。这个版本的soapUI在自己独立的UI里执行；新的1.7版本包括NetBeans、InterlliJ和Eclipse的插件。

    用户界面遵循普遍的IDE架构设计：左边是导航面板，右边是内容面板，额外的属性面板放在底部。如果你用过类似Visual Studio的IDE的话，你会发现使用soapUI很顺手。

    soapUI把工作组织成项目。每个项目主要由需要测试的接口来识别。在这里，接口是指另外一端的指向一个暴露了Web service方法的站点的URI（统一资源标识）。你可以很快地创建一个基本的项目结构；soapUI能接受一个文件的WSDL或者一个Web service终点传输的WSDL。

    项目被有层次结构地组织，并且包含一个或多个TestSuite，TestSuite包含一个或多个TestCase，TestCase包含一个或多个测试步骤。真正的工作 – 发送请求、接受响应、分析结果、改变测试执行流程 – 发生在测试步骤这个层面。TestCase收集和组织需要执行某个对目标的特定操作的步骤。TestSuite汇总那些发生在某个特定区域的Web service的TestCase（例如订购一本书所需要的操作）。你可以通过右键点击项目树中的父节点并选择上下文菜菜单中的“New”菜单，来创建新的TestSuite、TestCase和测试步骤。

    soapUI通过检查附加给测试响应的断言来判断测试是通过还是失败。有大量的断言可供选择，从“simple contains”测试 – 如果某个提供的字符串匹配则表示成功 – 到“XPath matching”，对响应信息执行复杂的XPath表达式匹配成功则表示测试通过。

    测试步骤与程序代码很类似。目前，soapUI定义了6个测试步骤类型，最普遍的是请求（Request），发送一个HTTP请求给目标地址，并接收一个响应。可插入条件跳转测试步骤（Conditonal GoTo）来控制流程。一个或多个检查最近的响应的Xpath表达式是必不可少的。第一个表达式的成功会导致相关测试步骤分支的执行。

    soapUI最强大的是Groovy测试步骤。Groovy是类Java的轻量级脚本语言。一个Groovy测试步骤可以是任何Groovy代码，也就是说基本上Groovy能做的事情，在测试步骤中也能做。测试步骤中的Groovy代码可以访问soapUI框架。例如，一个Groovy测试步骤可以通过JDBC读取数据库的信息，与前一个测试步骤的响应信息进行比较，并响应地修改执行的流程 – 甚至执行另外一个TestCase。

    除了功能测试外，soapUI还能对Web service进行压力测试。每个压力测试包含一个或多个TestCase的执行，并且可以调整用于模拟各种各样的场景。你可以指定测试执行一定量的时间长度，或者一定量的迭代周期，指定以并发的方式执行还是随时间线性变化的方式。

    当压力测试完成后，一个压力测试编辑器会为每个TestCase提供大量的统计数据：执行的次数，最大、最小、平均执行时间等。还可以在统计图表页以图表的形式查看这些数据。

    让soapUI运行起来很容易；能很快地构建一个基本的项目和基本的测试。我对这个工具不满的地方是：在系统中没有上下文帮助，这让你在某些区域想知道可供选择的是什么变得困难。不管怎样，文档提供的还是挺不错的，只要持续使用，一些最初的理解上的混淆都会慢慢消失。

    TestMaker

    TestMaker是PushToTest的一个Web service测试工具。它需要Java1.4或以上。我把TestMaker4.4安装在Ubuntu Linux6.10，看Web service测试在Linux会是怎样的。安装很简单，一旦设置好JAVA_HOME环境变量后，TestMaker启动和运行都没有问题。

    TestMaker的测试是用称为“测试代理”（test agents）的脚本来完成的。TestMaker提供一个“代理向导”（Agent Wizard）来读入WSDL定义并自动创建一个测试代理的基本结构。

    需要指出的是：TestMaker不仅仅能测试Web services；它还能被用于测试Web应用程序。与TestMaker绑定在一起的还有一个网络监视工具，能监视浏览器和目标Web应用之间的HTTP通信，并且从交互过程中产生测试用例。然而，我没有体验那些功能，因为那与Web services的关系不大。

    TestMaker的测试代理是用Jython（用Java写的Python）写的。这是把双刃剑。一方面，TestMaker的脚本可以变得很强大，拥有编程能力。Jython可以访问所有Java库，还有TestMaker提供的类和方法。TestMaker最大的库是TOOL（Test Object Oriented Library），它包括所有处理各种通讯协议的类：HTTP，HTTPS、SOAP、JDBC等。因此，你可以创建很精细的测试用例来处理任何Web service可能被调用的客户端应用。

    另一方面，你需要掌握Jython来充分利用TestMaker，或者换句话说，你需要知道Python和Java。这未必是件坏事，但是它绝对意味着TestMaker的学习曲线要比其他工具陡峭。

    由代理向导（Agent Wizard）创建的基本的测试代理（test agent）是很简单的：它知道目标服务的Web方法，并且执行不会出现错误，但是它没有真正执行任何请求、响应或者测试结果。我发现我需要检查一个测试代理例子的源代码来填写缺少的内容。

    一旦你跨越了陡峭的学习曲线，就可以很容易地通过拷贝、粘贴和调整已有的代码来创建新的测试。另外，用户界面的用户体验很好。最开始启动TestMaker的时候，它会打开一个“QuickStart”窗口，在这里，你可以运行代理向导（Agent Wizard），直接跳到测试代理提供的例子，或者深入阅读它的文档。TestMaker的用户界面也是标准的多窗口IDE，左边是导航面板，右边是编辑区域，结果显示区域在右下端，类导航视图界面在左下端。

    TestMaker可以在命令行执行，因此，你的测试代理（test agent）可以被自动化系统执行。另外，TestMaker还绑定了Apache Axis TCPMonitor工具，它让你可以监视某个端口的HTTP信息交换。这对于检查内部请求/响应对来决定如何编写Jython测试代码时会很有用。

    商业的TestMaker版本添加了XSTest，提供性能测试和容量测试（Scalabillity testing），一个监视面板提供实时的结果，报告能力，还有TestNetWork – 能远程执行测试代理（test agent），因此，允许你搭建测试代理服务器来同时测试目标Web应用程序。

    TestMaker的文档很好，工具的感觉像专业的应用。但是，很难掌握和精通。需要留出大量时间来阅读指南和分析那些例子的源代码。