质量的含义并不是简单地指减少缺陷。从根本上说，质量意味着构建那些满足用户需求的东西，包括现在的，还有未来的。对于一个高质量的产品，没有缺陷是必须的，但这并不意味着需要满足足够多的规范。软件质量也一样。虽然大量保证软件质量的工作都放在减少bug上，但是，这个消除bug的过程仅仅只是软件质量的开始。

无论采取何种方式的质量保证措施，软件质量的真正挑战在于如何保证软件满足需求。在现实世界中，质量保证(QA)人员只是简单地根据需求文档来建立一个测试计划，并且根据这个计划来执行测试。一旦这个项目通过了所有的测试，那么，这个项目也就成功了。但是，在现实世界中，在项目进行过程中，甚至在项目结束之后，需求仍在不断变化。对于大多数在项目开始阶段精心制定的QA计划而言，这些变更的需求所带来的搅乱是最恐怖不过了。

当然，业务需求不断变化，这个环境也为面向服务的架构(SOA)提供了完美的成长沃土。SOA提出了一种元数据驱动服务抽象，其目的非常明确——使IT采用敏捷的方式来响应需求的改变，它能够为业务用户提供更强大的功能和灵活性。然而，如果使用或组成SOA的服务(或是应用)质量很差的话，那么，构建于其上的、SOA的核心敏捷优势当然也就一击即溃。

日渐复杂的SOA测试工具

随着各大公司开始提出他们的SOA新方案，因此，面临这些改变时，质量应该放在首位。然而，在大多数项目中，质量并没有得到足够多的重视，尤其是当一个团队采用自底向上的开发方法来实现SOA时，他们是直接在遗留系统上创建web服务接口的。对于这样的团队，他们受限于这些服务接口，因此，他们的SOA项目架构很容易，但是软件开发却相当困难。最终，他们不得不采取普遍做法——仅仅对这些服务接口进行质量保证测试，这样做的局限性很大。

对于SOA测试工具而言，Web服务测试仅仅是最基本的功能。但是，实际上，市场上有很多工具自称是SOA测试工具，但其实际功能并不比web服务测试工具多，Web服务测试工具能够使公司通过减少缺陷以及保证服务符合开始的需求来提升web服务(包括服务消费者)。许多自称是SOA测试工具的工具仅仅是web页面测试工具的更新版本，它们泛化了web接口，基本上把web服务当作是一个没有用户界面的网页。虽然，这类web服务测试工具所服务的对象相当重要，但是，它们无法为真正的SOA实现提供所要求的质量保证。

更为成熟的SOA测试工具考虑到这个事实:服务不仅仅是基于标准的接口---而是来自多样的、异类的来源的抽象。这些工具把SOA质量问题当作集成测试的一个挑战，因此，目前市场上，许多SOA测试工具都是由集成测试产品演化而来，这就没什么奇怪的了。这些工具模拟服务请求和其他事件，通过服务接口和底层中间件、应用和数据源，揭示出在目前的分布式系统环境下，多种移动部分之间进行复杂交互所产生的细微的缺陷。虽然，对于所有的SOA质量体系而言，这种集成测试是其中的关键部分，但是，从根本上说，与web服务测试类似，这仅仅是一个设计阶段的活动。至今，还没有一种方式能够在服务实施后提供非常行之有效的测试。

最为成熟的SOA质量工具考虑了整个服务的生命周期—设计阶段，执行阶段，和变更阶段。通过验收测试不再意味着产品可以马上进行发布，因为实际上，SOA实现就是由这些很自然的不断变化的过程所组成的。SOA质量必须是一个不断进行的过程，它不断地确认现有的服务配置是否满足业务的需求。

为了实现高级的质量测量，这些工具必须关注SOA元数据测试，因为元数据是所有SOA实现响应动态变化的业务需求的核心。发生在变更阶段内的改变即元数据改变，包括面向服务的业务应用(SOBA)配置改变、规则改变，以及服务规约改变。目前，最先进的SOA质量工具必须提供：在开发环境中，对这些元数据的变更进行测试。

SOA质量最佳实践

然而，仅仅增加您的测试工具的成熟度，这并不等同于您的SOA就会有更高的质量。事实上，如果QA团队把SOA项目看作是一个传统的软件项目，那么，它的质量就可能会受到影响，因为传统的项目并没有灵活的业务需求——ZapThink称之为SOA的“元需求”，也就是能够支持变化的需求。目前对元需求的测试是缺失的，在QA实施过程中留下了一个很大的空白。

