引言

　　就在不久之前，工业标准测试实践(针对 C/S 架构的质量问题而发展起来的)仍聚焦于客户端的前端功能测试或者服务器端的后端可伸缩性测试与性能测试。这种"工作上的分离"主要是缘于传统的 C/S(客户端/服务器)架构比当前的多层架构和分布式环境相对简单的事实。在标准的 C/S 架构中，问题要么发生在客户端，要么就发生在服务器端。

　　今天，典型的计算环境是一种复杂的，异构的混合环境，其组件和代码来自遗留系统、自主开发或第三方，或者是标准的组件和代码(图示 1)。随着 Web 的发展，架构的复杂性进一步增加，通常在一个或多个后端数据库与面向用户的表示层之间会有一个内容层。该内容层可以提供来自多个服务的内容(其中这些服务集中在表示层中)，也可能包含一些原来存在于传统 C/S 架构前端上的业务逻辑。

　　这种复杂度的增加，与遗留系统集成和尖端技术开发交织起来，使软件及系统问题(包括功能和可扩展性及性能问题)的描述、分析和定位成为软件系统开发和发布过程中的主要挑战。此外，随着 SOAP/XML(简单对象访问协议/可扩展性标记语言)成为标准的数据传输格式，XML 数据内容的问题对于 .NET 平台和 J2EE 平台变得越来越重要。简单的说，正是现在的架构和计算环境的复杂性，导致了原来的面向 C/S 的测试模式遭到淘汰。

　　图1：现在典型的多层架构

　　总体质量策略

　　很显然，一种新的，有效的质量强化策略对成功的软件开发和部署是必须的。最有效的策略是将环境中单个组件的测试和环境的整体测试结合起来。在这种策略中，组件级和系统级的测试都必须包含功能测试来确保数据完整性，还要包含可伸缩性和性能测试来确保不同的系统负荷下的可接受的响应时间。 在评估性能和可伸缩性方面，这些并行分析模式能够帮助您发现系统架构的优势和缺陷，并在解决与性能和可伸缩性有关的问题时确定必须检查哪些组件。与此类似的功能测试策略(即全部数据完整性验证)，正显得越来越关键，因为现在数据可能是从分散的数据源派生而来。通过评估组件内外的数据完整性(包括处理过程中的任何功能性的数据转换)，测试人员可以定位每个潜在的错误，并使系统集成和缺陷隔离成为标准的开发过程的一部分。端到端架构测试(End to End Architecture Testing)指的是这样一种概念，它测试计算环境中所有的访问点，并在组件级和系统级的测试中将功能测试和性能测试整合在一起(见图2)。

　　从某种意义上来说，端到端架构测试实质上是一种"灰盒"测试，一种集合了白盒测试和黑盒测试的长处的测试方法。在白盒测试中，测试员能够访问底层系统组件并对其有足够的了解。尽管白盒测试能够提供非常详细和有价值的结果，但在检测集成和系统性能问题方面却有些"力不从心"。与此相反，黑盒测试需要很少或者完全不需要对系统的内部工作机制的了解，而将注意力集中在终端用户上――确保用户能够及时得到正确的结果。黑盒测试通常并不能指明问题的原因，也不能保证某段代码已经被执行并且高效运行，而且也不包含任何内存泄漏和类似的问题。通过将白盒测试与黑盒测试进行"技术嫁接"，

端到端架构测试真正实现了取长补短。
 

　　图2：端到端架构测试包含所有访问点的功能测试及性能测试

　　对可伸缩性测试和性能测试来说，访问点包括硬件、操作系统、应用程序数据库和网络。对功能测试来说，访问点包括前端的客户端，中间层，内容源和后台数据库。明白了这些，术语"架构"所定义的就是在环境中组件之间以及组件与用户之间是如何进行交互的。单纯从组件来看的优点和缺陷取决于将它们组织在一起的特定架构。正是一种架构将如何响应作用于它的命令的这种不确定性，使我们需要进行端到端架构测试。

　　为了有效实现端到端架构测试，RTTS 成功开发了基于风险的测试自动化方法。The Test Automation Process(测试自动化过程，TAP)建立在多年的成功测试实践基础之上，利用了最佳的自动测试工具。这是一个迭代的测试方法，包括五个阶段：

　　项目评估

　　测试计划创建和改进

　　测试用例编写

　　测试自动化、执行和跟踪

　　测试结果评估

　　端到端架构测试所要求的单项功能和性能测试是在"测试自动化、执行和跟踪"阶段进行的。如图 3所示，这个阶段被不断重复，而相应的测试也在每一次迭代过程中得到精化。
 

　　图 3：端到端测试的 RTTS 测试自动化过程(TAP)