Artillery性能测试实战：从脚本编写到结果分析全流程指南

1. 项目概述：为什么性能测试不是“跑个脚本”那么简单

“性能测试”这四个字，听起来挺唬人，好像得是架构师或者资深开发才能碰的东西。我刚开始接触的时候也是这么想的，总觉得得先啃完几本大部头的书，搞懂各种复杂的理论模型，才能动手。结果呢？往往是项目上线前，被老板或者产品经理追着问：“咱们这个系统能扛住多少用户啊？” 然后手忙脚乱地找个工具，录个脚本，跑一下，得到一个自己心里都没底的数字。这场景，是不是很熟悉？

后来我用了 Artillery，一个用 Node.js 写的开源性能测试工具，才慢慢把这事儿从“玄学”变成了“工程”。这个标题里的“从入门到能用”，指的就是这个转变过程：不是让你成为性能专家，而是让你能快速、可靠地给系统做一次“体检”，拿到有说服力的数据，发现真实的风险点。它解决的痛点非常明确：让开发和测试同学，在不需要成为专职性能工程师的前提下，也能开展有效的、可重复的、贴近真实场景的性能测试。

Artillery 的核心优势在于它的“开发者友好”。配置文件是 YAML 或 JSON，脚本逻辑可以用 JavaScript 灵活定制，报告清晰直观。它不像一些老牌工具那样需要复杂的图形界面和陡峭的学习曲线。你完全可以把性能测试脚本像代码一样管理，集成到 CI/CD 流水线里，每次提交都跑一下，看看有没有引入性能回退。这对于追求快速迭代的现代研发团队来说，价值巨大。

所以，这篇文章不是 Artillery 的官方文档翻译，而是我踩过不少坑之后，总结出来的一套“能用”的实践。我会带你走完从零开始写第一个测试脚本，到设计一个贴近业务的复杂场景，再到分析报告、定位瓶颈的完整闭环。目标是：看完之后，你不仅能跑起来一个测试，更能理解为什么这么设计，以及当结果不如预期时，你该从哪里入手排查。

2. Artillery 核心设计思路与配置哲学

在动手写配置之前，我们需要先理解 Artillery 是如何看待一次性能测试的。这决定了你的脚本结构，也直接影响测试结果的有效性。

2.1 负载模型：阶段化与目标导向

很多新手会犯一个错误：一上来就设置一个固定的并发用户数，比如 100 用户，跑 10 分钟。这往往不符合真实情况。真实世界的流量是有波峰波谷的，比如促销活动开始瞬间的洪峰，或者白天高、夜晚低的常态。

Artillery 用phases（阶段）来模拟这种动态负载。这是它的核心设计之一。一个典型的负载阶段配置如下：

config: target: 'https://api.your-app.com' phases: - duration: 60 arrivalRate: 5 name: 预热阶段 - duration: 300 arrivalRate: 20 rampTo: 100 name: 爬坡阶段 - duration: 600 arrivalRate: 100 name: 稳态压力阶段 - duration: 120 arrivalRate: 100 rampTo: 0 name: 冷却阶段

我们来拆解一下：

• 预热阶段：用较低的流量（5个用户/秒）跑1分钟。目的是“唤醒”系统，让JVM完成JIT编译、让数据库连接池初始化、让缓存热起来。避免一上来就高压导致冷启动性能差，误导测试结果。
• 爬坡阶段：在5分钟内，将每秒新增用户数从20逐渐提升到100。这模拟了用户逐渐涌入的场景，可以观察系统在压力增长过程中的表现，比如响应时间是否线性增长，错误率何时开始出现。
• 稳态压力阶段：在10分钟内，维持100用户/秒的恒定压力。这是测试系统在稳定高负载下的表现，获取稳态性能指标（如平均响应时间、吞吐量）的关键阶段。
• 冷却阶段：在2分钟内，将负载从100逐渐降为0。优雅地结束测试，让系统处理完剩余请求。

注意：arrivalRate指的是每秒到达的新虚拟用户数，而不是并发用户总数。一个用户完成一个场景（可能包含多个请求）后会退出，新的用户会按这个速率补充进来。这模拟了真实用户的行为。

