围绕DeepSeek辅助单元测试的落地流程，拆解上下文准备、用例生成、断言校验与CI回归，给出可复用的实战方法。
单元测试常被业务进度挤压，开发团队更愿意写集成测试或直接手工验证，结果是把缺陷发现推迟到联调阶段。DeepSeek的价值不在于替代测试设计，而在于把代码理解、用例草拟、边界枚举和断言审查做得更快，让工程师把精力放在业务规则确认和测试质量判断上。以下四个环节来自实际项目与AI指导教学中的反复验证，重点讨论如何让生成的测试可执行、可审查、可回归。
1. 明确测试边界与上下文准备
使用DeepSeek做单元测试的第一步不是写提示词，而是界定测试对象和上下文边界。一个函数往往依赖配置、数据库、远程服务和时间因素，如果直接要求模型“为这个文件生成测试”，它很容易假设不存在的返回值，或者遗漏关键异常路径。实际项目里应先把目标源码、接口契约、相邻模块的调用、既有测试样例和运行框架一并提供，并明确哪些依赖需要Mock、哪些行为属于本次测试范围。比如订单折扣函数 calculateDiscount 的入参包括 amount、userLevel 与 coupon，业务规则涉及满减门槛、优惠券过期、等级折扣互斥和金额精度，这些规则如果不写进上下文，模型生成的用例看起来完整，断言却可能偏离真实业务。
上下文准备还要控制粒度。把整个仓库丢给模型并不会提升质量，反而会稀释关键信息，比较稳妥的做法是按模块分批提供目标文件、直接依赖和两到三个既有测试样例，让模型学习团队的命名习惯、断言风格和fixture组织。提示词中应说明测试框架是pytest还是JUnit、是否使用参数化、异常断言采用哪种写法、覆盖率关注行覆盖还是分支覆盖。在AI指导老师的教学场景里，我会让学员先手写一份测试意图清单，列出正常路径、边界值、异常输入和依赖失败四类场景，再让DeepSeek补全用例。这样模型输出的是清单的扩展，而不是脱离业务规则的随机填充，后续审查也有明确依据。
2. 用例生成中的提示词与覆盖策略
用例生成的质量取决于提示词是否把覆盖策略说清楚。有效的提示词通常包含角色、目标、输入约束、输出格式和验收标准，例如要求模型按正常、边界、异常、状态组合四类组织用例，每条用例注明覆盖的业务规则和预期结果，并优先使用参数化减少重复代码。以折扣函数为例，可以让DeepSeek枚举金额为零、金额为负、刚好达到满减门槛、优惠券已过期、用户等级未知、折扣叠加冲突和浮点精度边界等场景。模型往往能快速给出大量输入组合，但其中不少是重复或不可执行的，工程团队需要把生成结果映射到代码分支，检查每个条件判断是否至少有一个用例命中，而不是只看用例数量。
覆盖策略要避免“为覆盖率而覆盖率”。行业实践通常把核心业务模块的分支覆盖目标设在70%到80%，再对支付、权限、金额计算等高风险路径提高要求，而不是盲目追求100%行覆盖。DeepSeek适合承担第一轮用例扩展，人工则负责去重、补充业务语义和删除无法稳定复现的用例。教学时可以安排一个对比练习：学员先写十到十五条手工用例，再让模型生成候选集，然后把两组用例合并去重，标注模型遗漏的异常路径和模型多出的无效组合。这个练习能直观看到，模型擅长枚举常见边界，但对隐含业务约束和跨模块状态依赖仍需要人来判断，提示词里加入“每条用例必须说明对应规则”会显著减少空泛输出。
3. 断言、Mock与可维护性审查
生成测试最容易出问题的地方是断言太弱。只断言函数没有抛异常，或者只检查返回值不为空，无法证明业务规则正确。审查时应要求断言具体到返回值、异常类型、异常消息、依赖调用次数和关键参数。以折扣函数为例，优惠券服务返回过期时，测试不仅要断言最终金额等于原价，还应验证是否记录了降级日志、是否没有调用折扣叠加逻辑。DeepSeek可以辅助生成这些断言，但必须由熟悉业务的人确认预期值。Mock的使用同样需要审查，外部HTTP服务、数据库、当前时间和随机数都应被隔离，过度Mock会把测试变成对实现细节的复刻，一旦重构就大面积失败，Mock不足则会让单元测试变成不稳定的集成测试。
可维护性审查关注命名、数据构造和测试独立性。模型生成的测试常出现魔法数字、重复的初始化代码和测试间共享状态，应改为fixture、工厂函数或参数化表格。命名要能表达场景和预期，比如“过期优惠券不参与折扣计算”比“test_discount_2”更有信息量。在AI指导老师带教时，我会让学员维护一份测试代码评审清单，逐条检查断言是否覆盖业务规则、Mock边界是否合理、是否存在时间依赖、是否能在随机顺序下独立运行。对生成测试还要保留来源标记和审查记录，明确哪些用例由模型草拟、哪些经过人工修改，这样后续维护时不会把模型假设当成业务事实。审查不是否定生成结果，而是把模型输出转化为团队可长期维护的测试资产。
4. 嵌入CI与回归验证的工程化落地
生成出来的测试只有进入持续集成流水线，才会真正产生回归价值。落地时先把DeepSeek生成的用例放入独立目录或标记为候选测试，在本地和合并请求流水线中运行全量单元测试，并观察覆盖率变化、失败率和执行时长。比较稳妥的做法是设置两周左右的观察期，记录误报和漏报，再决定是否把候选测试纳入阻断规则。流水线中可以要求核心模块分支覆盖率不低于既定阈值，使用pytest-cov或JUnit报告输出覆盖明细，命令如pytest –cov=src –cov-report=term-missing可以快速暴露未覆盖文件。对金额计算、权限判断等高风险模块，还可以引入变异测试工具检查断言是否真正有效，避免测试虽然通过却无法发现人为植入的缺陷。
回归验证不能只依赖一次生成。当测试失败时，把失败日志、最小复现输入和相关代码片段反馈给DeepSeek，让它提出修正建议，再由工程师判断是测试预期错误还是实现缺陷。CI中应区分快速单元测试和完整回归，提交阶段运行目标模块测试，合并请求阶段运行全量测试并生成覆盖率对比报告。某团队曾把生成用例先放在tests/generated目录，只报告不阻断，两周后发现大部分失败来自环境时间未Mock和断言过严，修正后才纳入合并门槛。这种渐进式落地比一次性全量接入更稳，也让团队逐步建立对生成测试的信任。DeepSeek承担的是加速草拟和辅助定位，工程化流程负责验证、隔离和持续反馈，二者结合才能让单元测试从一次性任务变成可持续的质量防线。
