第1部分，性能测试简介

Web应用程序性能测试指南

J.D.Meier、Carlos Farre、Prashant Bansode、Scott Barber和Dennis Rea

微软公司

2007年9月

目标

了解什么是性能测试。

学习性能测试的核心活动。

了解为什么性能测试很重要。

了解项目上下文与性能测试的相关性。

了解调优如何适应性能测试周期。

概述

性能测试是一种旨在确定给定工作负载下系统的响应性、吞吐量、可靠性或可伸缩性的测试。性能测试通常用于完成以下任务：

评估生产准备情况

根据绩效标准进行评估

比较多个系统或系统配置的性能特征

找出性能问题的根源

支持系统调整

查找吞吐量级别

本章提供了一组基本的构建块，在此基础上，您可以了解性能测试原则，最终获得成功的性能测试项目。此外，本章还介绍了本指南中使用的各种术语和概念。

如何使用本章？

使用本章了解性能测试的目的以及它所涉及的核心活动。要充分利用本章内容：

使用“项目上下文”部分了解如何在性能测试期间关注相关项。

使用“性能测试和调优之间的关系”部分了解性能测试和性能调优之间的关系，并了解整个性能调优过程。

使用“性能、负载和压力测试”部分了解各种类型的性能测试。

使用“基线”和“基准”部分了解各种性能比较方法，您可以使用这些方法来评估应用程序。

使用“术语”部分了解性能测试的通用术语，这将有助于在项目上下文中正确地表达术语。

性能测试的核心活动

性能测试通常是为了帮助识别系统中的瓶颈，为将来的测试建立基线，支持性能调整工作，确定对性能目标和需求的符合性，和收集其他与性能相关的数据，以帮助利益相关者做出与总体质量相关的明智决策。此外，性能测试和分析的结果可以帮助您估计在“上线”到生产操作时支持应用程序所需的硬件配置。

图1.1**核心性能测试活动

本指南中使用的性能测试方法包括以下活动：

活动1。识别测试环境。确定物理测试环境和生产环境，以及测试团队可用的工具和资源。物理环境包括硬件、软件和网络配置。从一开始就对整个测试环境有一个透彻的了解，可以使测试设计和规划更加高效，并帮助您在项目的早期识别测试挑战。在某些情况下，必须在项目的整个生命周期中定期重新访问此过程。

活动2。确定性能验收标准。确定响应时间、吞吐量和资源利用目标和约束。一般来说，响应时间是用户关注的问题，吞吐量是业务关注的问题，资源利用是系统关注的问题。此外，确定那些目标和约束可能无法捕获的项目成功标准；例如，使用性能测试来评估哪些配置设置组合将导致最理想的性能特征。

活动3。计划和设计测试。确定关键场景，确定代表用户之间的可变性，以及如何模拟可变性，定义测试数据，以及建立要收集的度量标准。将这些信息合并到一个或多个要实现、执行和分析的系统使用模型中。

活动4。配置测试环境。准备测试环境、工具和执行每个策略所需的资源，因为特性和组件可用于测试。确保在必要时对测试环境进行资源监控。

活动5。实施测试设计。根据测试设计进行性能测试。

活动6。执行测试。运行并监视测试。验证测试、测试数据和结果收集。在监视测试和测试环境的同时，执行已验证的测试进行分析。

活动7。分析结果、报告并重新测试。合并和共享结果数据。作为一个跨职能团队单独分析数据。重新排定其余测试的优先级，并根据需要重新执行它们。当所有度量值都在可接受的限制内时，没有违反任何设置的阈值，并且收集了所有所需的信息，您已经完成了对该特定配置上的特定场景的测试。

为什么要进行性能测试？

在最高级别上，性能测试几乎总是为了解决与支出、机会成本、连续性或公司声誉相关的一个或多个风险而进行。进行性能测试的一些更具体的原因包括：

通过以下方式评估发布准备：

使您能够预测或估计生产中应用程序的性能特征，并根据这些预测评估是否解决性能问题。这些预测对于那些决定应用程序是否准备好发布或者是否能够处理未来的增长，或者是否需要在发布之前进行性能改进/硬件升级的涉众来说也是很有价值的。

提供表明用户对系统性能特征不满意的可能性的数据。

提供数据以帮助预测收入损失或由于可扩展性或稳定性问题或用户对应用程序响应时间不满意而导致的品牌信誉受损。

通过以下方式评估基础设施的充分性：

