组件级测试

　　很显然，首先必须开发单个组件，然后才能将它们"装配"成功能系统。因为组件可以进行早期测试，所以在 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 ) 从数据的角度检查了整体系统是否完成了集成。也就是说，需要互相交互的硬件或软件组件是否通讯正常?如果是，那么，在它们间传递的数据是否正确呢?如果可以，数据应当在系统组件传送的中间阶段被访问和验证。例如，当数据被写到临时数据库中时，或者数据在被目标组件处理之前已经存在于消息队列中时，就应该对数据进行验证。在这些组件边界对数据进行访问能够为数据完整性验证和数据问题的描述提供一个重要的附加尺度。如果在两个数据传输点之间检测出数据错误，那么有缺陷的组件必定是位于这两个传输点之间。 系统级可伸缩性测试和性能测试

　　可以通过创建一个测试来回答以下关于环境的可伸缩性或者完成情况的问题：

　　在系统仍能维持可以接受的响应时间下，最多可以有多少用户同时访问它?

　　我的高可用性架构是否可以按照设计的那样工作?

　　在加入新的应用程序或者对正在使用的应用进行更新后会发生什么情况?

　　最初使用时，系统应该如何配置以支持我们所期望的用户数?6个月之后该如何配置呢?一年之后呢?

　　我们只能得到部分功能--设计是否合理?

　　这些问题的答案可以通过一定的测试技术来获得, 包括可伸缩性/负载测试、性能测试、配置测试、并发测试、压力和容量测试、可靠性测试，以及失败转移(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 和其他类似的工具提供了一些高级的，多用户的测试能力，它们可以用来高效进行上述的大多数或者全部的可伸缩性和性能测试。