组件级可伸缩性测试和性能测试
与这些功能测试并行的是组件级可伸缩性测试，在环境中检验每个组件来确定其事务（或者说容量）的限度。一旦有足够的应用功能来创建业务相关的事务，事务特征测试（transcation characterization testing）就被用来确定业务事务中的各个定量描述，包括消耗的带宽和后台 CPU 以及内存的占用率。资源测试（Resource testing）将这个概念扩展到多用户测试，从而确定应用程序和子系统或模块中全部的资源消耗。最后，配置测试（configuration testing）可以用来确定哪些硬件、操作系统、软件、网络、数据库或者其他配置上的变更可以优化性能。与功能测试一样，有效的自动工具如 Rational Suite TestStudio 和 Rational Team Test 所提供的那些工具可以极大地简化可伸缩性测试和性能测试。在这种情况下，创建、计划和驱动多用户测试以及监控资源利用率的能力是有效且成功完成资源测试、事务特征测试和配置测试的基础。
系统级测试
系统 "装配"完成后，对环境的整体测试就可以开始了。同样，端到端架构测试需要对整个环境的功能以及性能/可伸缩性进行验证。
系统级功能测试
集成是首要考虑的问题之一。集成测试 ( Integration Testing ) 从数据的角度检查了整体系统是否完成了集成。也就是说，需要互相交互的硬件或软件组件是否通讯正常？如果是，那么，在它们间传递的数据是否正确呢？如果可以，数据应当在系统组件传送的中间阶段被访问和验证。例如，当数据被写到临时数据库中时，或者数据在被目标组件处理之前已经存在于消息队列中时，就应该对数据进行验证。在这些组件边界对数据进行访问能够为数据完整性验证和数据问题的描述提供一个重要的附加尺度。如果在两个数据传输点之间检测出数据错误，那么有缺陷的组件必定是位于这两个传输点之间。
系统级可伸缩性测试和性能测试
可以通过创建一个测试来回答以下关于环境的可伸缩性或者完成情况的问题：在系统仍能维持可以接受的响应时间下，最多可以有多少用户同时访问它？
我的高可用性架构是否可以按照设计的那样工作？
在加入新的应用程序或者对正在使用的应用进行更新后会发生什么情况？
最初使用时，系统应该如何配置以支持我们所期望的用户数？6个月之后该如何配置呢？一年之后呢？
我们只能得到部分功能－－设计是否合理？
这些问题的答案可以通过一定的测试技术来获得, 包括可伸缩性/负载测试、性能测试、配置测试、并发测试、压力和容量测试、可靠性测试，以及失败转移（failover）测试。
在系统容量方面，总体环境测试通常是从可伸缩性/负载测试开始的。这种测试方法逐渐增大目标环境上的负载，直到某些性能要求如最大响应时间达到极限或者特定的资源被耗尽。这些测试的目的在于确定事务处理和用户容量的上限，它们经常会和其他测试手段结合起来以优化系统性能。
性能测试与可伸缩性/负载测试相关，它通过测试特定的业务场景来确定环境是否满足所设定的负载和事务组合的要求。（图 4）
与组件级配置测试并行的是系统级配置测试，它提供了特定的硬件和软件设置下的权衡信息，同时也提供了有效的资源分配所需的度量标准和其他信息。
图 4：性能测试：系统具有特定的用户负载时能够按照要求执行吗？
文章来源于领测软件测试网 https://www.ltesting.net/
