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为测试带来的附加影响。理解存在的风险、评估你的内部技巧并明确技能空白，建立一个有经验的从业者网络，确认必要的工具和所需流程，确保资金提供包含了测试组织的需求。