2. 特征清单概念：什么是压力测试特征清单，清单在测试生命周期中的定位与作用
2.1 压力测试特征清单的定义
压力测试特征清单（Stress Test Feature Checklist）是一份结构化的、可追溯的测试资产，它系统性地罗列了被测系统在压力场景下需要验证的所有关键特征。这些特征不仅包括功能层面的吞吐量、响应时间、错误率，还涵盖资源消耗、稳定性边界、降级策略、数据一致性等非功能维度。
与传统的“测试用例列表”不同，特征清单关注的是“测什么”而非“怎么测”。它是一份特征级的测试规划，为后续的脚本开发、场景设计、结果分析提供统一的参考基线。
核心公式： 压力测试特征清单 = 系统特征分解 + 压力维度映射 + 可观测指标绑定
2.2 清单在测试生命周期中的定位
压力测试生命周期通常包含以下阶段：需求分析 → 特征识别 → 场景设计 → 脚本开发 → 执行调度 → 结果分析 → 报告输出。特征清单位于需求分析与场景设计之间，是连接业务目标与技术实现的桥梁。
定位要点： 特征清单不是可选的“文档产物”，而是压力测试工程的核心骨架。缺少特征清单的压测项目，往往会出现“测了不该测的，漏了该测的”现象。
2.3 特征清单的三大核心作用
| 作用维度 | 具体说明 | 业务价值 |
|---|---|---|
| 1. 范围锚定 | 明确压力测试的边界：哪些特征必须测、哪些可选、哪些不测 | 避免测试范围蔓延，节省30%~50%的无效压测工作量 |
| 2. 质量基线 | 为每个特征定义可量化的通过标准（如：TP99 ≤ 500ms，错误率 ≤ 0.1%） | 提供客观的“通过/不通过”判定依据，消除主观争议 |
| 3. 沟通契约 | 作为开发、测试、运维、产品多方对齐认知的书面载体 | 减少跨团队沟通成本，提升压测结果的可信度与可复现性 |
2.4 特征清单的典型结构
一份完整的压力测试特征清单通常包含以下字段：
- 特征ID：唯一标识，如
STR-FEAT-001 - 特征名称：简洁描述，如“用户登录接口吞吐量”
- 特征类别：性能、稳定性、资源、降级、数据一致性等
- 压力维度：并发数、吞吐量、数据量、持续时间等
- 观测指标：RT、TPS、CPU、内存、错误率等
- 通过标准：量化的阈值或范围
- 优先级：P0/P1/P2（P0为必须通过）
- 关联场景：对应的压测场景名称或ID
常见误区： 将特征清单写成“测试用例清单”。特征清单关注的是“系统应该具备什么能力”，而不是“测试人员要执行什么步骤”。例如，“支持10万并发用户登录”是特征，“使用JMeter发送100个线程循环10次”是用例。
2.5 特征清单与周边资产的关系
2.6 构建特征清单的时机与责任人
| 阶段 | 参与角色 | 主要活动 | 产出物 |
|---|---|---|---|
| 需求评审后 | 性能测试工程师 + 系统架构师 | 识别核心业务链路与关键非功能需求 | 特征清单初稿（V1） |
| 技术设计评审后 | 系统架构师 + 开发负责人 | 补充技术约束特征（如连接池、缓存策略） | 特征清单修订版（V2） |
| 压测执行前 | 性能测试工程师 + 运维 | 确认环境配置与监控指标对齐 | 特征清单终版（V3） |
最佳实践： 特征清单应作为活文档管理，在压测执行过程中发现新的特征边界时，及时更新清单。推荐使用版本控制工具（如Git）管理清单的变更历史。
2.7 本章小结
压力测试特征清单是压测工程的核心资产，它解决了“测什么”的根本问题。通过将系统特征与压力维度、观测指标进行结构化绑定，特征清单实现了：
- 范围锚定：明确测试边界，避免资源浪费
- 质量基线：提供可量化的通过标准
- 沟通契约：对齐多方认知，提升协作效率