一：基础篇

一直以来，测试是都是应用生命周期的一个单独活动，使用不同并且没有关联的工具。首先，开发团队会运行一套JUnit测试套件，作为建设过程的一部分。然后，质量保证团队会手动创建并运行了一套针对用户界面的功能测试。最后，性能团队将使用一套单独的负载测来试运行和监督完成的应用。

在传统世界里，这些团队之间并没有太多的信息和测试结果的交流，除了偶尔会有书面的“错误报告”，但往往队问题发生的根源描述比较简单。发生这种情况主要是因为现有的测试工具所产生的测试结果是矛盾的，并且在很大程度上与链条上的下一个团队无关。单元测试对于开发人员测试代码中的结构型漏洞是很有帮助的，但这些测试并没有转化成质量保证小组任何可用的业务信息。质量保证小组不得不自己进行用户界面测试，很明显，他们测试组件或代码的方法与开发人员追踪问题根源所使用的方式不同。

这不是一个非常有效的过程，所以企业开始围绕高效的过程工具调整人员，更好地处理工具，从而实现更好地管理开发和集成。敏捷性不只是提供更快的发布周期，而且还提高了企业应用的可靠性，为应用生命周期和控制工具“灌输”了更高程度的协作和控制。敏捷性还能提高开发过程的效率以及灵活性。但是，如果测试和验证处理得不恰当，风险就有可能会出现并损害这些成果。

在这一系列文章中，我们主要看看敏捷生命周期的四个方面：测试和质量管理、应用生命周期管理、IT业务、监测和业绩、IT和SOA治理。但首先，让我们先来看看经常遇到的主要应用过程工具。
　　

所有应用过程工具的目标是在软件生命周期中嵌入某种形式的工作流程，无论是测试、开发、操作、治理还是IT基础设施一体化。能够由主流过程工具直接测试和验证是大多数SOA和企业软件组件所必须的。

通过使用可执行的测试资产支持这些工具的工作流程，我们得到了一个更高程度的可预见性和性能，同时允许开发、测试和运营团队用自己喜欢的工具和方法更好地管理各自的过程。虽然供应商提供的许多解决方案可能会跨不同的工作领域（例如生命周期管理可能包括一些测试管理），我们提供了上述列表作为典型的IT客户环境中遇到的工具样本。敏捷开发实践的关键是与开发活动进行密切测试互动，已变加快产品发布时间并优先考虑商业功能

从本质上说，测试或验证是向上述过程和自动化工具存储、或提供的一种反馈，有助于实现SOA的敏捷性这一目标。在下一篇文章中，我们将讨论测试和质量管理。

二：质量管理

本节我们主要介绍SOA测试与质量管理。

在过去，TM（测试管理）工具中使用的测试“脚本”实际上主要是一步一步的指令（保存在Word或Excel文档中），手工测试人员通过按照这些指令点击一个已经完成的界面完成测试。当测试工作完成以后，测试人员需要检查测试管理用户界面的“检查框”，从而确认测试是成功还是失败了。由于今天的企业应用中包含如此众多的变化组件和中间层系统在，这种形式的手动测试不是非常充分，所以测试团队需要努力制定（运行）更为复杂的测试，能够实际测试到用户界面“背后”更深层次的功能---业务逻辑。

除了更深的功能测试以外，使用TM工具的团队要求测试套件的自动化程度更高。数量巨大的测试脚本全部执行完毕有可能会使SOA生命周期推迟数天或数周，严重影响了团队的灵活性，并且由于重复和人为错误使得测试的价值大打折扣。

因此功能测试、回归测试、负载/压力测试需要被直接存储在TM工具中---例如，作为可执行的命令行或X ML脚本。这样，一个复杂的测试就只需在TM工具中点击一下就实现了，而成功、失败和其它成果或问题就会自动写回TM工具中。

这样，整个团队都使用他们都熟悉的测试过程，同时还能进行涉及中间层的更深入的测试，与手工测试相比，执行时间节省95％以上。此外，测试质量提高了，因为测试团队可以专注于测试新功能，而不是重复机械执行对现有功能的测试。

