小心进行 J2EE Web Services 的测试

核心提示：我们已经了解了很多关于Web Services开发方面的知识，而对于Web Services测试所面临的挑战却知之甚少，小心进行 J2EE Web Services 的测试，本文将阐述对Web Services功能性和互用性的测试，本文同时也指出了与传统测试模式相比Web Services测试所面临的挑战，•

　　我们已经了解了很多关于Web Services开发方面的知识，而对于Web Services测试所面临的挑战却知之甚少。本文将阐述对Web Services功能性和互用性的测试。本文同时也指出了与传统测试模式相比Web Services测试所面临的挑战。本文的目标读者是开发人员、测试人员以及那些对Web Services的技术知识或工作方式没有深入了解的项目经理。同时本文假设读者已经很熟悉Web Services的基本知识。
　　
　　下载作者提供的与本文相关的文件
　　
　　以下所述及的示例的环境由WebLogic Server 8.1和Microsoft Windows .Net构成，二者所用操作系统均为windows 2000。
　　
　　挑战
　　测试Web Services的有效性、性能、可伸缩性、可靠性以及安全性时所面临的主要挑战是 Web Services的分布性。
　　
　　为了使完整的Web Services能够实现预期的功能，就要求客户端和服务都要满足一系列的要求。接口必须在其WSDL文档中正确描述出来，消息必须遵守传输协议规范（如HTTP1.1）和消息协议（如SOAP 1.1）。同时消息必须遵守描述该服务的WSDL文档中的契约，要求同时考虑到消息的内容和传输层的绑定。加上综合的安全条款、互操作性问题、UDDI注册要求以及一定负载下的性能需求，就很轻易发现为什么网络测试不是无足轻重的事情。
　　
　　Web Services组件可由多个利益相关者来共同构建和部署。因此，测试这些组件过程中会发现确定代码质量、可用性等都有很大的难度。Web Services的标准是简单的，数据驱动的，并且共享一个公共的基于xml的基础。传统的测试工具可能不足以有效地测试这些标准。而且GUI自动化工具也不足以有效地测试Web Services的接口点和消息格式。
　　
　　功能测试
　　该测试的目标相当直观易懂：确保服务器能够对给定的请求发送正确的响应。然而，由于Web Services的复杂性，该任务原非想象的那么简单。对于大多数的Web Services而言，它不可能精确预见客户端会发来什么类型的请求。枚举所有可能的请求并不切实可行，因为可能输入的空间要么是没有边界，要么就是无穷大。因此，验证服务器是否能处理大范围的请求类型和参数是极其重要的。
　　
　　public boolean execute(String action, String symbol, int quantity)
　　
　　throws javax.xml.soap.SOAPException{
　　
　　Detail detail = null;
　　
　　detail = SOAPFactory.newInstance().createDetail();
　　
　　detail.addChildElement( "Stock Trade" ).addTextNode( "failed" );
　　
　　System.out.PRintln("execute() in webservices.stock.trade webservice has been invoked
　　
　　with following arguments:: action:" + action +
　　
　　" symbol:" + symbol + " quantity:" + quantity);
　　
　　if(action == null) {
　　
　　throw new SOAPFaultException(new QName( "http://StockTrade/execute", "ServerFailed" ),
　　
　　"action parameter is null.",
　　
　　null,
　　
　　detail);
　　
　　}
　　
　　if(symbol == null) {
　　
　　throw new SOAPFaultException(new QName( "http://StockTrade/execute", "ServerFailed" ),
　　
　　"symbol parameter is null.",
　　
　　null,
　　
　　detail);
　　
　　}
　　
　　if(action.equalsIgnoreCase("BUY"))
　　
　　System.out.println("BUYING quantity: "+ quantity + " of symbol:" + symbol);
　　
　　// Invoke method to execute trade here.
　　
　　else if(action.equalsIgnoreCase("SELL"))
　　
　　System.out.println("SELLING quantity: "+ quantity + " of symbol:" + symbol);
　　
　　// Invoke method to execute trade here.
　　
　　else
　　
　　{
　　
　　System.out.println("INVALID action: "+ action);
　　
　　throw new SOAPFaultException(new QName( "http://StockTrade/execute", "ServerFailed" ),
　　
　　"Invalid Action:" + action,
　　
　　null,
　　
　　detail);
　　
　　}
　　
　　return true;
　　
　　}
　　
　　
　　代码摘录：Stock Trade Web Services
　　该段摘录的代码是Stock Trade Web Services的“execute()”方法的实现代码。该方法首先验证输入参数的有效性，验证成功才执行功能。举例说明，假如参数action是空值，它就会抛出一个SoapFaultException异常，用faultstring参数（第二个参数）说明造成异常的原因。为了举例说明，在对参数symbol进行相似的验证之后，Web Services给出了处理机。在实际的情况下，商业逻辑应该在此位置中实现：
　　
　　try{
　　
　　// Setup the global JAXM message factory
　　
　　System.setProperty("javax.xml.soap.MessageFactory",
　　
　　"weblogic.webservice.core.soap.MessageFactoryImpl");
　　
　　// Setup the global JAX-RPC service factory
　　
　　System.setProperty( "javax.xml.rpc.ServiceFactory",
　　
　　"weblogic.webservice.core.rpc.ServiceFactoryImpl");
　　
　　StockTrade_Impl ws = new StockTrade_Impl();
　　
　　StockTradePort port　= ws.getStockTradePort();
　　
　　boolean returnVal = port.execute(action, symbol, quantity);
　　
　　System.out.println("The webservice got back the following result:" + returnVal);
　　
　　}catch(Exception e) {
　　
　　}
　　
　　代码摘录：Web Services的客户端
　　上面的一段代码描述了测试客户端如何激活前面讨论的Stock Trade Web Services，该例子使用了JAX-RPC API（JAX远程处理应用程序接口函数），并且假设在读者的CLASSPATH中已经含有了必要的BEA提供的JAR文件。这是一个静态实现，在这里可获得一个stub实现的实例。获得stub实现后，Web Services的“execute”方法就会被激活。
　　
　　互操作性测试
　　SOAP和Web Services的承诺之一就是互操作性。就是两个应用系统可以自动交互而不需要人为的介入。Web Services未来成功的要害就在于互操作性。
　　
　　Web Services互操作性测试套件的目标应针对于测试以下方面：
　　
　　•服务器分析客户端的SOAP包的能力。
　　
　　•服务器对包中所含的已编码参数进行反串行化的能力。
　　
　　•客户端对由服务器作为响应发送而来的SOAP包进行分析的能力。
　　
　　•客户端对从服务器发回的已编码参数进行反串行化的能力。
　　
　　测试模式
　　对于一个WLS客户和.NET Web Services：
　　
　　• 用Microsoft Visual Studio在目录/InetPub/wwwroot/DotNetServices/下创建一个.NET Web Services。
　　
　　• 在WLS端，在为DotNetService 提供了WSDL URL后，用WebLlogic clientgen ant task生成一个clientjar。
　　
　　•从testclient，对JAVA Stub进行一次调用。
　　
　　WebLogic Server
　　
　　.NET Server
　　
　　.NET Web Service
　　
　　WLS Client
　　
　　// STOCK TRADE WEB SERVICE
　　
　　// The Stock Trade web service executes a trade and returns result.
　　
　　[WebMethod]
　　
　　public bool execute(string action, string symbol, int quantity)
　　
　　{
　　
　　if(action == null) {
　　
　　Console.WriteLine("action null");
　　
　　return false;
　　
　　}
　　
　　if(symbol == null) {
　　
　　Console.WriteLine("symbol null");
　　
　　return false;
　　
　　}
　　
　　if(action.Equals("BUY"))
　　
　　Console.WriteLine("BUYING quantity: "+ quantity + " of symbol:" + symbol);
　　
　　else if(action.Equals("SELL"))
　　
　　Console.WriteLine("SELLING quantity: "+ quantity + " of symbol:" + symbol);
　　
　　else {
　　
　　Console.WriteLine("INVALID action: "+ action);
　　
　　return false;
　　
　　}
　　
　　return true;
　　
　　}
　　
　　
　　代码摘录：.NET Web Services
　　上面摘录的一段代码是Stock Trade Web Services，它是前面所设计的WLS Web Services的.NET版。它用与JAVA非常相似的C#语言编写。文件名是“StockTrade.asmx.cs”。
　　
　　代码编写完成后，在WebLogic服务器上部署WLS客户程序，在.NET框架上部署.NET Web Services，验证客户端是否能调用Web Services。
　　
　　.NET客户端和WLS Web 服务器端
　　• 创建一个WLS Web Services（EAR文件）
　　
　　• 使用WLS Web 服务WSDL并通过运行wsdl.exe生成一个.NetClient Stub。这一过程将生成一个.cs文件，该文件包含对应于WSDL提供的Web Services的方法定义。
　　
　　• 另外一步是在Stub中定义一个新的构造函数，并将WSL URL作为一个参数。这一步是必须的，因为wsdl.exe所生成的Stub在缺省情况下指向USDL URL中的本地主机。
　　
　　• 创建一个.NetClient 类（另外一个.cs文件），该类实际上以WSDL URL作为构造函数参数。该类是一个代理类，它含有与Stub中所定义的相同的方法