测试管理者的噩梦：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测试、大模型评测、质量保障感兴趣吗？我们建了一个 「人工智能测试开发交流群」，专门用来探讨相关技术、分享资料、互通有无。无论你是正在实践还是好奇探索，都欢迎扫码加入，一起抱团成长！期待与你交流！👇

四、硬着头皮推进的结果
周一，老板找我开会：“那份报告看了吧？说说你的想法。”

我说了我的顾虑。

老板说了一句让我很难反驳的话：“公司要活下去，每个人都要证明自己的价值。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省钱”，而是“带着团队走过这场变革”。让留下的人有成长，让走的人有尊严——这是我在这场经历之后给自己的要求。

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

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

推荐学习
测试智能体与智能化测试平台公开课，从Web/App/接口测试智能体，再到智能体工具Opencode，爱测智能化测试平台，手把手带你掌握AI智能体与智能化测试平台！

👉 扫码进群，报名学习！

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

关于我们
霍格沃兹测试开发学社，隶属于 测吧（北京）科技有限公司，是一个面向软件测试爱好者的技术交流社区。

学社围绕现代软件测试工程体系展开，内容涵盖软件测试入门、自动化测试、性能测试、接口测试、测试开发、全栈测试，以及人工智能测试与 AI 在测试工程中的应用实践。

我们关注测试工程能力的系统化建设，包括 Python 自动化测试、Java 自动化测试、Web 与 App 自动化、持续集成与质量体系建设，同时探索 AI 驱动的测试设计、用例生成、自动化执行与质量分析方法，沉淀可复用、可落地的测试开发工程经验。

在技术社区与工程实践之外，学社还参与测试工程人才培养体系建设，面向高校提供测试实训平台与实践支持，组织开展 “火焰杯” 软件测试相关技术赛事，并探索以能力为导向的人才培养模式，包括高校学员先学习、就业后付款的实践路径。

同时，学社结合真实行业需求，为在职测试工程师与高潜学员提供名企大厂 1v1 私教服务，用于个性化能力提升与工程实践指导。