自动化可行性判断是什么
自动化可行性判断决定一条用例是否值得自动化：看执行频率、稳定性、回报周期与维护成本，而不是「能写脚本就自动化」。每次构建都要回归的稳定场景通常是优先项；一次性探索或界面频繁改版的场景，维护成本可能超过收益。
基本信息
| 执行频率 | 每次构建都要回归的优先自动化 |
|---|---|
| 稳定性 | 需求与界面稳定适合；频繁改版要谨慎 |
| 复杂度 | 步骤确定、断言明确适合；依赖人工判断不适合 |
| 维护成本 | 定位稳定、依赖可控才能长期存活 |
| 汇报口径 | 看自动化覆盖的回归价值，不看脚本数量 |
判断维度
| 维度 | 倾向自动化 | 倾向手工 |
|---|---|---|
| 执行频率 | 每次构建都要回归 | 一次性或低频验证 |
| 稳定性 | 需求与界面相对稳定 | 界面与流程频繁改版 |
| 复杂度 | 步骤确定、断言明确 | 依赖人工判断与探索 |
| 维护成本 | 定位方式稳定、依赖可控 | 强依赖第三方与真实数据 |
典型使用场景
- 回归套件规划：按频率与稳定性挑出第一波自动化对象。
- 投资评估：估算脚本寿命与维护工时，算清回报周期。
- 探索式测试：保留人工发挥空间，不做机械化替代。
- 老旧脚本审计：清理已失去价值的自动化脚本。
- 汇报改进：用回归时长与缺陷拦截率替代脚本数量。
- 分层选择：接口层优先自动化，界面层只留关键路径。
Google Testing Blog 对「什么都自动化」持保留态度：端到端脚本的维护成本常被低估。
判断结果要留档：每条「暂不自动化」的用例注明原因与复查条件，避免反复讨论。
把不稳定的界面用例塞进 CI 门禁，会制造持续红灯与「习惯性忽略」。