采纳率从3%到80%：智能单元测试生成的进化之路

在《生成率从8%到60%：快手智能测试用例生成系统的四阶进化》中，快手研发效能团队重点分享了在「用例生成」环节的探索与实践，显著提升了测试阶段的自动化与覆盖能力。在此基础上，团队正逐步将智能化的触角从测试环节延伸至代码质量的源头防线——单元测试。业务高速迭代往往伴随着代码质量风险，作为保障快速交付稳定性的基石，单元测试的重要性不言而喻。但在业务高速迭代的背景下，传统人工编写模式长期受困于人力投入产出比失衡、覆盖率与有效性双低、工具辅助有限导致“治标不治本”的三大痛点，严重制约了研发效能的进一步跃升。

尽管AI生成被视为破局关键，但随之而来的“智能单测生成可用性危机”却成为新的拦路虎。面对这一挑战，本文将分享快手研发效能团队如何通过智能单测架构的多次演进升级，成功将采纳率从3%提升至80%的实战之路，进一步探索如何将个人层面的AI提效转化为组织级的交付效能。

一、背景

1.1 效率与质量的博弈：传统编写单测模式的固有痛点

在快手高速迭代的业务场景下，代码质量和交付速度的平衡面临严峻挑战。传统的人工编写单元测试模式存在三大核心痛点，严重制约了研发效率和质量保障能力。

• 人力投入产出比失衡，开发者“苦不堪言”：根据对业内的调研发现，如果想写好单测，其所需时间与编写业务代码相当甚至更长。在快手内部对单测要求严格的团队中，经常出现“半天写业务代码，一天写单测”的极端场景。这种“一行代码，十行单测”的情况严重拖慢了业务交付速度，开发者也普遍对编写单测感到枯燥乏味，缺乏动力。
  

• 覆盖率与有效性双低，质量保障“形同虚设”：快手单测现状充满挑战，单测接入率仅20%，全量单测覆盖率仅24%，增量单测覆盖率40%。相比业界领先水平存在显著差距。这种低覆盖率意味着大量代码变更缺乏最基本的质量保障，埋下线上隐患。
  

• 工具辅助能力有限，“治标不治本”：现有单测生成工具（如TestMe等插件）只能提供基础的测试模板，核心的覆盖逻辑、断言设计和复杂对象构建仍需人工完成。这种“半自动化”模式无法从根本上解决单测编写的效率和成本问题。

1.2 AI的引入与新挑战：如何突破“生成可用性”瓶颈 

面对传统单测模式的困境，AI生成被视为必然出路。然而，在初期探索过程中，我们遭遇了典型的AI单测生成可用性危机，主要表现为：

• 代码调用信息缺失：AI 基于被测方法获取的信息有限，在对方法进行mock时缺失参数、返回值类型等，导致import部分出现大量幻觉；

• 生成代码质量不稳定：直接使用通用大模型生成的单测代码存在大量语法错误、编译问题和运行时异常，需要开发者花费大量时间调试和修复，反而增加工作量；

• 场景覆盖不全面：AI生成倾向于“安全”的正常场景，对边界条件、异常情况的覆盖不足，难以满足质量保障要求；

• 集成体验割裂：现有AI编码工具多为独立对话式界面，无法无缝融入快手现有的研发流程（流水线、IDE开发环境），使用门槛高；

这些问题导致初期AI单测生成采纳率低，开发者普遍持观望态度，工具价值难以体现。

二、效果

快手智能单测生成系统从1.0到3.0的演进历程，涵盖从初期的启发式生成，再到场景分组+异常智能修复，最终到知识、规则驱动。目前，该系统在快手内部每日成码10w+行，采纳率可达到80%。

• 单侧代码生成质量

AI生成单测的代码质量取得显著提升，为质量保障提供坚实基础：

• 采纳率：3%→80%

• 编译通过率：30%→99%

• 执行通过率：10%→89%

• AI生成单测的覆盖率：38.38%→80.12%

• 研发效率大幅提升

通过用户回访显示，单测生成效率相比人工编写提升3～5倍，可将开发者从重复的测试代码编写中解放出来，聚焦于更有价值的业务逻辑和创新工作。

• 规模化落地

周采纳代码行数从2千行增长至35万行，使用量从周均15次增长至300次。这表明工具已从“可用”走向“好用”，广泛获得开发者信任。目前已接入42.5%的研发仓库, 支持日均生成代码10w+行。

三、实践1：核心技术实现

——从简单生成到智能工作流的演进

