云效用例驱动的自动化回归流水线

为什么做

人工执行有三个后果：慢、不一致、结论没有沉淀。测试平台里存着用例，本地 Excel 里存着另一份，跑完的结果 靠人抄进缺陷单，下一次回归还得从头来一遍。

怎么做的

读云效测试计划
   ↓
按用例类型分流执行
   ├─ 接口  → shell 脚本（可独立复现的 curl 用例）
   ├─ Web  → Playwright（复用登录态，选择器定位）
   └─ 小程序 → 微信 CLI（automator / debugger，元素级定位）
   ↓
逐条回写状态（PASS / FAILURE / POSTPONE）
   ↓
失败 → 云效创建缺陷工作项（自动取用例负责人 + 关联用例）
   ↓
产出 junit.xml / report.html / summary.md

两个关键决定

不用坐标点击 / 图像识别。 一开始考虑过 RPA 式的做法，但它的失败率会随分辨率和主题变化而漂移，看起来 “能跑”，实际不可维护。全部改成 CLI + 代码化选择器，失败就是真失败。

不追求 100% 覆盖。 无法自动化的用例显式回写 POSTPONE 并在报告里列出——宁可让缺口可见，也不要让 “通过率”好看而失真。

环境预检

第一版跑完拿到成批失败，排查发现是测试环境本身没起来。后来在三个执行器入口都加了预检：服务可达、数据库 可连、小程序构建产物存在，任一项不通过就快速失败并说明原因，避免把环境问题误报成业务缺陷。

结果

一条命令跑完三端，结果直接落在测试平台里，缺陷自动带证据。回归从“安排一个人做两天”变成“改完顺手跑一次”。