评估现有能力的充分性。

确定稳定性的可接受性。

确定应用程序基础结构的容量，以及确定交付可接受的应用程序性能所需的未来资源。

比较不同的系统配置，以确定哪种配置最适合应用程序和业务。

验证应用程序是否在预算的资源利用限制内显示出所需的性能特征。

通过以下方式评估开发软件性能的充分性：

在软件更改前后确定应用程序所需的性能特征。

提供应用程序当前和所需性能特征之间的比较。

通过以下方式提高性能调整的效率：

分析应用程序在不同负载级别的行为。

识别应用程序中的瓶颈。

在产品发布之前提供与产品的速度、可扩展性和稳定性相关的信息，从而使您能够就是否以及何时调整系统做出明智的决定。

项目上下文

为了使性能测试项目成功，测试性能的方法和测试本身都必须与项目的上下文相关。在不了解项目上下文的情况下，性能测试必然只关注性能测试人员或测试团队认为重要的项目，而不是那些真正重要的项目，这些项目经常导致浪费时间、挫折和冲突。

项目环境只不过是那些与实现项目成功相关或可能相关的事情。这可能包括但不限于：

项目的总体愿景或意图

性能测试目标

绩效成功标准

开发生命周期

项目进度计划

项目预算

可用的工具和环境

性能测试人员和团队的技能

检测到的性能问题的优先级

部署性能较差的应用程序的业务影响

与项目上下文中的性能测试工作相关的一些项目示例包括：

项目愿景。在开始性能测试之前，请确保您了解当前的项目愿景。项目愿景是决定什么样的性能测试是必要和有价值的基础。定期重新审视愿景，因为它也有可能改变。

系统的目的。了解正在测试的应用程序或系统的用途。这将帮助您识别出您应该关注测试的最高优先级的性能特征。您需要了解系统的意图、部署的实际硬件和软件体系结构以及典型最终用户的特征。

客户或用户期望。在计划性能测试时，请记住客户或用户的期望。记住，客户或用户的满意是基于期望，而不仅仅是符合明确规定的需求。

业务驱动因素。了解业务驱动因素（如业务需求或机会），这些因素在一定程度上受到预算、时间表和/或资源的限制。认识你的生意很重要

测试性能的原因。了解在项目早期进行性能测试的原因。不这样做可能导致无效的性能测试。这些原因往往超出了性能验收标准的列表，而且随着项目的进展，它们必然会改变或转移优先级，因此当您和您的团队了解更多关于应用程序、其性能以及客户或用户的信息时，请定期重新访问它们。

性能测试为项目带来的价值。通过将项目级和业务级的目标转化为具体的、可识别的和可管理的性能测试活动，了解性能测试期望为项目带来的价值。协调并确定这些活动的优先级，以确定哪些性能测试活动可能会增加价值。

项目管理和人员配备。了解团队的组织、运作和沟通技巧，以便有效地进行性能测试过程。了解团队的流程，并解释该流程如何应用于性能测试。如果团队的过程文档没有直接涉及性能测试，则根据您的能力推断该文档以包括性能测试，然后获得项目经理或工程师批准的修订文档。

符合性标准。了解与项目相关的法规要求。获取合规性文档以确保您具有与测试相关的任何声明的特定语言和上下文，因为此信息对于确定合规性测试和确保产品合规性至关重要。同时也要理解，性能测试的本质使得几乎不可能遵循为功能测试开发的相同过程。

项目进度表。了解项目开始和结束日期、硬件和环境可用性日期、构建和发布流程以及项目计划中的任何检查点和里程碑。

性能测试与调优的关系：
当端到端性能测试揭示了被认为不可接受的系统或应用程序特性时，许多团队将他们的重点从性能测试转移到性能调优，以发现使应用程序可以接受地执行所必需的内容。当满足性能标准时，团队还可以将重点转移到调优上，但团队希望减少所使用的资源量，以增加平台空间、减少所需硬件的数量和/或进一步提高系统性能。

 

合作努力：
虽然调优不是大多数性能测试人员的直接责任，但是当调优过程是与被测试的应用程序或系统相关的所有人员之间的合作时，它是最有效的，包括：

产品供应商

设计师

开发人员

测试员

数据库管理员

管理员组

网络管理员

如果没有跨职能团队的合作，几乎不可能获得有效或高效地解决性能问题所需的全系统视角。