工具不仅要能生成代码，更要生成可直接使用的、高质量的、符合业务场景的单元测试，实现从生码到入仓无干预——这是在智能单测生成系统的建设过程中，快手始终秉持的核心理念。

整个系统经历了[prompt工程探索] →[多轮异常修复+合并优化] →[知识构建+规则召回]三个阶段，现已基本实现生码到入库无干预的愿景，持续提升生码质量和采纳率，进而推动系统向更高可用性和实用性迈进。

3.1 智能单测1.0：纯LLM启发式单测生成（探索）

为解决人工编写单测痛点，我们在2025年Q2进行了引入LLM进行单测生成的初步探索，整体架构采用“目标方法识别+场景分析+AST解析+单测生成”的基础流程。

3.1.1 核心流程 

步骤1：目标方法识别

• 目的：快速识别目标方法，降低用户负担

• 做法：

• 基于git diff分析识别待测分支和基线分支的差异，提取新增/修改的方法

• 解析jacoco文件，进一步筛选目标方法

步骤2：AST解析

• 解析目标方法调用的下游方法，获取下游方法的全限定名，用于作为import

• 提取同类的私有调用方法

步骤3：场景分析

• 理解逻辑: LLM理解目标方法+私有调用方法代码逻辑

• 任务规划：基于AI理解代码逻辑，分析不同测试场景（正常、边界、异常），生成测试用例规划

步骤4：单测生成

• 基于标准模板生成测试方法

• 生成基础的Mock对象和断言语句

• 将生成的测试代码合并到现有测试文件中, 处理简单的代码冲突

3.1.2 核心问题 

• 生成代码稳定性差

• 频繁出现语法错误、编译失败等基础问题，代码可用性低，大量语法错误需要人工修复

• 未考虑编译错误、运行时异常等问题的自动修复

• 无法解决多个case的合并冲突

• 上下文缺失

• 没有获取代码信息的工具，所有信息来源只有AST解析和被测方法内容

• 三方包中的代码信息无法获取

• 对于非同类的方法调用，无脑mock

• 无法适配kconf、kswitch等私域中间件的mock

• 给模型的指令缺乏Know-how，过于依赖模型自主理解

• 能力缺失

• 无法支持私有方法、抽象类方法等特殊场景的单测生成

3.1.3 阶段总结

• 数据表现：单测代码采纳率3%，生成的代码出现大量无法编译的情况，编译通过率不足40%。

• 技术验证：证明了 AI 生成单测的技术可行性，但暴露了简单串联流程的严重不足。

• 演进方向：

• 重构整体流程，加入代码异常修复机制，提升代码质量；

• 引入代码和jar包的查看工具，补充上下文；

• 引入智能分组策略+工程解决，用于提升代码合并效果。

3.2 智能单测2.0：场景分组+多轮异常修复

针对V1.0阶段单测质量不稳定、编译错误多、执行失败率高的问题，我们进行了系统性重构，引入“单测场景分组+多轮异常修复”的创新架构。多轮异常修复用于提升单个case的质量，场景分组则有效地避免了大量的合并冲突。两者的互补大幅度提升了单测代码的质量，实现了从可生成到信任使用的跨越。

3.2.1 单测合并

合并单测的难点：

• 多个被测方法属于同一个类文件，每个被测方法都会生成大量的单测

• 合并时要包含已有单测，必须保留用户早期单测

• 单测生成阶段除了生成大量的单测方法，还会有单测的前置和后置方法

• 如果代码中有长json，经过模型处理后会出现json文件被修改而无法反序列化的问题

• 将以上内容合并为一个文件，并且有逻辑和语法冲突

  
  

（1）规划阶段：在待测方法和场景类型（正常场景、边界场景、异常场景等）层面上进行分组

• 场景类型分组

• 正常场景组：验证基本业务逻辑

• 边界场景组：测试参数边界条件和极端情况

• 异常场景组：验证异常抛出和错误处理

• 逻辑相似性分组

• 共享相同Mock对象的用例归为一组

• 使用相似断言模式的用例归为一组

• 需要相似数据准备逻辑的用例归为一组

优势：

• 相近逻辑批量处理：相近方法（例如某个方法的多个边界用例）有着相近的代码逻辑（Mock逻辑、断言方法等），也容易出现类似的问题（例如某个类Mock错误）。分组策略让这些相近方法生成和修复都在一起，实现通用逻辑的抽取以及批量修复问题。

• 减少重复工作：相似场景共享setup/teardown逻辑，避免重复代码生成

• 代码结构清晰

