建立SOA测试团队需考虑的几大问题

我们就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实施当中，架构师倾向于在自己的服务前利用许多代理服务。

原文转自：http://www.ltesting.net