AI 单元测试生成：自动补用例

写测试常被当成「顺手但枯燥」的活：同样的断言框架、相似的构造代码，重复又容易漏边界。AI 单元测试生成正是针对这种高重复、模式化的任务：给它一个函数，它能吐出一组可运行的测试用例，把人从样板劳动里解放出来，专注于真正需要判断的测试策略。

为什么用 AI 写测试

• 覆盖边界：模型容易补出人容易忽略的空值、越界、异常分支等用例。
• 省时：对遗留代码或大量小工具函数，AI 可批量产出初版测试，人只需审阅。
• 降低门槛：新人能借生成的用例快速理解函数契约与预期行为。

但它是「加速器」而非「担保人」：生成的测试必须通过人的审阅才能真正进入代码库。

输入与输出

典型流程是：把函数签名、实现与依赖上下文喂给模型，要求它输出带断言的测试文件。

# 被测试函数
def divide(a, b):
    if b == 0:
        raise ValueError("b 不能为 0")
    return a / b

# AI 生成的测试（示例）
def test_divide_normal():
    assert divide(10, 2) == 5

def test_divide_zero():
    import pytest
    with pytest.raises(ValueError):
        divide(1, 0)

输入越完整（含类型注解、docstring、调用示例），输出质量越高。

如何提升覆盖率与边界用例

• 给上下文：连同周边调用与既有测试风格一起提供，生成的用例更贴合项目。
• 要求枚举边界：明确让模型列出空输入、极大值、类型异常等情形。
• 迭代修正：先生成、跑通、再要求「补当前未覆盖的分支」，逐步逼近目标覆盖率。

局限：仍需人工校验

最大的坑是模型可能「编造」——调用项目中并不存在的 API、误读函数语义导致断言错误，或生成看似通过实则无意义的测试（例如永远为真的断言）。因此每条生成用例都要核对：是否真的对行为做了有效约束、是否依赖了虚构接口。AI 生成测试的价值在于「提供草稿」，而非「免审」。

小结

AI 单元测试生成依据函数签名与实现批量产出覆盖边界与异常的初版用例，能显著降低样板劳动、提升覆盖率起点。但它可能编造不存在的 API 或写出无效断言，必须经由人工校验语义与依赖后才可入库。把它当「测试草稿生成器」，而非免审的测试来源。

参考与延伸阅读

• 代码大模型在单元测试生成上的研究（如基于覆盖反馈的迭代生成）近年持续出现，具体方法与开源模型以各项目为准。待核实。
• 将 AI 生成测试接入 CI 时，建议关注「生成、跑通、人工复核」的闭环，相关实践见各测试框架文档。待核实。