通过这种方式，测试团队不仅实现了测试执行和结果反馈的自动化，而且还得到了一个很受欢迎的“副产品”---测试审计文件，它会及时地在某个时间点向你详细报告系统的工作状态。因而，测试工具被赋予了强大的功能，不仅能发现问题、强制执行，而且还能做出判断并向TM工具报告问题。

这一过程的总体目标是通过在开发、测试、业务分析和IT运营团队之间共享和迭代测试，从而实现更有效的协作。这增加SOA重用的级别，并加快了发布周期，因为所有团队能够将工作重点放在提供高品质的新功能，而不是每次产品发布都重复手动创建和执行测试。在下一篇文章中，我们将介绍应用生命周期管理。

三：生命周期管理

本节主要介绍SOA如何逐渐融入敏捷的生命周期。在这里，我们将研究一下应用生命周期管理（ALM）。

正如著名市场研究机构Forrester的Cary Schwaber所说的那样，最新的ALM平台将会改善开发过程，向应用工具提供普通服务。这一代的ALM软件在将需求、测试案例、bug跟踪和问题解决方案整合到一个应用套件中做了更多的工作。下图就简单说明了共享测试过程并把它作为协作资产。

将业务需求转换到软件中这一过程能够通过ALM工具自动完成。包括跟踪编程过程、储存源代码、执行测试案例（目的是确保功能），并记录产品的缺陷和改进。自动化测试历来只是被插入到ALM的“测试执行”阶段。这可以提供有关代码覆盖或替换成功或失败编译的统计数据。但是，功能更加强大的测试可以使ALM工具管理的生命周期的每一阶段增值。

例如，开发人员可以根据ALM库中存储的源代码检查测试，因为简单化的“基本路径”测试能够展示已经交付组建的既定功能。接着，质量保证团队会知晓有这些新资产，并运行和重复这些试验证明一个更大的可能进行的活动集。但是另外一个团队在集成和部署的过程中，可以使用开发和质量保证的所有的测试，将多个测试捆绑在一起，以确保用最小的成本得到整体回归和功能覆盖。最后，随着业务团队和支持团队的介入，他们可以运行、修改和检查对于平台的测试，以发现问题或确定ALM生命周期的下一阶段。按照这种方式实现共享，测试就变成了SOA协作资产，并增加了每个迭代周期的灵活性和速度，同时更好地确保了端到端业务流程的成功。

这种做法可以被任何测试工具所采用，无论你使用的是JUnit还是自动化程度更高的、无编码的测试工具。使用无编码测试环境的优势在于能够自动化执行测试，无需编码技能，它能够让非开发人员参与到上述周期中来。

在上面这个例子中，每次组件级的迭代被引入时，每个人都应该参与测试的制定和执行，这些测试被集成到一个更广泛的工作流程和业务流程中。一个敏捷机构允许多个团队的开发人员和非开发人员在开发结束前的很长时间就相互协作，共同致力于测试应用组件。这可以确保在每个迭代周期进行连续测试，以及更加可靠的方案修正和发布过程。

例如，一家保险公司可能会有将邮政编码与某种类型的汽车保险匹配的需求。开发人员创建一个组件，并利用一个能够显示一些邮编和保险类型匹配的简单的测试案例对它进行检查。质量保证团队可以利用一个包含完整的邮编/保险类型匹配的数据集重复这一测试，并且随后进行的系统开发都要进行这种测试。如果开发人员稍后更新了组件而所需的测试没有通过，那么这一情况就会报告给ALM系统，同时还配有问题根源分析。最后根据ALM系统的问题解决规则，有关团队互相沟通之后进行问题矫正。

四：IT运营和监测

本节是如何构建敏捷性SOA的第四部分，在这一节里，我们将主要研究一下IT运营、监测和性能。

一旦企业应用被部署完毕并投入使用，确保它的持续可用性、性能和准确性对于企业来说是至关重要的。在许多企业中，IT运营团队可能是整个测试和开发团队的一部分，或者被单独“抽取出来”作为一个独立的团队，职责就是提供一定程度的公正性，确保应用环境所需的服务水平得到满足。

运营管理和监督

