我们就SOA测试问题从三个不同的角度分别请教了三个人：培训师、厂商、从业者。Randy Rice是一位软件测试和软件质量领域的主要作家、发言人兼顾问。Randy的公司为SOA测试提供培训服务。Frank Cohen是一位作家也是一家开源软件测试公司Push2Test的创始人。Jim Giddings是一个SOA测试从业者，前任SOA路线捍卫者。过去几年中，他曾经从事许多SOA行动。

　　SOA为测试带来的最大改变是什么？

　　Randy说“无障碍服务”或“服务的无头特性”为测试员制造了新的挑战。测试人员将必须在没有用户界面帮助的情况下测试许多服务，还须要进行严格的测试来验证这些服务。Randy说测试服务让他想起了需要测试工具和测试框架的测试驱动器面临的挑战。

　　Frank谈到了服务是如何的“随时可获取”，这与“你受控其中”的多层架构是不同的。有了SOA，你就能在Mashups的世界中用服务召集其它的服务，测试人员在实行部署之前了解这些服务将如何使用。Frank列出的挑战中还包括了测量和性能。

　　Jim说你应该事先预料到频繁的测试周期就像敏捷项目一样，我们应该采取测试驱动开发的方法。Jim表示测试治理对于SOA来说已经是至关重要了。就像他的同行一样，Jim也讨论了服务的无头特性和性能测试的挑战。

　　你看到对于测试人员理解SOA所需的技术技巧提出的挑战了吗？

　　Randy强调了强大的技术知识的重要性。他说测试人员来自企业不同部分(业务、开发等等)，他们并不一定具有SOA所需的合适的技能。他也强调更大程度的面向业务需求的重要性，并将之称为“测试遗忘的区域”。只专注于技术的测试员会忽略业务流程方面的因素。非业务头脑测试员往往没有适当水平的与业务人员联系。

　　Frank指出测试员已经开始进行编码，而编码人员也开始从事测试工作了。测试驱动开发引起了这样的角色和责任的转变。如果你的测试员不能够编码，那么这将成为一种挑战。Frank提出的另外一点就是对于非SOA的通用记录和回录方法以及框架的需求。测试员必需要学习如何用框架工作，这或许就需要脚本和编码。测试人员还必须要理解支持状态（statefullness）的概念。

　　Jim提到许多测试员认为SOA等同于Web服务，而且对于架构范畴的理解也并不完整。并非所有的测试员都具备足够的技术水平来“深入到架构中去”。SOA需要的不仅仅是黑匣子测试。Jim说SOA需要黑、白、灰匣子相结合的测试，因为在架构的每一层有太多的内容。

　　测试SOA的关键工具是甚么（如果有的话）？

　　Randy谈到允许测试配置的工具，还提到了SoapUI和ITKO的Lisa产品，这两个测试工具的设计目的是为给予测试员服务结构获得途径。他说现有的工具是能够扩展的，但却达不到有效测试SOA的水平。

　　Frank表示SOA测试工具应该让你重新目的化。例如：工具应该允许测试人员使用开发人员的测试配置并通过功能测试将之扩展。Frank的公司建立了Testmaker Pro，一个开源工具为测试人员在无需学习像Groovy或Jython一样的新语言情况下提供重新目的化的框架。

　　Jim强调性能测试工具的重要性，还推荐一个像ITKO的Lisa一样的工具来跟踪代理服务和动态探测呼叫服务的路径。在一些SOA实施当中，架构师倾向于在自己的服务前利用许多代理服务。

　　SOA为测试和部署带来了哪些额外的风险？

　　Randy毫不犹豫的就性能处罚和成本问题提出警告。服务是从运行时间的不同地方进行确立的。这就制造了测试人员事先不可知的整合点。另外一个风险就是组织也许对SOA的理解不够充分，也不了解成功实施SOA的条件有哪些。这将导致资金不足，没有提出人才问题、忽略组织面临的挑战以及其他许多平常的错误。Randy强调公司第一次的SOA经验是一次学习经验。我建议公司寻求外部帮助以将许多需要的经验带入项目。

　　Frank表示“SOA是一种方法论而非标准”。SOA仍然处于演化阶段，而缺少标准将带来各种各样的问题。Frank给出的一个例子就是目前存在有至少33种XML剖析器，每一个都有自己的性能列表。SOA架构师可能会将某一个XML剖析器定为标准，即使这个剖析器可能并不适用一定的应用案例

　　Jim指出快速的转变将是SOA中的一大风险。我在过去提到过SOA将为业务带来简化、灵活性和敏捷度，但同时也会为IT带来复杂性、多重故障点和管理问题。在SOA的承诺之下是一个需要进行恰当管理的危险世界。Jim提到当软件在QA环境中部署的时候，整合特定侧面组件将引起风险。开发人员倾向于层次特异，但在单元测试中看起来好的东西并不一定在QA中运转顺畅。Jim说这就像标准的冒烟测试（smoke test）对于SOA来说完全是一个衰退测试一样。

　　对于第一次处理SOA的测试人员来说最大的挑战是什么？

　　Randy：通常来说，测试员并不能看到总体战略。一些企业存在的另外一个问题就是测试员需要争取所需工具。他们可能会在获取有效测试SOA所需的额外工具上受到挑战。

　　Frank重申了他的观点：现在还不存在针对处理SOA的“标准个体”或“从此开始”的指导。事实上，人们就SOA是甚么这个问题还存在激烈的讨论。由于这些问题，许多培训资料和工具都还达不到标准。

　　Jim曾经见证过测试员在分层为基础的测试方法概念上的挣扎。这样的情况发生的时候，测试员往往倾向于采用他们能感到满意和舒适的测试实践，但是这些测试可能对于端对端测试服务来说是不够的。

　　对于第一次从事SOA倡议的测试总监/经理你有什么建议？

　　Randy建议“开发一个4-5人的网络，这些人需要具有1到2年的SOA经验”。参加会议、阅读书籍能帮助你得到一些基础知识，但你也能够从那些已经在SOA战场上有过一手经验的从业者身上得到现实世界的学习和建议。

　　Frank建议评估测试团队的技能和能力。“你的团队具有相应的实力吗？” 你能否利用内部资源处理，还是说需要部分外部资源？ Frank强烈的感到你需要“具有正确特质的人”，包括知道如何迅速修补一个应用程序“了解所有界面”的测试工程师以及一个能够“由需求到测试结果”的管理者。

　　Jim的建议是“考虑持续的转变（比如敏捷度）”。他还高度推荐从一个强大的释放管理流程开始。从经验来看，如果不采取这条建议的话你将浪费无数的时间和金钱。Jim还建议SOA测试架构师并不是很多，如果你不能找到一个合适的，那么可以雇用一个具有Web服务经验的架构师作为代替。

　　小结

　　处于SOA早期阶段的企业或是企图发起SOA的企业不要忘记考虑SOA为测试带来的附加影响。理解存在的风险、评估你的内部技巧并明确技能空白，建立一个有经验的从业者网络，确认必要的工具和所需流程，确保资金提供包含了测试组织的需求。