5.2 脚本开发规范与最佳实践
5.2 脚本开发规范与最佳实践
本节摘要：脚本能跑不等于好脚本。本节讲脚本规范——命名、分层、参数化、版本管理——写出可维护可复用的压测脚本。
本节地图
阅读完本节，你应当能够：
- 写规范的命名和结构
- 合理分层复用
- 把脚本纳入版本管理
概念脉络
一、命名规范
清晰的命名让脚本可读：
- 线程组：
TG-场景名-负载，如TG-登录-100并发 - 采样器：
HTTP-接口名，如HTTP-登录接口 - 变量：有意义的名字，如
${USERNAME}不用${a} - 断言/提取器：
断言-校验内容，如断言-登录成功
二、分层与复用
- HTTP 默认值统一配置：服务器、端口、公共请求头放 HTTP 默认值，改一处全改
- 用户变量集中管理：环境配置（域名、超时）放用户定义的变量，切换环境改一处
- 片段复用：重复的逻辑（如登录）做成测试片段，多处引用
三、参数化与数据分离
- 业务输入参数化（用户名、商品 ID）放 CSV，不硬编码
- 环境配置（域名、账号池）放变量，脚本和数据分离
- 敏感数据脱敏，不入版本库
四、版本管理
- JMX 放 Git，团队协作
- 数据文件（CSV）单独管理，大文件用 LFS 或不入库
- 脚本变更走评审，重要场景脚本基线化
五、可维护性要点
- 注释：复杂逻辑加注释说明意图（JMeter 支持测试计划注释）
- 模块化：大脚本拆小片段，按场景分线程组
- 避免过度复杂：能用采样器解决的别堆 JSR223 脚本
- 调试开关：结果树等调试元件用开关控制，压测时关
六、常见反模式
- 硬编码 URL/账号，换环境要改脚本
- 所有元件堆一个线程组，作用域混乱
- 用 Beanshell 脚本（性能差）
- 压测时开结果树（吃内存）
⚠️ 常见坑：硬编码一切——URL、账号、参数都写死在脚本里，换环境换数据要改脚本。用变量和参数化分离。
💡 关键直觉：好脚本可维护可复用——命名清晰、HTTP 默认值统一、变量集中、参数化分离数据、JMX 入 Git。能简单别复杂。
一节小结
- 命名：线程组/采样器/变量有意义的名字。
- 分层复用：HTTP 默认值统一配置、用户变量集中、测试片段复用。
- 参数化：业务输入放 CSV，环境配置放变量，数据脚本分离。
- 版本管理：JMX 入 Git，数据文件单独管理，重要脚本基线化。
- 可维护：注释、模块化、别过度复杂、调试元件用开关。
- 避免硬编码、元件堆砌、Beanshell、压测开结果树。
下一节讲执行环境——压测机和被测环境怎么配。
脚本规范
工程化脚本开发遵循规范：命名规范（测试计划、线程组、采样器均用有意义名称）；配置外置（环境变量集中管理，避免硬编码）；断言分级（关键业务断言严格，辅助请求轻断言）；结果分离（不同场景独立结果文件）。
最佳实践清单
- 用用户定义变量管理环境与公共参数
- HTTP 请求默认值统一超时与编码
- 采样器间通过变量传递数据，避免硬编码关联值
- 长时间测试启用结果流式写入，防止内存溢出
- 脚本版本化入库，与代码同管
- 每个采样器设置合理的断言，防止"假成功"
反模式提醒
常见反模式：整个测试计划只有一个线程组（无法区分业务比例）；断言缺失或过宽（错误率失真）；监听器过多拖慢执行；使用非 JSR223 脚本（性能差）；在脚本中硬编码环境地址（无法移植）。对照清单自查能显著提升脚本质量。
规范落地示例
脚本规范落地检查表：命名（测试计划含项目与场景、采样器含接口名与操作）；变量（环境配置全部变量化、禁止硬编码域名）；断言（关键接口必有断言、错误信息记录）；结果（每个场景独立结果文件、命名含时间戳）；版本（脚本入库、提交信息含变更说明）。用检查表逐项自审，能快速提升脚本工程化程度。
评审要点
脚本评审重点关注：是否覆盖真实业务比例；并发模型是否符合目标场景；数据准备是否充分（避免全部命中缓存）；断言是否能有效识别错误；超时设置是否合理（过长掩盖问题、过短误报）；脚本是否可移植（换环境只需改变量）。评审通过后再执行，能大幅减少无效压测轮次。
命令行示例
<!-- 规范脚本示例片段 --> <TestPlan> <stringProp name="TestPlan.comments">登录+查询</stringProp> <elementProp name="User Defined Variables">...</elementProp> <ThreadGroup>...</ThreadGroup> </TestPlan>
规范检查
对照规范清单逐项检查：命名是否清晰、变量是否外置、断言是否到位、结果文件是否分离、脚本是否入库。规范的核心目标是让脚本可读、可维护、可复用，而不是为了形式合规。