测试管理者的噩梦：AI按“业务风险”自动排期，把两个老员工的活全优化了

当效率工具变成裁员加速器，我经历了最纠结的三周

大家好，我是某互联网公司质量保障团队的负责人，手下管理着20多人的测试团队。

今天聊一个让我至今都不太舒服的经历——我们上线了一套AI测试排期系统，它“理性”地把两个老员工的工作内容判了死刑。

不是标题党。这件事发生在去年年底，整个过程只有三周。

一、故事的起点：提效，还是提效

2024年Q4，公司开始大谈“降本增效”。我们测试团队也不例外——老板的目标很明确：在不降低质量的前提下，把人效提升30%。

我们梳理了一下测试流程，发现最耗时的环节是“测试排期”。

每次版本迭代，测试经理都要花1-2天手动排期：评估每个模块的变更影响范围、判断风险等级、分配测试资源、排定执行顺序。涉及十几个开发团队的代码变更、几十个业务模块、几百条用例，全靠人工判断和经验积累。

于是我们立项做了一个AI测试排期系统：

• 输入：本次迭代的代码变更、历史Bug数据、业务调用链路
• AI分析：每个模块的变更风险、受影响范围、历史故障概率
• 输出：自动生成测试优先级排期——高风险的先测、多测，低风险的后测、少测

原理不复杂，但效果确实好。系统上线后，**排期时间从2天压缩到了15分钟，高风险场景的测试覆盖率提升了25%**。

老板很高兴。

但问题也来了。

二、转折：AI说“这两个人的活可以砍掉”

系统跑了三周，我们开始用它来做测试资源分配优化——把AI的排期结果和实际的测试人力投入做对比，找出“投入产出比低”的工作内容。

结果AI给了一份让所有人都尴尬的报告。

报告显示，测试团队里有两类工作被标记为“低业务风险-高时间投入”：

第一类：老张的“全量回归”

老张，38岁，入职8年，是团队里最资深的测试工程师。他的核心工作就是每个版本跑全量回归——所有用例从头到尾过一遍，确保没有历史功能被破坏。

AI的分析结果是：过去6个月，老张负责的回归测试模块零故障。不是他测得好，而是这些模块已经18个月没有代码变更了。

AI的结论：“这部分回归测试的边际收益趋近于零，建议调整为按需执行，释放70%的人力。”

第二类：老李的“手工兼容性”

老李，42岁，入职10年。他最擅长的是手工兼容性测试——在不同品牌手机、不同系统版本上人工验证UI适配。

AI的分析结果是：这部分工作已经被自动化兼容性测试工具覆盖了92%。而且自动化工具的执行速度是手工的15倍，覆盖设备数量是手工的8倍。

AI的结论：“建议将剩余8%的边缘场景纳入自动化，该岗位工作内容可被完全替代。”

报告里没有写“建议裁员”，但字里行间的意思谁都看得懂。

三、尴尬的沉默

我拿到报告的时候，是周五晚上10点。

我一个人在办公室坐了很久。数据摆在那里，AI的推理逻辑没毛病——从纯理性的角度看，老张和老李的工作确实存在“优化空间”。

但他们是跟着我干了这么多年的人。

• 老张是我入职那年就在的老员工。当年App上线前夜发现了一个严重的内存泄漏，是他通宵排查定位的。
• 老李是全团队最懂Android碎片化的人。哪款国产手机的WebView有坑、哪个系统版本有兼容性问题，他脑子里有一张活地图。

这些价值，AI的报告里一个字都没有写。

我不知道该怎么跟老板开口，更不知道该怎么跟老张和老李开口。

四、硬着头皮推进的结果

周一，老板找我开会：“那份报告看了吧？说说你的想法。”

我说了我的顾虑。

老板说了一句让我很难反驳的话：“公司要活下去，每个人都要证明自己的价值。AI只是把问题提前暴露了，不是制造了问题。”

这句话站在管理者的角度没有错，但我还是争取到了两个缓冲方案：

• 给老张和老李3个月转型期，从执行岗转向“测试策略设计+AI工具训练”
• 在此期间，薪资和职级维持不变，由团队提供系统的AI测试技能培训

然后我分别找老张和老李聊了。

老张沉默了很久，最后说了一句：“我知道这一天迟早会来。 ”

老李的反馈更直接：“我来公司10年，你让我从头学AI？你觉得我学得动吗？ ”

那场对话是我职业生涯里最艰难的一次。

三个月后，老李还是走了。老张留了下来，现在在负责AI测试用例的训练数据标注，做得还不错——他的业务经验在这里派上了用场。

但这三个月的过程，对所有人都是一种消耗。

