第十五章：持续集成中的测试——Jenkins配置、GitLab CI集成、测试结果可视化
说实话，很多团队写单元测试时挺认真的，但一说到「持续集成」，就开始犯怵。我见过不少项目，测试用例写得漂漂亮亮，结果全靠手动跑——那跟没写有啥区别？
持续集成的核心就一句话：代码一提交，测试自动跑，结果看得见。今天我就带你走一遍，怎么把C语言的单元测试真正嵌入到CI流水线里。
15.1 为什么CI对C语言测试尤其重要
C语言项目有个特点：编译环境复杂。你本地能编译通过，换台机器可能就崩了。我在一个嵌入式项目中遇到过，开发机是Ubuntu 18.04，CI服务器是CentOS 7，结果因为glibc版本不同，测试直接跑不起来。
所以，CI不只是「跑测试」，更是环境一致性验证。你想想看，如果每次提交都能在干净环境里重新编译、链接、运行测试，很多隐蔽问题就能提前暴露。
- 保证每次提交都能在标准环境中编译通过
- 自动运行所有单元测试，避免人为遗漏
- 生成测试报告，让团队看到质量趋势
15.2 Jenkins配置：从零搭建C语言测试流水线
Jenkins虽然老，但胜在稳定。我最早用Jenkins 1.x版本，现在2.x的Pipeline语法已经非常成熟了。
15.2.1 安装必要插件
在Jenkins里，你至少需要这几个插件：
| 插件名称 | 用途 |
|---|---|
| Git Plugin | 拉取代码 |
| Pipeline Plugin | 定义流水线 |
| JUnit Plugin | 解析测试结果（支持xUnit格式） |
| Cppcheck Plugin | 静态分析（可选但推荐） |
15.2.2 编写Jenkinsfile
我个人习惯用声明式Pipeline，结构清晰。下面是一个典型的C语言测试流水线：
pipeline {
agent any
stages {
stage('Checkout') {
steps {
checkout scm
}
}
stage('Build') {
steps {
sh 'mkdir -p build && cd build && cmake .. && make -j$(nproc)'
}
}
stage('Unit Tests') {
steps {
sh 'cd build && ctest --output-on-failure -j$(nproc)'
}
post {
always {
junit 'build/test-results/*.xml'
}
}
}
stage('Static Analysis') {
steps {
sh 'cppcheck --xml --xml-version=2 . 2> cppcheck-report.xml'
}
post {
always {
publishCppcheck pattern: 'cppcheck-report.xml'
}
}
}
}
post {
failure {
emailext(
subject: "构建失败: ${env.JOB_NAME} - ${env.BUILD_NUMBER}",
body: "请检查构建日志: ${env.BUILD_URL}",
to: 'team@example.com'
)
}
}
}
--output-on-failure参数非常有用。测试失败时，它会直接打印出失败用例的详细输出，省得你再去翻日志。
15.2.3 测试结果可视化
Jenkins的JUnit插件会自动生成趋势图。你可以在任务页面看到「测试结果趋势」，每次构建的通过率、失败数、跳过数一目了然。
我曾经靠这个趋势图发现了一个问题：某个模块的测试通过率在两周内从98%降到了72%。查下来发现，是有人改了底层数据结构，但没更新对应的mock数据。如果没有趋势图，这种缓慢劣化很难被察觉。
15.3 GitLab CI集成：轻量级替代方案
如果你的团队用GitLab，那GitLab CI是更自然的选择。它跟代码仓库深度绑定，配置起来比Jenkins简单不少。
15.3.1 编写.gitlab-ci.yml
这是我最常用的配置模板：
stages:
- build
- test
- report
build-job:
stage: build
script:
- mkdir -p build
- cd build
- cmake ..
- make -j$(nproc)
artifacts:
paths:
- build/
expire_in: 1 hour
test-job:
stage: test
script:
- cd build
- ctest --output-on-failure -j$(nproc) --test-output-size-passed 0
artifacts:
when: always
reports:
junit: build/test-results/*.xml
report-job:
stage: report
script:
- echo "测试完成，请查看测试报告"
dependencies:
- test-job
when: always。我踩过这个坑——测试失败后想分析日志，结果artifacts根本没上传。
15.3.2 测试结果可视化
GitLab CI原生支持JUnit报告。你只需要在reports: junit里指定路径，Merge Request页面就会自动显示测试通过率。还能看到每个测试用例的执行时间、失败详情。
我个人特别喜欢GitLab的「测试面板」功能。它会把所有失败的测试用例汇总到一个页面，按模块分组。你一眼就能看出哪个模块问题最多。
15.4 测试结果可视化：不止是红和绿
很多人觉得CI可视化就是「构建通过/失败」两个状态。其实不然。好的可视化能帮你回答三个问题：
- 趋势如何？ 测试通过率是在上升还是下降？
- 哪里最脆弱？ 哪个模块的测试经常失败？
- 性能有没有退化？ 测试执行时间是不是越来越长？
下面这张图展示了CI测试流水线的核心流程：
15.5 实战经验：常见坑与解决方案
做CI集成这么多年，我踩过的坑能写满一页纸。挑几个最典型的说说：
我曾经在Jenkins上跑测试，本地全过，CI上全挂。查了两天才发现，CI服务器的gcc版本是4.8，不支持某些C11特性。解决方案：用Docker容器统一环境。
有个同事写了2000个测试用例，每个都做文件I/O。CI跑一次要40分钟。后来我们把纯逻辑测试和I/O测试分开，逻辑测试每次提交都跑，I/O测试每天跑一次。CI时间降到了5分钟。
很多人喜欢在测试脚本里写
./test-results/。但CI的workspace每次构建都可能变。我建议用环境变量或者相对路径，别写死。
15.6 总结
持续集成不是锦上添花，而是质量保障的底线。Jenkins和GitLab CI各有优势，选哪个取决于你的团队规模和技术栈。但不管用哪个，核心思路是一样的：自动化、可重复、可视化。
嗯，最后说一句：别等到项目快交付了才搭CI。从第一个测试用例开始，就把它放进流水线里。你会发现，很多问题在萌芽阶段就被掐死了。
公众号:蓝海资料掘金营，微信deep3321