小王刚改完一个登录页的样式，顺手提交了代码。五分钟后，他收到一封邮件——‘构建失败，UI自动化测试发现按钮点击无响应’。他赶紧回看代码，果然漏掉了事件绑定。这不是科幻场景，是很多团队每天都在用的 Jenkins + 自动化测试组合。
为什么非得搭这个‘自动检查员’？
手动点一遍登录、注册、忘记密码……测三遍就手酸；换浏览器再测一遍？时间直接翻倍。而 Jenkins 就像一个不知疲倦的值班程序员，只要代码一推到 Git，它立刻拉下来、编译、跑测试、发报告，整个过程不用人盯屏。
三步搭个能跑测试的流水线
假设你用的是 Python + pytest 做 Web 自动化测试，ChromeDriver 已装好，项目结构长这样：
my_project/
src/
tests/test_login.py
requirements.txt在 Jenkins 新建任务，选‘自由风格项目’，配置里加几步：
1. 拉代码
源码管理选 Git，填上你的仓库地址和分支（比如 main）。
2. 装依赖 + 跑测试
构建步骤选‘执行 shell’，写这几行：
pip install -r requirements.txt
export DISPLAY=:99
pytest tests/ -v --html=report.html --self-contained-html注意：如果 Jenkins 是 Linux 服务器且没桌面环境，得先启动虚拟显示（xvfb-run -a pytest ... 或提前配好 xvfb）。
3. 看结果
装个 HTML Publisher 插件，把 report.html 作为测试报告发布。每次构建完点进去，就能看到哪条用例红了、截图在哪、控制台输出啥——比翻日志快多了。
不是所有测试都适合塞进 Jenkins
冒烟测试、核心流程回归（比如下单→支付→发货）建议每次提交都跑；而全量兼容性测试（IE11、Safari旧版等）可以设成每天凌晨跑一次。别让流水线卡在‘等 Safari 启动’上。
有次我们把截图路径写死在 C:\tmp，结果 Jenkins 在 Linux 上跑崩了。后来统一改成 os.path.join(os.getcwd(), 'screenshots')，再配合 mkdir -p，问题当场消失。