01 为什么 Jenkins 是测试自动化的必选项
测试自动化的完整链条是：写测试 → 跑测试 → 看报告 → 修问题 → 再跑。
大多数团队卡在第二步：测试写好了，但跑测试需要人手动执行。结果就是——测试有了但没人跑，等于没有。
Before：测试工程师每天手动执行测试脚本，导出报告，发到群里。一天花2小时在"跑测试"这个动作上。
After：Jenkins Pipeline 配好后，代码一提交自动触发，测试自动跑，报告自动发。2小时变0。
Jenkins 在测试自动化中的三个核心价值：
| 价值 | 说明 | 效果 |
|---|
| 自动触发 | Git Push / 定时 / API 调用 | 代码提交即测试，0延迟反馈 |
| 流水线编排 | 串联测试、构建、部署步骤 | 全流程自动化 |
| 报告集成 | Allure / JUnit / HTML 报告 | 测试结果可视化、可追溯 |
Jenkins 不是测试工具，是调度中心。它不写测试，它让测试自己跑起来。
---
02 Pipeline 基础：声明式流水线
Jenkins Pipeline 有两种语法：声明式（Declarative） 和 脚本式（Scripted）。推荐声明式，结构清晰，上手快。
一个完整的测试 Pipeline：
groovy
pipeline {
agent any
// 定时触发：每天早上8点 + 手动触发
triggers {
cron('0 8 * * 1-5') // 工作日早8点
}
// 参数化：可以选择测试模块
parameters {
choice(name: 'TEST_MODULE', choices: ['all', 'api', 'ui', 'performance'], description: '选择测试模块')
string(name: 'ENVIRONMENT', defaultValue: 'staging', description: '目标环境')
}
environment {
PYTHON_HOME = 'C:\\Python312'
TEST_RESULTS = 'test-results'
}
stages {
stage('环境准备') {
steps {
echo "准备测试环境: ${params.ENVIRONMENT}"
bat 'pip install -r requirements.txt'
}
}
stage('执行测试') {
steps {
bat "pytest tests/${params.TEST_MODULE}/ --junitxml=${TEST_RESULTS}/report.xml --alluredir=${TEST_RESULTS}/allure-results"
}
}
stage('生成报告') {
steps {
junit "${TEST_RESULTS}/report.xml"
allure includeProperties: false, jdk: '', results: [[path: "${TEST_RESULTS}/allure-results"]]
}
}
}
post {
always {
archiveArtifacts artifacts: "${TEST_RESULTS}/**/*", fingerprint: true
}
success {
echo '测试全部通过！'
}
failure {
echo '测试失败，请检查报告。'
// 发送钉钉/企业微信通知
}
}
}
Pipeline 就是测试的剧本。写好了，Jenkins 按剧本演，每场都一样，不会忘词。
---
03 触发策略：什么时候跑测试
Pipeline 写好了，下一步是决定什么时候触发。触发策略直接影响反馈速度和资源消耗。
四种触发方式：
1. Git Push 触发（推荐）
groovy
triggers {
// 配合 GitHub/GitLab Webhook
pollSCM('H/5 * * * *') // 每5分钟检查一次代码变更
}
最佳实践：配合 Webhook 使用，代码 Push 后秒级触发。
2. 定时触发
groovy
triggers {
cron('0 8 * * 1-5') // 工作日早8点
cron('0 20 * * *') // 每晚8点跑全量测试
}
3. 上游任务触发
groovy
triggers {
upstream(upstreamProjects: 'build-job', threshold: hudson.model.Result.SUCCESS)
}
// 构建成功后自动跑测试
4. 多分支 Pipeline（GitOps 模式）
text
每个分支自动创建 Pipeline：
- feature/xxx 分支：跑该分支相关的单元测试
- develop 分支：跑集成测试 + API 测试
- main 分支：跑全量测试（单元 + 集成 + API + UI + 性能）
Before：测试什么时候跑？看测试工程师有没有空。有空就跑，没空就拖。
After：代码提交自动触发，开发提交代码后5分钟内就知道有没有测出问题。
| 触发策略 | 适用场景 | 反馈速度 |
|---|
| Git Push | 功能分支 | 秒级 |
| 定时执行 | 全量回归 | 固定周期 |
| 上游触发 | 构建→测试串联 | 依赖上游 |
| 手动触发 | 紧急验证 | 即时 |
触发策略的核心原则：测试离代码变更越近，修 bug 的成本越低。
---
04 多测试框架集成：一个 Pipeline 跑全部
真实项目中不会只用一种测试框架。单元测试用 JUnit，API 测试用 Postman/Newman，UI 测试用 Selenium，性能测试用 JMeter。
Jenkins Pipeline 可以把它们串成一条线：
groovy
pipeline {
agent any
stages {
stage('单元测试') {
steps {
bat 'mvn test'
}
post {
always { junit 'target/surefire-reports/*.xml' }
}
}
stage('API测试') {
steps {
bat 'newman run collections/api-tests.json -e staging.json --reporters cli,junit --reporter-junit-export api-results.xml'
}
post {
always { junit 'api-results.xml' }
}
}
stage('UI测试') {
when {
branch 'main' // 只在主分支跑UI测试（耗时较长）
}
steps {
bat 'pytest tests/ui/ --junitxml=ui-results.xml'
}
post {
always { junit 'ui-results.xml' }
}
}
stage('性能测试') {
when {
branch 'main'
}
steps {
bat 'jmeter -n -t perf-test-plan.jmx -l perf-results.jtl'
}
}
}
}
关键技巧：用 when 指令控制不同分支跑不同级别的测试，节约资源。
text
feature 分支：单元测试（2分钟）→ API 测试（3分钟） 总计5分钟
develop 分支：单元测试 → API 测试 → 集成测试 总计15分钟
main 分支： 全量测试（含 UI + 性能） 总计45分钟
不是所有测试都要每次跑。分级策略让快反馈和全覆盖兼得。
---
05 通知与报告：测试结果主动找你
测试跑完了，没人看等于白跑。Jenkins 的通知机制让结果主动推送到你面前。
邮件通知：
groovy
post {
failure {
mail to: 'qa-team@example.com',
subject: "测试失败: ${env.JOB_NAME} #${env.BUILD_NUMBER}",
body: "测试报告: ${env.BUILD_URL}allure/"
}
}
企业微信/钉钉 Webhook：
groovy
post {
always {
script {
def status = currentBuild.currentResult
def message = status == 'SUCCESS' ?
"✅ ${env.JOB_NAME} #${env.BUILD_NUMBER} 测试通过" :
"❌ ${env.JOB_NAME} #${env.BUILD_NUMBER} 测试失败"
bat "curl -X POST -H 'Content-Type: application/json' -d '{\"msgtype\":\"text\",\"text\":{\"content\":\"${message}\"}}' ${WEBHOOK_URL}"
}
}
}
Allure 报告（推荐）：
- ►自动生成趋势图、失败截图、步骤详情
- ►支持历史对比，一眼看出哪些用例变差了
- ►嵌入 Jenkins 面板，打开就能看
Before：测试结果存在本地文件里，领导问"测试跑了吗？"答不上来。
After：每次执行自动发通知，报告链接一键打开，历史趋势清晰可见。
好的测试报告不是一堆数字，是一个决策依据。通过就是通过，挂了在哪挂的，一清二楚。
---
Jenkins Pipeline 做的事，本质上是把测试流程从"人驱动"变成"代码驱动"。
触发自动化、执行自动化、报告自动化。三步走完，测试就不再是某个人的事，是整个系统的事。
代码提交即测试，测试失败即通知。这不是未来，是现在就应该有的基础设施。
声明：本站部分稿件版权来源于网络，如有侵犯版权，请及时联系我们。
京公网安备
11010802035719号
