关注 霍格沃兹软件测试开发 公众号回复「资料」, 领取人工智能测试开发技术合集当效率工具变成裁员加速器我经历了最纠结的三周大家好我是某互联网公司质量保障团队的负责人手下管理着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我有几点实在的建议不要用AI来做“对人的判断”AI可以判断“这段代码的风险”但不要让它去判断“这个人的价值”。数据和指标是冰冷的人的价值是多维的——经验、判断力、团队协作、隐性知识——这些AI看不到。在系统上线之前先想好“人往哪里去”技术落地之前先做好人力规划。如果某些岗位会被AI替代这些人应该转去哪里需要什么培训转型周期多久这些问题应该在项目启动时就回答而不是上线之后。保护好团队的信任感用AI“优化掉”同事的消息一旦传开整个团队的士气会崩塌。大家会觉得“下一个是不是我”然后人心涣散能跑的都会跑。宁可慢一点也不要把效率工具变成恐慌制造机。把“隐性知识”记录下来在老同事转型之前花时间把他们脑子里的经验系统性地沉淀下来业务的坑点清单历史故障的完整复盘边缘场景的手工测试手册这些不是“老员工应该做”的事而是“管理者应该组织做”的事。最后AI不会让测试这个岗位消失但会让某些工作方式消失。作为一个管理者我的责任不是“用AI省钱”而是“带着团队走过这场变革”。让留下的人有成长让走的人有尊严——这是我在这场经历之后给自己的要求。工具是冷的人是热的。效率是硬的信任是软的。做一个好的管理者就是要在这两者之间找到平衡。本文系作者基于真实经历的复盘总结。文中人名已做脱敏处理欢迎同行交流讨论。本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容侧重测试实践、工具应用与工程经验整理。
