TID质量竞争大会分享议题丨腾讯PCG工程效能专家张健：AI 生成用例只是起点，真正的难点是让质量持续进化

AI 进入测试领域之后测试用例生成成了最容易被关注的场景。输入一段需求AI 很快就能生成测试点、测试场景、BDD 用例甚至还能继续生成自动化脚本。看上去效率提升很明显但真正落地到业务团队后很多问题也会暴露出来生成的用例是不是覆盖了核心风险有没有大量重复、空泛、不可执行的描述需求描述变化后用例质量能不能自动跟着优化团队多人使用后系统能不能越用越准而不是每次都从零开始这也是当前 AI 测试用例生成从“能用”走向“好用”的关键挑战。在本次分享中腾讯 PCG 工程效能专家张健将带来《用例生成自进化AI驱动的测试用例质量持续进化实践》重点介绍腾讯 PCG 在 AI 测试用例生成方向从“AI 辅助生成”到“Agent 自主执行”的一年实践路径。一、讲师介绍从用例管理插件到 AI-Native 智能测试管家张健腾讯 PCG 工程效能专家来自腾讯 PCG 应用效能技术部、联合业务质效中心长期专注于 AI 测试工程方向。在智能化测试工具建设方面张健主导了多个关键系统的设计与落地BDD 用例管理 IDE 插件用例生成插件 CaseMasterAI-Native 智能测试管家 QA Seneschal其中QA Seneschal 是一套基于多 Skill 编排与置信度治理的全链路测试 Agent 系统代表了腾讯 PCG 在智能测试方向的一次重要升级。这次分享的重点不是停留在“AI 能不能生成测试用例”而是进一步回答生成之后如何评估评估之后如何修复修复之后如何持续学习和进化二、AI 生成用例的真正难点不是“生成”而是“质量可控”很多团队在引入大模型生成测试用例时第一阶段通常会比较兴奋。因为相比人工从需求中逐条拆解场景AI 确实可以快速产出大量测试用例尤其在需求初稿、场景梳理、边界条件补充等环节能够明显提升效率。但进入真实业务后问题也会变得复杂常见问题具体表现覆盖不稳定重要场景遗漏边界条件不完整描述不清晰用例步骤模糊验证点不明确重复率偏高多条用例表达不同但测试目标相近可执行性不足用例看起来完整但测试人员无法直接执行质量难评估生成结果好不好依赖人工主观判断成本不可控每次全量重生成Token 消耗高结果还不稳定所以AI 生成测试用例真正要解决的问题不只是“能不能写出来”而是要把用例质量变成一个可评估、可修复、可追踪、可持续优化的工程体系。张健本次分享的核心价值正是在这个方向上给出了一套可复用的自进化架构范式。三、核心架构生成、评估、修复、学习、优化的自进化闭环腾讯 PCG 的实践并不是简单地调用大模型生成一批用例而是围绕用例质量构建了一套完整闭环。整体流程可以概括为这套机制的关键点在于AI 不只是生成者也要进入评估、修复和学习流程。也就是说系统不是一次性输出结果而是通过多轮闭环让生成结果不断向高质量用例靠近。四、评估引擎自进化系统的“眼睛”用例生成之后第一件事不是直接交给测试人员使用而是先经过质量评估。在腾讯 PCG 的实践中评估引擎采用了“规则检查器 LLM 评估器”的双评估架构。其中规则检查器占 70%LLM 评估器占 30%这个比例背后的设计思路非常清晰规则保底线LLM 提上限。规则检查器适合处理确定性问题比如格式是否符合 BDD 规范、字段是否缺失、步骤是否完整、是否存在明显重复等。LLM 评估器则更适合处理语义类问题比如场景覆盖是否充分、描述是否清晰、测试意图是否合理、是否存在隐性风险遗漏等。两者结合之后可以让用例质量评估既有稳定底线又保留一定的智能判断能力。评估维度主要覆盖五个方面评估维度关注重点覆盖度是否覆盖核心业务路径、异常场景、边界条件多样性是否避免生成大量相似用例BDD 合规性是否符合 Given-When-Then 等结构化表达要求可执行性测试人员是否能直接理解并执行去重性是否存在语义重复、步骤重复、验证点重复这一步非常重要因为只有先把“什么是好用例”量化出来后面的自动修复和持续进化才有基础。五、自循环修复只重做低质量部分而不是全量推倒重来传统 AI 用例生成中一个常见问题是只要某些结果不满意就让模型重新生成一遍。这种方式看似简单但问题也很明显一方面原本质量不错的内容可能被覆盖另一方面每次全量生成都会带来额外 Token 消耗成本不可控。腾讯 PCG 的实践中采用的是局部修复策略只重做评分低的部分保留已经达标的高质量内容。修复流程分为三级L1规则自动修复适合处理格式类、结构类、字段类问题。例如缺少前置条件BDD 格式不完整标题命名不规范重复字段清理描述格式统一这类问题可以通过规则快速修复通常是秒级完成。L2LLM 局部重生成适合处理语义类问题。例如场景覆盖不足步骤描述不清晰断言不明确测试数据不合理某个子场景缺少边界条件此时不需要全量生成只需要让 LLM 针对低分片段局部重写。L3人工介入当系统判断置信度不足或者规则与 LLM 评估结果存在明显冲突时再引入人工介入。这样可以避免所有问题都丢给人也避免所有问题都盲目交给模型。更重要的是人工处理结果还可以反过来成为后续系统学习的信号。六、自适应进化用户操作本身就是学习信号真正的自进化不只是模型自己反复生成和修复更关键的是把用户使用过程中的真实反馈利用起来。在实际测试工作中测试人员会对 AI 生成的用例进行各种操作删除某些用例修改某些步骤合并相似场景补充断言调整优先级标记不可执行保留某些高质量用例这些动作背后其实都隐藏着质量判断。如果系统能够识别这些操作并转化为学习信号就可以逐步完成阈值校准和策略优化。例如用户操作可转化的学习信号删除用例可能存在重复、低价值、不可执行问题修改步骤原步骤可能不清晰、不准确补充验证点原用例断言不足合并用例可能存在语义重复保留用例当前生成策略有效标记高优先级对应场景更接近业务核心风险这样一来系统就不再是一次性的生成工具而是可以在真实业务使用中持续学习。这也是“用例生成自进化”的核心所在用户用得越多系统越知道什么样的用例更符合当前业务团队的质量标准。七、三级闭环让质量进化从单次生成变成持续工程能力本次分享中一个很值得关注的设计是三级闭环秒级自修复次级反馈学习版本级基线对比这三个层次分别解决不同问题。秒级自修复解决单次生成质量问题当系统发现格式、重复、结构等问题时可以快速自动修复减少人工清洗成本。次级反馈学习解决团队使用偏好问题系统通过测试人员的修改、删除、保留等行为持续学习业务团队对用例质量的真实判断标准。版本级基线对比解决长期质量演进问题不同版本、不同需求、不同业务线之间可以通过基线对比观察用例质量变化。例如当前版本覆盖度是否提升重复率是否下降坐标准确率是否稳定新需求场景是否出现质量波动某类业务场景是否一直生成效果较差这让 AI 用例生成从“单点能力”变成了“持续治理能力”。八、真实落地效果从模糊、重复、不可用到可量化提升在腾讯文档 Sheet 品类的落地实践中这套自进化机制已经取得了比较明显的效果。根据议题材料中的数据指标优化前优化后模糊描述占比60%2%重复率39%4%坐标准确率0%95%Token 消耗节省 60%用例质量提升 35%这些数据说明AI 测试用例生成的优化方向不应该只盯着“生成速度”还要关注描述是否准确用例是否可执行重复是否可控质量是否可评估成本是否可治理反馈是否能反哺系统尤其是局部修复策略在质量提升的同时还能节省大量 Token 消耗这对于企业级落地非常关键。因为在真实团队里AI 工具不能只追求“效果惊艳”还要考虑稳定性、成本、可维护性和规模化使用。九、这套方法不只适用于测试用例也适用于更多 AI 内容生成场景虽然本次分享聚焦测试用例生成但“生成 → 评估 → 修复 → 学习 → 优化”的自进化范式并不局限于测试领域。它同样可以迁移到很多 AI 内容生成场景中比如代码生成自动化脚本生成接口测试用例生成缺陷报告生成测试报告生成需求文档生成技术方案生成知识库问答结果优化凡是存在“生成质量不稳定、人工修正成本高、需要持续优化”的场景都可以参考这套闭环思路。这也是本次分享最有价值的地方它不是单个工具能力的展示而是一套 AI 工程化落地范式。十、给测试团队的启发AI 测试真正要建设的是质量闭环过去我们谈测试智能化更多关注自动化执行、脚本生成、用例推荐、缺陷预测。但进入大模型时代后测试团队面临的新问题变成了AI 生成了很多内容谁来保证这些内容是可信的如果每次都靠人工审核那 AI 提效会被审核成本吃掉。如果完全不审核又很容易把低质量内容带进测试流程。所以未来测试团队建设 AI 能力时不能只建设“生成能力”还要建设“质量治理能力”。包括评估标准置信度机制自动修复流程人工兜底策略用户反馈学习版本级质量基线成本与效果监控只有这些能力配套起来AI 才能真正从“辅助工具”走向“工程体系”。结语AI 生成测试用例并不难难的是让生成结果持续变好。腾讯 PCG 工程效能专家张健带来的这次分享真正值得关注的不是某一个插件、某一个 Agent或者某一组效果数据而是背后的工程化思路用评估引擎看见问题用局部修复降低成本用用户反馈驱动学习用版本基线持续治理质量。当 AI 测试用例生成具备自进化能力后它就不再只是一个“帮测试人员写用例”的工具而有机会成为企业测试质量体系中的基础能力。对于正在探索 AI 测试落地的团队来说这场分享非常值得关注。因为它回答了一个很现实的问题AI 生成用例之后如何让质量持续进化