在快手持续推进研发效能提升的过程中，我们对测试阶段各环节的耗时进行了深入分析，测试用例设计阶段（即测试用例编写阶段）在整个测试周期中占据了13.69%的时间成本，与用例执行、回归测试并列为耗时最高的三大环节；这一数据揭示了传统测试模式下的瓶颈：测试人员将大量精力投入在重复性的用例撰写工作中，而非聚焦于更具价值的测试策略设计和缺陷挖掘。
在用例设计提效方面，快手此前主要通过KCase 平台的用例编写在线化能力进行优化。该方案实现了用例模板的规范化与标准化、多人协作编辑与版本管理、用例资产的结构化沉淀。
然而，这种模式本质上仍依赖人工逐条编写，效率提升存在明显天花板。面对快手业务的高速迭代和海量的功能需求，测试团队面临以下挑战：
2023年以来，以GPT系列为代表的大语言模型（LLM）在代码理解、逻辑推理和文本生成方面实现了质的飞跃。快手质量工程团队敏锐捕捉到这一技术拐点，从2024年正式开始启动AI生成手工测试用例的探索项目，目标是将「人工编写」升级为「AI生成 + 人工审核」的全新模式，释放测试人员的生产力。
快手智能用例生成系统从V1.0到V4.0的演进历程，涵盖从初期的Prompt工程探索（生成率8%），到Multi-Agent人机协作模式（生成率12%），再到知识增强策略（生成率35%），最终通过自检测与自进化实现突破性提升（生成率超60%）。目前，该系统已在快手实现公司级60%以上的用例生成率，累计生成测试用例逾120万条。
从8%到60%+的生成率跃升，体现了快手技术理念的持续演进：
1. V1.0：验证了“AI 能够生成测试用例”的可行性
2. V2.0：确立了“人机协作生成优于纯自动化生成”的实践路径
3. V3.0：揭示了“知识比算法更关键”的本质规律
4. V4.0：实现了“AI 自我进化”的能力突破
我们不再纠结于AI是否能够替代人类，而是为“AI如何赋能人类更高效工作”寻求解法。
三、实践1：
从V1.0到V4.0的技术架构演进实践
3.1.1 初版设计思路
3.1.2 核心技术实现
3.1.3效果测评
为了验证 Prompt 优化策略的有效性，我们针对多个关键动作开展了系统性测评。测评基于真实业务场景中的 PRD 和技术方案文档，采用统一测试集进行对比评估。
测评一：Few-shot Learning 效果验证
场景1：PRD 功能用例生成
典型改进案例：
场景2：技术方案用例生成
典型改进案例：
3.1.4 核心问题
尽管经过多轮优化，V1.0 仍面临三大难以突破的瓶颈：
3.2 V2.0版本：Multi-Agent 协作与人机交互阶段
3.2.1 设计理念转变
QA编写测试用例的真实思维过程并非“一步到位”，而是分阶段逐步推进的，具体如下：
1. QA 会先“拆解测试点（模块）”再“细化为具体用例”
2. 每个阶段都存在 Review 环节，便于及时纠偏
3. 若前期阶段出现偏差，后续将越走越偏
基于此，我们对于V2.0采用了新的设计思路，即模拟人类思维方式，引入Multi-Agent协作机制，并在关键节点支持人工介入。
3.2.2 Multi-Agent架构设计
3.2.3 核心 Agent
这一Agent的职责是，对多种格式的输入文档进行标准化处理，提取其中的有效信息。
这一Agent的职责是从清洗后的文档中提取测试点，生成结构化的测试模块树。
这一Agent的职责是，基于用户确认的测试模块，生成详细的测试用例。
3.2.4 效果测评
为验证 Multi-Agent 架构与人机协作机制的有效性，我们针对 V2.0 版本的关键动作开展了基于真实业务场景的系统性测评，从多个维度对比 V1.0 与 V2.0 的表现差异。
测试场景： 处理不同长度和复杂度的 PRD 文档
对比组：
测试场景： 基于预处理后的文档生成测试模块树
测评结果：
3.2.5 阶段总结
3.3 V3.0版本：知识工程阶段
3.3.1 设计动机
我们发现，V2.0遗留着一个核心问题，即生成的用例缺乏“业务深度”。
基于此，我们调整了V3.0的设计目标，即构建体系化的知识引入机制，使 AI 具备“懂业务”的能力。
3.3.2 架构设计
召回结果的价值：
1. 提供了详细的步骤参考（如“URL参数携带need_amount”）
2. 补充了业务规则（如“充值后自动返回”）
3. 最重要：带入了历史缺陷经验（并发重复扣款、支付超时重复订单）
3.3.4 效果测评
为验证体系化知识引入机制的有效性，我们针对 V3.0 的关键功能进行了基于真实业务场景的系统性测评，从多个维度对比 V2.0 与 V3.0 的表现差异。
典型改进案例：【直播礼物需求】
3.3.5 阶段总结
3.4 V4.0版本：自主性&自进化阶段
3.4.2 核心突破一：自主评审，Review-Critique 生成模式
传统的 AI 生成采用“单次直出”模式，类似于只会答题而不会检查的学生。为提升生成质量，需赋予 AI “自我反思”能力，构建“生成-评审-优化”的自主评审闭环机制。
关键设计理念：
Critic（判别）：AI 扮演“评审员”角色，对生成结果进行系统性审查并给出专业指导建议
Generator（生成）：根据评审意见自动调整与优化输出内容
离线异步：因多轮迭代耗时较长，采用后台处理结合通知机制，保障效率与响应性
阶段一：模块级评审->优化闭环（结构治理）
自主评审Agent —— 模块审查维度详解：
输出示例（未通过）：
阶段二：用例级评审->优化闭环（细节打磨）
自主评审Agent
输出示例（未通过）：
对比传统模式的提升：
3.4.3 核心突破二：基于测试计划的自进化场景规则模板
在 V3.0 阶段，为了让 AI 理解业务，需人工编写大量团队业务模板（业务已维护 170+ 套业务定制的团队模板），但该模式存在三大痛点：
1. 维护成本高：每个新业务场景均需人工梳理规则
2. 知识更新慢：历史缺陷经验无法及时同步至模板
3. 专家依赖强：需资深 QA 才能总结高质量模板
因此，我们的核心设计理念是让系统从历史数据中自动学习，实现隐性知识显性化。
我们构建了两种层级的自进化模板：
3.4.4 阶段总结
AI测试用例生成系统的成功，往往依赖于一套分层递进的架构体系。基于此，我们在实践中提炼出“四层架构”模型：场景分层 → 用户运营 → 知识运营 → Agentic架构，自上而下指导决策方向，自下向上提供能力支撑。
4.1 四层架构全景
我们的核心原则是不追求“全覆盖”，而是基于价值x复杂度矩阵进行精准突破。
4.3 用户运营 —— Badcase驱动闭环
Badcase是最好的老师，通过系统化收集与分析用户反馈，驱动持续迭代优化。
4.4 四层协同：从Badcase到系统进化
我们以一个Badcase如何驱动四层协同进化来示例。
【触发】用户反馈：直播送礼场景缺少“并发送礼”测试点
【第一层 - 场景分层】
判定：直播送礼属于“高价值”场景，值得深入优化
【第二层 - 用户运营】
Badcase分类：覆盖类问题
根因分析：知识库缺少并发场景的历史缺陷数据
【第三层 - 知识运营】
补充缺陷库：新增“并发送礼重复扣款”历史Bug记录
更新规则库：提取“支付场景必须验证并发”规则
自动更新模板：直播送礼模板中新增并发测试点
【第四层 - Agentic架构】
RAG检索：后续生成自动召回并发相关知识
Critique Agent：自动检查是否覆盖并发场景
【结果】同类Badcase不再出现，场景覆盖率提升至92%
核心启示：
自顶向下做决策：通过场景分层明确资源投入方向，确保战略聚焦
自底向上建能力：以Agentic架构支撑知识运营，推动能力持续沉淀与复用
Badcase是进化燃料：每个问题都是优化契机，形成“反馈→改进→提升”的持续进化飞轮
经过从V1.0 到 V4.0的持续演进，快手智能测试用例生成系统已完成了从「实验性工具」到「标准化生产力工具」的跨越。
然而，我们也认识到，测试效率提升空间远不止于「生成」环节，测试人员仍需投入大量时间在手工用例执行上，这是下一阶段的核心突破方向。未来，我们将核心突破聚焦于「AI 智能执行用例」场景，构建从用例生成到用例执行的全链路智能化能力。
具体包含如下三个方向：
粤ICP备14082021号
免费POC，
零成本试错
