性能测试计划要先把目标指标、业务场景、负载模型、环境与数据、执行节奏和判定标准定下来，再落到角色分工与交付物上。一份可用的计划应让开发、测试、运维和业务对“测什么、测到什么程度算通过、谁在什么时候交付什么”形成一致理解。下面按编制顺序给出方法、角色分工、执行规则、示例与完成检查清单。
要点总览（TL;DR）
- 性能测试计划按六步编制：定目标与验收口径、排业务链路优先级、设计负载模型与场景、准备环境数据与监控、安排执行轮次与准入准出、约定风险处置与复盘。
- 性能指标要从业务量推导，并按“指标名+目标值+统计范围+分位数+采样周期”书写，否则同一数值在不同口径下不可比。
- 角色分工要落到交付物和确认人：测试负责人、性能测试工程师、开发、运维、业务方、DBA各自产出什么、在哪个评审节点确认，都写进计划。
- 执行轮次按基准、单接口、混合与峰值、稳定性与容量的顺序推进，环境、数据、脚本、监控四项准入条件未满足时该轮延期而非带条件开始。
- 计划定稿前用完成检查清单逐项核对，评审通过后连同评审记录归档，后续调整以版本方式更新。
性能测试计划先定哪几件事
性能测试计划的编制顺序建议固定为六步：明确性能目标与验收口径、梳理关键业务链路并排优先级、设计负载模型与场景、准备环境数据与监控、安排执行轮次与准入准出、约定风险处置与复盘方式。这个顺序的价值在于每一步的产出都是下一步的输入，指标没定就无法设计负载，场景没排优先级就无法安排执行轮次。
计划必须回答的核心问题可以归纳为一张要素清单：
| 要素 | 计划中要写清的内容 | 完成标志 |
|---|---|---|
| 性能目标与验收口径 | 响应时间、吞吐量、并发数、错误率、资源水位，以及各自的统计范围 | 每个指标有数值、口径和判定方式 |
| 业务链路与场景优先级 | 被测链路清单、重要度排序、覆盖范围说明 | 场景清单经业务方确认 |
| 负载模型 | 并发与吞吐的推导过程、加压方式、持续时间 | 模型假设写明，可被复现 |
| 环境、数据与监控 | 环境规格与生产差异、数据量与构造方式、监控项与采集频率 | 环境与数据就绪检查通过 |
| 执行轮次与准入准出 | 轮次排期、每轮准入条件、准出判定规则 | 排期表与判定规则可逐条核对 |
| 风险与回退 | 环境冲突、数据污染、指标不达标的处置路径 | 风险项有责任人和应对动作 |
这六项中，前两项决定计划的方向，中间两项决定计划能否执行，后两项决定执行结果是否可信。编写时不必追求一次写全，但每一项都要有明确的责任人和确认节点，否则计划容易停留在描述层面。
从目标到场景：性能指标与负载模型怎么定
性能指标要从业务量推导，而不是凭经验填数字。基本做法是：取业务高峰时段的访问量或订单量，拆到具体链路上的请求占比，再结合目标响应时间估算所需的并发与吞吐。推导过程中的假设要写进计划，例如“按大促峰值订单量为日常的若干倍估算”，这样后续指标调整时有据可查。
指标口径的写法决定数值是否可比。同一个“响应时间 500ms”，统计范围是全链路还是单接口、取平均值还是 95 分位、采样周期是 1 分钟还是 5 分钟，结论可能完全不同。建议每个指标都按“指标名 + 目标值 + 统计范围 + 分位数 + 采样周期”的格式书写，例如：下单接口响应时间，95 分位不超过 800ms，统计范围为网关到服务返回，采样周期 1 分钟。
典型场景类型及用途如下：
| 场景类型 | 目的 | 常见负载设置 |
|---|---|---|
| 基准测试 | 建立单请求在低负载下的性能基线 | 单用户或低并发，重复多轮取稳定值 |
| 单接口测试 | 定位单个接口的容量上限 | 逐步加压至指标劣化 |
| 混合业务场景 | 验证多链路并行时的相互影响 | 按业务请求比例分配流量 |
| 峰值测试 | 验证短时高峰下的表现 | 快速加压至峰值并维持一段时间 |
| 稳定性测试 | 发现长时间运行下的内存、连接泄漏 | 目标负载持续数小时以上 |
| 容量测试 | 确定系统可承载的上限，为扩容提供依据 | 阶梯加压直至准出指标不达标 |
场景优先级依据业务重要度和风险确定：交易、支付等核心链路优先，历史故障频发的模块优先，近期有大改动的模块优先。资源有限时，先保证核心链路的基准与峰值场景，稳定性与容量场景可安排在后续轮次。
指标暂时无法确认时，在计划中标注“待定”并写明约定复测的节点和确认人，比填入没有依据的数字更可靠。待定项要在评审时逐条过一遍，避免执行阶段才发现验收标准缺失。
角色分工与各阶段交付物
角色分工要落到交付物和确认人，只写岗位名称无法支撑执行。常见职责边界如下：
| 角色 | 主要职责 | 关键交付物 |
|---|---|---|
| 测试负责人 | 组织计划编写与评审，协调资源与排期，确认准出结论 | 性能测试计划、评审记录、准出结论 |
| 性能测试工程师 | 设计场景与负载模型，准备脚本与数据，执行并采集结果 | 场景设计说明、脚本、执行记录、监控数据 |
| 开发 | 提供链路与架构信息，配合定位性能问题并修复 | 链路说明、问题定位结论、修复版本 |
| 运维 | 准备环境与监控，保障执行期间资源可用 | 环境就绪确认、监控配置与数据 |
| 业务方 | 提供业务量与峰值信息，确认场景优先级与验收口径 | 业务量数据、场景确认意见 |
| DBA | 提供数据库容量与慢查询信息，配合 SQL 层面优化 | 数据库监控数据、优化建议 |
交付物之间形成链条：计划评审通过后进入场景设计与脚本、数据准备，脚本评审通过才允许执行；每轮执行产出执行记录与监控报告，全部轮次结束后汇总为性能测试报告。评审节点建议设在计划定稿、场景与脚本确认、准出结论三个位置，每个节点明确确认人，确认意见留痕。
跨团队交接时，用统一的工作项承载任务分派和状态流转会更清晰。例如在 ONES 中，测试计划可与迭代关联，用例可分配执行人并按用户组配置权限，未通过的用例可快速创建缺陷任务并在测试与研发团队间流转，测试报告支持按模板生成。这样计划中的角色分工、执行记录和缺陷闭环能落在同一套工作项上，减少口头交接带来的信息丢失。
执行安排与准入准出条件
执行轮次按“基准—单接口—混合与峰值—稳定性与容量”的顺序安排，前一轮的结论作为后一轮的输入。每轮开始前需满足准入条件：环境规格与生产差异已记录且可接受、测试数据按计划量级准备完毕、脚本通过评审、监控项已配置并可采集。四项中任一项未满足，该轮应延期而不是带条件开始，否则结果无法用于判定。
每轮执行要记录的内容包括：执行时间与持续时长、负载设置、实际达到的并发与吞吐、各指标实测值、监控曲线、异常现象与日志位置。记录格式在计划中统一，便于跨轮次对比。
准出判定以计划中定义的指标为准：核心链路指标全部达标、错误率在约定范围内、资源水位未触及瓶颈阈值，可判定通过。出现不达标时，处置路径为：记录性能缺陷并关联到对应场景与轮次、由开发定位、修复后安排回归轮次，回归范围至少覆盖受影响链路及其混合场景。性能缺陷的记录方式与功能缺陷一致，便于统一跟踪。
计划变更与延期要有明确处理方式：因环境、数据或需求变更导致轮次调整时，更新排期表并通知各确认人，涉及验收口径变化的需重新评审。延期原因和影响范围写入执行记录，作为复盘输入。
示例：一份电商下单链路的性能测试计划要点
以下为演示情景，数据仅用于说明写法，不代表真实项目。
目标指标示例：下单接口响应时间 95 分位不超过 800ms，统计范围为网关到服务返回，采样周期 1 分钟；下单链路整体吞吐不低于峰值时段订单量的 1.5 倍；错误率低于 0.1%；应用服务器 CPU 使用率不超过 70%。
场景与负载模型示例：基准场景用单用户重复请求建立基线；单接口场景对下单接口阶梯加压，每级维持 5 分钟，观察指标拐点；混合场景按浏览、加购、下单的请求比例分配流量，模拟真实访问结构；峰值场景在 10 分钟内加压至目标峰值的 1.5 倍并维持 30 分钟；稳定性场景以目标负载持续 8 小时，重点观察内存与连接数变化。
角色与时间安排示例：第一周完成计划评审与场景确认，业务方提供峰值订单量数据；第二周完成脚本与数据准备并通过评审，运维完成环境与监控就绪确认；第三周执行基准、单接口与混合场景；第四周执行峰值与稳定性场景，输出报告并组织准出评审。
判定与风险处置示例：峰值场景中若下单接口 95 分位超过 800ms，记录为性能缺陷并关联该轮次，开发定位后安排回归；若环境资源被其他项目占用导致轮次无法执行，由运维协调并顺延，顺延情况写入执行记录。准出结论由测试负责人汇总各轮结果后提交评审确认。
计划评审与完成检查
计划定稿前，按以下清单逐项核对，全部满足方可提交评审：
- 每个性能指标都有目标值、统计范围、分位数和采样周期，可被判定。
- 场景清单覆盖核心业务链路，优先级有业务方确认意见。
- 负载模型的推导假设写明，并发与吞吐可复现。
- 环境规格与生产差异已记录，测试数据量级与构造方式明确。
- 监控项、采集频率和查看方式已落实到具体配置。
- 每个角色有明确职责和交付物，评审节点有确认人。
- 执行轮次排期与环境、数据、脚本的准入条件对应。
- 准出判定规则可逐条核对，不达标时的处置路径写明。
- 风险项有责任人和应对动作，计划变更流程已约定。
- 待定项已标注并约定确认时间与确认人。
评审通过后，计划与评审记录一并归档，后续轮次调整以版本方式更新，保留历史版本以便追溯判定依据。执行结束后的复盘结论回写到计划或独立复盘文档中，作为下一次性能测试计划的输入。
常见问题
性能指标暂时定不下来，计划还能往下写吗？
可以。把该指标标注为“待定”，同时写明约定复测的节点和确认人，比填入没有依据的数字更可靠。待定项要在计划评审时逐条过一遍，明确由谁在什么时间补齐，避免执行阶段才发现验收标准缺失。其余已确认的指标、场景和环境准备可以照常推进。
性能测试中发现的问题，应该按什么方式记录和跟踪？
性能缺陷的记录方式与功能缺陷保持一致，便于统一跟踪。记录时关联到对应场景与执行轮次，写清实测值、监控曲线和日志位置，由开发定位，修复后安排回归轮次。回归范围至少覆盖受影响链路及其混合场景，避免只验证单接口而漏掉并行影响。若使用 ONES，未通过的用例可快速创建缺陷任务，缺陷任务在测试与研发团队间流转，并支持关联至迭代。
测试环境规格和生产不一致，结果还能用吗？
可以用，但前提是把差异记录清楚并在判定时说明适用范围。计划中要写明环境规格与生产的主要差异，例如机器配置、数据量级、依赖服务的部署方式，判定结论时据此说明结果的可迁移程度。差异过大导致指标无法支撑验收时，应调整环境或把结论限定为趋势参考，并在报告中注明。
执行轮次因环境被占用而延期，计划要怎么处理？
由运维协调资源并顺延轮次，顺延原因和影响范围写入执行记录，作为复盘输入。涉及验收口径变化的调整需要重新评审，仅排期变化则更新排期表并通知各确认人即可。计划后续调整以版本方式更新，保留历史版本以便追溯判定依据。
计划里的角色分工怎么落到日常协作中，避免只停留在文档上？
关键是让分工对应到具体工作项和评审节点，而不是只写岗位名称。计划定稿、场景与脚本确认、准出结论三个节点各设确认人，确认意见留痕。跨团队交接时用统一的工作项承载任务分派和状态流转会更清晰，例如在 ONES 中测试计划可与迭代关联，用例可分配执行人并按用户组配置权限，测试报告支持按模板生成，使分工、执行记录和缺陷闭环落在同一套工作项上。
