用途：该技能面向性能测试的编写与审查，衡量系统在既定负载下的非功能特性，如延迟、吞吐量、并发容量与资源消耗。它不用于验证业务逻辑正确性（应使用单元测试或集成测试），也不用于用户旅程验证（应使用端到端测试）。
主要能力：
- 以 SLO 作为断言依据：性能测试不对具体数值做断言，而是对由约定 SLO 推导出的阈值做断言，例如 p95 响应时间不超过 200ms、错误率低于 0.1%、在 100 虚拟用户下吞吐量不低于 500 req/s。缺少明确 SLO 阈值的测试只是测量，而非测试。
- 先建立基线：首次运行建立基线，后续运行以此为基础并设允许波动范围做断言，例如 p95 回退不得超过 10%；阈值应先测量后固化，不应凭猜测设定。
- 采用 AAA 结构：准备阶段配置负载画像（虚拟用户、爬升、持续时间）、准备数据并隔离被测系统；执行阶段运行负载场景；断言阶段对照 SLO 阈值评估结果，任一阈值被突破即判定失败。
- 隔离被测系统：使用专用测试环境、无其他用户共享流量、硬件等级与生产一致或记录换算比例、在测量窗口前预热缓存与连接池、避免生产环境中不存在的分析器与调试日志开销。
- 统计化报告：报告 p50、p95、p99 等百分位而非平均值，并同时报告错误率与吞吐量。
使用方式：资料提供了性能测试常见问题清单，例如无 SLO 阈值、无基线、环境不当、仅报告平均值、把预热计入结果、测试的是压测工具本身、缺少资源监控、仅有单一场景等，并给出对应修正方向。同时给出负载场景类型：基线负载、峰值负载、尖峰测试、浸泡测试与压力测试，建议先从基线与峰值开始，仅在关注内存泄漏或连接耗尽时增加浸泡测试。工具方面仅作参考不作规定：脚本类 k6（JS）、Locust（Python）、Gatling（Scala/Java）；图形化或录制类 Apache JMeter；HTTP 基准测试 wrk、hey、autocannon；持续性能分析 Pyroscope、Clinic.js、async-profiler。
适用场景：发布前验证服务是否满足延迟或吞吐 SLO、检测代码改动引入的响应时间回退、为预期流量规划基础设施容量、在持续或峰值负载下识别瓶颈。
限制：性能结果具有统计波动性，应多次运行并报告统计置信区间；若环境与生产不一致，绝对响应时间不可直接比较；2 分钟的基线运行无法暴露内存泄漏或连接池耗尽，需依赖长时间浸泡测试。具体工具用法应遵循团队标准，资料未提供更详细的实现步骤。