性能测试人员或性能测试团队是这个合作团队的关键组件，因为调优通常需要在各种负载条件和配置下对组件、资源和响应时间进行额外的监控。一般来说，性能测试人员拥有以有效方式提供这些信息的工具和专业知识，使性能测试人员成为进行优化的推动者。

调整过程概述

调优遵循一个迭代过程，该过程通常与项目所遵循的性能测试方法分离，但并不独立。以下是典型调整过程的简要概述：

测试是在一个定义明确、受控的测试环境中部署系统或应用程序进行的，以确保测试过程开始时的配置和测试结果是已知的和可重复的。

当测试显示被认为不可接受的性能特征时，性能测试和调整团队将进入诊断和补救阶段（调整），需要对测试环境和/或应用程序进行更改。为了诊断目的而故意扩大问题的临时更改，或更改测试环境以查看这些更改是否会导致更好的性能，这并不少见。

为了最大限度地提高调优阶段的有效性，协作测试和调优团队通常被赋予对测试环境的完全和独占控制权。

性能测试是在对测试环境进行每次更改后执行或重新执行的，以测量补救更改的影响。

调整过程通常包括一系列快速的变化和

调优过程通常包括一系列快速的更改和测试。如果一个合作的测试和调优团队在调优阶段还没有完全可用并致力于此工作，那么这个过程可能会花费成倍的时间。

当一个调整阶段完成时，测试环境通常被重置为初始状态，成功的补救更改将再次应用，任何不成功的补救更改（连同临时仪器和诊断更改）将被丢弃。然后应重复性能测试，以证明已识别出正确的更改。测试环境本身也可能发生变化，以反映对最低要求的生产环境的新期望。这是不寻常的，但调优工作的一个潜在结果。

性能、负载和应力测试

性能测试通常被描述为属于以下三类之一：

性能测试。这种类型的测试确定或验证被测系统或应用程序的速度、可伸缩性或稳定性特征。性能是指实现响应时间、吞吐量和资源利用水平，以满足项目或产品的性能目标。在本指南中，性能测试表示与性能相关测试的所有其他子类别的超集。

负载测试。此性能测试子类别的重点是确定或验证在测试中的系统或应用程序在承受生产操作期间预期的工作负载和负载量时的性能特征。

压力测试。此性能测试子类别的重点是确定或验证在测试中的系统或应用程序在超出生产操作预期的条件下的性能特征。压力测试还可以包括在受到其他压力条件（如内存有限、磁盘空间不足或服务器故障）时，集中于确定或验证测试中的系统或应用程序的性能特征的测试。这些测试旨在确定应用程序在什么条件下会失败、如何失败以及可以监控哪些指示器来警告即将发生的失败。

基线

创建基线是运行一组测试以捕获性能度量数据的过程，目的是评估后续性能改进对系统或应用程序的更改的有效性。基线的一个关键方面是，除了那些为比较而专门改变的特性和配置选项之外，所有的特性和配置选项都必须保持不变。一旦系统的某一部分（并非有意改变以与基线进行比较）发生变化，基线测量就不再是进行比较的有效依据。

对于Web应用程序，您可以使用基线来确定性能是提高还是降低，以及找出不同版本和版本之间的偏差。例如，您可以测量加载时间、每单位时间处理的事务数、每单位时间服务的网页数以及资源利用率（如内存使用率和处理器使用率）。关于使用基线的一些考虑因素包括：

可以为系统、组件或应用程序创建基线。还可以为应用程序的不同层（包括数据库、Web服务等）创建基线。

基线可以为比较设置标准，以跟踪未来的优化或回归。重要的是要验证基线结果是可重复的，因为由于环境和工作负载特性，测试结果之间可能会发生相当大的波动。

基线可以帮助识别性能的变化。基线可以帮助产品团队识别反映开发生命周期过程中降级或优化的性能变化。与已知的状态或配置相比，识别这些更改通常可以简化解决性能问题。

基线资产应该是可重用的。如果基线是通过使用一组可重用的测试资产创建的，那么基线是最有价值的。这些测试必须准确地模拟可重复和可操作的工作负载特性。

基线是度量标准。基线结果可以通过使用一组广泛的关键性能指标来表达，包括响应时间、处理器容量、内存使用、磁盘容量和网络带宽。

基线充当共享参考框架。共享基线结果允许您的团队构建一个关于应用程序或组件性能特征的已获得知识的公共存储库。

