1. 课程导论：容量性能压测巡检的背景与重要性，JMeter与k6双引擎对比的课程目标与学习路径
1.1 容量性能压测巡检：为什么需要常态化？
在微服务架构与云原生基础设施广泛普及的今天，系统容量不再是“上线前测一次”就能一劳永逸的静态指标。业务流量波动、代码持续交付、基础设施弹性伸缩等因素，使得系统容量呈现动态衰减特征。容量性能压测巡检（Capacity Performance Testing Patrol）正是为了应对这一挑战而生的常态化机制。
核心痛点： 传统“大促前压一次”的模式，无法发现日常迭代中引入的性能劣化（如慢SQL、内存泄漏、线程池耗尽），导致线上故障频发。
容量巡检的核心价值体现在三个维度：
- 风险左移： 在每次发布前或定期（如每日/每周）执行轻量级压测，提前暴露容量瓶颈。
- 趋势分析： 通过持续采集吞吐量（TPS）、响应时间（RT）、错误率等指标，建立容量基线，识别劣化趋势。
- 成本优化： 基于真实压测数据指导资源规格调整，避免过度配置或资源不足。
| 巡检维度 | 传统压测 | 容量巡检 |
|---|---|---|
| 执行频率 | 季度/大促前 | 每日/每次发布 |
| 场景规模 | 全链路、高并发 | 核心链路、中低并发 |
| 关注指标 | 最大TPS、极限水位 | 基线偏差、劣化趋势 |
| 自动化程度 | 人工触发、半自动 | CI/CD集成、全自动 |
| 输出产物 | 一次性报告 | 时序指标、告警事件 |
1.2 为什么选择JMeter与k6双引擎？
在容量巡检脚本编排领域，JMeter与k6分别代表了两种主流技术路线：GUI驱动的传统测试工具与代码驱动的现代压测工具。两者并非替代关系，而是在不同场景下互为补充。
课程立场： 本课程不鼓吹“k6取代JMeter”，而是帮助学员掌握双引擎的编排思维，根据团队技术栈、巡检场景和运维能力，选择最合适的工具或组合使用。
下表从巡检脚本编排的核心维度进行对比：
| 对比维度 | JMeter | k6 |
|---|---|---|
| 脚本形态 | XML (.jmx) + GUI配置 | JavaScript (ES6+) 代码 |
| 版本控制 | 二进制文件，diff困难 | 纯文本，Git友好 |
| CI/CD集成 | 需CLI + 插件 | 原生支持，CLI简洁 |
| 动态参数化 | CSV Data Set Config / 函数 | JS变量 + 外部数据加载 |
| 断言与检查 | 响应断言 + JSON断言 | check() + 自定义JS逻辑 |
| 分布式执行 | Master-Slave模式 | k6-operator (K8s) / 云执行 |
| 资源消耗 | 较高（Java虚拟机） | 较低（Go二进制） |
| 学习曲线 | 低（GUI拖拽） | 中（需JS基础） |
1.3 课程目标与学习路径
本课程旨在帮助学员建立双引擎视角下的容量巡检脚本编排能力，而非单纯教授工具操作。完成本课程后，学员将能够：
- 独立设计 基于JMeter或k6的容量巡检脚本框架。
- 掌握 参数化、断言、数据驱动、分布式执行等核心编排技巧。
- 实现 巡检脚本在CI/CD流水线中的自动化集成与结果断言。
- 对比分析 两种引擎在特定场景下的优劣，做出合理技术选型。
1.4 学习路径图
前置要求： 学员需具备基本的HTTP协议知识、至少一种编程语言基础（Java或JavaScript更佳），以及基础的Linux命令行操作能力。本课程不教授编程入门。
1.5 课程章节速览
| 章节 | 核心内容 | 引擎侧重 |
|---|---|---|
| 第1章 | 课程导论：背景、目标、学习路径 | 双引擎 |
| 第2-5章 | 容量巡检基础：指标、场景、数据模型 | 通用 |
| 第6-12章 | JMeter脚本编排：参数化、断言、分布式、CI集成 | JMeter |
| 第13-19章 | k6脚本编排：JS语法、check、thresholds、k6-operator | k6 |
| 第20-25章 | 双引擎对比：脚本结构、执行效率、维护成本、选型决策 | 双引擎 |
| 第26-30章 | CI/CD集成实战：Jenkins、GitLab CI、ArgoCD | 双引擎 |