引言
就在不久之前，工业标准测试实践（针对 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）
组件级测试
很显然，首先必须开发单个组件，然后才能将它们"装配"成功能系统。因为组件可以进行早期测试，所以在 TAP 中端到端测试是从组件测试开始的。在组件测试中，随着环境的建立，适当的测试也分别实施于各个不同的单个组件上。功能测试和性能测试在组件测试阶段都相当有价值，它们帮助诊断了在整个环境构建前和构建中的各种缺陷。
组件测试中的功能测试
组件级功能测试验证了每个组件所执行的事务。这包括了组件或系统所要求的任何数据转换和组件所处理的事务的业务逻辑的验证。在应用程序功能的开发中，基础设施测试（infrastructure testing）验证并量化整个环境中的数据流量，并以这种方式来同时进行功能和性能测试。数据完整性必须当数据在组件间传递时进行验证。例如，XML 测试在逐个事务地验证 XML 数据内容，并在需要时验证正式 XML 结构（元数据结构）。对组件测试来说，诸如 IBM Rational Robot 这样的自动可扩展的测试工具可以大大的减少用在 GUI 测试和非GUI组件的功能测试上的时间和精力。Rational Robot 的脚本语言支持对外部 COM DDLs 的调用，是非 GUI 对象测试的理想工具。此外，Rational Suite TestStudio 和 Rational Team Test 所附带的新的 Web 和 Java 测试功能，提供了测试 J2EE 架构和使用 java 语言来编写测试脚本的附加功能。
组件级可伸缩性测试和性能测试
与这些功能测试并行的是组件级可伸缩性测试，在环境中检验每个组件来确定其事务（或者说容量）的限度。一旦有足够的应用功能来创建业务相关的事务，事务特征测试（transcation characterization testing）就被用来确定业务事务中的各个定量描述，包括消耗的带宽和后台 CPU 以及内存的占用率。资源测试（Resource testing）将这个概念扩展到多用户测试，从而确定应用程序和子系统或模块中全部的资源消耗。最后，配置测试（configuration testing）可以用来确定哪些硬件、操作系统、软件、网络、数据库或者其他配置上的变更可以优化性能。与功能测试一样，有效的自动工具如 Rational Suite TestStudio 和 Rational Team Test 所提供的那些工具可以极大地简化可伸缩性测试和性能测试。在这种情况下，创建、计划和驱动多用户测试以及监控资源利用率的能力是有效且成功完成资源测试、事务特征测试和配置测试的基础。
系统级测试
系统 "装配"完成后，对环境的整体测试就可以开始了。同样，端到端架构测试需要对整个环境的功能以及性能/可伸缩性进行验证。
系统级功能测试
集成是首要考虑的问题之一。集成测试 ( Integration Testing ) 从数据的角度检查了整体系统是否完成了集成。也就是说，需要互相交互的硬件或软件组件是否通讯正常？如果是，那么，在它们间传递的数据是否正确呢？如果可以，数据应当在系统组件传送的中间阶段被访问和验证。例如，当数据被写到临时数据库中时，或者数据在被目标组件处理之前已经存在于消息队列中时，就应该对数据进行验证。在这些组件边界对数据进行访问能够为数据完整性验证和数据问题的描述提供一个重要的附加尺度。如果在两个数据传输点之间检测出数据错误，那么有缺陷的组件必定是位于这两个传输点之间。
系统级可伸缩性测试和性能测试
可以通过创建一个测试来回答以下关于环境的可伸缩性或者完成情况的问题：在系统仍能维持可以接受的响应时间下，最多可以有多少用户同时访问它？
这些问题的答案可以通过一定的测试技术来获得, 包括可伸缩性/负载测试、性能测试、配置测试、并发测试、压力和容量测试、可靠性测试，以及失败转移（failover）测试。
在系统容量方面，总体环境测试通常是从可伸缩性/负载测试开始的。这种测试方法逐渐增大目标环境上的负载，直到某些性能要求如最大响应时间达到极限或者特定的资源被耗尽。这些测试的目的在于确定事务处理和用户容量的上限，它们经常会和其他测试手段结合起来以优化系统性能。
性能测试与可伸缩性/负载测试相关，它通过测试特定的业务场景来确定环境是否满足所设定的负载和事务组合的要求。（图 4）
与组件级配置测试并行的是系统级配置测试，它提供了特定的硬件和软件设置下的权衡信息，同时也提供了有效的资源分配所需的度量标准和其他信息。
图 4：性能测试：系统具有特定的用户负载时能够按照要求执行吗？
并发测试（concurrency testing）（图 5）剖析了当多个用户同时访问同一段应用代码、同一个模块或者数据库纪录时的效果。它鉴别并度量了系统加锁和死锁的级别以及系统中单线程代码和加锁信号的使用。从技术角度讲，并发测试可以归为一种功能测试，不过它常常和可伸缩性/负载测试配合使用，因为它需要多用个户或者虚拟用户来驱动系统。
图 5：并发测试能够识别死锁和其他并发访问问题
压力测试（stress testing）（图 6）在系统达到饱和（指资源如 CPU、内存耗尽等情况）时来测试系统以判断其行为是否发生变更，或者是否会对系统、应用程序和数据产生不利影响。容量测试（volume testing）是和压力测试及可伸缩性测试相关联的，它可以确定整个系统能够处理的事务容量。通过压力和容量测试能够知道系统分别在处理突发的访问量增加或进行持续的大容量活动时所具有的弹性，这不包括那些因为内存泄漏或者队列溢出所引发的失败。
图 6：压力测试能够确定高容量使用时的效应
一旦应用环境开始工作并进行了性能优化，可以在 75％到 90％的环境利用率下进行一项长期可靠性测试（reliability testing），用来发现任何与较长的运行时间有关的问题。在应用了冗余和负载平衡的环境中，失败转移测试（failover testing）（图 7）分析理论上的失败过程并测试和测量总体失败转移进程及其对终端用户的影响。本质上，失败转移测试回答了这样一个问题："如果一个特定的组件运行失败，用户还可不可以在最小的中断下继续进行访问和处理？"
图 7：失败转移测试：如果组件X失败，那么将发生什么情况呢？
最后，如果在环境中使用了第三方软件，或者主机供应商及其他外部来源所提供的组件，那么 SLA（Service level Agreement服务水平协议）测试则可以用来确保双方合同规范中所规定的终端用户响应时间，以及流入和流出的数据量。一个典型的协议通常会指明在既定时间范围内的活动容量和一个特定的最长响应时间。
一旦外部数据或软件到位后，对这些来源进行持续监控是明智的做法，这样就可以在问题发生时快速的采取补救措施，将对终端用户的影响降到最小。
与组件级的可伸缩性测试一样，Rational suite TestStudio、Rational TeamTest 和其他类似的工具提供了一些高级的，多用户的测试能力，它们可以用来高效进行上述的大多数或者全部的可伸缩性和性能测试。
一个实际例子
也许举一个例子是说明的最好办法。请考虑下面的情况：
通过 eRetailer 构建一个公共的 Web 书店，并在它的内容层中使用了四种由内容提供的 Web 服务。第一种服务提供目录，包括书名，介绍语和作者。第二种服务提供所有产品的当前库存信息。第三种是价格服务器，它提供商品定价信息，并根据购买者的所在地提供运费和税费信息并完成交易。最后一种服务用来保存用户档案和历史购买纪录。
表示层将用户通过 UI 图形界面输入的请求转换成 XML 并发送给相应的内容服务器。接着响应 XML 就会通过表示层转换成 HTML 并服务于用户会话。每一种内容层的服务都会根据需要更新其他的服务。（参见图 8）例如，在用户的历史购买纪录发生变更时，价格服务器必须更新相应的用户档案服务。
图8：典型的 eRetailer 应用程序的访问点
对上述的系统来说，一个端到端测试策略的起点是分别对内容层的每种服务同时应用功能测试和可伸缩性/负载测试。XML 请求被提交给每种内容服务，而相应的响应 XML 文档则被捕获，从而对它的数据内容或者响应时间进行评估。随着这些内容服务逐个的集成到系统中，通过向 Web 服务器提交事务，功能测试和可伸缩性/负载测试也都可以在集成系统中进行。事务可以贯穿整个站点进行验证，不论是为功能测试（使用 SQL 查询）还是为可伸缩性/负载测试。
在系统开发过程中，应用于所有访问点的单个测试可以被用来调协各个服务，以便使其能够在整个系统中正常运作――无论从数据内容（功能性）还是性能方面（可伸缩性）来说。当前端发现问题时（比如,通过浏览器），那些原来用来测试单个组件的测试用例和数据可以帮助我们快速定位错误位置。
网络建模的优点
作为设计过程的一部分，无论在硬件获取之前还是在最初的测试阶段中，为不同的网络架构进行建模都可以扩大端到端测试的优点。因为它可以帮助设计更有效和低错误率的网络。在部署之前进行网络基础设施的建模可以帮助指出性能的瓶颈所在，以及路由表和配置中的错误。此外，在测试中获取的应用程序事务物证可以输入到这种模型中，用来识别和分离应用程序的"chattiness" 和基础设施中的潜在问题。
结束语
端到端测试从一个概括的质量角度对计算环境进行测试和分析。每一个组件的可伸缩性和功能性在开发阶段和前期的质量评估中都进行了单个测试和集成测试。这为开发的有效性提供了诊断信息，同时为系统的发布提供了高度的质量保证。端到端测试为管理当今架构和分布式计算环境的复杂性提供了一个全面而可靠的解决方案。
当然，在需要做大量的测试和分析时，端到端测试要求有相当的专业技术和经验来组织、管理和实践。但是从商业角度来说，那些应用端到端测试的组织能够得到应用软件、系统性能和可靠性上的高度保证。最终，这些组织将获得质量的提高所带来得种种好处：更好的顾客关系，较低的运营成本和巨大的收入增长。
在过去的六年中，RTTS 作为 IBM Rational 的伙伴之一，开发并完善了自己的端到端测试方法，并与数以百计的客户一起努力确保了应用的功能性、可靠性、可伸缩性和网络性能。欢迎访问 RTTS 的网站：www.rttsweb.com。.
参考资料
您可以参阅本文在 developerWorks 全球站点上的 英文原文。
Johanthan Harris，RTTS，可伸缩性测试部门经理
Bill Hayduk，RTTS，专业服务部门主管
本文地址：http://com.8s8s.com/it/it23784.htm