只要我们想想Web服务，就很明确了。把我们现有的一些应用暴露其业务功能为Web服务是一个很好的主意。实际上，确有一些IT公司在初涉SOA领域时首先做的就是这件事。他们创建起Web服务库。而只要你选择正确的业务构件，就会马上见效。
但是你如何测试这些Web服务，知道它们就是在做你想要它们做的事情呢?要知道原来的应用可能根本没有预想到自己会被做成一些构件的。程序代码可能是意大利面式的。想象一下某个相当简单的东西，比如管理用户数据库。假设，我们的Order Processing应用就这么干，因此我们需要把用户更新功能(即添加、修改和删除用户)作为web服务暴露出来。我们了解此应用，因此我们知道其程序逻辑做了我们想要它做的事情。但它还做了别的什么事情吗?这就是潜在的问题。
Web服务的单元测试
我们要如何做呢?我们可以读源代码。这是个好主意，去查看时候在我们添加、修改或删除用户时调用了我们不想调用的逻辑。但我们需要做的比这更多。我们除了把新的web服务与Order Processing应用一起测试之外没有别的办法。我们可以在测试所有可能的新的Customer Update web服务接受和发出的SOAP消息组合时，对Order Processing应用使用现有的回归测试。当我们完成这项测试后，所有我们所做的事就是web服务的单元测试。因此，当我们暴露任何要用的web服务时，我们都需要做这样的测试。实际上，这样的测试手段应该成为IT管理的一部分。
假设现在的情况是我们用一些web服务和一些新的逻辑构建起组合的应用。我们希望每个web服务都已经被单元测试过了。于是测试过程应该按如下循环进行:创建测试计划，创建测试床以及进行测试(测试设计，编写特定测试用例，编写特定脚本，执行测试，测试报告)。我们使用的已经被单元测试过的web服务不应该让我们过于自信。就算在单独测试时它们没有出错，也很有可能在一起工作时出错。我们的测试方法应用能让我们打散端到端的交易，探测失败出现的地点。这意味着要能够捕捉并分析从一个构件传到另一个构件的所有SOAP消息。
集成测试
集成测试和传统的系统测试非常不同。首先，我们做单元测试，然后做集成测试。额外的事情是当我们做集成测试时，我们必须对用到web服务的应用做回归测试。
另两种测试(压力/性能测试和交付测试)也需要这个额外过程。我们需要测试相互关联的东西，这样它才能在真实的环境中运行起来。
可能我们已经提出了问题。但事情可能变的很复杂。对于可行但低效的垂直应用，测试还相对简单。你只需对应用构件做单元测试。然后对整体做集成测试。然后，如果你对性能有什么要求，你可以再做压力测试。最后，你再做交付测试。创建测试床不是什么问题，你只需建立运行时环境并构建一套测试数据，或者从真实系统中提取一些数据。
SOA的问题在于它是端到端的。垂直应用和简单建立测试床将不复存在。随着SOA项目的深入，你将需要有更多的各种各样的测试床。事实上，你很可能需要能创建和拆除测试环境并从真实系统中提取数据的工具。没有它们，创建足够的测试床将非常困难。
压力测试/性能测试也会成为测试床的一个挑战。新的组合应用的运行决定了你会需要对很可能跨越很多不同服务器的整套端到端软件进行压力测试。
当前可以被管理的SOA测试情况非常少，如果有的话，组织就可以马上构建复杂的端到端组合应用。他们的项目会涉及到集成相邻的垂直应用或为核心系统增加浏览器接口，或者增加一些BPM。而当业务更复杂一些，他们就会发先SOA测试有多么复杂了。
文章来源于领测软件测试网 https://www.ltesting.net/
