Postman于Linux如何进行性能测试 - 问答

Linux 下使用 Postman 进行性能测试

一方案总览

在 Linux 环境中，Postman 更适合做功能与回归测试；做性能测试通常借助 Newman（Postman 命令行运行器） 执行集合，并通过脚本或专业工具实现并发与压力控制。
常用组合与适用场景如下：
- Postman Runner：仅适合非常简单的“并发/迭代”验证，指标较基础。
- Newman：便于在 CI/CD 中批量运行并生成报告，但本身不直接提供并发控制。
- Newman + Shell 并发脚本：快速模拟低到中等并发（如 ≤50 VU），实现简单但需自行聚合结果。
- Newman + Artillery：更精准的并发/吞吐控制（VU、RPS、持续时间），适合稳定性与峰值场景。
- 专业工具（如 JMeter/LoadRunner）：复杂场景、分布式压测与更丰富指标的首选。

二环境准备

安装 Node.js（建议 v14+），自带 npm。
全局安装 Newman 与报告插件：
- npm install -g newman
- npm install -g newman-reporter-html
可选：安装 Artillery 做精准并发（npm install -g artillery）。
在 Postman 中创建 Collection，添加请求与 Tests 断言，导出为 JSON；如有多个环境，导出 Environment JSON 便于切换。

三执行步骤

单线程基线验证（确保脚本与断言正确）
- newman run test_collection.json -e dev.postman_environment.json -r html --reporter-html-export report_baseline.html

简易并发（Shell 多进程）

思路：启动 N 个 Newman 进程并行，各自执行 M 次迭代，最后聚合报告。

参考脚本（示例：10 并发、总 100 次，报告分片输出）：

performance_test.sh

#!/usr/bin/env bash
COLLECTION="test_collection.json"
ENV_FILE="dev.postman_environment.json"
CONCURRENT=10
TOTAL_RUNS=100
REPORT_DIR="reports"
mkdir -p "$REPORT_DIR"
for ((i=1; i<=$CONCURRENT; i++)); do
  RUNS=$((TOTAL_RUNS / CONCURRENT))
  [ $i -eq $CONCURRENT ] && RUNS=$((RUNS + TOTAL_RUNS % CONCURRENT)) # 余数给最后一个进程
  newman run "$COLLECTION" -e "$ENV_FILE" -n "$RUNS" -r html \
    --reporter-html-export "$REPORT_DIR/report_$i.html" &
done
wait
echo "All done. Reports: $REPORT_DIR/"

赋予执行权限并运行：chmod +x performance_test.sh && ./performance_test.sh

精准并发（Artillery）
- 示例配置 artillery_config.yml（目标 http://api.example.com，60 秒；每秒新增 10 个用户，线性 ramp 到 50 VU）：
```
config:
  target: "http://api.example.com"
  phases:
    - duration: 60
      arrivalRate: 10
      rampTo: 50
scenarios:
  - postman:
      collection: "./test_collection.json"
```
- 执行：artillery run artillery_config.yml（可加 -o report_artillery.json 导出结果）。

四结果分析与系统监控

报告与指标
- Newman 报告（HTML/JSON/JUnit）可查看每个请求的 响应时间分布、成功率、断言结果 等，用于定位功能正确性与基本性能基线。
- Artillery 输出 请求速率、响应时间 P95/P99、并发/错误率 等，更适合吞吐与稳定性评估。
Linux 资源监控
- 在压测同时采集服务器资源：top/htop（CPU/内存）、vmstat（系统整体）、iostat（磁盘 IO）、netstat/ss（连接数/端口）。
- 建议将监控数据落盘（如 csv/tsv），与压测时间轴对齐，便于分析瓶颈（CPU 饱和、连接耗尽、IO 等待等）。

五局限与建议

Postman/Newman 更适合 简单性能验证与回归；当需要 高并发、复杂场景编排、分布式压测、更丰富指标 时，优先使用 JMeter/LoadRunner/Artillery 等专业工具。
并发模型差异：多进程/多实例脚本容易实现，但 RPS 与 VU 的精确控制、Think Time、梯度加压/峰值保持 等能力有限；Artillery 在这些方面更成熟。
持续集成：将 Newman 命令写入 Jenkins/GitLab CI 定时或触发执行，归档 HTML/JUnit 报告，结合资源监控做趋势分析。

0 赞

0 踩