AI驱动用户旅程测试用例自动化生成实践

1. 为什么测试用例生成这件事值得用AI重做一遍做测试的同学应该都有这种体会辛辛苦苦维护用户旅程测试用例需求一改就要手动梳理费时费力还容易漏场景。最近我在某电商业务线实践了一个“AI驱动用户旅程测试用例自动化生成”的项目简单说就是让AI从埋点日志、业务描述里自动产出可落地执行的测试用例再配合规则校验和人工抽审收口结果。这个方向对维持回归测试质量、释放测试人力很有帮助适合正在做用户行为数据建设的中大型业务团队也适合想提高用例编写效率的测试小组参考。1.1 手工编写用户旅程用例的四个“痛点”先说说我为什么会盯上这个问题。大多数人包括以前的我都把“写用例”当成纯手工活。一个下单流程要写几十条正反用例覆盖搜索、详情、加购、结算、支付、订单状态。这个工作量不是一次性投入需求一改、页面一调、文案一变全链路用例都要跟着改。在我待过的项目里用户旅程用例的维护成本远高于单接口或单页面的功能用例而且这类用例往往是回归测试的主力漏一条就可能漏掉一个线上问题。我把手工维护的痛点拆成四类下面每一条听起来都很简单但背后都是实打实的成本。第一路径枚举靠人肉很容易漏分支。用户旅程不是一条直线“搜索无结果”“库存不足”“优惠券不可用”“支付超时”这些都是真实存在的分支。谁想起来谁就写没想到就漏最后覆盖度完全取决于某个测试工程师当时的状态。第二用例描述和业务语义脱节。手工写出来的步骤经常是“点击按钮A断言文本B”但完全没表达用户到底想完成什么目标。等需求方来问“这个用例覆盖了快速退货的场景吗”测试这边往往要翻半天文档才能对上。第三跨团队语言不统一。产品经理用自然语言描述需求开发用接口和状态机描述实现测试写的用例又是另一套格式三方对齐成本很高。第四维护节奏赶不上迭代。业务App一周一个版本靠测试每周手工更新用例本质是在救火。我刚接手某个模块时光是清掉一批已经失效的历史用例就花了一个下午最费时的还是把新需求逐条翻译成用例。这种重复劳动天然适合交给AI做第一版草稿。1.2 这个项目到底在解决什么问题这个项目的定位不是取代测试工程师而是把“从用户旅程到测试用例”这一段低创造性、高重复性的翻译工作自动化。我要先给用户旅程一个可操作的定义用户在一个业务目标驱动下经历的一系列页面、动作、事件和状态迁移。测试用例则是对这个旅程的覆盖性描述包含前置条件、具体步骤、预期结果。AI要做的就是从旅程描述或行为数据里自动抽取这些要素生成结构化用例。为什么要选“AI驱动”而不是纯规则模板因为纯规则只能覆盖已经被建模好的主流程对长尾分支场景基本无能为力。大模型擅长从模糊描述中理解业务意图能补出埋点数据里没有的语义细节。当然纯靠大模型也不行它很容易一本正经地编造不存在的按钮。所以整套方案的底线是AI负责批量生成草稿规则负责约束边界人工负责最终把关。这个组合原则是整个项目最核心的取舍。1.3 适合谁来用用到什么程度这套方案最适合的团队是已经有用户行为埋点、但用例维护还处于半手工状态的中大型业务团队。如果暂时没有埋点数据也不用慌直接用产品经理写的用户故事描述作为输入也可以生成的用例会更依赖模型理解能力人工审核比重需要加大。小团队和初创项目可以用轻量版本起步不一定要先建完整的数据管道先拿有代表性的几条旅程做试点跑通价值再扩展。我在这篇文章里讲的步骤可以直接照着逐步实施。对个人来说即使不做完整平台学会把旅程数据规范成事件序列再让模型生成用例草稿也能明显减轻重复劳动。2. 整体设计思路把“用户旅程”翻译成“可执行用例”设计这套系统时我最关心的是用什么中间格式让不同来源的旅程数据被统一处理。许多刚接触这个方向的人一上来就调prompt结果换一种描述方式效果就崩了。问题不在模型而在于没有先把数据规范好。所以我在项目里先定了“旅程事件”模型后面所有生成、校验、去重都围绕这个模型展开。2.1 先定义清楚什么是机器可理解的“用户旅程”我定义的基本单位是事件Event包含如下字段事件名称、所在页面、动作类型、参数、时间、用户标识、会话标识。一个用户旅程就是一连串有先后顺序和状态依赖的事件流。这个模型的最大好处是埋点日志、产品文档、产品经理口述都可以转成同一种中间格式。AI生成用例时只认这个格式不关心原始数据来自哪里。实际项目中第一步是梳理埋点字典确认每个事件字段的含义。如果埋点字典本身混乱后面所有生成结果都是在沙地上盖楼所以我在这步会花掉接近一半的项目时间。这里要特别提醒一个坑不要把原始日志直接丢给模型。日志里有大量机器噪声比如页面心跳、网络重试、按钮曝光这些事件跟用户完成业务目标没有直接关系。模型如果收到了这些噪声生成的用例会严重跑偏。我习惯先按会话聚合再过滤低频和无意义事件最后按业务目标把长旅程切分成一个一个独立片段。至于怎么切分如果埋点里带了业务标记比如订单号生成时间点、关键页面进入时间可以按这些标记来切如果没带就要靠页面类型序列来做启发式切分比如从入口页到结束页之间算作一个旅程。这个“会话切分”的粒度直接决定了AI看到的上下文是否完整。2.2 AI生成测试用例的三条可行路线在实际工程里生成测试用例有三条路线可选我建议先理解清楚再组合使用。第一条是规则模板加状态机。把核心旅程建模成状态图每个节点表示页面或业务状态每条边对应一次动作测试用例就等价于从起始状态到结束状态的一条路径。这条路线的优点是结果完全可控、解释性强缺陷是建模成本高只能覆盖已经画好的路径对未知场景没有任何发现能力。适合主流程非常稳定、监管要求高的业务模块。第二条是序列挖掘加聚类。从用户行为日志里挖掘高频子序列再按相似度把行为序列聚成若干类每一类代表一种典型旅程然后再为每类旅程生成用例。优点是不需要人工建模能发现真实用户已经走出来的高频路径缺点也很明显挖掘结果没有业务语义。比如一次连续点击返回键可能只是误触也可能是一段完整的纠错行为算法分不清需要人工给这些簇命名和确认。第三条是LLM生成。把旅程描述或事件序列作为上下文用提示词让模型生成测试用例。优点是能理解自然语言能把“用户想快速退货”这种模糊目标拆成具体步骤缺点是输出不稳定会编造不存在的页面或动作需要加约束和校验。我在项目里三条路线并没有谁取代谁而是按旅程类型分流核心主流程用状态机保证稳定探索性场景用序列挖掘加LLM补语义长尾业务描述走纯LLM加人工审核。这种分流方式既能守住质量底线又能尽可能覆盖边界情况。2.3 我为什么选“LLM规则校验”的组合方案听到这里你可能会问既然纯LLM有这么多问题为什么不完全用规则模板我的回答是规则的确定性是优点也是天花板。用户旅程天然存在大量“不确定但合理”的分支这些分支在状态机里根本画不完。反过来说如果完全信任LLM测试用例的严谨性又会被破坏。所以我选了折中方案LLM负责生成创意性的步骤和预期结果规则校验负责把输出约束在可执行范围内。具体实现包括三层。第一层是定义“用例Schema”用结构化约束让模型只能输出固定字段的JSON第二层是后置规则引擎检查每个步骤里出现的页面、动作是否在预先维护的字典内检查前置条件是否被步骤序列满足第三层是人工审核抽样高优先级用例全量审核中低优先级按比例抽审。这样模型生成的东西再离谱也只会停留在草稿层面不会被直接送进测试套件。我的原则是宁可少生成十条也不要让一条不可执行的垃圾用例混进回归集。整套方案的“翻译层”其实就是这三个环节的配合。3. 核心模块拆解从原始行为日志到测试用例库下面拆解真正的实现环节。整个流程是原始数据入清洗 → 会话切分 → 旅程片段的意图识别 → LLM用例生成 → 规则校验 → 去重与覆盖度评估 → 人工审核。每一步都很基础但少了哪一步最终用例库的质量都会肉眼可见地下滑。3.1 旅程数据的采集与清洗先看原始埋点长什么样。假设是一个电商App用户从商品详情页加购到结算支付事件日志大致像下面这样{ event_name: cart_add, page: product_detail, action: click, params: {sku_id: P10086, quantity: 1}, timestamp: 2025-05-20 14:33:21, user_id: u_12345, session_id: s_67890 }清洗阶段我一般做四件事字段映射、噪声过滤、会话切分、路径压缩。字段映射是把各端上报日志统一成规范的事件名避免App端叫“add_cart”、小程序端叫“cart_add”这种不统一的情况。噪声过滤要建立一张“无意义事件表”把曝光、心跳、前后台切换这类事件直接丢弃。会话切分可以用一个时间阈值比如同一用户相邻两次事件间隔超过30分钟就视为新会话。路径压缩则是把连续重复的相同动作合并成一个事件比如用户连续三次点击加购按钮底层日志会记三条事件业务上可以视为一次意图内的高频操作。这一步做完得到的是干净的“用户事件序列”。我在这上面投入了差不多一半的开发量因为后面所有模块的质量都取决于这一步。数据没洗干净AI生成的用例大概率会在一些看起来正常、但实际不可能发生的页面之间跳来跳去。3.2 关键节点抽取与意图识别拿到事件序列后下一步是找到哪些节点值得生成用例。这里的思路是“规则定位高频路径AI补充语义标签”。我会先用序列统计算法从清洗后的数据里提取高频连续子序列比如“商品详情→加购→购物车→结算→支付”就是一条典型旅程。这些子序列可以按支持度过滤只保留出现次数超过阈值的热门路径。这样的路径虽然高频但它只是节点序列缺少“用户在干什么”的语义。语义标签可以交给LLM来做。把一条事件序列喂给模型让它总结成一句业务描述比如“用户搜索无结果后返回首页重新搜索”然后我们把这句描述作为旅程的名称。这里要注意LLM总结的时候可能会有幻觉所以我要求输出时带上从事件序列中引用的关键事件名作为证据字段。有了带语义标签的旅程片段后面的用例生成才能真正贴合业务而不是只生成“点击按钮”式的机械步骤。3.3 测试用例骨架生成数据结构与提示词设计生成用例的核心是定义好目标数据结构。我在项目里用的Schema大致是下面这个示例{ case_id: TC_RC_0001, journey: 用户提交退款申请, preconditions: [用户已登录, 订单状态为待退款], steps: [ {order: 1, action: open_app, target: 首页, assert: 首页加载成功}, {order: 2, action: enter_order_detail, target: 订单详情页, assert: 退款入口可见} ], expected_result: 退款申请提交成功订单状态变更为退款中, priority: high, tags: [refund, regression] }这个Schema不是随手定的。action字段必须来自动作字典target必须来自页面字典assert描述必须是可检查的预期状态preconditions用来约束上下文。只有字段都被约束后续才能自动化执行和去重。Prompt设计上我给模型三条指令。第一只输出合法JSON不要任何解释。第二必须优先引用输入的旅程事件不允许凭空添加页面。第三如果旅程信息不足以确定预期结果就明确写“待人工确认”不要自己编。同时给两条示例做few-shot。生成参数上temperature我调到0.2max_tokens按用例复杂度给1500这能显著降低发散性。输出后还要做一道后处理用JSON解析器解析失败就做轻量修复再过规则引擎。这个流程跑下来大部分问题用例都停在草稿阶段不会直接进入正式用例集。3.4 去重、覆盖度评估与人工审核闭环生成出来的用例不能直接入库否则几天内就会出现一堆相似用例。去重我用的方案是“结构化相似度”把每条用例的步骤序列转成动作和页面对的组合序列再算SimHash距离距离低于阈值就视为重复保留优先级高且步骤更完整的那条。这里不推荐做纯文本去重因为两条用例的标题可能不同但底层步骤几乎一样纯文本算法很容易漏掉。覆盖度评估需要建立“关键节点集合”把业务方认为不可遗漏的页面、动作、状态都列出来然后检查生成用例集合覆盖了其中哪些节点输出一份覆盖报告。这份报告有两个用途一是让测试负责人快速看到哪类旅程还没被覆盖二是反馈给生成模块让它下一轮优先生成未覆盖的分支。人工审核闭环上我采用的规则是高优先级用例全量审中优先级按30%抽审低优先级按10%抽审。审核页面上每条用例必须携带“生成来源”即旅程片段ID和原始事件ID方便出问题后快速回溯。4. 实操过程记录一个退款旅程的完整生成示例光讲抽象设计不够我拿一个常见业务场景完整走一遍。场景是某个电商App的“用户申请退款”输入包括一段产品描述和一份清洗后的部分日志。整个流程包括预处理、生成、导入三个环节跑完大概能看到一套可落地的用例长什么样。4.1 输入样例与预处理结果产品描述大概是用户已登录账号在待收货订单列表找到目标订单进入订单详情页点击“申请退款”选择原因提交申请系统生成退款单后续在退款详情页看到状态为退款处理中。清洗后的核心事件序列被我压缩成下面的形式打开App进入首页登录成功进入个人中心打开待收货订单列表点击目标订单进入订单详情点击申请退款选择退款原因并提交系统创建退款单进入退款详情页看到退款处理中状态。这8步已经隐含了至少三条用例的骨架正向成功路径、打开退款入口但取消操作、提交后后台处理失败。预处理阶段这些步骤会带上页面字典和动作字典的校验标签比如“申请退款”动作在订单详情页上合法在首页上就不合法。这一步把业务描述转换成了模型可处理的结构化输入。4.2 生成结果与字段说明下面是我实际跑出来的一条正向用例摘要。用例编号TC_RC_0102旅程“用户提交退款申请”前置条件已登录、订单状态为待收货。步骤就是上面8步每一步都带预期断言。比如第4步断言“订单详情页展示申请退款入口”第6步断言“退款原因必填项校验通过”第8步断言“退款单状态显示退款处理中”。预期结果是“申请提交成功退款单进入处理中状态”。优先级标为高标签为退款回归。这个结果不是一次生成的它经历了规则校验。第一次生成时模型给步骤里加了一个“点击联系客服弹窗”的动作但页面字典里没有这个元素被规则引擎拦截后退回重写第二次才生成干净结果。这说明“规则校验”不是摆设它真的能把幻觉挡在门外。另外一条异常用例会覆盖“退款原因未选择时点击提交”的校验提示还有一条分支用例覆盖“退款提交后系统处理失败”的补偿提示。这三条组合起来基本构成了这个旅程的回归用例集。4.3 如何把AI用例接入现有测试管理工具生成只是开始用例得进到测试管理体系里才能发挥价值。我们内部的导入逻辑大概是这样脚本读入生成好的JSON用例文件批量创建到测试管理平台的指定测试套件下每条用例打上自动生成标记、来源批次号并关联对应的旅程片段ID。运行时的命令行大致类似这样python scripts/import_cases.py \ --source generated_cases.json \ --project demo_project \ --suite refund_regression \ --tag auto_generated导入之后测试工程师可以在平台里直接编辑平台会把修改过的用例和“自动生成”标记自动解除避免下次批次导入时把人工修改覆盖掉。这是一个非常重要的设计细节。如果不同时处理人工修改和自动生成的版本关系AI跑一晚上第二天就把测试同事昨晚的修订冲掉了信任感会瞬间崩塌。另外执行结果需要回传这样才能统计自动生成用例的通过率和缺陷发现率。这个回传闭环是后续衡量项目价值的数据基础。如果团队还没有测试管理平台也可以先导出成CSV或Excel共享但长期看还是建议把“生成批次”和“用例版本”的关联做进系统里。5. 常见问题与排查技巧实录下面这部分是踩坑记录。我把实践中最常见的四类问题列出来每条都给出原因和可复现的排查方法希望能帮你少走几个弯路。5.1 LLM输出不稳定结构化约束与自校验最让人头疼的问题是模型偶尔返回一段解释性文字而不是JSON或者JSON字段缺项。第一次遇到时我以为调高temperature就行结果发现真正有效的不是温度而是把输出约束写死。我现在的做法是三层兜底第一在系统提示词里明确写“只输出JSON禁止输出任何解释和Markdown代码块”第二用解析器解析解析失败就用正则把代码块里的JSON片段提取出来再解析第三如果还失败就把失败信息和原提示词拼在一起让模型重写一次。经过这三层我这边结构化解析成功率能稳定在98%以上。如果你发现模型经常把页面名称写错不要急着改prompt先检查你是否在字典文件里把可选的页面名称都写清楚了。模型看不到可选范围自然只能靠猜。5.2 会话状态缺失导致用例不可执行另一类高频问题是生成的步骤之间缺少状态依赖。比如先写“进入订单详情页”但没有前置条件“用户已登录”也没有前面“打开订单列表”的步骤执行时发现跳转不过去。我在规则引擎里专门加了一道“前置条件一致性检查”遍历所有步骤提取每个动作执行前必须存在的状态再检查该状态是否由之前的某一步创建。如果没有就自动在步骤序列头部补一条“准备条件”步骤并加入前置条件字段。这种方式比让模型自己补靠谱得多因为模型并不了解测试环境里状态切换的底层限制。举个例子生成“进入退款详情页”之前必须要有“提交退款申请成功”的状态否则后续所有断言都无从谈起。人工审核时也要重点看这一类问题特别是分支路径里的状态依赖。5.3 用例重复度过高与覆盖漏洞有一段时间生成出来的20条用例里有12条都是“进入订单详情→点击退款→提交→验证”只是标题和参数略有不同。原因是LLM面对相同的高频旅程很容易生成同质化内容。后来我把去重模块从“文本标题相似度”改成“结构化步骤相似度”并按页面加动作的组合计算SimHash阈值设在0.85。同时覆盖度报告会和批量生成任务联动已经覆盖的关键节点会作为负样本告诉模型“不要重复生成”优先补充未覆盖分支。这一改重复率明显下降用例集合的覆盖度从75%涨到了89%。建议你在跑第一版时就加上覆盖度报告哪怕只是一个简单的关键节点统计表也能防止团队在“看起来很热闹”的用例库里迷失方向。5.4 与CI/CD集成的三个坑接入持续集成时还有三个容易踩的坑。第一个坑是每次全量导入用例导致测试管理平台一天多出几千条记录里面还混着大量重复数据。对策是导入前先按用例指纹做增量比对只导入新增或变更的用例。第二个坑是AI生成任务不稳定偶尔会中断定时任务失败到了第二天才被发现。对策是给生成任务加失败重试和批次状态上报失败时发告警。第三个坑是执行结果和生成批次对不上问题用例无法追溯是哪个旅程生成出来的。对策是生成批次号贯穿导入、执行、结果回传全链路问题定位时先按批次号过滤。这些问题都不是算法难题但处理不好项目很难从“能跑”走向“好用”。我把这几个高频问题整理成了一个速查表方便你在现场排查时对照。问题现象主要原因快速排查方法生成结果不是JSON提示词约束不足检查提示词是否只要求输出JSON步骤跳转不合理缺少前置状态检查查看规则引擎是否有前置条件校验用例大量重复去重维度太粗切换到结构化步骤相似度去重导入用例冲掉人工修改版本管理缺失打自动生成标记修改后自动解除6. 后续还能怎么玩从单条旅程到全链路质量地图项目走到这里已经不只是“自动生成用例”了。再往深走这个方向能接上很多质量保障能力下面聊聊短期可落地的扩展和长期评估价值的方法。6.1 短期可落地的扩展第一把生成的用例喂给自动化测试框架做真实执行。目前很多业务团队的自动化脚本还是手工录制的覆盖路径少维护成本高。我们可以让AI先按旅程生成步骤再由脚本翻译成具体操作调用至少能把探索性测试的启动速度提起来。第二把用户旅程数据直接喂给流量录制回放系统录下真实用户在某个页面上的操作序列回放时校验关键业务状态是否符合预期。这不属于传统用例生成但和用户旅程自动化测试是同一套数据资产复用起来很顺手。第三结合混沌工程思路让AI针对每个旅程生成“故障注入剧本”比如在退款提交时注入依赖服务超时看系统能否给出正确降级提示。短期看来这三项都是低成本、高感知的扩展而且都围绕同一个“旅程事件模型”不会产生额外数据孤岛。6.2 长期价值判断与效果度量长期做这个项目不能只看“一天生成了几百条用例”。我建议用一个组合指标来评估自动生成用例被人工采纳并入库的比例这是模型质量的最直接信号自动生成用例在回归执行中的通过率这是生成结果稳定性的信号用例库整体对关键旅程节点的覆盖率这是业务覆盖度的信号以及靠自动生成用例发现的有效缺陷数量。我给自己定的基线是采纳率不低于80%执行通过率不低于95%覆盖率达到人工用例集的120%这时候项目才算真正产生了业务价值。如果没有这些指标AI生成再多用例也只是数字游戏。我自己就会把每月采纳率和缺陷发现数放在周报里用它来对内对外说明这个项目的真实效果。6.3 我的几点体会与建议最后分享一点个人经验。我在实际项目里最大的体会是这类项目真正的杠杆不在模型强弱而在数据基础和工程边界。你要先把事件字典、页面字典、动作字典和维护流程做好模型的表现才有意义。另一个体会是永远不要取消人工审阅环节。生成式工具越强越需要一个人来对“不存在的界面操作”负责。说句实话AI驱动用户旅程测试用例自动化生成并不是一个装个模型就能跑的项目它需要把数据治理、规则引擎和现有测试工具串成一条完整的流水线。如果你也想做建议先挑一条最痛的核心旅程试跑跑通后再慢慢扩展这条路是目前我验证过走得比较稳的。