Gemini测试用例清单提示词编写指南：全面覆盖异常路径的5个关键技巧
要让Gemini生成的测试用例清单真正覆盖代码中的异常路径，不能只靠“写几个异常测试”这种模糊指令——那样它多半会编造出根本不会发生的if分支。必须把异常类型精准绑定到代码中实际抛出错误的位置和触发方式，才能产出有效用例。
第一步：锚定异常触发点
在提示词开头直接贴上目标函数的完整代码，重点保留所有显式throw语句、空值判断、类型转换、边界校验逻辑——比如if (input == null) throw new IllegalArgumentException("input must not be null")这一行必须原样保留，一个字不能少。
【没有throw语句或显式校验的函数，Gemini无法推导异常路径，默认只会返回空列表。】
这一步操作极其简单，直接把源文件拖入提示词即可。
第二步：强制枚举三类异常输入
在提示词中用三行明确指定必须覆盖的异常输入类型，每类后面紧跟一条验证动作说明，避免模型自行猜测：
① 空值类：传入null、空字符串、空集合 → 验证是否抛出IllegalArgumentException且异常消息包含“must not be null”
② 类型错位类：传入int代替String、List
③ 超限类：传入长度10001的字符串、数值-999999999999L、浮点数NaN → 验证是否触发预设的maxLen/maxValue断言失败
第三步：堵死“假异常”漏洞
方法一：禁止推测性异常
添加硬性约束：“若函数体内无try-catch块且无throw语句，不得生成任何‘应抛出IOException’类测试项”。
方法二：绑定异常消息原文
明确写出：“每个异常测试用例的assertMustThrowMessage字段，必须与代码中throw new XxxException(‘xxx’)括号内字符串完全一致，一字不差”。
方法三：切断堆栈干扰
强调一句：“不根据调用链下游方法（例如内部调用的HttpClient.execute）推导异常，只响应本函数直接抛出的异常”。