Jenkins Pipeline 自动化测试调度：代码提交即触发，测试报告自动出

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：

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 触发（推荐）

triggers {

    // 配合 GitHub/GitLab Webhook

    pollSCM('H/5 * * * *')  // 每5分钟检查一次代码变更

}

**实践：配合 Webhook 使用，代码 Push 后秒级触发。

2. 定时触发

triggers {

    cron('0 8 * * 1-5')     // 工作日早8点

    cron('0 20 * * *')       // 每晚8点跑全量测试

}

3. 上游任务触发

triggers {

    upstream(upstreamProjects: 'build-job', threshold: hudson.model.Result.SUCCESS)

}

// 构建成功后自动跑测试

4. 多分支 Pipeline（GitOps 模式）

每个分支自动创建 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 可以把它们串成一条线：

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` 指令控制不同分支跑不同级别的测试，节约资源。

feature 分支：单元测试（2分钟）→ API 测试（3分钟）  总计5分钟

develop 分支：单元测试 → API 测试 → 集成测试       总计15分钟

main 分支：  全量测试（含 UI + 性能）               总计45分钟

> 不是所有测试都要每次跑。分级策略让快反馈和全覆盖兼得。

---

05 通知与报告：测试结果主动找你

测试跑完了，没人看等于白跑。Jenkins 的通知机制让结果主动推送到你面前。

邮件通知：

post {

    failure {

        mail to: 'qa-team@example.com',

            subject: "测试失败: ${env.JOB_NAME} #${env.BUILD_NUMBER}",

            body: "测试报告: ${env.BUILD_URL}allure/"

    }

}

企业微信/钉钉 Webhook：

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 做的事，本质上是把测试流程从"人驱动"变成"代码驱动"。

触发自动化、执行自动化、报告自动化。三步走完，测试就不再是某个人的事，是整个系统的事。

代码提交即测试，测试失败即通知。这不是未来，是现在就应该有的基础设施。