• 组织清晰：不同方法和不同场景的笛卡尔积会让单测方法数量很大，也难以维护和理解；分组策略按逻辑组织测试代码，结构清晰易懂。

• 可维护性增强：每个分组独立，修改和调试时影响范围明确。

（2）生成阶段：按照规划阶段对每个分组进行生成，一个分组对应一个nested class，组内的单测方法共享前置后置方法。

（3）合并阶段：会通过语法树对已有单测和新生成的大量单测文件进行合并。

• 使用JavaParser解析现有单测文件和新生成的单测文件

• 将多个类通过nested class的方式合并在一个语法树中，nested class内的前置后置方法共享，对外互不影响（方法合并→内部类合并)

  
  

• 收集所有的import块，并对其进行去重、排序，然后注入到语法树中

• 编译检测，如果发现问题，通过模型优化

优势

• 用户代码零修改：AST操作确保手写代码完整性

• 结构正确性：语法树操作避免大括号等结构错误

• 内容保护：长文本保护机制防止AI幻觉破坏

3.2.2 多轮异常修复

在生成单测的过程中，上下文信息缺失和模型幻觉往往导致代码出现语法错误或编译失败等基础问题，这导致代码可用性低，且人工修复成本高昂。鉴于覆盖率是评估单测效果的核心指标，而该指标的获取严格依赖于代码的可编译性与可执行性，这就要求我们必须生成“零错误”的代码。既然依赖模型一次性生成完美代码并不现实，我们便转而采用多轮次修复的方式，通过反复迭代来打磨代码质量。

（1）编译修复阶段

• 建立“执行-反馈-优化”的持续迭代机制

• 采用javac进行单文件编译

• 对错误类型分组，每轮只修复特定类型问题

• 多个位置暴露同类问题，更有利于定位原因、修复

• 避免上下文过载

• 可批量修复

• 成功修复的方法不再参与后续轮次

• 达到质量阈值或最大轮次时自动终止

• 编译错误大多是类型不匹配、方法不存在、import缺失，可通过调用代码查看工具快速解决

（2）执行修复阶段

• 同样采用“执行-反馈-优化”的持续迭代机制

• 执行过程为了避免影响线上业务，采用沙箱环境执行（staging)

• 执行错误大多是mock造成的，在本阶段没有达成很好的效果，会在V3.0阶段基于规则和知识解决

3.2.3 并发生成

由于多轮修复大幅度拉长了主流程，使单测生成从单方法5分钟提升到了20分钟，严重影响了用户体验。因此，生成过程可以采用并发流程，以此降低生成时长。

3.2.4 远程沙箱执行

由于产品形态的变更，用户不再通过流水线的方式生成单测，而是在本地通过IDE插件的交互生成。但是为了保证安全，单测生成的过程依然需要借助流水线这种天然沙箱作为运行环境，这就带来一些新的挑战，例如用户不再基于某个提交记录（commit）生成代码，而会包含一些本地未提交的新代码，我们需要把本地代码搬到远端。

获取变更方法列表（用于默认目标方法）：

• 基于当前代码与远端仓库的最新commit做对比

• 基于IDE能力获取当前代码的方法位置信息

• 基于IDE能力获取当前代码与对比commit的git diff信息

• 在远端沙箱中基于一个commit和git diff内容拼出最新代码

IDE工具与系统交互图

3.2.5 阶段总结

通过系统性优化合并过程、增加编译和执行修复机制，V2.0架构从根本上解决了V1.0的核心问题，大幅度提升了单测的代码质量，实现了评论采纳率从3%到38%的跨越式增长，重建了开发者信任。

3.3 智能单测3.0：从模板生成到知识、规则驱动的全链路增强

智能单测2.0虽已显著提升代码生成质量，但在实际应用中依然面临三大核心挑战，制约了开发者采纳率。

(1) 生成过程深度理解不足

上下文的获取主要采用工程化预定义策略，加上粗粒度查看代码工具调用的辅助，缺乏更细粒度运行时自适应能力。生成过程多为“所见即所得”的模板填充，缺乏对被测方法内部逻辑、外部依赖关系的深度理解，导致生成的单测覆盖度低、断言价值不高。借助查看代码工具调用试图解决这类问题，但通常会拿到过多的信息，缺乏提炼有效信息的能力，导致信息效率很低，大量无关信息会造成token成本过高并且干扰注意力。

(2) 复杂场景缺乏

对于私有方法、抽象类、复杂依赖链等场景，现有工具难以给出合理的Mock方案和测试构造方法，常常生成无法直接运行的“半成品”。

