AI 时代，测试工程师的生存之道

测试工程师这行有个默认成立的隐含前提你测的东西行为是可预期的。这个前提在传统软件测试里成立因为代码是确定的。你测一个计算器的加法224永远成立。你测一个搜索框输入上海结果页一定包含上海。这些断言写完就可以睡觉不用担心明早它无缘无故翻车。但 AI 系统不吃这套。你让 LLM 写一段营销文案它今天写得文采飞扬明天同样的 prompt 给你来一段平平无奇。你让它做信息抽取某条数据今天抽对了明天可能多抽一个字段后天可能少抽一个。不是 bug不是部署问题就是这个系统在本质上不一样——它的输出是概率分布的采样不是固定的返回值。你拿一把只有通过和失败两格的尺子去量一个每次落点都在漂移的东西。量出来的结果你自己信吗一、以前的方法和思维模式已经失效这个坑行业里不是没人踩过。微软研究院的一篇报告里提到他们在评估某款 AI 写作辅助工具时发现自动化测试全部通过但真实用户满意度只有 62%。原因是测试用例全部基于标准答案对比而用户真正在意的是语气、节奏、上下文的连贯感——这些维度传统断言根本测不到。更扎心的是光有测试用例还不够测试用例本身也会撒谎。某个做智能客服的团队花了三个月建了 200 条自动化测试用例回归通过率长期保持在 94% 以上。结果新版本上线后用户投诉量翻倍。事后复盘那 200 条用例几乎全是正常提问 标准回答的配对没有一条覆盖用户情绪激动时的语气处理没有一条测过上下文被截断时的行为。94% 的通过率测的是一个缩小版的假世界。说实话我们太喜欢那个绿色的对勾了。它给人一种质量有保障的踏实感。但对于 AI 系统单次的全部通过有时候比部分失败更危险——失败至少提醒你去翻一眼日志全部通过让你扭头就走准备发布。这才是最坑的地方。它不报错。测试报告一片绿骗你睡个好觉然后线上用户给你补上一条条差评。二、测试工程师技能和思维模式都要升级那继续用老方法还是彻底推翻重来都不对。核心就三个转变。第1从验证正确性转向刻画行为分布不是这次输出对不对是这个系统在 N 次运行下的质量分布长什么样。好情况同一条用例跑 10 次得分分布是 0.88±0.03。稳可信。 坏情况跑 10 次均值 0.76但最低分 0.41最高分 0.93。这个系统在抽卡你不能信任它。为什么要这样转变因为你现在的任务不是找 bug是描述风险。一个方差很大的系统不是有时候有 bug是本身就是个高风险系统。这两种表述对产品决策的影响完全不同。第2从覆盖代码路径转向覆盖用户意图空间传统测试的覆盖率是代码覆盖率——多少行代码被执行到了。对 LLM 系统这个指标没有意义。你要覆盖的是用户会怎么提问、会提什么奇怪的问题、会在什么场景下用这个功能。好情况用例设计涵盖了正常提问、模糊提问、带情绪的提问、跨语言的提问、明显越权的提问。 坏情况200 条用例全是标准问题标准回答对应的是一个不存在于现实的完美用户。测试用例的来源要从工程师自己想扩展到从真实用户日志里挖。线上跑了一个月的真实 query比工程师凭空想象的 1000 条用例更有价值。第3从自动化替代人工转向人机协作分层审核说白了AI 测 AI不能完全信任。LLM-as-Judge用大模型当评判者会对格式有偏好会受评估 prompt 措辞影响自身也在漂移。你不能把一个概率系统交给另一个概率系统去把关然后自己去喝咖啡。好情况自动化评分负责快速筛选人工审核负责最终裁决尤其是高分区防假阳性和低分区理解失败原因都要有人眼看到。 坏情况自动化全流程报告里一片绿没有人知道绿的是什么。这套分工逻辑其实成熟行业早就在用了。医疗影像 AI 给出诊断概率最终签字的是医生。金融风控模型打出风险分最终放不放款是信贷官的责任。自动驾驶感知系统输出置信度驾驶决策还有多层安全冗余。是我们的测试报告把自动化当成了终点而不是起点。三、3档分层每档行动不同把所有测试结果按风险程度分三档处理。稳定区条件多次运行均值 ≥ 0.85标准差 ≤ 0.05无灾难性失败案例连续版本无退化趋势。 行动自动放行进入下一流程节点不需要人工干预。 分治逻辑如果某条用例长期稳定在绿区每季度抽检一次确认用例本身没有过时需求变了但用例没更新。观察区条件均值在 0.70–0.84 之间或标准差 0.10或存在低分但未灾难性的失败。 行动进入人工复核队列。 分治逻辑失败集中在某类输入 → prompt 工程问题改系统 prompt 或补 few-shot 示例失败随机分散 → 模型能力边界考虑拆分任务或升级模型失败集中在某个时间段 → 排查上游数据或外部依赖问题。危险区条件均值 0.70或任意一次出现灾难性输出严重事实错误、有害内容、逻辑崩塌或关键安全用例未通过。 行动一票否决不上线打回修复记录失败模式。 分治逻辑如果是用例设计遗漏导致未提前发现 → 修用例如果是系统本身缺陷 → 修系统同时给这类场景新增回归用例防复现。最佳实践清单• 给每条测试用例加run_count配置5 次起步核心对话链路拉到 10 次安全合规场景拉到 20 次。• 报告字段别只写pass/fail。标准字段写清楚runs、mean_score、std_dev、min_score、failure_types、failure_rate。•accuracy这类二值指标换成pass_rateN让不确定性显式出现在报告里而不是被单次结果掩盖。• 每次版本迭代不只跑新功能用例必须跑全量回归。时间不够就减少用例数量不能跳过回归。• 从真实用户日志里定期每月至少一次补充新的测试用例尤其是那些你没想到的奇怪 query。• LLM-as-Judge 只当概率参考。它是辅助层高分区每月人工抽检 10%低分区必须人工确认失败原因签字的人还得是你。结尾AI 时代测试工程师的价值从来不在于把所有测试都自动化掉。在于你敢不敢把这个系统的输出在某些场景下是不稳定的我们观测到的风险分布是这样的明明白白写进测试报告交给产品和业务去做决策。我知道要团队从跑通就行改成看分布才算数没那么容易。光是说服研发负责人接受我们的测试结论是个概率区间可能就得开几轮对齐会。改 CI 流程、改报告模板、改评审节点每一步都有工程成本。我也不确定每个团队现阶段都扛得动这个改造成本。但 AI 功能已经在你的系统里跑了。你的测试体系还停在确定性输出的时代。你手里现在测的这个系统还在用红绿灯交差吗评论区告诉我——你遇到的最头疼的问题是用例不够用还是根本不知道测出来的结果该怎么解读测试工程师这行有个默认成立的隐含前提你测的东西行为是可预期的。这个前提在传统软件测试里成立因为代码是确定的。你测一个计算器的加法224永远成立。你测一个搜索框输入上海结果页一定包含上海。这些断言写完就可以睡觉不用担心明早它无缘无故翻车。但 AI 系统不吃这套。你让 LLM 写一段营销文案它今天写得文采飞扬明天同样的 prompt 给你来一段平平无奇。你让它做信息抽取某条数据今天抽对了明天可能多抽一个字段后天可能少抽一个。不是 bug不是部署问题就是这个系统在本质上不一样——它的输出是概率分布的采样不是固定的返回值。你拿一把只有通过和失败两格的尺子去量一个每次落点都在漂移的东西。量出来的结果你自己信吗