主要的监测框架可以通过直接测试和验证受控系统，同时给IT管理控制台提供丰富的度量标准和测试输出来进行支持，比如Wily/CA Unicenter、TIBCO Hawk、HP OpenView、IBM Tivol等等。

在这些连续测试中，运营团队可以设置阈值或边界条件，如果有问题发生，测试框架就会发出警报。举例来说，如果性能过于缓慢，或者内存使用量或某个数据库表随着时间的推移按照一种非预期的方式增长，那么该测试应该向管理控制台报告一个失败信息，并且给系统管理员发送短信通知，同时还要提供测试案例用于问题分析和纠正。

用一流的工具和虚拟服务环境（VSE）进行性能和负载测试

确保交付的系统满足客户预期的服务水平协议（SLA）对于运营团队来说同样很重要。就目前高度互联的应用而言，市面上一流的测试和性能解决方案直到一个接口或一个完整的系统环境具备测试的条件时才进入应用生命周期中。虚拟服务环境（VSE ）能够确保使用性能测试工具（比如LoadRunner和SilkTest）的小组尽早介入应用生命周期中，这使得 每个测试环境的成本减低高达90％。

VSE捕获和模拟目标环境中所有相关系统的预期行为和反应时间。由于组件负载试验进行地比较早，团队可以在设计和开发生命周期的更早阶段优化系统资源的使用，找到内存泄漏并修复错误根源，而无需进入实用系统或测试环境所需要的所有相互依赖的组件。在解决方案交付之前，多个团队并行执行各自性能测试过程的能力能够给生产率和部署质量带来巨大的意外之喜。

在这个意义上说，行为服务虚拟化决不是为了节省IT运营的成本而虚拟化硬件和网络资源的一个替代方案。但它确实是一个减少依赖性和成本的极好的方案，虚拟化一组给定的服务器有时并不能达到这个效果---毕竟，处于云中的许多第三方和共享服务，或者巨型交易系统和合作伙伴系统不能被常规手段虚拟化。

资深分析师Michael Vizard在谈到虚拟化的作用时说，许多供应商都表示，将现有的网络和系统管理工具扩展到虚拟化领域已经成为关键因素。他们还争辩说，IT组织并不需要为了学习单独的物理和虚拟环境管理工具而进行投资，在一个环境中决策彼此之间的影响可能是毁灭性的，除非管理基础设施都是紧耦合的。

开发团队可以使用VSE对不完善的组件建模，捕捉实用服务，并在正在运行的服务器上模拟行为。VSE中托管的虚拟服务的运行机制与你连接到部署中的其它服务、数据库和系统是一样的，包括预期的反应和交易时间。不需要访问关键的实用系统，开发团队可以将自己的组件连接到VSE的虚拟架构的其它部分，并用自己选择的工具进行性能和负载测试。

五：IT和SOA治理

由于采用了灵活、螺旋状的并行开发方法，在很多敏捷性开发周期的收尾阶段，用传统的瀑布式开发方法测试接近完成的应用程序其实并不能达到敏捷的效果，因为应用程序的组成要素在不断变化。传统的IT治理模式也将无法发挥作用。

为了解决这一问题，人们采用了SOA（面向服务的架构）设计模式，努力让IT更加积极地对业务所需要的变化做出更加积极的响应。新的过程工具被引进，专门用来协助分类服务资产，并组织SOA治理策略。

这些为了支持SOA而特意开发的新工具主要围绕SOA治理平台，比如惠普公司的Systinet / s2、SAG Centrasite、SOA Software、TIBCO ActiveMatrix和Oracle Fusion。这些SOA治理工具管理与服务有关的元数据的收集和分类，并组织他们之间的相互依存关系，同时再根据SOA策略文档确定如何组合服务才能满足业务需求。

在治理工具集中，SOA Registry/Repositories自动化测试和验证的新平台。传统的系统需求和功能测试将仍然执行，但在SOA环境中，自动化策略验证和执行的机会将会更多。