除了基于到达率的模式，Artillery 还支持目标导向模式。比如，你更关心系统能否维持每秒处理 1000 个请求（RPS），那么可以这样配置：

config: target: 'https://api.your-app.com' phases: - duration: 600 arrivalRate: 1 rampTo: 50 name: 达到目标RPS - duration: 300 arrivalRate: 50 name: 维持目标RPS processor: './helpers.js' payload: path: './data.csv' fields: - 'username' - 'password'

这里的关键是，你需要通过调整arrivalRate来间接达到目标 RPS。通常需要几次试探性运行，找到能产生目标 RPS 的大致用户到达率。一些更专业的性能测试工具（如 k6）有原生的 RPS 模式，但 Artillery 的这种“用户到达”模型在模拟真实用户行为上更直观。

2.2 场景定义：把用户操作编成剧本

scenarios（场景）定义了单个虚拟用户会做什么。一个用户不止打一个接口，他可能先登录，然后浏览列表，再查看详情，最后下单。这就是一个场景。

scenarios: - name: '普通用户浏览下单流程' flow: - post: url: '/api/login' json: username: '{{ username }}' password: '{{ password }}' capture: json: '$.token' as: 'authToken' - think: 3 - get: url: '/api/products' - think: 1 - get: url: '/api/product/{{ $randomNumber(1, 100) }}/detail' - think: 2 - post: url: '/api/order' json: productId: '{{ $randomNumber(1, 100) }}' quantity: 1 headers: Authorization: 'Bearer {{ authToken }}'

这里有几个关键技巧：

1. 变量捕获与传递：capture指令可以从响应中提取数据（如登录后的token），存入变量（as: 'authToken'），供后续请求使用。这是实现有状态测试的基础。
2. 思考时间：think指令让虚拟用户等待 N 秒。这是模拟真实用户行为最重要的设置之一！去掉思考时间的测试是“压力测试”或“极限测试”，而不是“负载测试”。真实的用户不会毫秒不差地连续点击。思考时间能极大地影响对系统并发能力的判断。通常，根据业务操作复杂度，设置 1-5 秒的随机思考时间是合理的。
3. 使用函数和外部数据：{{ $randomNumber(1, 100) }}是 Artillery 的内置函数，用于生成随机数。更复杂的数据（如用户名列表）可以通过payload从 CSV 或 JSON 文件加载，然后在脚本中用{{ username }}引用。这避免了所有用户行为完全一致，使测试更真实。
4. 请求断言：你可以在请求后添加expect子句来检查响应状态码或内容，确保业务流程正确。这能帮你发现那些返回了 200 但业务逻辑已出错的“静默错误”。

2.3 配置的模块化与复用

当测试脚本变复杂后，一个巨大的 YAML 文件会难以维护。Artillery 支持配置的模块化和引用。

你可以创建一个config.base.yaml存放公共配置：

# config.base.yaml config: target: '{{ $env.TARGET_URL, "https://default-env.com" }}' http: timeout: 30 pool: 10 plugins: - 'expect' - 'apdex' ensure: p95: 2000 maxErrorRate: 0.01

然后在具体的测试脚本中引用它，并覆盖或添加特定配置：

# load-test-search.yaml extends: 'config.base.yaml' config: phases: - duration: 300 arrivalRate: 50 processor: './search-flow.js' scenarios: - name: '搜索场景' flow: 'include: ./flows/search.js'

这种结构让管理多套测试环境（开发、测试、预生产）和不同测试场景（登录、搜索、下单）变得非常清晰。你可以用环境变量（如{{ $env.TARGET_URL }}）来动态切换测试目标。

3. 编写真实有效的测试场景：超越 Hello World

掌握了基础配置，我们来设计一个更贴近真实业务的测试场景。假设我们测试一个电商平台的商品搜索和详情页。

3.1 数据准备与参数化

首先，准备测试数据。创建一个data/users.csv：

userId,searchKeyword 1001,智能手机 1002,蓝牙耳机 1003,运动鞋 1004,笔记本电脑 1005,咖啡机 ... (更多数据)

再创建一个data/products.csv，包含商品ID和类别：

productId,category 1,electronics 2,electronics 3,clothing ... (更多数据)

3.2 复杂场景流程实现