避免过度概括基线。如果您的项目需要对应用程序进行重大的重新设计，那么您需要重新建立测试该应用程序的基线。

需要对应用程序进行重大的重新设计，您需要重新建立测试该应用程序的基线。基线是特定于应用程序的，对于比较不同版本之间的性能最有用。有时，应用程序的后续版本如此不同，以致于以前的基线不再适用于比较。

了解应用程序的行为。最好确保在创建基线时完全了解应用程序的行为。如果在对系统进行更改之前不这样做，而将重点放在优化目标上，通常会适得其反。

基线不断发展。有时，您必须重新定义基线，因为自最初捕获基线以来对系统所做的更改。

标杆管理

基准测试是将系统性能与内部创建的基准或其他组织认可的行业标准进行比较的过程。

对于Web应用程序，您将运行一组符合行业基准规范的测试，以捕获确定应用程序基准分数所需的性能指标。然后，您可以将您的应用程序与其他系统或应用程序进行比较，这些系统或应用程序还计算了相同基准的得分。您可以选择调整应用程序性能以达到或超过某个基准分数。关于基准测试的一些考虑因素包括：

你需要按规则办事。基准是通过使用行业规范或移植现有的实现来实现的，以满足这些标准。基准测试需要确定所有必要的组件，这些组件将一起运行，产品存在的市场，以及要测量的特定指标。

因为你按规则行事，你可以是透明的。基准测试结果可以对外公布。由于比较可能是由您的竞争对手产生的，因此您需要使用一套严格的标准方法来进行测试和数据，以确保结果可靠。

您可以在不同的度量中发布结果。性能指标可能包括加载时间、每单位时间处理的事务数、每单位时间访问的网页、处理器使用率、内存使用率、搜索时间等。

术语

本指南中使用了以下定义。已尽一切努力确保这些术语和定义与正式使用和行业标准一致；但是，已知其中一些术语在特定行业和组织中具有某些有效的替代定义和含义。请记住，这些定义旨在帮助沟通，而不是创建通用标准的尝试。

术语/概念

描述

容量

系统的容量是在不违反预定的关键性能验收标准的情况下可以处理的总工作量。

容量测试

容量测试通过确定服务器的最终故障点来补充负载测试，而负载测试在不同级别的负载和流量模式下监视结果。您可以结合容量规划来执行容量测试，用于规划未来的增长，例如增加用户群或增加数据量。例如，为了适应未来的负载，您需要知道有多少额外的资源（如处理器容量、内存使用、磁盘容量或网络带宽）是支持未来使用级别所必需的。容量测试可以帮助您确定一个扩展策略，以确定您应该扩展还是扩展。

元件测试

组件测试是针对应用程序的体系结构组件的任何性能测试。通常测试的组件包括服务器、数据库、网络、防火墙和存储设备。

耐久性试验

耐久性试验是一种性能试验，主要是在长期承受生产操作期间预期的工作量模型和负荷量时，确定或验证试验产品的性能特征。耐久性测试是负载测试的一个子集。

调查

调查是一项基于收集与被测产品的速度、可扩展性和/或稳定性特征相关的信息的活动，这些信息可能对确定或改进产品质量有价值。调查经常被用来证明或反驳关于一个或多个观察到的性能问题的根本原因的假设。

等待时间

延迟是一种响应性度量，表示完成请求执行所需的时间。延迟也可以表示几个延迟或子任务的总和。

韵律学

度量是通过运行性能测试获得的度量，如在通常理解的尺度上所表示的。一些常用的度量标准

通常通过性能测试获得的数据包括随时间推移的处理器利用率和按负载计算的内存利用率。

性能

性能是指有关应用程序的响应时间、吞吐量和资源利用率级别的信息。

性能试验

性能测试是为确定或验证被测产品的速度、可扩展性和/或稳定性特征而进行的技术调查。性能测试是包含本章描述的所有其他性能测试子类别的超集。

绩效预算或分配

性能预算（或分配）是对开发人员关于其组件允许的资源消耗的限制。

绩效目标

性能目标是您的团队希望在产品发布之前达到的标准，尽管在某些情况下，这些标准可能是可协商的。例如，如果为特定事务设置了3秒的响应时间目标，但实际响应时间为3.3秒，则涉众可能会选择发布应用程序，并将该事务的性能调整推迟到将来的版本。

绩效目标

性能目标通常是根据响应时间、吞吐量（每秒事务数）和资源利用率级别来指定的，并且通常侧重于与用户满意度直接相关的指标。

