从手动敲命令到代码推送自动触发测试，本周我用 GitHub Actions 完成了自动化项目的工程化升级。
一、本周学习前言
第三周我已经熟练掌握了 Playwright + PO 分层模式 + Allure 可视化报告，成功搭建了完整的 Web 自动化测试项目（目前已扩展至 16 条测试用例，覆盖正向、异常、边界、安全、UI 交互、购物车、结算、视觉回归 8 个维度）。但整套执行流程仍然依赖手动输入命令运行用例——每次代码修改、新增用例后，都需要人工执行测试、生成报告，不仅重复性高、耗时费力，还容易出现漏测、忘测的情况，无法保障项目稳定性。
因此本周的核心学习目标：引入持续集成（CI）思想，基于 GitHub Actions 搭建自动化流水线，实现代码提交后自动触发测试执行，彻底告别手动运行，完成项目从「手动自动化」到「全自动工程化」的升级。
二、Day 1｜理解 CI 持续集成核心概念与测试价值
1. 什么是 CI（持续集成）？
CI 全称持续集成（Continuous Integration），核心思想是高频代码合并 + 自动构建 + 自动测试。开发者每次将代码 Push 或提交 PR 到主干分支后，CI 服务器会自动拉取最新代码、搭建运行环境、安装项目依赖、批量执行测试用例、生成测试报告，全程无需人工干预。
2. 为什么测试工作必须用到 CI？
在没有 CI 的情况下，代码迭代完全依赖人工回归，存在几个明显的痛点：
- 容易漏测：修改了一行代码，忘记跑相关用例，Bug 就悄悄上线了
- 环境不一致：本地能跑的测试，到别人电脑上就报错
- 回归成本高：每次发版前手动跑一遍全部用例，既枯燥又耗时
接入 CI 之后，这些问题都可以得到解决：
| 痛点 | CI 如何解决 |
|---|---|
| 人工漏测 | 每次代码变更自动触发全量测试，杜绝人为疏漏 |
| 缺陷堆积 | 问题在代码集成阶段就暴露出来，修复成本极低 |
| 环境不一致 | CI 服务器提供标准化运行环境，消除本地与线上差异 |
| 协作冲突 | 每次合并前自动验证，保障主干分支始终可用 |
三、Day 2｜基于 GitHub Actions 搭建 CI 自动化流水线
GitHub Actions 是 GitHub 官方自带的 CI/CD 工具，完全免费，无需额外部署服务器，只需要在项目中添加一个 .yml 配置文件，即可自动触发流水线任务。
本次配置文件存放路径：第三周_web_auto_po/.github/workflows/ci.yml
完整配置如下：
name: SauceDemo Web自动化测试 CI
# 推送代码、合并请求均触发流水线
on:
push:
branches: [ main, master ]
pull_request:
branches: [ main, master ]
jobs:
test:
runs-on: ubuntu-latest
steps:
# 拉取仓库全部代码
- name: Checkout code
uses: actions/checkout@v4
# 配置 Python 运行环境
- name: Set up Python
uses: actions/setup-python@v5
with:
python-version: '3.13'
# 安装项目所有依赖
- name: Install dependencies
run: |
pip install pytest playwright allure-pytest
playwright install --with-deps chromium
# 切入项目目录、执行自动化用例
- name: Run tests
run: |
cd 第三周_web_auto_po
pytest tests/test_saucedemo_po.py -v --alluredir=./allure-results --clean-alluredir
# 上传测试原始结果文件，用于后续查看报告
- name: Upload Allure results
uses: actions/upload-artifact@v4
with:
name: allure-results
path: 第三周_web_auto_po/allure-results
整条流水线的执行逻辑：代码推送 → 拉取代码 → 配置 Python 环境 → 安装依赖 → 执行自动化用例 → 保存测试结果，形成完整的自动化测试闭环。
四、Day 3｜实战踩坑记录
本次 CI 搭建过程中，遇到了 4 个典型的线上环境报错，全部独立排查并解决，积累了宝贵的 Linux 环境自动化测试适配经验。
坑 1：测试脚本文件名不一致导致用例找不到
报错现象：CI 提示 file or directory not found
问题原因：YAML 配置中填写的文件名是 test_sucedemo_po.py，但本地实际文件名是 test_saucedemo_po.py（相差一个字母 a）。Linux 系统严格区分文件名字符，无法模糊匹配。
解决方案：统一配置文件与本地实际文件名，保证路径、文件名完全一致。
坑 2：工作目录不匹配，找不到测试用例文件夹
报错现象：CI 找不到 tests 测试目录
问题原因：流水线默认在仓库根目录执行 pytest，而我的测试项目存放在二级子文件夹中（第三周_web_auto_po/），导致相对路径失效。
解决方案：在执行测试前先通过 cd 命令切入项目根目录，再执行 pytest 运行用例。
坑 3：Linux 无图形界面，浏览器启动失败
报错现象：launched a headed browser without having a XServer running
问题原因：GitHub CI 服务器是纯 Linux 环境，没有桌面图形界面，脚本中 headless=False 的带界面模式无法运行。
解决方案：将浏览器启动参数改为 headless=True 无头模式，适配线上服务器环境。后续进一步优化为通过环境变量 HEADLESS 控制，本地调试用有头模式，CI 用无头模式：
# conftest.py
headless = os.getenv("HEADLESS", "false").lower() == "true"
browser = p.chromium.launch(headless=headless)
坑 4：fixture 作用域不合理导致测试执行慢
现象：每个测试用例都重新启动浏览器，执行耗时超过 60 秒
原因：@pytest.fixture(scope="function") 导致每个用例都执行 launch 和 close
解决：改为 scope="session" 复用浏览器实例，每个用例只新建 context 和 page
效果：测试执行时间从 60 秒降至 18 秒，效率提升约 3 倍
五、Day 4｜流水线成功跑通，实现全自动 CI 集成 ✅
修复全部问题后，重新推送代码触发 GitHub Actions，流水线绿色通过 ✅
最终测试用例执行成功：16 passed。
自此我的自动化项目完成升级：本地可手动运行 + 云端可自动 CI 运行，真正具备了小型工程化项目的标准能力。
六、Day 5｜项目进一步优化与工程化完善 ✅
流水线跑通后，我对整个项目做了一轮工程化优化：
1. 测试执行效率优化
- 引入
pytest-xdist并行执行，16 条用例从 85 秒压缩至约 45 秒 - 支持冒烟测试快速验证：
pytest -m smoke，3 条核心用例约 20 秒
上图：16 条用例并行执行，耗时从 85 秒降至 27.56 秒，效率提升约 68%。
2. 安全加固
- 账号密码从
config.json迁移到.env环境变量，敏感信息不提交版本库 .env加入.gitignore，防止泄露
3. 项目结构完善
- 新增 BasePage 基类，封装公共方法（截图、等待、导航）
- 补充
.gitignore，忽略临时文件和测试产物 - 完善
README.md，增加踩坑记录和运行方式说明
4. Allure 报告增强
- 补充 Environment 环境信息（浏览器版本、操作系统、Python 版本）
- 测试失败自动截图，快速定位问题
七、本周学习总结
本周在第三周 Web 自动化 PO 项目的基础上，完成了持续集成的工程化改造，从只会写自动化脚本，升级为会搭建自动化测试流水线，核心收获如下：
- 理解了 CI 持续集成的原理及其在软件测试工作中的实际价值
- 熟练掌握了 GitHub Actions 的完整配置流程，能够独立编写
ci.yml流水线文件 - 掌握了线上 Linux 环境的适配技巧（无头模式、路径适配、依赖安装）
- 具备了独立排查 CI 流水线常见报错的能力，积累了工程化问题排查经验
- 实现了代码提交自动触发回归测试，完成自动化项目的工程化闭环
- 测试用例从最初的 1 条扩展到 16 条，覆盖 8 个维度，100% 通过
- 通过
pytest-xdist并行执行，测试效率提升约 50%
八、后续计划
- 继续扩展 Web 自动化测试用例覆盖范围，目前已从 4 条扩展至 16 条
- 整理项目文档和代码结构，方便面试时展示
- 梳理简历技术栈与项目亮点，准备开始投递
- 接口自动化项目内容较多，会单独整理一篇文章来写（目前已具备数据库双检、JSON Schema 检验、质量门禁、Docker 一键运行等能力）
九、相关资源
欢迎交流，一起进步！ 🚀