现在，编写一个复杂的场景脚本scenarios/shopping.j（注意，对于复杂逻辑，可以用.j后缀，这是 Artillery 的 JavaScript 场景格式，功能更强大）：

// scenarios/shopping.j module.exports = { shoppingFlow }; function shoppingFlow(userContext, events, done) { const userId = userContext.vars.userId; const keyword = userContext.vars.searchKeyword; const faker = require('faker'); // 可以使用外部库生成更真实的数据 // 1. 搜索商品 const searchRequest = { url: `/api/v1/search?q=${encodeURIComponent(keyword)}&page=1&size=20`, method: 'GET' }; // 使用 artillery.http 发起请求 artillery.http.request(searchRequest, (err, response) => { if (err) { events.emit('counter', `errors.search`, 1); return done(err); } // 捕获搜索结果中的第一个商品ID let firstProductId = null; if (response.body && response.body.items && response.body.items.length > 0) { firstProductId = response.body.items[0].id; userContext.vars.productId = firstProductId; // 存入变量 } else { // 没搜到结果，模拟用户换个关键词 userContext.vars.searchKeyword = faker.commerce.productName(); // 这里可以递归调用自身或记录后继续，简单处理：直接去浏览热门商品 firstProductId = Math.floor(Math.random() * 1000) + 1; } // 2. 等待一段时间（模拟用户查看搜索结果） setTimeout(() => { // 3. 查看商品详情 const detailRequest = { url: `/api/v1/products/${firstProductId}`, method: 'GET' }; artillery.http.request(detailRequest, (err, response) => { if (err) { events.emit('counter', `errors.detail`, 1); return done(err); } // 4. 随机决定是否加入购物车（30%概率） if (Math.random() < 0.3) { setTimeout(() => { const cartRequest = { url: '/api/v1/cart/items', method: 'POST', headers: { 'Content-Type': 'application/json', 'Authorization': `Bearer ${userContext.vars.authToken}` // 假设已登录 }, json: { productId: firstProductId, quantity: 1 } }; artillery.http.request(cartRequest, (err) => { // 处理响应... done(); // 场景结束 }); }, 2000); // 加入购物车前再思考2秒 } else { done(); // 不加购，场景结束 } }); }, 3000 + Math.random() * 2000); // 随机思考3-5秒 }); }

然后在主 YAML 配置中引用：

config: target: 'https://shop.example.com' phases: - duration: 600 arrivalRate: 10 rampTo: 30 payload: path: './data/users.csv' fields: - 'userId' - 'searchKeyword' order: sequence processor: './scenarios/auth.js' scenarios: - name: '复杂购物流程' weight: 70 flowFunction: 'shoppingFlow' - name: '简单浏览流程' weight: 30 flow: - get: url: '/api/v1/homepage' - think: 5 - get: url: '/api/v1/hot-products'

实操心得：

• 使用flowFunction：当流程逻辑复杂、需要条件判断、循环或异步操作时，.j脚本比纯 YAMLflow强大得多。
• 权重分配：通过weight属性，可以混合不同的用户场景。比如 70% 的用户执行复杂的购物流程，30% 的用户只是简单浏览。这比所有用户行为一致要真实得多。
• 错误处理与指标记录：在.j脚本中，可以使用events.emit('counter', ...)来自定义指标。例如，记录搜索无结果的次数、加入购物车的比例等，这些业务指标对分析非常有帮助。
• 引入随机性：思考时间、用户决策（如是否加购）都应加入随机性，避免所有用户行为同步产生“共振效应”，这种共振可能会不真实地放大或掩盖某些性能问题。

3.3 插件扩展：获取更深入的洞察

Artillery 的插件生态可以丰富测试能力。最常用的两个插件是expect和metrics-by-endpoint。

expect插件：用于断言。

config: plugins: expect: {} scenarios: - flow: - get: url: '/api/health' expect: - statusCode: 200 - contentType: json - hasProperty: 'status' - equals: - 'UP' - '{{ $.[0].status }}'

如果断言失败，测试会继续，但报告中会记录失败，帮助你发现功能性问题。

