performance-test-gatling

performance-test-gatling（EN）

中文版： 请参阅对应的中文技能。

适用场景

• 需要以 Gatling 结构生成性能测试产物。
• 项目已使用 Gatling，或希望生成可直接用于 Gatling 的场景。

工作流

1. 阅读并遵循渐进式披露部分列出的主提示词（覆盖范围、结构、质量标准）。
2. 仅补充会影响结果的项目背景：范围、环境、限制、风险、依赖项、预期交付内容。
3. 如果输入不完整，请返回可用的初稿，并明确标注假设和信息缺口。
4. 默认使用 Markdown；仅在用户要求时切换格式。

领域执行要点

1. 阅读项目的 Gatling、插件、JDK 以及 Java/Scala/Kotlin DSL 版本，并保留其目录结构。在同一个 DSL 中使用兼容的注入和断言 API。使用项目构建工具对生成的产物进行离线测试编译；依赖未缓存时应标记为 BLOCKED，而非编译通过。
2. 开放模型控制用户到达率；只有在每个用户仅发出一个请求且没有额外循环或重试时，到达率才等于请求 RPS。封闭模型控制并发数；应根据实际请求数量和时间窗口核实 RPS。
3. 按用户/循环计算 feeder 消耗量。队列耗尽必须明确失败；循环复用数据必须获得策略许可，且身份标识/业务键不能冲突。
4. 使用项目阈值和版本支持的断言。缺少门槛条件时，应提供未配置的骨架，而非臆造 500ms/1% 等数值。编译、实际达到的负载和 SLO 结果是不同的证据。

核心约束

• 按风险/业务影响排序，不要一概而论。
• 将已确认事实与当前假设分开；如果没有 SLA/流量数据，请将每个数字标记为假设，并列出待确认问题。
• 不要臆造用户未提供的端点、字段、环境或根本原因；密钥只能使用占位符/环境变量，绝不能使用真实令牌。
• 确保输出可执行：场景具体、优先级明确、后续步骤清晰。
• 默认仅采用最关键的 1–2 种场景类型，不要默认同时运行基线/负载/压力/峰值/耐久测试。

渐进式披露

• 校准领域结果、有效控制手段或证据缺口时，请阅读 references/domain-decision-example.md，了解经过脱敏的输入、逐项判定依据和可复现的计算过程。

• 生成输出前，请阅读并遵循 prompts/performance-test-gatling.md（最低覆盖要求、输出结构、质量标准）。

• 如果有合适的现成模板，请使用 output-templates/ 下对应的文件。

• 用户需要示例或希望与现有产物保持一致时，请阅读相关的 examples/。

• 对于深入的框架/故障排查/架构说明，仅阅读 references/ 下的相关文件，不要加载整个目录。

• 对于格式转换或辅助检查，优先使用现有的 scripts/，不要重复造轮子。

• 对此技能进行评估/回归测试时，请使用 skill-up 和 evals/。

交付前检查清单

• 遵循了主提示词的输出结构
• 聚焦最低覆盖要求：目标场景、负载模型、测试数据或 feeder 需求、渐增负载曲线、阈值、环境与监控、优先级最高的瓶颈、报告需求……（详情见主提示词）
• 覆盖了最低检查清单，或说明了未覆盖项
• 高风险项已明确标注优先级
• 未臆造用户未提供的细节
• 已标注假设和信息缺口

常见陷阱

• 范围/背景缺失时，不要假装内容完整。

• 不要把所有事项都视为同等重要。

• 不要遗漏假设和信息缺口。

• 不要堆砌与当前工具链无关的泛泛理论。

• 如需检查 DSL/JMX 产物和数据消耗边界，请阅读 evals/fixtures/java-dsl/README.md；本地示例可用于校准产物，但在没有项目门槛的情况下，不能作为验收依据。