【转帖】如何制定一份详尽的性能测试计划
进行任何性能测试之前，都需要制定一份详尽的测试计划，从业务角度到技术角度详细地说明性能测试将如何进行。一份性能测试计划应该至少包含以下方面：[*]总体方法
[*]依据与基本假定
[*]性能测试前的操作
[*]性能测试方法
[*]性能测试操作
[*]业务范围内的过程
[*]业务范围外的过程
[*]性能测试方案
[*]性能测试的执行
[*]性能测试指标
和任何测试计划一样，这份性能测试计划的文字要做到尽量精简，可以使用列表清晰明确地将信息表达出来。这将减少因为沟通问题产生的误解。总体方法这一部分是指用非技术性术语将性能测试的总体方法描述出来。目标受众是管理部门与业务部门。样例如下：“此性能测试方法主要用来对新部署的系统所支持的业务过程进行测试。通过部署这次性能测试，我们将：以减少这次新部署所带来的性能问题为主要目的。做出基本的运行假定，确定部署中需要进行性能测试的部分。就这些假定取得一致意见，决定性能与压力测试的适当等级，并在有限的任务时间内完成。这份文件是即时更新的。随着我们收集到越来越多的信息，并就适当的性能测试方法达成一致协议时，将再次更新这份文件。”依据与基本假定在这一部分中，要清晰地描述测试前必须满足的依据（必须完成的任务）与基本假定（测试时假定为真）。样例如下：
“继续部署任何性能测试之前，必须满足以下条件：要进行性能测试的组件必须能完全正常运行。要进行性能测试的组件要安装在可以代表（或按比例可调的）预期的生产系统的硬件或固件中。数据存储库要能代表（或按比例可调）预期的生产系统。有确定的性能测试目标，包括运行情况的假定与测试方案。安装好性能测试工具并提供所需的技术支持。”性能测试前的操作这部分要清楚地说明在正式进行性能测试之前为确定系统已经就绪而进行的预测试操作。相当于功能测试中的烟雾测试（smoke testing）。样例如：
“为减少性能测试中的风险，可以进行几项预测试操作：在质量保证测试环境下利用‘桩(stub)’或‘实用程序（utilities）’测试事务处理能力，即投影最大负载（projected peak loads）。用‘桩’或‘实用程序’代替无需测试或只需进行有限测试的B2B类事务。这将取消任何关于B2B事务的依据。用‘桩’或‘实用程序’代替性能测试中无法使用的内部组件。这将移除所有关于此类组件的依据。在所有大规模服务器上部署合适的性能监控器。”性能测试方法这一部分是前面总体方法的扩展，但考虑到了业务与技术两个方面。样例如：“本性能测试方法主要用来测试新部署的系统的逻辑。通过部署这次性能测试，我们将：以减少这次新部署所带来的性能问题为主要目的。做出基本的运行假定，确定部署中需要进行性能测试的部分。就这些假定取得一致意见，确定即将完成的性能的适当等级。使用可以模拟预期生产规模的一流的性能测试工具。模拟需要进行性能测试的组件（将在生产中使用的组件）构成测试环境，检测所有异常。在性能测试期间同时使用生产与非生产（测试）监控器器检测系统的性能。”性能测试操作这一部分详细说明了性能测试中所进行的操作。样例如：“性能测试中将进行以下操作：根据既定方案对系统进行合适的负载测试。方案包括：
[*]用户操作（业务流程）
[*]既定负载（每分钟的事务处理次数）
[*]既定指标（响应时间）
性能测试期间将进行手工测试和自动化的功能测试，保证在当前负载下用户操作不会受到影响。将使用系统监控器监测测试涉及的所有服务器的性能，保证其达到预期的性能要求。部署后支持团队将在性能测试现场观察性能测试结果并提供支持。”业务范围内的过程这一部分指定系统的哪些方面属于业务范围内（基于标准）。样例如：
“性能测试时将以下过程视为业务范围内的过程：用户注册登录/访问用户对内容进行浏览销售条款与执行账目计算业务过程目录与以下人员商议制定：业务分析员、市场分析员、基础组织和业主。”业务范围外的过程这一部分指定系统的哪些方面属于业务范围外（基于标准）。样例如：
“性能测试时将以下过程视为业务范围外的过程：信用检查> 前提：信用检查将委托第三方进行――因此不会对性能产生明显的影响。所有在当前未被列为业务范围内或范围外的业务功能。> 前提：所有未在本文件中列出的范围内或范围外的业务都不会对业务产生明显的性能影响。” 制定性能测试方案这一部分在测试计划中的位置要取决于企业在性能测试领域的成熟度。如果企业几乎或者完全没有这一领域的经验，就在计划中包括这一部分，否则可以将其作为附录部分。样例如：“制定性能测试方案需要大量来自IT与业务部门的信息。业务方案
[*]业务方案首先要用简单的文本描述待测的业务过程。
[*]然后业务方案扩展到一系列包含准确的数据需求的详细步骤。
[*]最后直到当IT部门确定了应用/服务器的行为(比如缓存)需要(或不需要)哪些额外的数据需求，业务方案就算完成。
预期吞吐量(峰值)
[*]预期吞吐量首先要说明高峰时段和非高峰时段用户对某一业务的预期操作量。
[*]然后扩展到一系列不同的、终端用户可能无法分辨(或可以分辨)的业务过程。
[*]直到IT部门确定哪些额外的因素(如果有的话)会影响到负载(比如负载平衡)，预期吞吐量这部分就算完成了。
验证性能标准(验证不同负载条件下的响应时间)
[*]性能标准验证是指在低、中、高负荷条件下可接受的业务响应时间。根据一天的系统负载情况为参考。这可以用其它的性能方案进行模拟。
[*]然后性能测试团队便能用可测的系统事件对验证标准进行阐述。然后这些标准就提交到业务部门以供验证。
[*]直到IT部门确定了如何在性能测试过程中对系统性能进行监控，验证标准过程部分就完成了。这其中包括性能测试团队的指标。
数据需求(方案与部署的具体内容)
[*]业务部门确定会影响到终端用户体验的主要数据部分。
[*]IT部门对这些数据需求进行扩展以包含终端用户不可见的一些因素，比如缓存。
[*]性能测试团队与IT和业务部门合作创建所需的数据存储库以支持性能测试。”
性能测试的执行这一部分在测试计划中的位置仍然取决于企业在性能测试领域的成熟度。如果企业有大量的性能测试经验，那么这一部分可以作为辅助性的附录。样例如：“性能测试通常按照一定的顺序进行：制定性能测试方案。根据制定的方案定义一天的负载。单独执行性能测试以检测特定的业务流程中可能存在的问题。以封包的方式执行性能方案，模拟一天的活动，并根据性能标准进行评测。报告性能测试的结果。调节系统。根据需要重新进行测试。”性能测试指标性能测试指标是与性能测试方案中制定的性能验证标准相对应的。如果企业预备将其作为性能要求，那么就应该在性能测试计划中增加性能要求的部分。最基本的性能测试指标包括检测响应时间和给定性能负载下事务处理的失败率(如性能测试方案中所述)。然后用这些指标与性能要求对比，确定系统是否符合业务要求。结束语本文只能描述性能测试计划的一般情况，具体则要根据所测试的系统和情况而定。最后要说的是，许多非性能测试操作经常被视为性能测试——我喜欢称之为假寐的(warm-and-fuzzy)性能测试。如果你没有模拟预期的生产负载，那就不能说是在做性能测试。
:victory: 支持分享
页:
[1]