metrics-by-endpoint插件：这是必备插件。默认报告只按场景聚合指标，但一个场景可能包含多个请求（如搜索、详情）。这个插件能为每个独立的 URL 端点生成详细的指标（响应时间分布、错误率等），让你精准定位是哪个接口慢。

config: plugins: metrics-by-endpoint: {}

安装插件：npm install -g artillery-plugin-metrics-by-endpoint

4. 执行测试与结果分析：从数据到决策

配置好了，如何运行并理解结果？

4.1 执行命令与关键参数

基础运行命令很简单：

artillery run my-test.yaml

但实际使用时，需要添加一些参数：

artillery run --output report.json --insecure my-test.yaml

• --output report.json：将原始结果数据输出到 JSON 文件，便于后续生成 HTML 报告或自定义分析。
• --insecure：在测试 HTTPS 目标时，忽略证书错误（仅用于测试环境）。
• --environment prod：如果你的 YAML 配置中使用了{{ $environment }}变量，可以用此参数指定。
• -q：安静模式，减少控制台输出。

对于长时间的压力测试，你可能需要让它在后台运行：

nohup artillery run --output result_$(date +%Y%m%d_%H%M%S).json my-test.yaml > artillery.log 2>&1 &

4.2 解读 HTML 报告

运行结束后，用以下命令生成直观的 HTML 报告：

artillery report report.json

生成的report.html会包含以下核心部分：

1. 概览面板：显示测试总时长、总请求数、吞吐量（RPS）、总虚拟用户数、以及最重要的——错误率和 p95/p99 响应时间。第一眼就应该看错误率是否为 0，以及 p95 时间是否在可接受范围内（例如，对于 API，p95 < 1s 可能是一个目标）。

2. 响应时间趋势图：一张随时间变化的折线图，展示最小、中位数、p95、p99 响应时间。理想情况下，这些线在稳态阶段应该是平稳的。如果 p95 或 p99 线持续攀升，说明系统可能存在资源泄漏（如内存泄漏、数据库连接未释放）或达到了某个瓶颈。

3. 吞吐量趋势图：展示每秒完成的请求数（RPS）。这个图应该和你的负载模型（arrivalRate）相匹配。在爬坡阶段，RPS 应稳步上升；在稳态阶段，应保持相对稳定。如果 RPS 上不去甚至下降，而响应时间飙升，这就是典型的系统过载信号。

4. 虚拟用户数趋势图：展示活跃的虚拟用户数。这有助于你确认负载生成是否符合预期。

5. 错误率与错误类型：列出所有发生的 HTTP 状态码错误（4xx，5xx）和其他错误（如超时、连接断开）。这里是你排查问题的起点。大量的 5xx 错误通常指向服务端应用或依赖服务故障；4xx 错误可能源于测试数据或配置问题（如无效 token）；连接超时则可能意味着服务器处理能力不足或网络问题。

6. 场景与请求细分：如果使用了metrics-by-endpoint插件，这里会有每个 URL 端点的详细指标表。这是定位性能瓶颈最关键的部分。你可以一眼看出/api/search的 p99 时间是 2.5 秒，而/api/product/{id}只有 200 毫秒。那么优化重点显然在前者。

4.3 定义性能验收标准与告警

测试不是为了跑个数字，而是为了验证系统是否达标。在 Artillery 配置中，你可以使用ensure块来定义性能验收标准，测试不达标则自动失败。

config: ensure: thresholds: - http.response_time.p95: 500 http.response_time.p99: 1000 http.response_time.max: 2000 - http.errors.rate: 0.005 # 错误率低于 0.5% conditions: - expression: 'http.codes.200 == 0' message: '没有收到任何 200 响应，服务可能完全不可用。' - expression: 'http.response_time.median > 1000 and duration > 60' message: '在测试运行超过1分钟后，中位数响应时间仍超过1秒，性能不达标。'

运行测试时，如果任何阈值或条件被触发，Artillery 会以非零退出码结束，这可以很方便地集成到 CI/CD 流水线中，实现性能门禁。

5. 实战避坑指南与高级技巧

纸上得来终觉浅，下面这些是我在实战中总结出来的血泪经验。

5.1 负载生成器自身的瓶颈

