通义千问单元测试提示词优化：覆盖异常场景的完整方案

写单元测试最怕什么？精心编排提示词后，AI只跑通Happy Path就收工——边界值如折扣0%、价格0、空字符串统统遗漏，异常输入像负数、折扣超100%、None参数直接被忽视，测试覆盖率卡在40%彻底停滞。问题不在提示词数量，而是缺少硬性约束。下面这套指令框架，能让通义千问老老实实覆盖全部三类用例。

强制覆盖三类用例的提示词结构

第一步：在待测函数代码正上方，明确声明测试框架及用例分类要求；第二步：用数字序号逐条列出必须覆盖的场景类型；第三步：为每类场景补充至少一个具体示例，杜绝AI自由发挥漏掉关键节点。例如不要只说“覆盖边界情况”，而要写成：“② 边界值：必须包含折扣0%（返回原价）、折扣100%（返回0）、商品价格为0（返回0）三个用例”。操作时直接粘贴函数定义，前面加上带编号的硬性指令即可。AI对数字序号的识别准确度远高于“包括但不限于”这类模糊措辞。

方法一：用自然语言描述反推测试数据

通义千问在解释函数行为时，经常主动输出类似“当original_price=0时，函数返回0”这样的句子。这些不是废话——它们是【可直接提取为断言的黄金数据源】。定位回复中所有“当……时，返回……”“例如……输出……”“输入……得到……”结构的句子，逐句提取输入参数与预期结果，然后按Python元组格式整理成test_cases列表。例如它写“当discount_percent=150时，抛出ValueError”，你就该生成一条assertRaises语句，而不是忽略提示另编一个异常用例。

方法二：绑定项目已有测试风格

如果你的项目里已存在test_calculate.py，每个测试方法都带fixture setup和详细中文注释，那就别让千问凭空造轮子。直接告诉它：“请严格按当前项目中test_*.py的格式续写，包括fixture命名（如setup_discount_calculator）、assert写法（使用pytest.approx处理浮点）、注释密度（每个测试方法前必须有3行中文说明）。”AI一旦被锚定在真实上下文里，就不会默认只写最简的test_开头的空壳函数。

方法三：注入防御性约束条款

在提示词末尾追加一条不可绕过的硬约束：“所有测试文件必须包含test_invalid_negative_price、test_discount_over_100_percent、test_empty_string_input三个方法名，缺一不可。”这个动作相当于给AI设了一道闸口——它无法跳过这三个名字去生成其他测试，哪怕逻辑上觉得没必要也得先建好空方法。【注意：方法名必须完全匹配，大小写和下划线都不能错，否则生成的文件无法被pytest自动发现】