目前关于SOA治理的思想基本上是围绕设计时WSDL验证、运行性能和安全政策的执行。随着SOA治理的逐渐成熟，它需要支持各种各样的SOA项目，而SOA治理思想也必须大幅度扩大。SOA治理平台最大的价值之一就是必须提供一个证明，确保用人类语言或商业条款所表述的策略能够在系统中连续执行。

验证SOA策略

让我们看看下面这个部署示例：比如，你要将一系列的Web服务定义（WSDL文件），加载到UDDI注册器中。这些服务彼此之间的关系，以及这些文件如何捆绑在在一起以创建一个业务流程会被记录下来。如果企业招聘了一位新员工，这就可能会设计到一系列的服务，从确定员工的职位和上司的人力资源计划，到提供IT必要的资源比如电脑和电子邮件，同时还可能涉及到外部合作伙伴的保险和福利登记。这些服务将通过WSDL记录下来并储存在UDDI注册器中。这样，一个从人力资源到薪水制定的业务流程将会被确定下来。

只要每一个业务流程参与者提供了有案可稽的，可靠并安全的服务，这一切看起来很简单。这些围绕单个服务架构、行为和性能的策略都被记录在治理工具中。举例来说，业务分析师将会在CentraSite ActiveSOA这样的工具中编写策略，描述服务的行为。

IT服务将会根据新雇员的姓名和身份证号码返回一个新的e-mail地址，域登录和默认密码。安全服务将会向这位新雇员提供合适的系统访问控制权限。安全负责人指出，只有加密和签名数据被发送给服务，该服务才能运行。签名必须由企业安全证书主管验证，证明该请求是来自经过授权的HR人员。最后，IT运营团队将会围绕该服务每秒应该处理多少交易以及服务的最大响应时间制定一个策略。

如果要进行一个严格的人工验证过程，要进行的步骤远远不止这些。测试的执行应该驻留在SOA治理过程之中。

测试，验证和政策执行解决方案

企业为了管理IT环境的设计、架构、集成和治理必须要部署很多过程，鉴于此，找到一种通用的并且可重用的过程验证和执行方法是非常有意义的。SOA验证执法范围大增，可重复使用并且丰富的测试融合到业务的每一个流程以及支持它们的工具中。

上图所示的验证法提供了通过运行测试案例来验证一流的IT过程工具定义的不同的规则和策略的功能。通过在过程工具的工作流中将自动化的测试运行与的预期的行为和政策捆绑在一起，治理行为得以实现。从治理平台援引测试以确保SOA策略这一做法与测试管理解决方案的治理方法很相似，最大的不同在于需要验证组件整个生命周期的背景和阶段。

在传统的瀑布式开发测试方法中，有一个具体的时间点，用来标志该系统可以用于测试了。在今天基于服务的应用程序中，我们不能找到这样一个时间点。

在SOA生命周期中，我们将设计时、运行时和变更时看做是松散耦合系统中正在建设的业务过程或服务的三个阶段。在上面的例子中，一些服务与套装应用软件（人力资源系统）是互动的，一些是本地系统，其余的则来自外部合作伙伴。这三个阶段的开发和发布周期会有所不同，并且不能通过协调融合成一个大型发布。SOA的一个优势是有能力实现系统分拆，并利用其它项目创建的服务，无需自己开发。

在设计时阶段，运行测试确保WSDL符合WS-I的标准，并遵循RPC或文档调用结构，而且客户的特定标记被用于服务标识。在通过了上述符合性测试的基础上， WSDL就会被放入Repository中，开发人员就可以使用它们进行功能编码。

六：结论

由于开发周期已经从传统的瀑布开发和测试转向了ALM支持的敏捷、螺旋、并行的开发模型，所以在应用的整个生命周期都需要不断进行测试已经是不言自明的。为了促进这些过程，并实现SOA的业务响应和成服务、主机和数据行为的虚拟化使开发和测试团队能够完成在现实环境中的所哟管理和测试工作，并且大大节省了成本。这大大增加了灵活性，将开发和测试团队移动到更多的并行开发周期中，消除了不能用于测试的服务和组件的限制。

这确实大大节省了成本，尤其是在目前全球经济持续低迷的条件下，它的重要性更加明显了。敏捷性SOA正在引起越来越多的企业的关注和兴趣。