DeepSeek测试用例提示词模板权威排行榜 2024

每次让DeepSeek生成单元测试，最终结果总是不够理想？不是遗漏边界值，就是缺失异常分支，参数组合覆盖全靠运气。说实话，问题多半不在模型本身，而在于提示词——你没有把测试维度和校验逻辑彻底锁死。

高质量单元测试必须锁定四个核心维度：正常路径、边界输入、非法类型、空值或零值特例。同时，交付的必须是带assert断言的可执行代码。对于多参数场景，利用笛卡尔积或等价类划分覆盖组合；异常测试则需要明确异常类型、触发条件，并用with pytest.raises进行断言。这些原则大家心里都清楚，但一旦让模型实操生成，结果就容易走样。

因此，本文的核心是：如何设计提示词，让DeepSeek一次性生成高质量、可直接运行的测试用例。

基础测试用例生成（单函数场景）

第一步，把函数签名和业务行为交代清楚。很多人只写一句“帮我写个测试”，DeepSeek按通用模板填充，最终生成的用例大概率忽略你代码里的None检查或浮点精度容忍逻辑。正确做法是：把原始函数完整粘贴进去，别偷懒。

第二步，在提示词里强制锁定四个测试维度。举个例子：你要为def parse_int(s: str) -> int写pytest用例，就在提示词中明确要求覆盖——有效数字字符串（如'123'）、带正负号（'-45'）、空字符串和None这类边界情况、含字母的乱码（'abc7'），以及超长整数字符串（能触发OverflowError的那种）。不这样写，DeepSeek大概率只给你生成两三个常规用例。

第三步，要求输出带断言语句的完整可执行代码块。这一步容易被忽略，一旦漏掉，DeepSeek可能只返回测试思路，连一行assert都没有。直接在提示词里写明：“请输出完整可执行的Python代码，包含pytest框架的assert断言”。

多参数组合覆盖（接口级测试）

处理多个参数的接口测试时，有两种实用方法。

方法一，用笛卡尔积思维写约束。比如你要测试POST /v1/orders接口，参数包括user_id（int）、items（list[dict]）、discount_code（str | None）。在提示词里直接组合：user_id取0、1000、999999；items取空列表、[{'id':1,'qty':1}]、[{'id':1,'qty':0},{'id':2,'qty':-1}]；discount_code取None、'VIP2024'、'INVALID'。这样生成的用例数量可控，且覆盖全面。

方法二，用等价类划分法压缩用例量。直接告诉DeepSeek：“不要穷举所有组合，按等价类合并。user_id取负数、0、正数三类；items取空、单合法项、含非法qty三类；discount_code取None、有效码、过期码三类。最终生成的用例不超过12条。”这样既保证覆盖度，又避免用例爆炸。

关键前提：必须提供接口的OpenAPI Schema或字段校验规则原文。否则DeepSeek不知道哪些是业务上的非法值——比如discount_code长度超过20才报错，它只能基于Python语法做泛化判断，结果自然不准。

异常路径专项测试（容错验证）

异常测试的写法，很多人容易踩坑。最直接的写法是：锁定异常类型、触发条件、断言方式。比如为数据库连接函数connect_db(host, port, timeout)写测试，明确要求——当host为空字符串时抛出ValueError，用with pytest.raises(ValueError)捕获；当port=0时抛出OSError；当timeout<0时抛出TypeError。而且每条用例必须包含具体的异常消息匹配，比如match='timeout must be positive'。

这一步最容易被忽略：很多人写了异常测试，但没加match参数，结果测试只是“是否抛异常”，根本没验证错误提示是否符合团队规范。DeepSeek默认不会生成match，你必须明确指定。

如果原函数用的是logging.error而不是raise，那就换指令：“验证当host不可达时，是否调用logging.error且消息含'connection refused'”。用caplog fixture捕获日志并断言。

来源：互联网