(3) badcase优化陷入僵局

当生成结果出现缺陷（如错误的Mock、不合理的断言）时，缺乏高效的优化途径。我们只能“打补丁”式地调整通用提示词，但这种全局调整往往在修复一个旧问题的同时，引发新的未知问题，陷入“按下葫芦浮起瓢”的困境，系统质量无法持续、稳定地提升。

为此，我们设计了新一代“规则与知识双驱动” 的智能单测生成系统。构建 “生成前深度分析 + 生成中精准Mock + 失败后智能修复” 的全链路增强框架，从根本上解决理解深度与BadCase优化的难题，实现从“生成代码”到“生成高质量、可直接使用代码”的根本性跨越。

3.3.1 代码分析阶段：构建深度代码知识库

代码分析阶段的目标是基于工程化的手段，将代码仓信息进行结构化，提炼包括调用关系、方法特征等信息，实现对代码仓库的深度理解与结构化建模，为后续代码检索工具和规则召回提供可能。

输入：

• 源代码仓库：包含完整的源代码文件。

处理过程：

• 多维度静态分析

• 语法分析：解析AST（抽象语法树），提取基础代码结构

• 语义分析：理解类型系统、继承关系、接口实现

• 特征分析：公司内部的中间件（kconf、kswitch)

• 调用关系：构建整个代码仓库的调用关系图（call-graph)

• 知识提取与建模

• 从原始代码中提取关键信息要素

• 建立信息间的关联关系，形成结构化知识图谱

输出：结构化代码知识库。

迭代方式：基于知识提取需求，扩展知识构建算法。

3.3.2 生成阶段：规则与知识驱动的智能测试生成

基于代码知识库和规则召回，明确生成中的具体指令，为单测生成高质量、可直接执行的单元测试代码提供可能，重点解决Mock方案生成、特殊场景适配等传统难题。

输入：

• 被测方法：需要生成单元测试的目标方法

• 代码知识库：第一阶段构建的结构化代码知识

处理过程：

• 被测方法性质分析

• 知识查询：从知识库获取被测方法的元信息

• 性质判断：判断是否在抽象类、是否为private方法、是否为静态方法等

• 规则召回：基于性质从规则库召回相应的生成规则

• 框架指导：规则指导测试框架选择与测试类构造方法

• 下游方法分析

• 依赖识别：从知识库获取被测方法调用的所有下游方法

• 知识提取：为每个下游方法获取其完整知识信息（类型、行为、复杂度等）

• 规则智能召回：基于下游方法知识信息召回针对性的Mock规则

• Mock方案生成：将知识+规则+代码输入生成模型，输出定制化Mock方案

• 简单工具方法 → 使用真实对象

• 外部服务调用 → 使用Mockito.mock并设置返回值

• kconf→ 使用公司内部框架mock，并给出mock所需信息

• 上下文注入生成方案, 完成单测生成

输出：高质量单测方法

迭代方式：基于badcase补充新的规则。

3.3.3 修复阶段 - 基于执行反馈、修复规则生成修复建议

在V2.0版本中，针对异常代码，已经形成“生成-执行-修复”的完整质量闭环，但由于缺少足够的上下文信息，在多轮修复后依然难以生成正确的代码。在V3.0版本中，会基于错误信息发起召回，基于代码片段和规则生成修复建议。系统能够智能诊断失败原因，并提供精准、可直接应用的修复方案。

输入：

• 执行失败信息：单元测试运行时的报错信息、堆栈跟踪

• 代码知识库：第一阶段构建的结构化代码知识

• 原始生成的测试代码：需要修复的测试代码

处理过程：

• 执行测试与捕获报错

• 自动执行生成的单元测试

• 捕获各类失败信息：编译错误、运行时异常、断言失败等

• 标准化错误信息格式，提取关键特征

• 智能分类与根因分析

• 错误分类：基于错误模式识别错误类型

• 空指针、类型转换异常、Mock配置错误等

• 根因定位：结合堆栈信息与知识库，定位错误根本原因

• 上下文动态增强

• 工具调用：调用代码分析工具获取深层上下文

• 信息补充：

• 相关类的完整定义

• 调用链的完整路径

• 类型系统的详细信息

• 规则召回与修复生成

• 规则召回：基于代码知识+错误信息+工具结果召回匹配的修复规则

• 修复方案：执行召回规则，生成具体的代码修复建议

• 执行修复：基于修复建议修改代码

输出：修复后的单测方法。

3.3.4 阶段总结 

当前的整体架构

效果提升

四、实践2：产品运营策略

