Selenium 这些年很容易被一句话概括掉：老、重、没有 Playwright 顺手。这个评价不完全错，但也太粗。 更贴近实战的判断是，Selenium 的核心问题不是“不能做 UI 自动化”，而是它对工程纪律的要求高很多。等待写不好、页面分层做不好、失败留痕做不好，它就会显得特别脆；但如果项目已经基于它沉淀了大量资产，贸然推翻重写，也未必是最优解。 所以我一直不把 Selenium 当成“应该立刻淘汰的老框架”，而是把它看成：在历史...
第一次做 UI 自动化时，容易陷入一个非常自然但代价很高的误区：既然浏览器也能自动点，那就把所有核心功能都录进去、跑起来。结果往往是： 第一版看起来很热闹 第二个月开始大量修脚本 第三个月团队开始说 UI 自动化不靠谱 问题通常不在工具，而在场景选择。UI 自动化从来不是“能测的都测”，而是“哪些业务路径值得用最贵的验证方式去测”。因为和接口自动化相比，UI 自动化天然更慢、更脆、更依赖页面结构，也更依赖等待、账号、数据和浏览器环境。 ...
在把测试平台接入发布流水线之后，最初看到的通常是效率收益： 提测后可以自动触发回归 合并后可以自动触发冒烟 发布前可以自动执行关键校验 失败后可以自动发通知 但只要平台和流水线开始长期协同，真正的问题很快就会暴露出来： 平台显示任务仍在执行，流水线却已经结束 流水线已经放行，平台里的测试报告还停留在旧结果 某个发布经理可以在流水线里点继续，却无法在平台里看到完整证据 测试平台里把任务判成环境失败，流水线里却把同一次执行算成发布阻塞 一次...
在测试逐步平台化、自动化逐步接入交付链路之后，会遇到一个非常现实的变化： CI/CD 不再只是研发的发布工具，而开始变成质量门禁、环境校验、回归执行和结果收敛的主链路。 一旦测试团队开始真正接手这条链路，最容易犯的错误不是技术不会，而是顺序错了。 常见失控方式通常是这样的： 先把大量测试脚本塞进流水线 先追求全链路自动化 先追求发布阻塞能力 先追求覆盖率报表和大盘 这些动作单看都没错，但如果能力底座没有先补齐，后面几乎一定会出...
在把测试平台、Jenkins、定时巡检和发布回归逐步接起来之后，都会经历一个表面上很省事、后面却越来越乱的阶段： 所有任务都做成 Jenkins Job 或统一流水线入口 定时巡检和发布回归共用一套参数模板 构建任务失败、回归失败、巡检失败都统一显示为一次流水线失败 白天发布高峰和夜间巡检窗口共用同一批执行节点 告警渠道不分类型，任何失败都直接推到同一个群 这套方式最开始看起来没有问题，因为所有东西都能跑起来。 但只要任务数量上来，治理...
Jenkins Pipeline 在 里都不是从设计开始失控的，而是从“先能跑起来”开始失控的。最初只有几个阶段，编译、测试、打包、部署看起来都不复杂。随着项目增多、环境增多、分支策略变化、测试链路加长、通知和回滚逻辑不断叠加，Pipeline 很容易从一条可读的交付链路，变成一大段难以理解、难以修改、难以复用的脚本集合。 真正难维护的 Pipeline，通常不是功能不够，而是职责边界混乱。有人把环境判断塞进每个阶段，有人把业务参数和构...
把自动化测试接入 CI/CD，最开始理解成下面这件事： 代码提交后触发流水线 流水线执行测试脚本 失败了就阻塞发布 这套理解并不算错，但它只覆盖了最表层的“能跑起来”。 真正开始长期使用后，问题通常会集中暴露： 流水线里能跑，本地却复现不了 同一套测试脚本，白天稳定，晚上频繁误报 构建时间越来越长，发布节奏越来越慢 测试失败后没人能快速判断是代码问题、环境问题还是测试自身问题 发布前明明做了自动化校验，线上还是出了本该被提前拦...
在把自动化测试、定时巡检和发布回归逐步接起来之后，最容易出现的一种局面是： Jenkins 既负责触发，又负责参数输入 Jenkins 既负责跑任务，又负责展示结果 Jenkins 既负责定时，又负责权限判断 Jenkins 既负责流水线，又负责告警通知 短期看，这种方案很顺。 因为只要把 Job 配起来，接口自动化、UI 回归、巡检脚本、发布前校验都能很快跑起来。 但只要任务类型开始变多，问题会迅速积累： 平台里看到的是一次“回归任务...
质量问题最容易出现一种假象： 问题提出来了 群里也同步了 研发也回复会处理 下一版看起来也修过了 但过一段时间，同类问题又会以新的表现方式重新出现。 这说明问题并没有真正收敛，只是被阶段性压下去了。 测试负责人在这类场景里的职责，不是多开几次会，也不是把问题单催得更紧，而是把问题从“被发现”推进到“被验证修复、被纳入约束、被防止复发”。 这篇文章只讨论一个核心问题： 测试负责人如何从工程治理角度推动质量问题真正收敛，而不是长期停留在提单...
并不缺监控、巡检、告警和回归。 真正缺的是把这四件事组织成一条可信的质量闭环。 常见现场通常是这样的： 监控平台能看到波动，但没人知道该不该拦版本 巡检脚本每天都在跑，但失败后只能再看一次 告警渠道接了很多，群消息却越来越没人看 回归体系也存在，但和线上问题、巡检失败、历史高风险点并没有真正挂起来 最后的结果是： 问题被发现了，但没有被收敛 问题被通知了，但没有被接住 问题被修掉了，但没有进入长期防回归链路 所以这篇文章不讨论“监控有没...