这种流行的趋势其实是若干因素共同促进的结果。一方面，历经多年软件工程发展所积累的经验、方法和各种架构模式，比如 OO/MDD/MDA，需要新的想法来促进更加快捷的工程组织模式，以应对飞速发展变化的商业模式;另一方面，互联网的多年发展带来了前所未有的分布式系统的交互能力，这成为了实施进一步标准化需求的基础。
图 2. 复杂的 SOA 系统
SOA 架构提高了企业对系统的复用程度，以一种松耦合的方式将不同的系统联系到一起，用户会以 PC 联入系统，也可能以移动设备(如智能手机或 Pad)联入系统，这类系统的特性在于：
系统间基于"消息"进行通信。消息格式复杂多样，包括 HTTP、XML、SOAP、File、JSON、REST、二进制、JMS、Base64 等。针对特定的行业还会有 HL7、FIX、SWIFT 等。
体系结构复杂，采用多种技术。如 Web Service、FTP、SCA、SDO、BPEL、ESB、BPM、消息中间件等。
系统间依赖关系复杂，接口众多，难以关联和调试。
传统意义上，测试人员通常会基于开发好的 PC 用户界面做功能测试和性能测试，并使用自动化测试工具进行相应的自动化测试。但是许多项目组发现，针对 SOA 开发使他们比较头疼的是集成测试，因为在集成测试时候会出现大量缺陷。为什么会有这种情况 我们来看一下 SOA 系统集成测试带来的新问题。
集成测试的困惑
集成测试，也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求组装成子系统或系统，进行集成测试。实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。而针对 SOA 和分布式复杂应用系统的集成测试，往往会碰到如下的一些困惑：
无图形用户界面
与传统的基于 GUI 的测试方式不同，SOA 类系统的测试主要是围绕着系统底层各个组件和模块之间的接口来进行的，通过消息的 Schema 来判定接口之间的通信是否正确。这些接口通常没有图形用户界面，无法采用传统的基于图形用户界面的录制方式来进行测试。
消息格式复杂，缺乏统一的测试手段
如图一所述，分布式复杂应用系统的各个模块之间通信和消息格式复杂多样，常见的包括 HTTP、XML、SOAP、File、JSON、REST、二进制、JMS、Base64 等。这就要求测试人员必须要熟悉系统中每一种消息的格式和测试方法，必须针对每一种消息构建独立的测试脚本。这将导致测试工作复杂，难以以统一的方式有效的执行和管理。
单元测试和集成测试的“鸿沟”
我们前面提到，项目组在集成测试时感到头疼，在做分布式复杂应用系统的测试过程中，往往会碰到这样的问题：各个子系统和模块在独立开发和单元测试阶段都进行的十分顺利，软件的质量也不错。一旦进行到集成测试阶段，由于各个模块和组件之间的消息契约十分复杂，依赖关系众多，系统与系统之间在做联调测试的时候容易出现各种各样的问题，导致集成之后的软件系统质量底下，运行期间持续暴露各种各样的缺陷。
图 3. 到了集成测试阶段，质量突然下降
图三中，我们看到软件质量在"Big Bang"后有个下降期，这是因为在单元测试阶段没有考虑集成测试的问题。举个例子，组件 A 依赖组件 B 和 C，组件 ABC 分别由不同的小组开发，每个小组都会进行单位测试，保证自己小组开发的组件没有问题。但当某一时刻，组件 ABC 都开发好后一集成，问题就出来了。这是我们所说的单元测试和集成测试的"鸿沟"，如果将集成测试介入到单元测试中，出现问题的几率就会大大降低。
测试环境构建费时费力，难以平衡质量和进度
分布式复杂应用系统采用技术种类众多，包含各种类型的操作系统、中间件、数据库、通信协议等等。为了测试一个端到端的业务场景，往往需要耗费大量的人力、物力和时间来重复搭建测试环境(如应用服务器配置、测试数据准备、消息队列初始化等)，并且十分容易出错。据统计，测试环境搭建平均耗费掉测试周期 30% 到 50% 的时间。
另外，有时需要定制和额外的软件支撑来满足种种约束(例如，第三方软件可用性，安全，等等)，可能仍然不足以反映目标运行环境 , 或者针对特定条件的测试 ( 第三方组件新的版本等等 )。为满足业务目标，系统所需要的开发和测试频率，由于测试环节低下的生产率和覆盖率而被大大地限制了。更长的测试周期增加了应用交付的风险，系统的质量也难易得到保证。
后台性能瓶颈难捕获
对传统的应用系统做性能测试时，通常的做法是采用性能测试工具通过录制用户界面操作生成测试脚本的方式来进行。但分布式复杂系统的性能瓶颈往往不在 Web 前端界面，界面上一个简单的操作往往对应着后台大量的子系统、模块接口的消息调用，任何一个接口的消息处理性能瓶颈都会影响到整体系统的性能。此外，通过传统基于界面操作录制的方式也无法灵活地模拟多个接口直接的串联和并发调用的场景。而且，传统的性能测试工具，如 Load runner, RPT 等，录制的是第一层客户端(经常是浏览器)发送给第一个服务器(经常是 web 服务器 ) 的请求，而服务器发送给后台的请求是捕获不到的，而后台的服务器设置往往是性能优化的关键。
移动终端应用为测试带来的挑战
从目前软件开发来看，越来越多的企业认识到其业务应用的用户已开始从个人计算机 ( 如台式机和笔记本电脑 ) 转向移动设备 ( 如智能手机和平板电脑 ) 来访问 Internet 并获取所需的信息。用户使用移动设备作为访问 Internet 获取信息和请求服务的主要途径，因为无论去哪里人们都能随身携带移动设备，并且移动设备更加直观易用。这种用户行为的重大转变促使企业为现有的应用开发移动版本，随着移动应用市场的成熟，相应的移动软件开发测试问题呈现到人们的视野之中。