Rami Jaamour：我想我们需要在头脑里保持以下这些意识：

　　1) 不同于传统的应用(web开发，富客户端应用)，你正在构建和测试的services没有直接的用户界面，所以你需要把它组合到一个界面中，让你能够和这些services轻松地进行交互(例如提供数据，构建信息等等)。

　　2) 类似于传统的应用，有些是要求你的services符合的功能性的要求，例如正确执行那些要求和正确实行你的用例场景，但也有一些非功能性质的要求：

　　1.符合标准(W3C，OASIS， WS-I等等)，以便当你维护供应商的独立性和避免专有插件的同时可以成功地随时重用和访问那些services。
　　2.遵循政策，其中包括标准以及设计和运行时的政策，还有的政策是确保services内部一致性，使能够重用和加强信任，以便随着你的SOA的发展你能够真正重用services，并使他们的质量状况具有充分的可见性(像信用报告)。
　　3)在SOA中的功能和性能的考虑需要更多的关注和与传统的应用不同的方式，因为一旦你围绕你的SOA中的services构建业务流程，你的services可能会以不易预测的方式被访问和消耗，这是因为它们使用的范围不再受具体流程和约束于一个所谓的具体web应用的场景的控制，所以你需要注意负面测试，并确保在突发状况(例如不良数据，数据丢失等等)下services功能是可靠的。

　　4)安全。永远不要忘记安全考虑：内部外部都要考虑，即使你的services只是内部的。需要避免一些专门针对XML的攻击，还有传统安全考虑，像要阻止对SQL的注入攻击。

　　从流程角度看，一个连续的测试过程需要建立在你可以孤立的系统部分上(有时你需要清除或仿真来实现)，并不断地(自动)对它进行回归测试。这有一些关键信息：

　　1)把你的资源放进来构建测试，而不执行测试。这个执行应该是自动的。每当你发现自己在花费时间做测试(发布XML信息并分析)，那么，你是在做错误的事情。

　　2)维护你的回归组件和你创建的测试，这是非常有价值的资源，因为一旦你需要做一新版本的services，这些测试资源会非常有用，所以你可以运行并确保从一个版本到另一个版本没有什么损坏。

　　3)有一个基础结构来分享这些测试资源也是很关键的，这样不同的组、QA和开发人员等等可以访问、改进和重用那些其他人创建的测试。这是web services被不同的团队重用和消耗的必然结果。