想要让Gemini生成的测试用例清单真正覆盖异常路径？仅仅一句“请写几个异常测试”远远不够——它很可能会凭空编造一堆现实中永远不会触发的if分支来应付你。必须将异常类型精确锚定到你代码中实际会抛出错误的位置和方式，才能真正有效。
第一步：精准定位异常触发点
在提示词开头直接贴入目标函数的完整代码，重点保留所有显式throw语句、空值判断点、类型转换处以及边界校验逻辑——例如if (input == null) throw new IllegalArgumentException("input must not be null")这一行，必须原样保留，一字不差。
【若函数中没有throw语句或显式校验逻辑，Gemini根本推导不出异常路径，默认会返回空列表。】
这一步操作起来毫无技术难度，直接拖入文件即可。
第二步：强制列举三类异常输入
在提示词中用三行明确指定必须覆盖的异常输入类型，每类后面紧接一句验证动作说明，不让AI自行猜测：
① 空值类：传入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）推导异常，只响应本函数直接抛出的异常”。