为了处理元需求，SOA继承了敏捷运动的最佳实践，包括迭代、预先测试开发。通过这样的方法，架构师把SOA实现分成独立的迭代或是特定的，小范围的“微型项目”。开始的时候，通过合约和策略，元数据与每一个迭代关联，项目组通过制定一个测试计划来推动实现服务所必须的开发工作。然后，项目组继续完成其他的迭代，直到所有在测试计划的测试都通过。最后的步骤是重新评估剩余的需求(这些可能在之前的迭代中被改变)来为下个迭代做计划，如果有必要还要重复这个步骤。

然而，SOA质量最大的挑战，也许在于贯穿于服务生命周期的质量维护，特别是一旦SOA 实施到位。问题是，SOA实现越成熟——即:服务抽象实现维护业务用户和底层的IT性能间的灵活的分离越好——传统的QA方法就越不适用。当今大多数IT公司，他们采用的是各自独立、但又类似的QA及生产环境。在认同改变产品环境能够起到促进作用之前，QA人员将所有新添加的以及已修改的代码加载到新环境中，并且在核心内容中进行测试。在一个成熟的SOA环境里，想要维护一个运行系统的有效的拷贝，实际上是不可能的，因为服务、配置和相关的元数据都在不断地改变。结果是,对一个类似的QA 环境的维护很快变得毫无意义。

解决这道质量难题的办法是:将新的和被修改的服务连同服务配置在一个实际的, 产品环境中进行测试。保证一个新配置的所有方面仍能满足需求的唯一的方法是通过产品服务来执行测试信息。现在，如果说您应该在生产中进行测试，那相当于建议您为您的房子重新布置电线——这是可能的，但您必须特别小心, 知道您在做什么, 并且提前计划好。在SOA的情况下, 提前计划意味着服务(也包括服务消费者) 一定能支持某一种测试方式。

为了说明服务测试在开发中如何进行, 让我们一步步地，通过一个服务修改实现版本1 到版本2 的例子来进行说明:

1.当版本1在运行时，把版本2在测试模式下置入产品中。

2.从harness(一个为此配置的测试工具)或理想地从本身也在测试模式下的产品服务消费者那，通过版本2发送测试消息。

3.一旦测试通过，把版本2置为产品模式(手工或自动地) 。

4.通知服务寄存器:任何支持版本2规约的服务请求现在将发送至版本2。

5.设置版本1状态为反对(deprecated)，假如反对策略要求这一步。

6.如果版本2 的突然出现问题, 恢复到版本1 (如果您的策略要求如此) 。修复版本2 的问题并重复以上过程。

7.依据您的反对策略，从产品中剔除版本1。

如何在一个开发系统中执行QA过程，需要注意以下事项:首先,这个 QA 过程应该是策略驱动的。结果是，这样测试过程本身就是面向服务的, 它要满足SOA的元请求需要经过一个漫长过程。其次, 它应该是弹性的。既使一个充分被测试过的服务仍然可能在产品中失败, 因此，QA 过程应该把对业务的影响减到最小—并且因而最大化服务间的松耦合。但最重要地是, SOA 质量要求提前计划。架构师必须把对测试模式和反对策略的支持作为设计服务的要点。

ZapThink所做的

"提前计划" 是ZapThink SOA道路上又迈进的一步，它是管理框架的里程碑。在您把任何服务作为SOA 项目一部分实施前, 这个管理框架应该包括关于您的服务在接下来将需要支持的策略的细节, 也包括反对策略和测试策略。(ZapThink 利用ZapFlash掩盖了服务版本和反对，使我们不必"为SOA 变动和版本管理伤神" 。)如果您未添加质量到您的架构中,那么您的SOA 测试工具怎么先进都是无关紧要的。因为在SOA 的其它许多方面, 这些工具不会给您最佳实践。反而, SOA最佳实践会帮您从您的工具中获得最大受益。

事实上, ZapThink经常同那些没有做好充分的提前计划的公司进行交流, 他们现在面临一个困惑: 怎么管理服务的版本而不影响服务消费者的使用? 在多数情况下,都没有一个很好的答复。他们只是简单地根据以往经验，又不得不调整他们的SOA 并重新启动。这对那些开辟SOA 最佳实践道路的早期应用者来说是可以的，然而,对于现在那些开始考虑SOA计划的机构, 没有理由在一开始不构建SOA质量。