问题：当你把arrivalRate调到很高（比如几百）时，测试机（负载生成器）本身的 CPU 或网络可能先扛不住了，导致无法产生足够的压力，测试结果失真。

排查与解决：

1. 监控负载生成器：运行测试时，用top或htop命令观察 Artillery 进程的 CPU 占用。如果单核接近 100%，说明负载生成器是瓶颈。
2. 分布式负载测试：Artillery Pro 版本支持多机分布式运行。开源版可以通过手动在多台机器上运行不同的测试片段来模拟，但协调和聚合报告比较麻烦。对于极高负载测试，建议使用专业的云压测服务，或者考虑用 k6 这样的工具，它在高并发下资源消耗更低。
3. 优化测试脚本：简化flow逻辑，减少不必要的think时间（在纯粹的压力测试中），使用更高效的 JSON 解析方式（在.j脚本中）。

5.2 “低错误率”的陷阱

问题：报告显示错误率是 0.1%，看起来不错？但可能隐藏了大问题。

案例：一次测试中，错误率只有 0.2%，但业务成功率（通过自定义指标捕获）却下降了 30%。检查日志发现，大量请求返回了 HTTP 200，但响应体里是{“code”: 500, “msg”: “系统繁忙”}。这是因为网关或应用统一了错误响应格式。

对策：

• 使用capture和expect进行业务断言：不仅检查状态码，还要检查响应体内容。
• 在.j脚本中实现自定义校验：解析响应 JSON，判断业务字段是否成功。
• 记录自定义失败指标：如上例，在发现业务码为 500 时，执行events.emit('counter', 'business.error', 1)。

5.3 测试数据与缓存效应

问题：使用固定的少量测试数据（如反复查询同一个商品ID），可能导致测试结果过于乐观，因为数据库查询、应用层缓存都命中了。

对策：

• 准备充足、多样化的测试数据：数据量至少是缓存容量的数倍，确保有足够的“冷数据”被访问。
• 使用随机函数：$randomNumber、$randomString，或从大的数据文件中随机选取。
• 区分“热数据”和“冷数据”场景：可以设计两套场景，一套主要访问热门数据（测试缓存效率），一套主要访问长尾数据（测试数据库和底层服务性能）。

5.4 环境差异与结果可比性

问题：在测试环境跑得很好，上线就崩了。除了环境配置（CPU、内存）差异，一个常被忽略的因素是依赖服务。

对策：

• 尽可能在独立或隔离的环境测试：使用 Docker Compose 搭建一个包含核心应用和模拟依赖（如 Mock Server）的完整环境。
• 对依赖服务进行打桩或流量录制回放：确保每次测试时，依赖服务的响应时间和行为是一致的。工具如 WireMock、Mountebank 可以帮你模拟下游服务。
• 记录测试环境的基准性能：在每次测试报告中，注明测试环境的详细配置（CPU核数、内存、数据库版本等），并运行一个标准的基准测试套件，作为横向对比的参考。

5.5 持续性能测试集成

要让性能测试真正产生价值，必须把它自动化、常态化。

1. CI/CD 集成：在 Jenkins、GitLab CI、GitHub Actions 中，添加一个性能测试阶段。

   # .github/workflows/performance.yml 示例 - name: Run Performance Test run: | npm install -g artillery artillery run --output report.json perf-test.yaml artillery report report.json env: TARGET_URL: ${{ secrets.PERF_TEST_ENV_URL }}

2. 设置性能门禁：如上文所述，利用ensure配置，如果 p95 响应时间或错误率超过阈值，则令 CI 流水线失败，阻止代码合并或部署。
3. 历史趋势分析：将每次性能测试的关键指标（如 p95 响应时间、吞吐量、错误率）存储到时序数据库（如 InfluxDB）中，用 Grafana 绘制趋势图。这样，你能清晰地看到每次代码变更对性能的影响，是改善了还是恶化了。

性能测试不是一锤子买卖，而是一个持续的、迭代的反馈过程。从用 Artillery 跑通第一个简单的脚本开始，逐步完善场景、数据、断言和流程，把它变成研发流程中一个自然而可靠的环节。当你和你的团队能对每次发布后的系统性能心中有数时，你就真正从“入门”走到了“能用”，并且正在向“精通”迈进。