一、测试参加了评审会，一句话没说
需求评审会，产品讲了四十分钟，测试全程记笔记。散会后开发问"有问题吗"，测试说"没，挺清楚的"。
三个月后线上出了资损——优惠券可以重复叠加使用。复盘会上有人问："评审的时候怎么没提出来？"
因为当时没人看出这里有歧义，现在回头看，"单笔订单限用一张"能读出两种意思：同一券种限一张，还是所有券合计限一张？可当时听着就是一个意思。歧义事后看明摆着，事前是藏着的——得盯着那行字反复读，它才分裂得出来。而一份 PRD 八十句，逐句抠一天就没了，评审会前两天测试手上还有回归和提测。
三个原因：当场想不到，会前没时间想，问了也白问——产品大概率回一句"就是限一张啊"，他自己也没想清。开发阶段更明显：开发说"改了个金额计算"，测试只能等提测，代码里有没有边界错误，不是不想看，是看不懂。到了联调，前端说接口不对、后端说文档就是这么写的，测试夹在中间连插话的资格都没有。
所谓"左移"，就是把测试活动往前挪——需求评审盯可测性，接口评审盯可断言，代码写完审风险，提测前卡准入。缺陷越往后修越贵：需求里改一句话五分钟，到线上就要拉复盘、发补丁、挨投诉。但很多团队的实际状态是：测试提前到场了，但没有提前拿到能干活的信息。
AI 在这件事上的价值，是把产品的话和开发的代码，翻译成测试能验证的东西。
二、需求阶段：把 PRD 翻译成问题清单
这一步的产出不是测试用例，是给产品的问题。
让 AI 扫五类问题
不要跟 AI 说"帮我评审这个需求"，它会给一堆泛泛而谈的建议。要给它五个明确的扫描维度：
- 歧义：同一句话能读出两种以上含义
- 缺失分支：只写了正常路径，没写异常和边界
- 前后矛盾：A 处和 B 处的规则对不上
- 不可测：表述模糊到无法判断对错
- 边界未定义：等于、大于、超过这类临界情况没说清
提示词
你是资深测试工程师，正在参加需求评审。请阅读下面的需求文档，只输出"会导致测试无法判断对错"的问题，不要给改进建议，不要写测试用例。
按五类逐条扫描：
1. 歧义：同一句话能读出两种以上含义
2. 缺失分支：只写了正常路径，缺异常、边界、并发
3. 前后矛盾：不同条目的规则互相冲突
4. 不可测：表述模糊到无法判断实现是否正确
5. 边界未定义：等于、大于、超过等临界情况未说明
判定标准（不满足就不要输出这一条）：
- 判为"歧义"的，必须写出至少两种不同的读法，且这两种读法会导致不同的实现或不同的测试结论。写不出两种的，说明它不构成歧义
- 判为"缺失分支"的，必须指出缺的是哪个具体场景，不能只说"缺少异常处理"
- 判为"不可测"的，必须说明按哪种理解会得出不同的验收结论
- 每条都必须引用原文，不能凭空推测需求里没写的内容
输出格式：表格，四列——类型 | 原文位置 | 两种读法/具体场景 | 建议向产品确认的问题
需求文档：
需求：优惠券使用规则
1. 用户可在下单时使用优惠券，单笔订单限用一张。
2. 优惠券有面额和最低消费门槛，订单金额达到门槛方可使用。
3. 优惠券在有效期内可用，过期自动失效。
4. 退款时，优惠券是否退回由运营配置决定。
拿这段需求跑一遍，它给出的问题清单大致是这样：
| 类型 | 原文 | 两种读法 / 具体场景 | 该问产品什么 |
|---|---|---|---|
| 歧义 | "单笔订单限用一张" | ①同一券种限一张 ②所有券合计限一张 | 是哪种？ |
| 歧义 | "订单金额达到门槛" | ①商品金额 ②优惠前金额 ③实付金额 | 指哪个？含不含运费？ |
| 边界未定义 | "达到门槛" | ①等于可用，写 >= ②等于不可用，写 >
|
等于算不算？ |
| 不可测 | "过期自动失效" | ①下单时判定 ②支付时判定 ③核销时判定 | 哪个时点失效？ |
| 缺失分支 | 未提及叠加规则 | 与会员折扣、满减活动同时出现 | 能否叠加？ |
| 缺失分支 | 未提及部分退款 | 只退其中一件商品时券怎么算 | 怎么处理？ |
| 缺失分支 | 未提及并发 | 同一张券被两个订单同时提交 | 谁成功？ |
| 前后矛盾 | 第 1 条与第 4 条 | 券退回后是否恢复可用、是否仍受"限用一张"约束 | 怎么算？ |
这八条里，大多数在评审会上根本不会被提出来，因为它们不在"功能对不对"的层面，而在"这句话到底什么意思"的层面。
提示词里有两句是关键。
①"必须引用原文"防的是空话——不加这句，AI 会给你一堆"建议考虑高并发场景"之类的建议，落不到具体条目上。
②"必须写出至少两种不同的读法"防的是误报，歧义的判定标准不是"我觉得这句话模糊"，是"我能构造出两种不同实现"。没有这句，凡是句子短一点它都敢报。
这两句消不掉全部问题：模型能编出两种"其实没区别"的读法。评审会上照单全提，两次之后产品就不理你了，他会觉得你在挑刺。所以提之前还是要过一遍——它给的那两种读法，是不是真的会导致不同实现。 是就提，不是就删。
这一节怎么用
评审会前一天跑一遍，把输出整理成问题清单带进会。会上照着问就行。
三、接口设计阶段：把接口文档翻译成能写断言的字段
需求定了，开发开始定接口。这个阶段测试能参与的通常只有一次——接口评审。
很多团队连接口评审都没有。但接口文档一般都有，哪怕只是开发在群里发的一段话。这份文档通常长这样：
POST /api/coupon/apply
入参：
order_id：订单号
coupon_id：券号
出参：
code：结果码
msg：提示信息
data：抵扣后金额
看着什么都有，实际什么也没说。
一份接口文档缺什么
把上面这段喂给 AI，让它按"测试能不能照着写出断言"这个标准检查：
| 缺什么 | 具体位置 | 会出什么问题 |
|---|---|---|
| 类型 |
order_id、coupon_id
|
字符串还是数字？多长？传错类型谁校验 |
| 类型 | data |
"抵扣后金额"是数字还是字符串？几位小数？单位是元还是分 |
| 必填 | 全部入参 | 哪个能省？省了走什么分支 |
| 错误码 | code |
成功是 0 还是 200？未达门槛、券过期、券已用分别返回什么 |
| 空值语义 | data |
失败时是 null、是 {}、还是不返回？前端靠什么判断 |
| 枚举 | code |
有几个值？新增一个值，老版本前端怎么兜底 |
| 一致性 |
data 与 order_id
|
金额单位、时间格式在入参出参里是否统一 |
六类，每一类都直接决定测试能不能写出可判定的断言。比如"失败时 data 是 null 还是 {}"，这两种写法前端处理逻辑完全不同，文档不写，联调时就要吵一次。"单位是元还是分"更是资损类事故的经典来源，文档里一个字没提。
提示词
你是资深测试工程师，正在评审接口设计。下面是接口文档。
请只输出"会导致测试无法写出明确断言"的缺失项，不要给改进建议，不要写测试用例。
按六类逐条检查：
1. 类型：字段的数据类型、精度、单位、长度上限是否明确
2. 必填：入参是否标注必填/选填，选填项不传时的行为是否说明
3. 错误码：成功码是否明确，各类失败场景的错误码是否穷举
4. 空值语义：无数据时返回 null、空数组、空字符串还是不返回
5. 枚举：状态类字段的取值范围是否列全，新增值如何处理
6. 一致性：字段命名、时间格式、金额单位在全文是否统一
团队约定（符合以下约定的不要报为缺失；下面是示例，请按你们团队的实际情况替换）：
- 所有接口统一返回 code/msg/data 三层结构
- 成功码统一为 0
- 金额单位为元，保留两位小数
- 时间格式为 YYYY-MM-DD HH:mm:ss
输出格式：表格，四列——缺失类型 | 字段位置 | 当前写法 | 需要补充什么
每条必须引用文档原文，文档没写的地方标注"文档未提及"。
提示词中「团队约定（符合以下约定的不要报为缺失；下面是示例，请按你们团队的实际情况替换）」防的是把规范当缺失——不加这一栏，AI 不知道你们统一用 code/msg/data 三层、成功码统一 0，会把规范当成缺失报上来。
这一节怎么用
接口评审会前跑一遍，把输出整理成问题清单。没有接口评审的团队，直接发给开发让他补文档——他补的过程就是自查的过程，比开会有效。
四、编码阶段：把代码改动翻译成风险点
先从代码改动里读出该测什么，清单给开发；开发照着补单测；补完再验这批测试是不是真在验。中间顺带出一份 Code Review、筛一遍扫描报告。
一段真实的改动
假设开发愿意把 diff 提前发你，核心改动是这样的：
+ def apply_coupon(order, coupon):
+ if order.amount < coupon.threshold:
+ raise BizError("未达使用门槛")
+ if coupon.expired:
+ raise BizError("优惠券已过期")
+ order.amount -= coupon.value
+ order.coupon_id = coupon.id
+ return order
八行代码，看着挺清楚。但同一份 diff 能读出三种东西：该测什么、这次改动本身有什么问题、扫描报告里哪条是真问题。下面分开说，三种各用一个提示词。
用法一：读出该测什么
让 AI 按"风险点"而不是"代码风格"的角度读一遍：
| 风险类型 | 具体位置 | 为什么要测 |
|---|---|---|
| 边界错误 | order.amount < coupon.threshold |
金额等于门槛时会被拒绝。若需求是"达到即可用"，这里应该用 <=，方向反了 |
| 缺失校验 | 未校验券的归属 | 传别人的 coupon.id 能不能用？越权风险 |
| 缺失校验 | 未校验券状态 | 已使用、已锁定的券能不能再次使用？重复核销 |
| 缺失校验 | 未校验叠加 | 订单已有其他券时，这段逻辑不拦截 |
| 数值越界 | order.amount -= coupon.value |
券面额大于订单金额时，金额会变成负数，没有下限保护 |
| 并发问题 | 无锁、无幂等 | 同一张券被两个请求同时提交，可能双花 |
| 状态未落库 | 只改了 order.coupon_id
|
券本身的核销状态没有更新，下次还能用 |
七条风险里没有一条是代码风格问题，全是逻辑漏洞。这些点如果在提测前就写进测试重点，比提测后靠用例覆盖去碰运气靠谱得多。
这份清单有两个去处：发给开发当单测清单，他照着补及自测；或者自己整理成本次重点测试清单，提测当天带着测。
你是资深测试工程师，正在做提测前的风险审查。下面是本次改动的 diff。
只从"这段代码可能出错、需要补测试"的角度分析，不要评价代码风格。
按七类输出：
1. 边界错误：比较符号方向、临界值处理
2. 缺失校验：越权、状态、归属、重复提交
3. 数值问题：溢出、精度、负数、除零
4. 并发问题：竞态、幂等、锁
5. 状态不一致：改了 A 没改 B、缓存与库不同步
6. 异常路径：异常吞掉、事务不回滚、失败未回滚
7. 外部依赖：调用第三方失败、超时、重试
约束：
- 只依据上面这段 diff 判断。看不到外层调用、上游校验、其他模块时，不要断言"缺少某某"，标注"需确认"并说明需要看哪部分代码
- 每条必须能指到具体代码行。找不到对应代码行的不要写，不要凭经验补充
- 不要写通用建议（如"建议加强异常处理"），必须落到这一行代码上
输出格式：表格——风险类型 | 代码位置 | 风险描述 | 建议补的测试点
清单给出去之后：验单测是不是真在验
清单给出去，开发照着补单测。对开发提的不只是"补几条单测"，还有每条单测都得能验住东西。他不认这个标准，你抽几条自己改一遍，改不红的打回去。
一条典型的浅断言长这样：
def apply_coupon(amount, threshold, value):
if amount < threshold:
raise BizError("未达使用门槛")
return amount - value
def test_apply_coupon():
result = apply_coupon(100, 50, 20)
assert result is not None
看着没毛病，跑起来也绿。但把 return amount - value 改成 return amount，它还是绿——这个断言只检查了"有返回值"，没检查"返回多少"。
这就是假通过：测试跑了，绿灯亮了，但它验不住任何东西。开发赶进度的时候最容易这么写，断言个非空就交差。如果开发是用 AI 生成单测，它变更严重了：生成成本接近零，一次几百条，全是浅断言，覆盖率数字上去了，实际一条都没验住。
判断标准只有一条：把被测代码故意改坏，它能不能变红。 改法很直接，把断言落到具体值上：
def test_apply_coupon():
assert apply_coupon(100, 50, 20) == 80
def test_below_threshold():
with pytest.raises(BizError):
apply_coupon(40, 50, 20)
用法二：写出一份完整的 Code Review
同一份 diff、同一次阅读，还能顺手出一份 Code Review 给开发。
真实的 Code Review 要看的维度——除了逻辑对不对，还有安全、性能、兼容性、可观测性、可维护性，以及这次改动有没有配套测试。
| 维度 | 代码位置 | 问题 | 影响 |
| --- |---| --- |---|
| 正确性 | if coupon.expired | 只判了过期，没判未生效——券有生效时间区间 | 未生效的券能直接用 |
| 安全 | raise BizError("未达使用门槛") | 业务规则原文直接返回给调用方，外部能摸清券门槛的判定逻辑 | 规则被绕过 |
| 性能 | 整个 apply_coupon | 若方法内还要查券详情、查用户余额，一次下单三次查询 | 大促时数据库压力翻倍 |
| 兼容性 | 返回的 order 对象 | 新增 coupon_id 字段，下游若做严格字段校验会失败 | 要确认调用方 |
| 可观测性 | 两处 raise BizError | 没带订单号和券号，线上只看到"未达门槛" | 排障时间翻倍 |
| 可维护性 | 参数名 amount | 看不出是订单金额还是商品金额 | 调用方传错就是资损 |
你是资深开发工程师，正在做 Code Review。下面是本次改动的 diff。
按七个维度逐项检查，每个维度都要给出结论，没问题的写"无"，不要跳过：
1. 正确性：逻辑是否符合意图、边界处理、异常路径、并发安全
2. 安全：注入风险、越权、敏感信息是否进日志、权限校验放在哪一层
3. 性能：循环内 IO、N+1 查询、缺索引的查询、大对象拷贝、无缓存的高频调用
4. 兼容性：接口字段增删、老数据能否兼容、出问题能否灰度回滚、下游是否依赖旧行为
5. 可观测性：关键分支有没有日志、出错后能不能定位到具体订单和用户
6. 可维护性：业务语义不清的命名、抽象层次混乱、隐式耦合、失败语义缺失
7. 测试覆盖：新增的每个分支有没有对应测试
约束：
- 只依据上面这段 diff 判断。看不到外层代码、上游校验、调用链时，不要断言"这里缺少某某"，标注"需确认"并说明需要看哪部分
- 可维护性只报 lint 查不出的那类，缩进、命名大小写、注释缺失不要报
- 每条必须指到具体代码行，说不出影响的不要写
- 不确定的地方标注"需确认"，不要凭猜测下结论
输出格式：表格——维度 | 代码位置 | 问题 | 影响 | 建议怎么改
这份输出顺手给开发，他能省一遍从零读 diff 的时间。这也是测试提前拿到 diff 的一点回报——他下次更愿意发你。
用法三：从静态扫描报告里筛出真问题
diff 之外，编码阶段还有一份材料经常被浪费掉——静态扫描报告。
SonarQube 跑一遍，两百条问题，Blocker 五条、Critical 三十条。开发扫一眼，挑三条改了，剩下全挂着。测试更看不懂，那些规则名（"条件恒为假"、"资源未关闭"）跟业务没关系。而且报告里混着大量风格规则，改不改都不影响行为，占的篇幅却不小。
但这些条目里确实可能藏着真问题，区别在于：扫描工具只能按规则报，判断不了这条在这条业务路径上会不会真出事。 比如"可能的空指针解引用"，如果上游已经判过非空，就是误报；如果上游那个判断有漏洞，就是真问题。工具看不出这个差别，AI 能。
你是资深测试工程师，正在处理静态代码扫描结果。下面每条都是扫描工具报出的问题，附带对应代码片段。
先筛一遍：属于代码风格与可维护性范畴的（命名规范、格式、注释缺失、未使用变量、魔法数字、重复代码、方法过长），归为"不测"——这类不是行为问题，验不出对错，该由 lint 和 Code Review 管。
其中"重复代码""方法过长""嵌套过深"三类要单独说一句：它们本身不是缺陷，不用去验对错，但这段代码一旦改动就容易漏分支，测试要重点覆盖那块区域。
剩下的逐条判断，分三类输出：
1. 真问题：说明在什么输入或调用路径下会触发，触发后表现是什么
2. 误报：说明为什么不会触发（上游已校验、类型保证、分支不可达、框架已处理）
3. 需确认：信息不足，需要看更多代码才能判断
要求：
- 判为误报必须写清"为什么不会触发"的具体条件（上游已校验、类型保证、分支不可达、框架已处理）。写不出具体条件的，一律判"需确认"
- 判为真问题必须能指到具体代码行，并说明在什么输入下触发
- 只依据给出的代码片段判断，看不到的部分不要推测
输出格式：表格——编号 | 结论 | 判断依据 | 建议动作
结论只能是四选一：真问题 / 误报 / 需确认 / 不测。判"不测"的，判断依据写一句属于哪类风格规则；属于重复代码、方法过长、嵌套过深的，再补一句"改动易漏分支，建议重点覆盖"。
提示词里有两句是关键。
①三个提示词都写了「只依据给出的代码判断，看不到的部分标注"需确认"，不要断言缺失」防的是幻觉——不加这句，它只看得到你给的那段代码，却按完整上下文的口气下结论，说"这里没有事务回滚"，其实外层有；说"缺少参数校验"，其实在更上游的入口层做了。
②用法三那句「判为误报必须写清"为什么不会触发"的具体条件。写不出具体条件的，一律判"需确认"」防的是过度判误报——判误报等于宣布"不用干活"，模型天然倾向选它。不加这句，它会把看不懂的也标成误报，你还以为真没问题。
这一节怎么用
提测前一天，让开发把 diff 和最近的扫描报告一起发你。拿不到也别跳过：GitLab/GitHub 的 MR 页面测试一般有只读权限，自己拉就行；提测邮件里的 commit 链接也能看。实在没有，就用第五节的变更清单反推——粒度粗一点，但比不看好。
diff 跑两遍——一遍出该测什么，一遍出 Code Review 给开发；扫描报告跑一遍筛出有无真问题。该测什么那份有两个去处：发给开发当单测清单，或者自己整理成本次重点测试清单，提测当天带着清单测，而不是从头翻用例库。
五、提测前：把变更清单翻译成冒烟范围和风险等级
这是四个节点里最容易见效的一个，因为它不依赖任何人配合——变更清单本来就会发给你。
问题在于，大多数团队的变更清单长这样：
本次提测变更：
1. 订单服务新增优惠券抵扣逻辑
2. 订单金额计算从 float 改为 Decimal
3. 新增 /api/coupon/apply 接口
4. 修改订单列表排序规则
5. 数据库新增 order_coupon 表
五条，看完你还是不知道先测什么、重点在哪、开发漏了什么材料。
AI 要做三件事
第一，排风险等级。
同样是五条变更，风险差得很远：
| 变更 | 风险等级 | 判断依据 |
|---|---|---|
| 金额计算从 float 改为 Decimal | 高 | 动了所有金额相关逻辑，回归面最大，且类型转换容易出精度和兼容问题 |
| 新增优惠券抵扣 | 高 | 新功能 + 涉及资损 + 改动主流程 |
新增 /api/coupon/apply
|
中 | 独立接口，影响面可控 |
新增 order_coupon 表 |
中 | 涉及数据迁移和回滚 |
| 订单列表排序规则 | 低 | 展示层，不影响数据 |
排完你就知道：这次的八成精力该压在金额和优惠券上，排序规则跑一遍冒烟就够。
第二，推冒烟范围。
从变更反推哪些主流程必须过一遍：
- 下单主流程：不带券、带券、券刚好达门槛、券未达门槛
- 金额相关：订单详情、订单列表、退款、对账
- 新接口：
/api/coupon/apply的正常、异常、越权 - 数据层：
order_coupon表的写入、查询、回滚
第三，查提测材料完整性。
提测前该有的东西，AI 可以帮你对着清单核一遍——变更说明、影响范围、自测结论、配置变更、数据库回滚方案、依赖方同步，少一样就是提测后要返工的地方。
提示词
你是测试负责人，正在做提测准入检查。下面是开发提交的变更清单和自测说明。
请输出三部分：
一、风险评级
按"影响面 × 改动深度 × 资损风险"给每条变更评级（高/中/低），并写一句判断依据。如果你们有缺陷库，把这块模块的历史缺陷数一起贴给它，评级会更准。
二、冒烟范围
从变更反推必须验证的主流程，按"功能域 → 具体场景"列出，每条场景写清验证点。
三、准入检查
对照下面清单逐项核对，缺哪项直接指出：
- 变更说明是否明确
- 影响范围是否列出
- 自测结论是否有
- 配置变更是否列出
- 数据库变更是否有回滚方案
- 依赖方是否已同步
只基于我提供的信息判断，信息不足的地方标注"清单未提供"，不要假设。
提示词里「只基于我提供的信息判断，信息不足的地方标注"清单未提供"，不要假设」防的是替开发脑补——不加这句，你给一份缺了回滚方案的清单，它会自己编一个"已有回滚方案"填进去，准入检查全绿，材料不全你也看不出来。
这一节怎么用
收到提测邮件的第一件事，不是打开用例库，是跑一遍这个。十分钟后你会得到：这次先测什么、重点压哪儿、开发漏了什么材料。
手工对着变更挑冒烟用例，一小时起步；跑这个流程跑一遍只要十分钟。
材料不全就打回去，这一步比测出十个 bug 更值钱。
左移这件事，卡住测试的从来不是态度，是信息。
PRD 是产品写的，接口文档是开发定的，代码是开发写的，变更清单是开发列的——四种材料，测试都得读懂才能干活。过去靠经验硬啃，啃不动的部分就跳过去，跳过去的部分就变成线上的坑。
AI 现在能做的，是把这四种材料翻译成测试能直接用的东西：一份问题清单、一张缺失项表、一张风险表、一个冒烟范围。 每次线上出问题，回头再看一眼：这次的坑，本该被哪一节拦住？拦得住，说明提示词已经覆盖了，是执行时漏了；拦不住，就往那一节里补一条，补几次之后，它就变成了"你们项目的提示词"。