五、复盘：问题到底出在哪？

事情过去半年了，我一直在想这个问题。

AI的判断确实“理性”，团队也确实“提效”了——测试人效提升了28%，版本发布周期缩短了2天。老板满意，数据好看。

但我心里始终觉得，这个过程中我们做错了一些事。

错误一：把“测试排期系统”扩展成了“资源优化系统”

初衷是做“排期提效”，跑着跑着变成了“人力优化”。

这两个目标的性质完全不同。前者是用AI解放生产力，后者是用AI替代人。当工具的边界被悄然扩大，风险就不是技术问题了。

错误二：忽略了隐性知识的价值

老张和老李的价值，不在他们“做了什么”，而在他们“知道什么”。

• 老张知道哪个模块历史上出过什么诡异问题
• 老李知道哪款手机的某个特定系统版本有特殊行为

这些知识不在代码里、不在文档里，在他们的脑子里。AI可以替代他们的“操作”，但替代不了他们的“经验”。

等这些人走了，这些隐性知识也就跟着走了。

错误三：没有提前做技能规划

我们上线AI系统的时候，没有同步规划团队成员的技能转型路径。

• 老张这样的老测试员，未来应该做什么？
• 手工测试的同学，怎么转成AI测试工程师？
• 哪些岗位会被替代，哪些岗位会新增？

这些问题的答案，系统上线两个月后才开始想——已经太晚了。

错误四：数据指标过于简化

AI判定老张的工作“低风险”，依据是“过去6个月零故障”。

但这个“零故障”本身，正是因为他每个版本都在做全量回归——他查得那么细，才没让问题漏到线上。把“没发现问题”等同于“工作没价值”，在逻辑上是一个致命的谬误。

用结果倒推行为的价值，尤其在质量保障这个领域，是非常危险的思维。

六、这件事之后的三个改变

经历这件事之后，我对“AI+测试管理”有了新的思考。我做了三个改变：

改变一：明确AI的边界——它做“排期”，人做“决策”

AI的输出不再是“指令”，而是“参考”。

现在的流程是：

• AI生成排期建议 → 测试经理review → 根据实际情况调整 → 最终确认

AI可以告诉你“哪个模块风险高”，但“谁来测、测多久、能不能砍掉”——这些决策必须由人来做。

改变二：建立“技能转型通道”

在推动AI工具落地的同时，同步规划人员转型路径：

• 手工测试 → AI测试训练师（教AI怎么测）
• 脚本维护 → 测试工具开发（帮AI搭平台）
• 用例编写 → 测试策略设计（告诉AI测什么、为什么测）

每个人都有一个明确的转型方向和时间表。

改变三：重新定义“老员工的价值”

老员工的经验不能被AI替代。我们的做法是让他们转型成“AI训练师”：

• 标注高质量数据
• 定义“什么是好用例”
• 验证AI生成结果的准确性
• 补充AI覆盖不到的边缘场景

这些工作AI干不了，但老员工干得很好。

七、给同行的一些话

如果你正在测试团队引入AI，我有几点实在的建议：

1. 不要用AI来做“对人的判断”

AI可以判断“这段代码的风险”，但不要让它去判断“这个人的价值”。

数据和指标是冰冷的，人的价值是多维的——经验、判断力、团队协作、隐性知识——这些AI看不到。

2. 在系统上线之前，先想好“人往哪里去”

技术落地之前，先做好人力规划。

如果某些岗位会被AI替代，这些人应该转去哪里？需要什么培训？转型周期多久？这些问题应该在项目启动时就回答，而不是上线之后。

3. 保护好团队的信任感

用AI“优化掉”同事的消息一旦传开，整个团队的士气会崩塌。

大家会觉得：“下一个是不是我？”然后人心涣散，能跑的都会跑。

宁可慢一点，也不要把效率工具变成恐慌制造机。

4. 把“隐性知识”记录下来

在老同事转型之前，花时间把他们脑子里的经验系统性地沉淀下来：

• 业务的坑点清单
• 历史故障的完整复盘
• 边缘场景的手工测试手册

这些不是“老员工应该做”的事，而是“管理者应该组织做”的事。

最后

AI不会让测试这个岗位消失，但会让某些工作方式消失。

作为一个管理者，我的责任不是“用AI省钱”，而是“带着团队走过这场变革”。让留下的人有成长，让走的人有尊严——这是我在这场经历之后给自己的要求。

工具是冷的，人是热的。效率是硬的，信任是软的。

做一个好的管理者，就是要在这两者之间找到平衡。

本文系作者基于真实经历的复盘总结。文中人名已做脱敏处理，欢迎同行交流讨论。