性能要求

由于合同义务、服务水平协议（SLA）或固定业务需求，性能要求是绝对不可协商的标准。毫无疑问，任何性能标准都不会导致延迟发布的决定，直到标准通过，这不是绝对必要的——因此，也不是要求。

绩效目标

性能目标是在特定的一组条件下为项目确定的度量标准所需的值，通常根据响应时间、吞吐量和资源利用水平来指定。资源利用率级别包括应用程序使用的处理器容量、内存、磁盘I/O和网络I/O的数量。绩效目标通常等同于项目目标。

性能测试目标

性能测试目标是指通过性能测试过程收集的数据，这些数据预计对确定或改进产品质量有价值。但是，这些目标不一定是定量的，也不直接与性能需求、目标或声明的服务质量（QoS）规范相关。

性能阈值

性能阈值是为项目确定的度量的最大可接受值，通常以响应时间、吞吐量（每秒事务数）和资源利用率级别来指定。资源利用率级别包括应用程序使用的处理器容量、内存、磁盘I/O和网络I/O的数量。性能阈值通常等同于需求。

资源利用

资源利用率是项目在系统资源方面的成本。主要资源是处理器、内存、磁盘I/O和网络I/O。

响应时间

响应时间是应用程序或子系统对客户机请求的响应程度的度量。

饱和

饱和是指资源达到充分利用的时刻。

可扩展性

可伸缩性是指通过添加诸如处理器、内存和存储容量等资源，应用程序能够处理额外的工作负载，而不会对性能产生不利影响。

情节

在性能测试的上下文中，场景是应用程序中的一系列步骤。场景可以表示用例或业务功能，例如搜索产品目录、将项目添加到购物车或下订单。

冒烟试验

冒烟测试是性能测试的初始运行，以查看应用程序是否可以在正常负载下执行其操作。

尖峰试验

峰值测试是一种性能测试，主要用于确定或验证在测试产品的性能特征，当受到负载模型和负载量的影响时，负载量会在短时间内反复增加，超过预期的生产操作。峰值测试是压力测试的一个子集。

稳定性

在性能测试的上下文中，稳定性是指系统在各种条件下的总体可靠性、健壮性、功能和数据完整性、可用性和/或响应的一致性。

应力测试

压力测试是一种性能测试，旨在评估当应用程序被推到超出正常或峰值负载条件时的行为。压力测试的目标是揭示只有在高负载条件下才会出现的应用程序错误。这些错误可能包括同步问题、争用条件和内存le等。

泄漏。压力测试使您能够识别应用程序的弱点，并显示应用程序在极端负载条件下的行为。

吞吐量

吞吐量是每单位时间可处理的工作单位数；例如，每秒请求数、每天调用数、每秒命中数、每年报告数等。

单元测试

在性能测试的上下文中，单元测试是针对代码模块的任何测试，其中该模块是应用程序整个现有代码库的任何逻辑子集，重点关注性能特征。通常测试的模块包括函数、过程、例程、对象、方法和类。性能单元测试通常由编写测试代码模块的开发人员创建和执行。

利用

在性能测试的上下文中，利用率是资源忙于为用户请求提供服务的时间百分比。剩余的时间百分比被认为是空闲时间。

验证试验

验证测试将被测产品的速度、可扩展性和/或稳定性特征与为该产品设定或假定的期望值进行比较。

工作量

工作负载是应用于系统、应用程序或组件以模拟使用模式的刺激，涉及并发性和/或数据输入。工作负载包括用户总数、并发活动用户、数据量和事务量，以及事务组合。对于性能建模，您将工作负载与单个场景关联起来。

总结

性能测试有助于识别系统中的瓶颈，为将来的测试建立基线，支持性能调整工作，并确定是否符合性能目标和需求。在开发生命周期的早期包含性能测试往往会为项目增加显著的价值。

为了使性能测试项目成功，测试必须与项目的上下文相关，这有助于您关注真正重要的项目。

如果性能特性是不可接受的，那么您通常希望将焦点从性能测试转移到性能调优，以便使应用程序可以接受地执行。如果您希望减少正在使用的资源的数量和/或进一步提高系统性能，那么您可能还会关注调优。

性能测试、负载测试和应力测试是性能测试的子类别，每个测试都有不同的用途。

创建一个基线来评估后续性能改进对系统或应用程序的更改的有效性，通常会提高项目效率。