在一个SOA环境中开发并保证功能是非常复杂的。系统的分布式性质和数据几乎使建立阶段性测试环境成为不可能。
SOA的设计部分通常都需要使用未完成的或不可获得的服务，通过仿效服务来提供压缩服务是比较理想化的方式。一个开发员或质量工程师应该仿效服务并在早期就演练业务情景以在早期阶段就确认问题所在，并判断服务的正确性、更好的预测性能。
流程敏捷性与速度
先进的平台可以保证一个提供速度与敏捷性的SOA基础设施以满足更加复杂的业务需求变化。但不幸的是，质量检测流程仍旧还停留在传统的连续程度。有效协作与积木式构建方式的质量解决方法会是针对SOA所带来的一系列复杂问题最为合适的方法。如果一个企业需要快速递增的可交付产品从而达到需要的敏捷性，那么仅仅通过这样传统的质量检测流程是绝对做不到的。
面对SOA环境下的新交付状况，在企业中必须完全改变这样的质量监测手法才能更好的受益于敏捷性变化所带来的好处。这样的话一个可重复，并以变化为基础的质量流程将会最大程度的体现SOA真正的敏捷性优势。在之前的测试过程中所使用到的测试方法在业务服务的演变过程将会得到有效的重用，从而提高敏捷性和速度反应。
此外，设置连续性的回归测试套件将会给刚刚所提到的敏捷性增加带来显著的效果。
以变化为基础的测试可以让团队更好的共同合作，改变版本控制，了解影响范围等，这样的测试以节约时间为重，并提供更快更准确的完善解决方案。
整合
如何让业务合作伙伴更有效的整合到一起仍旧是一个停留在“整合”层面的难题。无论是对于任何两个以上的业务流程而言都必须得做出取舍和让步。这意味着即便是基于标准的生产和消费服务都会有难以避免的麻烦所在。为了消除在整合过程中所出现的问题，业务合作伙伴需要获得一份关于服务的“健康报告”，一个类似于包含备份与数据测试的报告从而可以对服务的交互起到监测调控作用。这可以有效的防止错误在整个周期的最开始时期就被体现出来，而这也可以在服务资产回归测试中暴露并得到解决。
发展和发展前期的准备
在业务流程方面，架构师将必须做出选择，从而确保某项特定的服务资产会是所有资产中最优先的。当然，对于这项服务的选择决非毫无缘由。架构师在做出决定之前必须能够验证他们所选择的服务资产所能表现出来的性能。这使得开发人员以及质量测试人员可以通过其连续不断的回归测试手段所能实现的更新结果去对自己的业务情况和业务流程有一个清楚准确的认识。
结论
大家看到有大企业，两三年前还在讨论建立现代企业制度，还要从老三会变成新三会，差一百多天的时间。同时这些企业要构建最先进，与世界最同步的，甚至超过SOA的标准，这个对我们来说的确很严重，但是的确又是一个机会。但是在未来全球化当中没有一个企业是封闭的。考虑到整个SOA环境的复杂性，对于企业内部而言鲜明的角色和责任将会带来一个非常显著的影响。传统的应用测试方法将不能再确保任何有关于SOA的应用质量。在当前的SOA时代里，逻辑问题在信息层与跨系统之间表现的更为抽象，正是出于这样的原因才使得测试变得更加复杂，而质量保证方面不由得有所下降。虽然发展同质量评估之间的问题会一如既往的维持下去，各个环节的职能尤其是质量检测流程还是需要尽可能早的开始提升，从而在整个周期的最开始便能确保安全，可靠已经完全兼容的面向服务架构。
文章来源于领测软件测试网 https://www.ltesting.net/