——试点MVP到无缝接入开发

解决的问题：

• 如何让开发者无感接入，降低使用门槛

• 如何无缝融入开发过程，降低产品间的割裂感

• 如何从试点到规模化推广，建立用户信任

4.1 第一阶段：极速跑通，快速验证 —— 流水线集成

• 核心目标：快速验证AI生成单测的技术可行性，建立质量基准线

• 产品形态：作为CI/CD流水线中的一个自动化节点，在代码开发完成后自动生成单元测试

• 基于开发分支和基线分支自动识别变更方法

• 流水线作为天然沙箱，提供了与外界的隔离环境

• 基于代码分析+LLM能力的单测生成

• 生成一个临时分支，提交到代码仓库

• 核心特性：

• 零配置自动触发：基于分支变更自动识别需要生成单测的方法

• 批量处理模式：一次运行生成所有变更方法的单元测试

• 分离式工作流：在独立的AI单测分支中生成代码，避免干扰开发过程

• 痛点：

• 流程割裂：单测生成与开发过程分离，需要切换到不同工具和分支

• 控制感弱：用户无法选择生成哪些方法的单测，无法实时调整

• 调试困难：问题修复需要在AI分支中操作，与开发分支隔离

• 心理负担：生成的代码量可能很大，审查压力大

4.2 第二阶段: 体验优化——IDE插件形态

• 核心目标：将AI单测能力深度集成到开发者工作中，提供即时、可控、无缝的生成体验

• 设计理念转变：从“自动化工具”到“开发助手”，从“批量处理”到“精准交互"

• 产品形态

• 从流水线变成了IDE插件，在目标方法选择、生成代码采纳上赋予了用户更多的选择

• 为了保证安全可靠，整个生成过程依然运行在沙箱中

• 方法智能选择

• Git变更检测：自动识别相对于远程分支的代码变更

• 文件级选择：支持基于文件选择待测方法

• 方法级精准：用户可以精确选择需要生成单测的具体方法

• 渐进式采纳机制：预览→选择→合并文件→diff对比→应用

• 非侵入式预览：生成结果不会直接修改代码，提供完整预览

• 选择性采纳：用户可以勾选需要的方法逐个采纳

• 安全回退：支持重置操作，随时撤销采纳的变更

• 用户体验优化

• 降低认知负担

• 渐进式交互：将复杂的单测生成过程分解为简单步骤

• 可视化反馈：清晰的进度指示和结果展示

• 上下文保持：在IDE中完成所有操作，无需切换工具

• 增强控制感

• 每一步都可控：从方法选择到结果采纳，用户全程主导

• 随时可中止：在任何步骤都可以取消或重新开始

• 选择性应用：可以只采纳高质量的单测，忽略有问题的

• 提升效率

• 免分支切换：直接在开发分支中操作

• 集成调试：生成的问题可以直接在IDE中调试修复

4.3 用户运营：Badcase驱动闭环

Badcase分类与解决路径

闭环运营流程

具体案例

五、展望

快手智能单元测试生成的实践，已成功将覆盖率从24%提升至80%，并赢得了开发者的广泛信任。然而，这并非终点，而是一个更高阶的起点。AI驱动的研发效能革新，其潜力远不止于自动化编写测试代码。未来，我们将围绕 “更精准、更智能、更前置、更普惠” 的核心方向，推动技术、产品与研发文化的全面演进，致力于将智能测试能力从“提效工具”进化为“质量伙伴”。

5.1 迈向“精准诊断”：从覆盖率提升到缺陷主动发现

当前系统已能高效生成高覆盖率的单测，但未来的核心价值将超越“覆盖”，聚焦于 “精准”。

• 断言智能增强：突破当前基于行为模仿的断言生成，通过分析业务逻辑契约、数据流与异常传播路径，生成具有语义理解能力的“黄金断言”，不仅能验证代码执行正确，更能验证业务意图正确。

• 测试用例价值评估：引入测试用例的“独特价值”评估体系，智能识别并清理冗余、无效的测试，优化测试套件，在保持高覆盖率的同时，提升测试集的执行效率和维护性。

5.2 深度融合与流程重塑：从辅助工具到内生智能流程

未来的研发工具不应是割裂的“外挂”，而应是深度融入研发心智与流程的“内生智能”。

• IDE深度智能协同：将单测生成与IDE的代码诊断、实时调试、代码补全能力深度融合。实现“编码即伴随测试”的体验，在开发者编写业务代码的同时，智能推荐测试用例结构与断言，提供实时反馈。