1. 项目概述为什么我们需要并发测试在API开发和测试的日常工作中我们常常会陷入一种“单点验证”的舒适区发送一个请求等待响应检查状态码和返回体然后标记为通过或失败。这就像在检查一辆汽车的每一个零件从轮胎到引擎但从未真正把它开上高速公路看看在车流中、在连续爬坡时它的表现究竟如何。并发请求正是将我们的API从“零件台架测试”推向“真实路况压力测试”的关键一步。想象一下你开发了一个用户注册接口。在开发环境你手动调用一次1秒内返回成功感觉良好。但上线后在促销活动开始的一瞬间成千上万的用户同时点击“注册”你的服务器是像训练有素的交响乐团一样和谐处理还是瞬间崩溃成一团乱麻并发测试要回答的就是这类问题。它模拟的是真实世界中多个用户或系统在同一时刻对同一个或不同API端点发起请求的场景目的是评估系统在高负载下的稳定性、性能瓶颈、资源竞争和数据一致性。而Postman早已不是那个简单的“API调试工具”了。对于很多测试同学和开发者来说它集成了从接口调试、自动化测试到性能压测的完整能力。其内置的Collection Runner和更强大的Newman命令行工具为我们设计并执行并发测试提供了非常便捷的途径。掌握在Postman中实现高效并发测试的艺术意味着你能在开发早期就发现潜在的并发bug如库存超卖、重复下单、状态覆盖评估系统的吞吐量和响应时间拐点从而为系统架构优化和容量规划提供坚实的数据支撑。无论你是后端开发者、测试工程师还是DevOps这都是提升交付质量不可或缺的一环。2. 核心思路与方案选型Postman并发测试的“工具箱”在Postman的生态里实现并发测试并非只有一条路。根据测试场景的复杂度、执行环境的需求和结果分析的深度我们可以选择不同的“工具”。理解每种方案的原理和适用边界是设计高效测试的前提。2.1 方案一Collection Runner 的“伪并发”迭代这是最直观、入门门槛最低的方式。在Postman图形界面中选中一个集合Collection点击“Run”。在运行器界面你可以设置迭代次数Iterations比如100次然后选择“Delay”为0毫秒并勾选“Persist responses for this session”以便查看结果。它的工作原理是什么Collection Runner会顺序地、尽可能快地执行你集合中的请求。当你把延迟设为0并且你的机器和网络足够快时这些请求会以极高的频率一个接一个地发出。从宏观上看在一段很短的时间内完成了大量请求模拟了一种“高吞吐”的场景。然而从微观的协议层面看它本质上是“串行”的。一个请求的响应接收完成后或超时才会发起下一个请求。它并没有真正地同时创建多个网络连接并发起请求。适用场景与局限快速验证逻辑适用于验证接口在连续快速调用下的业务逻辑正确性例如验证幂等性同一请求重复发送是否产生相同效果。发现资源泄漏通过快速连续调用有时能暴露出数据库连接未关闭、内存缓慢增长等问题。局限无法模拟真实的并发压力无法测量在严格“同一时刻”N个请求并发时系统的表现如锁竞争、连接池耗尽。对于性能压测来说这个数据是不准确的。2.2 方案二Postman Monitors 的云端定时并发Postman Monitors是一个云端服务。你可以将一个集合设置为监视器Monitor并配置它在特定时间如每天凌晨2点运行或者每隔一段时间如每10分钟运行一次。最关键的是你可以设置并发数Concurrency。例如设置并发数为5迭代次数为20那么Postman的云端机器人会同时启动5个虚拟用户VUs每个VU执行整个集合总共执行20次迭代。这才是真正的并发。云端的不同VU会同时在毫秒级误差内向你的API服务器发起请求。这是模拟真实用户并发行为更有效的方式。适用场景与局限自动化监控与回归非常适合用于生产或预发环境的API健康检查与监控。定时并发执行可以及时发现因部署、依赖服务变化导致的接口性能退化或错误。跨地域测试Postman的云端节点分布在各地你可以选择不同的地理区域来运行Monitor从而测试API在不同网络环境下的表现。局限执行频率和并发数有免费额度限制。高级配置需要付费。测试环境必须是公网可访问的对于内网服务不适用。此外你对测试机的环境和资源无法控制。2.3 方案三Newman Node.js/Shell 脚本的本地并发控制这是最灵活、最强大也是我们本次重点探讨的方案。Newman是Postman的命令行集合运行工具。通过编写Node.js脚本或Shell脚本我们可以启动多个Newman进程或在一个进程中控制多个并行执行流。其核心原理在于利用Node.js的异步非阻塞特性或操作系统的多进程能力。例如在Node.js中我们可以使用async/await配合Promise.all()或者使用worker_threads模块来同时发起多个独立的Newman运行任务。每个任务都相当于一个独立的用户会话它们之间的执行是并行的。适用场景与优势高度定制化你可以完全控制并发用户数、思考时间Think Time、持续时长、递增策略Ramp-up。复杂场景模拟可以方便地混合不同的业务场景集合分配不同的并发权重。集成CI/CD可以轻松集成到Jenkins、GitLab CI等流水线中在代码合并或构建后自动执行并发性能测试。资源可控在本地或专属测试服务器上运行资源独占结果稳定且可以测试内网服务。成本低廉除了硬件成本无额外服务费用。注意方案选择不是排他的。我通常会用Collection Runner做快速调试和逻辑验证用Newman脚本在测试环境进行正式的压测和基准测试再用Monitors对关键生产接口进行持续监控。三者结合覆盖API质量保障的全生命周期。3. 实战构建基于Newman的本地并发测试框架纸上得来终觉浅我们来搭建一个实实在在的、可复用的并发测试框架。我们的目标是通过一个Node.js脚本能够灵活控制并发数运行指定的Postman集合并生成详细的HTML测试报告。3.1 环境准备与工具安装首先确保你的机器上已经安装了Node.js建议版本14或以上和npm。然后我们需要安装核心工具# 全局安装Newman以便在命令行中直接使用 npm install -g newman # 安装Newman的HTML报告插件这是生成可视化报告的关键 npm install -g newman-reporter-html # 在你的测试项目目录中初始化并安装必要的依赖如果你要写复杂的控制脚本 mkdir api-load-test cd api-load-test npm init -y npm install newman async这里解释一下为什么选择这些工具newman是执行核心newman-reporter-html提供了比默认控制台输出直观得多的结果展示包含统计图表和请求详情对于分析性能趋势至关重要async库是一个强大的异步流程控制工具能让我们优雅地管理多个并发任务避免“回调地狱”。3.2 设计测试集合与环境变量在Postman中良好的测试集合设计是成功的一半。集合结构将需要并发测试的接口按场景组织在一个集合中。例如“用户下单流程”集合可能包含登录-获取商品信息-添加购物车-提交订单-支付。参数化与动态数据并发测试绝不能使用硬编码的固定数据如同一个用户ID否则会引发数据冲突测试结果也不真实。必须使用动态变量。在Pre-request Script中可以使用pm.variables.set生成随机数据如{{$randomInt}}{{$timestamp}}。更推荐的方式是使用外部数据文件CSV或JSON。在Collection Runner或Newman中指定数据文件每个迭代或虚拟用户会取用文件中的一行数据。例如CSV文件包含username, password, productId多行这样每个并发用户都会使用不同的账号和商品进行测试。环境变量将基础URL如{{base_url}}、通用认证信息如{{access_token}}配置在环境变量中。这样只需切换环境就能轻松地在开发、测试、生产环境间执行测试。3.3 编写核心并发控制脚本下面是一个使用Node.js和async库实现的并发控制脚本run-concurrent.js。这个脚本模拟了10个并发用户每个用户顺序执行集合中的所有请求这模拟了10个用户同时在操作总共运行30秒。const newman require(newman); const async require(async); const path require(path); // 配置参数 const CONCURRENCY 10; // 并发用户数 const RUN_DURATION 30; // 运行时长秒 const COLLECTION_PATH path.join(__dirname, Your-API-Collection.postman_collection.json); const ENVIRONMENT_PATH path.join(__dirname, Your-Env.postman_environment.json); // 可选 const DATA_FILE_PATH path.join(__dirname, test-data.csv); // 可选用于参数化 const REPORT_DIR path.join(__dirname, reports); // 每个虚拟用户的任务函数 function runVirtualUser(userId, callback) { const startTime Date.now(); const endTime startTime (RUN_DURATION * 1000); let iterationCount 0; // 定义一个递归函数在指定时间内反复运行集合 function runIteration() { if (Date.now() endTime) { console.log(虚拟用户 ${userId} 完成共执行 ${iterationCount} 次迭代。); return callback(null, { userId, iterationCount }); } newman.run({ collection: require(COLLECTION_PATH), environment: ENVIRONMENT_PATH ? require(ENVIRONMENT_PATH) : undefined, iterationData: DATA_FILE_PATH, // 注入外部数据 reporters: [cli, html], // 命令行和HTML报告 reporter: { html: { export: path.join(REPORT_DIR, report-user-${userId}-${Date.now()}.html) } }, // 禁用默认的迭代次数限制由我们控制时长 iterationCount: 1 }, (err, summary) { iterationCount; if (err) { console.error(虚拟用户 ${userId} 第 ${iterationCount} 次迭代出错:, err); } // 立即开始下一次迭代模拟用户连续操作无思考时间 // 若要添加思考时间可在此处使用setTimeout setImmediate(runIteration); }); } runIteration(); } // 创建并发任务队列 const tasks []; for (let i 1; i CONCURRENCY; i) { tasks.push(async.apply(runVirtualUser, i)); } console.log(开始并发测试并发数${CONCURRENCY} 持续时间${RUN_DURATION}秒); const start Date.now(); // 使用async.parallelLimit控制最大并发数 async.parallelLimit(tasks, CONCURRENCY, (err, results) { const totalTime (Date.now() - start) / 1000; const totalIterations results.reduce((sum, r) sum r.iterationCount, 0); const throughput totalIterations / totalTime; console.log(\n 并发测试总览 ); console.log(总执行时间: ${totalTime.toFixed(2)} 秒); console.log(总迭代次数: ${totalIterations}); console.log(系统吞吐量: ${throughput.toFixed(2)} 次/秒); console.log(\n); // 这里可以汇总所有报告或发送通知 });脚本关键点解析async.parallelLimit:这是并发控制的核心。它接受一个任务数组和一个并发限制数然后并行执行这些任务但同时活跃的任务数不会超过限制。这完美模拟了“并发虚拟用户”的概念。时长控制 vs 次数控制脚本采用了“固定时长”模式RUN_DURATION。每个虚拟用户一旦启动就会在指定时间内不停地循环执行集合直到时间到。这比“固定迭代次数”更能模拟持续负载也更容易计算稳定的吞吐量TPS。无思考时间Zero Think Time当前脚本中一个迭代结束立即开始下一个setImmediate。这是“压力测试”模式旨在压出系统极限。如果是“负载测试”模拟更真实用户行为应在runIteration函数内加入随机的延迟如setTimeout(runIteration, Math.random() * 3000)模拟0-3秒用户思考时间。报告生成每个虚拟用户会生成独立的HTML报告。在实际分析时你更需要关注聚合指标。可以考虑使用newman-reporter-htmlextra等更高级的报告插件或者将结果输出为JSON后用自定义脚本进行聚合分析。3.4 执行测试与初步观察在终端中运行脚本node run-concurrent.js执行过程中观察控制台输出是否有大量请求失败4xx, 5xx平均响应时间是否随着测试进行而显著增长你的测试机Client的CPU、内存和网络带宽是否成为瓶颈可以用htop或任务管理器监控一个常见的误区是压测时只关注服务器忽略了测试机本身。如果测试机网络带宽打满或CPU跑满它就无法及时发出足够多的请求测试结果就会失真。此时你需要减少并发数或者使用分布式压测多台测试机同时运行Newman。4. 结果分析与性能瓶颈定位测试跑完了生成了几十个HTML报告我们该看什么如何从数据中发现问题4.1 关键性能指标解读打开任意一个HTML报告或聚合看整体关注以下核心指标指标含义健康信号潜在问题平均响应时间所有请求从发起到接收完响应所花费时间的平均值。平稳且符合业务SLA要求如95%的请求200ms。持续上升或远高于预期。表明服务器处理能力达到瓶颈。最小/最大响应时间最快和最慢的请求耗时。最大时间与平均时间相差不大排除首次冷启动。最大时间异常高如“长尾请求”可能存在个别请求阻塞如死锁、慢查询。请求速率 (RPS)每秒完成的请求数。Newman报告中的 “Requests per second”。在并发数增加时RPS能线性或接近线性增长直到达到系统瓶颈。并发数增加但RPS增长缓慢甚至不增长说明系统存在明显的并发处理瓶颈。错误率失败请求数占总请求数的百分比。接近0%。高于0.5%就需要警惕。特别是并发时出现的错误如429 Too Many Requests限流、502 Bad Gateway上游服务挂掉、500 Internal Server Error代码bug。标准差响应时间的离散程度。越小越好说明服务稳定。标准差大说明用户体验不一致有些请求快有些慢得离谱。4.2 从现象定位瓶颈的实战思路根据测试中观察到的现象可以按以下思路进行排查现象A低并发下正常高并发下响应时间飙升错误率增高。排查方向1应用服务器资源。登录服务器使用top,vmstat 1命令查看。如果CPU使用率持续高于80%或内存使用率不断增长可能内存泄漏说明应用服务器是瓶颈。可能需要优化代码、扩容实例或调整JVM/应用服务器参数如线程池大小。排查方向2数据库。高并发下数据库连接池很容易被耗尽。检查应用日志是否有“获取连接超时”的错误。使用数据库监控工具如MySQL的SHOW PROCESSLIST查看是否有大量慢查询或锁等待。索引缺失、事务过大是常见原因。排查方向3外部依赖服务。你的API可能调用了其他服务的接口。在高并发下这些下游服务可能先扛不住了。查看调用链日志或监控定位到具体的慢依赖。现象B响应时间平稳但RPS上不去达不到预期吞吐量。排查方向1网络带宽。检查服务器出口带宽和测试机入口带宽是否已满。对于返回数据量大的接口如列表查询带宽可能成为瓶颈。排查方向2限流。检查服务器或网关是否配置了限流策略。观察错误中是否有大量429状态码。排查方向3串行化瓶颈。检查代码中是否存在全局锁、单例模式下的同步处理、或串行访问的共享资源如一个文件、一个Redis键。这会导致请求排队无法充分利用多核CPU。现象C出现偶发的、非5xx的业务逻辑错误如“库存不足”、“重复提交”。排查方向并发安全。这是并发测试的核心价值所在这类错误在单次请求测试中永远不会出现。典型场景是“超卖”查询库存和扣减库存不是原子操作在两个并发请求间出现了竞争条件。解决方案是使用数据库的悲观锁SELECT ... FOR UPDATE或乐观锁版本号或者利用Redis的原子操作DECR等。实操心得不要只看聚合报告的平均值。一定要把报告下载下来仔细查看“失败”的请求详情。Postman的HTML报告会列出每个失败请求的请求和响应信息。一个500错误的响应体里往往藏着具体的异常堆栈这是定位Bug最直接的线索。我曾通过一个并发测试发现的NullPointerException定位到一个未做空值判断的共享静态变量它在高并发下被多个线程同时修改从而引发了问题。5. 高级技巧与避坑指南掌握了基础框架后下面这些技巧能让你的并发测试更加专业和高效。5.1 参数化数据的艺术使用CSV文件进行参数化时一个常见问题是数据量不够。如果设置100个并发用户运行100次迭代就需要1万行数据。手动造数据不现实。技巧使用脚本动态生成数据文件。可以写一个简单的Node.js脚本用faker库生成海量逼真的测试数据用户名、邮箱、地址等并输出为CSV。注意确保数据的关键字段如用户名、手机号在文件内是唯一的以避免业务逻辑上的冲突。5.2 处理动态认证信息很多API需要先登录获取token后续请求携带这个token。在并发测试中如果所有虚拟用户使用同一个token可能触发服务器的单token频率限制或者不符合真实场景。解决方案为每个虚拟用户准备独立的登录凭据在数据文件中。在集合中将“登录”请求放在最前面在它的Tests脚本中将响应中的token提取出来并设置为集合变量Collection Variable。// 在登录请求的Tests标签页中 const jsonData pm.response.json(); pm.collectionVariables.set(access_token, jsonData.data.access_token);这样同一个集合内的后续请求使用{{access_token}}引用时每个并发用户会话Collection Run都有自己的token副本互不干扰。这是Postman变量作用域的关键知识。5.3 监控与度量集成单纯的Newman报告可能不够。我们需要将性能数据集成到监控系统如Grafana中以便长期跟踪。技巧使用newman-reporter-influxdb或newman-reporter-prometheus插件将测试结果响应时间、RPS等直接推送到时序数据库InfluxDB或暴露给Prometheus。然后就可以在Grafana中制作漂亮的性能趋势面板设置告警阈值如平均响应时间1s时告警。5.4 常见陷阱与排查“Socket Hang Up” 或 “ETIMEDOUT” 错误原因服务器连接数已满端口耗尽、服务器处理太慢导致客户端超时、或测试机本地端口耗尽。排查首先调大Newman的--timeout-request参数。检查服务器端的最大连接数配置如Tomcat的maxConnections。在测试机上通过netstat命令查看TIME_WAIT状态的连接是否过多可以考虑调整系统TCP参数如缩短tcp_fin_timeout。测试结果波动巨大每次运行数据差异大原因测试环境不干净。后台有其他任务在跑如定时Job、其他人在测试、数据库缓存未预热、或服务器存在资源竞争如共享的物理机。解决确保测试环境独立、数据干净。正式压测前先进行几轮“预热”运行让JVM完成JIT编译让数据库热点数据加载到内存。在虚拟机或容器环境中确保测试实例独占计算资源。Newman脚本内存泄漏导致测试中途崩溃原因在长时间运行的脚本中如果不断创建对象而不释放Node.js进程内存会持续增长。解决简化脚本逻辑避免在循环中创建大对象。使用--disable-unicode等Newman选项减少内存开销。定期重启Newman进程对于长达数小时的稳定性测试可以分段进行。并发测试不是一锤子买卖而是一个持续迭代的过程。从简单的集合运行器开始逐步过渡到脚本化的、可配置的并发测试框架并将其作为CI/CD流水线中的一个质量关卡。每一次代码提交都可以对核心接口进行一次小规模的并发冒烟测试将性能回归和并发Bug扼杀在萌芽阶段。当你把并发测试当成一种习惯你对系统在真实世界中的行为就会有完全不同的、更深刻的认知。这不仅仅是测试的艺术更是构建稳健系统的工程智慧。