在前面的文章中，我们从用户的角度讨论了Web服务测试。现在我要研究一下服务器。为了测试整个系统，你要有一个工作的客户端，但是在完成测试之前还有很多其它的工作要做。如果你的架构遵循了最佳方案。很多组件可以在服务器环境外部完成测试。

　　单元测试原理

　　单元测试的目的是为了提供一个框架。源代码的个别单元运行良好时可以通过该框架表现出来。这些源代码最先组建起来，然后在加入了项目后，修订目标也被包含其中。在最终产品里，我们并不会看到创建这些大量代码所涉及的原理。但是在测试中会应用这些原理。

　　尽管你不会经由全部的单元测试路线，设计代码的原则，因此分别测试这些元件依然是有效的。当然，光测试元件并不能保证最终产品能够满足你的要求，必须保证各个元件都能正常运转。只有测试了带有众多客户端的整个系统时，才会揭露性能和线程问题。

　　使用测试工具

　　开放源Junit框架很受Java程序设计师的欢迎。通过各种开放源加载项，基本框架得以扩展。其中的一个扩展叫做SQL单元测试框架，该框架意在测试数据库储存过程。NetBeans 和Eclipse IDEs都可以支持Junit框架。

　　如果你没有使用Java，不必担心，这里有许多用其他语言编写的开放源单元测试框架。浏览opensourcetesting.org网站，我找到了用于Ada， Javascript, .NET, PHP, Python, Ruby, SQL 以及Tcl的单元测试工具。该网站也列出了许多其它不是建立在单元测试理念的测试框架。

　　后端测试

　　如果你的服务需要一个数据库连接，你就要计划用典型的操作在服务器环境外部做一些实际可行的负载测试。我之所以这样说是因为你的最终服务有有性能问题。我们最先遇到的不可避免的问题就是数据库响应时间会延迟多久，其它的服务代码需要花费多少时间。

　　监测运行中的Web服务

　　你已经完成了所有的单元测试，现在是时候将服务放在网上了，用真正的请求瞬间干扰它，看它是如何响应的。JAMon是一个开放源代码，是监测所有Java程序非常有效的工具。为了有效并仔细的监测，你需要更改你的代码来启动或者停止“检测器”功能，但是你也可以在基于Java语言的HTTP Web服务应用上简单地添加一个“过滤器”就可以获取大量信息。

　　为了展示使用JAMon是多么简便，我下载了最新的JAMon数据包(2.7版本)，并用部署描述符(web.xml)的附加指令为特定的程序设置了一个过滤器。该配置将所有的HTTP请求发送到这个过滤器，在启动“检测器”之后，该过滤器将没有修改的请求传递到原来的程序。当程序响应时，监测停止，数据被保存了下来。

　　<filter>
　　    <filter-name>JAMonFilter</filter-name>
　　    <filter-class>com.jamonapi.JAMonFilter</filter-class>
　　 </filter>
　　 <filter-mapping>
　　    <filter-name>JAMonFilter</filter-name>
　　    <url-pattern>/*</url-pattern>
　　 </filter-mapping>

　　为了使用JAMon的远程监测功能，我安装了基于HTML/JSP的监测管理功能，并附加了一些适当的安全限制。在向被监测的程序多次提出请求后，我打开了JSP管理，呈现的详细监测结果消除了JSP管理。图表每一个独特的URL显示了瞬间干扰的数量，最初和最后的存取时间，有效请求的数量以及在毫秒发生额度响应时间的统计性分类。默认的监测数据以HTML图表的形式显现出来，但是你可以选择以XML, CSV或者MS Excel格式进行输出。

　　监测Java内存的使用

　　许多Web服务的性能问题都和内存使用有关。除了Java本身的内存管理之外，这里还有许多设计不够精良的Web服务，这些服务会慢慢地消耗内存，并在某个时刻突然瘫痪。Java version 6带有几个性能监测和故障诊断工具，这些工具可以和一个运行的JVM相连。有些工具被标注为“实验性”，所以你可能想看一看Jprobe，这个更为完善的工具。

　　Jprobe是最早的Java内存监测工具之一。目前的Jprobe是8.0版本，Jprobe多年来一直好评不断。除了内存监测以外，Jprobe能够跟踪线程监测性能一直到代码行。尽管Jprobe是付费软件，你可以下载一个10天的免费试用版本，那里面有一个用于信息储存分析的免费Eclipse插件。

　　用记录过的请求进行监测

　　典型的SOAP用户在内存中建立一个请求，并将该请求作为一个XML结构，然后将其序列化。这个过程会耗费很多时间。用在这种方式下生成的请求测试服务，限定了你在一个小型网络上产生的负载量，并且很难测试其对客户端错误的回应。正如我在前面的文章里谈到的，像TCPMON 或者soapUI这样的工具准许你将一个客户请求记录为一个文本文件，该文本文件可以在负载测试时重播。并且在记录文本中生成一个请求的速度要比执行一个SOAP客户端快得多。

　　不要依赖你的SOAP客户端进行服务器测试。因为如果你的服务使用了WS-*相关的协议，很难迫使或者不可能迫使一个SOAP客户端建立一个非法请求。要想完全信任你的服务程序，你需要保证你的服务程序能够准确地扑捉所有的输入错误。从一个合法的记录请求开始，你能够修改像数字签名这样的各种标题和SOAP信息内容。