评估自愈系统,核心不是看 “自愈次数越多越好”,而是在降低维护成本的同时,保证测试结果准确可靠,可以从这几个维度衡量:
第一,自愈效率指标。重点统计自愈成功率:即脚本因页面微调失败后,自愈成功、正常跑完用例的占比。同时统计自愈触发总量、假失败减少率,对比接入自愈前后,自动化脚本人工修改次数、QA维护耗时。如果自愈频繁触发,说明前端缺少稳定测试标识,属于产品侧可测性问题,不是自愈系统优秀。还要区分:哪些是合理自愈(元素id、class改动,功能不变),哪些是无效自愈。
第二,测试结果质量指标,这是最关键的。重点监控假通过率:自愈后匹配到错误元素,本该发现bug却显示通过,这是自愈最大风险。同时统计漏报率、误报率,对比自愈开启和关闭时,真实缺陷的捕获能力有没有下降。自愈系统必须完整留存自愈日志,每条自愈记录可追溯,方便人工复核。
第三,稳定性与性能指标。统计自愈带来的额外耗时,单次自愈查找、匹配元素增加的执行时长,避免拖慢CI流水线。评估自愈的资源开销,以及并发执行下自愈模块是否稳定。还要看异常识别准确率:系统能不能分清“定位器失效”和“业务bug”,不要把真实缺陷当成页面改动去自愈。
第四,易用性与运维指标。查看日志、告警是否清晰,是否支持自愈规则配置、黑白名单,允许对高危用例关闭自愈。评估学习能力:多次出现的同类变更,系统能否沉淀规则,后续无需重复自愈。同时评估故障兜底能力,自愈多次失败后,能否正常标记用例失败,而不是卡死。
第五,业务收益综合评估。对比投入产出:节省的脚本维护工时,是否高于复核自愈记录、排查假通过的成本。结合业务场景判断,UI频繁迭代的场景收益更高;核心支付、权限等高风险场景,自愈要严格限制。
简单总结:好的自愈系统,是减少无效维护、不降低缺陷检出能力、可控可追溯,而不是追求尽可能多的自愈。