我让AI模拟10万个“暴躁用户”操作，找到了产品经理都不敢写的崩溃路径

关注 霍格沃兹软件测试开发 公众号回复「资料」, 领取人工智能测试开发技术合集当AI学会像用户一样“乱点”那些藏在代码深处的定时炸弹就藏不住了大家好我是某互联网公司质量保障团队的技术负责人负责移动端稳定性测试体系建设。今天聊一个我们最近做成的实验——用AI模拟10万个不同性格的真实用户在App里“疯狂探索”然后找到了产品经理做梦都想不到的崩溃路径。先上结果系统上线四个月累计发现了127条人工测试和传统自动化完全漏掉的崩溃路径其中23条是P0级——一旦触发就是App闪退、用户流失的那种。关键是这些路径没有一条在产品PRD里出现过。一、为什么传统测试找不到“真崩溃”说个真实的数据主流App需适配超过20,000种设备-OS组合用户行为路径复杂性导致30%以上崩溃未被预发现。30%。也就是说每三个崩溃里就有一个是上线后才被用户“撞”出来的。原因其实很简单——测试用例是“好人”写的。测试用例打开App → 登录 → 浏览首页 → 点击商品 → 加入购物车 → 支付真实用户打开App → 疯狂滑动 → 点进一个页面 → 立刻返回 → 再点进另一个 → 快速切换Tab → 在加载中点了三次 → App卡死了正常用户不会按照用例操作暴躁用户更不会。我们的产品经理在PRD里写的都是“理想路径”——用户会乖乖登录、按流程操作、耐心等待加载。但真实世界里的用户网络不好时疯狂重试点加载转圈时连续按返回在页面还没渲染完时就滑动在不同Tab之间来回快速切换这些操作没有一个写在需求文档里但每一个都可能触发崩溃。二、转折让AI学会当“坏用户”去年年底我们开始了一个项目——训练AI模拟不同性格的真实用户对App做大规模探索式测试。核心思路来自一个很朴素的想法大语言模型经过海量通用知识训练具备一定的模拟人类常识与预期的能力恰好契合模拟用户行为的需求且无需针对特定应用单独适配天然具备泛化性。翻译成大白话AI知道“正常人会怎么用App”也知道“暴躁的人会怎么搞破坏”。我们给AI设定了三类“用户画像”第一类正常用户占比60%按常规路径操作偶尔滑动、偶尔返回用于建立“基准行为基线”第二类急躁用户占比25%操作节奏快、不等加载完成就进行下一步频繁切换页面、快速滑动列表在加载动画出现时连续点击第三类探索型用户占比15%专门点那些“看起来不像按钮”的地方长按、双击、三指滑动在页面边界和角落疯狂试探三类用户加起来我们让AI模拟了10万个独立的“虚拟用户” 每个用户在App里执行5-15分钟的“自由探索”然后记录所有操作序列和App的响应。三、技术方案怎么让AI“学会”乱点技术实现上我们走了三条路。路径一大模型驱动UI理解传统自动化测试依赖XPath和ID定位——UI一变就挂。我们的方案是多模态模型直接“看”屏幕。每次AI“看到”一个页面多模态模型会识别所有可交互元素按钮、输入框、滑动条、Tab理解每个元素的语义“这个是返回”“这个是提交”根据当前用户画像决定“点哪个”和“怎么点”这套方案参考了美团的KuiTest思路——让大模型理解UI交互组件的功能预测点击后的合理结果。不同的是我们刻意让AI“预测不合理的结果”——专门找那些“点了之后会出问题”的操作。路径二Delta-Debugging路径压缩AI探索过程中会产生大量操作序列有些长达几十步。但真正导致崩溃的往往只是其中某几步的组合。我们引入了一个基于Delta-Debugging二分算法的路径压缩模块当AI触发了一个崩溃系统记录下完整的操作序列比如15步然后自动尝试删除序列中的某些步骤看崩溃是否还会复现反复二分直到找到能复现崩溃的最短路径举个例子AI用12步操作触发了一个崩溃路径压缩后可能发现——只需要“快速切换Tab3次”就能复现。这个功能的价值怎么强调都不为过。测试团队拿到的不再是“崩溃日志长串操作录像”而是精准的、可复现的最小崩溃路径——开发同学一看就知道问题在哪修起来快太多了。路径三多智能体协同探索单靠一个AI到处乱点效率太低。我们部署了一组AI智能体并行探索每个智能体独立运行有不同的“探索策略”有的专注“深层路径”点进深层页面再操作有的专注“边界路径”在页面边缘和角落操作有的专注“快速切换”在页面间高频跳转10万个虚拟用户实际上是10万个并发的AI探索任务分布在我们的云真机集群上并行执行。四、真实案例那些“产品经理不敢写”的崩溃说三个AI找到的真实案例。案例一“快速返回”触发的内存泄漏AI在模拟“急躁用户”时发现在商品详情页快速点击返回按钮5次以上App会逐渐变卡第7-8次时直接闪退。开发排查后发现每次返回时详情页的图片缓存没有被正确释放。正常用户返回一次内存还能撑住。但急躁用户连续快速返回内存泄漏累积到阈值直接OOM。产品经理看到这个Bug时的表情“谁会连续点那么多次返回啊”我反问“你见过用户骂一个加载慢的页面时怎么操作的吗”案例二“加载中连续点击”导致的ANRAI在模拟“网络差环境下的暴躁用户”时发现在弱网环境下在加载转圈出现时连续点击屏幕任意位置3次主线程会被彻底卡死触发ANR应用无响应。原因是每次点击都会触发一个等待队列的检查而加载中的页面状态没有做防抖处理。正常用户等加载完成再操作永远不会触发。但暴躁用户会在加载时疯狂点屏幕——“怎么还没好点一下再点一下”这个Bug我们修复后线上ANR率下降了12%。案例三“跨页面快速切换”导致的状态错乱AI在模拟“探索型用户”时发现了一个极其隐蔽的问题从首页→分类→详情→返回首页→再点分类→再进详情→快速返回——在特定节奏下页面栈会被污染导致“返回”按钮跳转到错误的页面。这个Bug产品经理完全无法理解“用户怎么会这么操作”但线上数据告诉我们每天有数千个真实用户就是这么操作的——他们只是“手快”而已。五、踩过的坑说三个最痛的坑一AI“太聪明”了反而不像真人初期AI的操作非常“高效”——每次都能精准找到按钮、快速完成任务。但这根本不像真实用户。解法我们给AI加入了“不确定性因子”——随机延迟100-800ms、随机滑动偏移、偶尔的“误触”点偏5-10像素。让AI的操作更像“手残”的真实用户。坑二探索空间太大跑不完一个中等复杂度的App页面状态组合是天文数字。AI如果无限制探索跑三天三夜都跑不完。解法引入覆盖率引导——优先探索“没去过”的页面和“没试过”的操作组合。同时设置探索上限每个虚拟用户最多15分钟超时自动停止。坑三误报太多初期AI“发现”的崩溃里60%以上其实是测试环境的问题——网络抖动、设备过热、测试账号权限不足。解法建立了三级验证机制AI发现疑似崩溃 → 自动在同一设备上重试3次3次中至少2次复现 → 标记为“高置信度”高置信度问题 → 进入人工复核队列这套机制把误报率从60%降到了8% 。六、效果数据说几个硬数据指标数据模拟虚拟用户数10万累计发现崩溃路径127条P0级崩溃23条人工测试漏测率从30%降至**5%**路径压缩效率平均12步→3步线上ANR率案例二修复后↓12%最关键的变化测试团队从“按PRD写用例”变成了“让AI找PRD之外的崩溃” 。我们不再只验证“产品想让用户怎么用”而是验证“用户实际会怎么用”。七、给同行的一些建议如果你也想尝试这个方向我有几点实在的建议从“用户画像”开始别一上来就搞全量探索先定义清楚你要模拟哪几类用户——正常、急躁、探索型就够了。每种画像的操作模式差别很大混在一起AI会“精神分裂”。路径压缩比探索本身更重要找到崩溃只是第一步。能不能给出最短复现路径决定了开发愿不愿意修。 一个15步的崩溃录像开发看都不想看。一个3步的精准复现步骤开发当天就修了。别在真机上跑用云真机集群10万个虚拟用户如果都在本地真机上跑你得买多少台手机我们用的是云真机集群并行跑、按需扩容成本可控。接受“AI找到的不全是Bug”AI会找到很多“看起来像Bug但其实不是”的东西——比如设计如此、或者测试环境问题。建立分级验证机制把人工复核的工作量降到最低。先跑非核心模块别一上来就让AI去折腾支付流程。先从非核心、低风险的模块开始跑比如设置页、个人中心、帮助中心跑通了再逐步扩展到核心业务。最后AI模拟用户操作做探索式测试本质上是在做一件事——把“真实用户怎么用App”这个黑盒打开。产品经理写PRD的时候假设用户是“理性的、耐心的、按流程走的”。但真实世界里的用户是“急躁的、手快的、乱点的”。这两者之间的差距就是崩溃藏身的地方。AI不会替代测试工程师但它帮我们找到了那些“产品经理都不敢写进PRD”的崩溃路径。而这些路径恰恰是用户每天都在撞的。本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容侧重测试实践、工具应用与工程经验整理。