关注 霍格沃兹软件测试开发 公众号回复「资料」, 领取人工智能测试开发技术合集当“AI帮我写的”成了测试报告里最高频的短语我意识到出事了大家好我是某互联网公司质量保障团队的技术负责人。上个月我们给测试团队全员配了AI Copilot。工具是好工具GitHub Copilot加内部大模型双管齐下目标是让测试用例编写效率翻倍。结果第一周结束我打开大家的日报被一个短语刷屏了“AI说的。”“这个用例覆盖了边界条件——AI说的。” “断言逻辑是这样写的——AI说的。” “这个模块风险较低不用深入测——AI说的。”整整一周的日报里“AI说的”出现了47次。没有一个人写“我判断”“我认为”“我分析”。那一刻我感觉不太对劲。一、事情是怎么开始的先交代一下背景。我们团队20多人负责公司核心业务的质量保障。日常工作量最大的就是用例编写和回归验证——每个版本几百条用例全靠人肉写一个版本耗掉3-4人天。今年Q1公司引进了AI Copilot的企业版可以接入内部代码库和知识库。测试团队作为首批试点全员配上了。第一周大家热情很高。AI确实能干活——你输入“请为订单支付接口生成完整的测试用例”10秒钟出来20多条用例覆盖正向、反向、边界场景。换以前一个测试同学至少要花半小时。效率提升肉眼可见。但问题也肉眼可见。周一一个初级测试同学提交的用例里AI生成了一个“优惠券叠加使用”的场景——规则是“满100减10”和“满200减30”可以叠加。但实际上我们系统的规则是不能叠加只能选一个最优的。我问ta“这个用例的逻辑你验证过吗”ta回答“AI生成的我看了一眼觉得没问题。”“看了一眼。”这个回答让我心里咯噔了一下。二、“AI说的”背后藏着三个致命问题第一周结束后我把那47条“AI说的”全部拉出来看了一遍。发现问题比我想象的严重得多。问题一盲从——把AI当成了“正确答案”最典型的一个案例一个测试同学用AI生成了一段接口自动化脚本AI在断言部分写了一个错误的预期返回值——把“订单状态已支付”写成了“订单状态已发货”。脚本跑完之后显示“全部通过”ta就直接提交了报告。我问ta“你没看一下断言的逻辑吗”ta说“AI写的应该是对的吧。”“应该是对的吧” ——这句话的危险程度不亚于在生产环境直接执行DROP TABLE。类似的案例在行业里并不少见。有测试工程师因为相信AI生成的“100%路径覆盖、0错误”报告忽略了“输入字段为空并发写入”这种AI逻辑无法覆盖的组合最终导致生产环境崩溃。不是AI不行是人太信AI了。问题二惰性——从“主动思考”退化成“被动接收”有一个细节让我印象特别深。我们有一个测试用例的评审会大家一起过AI生成的用例。以往人工写的用例大家会争论——“这个边界值设得对不对”“这个场景有没有遗漏”那天全场沉默。我问“大家觉得这些用例怎么样”一个同学说“AI生成的应该覆盖得挺全的吧。”没有人质疑没有人提问没有人补充。 所有人都在默认“AI是对的”。这种现象在业内已经有专门的研究了。AI工具在接管重复性测试的同时正在无形中“驯化”人类专家导致他们从“主动怀疑”的探索者退化为“被动接收报告”的审查员。即使是资深工程师在接触新技术时过度依赖AI技能退化同样会显著发生。我们团队从“写用例的人”变成了“看AI用例的人”——但“看”的时候脑子是关着的。问题三逃避责任——把决策权甩锅给AI最让我担心的是那句“AI说的”背后的潜台词。“AI说的”“出了问题别找我是AI说的。”这不是个例。有媒体曝光过一个真实案例某大厂推行零代码测试平台后因为一个人不懂底层日志写错断言导致AI自动生成一百多个误报工单整个研发团队崩溃。不是技术故障是认知断裂。当测试工程师不再为自己的判断负责而是把决策权外包给AI——这个团队的质量保障能力实际上是在倒退。三、第三周事故来了第三周出事了。一个支付模块的回归测试AI生成了一套用例全部跑通。测试同学在报告里写“支付模块回归通过无新增问题”——AI说的。上线第二天线上反馈部分用户支付成功后订单状态没有更新。排查后发现AI生成的测试脚本里断言只验证了接口返回码是否为200没有验证数据库里的订单状态字段是否真的更新了。那个测试同学说“AI生成的断言就是这样我以为够了。”“我以为够了。”这个Bug不算大影响了几十个用户紧急修复了。但这件事让我意识到——我们不是在用AI提效我们是在用AI给自己挖坑。四、我做了什么事故之后我停掉了AI Copilot的“自动生成”权限改成“辅助模式”。然后做了三件事。第一件事把“AI说的”从日报里禁掉了我在团队群里发了一条消息“从今天开始日报里再出现‘AI说的’这三个字重写。我要看到的是‘我验证了’‘我确认了’‘我判断’。AI可以是你的工具但不能是你的大脑。”不是矫情。当一个人开始用“AI说的”来为自己的工作背书时说明他已经放弃了对工作结果的 ownership。第二件事立了一条铁规矩——AI生成的必须人工验证具体做法很简单AI生成用例后必须逐条review标注“已验证”才能提交AI生成的断言必须在测试环境手动跑一遍确认逻辑正确AI生成的风险判断必须人工复核不能直接采纳不是不相信AI是相信之前先确认。第三件事每周一次“AI盲测”训练每周五下午我挑一个模块让团队同学不用AI、纯手写一套测试用例。不是为了让他们“回到石器时代”而是为了保持手感。一个做了半年AI辅助测试的同事跟我说第一次做“盲测”的时候他发现自己写用例的速度和逻辑严密性比半年前退步了至少30%。这个结果让我后背发凉。五、后来怎么样了调整之后又跑了两个月。数据是这样的指标调整前调整后用例编写效率↑150%↑80%用例准确率首次提交72%93%线上漏测率↑20%↓5%团队成员“主动思考”的自评分数6.2/108.5/10效率降了一些但质量回来了。更重要的是团队的氛围变了。日报里不再有“AI说的”取而代之的是“我验证了AI生成的用例补充了3个边界场景”“我修改了AI的断言逻辑增加了数据库状态检查”。工具还是那个工具但使用工具的人脑子回来了。六、给同行的几点建议如果你也在给团队配AI Copilot我有几条掏心窝的话AI是副驾驶不是自动驾驶Copilot这个名字本身就说明了问题——它是副驾驶不是自动驾驶。副驾驶可以帮你导航、提醒路况但方向盘必须在你自己手里。任何AI生成的内容在提交之前必须经过人工验证。这是底线没有商量余地。保护好团队的“质疑能力”质疑能力是测试工程师最核心的能力——质疑需求、质疑设计、质疑代码、质疑自己的判断。AI最容易侵蚀的就是这个能力。因为它给出的答案太“像那么回事”了让人懒得质疑。每周至少安排一次“无AI”的测试设计训练让团队保持手动设计用例的能力。建立“AI输出审查”机制不是说AI生成的不能用而是要有机制地使用AI生成 → 人工review → 标注修改内容 → 提交每周统计AI输出的准确率和人工修改率修改率超过30%的模块说明AI在这个领域还不成熟暂时不要用4. 警惕“效率幻觉”AI提效是事实但效率提升不等于质量提升。一个测试同学用AI一天写了200条用例如果其中有30条逻辑有问题那这200条用例的价值可能还不如手写50条高质量的。效率是手段质量是目的。别搞反了。最后AI Copilot是个好工具。但它也是一面镜子——照出了我们团队在“独立思考”这件事上有多脆弱。第一周那47条“AI说的”本质上不是AI的问题是我们的问题——是我们太容易放弃思考太容易把决策权交给别人。现在我的团队还在用AI Copilot但用法变了AI负责“生成初稿”人负责“最终决策”。AI负责“提供建议”人负责“做出判断”。AI负责“提高速度”人负责“保证质量”。工具是冷的人是热的。别让AI替你思考让AI帮你思考得更快。本文系作者基于真实经历的复盘总结欢迎同行交流讨论。本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容侧重测试实践、工具应用与工程经验整理。
函数详解：从字符读取到流操作，避免常见陷阱)
