1. 项目概述为什么要把Postman、Newman和Jenkins拧在一起如果你已经用Postman手动测试接口有一段时间了那你肯定经历过这种场景每次开发提交新代码或者产品经理提了个新需求你都得打开Postman找到对应的集合点一下“Run”然后盯着屏幕看结果。一次两次还行但项目迭代快了一天跑个十几次不仅枯燥还容易因为手滑或者状态没清空而出错。更别提那些需要在凌晨执行的定时任务或者需要集成到持续交付流水线里的测试了。这就是“Postman教程-22-Newman结合Jenkins执行自动化测试”这个标题背后要解决的核心痛点将接口测试从手动、孤立的桌面操作转变为自动化、可调度、可集成的持续测试环节。简单说就是让机器在后台帮你跑测试你只需要关心结果报告。Postman是前端负责设计、调试和保存我们的测试用例集合。Newman是Postman的命令行工具它能把Postman集合“翻译”成机器能理解并自动执行的脚本。而Jenkins则是那个不知疲倦的“调度员”和“监工”它可以定时触发Newman执行测试或者在代码提交后自动触发并把测试结果整理成报告通过邮件或消息通知你。这套组合拳的价值在于它把接口测试无缝嵌入了DevOps流程。开发代码一提交Jenkins自动拉取代码、构建、部署到测试环境紧接着就触发Newman执行接口测试。如果测试失败第一时间就能发现是哪个接口、哪个断言出了问题快速定位避免有问题的代码流入下一个环节。这不仅仅是解放了测试人员的双手更是为软件质量增加了一道自动化的、可靠的防线。2. 核心工具链解析与选型考量在动手搭建之前我们得先搞清楚手里这几件“兵器”的特性和为什么选它们。这不是简单的工具堆砌每个选择背后都有其场景适应性的考量。2.1 Postman不仅仅是API调试工具很多人对Postman的认知停留在“API调试客户端”这低估了它的能力。对于自动化测试而言Postman的核心价值在于其集合Collection和环境变量Environment功能。一个设计良好的Postman集合就是一个结构化的测试套件。你可以把相关的接口请求如用户模块、订单模块分组到不同的文件夹里。更重要的是你可以在请求之间使用Tests标签页编写JavaScript断言脚本验证响应状态码、响应体结构、字段值等。还可以在Pre-request Script标签页编写前置脚本用于生成签名、获取Token等。而环境变量是让测试用例变得灵活可配置的关键。比如你可以定义一个“测试环境”变量base_url的值是http://test-api.example.com再定义一个“生产环境”base_url变成https://api.example.com。同一个集合通过切换环境就能在不同目标上执行测试。这种设计为后续的自动化执行铺平了道路。注意在设计用于自动化的集合时要特别注意测试的独立性和可重复性。避免测试用例之间有状态依赖比如用例B依赖用例A创建的数据。如果无法避免要善用脚本在测试前后清理数据或者使用诸如pm.variables.set来动态传递数据。2.2 Newman从图形界面到命令行执行Newman是Postman官方推出的命令行工具本质是一个Node.js包。它的作用非常纯粹读取Postman导出的集合JSON文件和环境变量JSON文件然后在命令行中模拟Postman的运行器Runner执行所有请求和测试脚本。为什么需要Newman因为图形化的Postman无法被Jenkins这类自动化服务器直接调用。Newman提供了程序化执行的入口。它支持丰富的命令行参数可以指定迭代次数、延迟、环境、数据文件等并且能以多种格式JSON、HTML、JUnit等输出测试报告。安装Newman非常简单前提是系统已安装Node.js和npm或yarnnpm install -g newman # 或者 yarn global add newman安装后一个最基本的执行命令如下newman run MyCollection.postman_collection.json -e TestEnvironment.postman_environment.json这条命令就完成了从图形化工具到自动化脚本的关键一跃。2.3 Jenkins自动化流程的“大脑”与“枢纽”Jenkins是一个开源的持续集成/持续交付CI/CD工具。在这里我们主要利用它的两个核心能力任务调度和流水线编排。你可以创建一个自由风格项目配置一个定时任务例如每天凌晨2点执行或者配置GitHub/GitLab的Webhook在代码推送时自动触发。触发后Jenkins会在其代理节点可以是Master也可以是Slave节点上执行你预设的Shell或批处理命令也就是调用Newman。更现代的做法是使用Jenkins Pipeline流水线。你可以编写一个Jenkinsfile文件用代码通常是Groovy DSL来定义整个构建、测试、部署的流程。这种方式将流水线配置也纳入了版本控制更易于维护和复用。对于我们的场景一个简单的Pipeline脚本可能包含“检出代码”、“安装依赖”、“执行Newman测试”、“归档测试报告”等阶段。选择Jenkins是因为它生态成熟、插件丰富、社区活跃。它有专门的插件来美化测试报告如HTML Publisher插件用于发布HTML报告也有插件能很好地与邮件、消息通知集成。虽然市面上有GitLab CI、GitHub Actions等更现代的选择但Jenkins在私有化部署、复杂流程定制方面仍有其不可替代的优势。3. 实战搭建从零构建Jenkins中的Newman任务理论讲完我们进入实战环节。假设我们已经在服务器上安装好了Jenkins可通过Docker、War包或系统包安装并且Jenkins服务器上已经安装了Node.js和Newman。3.1 准备Postman资产集合与环境自动化测试的基石是稳定、可靠的Postman集合。在导出之前请在你的Postman中完成以下检查集合结构梳理确保集合内的请求逻辑清晰文件夹划分合理。避免一个集合过于庞大可以按业务模块拆分成多个小集合便于管理和并行执行。断言全面性检查每个请求的Tests脚本。除了检查pm.response.code是否为200还应验证关键业务字段。例如查询用户接口可以断言响应体中包含必要的用户信息字段。// 示例Tests脚本 pm.test(Status code is 200, function () { pm.response.to.have.status(200); }); pm.test(Response has user id and name, function () { var jsonData pm.response.json(); pm.expect(jsonData).to.have.property(id); pm.expect(jsonData.name).to.be.a(string).and.to.not.be.empty; });变量化配置将所有可能变化的部分替换为变量。最重要的就是base_url。在请求的URL中使用{{base_url}}/api/user的形式。在环境配置中定义base_url的值。导出文件在Postman中点击集合右侧的“...”选择“Export”导出为Collection v2.1格式推荐。同样地导出你的环境变量。你会得到两个JSON文件例如user_api_collection.json和test_env.json。3.2 在Jenkins中创建自由风格项目这是最简单直接的入门方式。新建任务登录Jenkins点击“新建Item”输入任务名称如“API-AutoTest-With-Newman”选择“Freestyle project”点击确定。源码管理可选但推荐在“源码管理”部分选择Git。填入你的代码仓库地址其中存放着刚才导出的Postman集合JSON文件、环境文件以及可能需要的测试数据文件。这样做的目的是实现“配置即代码”所有测试资产与项目代码一同管理版本可控。构建触发器这里决定何时运行测试。定时构建例如填入H 2 * * *表示每天凌晨2点执行一次H代表哈希用于分散负载。轮询SCM例如*/5 * * * *表示每5分钟检查一次代码仓库有更新则触发。GitHub/GitLab Webhook更推荐在代码仓库配置Webhook指向Jenkins的/github-webhook/或/project/端点实现代码推送后立即触发。这需要先在Jenkins中安装对应的插件并配置。构建环境可以勾选“Provide Node npm bin/ folder to PATH”如果你是通过Jenkins的Node.js插件全局安装了Node.js的话。这能确保newman命令可用。构建步骤这是核心。点击“增加构建步骤”选择“Execute shell”Linux或“Execute Windows batch command”Windows。 假设你的仓库结构如下project-root/ ├── postman/ │ ├── collections/ │ │ └── user_api_collection.json │ └── environments/ │ └── test_env.json └── 其他源代码那么一个基础的Shell构建步骤可以这样写# 进入postman资产目录 cd postman # 执行Newman测试并生成多种格式的报告 newman run collections/user_api_collection.json \ -e environments/test_env.json \ --reporters cli,json,html,junit \ --reporter-json-export newman-report.json \ --reporter-html-export newman-report.html \ --reporter-junit-export newman-report.xml # 检查Newman的退出码非0表示测试失败 if [ $? -ne 0 ]; then echo Newman测试执行失败 # 这里可以执行一些失败后的操作比如发送紧急通知 exit 1 # 让Jenkins构建标记为失败 fi这段脚本做了几件事切换到正确目录用Newman运行集合并指定环境同时生成四种报告命令行输出、JSON、HTML、JUnit最后检查命令执行状态。后置构建操作这是呈现结果的关键。归档产物在“后置构建操作”中添加“Archive the artifacts”。填入postman/newman-report.html, postman/newman-report.xml。这样每次构建后报告文件都会被保存下来可以直接在Jenkins界面下载。发布HTML报告安装“HTML Publisher Plugin”插件。然后在后置构建操作中添加“Publish HTML reports”。设置HTML目录为postman索引页面为newman-report.html报告标题自拟。之后Jenkins项目侧边栏会出现一个链接直接点击即可在浏览器中查看格式美观的HTML测试报告。发布JUnit测试结果添加“Publish JUnit test result report”。测试报告XML填入postman/newman-report.xml。Jenkins会解析这个XML在项目趋势图中展示测试通过率、失败历史非常直观。邮件通知配置“Editable Email Notification”可以设置当构建失败时自动发送邮件给相关责任人附上失败日志和报告链接。3.3 进阶使用Jenkins Pipeline流水线对于更复杂或追求最佳实践的团队Pipeline是更好的选择。它在项目根目录创建一个Jenkinsfile。pipeline { agent any // 指定在任何可用代理上运行 tools { nodejs nodejs-16 // 假设你在Jenkins全局工具配置中定义了一个名为nodejs-16的Node.js安装 } stages { stage(Checkout) { steps { git branch: main, url: https://your-git-repo.git // 检出代码 } } stage(API Test) { steps { dir(postman) { // 进入postman目录 sh # 如果Newman未全局安装也可在Pipeline中临时安装 # npm install -g newman newman run collections/user_api_collection.json \ -e environments/test_env.json \ --reporters cli,json,html,junit \ --reporter-json-export newman-report.json \ --reporter-html-export newman-report.html \ --reporter-junit-export newman-report.xml } } post { always { junit postman/newman-report.xml // 总是发布JUnit报告 publishHTML(target: [ reportName: Newman HTML Report, reportDir: postman, reportFiles: newman-report.html, keepAll: true ]) } failure { // 构建失败时可以执行更多操作如发送Slack消息 echo API测试阶段失败 } } } // 可以在此之后添加更多阶段如部署到测试环境、执行UI测试等 } }将Jenkinsfile提交到代码仓库然后在Jenkins中创建一个“Pipeline”类型的任务在配置中指定“Pipeline script from SCM”。这样整个流水线的定义就和代码在一起了修改流程只需要修改Jenkinsfile并提交实现了真正的“Pipeline as Code”。4. 深度优化与高级实践基础流程跑通后我们会遇到更多实际场景下的问题。下面是一些提升自动化测试效能的进阶技巧。4.1 测试数据管理与动态化硬编码的测试数据是自动化测试的“毒药”。当测试数据变化或需要多组数据验证时维护成本极高。Newman支持通过数据文件Data Files进行数据驱动测试。准备数据文件创建一个JSON或CSV文件。例如test_data.json[ {username: user1, password: pass123, expected_status: 200}, {username: user2, password: wrongpass, expected_status: 401}, {username: , password: pass123, expected_status: 400} ]在Postman集合中使用变量在登录请求的Body中使用{{username}}和{{password}}。在Tests脚本中可以使用data.username来引用当前迭代的数据行。// 在Postman请求的Tests标签页中 var expectedStatus pm.iterationData.get(expected_status); // 获取数据文件中的值 pm.test(验证状态码为 ${expectedStatus}, function () { pm.response.to.have.status(expectedStatus); });在Jenkins中调用在Newman命令中增加-d test_data.json参数。Newman会为数据文件中的每一行数据运行一次整个集合或指定的迭代。newman run collection.json -e environment.json -d test_data.json --iteration-count 3 // --iteration-count 3 指定运行3次迭代与数据文件行数对应。4.2 复杂场景下的脚本编排有时测试流程不是简单的顺序执行。例如流程依赖必须先拿到登录Token才能执行后续的增删改查。条件执行只有某个前置接口成功才执行下一个接口。循环执行模拟并发压力或重复操作。这些可以在Postman的Collection级或Folder级的Pre-request Script和Tests Script中通过编写复杂的JavaScript逻辑来实现。Newman会忠实地执行这些脚本。例如在集合的Pre-request Script中获取Token并设为全局变量// 集合级Pre-request Script const loginRequest { url: pm.variables.get(base_url) /auth/login, method: POST, header: { Content-Type: application/json }, body: { mode: raw, raw: JSON.stringify({ username: admin, password: admin123 }) } }; pm.sendRequest(loginRequest, function (err, response) { if (!err) { var token response.json().access_token; pm.collectionVariables.set(auth_token, token); // 设置为集合变量 console.log(Token fetched:, token); } });然后在该集合下的其他请求的Headers中就可以使用{{auth_token}}了。实操心得过度依赖复杂的集合级脚本会降低测试用例的独立性。更推荐的做法是将获取Token这类前置操作单独封装成一个“初始化”文件夹或独立的集合在Jenkins中通过多个Newman命令顺序执行或者使用Newman的--folder参数只执行特定文件夹。这样逻辑更清晰也便于排查问题。4.3 报告定制与集成Newman默认的CLI报告在命令行看还行但给团队分享就不够直观。除了之前提到的HTML Publisher插件还有更强大的方案Newman Reporter HTML Extra这是一个社区维护的增强版HTML报告生成器。安装后生成的报告比官方版美观得多带有统计图表、时间线等。npm install -g newman-reporter-htmlextra newman run collection.json -r htmlextra --reporter-htmlextra-export report.html在Jenkins中发布这个report.html体验更佳。与Allure集成Allure是一个强大的测试报告框架。可以安装newman-reporter-allure生成Allure兼容的原始数据然后由Jenkins的Allure插件生成交互式报告。这种报告支持用例分类、历史趋势、附件如图片、日志等非常专业。与钉钉/飞书/企业微信集成当构建失败时除了邮件及时的消息通知更重要。可以在Jenkins中安装对应的插件如“DingTalk Plugin”在Pipeline的post { failure { ... } }阶段或自由风格项目的后置构建操作中配置Webhook将简要结果成功/失败、构建链接、失败用例名推送到群聊机器人。4.4 性能考量与稳定性提升当测试集合很大或需要在多环境下并行执行时需要考虑性能。使用--disable-unicode和--suppress-exit-code--disable-unicode可以加速CLI输出特别是在一些终端环境下。--suppress-exit-code让Newman即使测试失败也返回0退出码这在某些希望继续执行后续步骤如归档报告的流水线中可能有用但通常不建议因为我们需要用退出码判断成败。控制请求并发与延迟--delay-request [ms]可以在请求间加入固定延迟避免对服务器造成瞬时压力。对于需要模拟并发的场景Newman本身是顺序执行的可以考虑用多个Jenkins节点并行执行不同的集合或者使用K6、JMeter等专业的性能测试工具。环境隔离与清理自动化测试尤其是集成测试很容易因为测试数据残留导致后续测试失败。一定要在测试套件的开始Pre-request Script或结束Tests Script中加入数据清理的逻辑比如调用专门的“数据清理”接口或者操作测试数据库。确保每次测试都在一个干净、已知的状态下开始。5. 常见问题排查与调试技巧实录在实际搭建和运行过程中你一定会遇到各种“坑”。下面是我踩过的一些坑和解决方法。5.1 Newman命令执行失败命令未找到或权限不足现象Jenkins控制台输出newman: command not found。排查登录Jenkins服务器直接在命令行执行newman --version确认是否全局安装。如果是在Jenkins的Shell步骤中检查执行用户的环境变量PATH是否包含Node.js的全局安装路径通常是/usr/local/bin或/npm-global/bin。对于自由风格项目可以尝试在构建步骤的最开始使用绝对路径调用newman例如/usr/local/bin/newman run ...。对于Pipeline确保在tools指令中正确指定了Node.js版本或者直接在sh步骤中通过npx newman来调用无需全局安装。解决最稳妥的方式是在Pipeline的sh步骤内使用项目本地的Node.js和npm安装newman并执行。sh cd postman npm init -y # 如果还没有package.json npm install newman --save-dev ./node_modules/.bin/newman run collection.json ... 5.2 测试用例间歇性失败环境与依赖问题现象测试有时成功有时失败错误可能是网络超时、依赖服务未就绪、或数据竞争。排查检查环境确认测试执行时所依赖的后端服务、数据库、中间件等是否处于稳定可用状态。可以在Newman命令前加一个curl或ping命令检查服务健康度。增加重试与超时Newman本身不支持请求重试。对于不稳定的网络或服务可以在Postman的Tests脚本中用pm.sendRequest封装请求并实现简单的重试逻辑。查看详细日志在Newman命令中添加--verbose参数它会输出每个请求的详细信息包括请求头和响应头对于调试鉴权、参数传递问题非常有帮助。数据竞争如果多个Jenkins任务同时运行或者测试用例没有做好数据隔离可能会互相干扰。确保使用独立的测试数据或使用随机数据如Date.now()生成用户名。解决在测试套件开始前增加一个“健康检查”阶段。在Jenkins Pipeline中可以单独设立一个stage(Health Check)使用脚本检查所有依赖服务的端口或健康接口全部通过后才进入测试阶段。5.3 HTML报告无法显示或样式丢失现象通过HTML Publisher插件发布的报告打开后样式混乱只有纯文本。排查这是Jenkins出于安全考虑默认禁止HTML页面加载外部CSS/JS或执行内联脚本。解决进入Jenkins系统管理 - 脚本命令行执行以下Groovy脚本降低安全限制需管理员权限System.setProperty(hudson.model.DirectoryBrowserSupport.CSP, sandbox allow-scripts; default-src none; img-src self data:; style-src self unsafe-inline; script-src self unsafe-inline;)这条策略允许内联样式和脚本相对宽松。请注意这会在一定程度上降低安全性请在内网或可信环境中使用。更安全的方法是使用前面提到的newman-reporter-htmlextra它生成的报告是单个HTML文件所有资源都已内联不受Jenkins CSP策略影响。5.4 如何管理多环境、多集合的复杂配置问题项目有开发、测试、预生产、生产多个环境每个环境对应不同的Postman环境文件。同时测试集合也按模块分成了多个。方案目录结构化在代码仓库中建立清晰的目录。postman/ ├── collections/ │ ├── user_management.json │ ├── order_processing.json │ └── payment_gateway.json ├── environments/ │ ├── dev.json │ ├── test.json │ ├── staging.json │ └── prod.json └── data/ └── test_users.csv使用Jenkins参数化构建在Jenkins任务配置中勾选“This project is parameterized”。添加“Choice Parameter”名称设为TARGET_ENV选项填入dev, test, staging, prod。在Shell构建步骤中就可以动态选择环境文件newman run collections/user_management.json -e environments/${TARGET_ENV}.json ...Pipeline参数在Jenkinsfile的pipeline块顶部定义参数parameters { choice choices: [dev, test, staging, prod], description: 选择测试环境, name: TARGET_ENV }然后在sh步骤中使用params.TARGET_ENV来引用。并行执行对于独立的集合可以在Pipeline中使用parallel阶段并行执行加快整体反馈速度。stage(Parallel API Tests) { parallel { stage(Test User API) { steps { sh newman run collections/user_management.json ... } } stage(Test Order API) { steps { sh newman run collections/order_processing.json ... } } } }5.5 认证与密钥的安全存储问题Postman环境文件中可能包含数据库密码、第三方API密钥等敏感信息。将这些JSON文件明文存放在代码仓库是极不安全的。方案使用占位符在提交到仓库的环境文件中将敏感值替换为占位符如{{db_password}}。利用Jenkins的凭证管理在Jenkins的“凭据”系统中添加“Secret text”类型的凭据将真实的密码粘贴进去并记录其唯一的凭据ID如db-prod-password。在构建时注入在Pipeline中使用withCredentials指令将凭据注入为环境变量。stage(API Test) { environment { // 从Jenkins凭据中读取并赋值给一个环境变量 DB_PASSWORD credentials(db-prod-password) } steps { sh # 在Shell中这个环境变量是存在的 # 我们需要在运行Newman前用真实值替换占位符 sed -i s/{{db_password}}/$DB_PASSWORD/g environments/prod.json newman run ... -e environments/prod.json // 注意sed命令会修改原文件如果介意可以先复制一份。 } }对于自由风格项目可以通过“Inject passwords to the build as environment variables”或使用“Environment Injector Plugin”插件实现类似功能。这样敏感信息只存在于Jenkins Master服务器上实现了安全管控。