夜雨聆风在软件测试向AI驱动转型的过程中，真正的最大障碍并非技术本身，而是管理层的认知固化与旧有考核体系的惯性。
老贺通过一个真实的试点案例，揭示了转型中的典型悖论：AI工具将回归测试从3天压缩至4小时，但管理者的考核指标仍以“用例执行数量”为核心（占比40%），导致工程师不敢减少手工用例，AI工具反而沦为增加工作量的“昂贵摆设”。
老贺通过“五层追问”层层剖析了管理者的阻力根源：
- 路径依赖
：管理者自身的晋升依赖“用例执行效率”等旧指标，否定旧体系等于否定其职业生涯。 - 权力动摇
：新指标（如风险覆盖率）要求管理者从“监督执行”转变为“风险架构师”，这超出了许多人的能力边界。 - 系统性缺失
：组织在引入AI工具后，并未配套更新考核体系与提供试错空间，导致“新工具+旧规则”的割裂。 - 认知落后
：许多管理者对测试的理解停留在“验证功能实现”，而非“暴露系统未知风险”，这决定了他们只会把AI当作加速器而非探索伙伴。
“因为无法被度量的价值，最终被算法定价为零”
mabl《Testing in DevOps Report 2025》亮出一个数据：70%的测试团队已经用上了AI。可你知道Katalon《State of Software Quality Report 2025》同时说了什么吗？55%的团队依然认为测试时间不足是实现质量目标的最大挑战。
新工具没解决老问题。这中间到底丢了哪个关键变量？
一个让我后背发凉的场景
去年，我陪一家大型互联网公司的测试团队做AI测试平台试点。工具选型、培训、上线，一切按部就班。三个月后复盘，你猜怎么着？季度缺陷检出率不但没升，反而降了12%。
团队里那个最先拥抱AI的年轻工程师找到我，满脸委屈：“贺老师，我明明用AI把回归测试从3天压缩到4小时，可领导不看这个。他只看我每天执行了多少用例。”
我顺着这个线索往下挖，发现了一个更扎心的事实：测试总监的考核指标里，“用例执行数量”占了40%的权重。引入AI工具后，工程师们不敢减少手工用例——因为减少了，考核数据就不好看。结果AI工具变成了一台昂贵的摆设，工程师白天跑AI脚本，晚上还得补手工用例。
许多测试管理者本身是‘用例搬运工’出身，他们既得利益依赖于传统度量体系，因此转型的真正障碍不是技术，而是管理层的认知固化。
五层追问，揭开真相
为什么管理者会成为转型的阻力？我用了5层追问，越问越心惊。
第一层：管理者为什么坚持用“用例执行数量”考核？
很简单，因为用例数量可量化、可追踪、可向上汇报。你见过哪个CTO会问“这周团队提出了多少个有价值的质疑”？从来没人这么问。但“这周执行了多少用例”这个问题，从入职问到升总监。
第二层：管理者的职业晋升路径是否依赖这套旧指标？
一个扎心的事实：大多数测试管理者，恰恰是因为“用例执行效率高”、“缺陷发现数量多”才被提拔的。他们的整个职业生涯都建立在这套度量体系上。现在你告诉他这套体系过时了，要用新标准——你等于在否定他过去十年积累的经验。大多数人以为转型的障碍是技术，但真相是：依赖旧体系生存的管理者，本能地抗拒新体系。
第三层：如果新指标被采用，管理者的权力基础会被动摇吗？
会，而且会得很彻底。假如考核指标从“用例执行数”变成“风险覆盖率”，从“缺陷发现数”变成“质疑深度”，那么管理者从“监督执行”的角色，必须变成“指导风险策略”的角色。问题是，很多管理者连“风险覆盖率”怎么算都没想明白，你让他们怎么转型？
第四层：组织提供了管理者转型的试错空间吗？
几乎没有。大多数组织的逻辑是：引入AI工具→保持原有考核体系→期望效率提升。这就像一个教练要求运动员换新装备，但比赛规则和评分标准不变。新装备反而成了累赘。
第五层：管理者自身的认知模型是否还停留在“监督执行”？
这是最致命的一层。我见过太多测试管理者，把“管理”等同于“盯着下属干活”。他们对测试的理解，停留在“验证功能是否实现”这个层面，而不是“暴露系统在未知边界下的非预期行为”。
测试的本质不是验证功能是否实现，而是暴露系统在未知边界下的非预期行为。
这个认知差距，决定了管理者对AI的态度。如果是前者，AI就是个加速器，更快地执行更多用例；如果是后者，AI就是个探索伙伴，帮助人类发现从未想到的盲区。
数据不会说谎
为了验证这个发现，老贺对比了两组数据。
完全采用DevOps的组织里，65%在开发中使用AI，70%在测试中使用AI（来源：mabl, Testing in DevOps Report 2025）。这些组织的管理者，更倾向于把自己定位为“风险架构师”——他们关注的是系统的整体质量策略，而非单个用例的执行效率。
而传统组织里，73%的受访者在CI/CD工作流中完全不使用AI（来源：JetBrains, State of CI/CD 2025）。这些组织的管理者，更倾向于固守“用例搬运工”的定位——他们关注的是下属今天跑了多少测试用例、发现了多少缺陷。
这个差异不够明显吗？
再看另一个数据：51.53%的测试者让最终用户参与测试过程，只有4.9%从不这样做（来源：Katalon, State of Software Quality Report 2025）。那些敢于让最终用户参与测试的团队，管理者的认知水平明显更高——他们理解“质量不是测出来的，是用出来的”。
而82%的QA从业者认为AI在未来3-5年内将变得重要（来源：Katalon, State of Software Quality Report 2025），但73%的团队在CI/CD中完全不使用AI。这82%和73%之间的巨大鸿沟，不就是管理者认知固化造成的吗？
回应反对意见
我知道有人会反驳：“老贺，你说得太绝对了。管理者也是被逼的，上面要数据，下面要考核，他们能做啥？”
我承认这个反驳有道理。管理者确实处在夹缝中，上有决策层的高压，下有团队的执行压力。但问题恰恰在这里——系统惯性比技术落后更可怕，因为它把创新者拉回原点。
一个测试总监，如果他只能在“用例执行数”和“缺陷发现数”之间做选择题，那他确实没办法。但如果他主动向上级提出一套新的度量体系呢？
比如，把“风险覆盖率”作为核心指标，把“质疑深度”纳入能力评估，把“AI辅助效率提升”作为团队目标——这些不是做不到，而是管理者愿不愿意做。
还有人会说：“AI工具还不够成熟，不能完全替代手工测试。”
我同意。AI确实有它的局限——它依赖训练数据的分布，无法覆盖长尾场景中的新型失效模式；它可能产生共谋偏差，所有代理共享同一套世界观，漏掉跨界破坏。
但这个问题恰恰证明了管理者的转型必要性。如果AI学会质疑，人类可以与其协作形成‘质疑链’，而非对立。人类负责元质疑，AI负责执行层质疑。
管理者需要做的，不是决定“用不用AI”，而是设计“人和AI怎么分工协作”的新模式。
预测未来12-18个月，会发生什么？
AI测试自动化市场预计到2032年将达到359.6亿美元，复合年增长率21.8%。当市场压力迫使组织必须采用AI时，那些固守旧度量体系的管理者会面临两种选择。
第一种：完成自我革命，成为“风险架构师”。
主动学AI工具，重新定义测试策略，建立新的度量标准。这类管理者会带领团队实现真正的效率飞跃，成为组织的质量护城河。
第二种：被更高效的系统淘汰。
不是被AI直接淘汰，而是被那些拥抱新度量体系的团队和组织淘汰。当一个团队能用AI把回归测试从3天压缩到4小时，同时把风险覆盖率从60%提升到90%，那个还在用“用例执行数”考核的管理者，你觉得他还能撑多久？
但有一个值得警惕的趋势：一些管理者会选择“伪转型”。
引入AI工具，但不改变考核指标。AI跑出来的结果没人看，手工用例照常执行，团队工作量翻倍。这是最糟糕的情况——花了钱，费了力，什么都没得到。
管理者不转型，AI工具只是昂贵的摆设。
我的预测是：未来12个月内，我们会看到两种模式的明显分化。那些敢于重新定义考核标准的管理者，其团队质量指标会明显优于那些只换工具不换体系的管理者。具体来说，前者的缺陷逃逸率至少会下降30%，后者可能反而上升10%以上。
这个预测是可验证的。如果你所在的组织正在引入AI测试工具，留意一下：6个月后，考核指标变了吗？如果没变，你大概率会看到“伪转型”的结果。
你现在最应该做什么？
对于测试工程师，我给你的建议是：不要等管理者转型。
你可以主动提出新的度量提案，用“风险覆盖率”和“质疑深度”等新指标，倒逼管理者重新定义考核标准。当你说“我用AI把回归测试从3天压缩到4小时”时，别忘了补一句：“这4小时我用来做边界探索和异常场景测试，发现了3个以前从未注意到的问题。”——这才是新体系下真正的价值。
对于管理者，我的建议更直接：发起一次“管理者转型工作坊”。亲身体验AI工具，然后回答一个问题：转型的起点不是学AI，而是让管理者学会放弃旧尺子。
对于软件测试行业，老贺呼吁：联合推动测试度量体系的标准变革。把“质疑能力”纳入核心能力模型，把“风险覆盖率”纳入考核标准。只有从系统层面改变度量体系，个人转型才能规模化落地。
最后，说一句心里话。
老贺做了快30年测试，见过太多技术变革。每次变革，真正的障碍从来不是技术本身，而是那些依赖旧体系生存的人。AI测试工具不会淘汰测试工程师，但那些固守旧度量体系的管理者，一定会。
因为无法被度量的价值，最终会被算法定价为零。 而测试的核心价值——质疑、探索、暴露盲区——如果管理者不敢重新度量它，它就会在组织的考核体系里消失，然后被市场淘汰。
这不是危言耸听。这是过去三十年，每个技术变革周期的铁律。
领测老贺
30年软件测试老兵 | ISTQB CT-GenAI测试本地化工作组组长专注AI时代的软件测试方法论与实践
AI测试自动化测试质量保障
