1. 为什么“装傻”成了AI时代测试的第一生产力最近我所在的测试组接了几个大模型辅助开发的项目开发同学交代码的速度肉眼可见地快了但测试这边的情况却越来越微妙AI生成的代码边界条件写得“看起来都对”可一旦真跑到极端输入、断网重连、设备断电这种场景一下子就露馅儿了。更要命的是开发同学自己也会被AI带偏觉得“模型都这么写了应该没问题吧”。资历浅一点的测试新人面对这种“集体迷信AI”的氛围往往不敢提质疑生怕显得自己不懂前沿技术。我做了十多年软件测试这几年的体会越来越深在所有人都在捧AI、信AI、依赖AI的时候测试人员最值钱的技能反而是“装傻”——这个词不是贬义而是一种刻意为之的专业姿态。你假装自己完全不懂大模型那套逻辑假装看不懂AI给出的漂亮结论然后用最原始、最笨拙的怀疑去对抗最聪明的模型输出。这篇文章我想把我和团队过去半年摸索出来的这套“装傻生存指南”完整梳理一遍。它的核心不是教你怎么拒绝AI而是教你怎么在AI生成代码、AI辅助测试、AI Agent满天飞的环境里找到软件测试从业者真正的护城河。适合正在做功能测试、自动化测试、测试开发以及那些被问到“你怎么测AI生成的功能”这类面试题的同学参考。为什么需要“装傻”因为当前行业里最危险的一件事就是测试人员开始“太聪明”了。聪明到能替AI圆谎、能看懂AI的思路、能顺着模型的逻辑去设计用例。结果就是AI写了个有缺陷的功能测试人员用AI的思路去验证AI的代码两两配合缺陷完美藏住。真正能拦住问题的那个人反而是那个坚持用“如果用户是个不讲理的人会怎么操作”这种笨问题来拷问系统的人。1.1 AI正在把测试人员推到一个尴尬位置过去几年“AI会取代软件测试”这个话题每隔一段时间就上一次热榜。我见过不少测试同行焦虑得不行忙着报班学大模型原理、卷Prompt Engineering生怕自己哪天被一个自动化测试Agent顶掉。但以我实际观察到的落地情况来说AI短期内很难彻底取代测试它更可能先改变测试的工作方式——而且这种改变已经发生了。最典型的变化是测试用例设计开始依赖大模型生成。以前我们写用例是从需求文档里一行一行抠逻辑画出流程图、状态图再逐个分支去补边界。现在呢把需求文档丢给大模型几秒钟就能吐出一份格式工整、覆盖了正常流和部分异常流的用例表。速度快是真的快但我也发现一个规律大模型生成的用例整体质量像一份“包装精美的半成品”看起来五脏俱全实际上它默认了需求是合理的、开发不会写错、用户不会乱来。这种“默认”恰恰是测试的大忌。另一个尴尬来自AI编程助手的普及。开发侧用了AI生成代码之后代码风格变得非常统一变量命名规范函数粒度合理一眼扫过去几乎挑不出毛病。但这恰恰是问题所在以前我们还能通过“代码写得别扭”来嗅出潜在缺陷现在代码太“顺滑”了缺陷就藏在那些AI没有生成到的角落里。比如某个定时任务的时区处理、某个宕机恢复分支、某个极端并发下的状态错乱——这些边角料AI模型不会主动给你生成开发同学也不会主动想起来。于是测试人员变成了最后一道防线而我们手里唯一的武器就是“不信任”。1.2 “装傻”的本质刻意不信任专业性质疑我说的“装傻”不是真的让你放弃技术学习、不去了解AI而是建议你在测试执行阶段刻意让自己回到一个“外行用户”的视角。你可以精通大模型原理但在设计测试用例的那一刻请把大模型当成一个“很会编故事但经常记错细节的同事”。你说这个功能是这么设计的我不听你说AI说这个逻辑没问题我也不听。我只问一个问题如果真实用户在用的时候能不能找到一条路把你的系统搞坏听起来简单做起来很难。因为人的思维是有惯性的——你刚看完AI生成的方案大脑不自觉会顺着它的逻辑往下走甚至会觉得它“说得真有道理”。所以“装傻”其实是一种对抗认知惯性的训练你要刻意在脑子里把自己清零假装自己就是个第一次用这个产品的用户什么技术背景都没有什么需求文档都没看过只会乱点乱按。这种视角往往能找到那些专业测试员最容易漏掉的问题。我管这个叫“测试者的‘先验无知’”。也就是不管系统逻辑多复杂、代码多优雅我都先默认它有问题然后去找证据。这套思路以前适用现在更适用。因为以前代码是人写的人的失误有迹可循——累了、忘了、理解偏了现在代码是模型生成的模型的失误更加隐蔽——它不是在“理解”需求它是在“预测”你想要的答案预测错了就编一个编得还很有说服力。面对这种对手逻辑推演不见得好使反倒是“装傻式”的暴力试探更有效。1.3 对抗不是拒绝AI是把AI当成对手来练也有人问我你说得这么玄乎是不是让我们抵制AI、回到手工测试时代完全不是。我们团队现在用AI用得比谁都狠但用法不一样别人是把AI当成“完成测试任务的助手”我们更愿意把AI当成“需要被测试的对象”同时也当成“用来找茬的陪练”。具体来说我们把当作对手的AI分成了两路。第一路是开发侧的AI生成代码这是我们要对抗的“假想敌”——你要假设它写的每一个函数都藏着边界问题然后用测试去证明。第二路是测试侧的AI辅助工具包括AI生成用例、AI写自动化脚本、AI做缺陷分析这些是我们的“工具”但用工具的同时要保持警惕AI给出来的结论只能作为线索不能作为依据。把AI当对手来练还有一个额外的好处它会逼你把测试设计能力提升到一个新的层次。以前你测的是“开发有没有写对”现在你要测的是“模型有没有猜对”。这完全是两个维度的事。“写对”至少还有个需求文档作参照而“猜对”压根没有标准答案需求文档只能告诉你“系统应该做什么”但模型可能生成的是“系统做了一堆看似相关但并非用户真正要的东西”。所以测试人员得学会和AI玩“猜心思”的游戏一边猜模型会怎么理解需求一边猜真实用户会怎么使用产品——两边都对上了质量才稳。这个过程其实就是给“软件测试”这四个字换了一层新的内核。2. 对抗方法论核心测试人员的“三不原则”聊完了心态层面的事接着说说方法论。我根据自己团队踩过的坑总结了三条特别实用的原则。这三条原则只要贯彻到位大部分AI相关项目的测试质量都能兜住底。它们的共同点是都建立在“怀疑AI默认逻辑”的基础上。这三条原则分别是不轻信需求描述、不轻信AI生成的用例、不轻信全绿的结果。听着像绕口令但每一条背后都有真实的翻车案例支撑。接下来一条一条拆开讲。2.1 不轻信需求描述需求本身就是问题源第一性原理是这样的软件测试的核心不是“验证需求被实现”而是“验证系统在真实世界里能不能扛住”。需求文档是理想世界的产物真实世界是混乱的。大模型有一个习惯——它倾向于把需求描述里的“正常情况”当成唯一场景来生成代码或用例。你给它看一句话“用户可以通过手机号注册”它就老老实实地围绕“输入手机号、获取验证码、注册成功”这种标准路径来设计。但真实世界里手机会欠费停机、验证码会延迟60秒、用户会在等待验证码的时候切走App再切回来、同一个手机号可能已经被注销过又重新放号……这些脏场景需求文档里通常不会写。所以我的第一个“装傻”动作就是拿到需求文档后先在页边空白处列出所有“需求文档假设成立才可能出现”的前提条件然后一条条反驳它。举个我们实际遇到的例子有个AI生成的数据看板功能需求文档写的是“按小时汇总交易数据并显示趋势图”。开发用AI辅助很快就写完了UI很漂亮查询也很快。但测试的时候我装傻问了一个很蠢的问题如果某一天某一小时一单交易都没有这个看板要不要显示如果显示是显示0还是显示空如果不显示那这一小时是不是会在趋势图里形成断层让用户误以为数据丢了需求文档完全没提这个问题AI生成的代码直接按“有数据才插入记录”的逻辑来做结果那一小时直接消失。这种问题靠“验证需求”是永远发现不了的只有靠“怀疑需求”才能揪出来。2.2 不轻信AI生成的用例覆盖率好看不等于测得到位第二条原则可能很多人不爱听但它确实是我用实践换来的教训。AI生成测试用例的能力已经在平均水平之上了尤其是一些从事例中归纳场景的工作模型做得比人快得多。但你让模型生成一套“针对某个功能的完整用例”它大概率给你生成一份行业标准的“正常流基本异常流”模板覆盖率报告出来挺好看核心功能也都沾边了但总让人觉得“少了点什么”。少了什么呢少的是那些“需要真实业务经验才知道”的组装型场景。举个具体例子我们测过一套物联网设备的远程控制功能需求是手机App控制家里的智能门锁。AI生成用例时很自然地列出了“手机在线时开锁”“手机离线时提示失败”“密码错误时拒绝开锁”这些基础场景。但真正干过物联网测试的人都清楚这还远远不够。你还要测设备在弱网环境下收到开锁指令后网络突然断了返回结果没到达手机用户以为没开锁又按了一次结果设备收到了两条重复的开锁指令——这时候业务上要不要做幂等处理再比如App显示“门锁已开启”但门锁的开关状态上报延迟了10秒这个中间态怎么展示这些场景需要的是对产品形态、网络环境、用户行为的立体理解而这些恰恰是大模型最缺的。模型能给你一片森林但看不出哪棵树下埋着地雷。我的处理办法是AI生成的用例可以留但只能当“基础题清单”用。拿到之后我会再花等量的时间用“装傻视角”自己补一轮“脏场景用例”——就假设用户是个没耐心、爱乱点、网络差、还喜欢暴力操作的熊孩子然后一条条追问系统能不能扛住。两套用例合并在一起才敢说覆盖得差不多了。2.3 不轻信全绿的结果测试通过背后可能是假阳性这条原则是最容易被误解的。以前我们认为测试用例全部跑完、结果全绿就代表质量达标了。但我做过的几个AI相关项目都在提醒我全绿的结果有时候恰恰是最需要警惕的信号。为什么因为AI参与的测试链路里“假阳性”的概率在悄悄升高。举个例子我们团队用过AI生成的自动化测试脚本脚本逻辑写得非常规整Pytest风格fixture管理得清清楚楚断言也写得花团锦簇。跑起来确实全绿但我随手翻了一下执行日志发现一个诡异的现象某个关键接口在断言之前打印的响应体是500错误但脚本依然通过了。后来排查发现AI生成的脚本里有一个隐性bug——它断言的是“响应体包含某个字段”但那个字段在错误响应里也有只是取了个空值。字段存在不等于字段有效。这个错误非常隐蔽因为脚本逻辑上没毛病断言也执行了结果也对但测了个寂寞。所以我现在定了一条规矩不管AI脚本生成得多漂亮最终执行结果都要人工抽检原始日志。全绿不算数必须能说清楚“每条用例到底验证了什么、数据从哪来、断言是否真的具备筛选能力”。说得玄一点测试人员要学会给自动化脚本本身做“测试的测试”。这也就是我强调的“装傻”——哪怕结果全绿我也先假装结果不可信非要翻出原始凭证来亲眼确认一遍才踏实。3. 一套可以上手的AI对抗测试流程含物联网设备实战理论说了一堆重点还是要落地。我以最近一个真实的物联网设备管理平台项目为例子完整走一遍我们怎么把“装傻”方法论落成一套可复制的测试流程。这个项目涉及设备端、云端、App端三端联调中间还嵌了不少AI生成代码测试复杂度相当高。整个过程分成准备、设计、执行、验收四个阶段。3.1 准备阶段建立“对抗性需求清单”很多测试团队做项目启动的第一件事是读需求文档、整理功能点清单。我们的显著区别是除了功能点清单还会额外产出一份“对抗性需求清单”。这份清单分两栏左边写“需求文档里明确写了什么”右边写“需求文档没写、但现实世界中一定会发生什么”。右边这一栏就是测试的核心战场。实际操作中我会组织测试同事做一场“装傻风暴会”——刻意不请开发大家只拿需求文档谁问出来的问题越“白痴”越好。比如设备离线重启后上报数据会不会丢App长时间退到后台再回来设备状态会不会变成假的同一个设备如果被解绑后再绑定新账号历史数据怎么办这些问题不需要懂代码也能问出来但恰恰就是AI生成代码最容易漏掉的地方。最后我们把这些问题汇总成一张表每条都标注“需要特别测试验证”交给后续的测试设计阶段逐条认领。这里多说一句对抗性需求清单的价值在于倒逼测试人员提前暴露系统的脆弱假设。别等用例设计写到一半才想起来也别等开发说“这个场景不支持”的时候才去确认。准备工作做得越细后面的实操阶段越省力。3.2 设计阶段让大模型出题人来挑刺到了用例设计阶段我们不会傻乎乎地纯手工写用例也不会全盘甩给AI。团队的标准流程是“AI出题、人挑刺”。具体操作是先把整理好的需求功能和对抗性需求清单一起丢给大模型让它分别生成“基础功能测试用例集”和“对抗场景测试用例集”。这一步的好处是AI能把那些常规的、行业标准化的场景快速铺满省掉我们大量打底时间。但AI生成的对抗场景用例基本只能当参考提纲。因为这些场景如果描述得不够具体模型很容易生成“测试弱网环境下设备控制是否正常”这种正确的废话——什么叫正常弱网到什么程度延迟是500ms还是1ms丢包率多少如果是控制指令发出去后服务器确认收到了但设备没收到怎么判断这些问题模型不会替你细化只能靠有实战经验的人来补。我会拿AI生成的那些泛泛场景逐条结合我们设备的具体通信协议MQTT、CoAP这些和网络部署情况来细化把它变成一条条可执行、有明确前置条件和预期结果的具体用例。这个阶段还有个额外收获通过让AI出题测试新人能快速学习到那些行业标准场景长什么样。但我会反复提醒新人参考AI的题可以但“挑刺”的能力只能靠经验积累AI替代不了。3.3 执行阶段用AI提效自动化但保留“手工怀疑点”执行阶段是我们团队在AI对抗方法论上投入模块最大的部分。我们的核心思路是“能用AI自动化快速覆盖的绝不手工做但自动化测完的区域必须额外保留手工怀疑点复查机制”。拿这个物联网项目来说常规的接口测试、设备状态上报测试、App基础流程测试我们全部交给了AI生成的自动化脚本去跑。具体做法是把接口文档和部分历史脚本扔给大模型让它生成一版Pytest自动化框架我们再做代码走查和手工修正。这一步效率确实高脚本框架、公共方法、断言模板都能直接生成测试人员只需要把核心业务断言改准。但我们的第二条铁律是AI生成的自动化脚本每一条都要在真实环境里肉眼观察一次执行过程再确认保留。执行日志、请求响应、状态码、数据落库结果四样缺一不可。与此同时那些对抗性需求清单里标注了“需要特别测试验证”的场景坚持手工测试探索性测试。因为这些场景本来就没办法完全自动化——你没法轻易自动化出真实的弱网环境也没法自动化模拟一个操作到一半突然把App杀了、再等五分钟再回来的用户行为。我们会在测试环境里架真实的物联网设备人为控制网络丢包手动执行各种中断操作用最原始的方式去验证系统的真实反应。这部分的耗时往往比自动化翻倍但价值也是翻倍的。3.4 验收阶段“装傻三问”最终把门流程跑完用例也执行得七七八八了但测试负责人往往面临一个最纠结的问题能不能放行上线纯看指标的话功能用例通过率99%自动化测试全绿缺陷密度也控制住了看起来确实可以放行。但我坚持在最终测试报告前把“装傻三问”贴在最显眼的位置逐条回答。第一问真实用户中有没有可能有人做出一件我们流程里完全没预判到的操作第二问系统真的扛得住一个“不太讲道理”的极端场景吗第三问如果我们测出来的所有结果都正常是不是因为我们一直在用同一种方式测它这三个问题如果能给出让人信服的答案我才会在验收报告上签字。回答不了的话哪怕指标全绿我也不会签字放行。事实证明这套把关方式帮我们拦下了至少三个上线后可能引发大事故的严重缺陷。4. 常见陷阱与排查实录方法论讲完接着分享一些实际踩坑和排查经验。做AI相关测试半年多来我们碰到过不少让人哭笑不得的陷阱有些是AI工具本身造成的有些是我们在“装傻”装得还不够彻底时犯的错。我把它整理成一份速查表供大家参考。陷阱类型表面现象真实原因排查手段AI用例同质化覆盖率报告很漂亮场景五花八门模型把同一逻辑换了个皮重复生成人工聚类比对去除重复场景再统计真实覆盖自动化假阳性脚本全绿功能一用就挂断言写得太宽松或者根本没断到点子上抽样比对执行日志与原始响应测试数据幻觉用例数据看起来合理但不符合业务规则大模型“编造”了不存在的组合数据严格人工审核数据集字段合法性与关联性测试脚本幻觉脚本逻辑通畅但引用的模块或接口根本不存在模型为了完成任务“编”了一个假接口逐条核对脚本调用的方法与接口文档团队氛围风险测试人员不敢质疑AI结论怕显得落后对AI能力过度崇拜丧失了职业怀疑建立“装傻文化”明确质疑AI是被鼓励的4.1 看起来专业的用例全是重复验证这个问题我们遇到得最频繁也最隐蔽。早期用大模型批量生成用例时我看到生成结果的第一反应是“太全了功能点全覆盖”结果实际执行起来才发现大量用例本质上是在测同一件事。比如针对一个“修改用户昵称”的功能AI生成了20条用例但其中5条都是“正常修改昵称后个人信息页面显示新昵称”只不过前置条件在“App端修改”“Web端修改”“修改后刷新页面”这些细枝末节上滚来滚去。真正该测的“昵称包含表情符号”“昵称长度为1个字符”“昵称是纯空格”这些边界反而没几条。排查方法其实不难把所有AI生成的用例做一次关键词聚类把描述里的“操作动作”提取出来看重复率。如果某一个操作动作在用例清单里出现超过三次基本可以确定是凑数的。我们后来在流程里加了道检查关卡——AI生成的用例先让资历最浅的测试同学用同一标准重新聚类一遍把“换个说法其实同一件事”的用例并掉再进评审。这道关卡倒逼新人去理解每个用例的业务本质效果比单纯让他们从头写用例好得多。4.2 自动化全绿其实是数据污染“数据污染”是自动化测试里的老问题但在AI时代突然变得普遍了。我们用AI生成自动化脚本时模型非常喜欢复用已有的测试数据或者干脆在脚本里固定写死一批ID和账户信息。这些固定数据在多轮迭代之后可能早就不是原来那个状态了。举一个实际例子AI生成的自动化脚本里有一条用例依赖一个“测试企业账号A”。第一轮跑的时候账号A是正常状态用例通过。两周后另一条AI生成的脚本在执行时将账号A给注销了。结果呢所有依赖账号A的脚本开始接连失败但失败原因被误判成“产品功能有bug”测试人员排查了半天最后发现就是数据没了。这种问题排查起来很费劲因为AI生成的脚本里有很多隐式的数据依赖肉眼很难直接看出来。我现在给团队的规矩是AI自动生成的测试脚本上线前必须有一个人手工通读一遍把所有直接引用测试数据的地方挑出来和测试数据管理模块进行对照。凡是引用了共享可变数据的一律改成动态获取或者单独隔离的数据副本。另外还想提醒一句定期清理测试环境里的旧数据是必不可少的AI脚本对数据状态的假设比人写的脚本更敏感。4.3 大模型幻觉导致的测试数据失真大模型幻觉这事在测试领域不止体现在代码和脚本上还体现在测试数据的生成上。我们有个项目需要制造一批模拟用户操作日志来做大数据测试为了省事让大模型直接生成了一批JSON格式的日志数据。生成得很逼真字段齐全时间戳间隔合理但放到系统里一跑立刻问题百出——后来一查发现模型生成的日志数据里用户ID和用户名对不上操作时间里的日期有跳变甚至出现了同一个用户在同一秒内执行了两种互斥操作的“灵异数据”。这件事给了我一个特别深刻的教训用大模型生成数据必须做双重复核第一次核格式第二次核业务合理性。格式问题好解决拿个简单的校验工具就能跑业务合理性就麻烦了必须靠懂业务的人逐条抽查。我后来让团队建了一个“数据生成提示词”模板把必须满足的业务规则作为强约束写进去同时留出人工抽查时间宁可数据量少一点也不让假数据把测试分析给污染了。4.4 团队协作里“装傻”的尺度怎么拿捏最后说个比较现实的管理问题。我们团队引入“装傻文化”之后遇到的最大的阻力其实不是来自技术层面而是来自协作关系层面。有些开发同学会觉得测试老揪着AI生成代码的角落问题不放是在“不信任AI”、“不拥抱变化”。这种情绪一上来很容易变成团队内部的对立。怎么化解我个人的经验是两条。第一测试人员提缺陷的时候建议把问题逻辑讲清楚重点放在“真实用户会遇到什么麻烦”上而不是强调“AI生成的代码有问题”。你质疑的是产品风险不是技术进步这个立场要先立住。第二允许测试人员在正式提出缺陷之前先在评审会上用“装傻”的姿态公开提问我这边有个蠢问题不太懂AI是怎么处理这个场景的如果用户这样做会怎样这种提问方式不伤人又能把问题摆到台面上。很多时候开发自己听完也会当场拍脑袋对啊这个场景我们没考虑到。这样整个团队就把焦点从“谁对谁错”转移到了“怎么把产品做稳”上。5. 一点过来人的心得和后续可以玩的方向这套“装傻生存指南”写到这儿核心内容基本都交代了。最后说几句我自己真实操作下来的体会。第一测试人员在AI时代最怕的不是被替代而是主动放弃思考。AI再强它也只是一个基于概率的预测机器它不承担产品出问题的责任也不理解用户真正想要什么。那个责任和判断如果测试不接住产品就真的裸奔了。第二所谓的“装傻”说到底是一种“反向思考能力”的刻意训练。每次看到AI给出一个顺滑的答案都逼自己停下来问一句它凭什么这么笃定这个“凭什么”问多了你会发现自己对系统的理解比过去深了很多。第三尽量别让AI替你完成“理解需求”这一步。AI可以帮你把需求文档转成用例草稿但只有人才知道需求背后那个真实业务的血肉是什么样的。接下来我们团队准备尝试的方向是在这次流程基础之上给AI加一个“对抗陪练”的角色让两个不同的大模型互相生成测试方案和反例测试人员只做裁判专门挑两边都没想到的盲区。这个玩法目前还比较初步但给我最大的感受是AI工具之间相互制衡反而能把测试人员的判断力提到一个新的档位。将来这个方向如果再走通我再回来接着写。