17｜自动化怎么接入 CI/CD？接入后失败告警怎么处理？

开场先讲接入点设计——不进 CI 的自动化只是个人玩具。

回答思路

第一步：三个触发时机

触发	跑什么	作用
提交触发	冒烟集	分钟级反馈
合并前门禁	核心回归	不过不许合
定时任务	夜间全量 + 趋势	盯慢性漂移

把自动化嵌进研发流程，而不是游离在外。

第二步：讲接入的技术形态

Jenkins 或 GitLab CI 里一个 stage 调用测试仓库的执行入口；容器化运行环境（镜像里装好浏览器和依赖）保证执行环境一致；测试代码和被测代码的版本对齐策略（测哪个分支就跑哪个分支的用例）——这个细节最容易漏。

第三步：讲失败处理的分级逻辑

失败先自动分类：

• 环境类失败（服务起不来、依赖不可用）不算测试失败——直接标基础设施问题，重试或告警运维
• 断言失败才走质量流程

这个分类没做，流水线会被环境噪声淹没，没人再看红色。

第四步：讲告警的降噪

冒烟失败即时推送（群机器人加 @负责人）、夜间全量失败次日汇总报告、连续 N 次失败才升级——告警轰炸的结果是所有人屏蔽群消息。降噪设计和告警本身一样重要。

收尾：讲门禁的松紧哲学

门禁太松拦不住问题，太严误报会阻塞发布伤士气——留 flaky 白名单和紧急跳过机制。门禁要「有牙齿但不咬人」。

考察重点

维度	说明
企业动机	企业要看你能不能把自动化变成研发流程的一部分，以及有没有运营一条流水线的痛感经验
过线标准	多触发时机 + 失败分类（环境和断言分开）
区分度	讲告警降噪、门禁松紧权衡的是被流水线折磨过并解决过的；只讲「Jenkins 配个任务」的是没接深过
加分项	容器化环境和版本对齐策略这两个细节
减分项	所有失败都发群告警，不分类不降噪——流水线活不过三个月

来源

整理自知识星球帖《面试情报 03｜自动化测试 20 题》，返回题库。