PR 测试影响分析 Skill:一个 PR 该跑哪些测试

PR 里变动的文件不等于受影响的功能。只按目录挑回归用例,往往会漏掉调用链另一端的行为。

PR 测试影响分析 Skill 将差异理解为行为变化,再连接契约、依赖和最小可信测试集。

本文将用明确的输入、边界和输出组织实践过程,帮助你把结论交给下一个需要据此行动的人。

PR 测试影响分析 Skill 用来做什么

PR 测试影响分析适合需要缩短反馈时间、又不能靠“改动很小”跳过风险的团队。它解释每个测试为什么被选中,也解释哪些测试暂缓以及风险如何保留。

先回到源 Skill

这个 Skill 的完整执行规则在 PR 测试影响分析 提示词。源目录还包含 3 个评测用例,用于验证输出是否遵守契约。

它要求特别注意:

  • 不要只根据文件名推断
  • 测试选择需给证据链
  • 高风险且证据不足时应扩大范围

用一份项目材料开始

先把当前拿得到的材料摆上来。缺口可以保留,状态必须说实话。

材料这次填什么缺失时的处理
目标与范围分析一个修改订单校验规则的 PR,选择受影响单元、接口、UI 与回归测试标出不在本轮判断内的链路
版本与环境PR base/head、构建矩阵、依赖版本和目标分支diff 不完整时只给候选测试集
证据文件变更、覆盖映射、依赖图、历史失败和测试标签找不到执行关系时保留人工确认项
决策边界必跑检查、可并行任务、排除项和合并 Owner每个取舍绑定风险与补跑条件

可以这样调用:

请使用 pr-test-impact-analysis Skill。

任务:分析一个修改订单校验规则的 PR,选择受影响单元、接口、UI 与回归测试
输入材料:[版本、链接、日志或报告路径]
范围:[本次包含和排除的对象]
限制:[时间、数据、权限、合规要求]

先审计输入,再按风险和证据强度排序。材料没有证明的内容标为假设,并列出验证方法。

PR 测试影响分析要给出可解释的选择

产物要回答的问题最低证据
改动对象PR 改了哪些符号、配置或数据diff、提交和文件路径
依赖路径哪些生产链路或契约会被触及调用图、schema 和历史缺陷
选中测试哪些测试最能覆盖风险选择规则、标签和预计时长
排除说明哪些测试本轮不跑,为什么风险理由、Owner 和后续窗口

没有基准分支、依赖关系和测试标签时,只能给候选集合,不能把选集写成充分覆盖。

在项目里跑一轮

先用一个边界清楚的小回合启动——分析一个修改订单校验规则的 PR,选择受影响单元、接口、UI 与回归测试。别急着把结果写成报告。先把输入版本、时间窗口和负责人贴到同一处;然后把每个判断连回具体材料;最后只安排一项能改变结论的验证动作。

把代码差异映射到行为、依赖和已有测试,未覆盖的高风险项要单列。这一轮交付应当包含:可复查的证据索引、仍然成立的假设、以及下一位同事可以直接执行的动作。这样做很朴素,也很有效。

进阶使用:把一次分析变成持续机制

把代码差异映射到行为、依赖和已有测试,未覆盖的高风险项要单列。

每次 PR 测试影响分析都保存 base/head、依赖版本和选择规则。PR 继续更新时,只重算被改动的路径,并留下新增、移除和保持不变的测试。

三段式 Skill 链

pr-test-impact-analysisregression-test-selectionrelease-testing-workflow

交接传递内容接收方要检查什么
上游到 pr-test-impact-analysis来源版本、范围、风险、未决项输入是否过期,冲突是否标记
pr-test-impact-analysis 到下游判断、证据索引、残余风险、待办产物是否可执行,Owner 是否明确
下游回写 pr-test-impact-analysis执行结果、缺陷、事实变化是否更新基线与回归范围

交接时传摘要、证据索引和原始材料的位置。信息量足够,结论出了问题也能回到来源。

团队门禁

门禁检查内容未满足时
pr-test-impact-analysis 输入门禁版本、环境、证据来源和 Owner停止生成,列出缺口
pr-test-impact-analysis 产物门禁关键结论带依据、状态和影响退回补证据
pr-test-impact-analysis 执行门禁命令、查询或验证路径可复现标记基础设施或测试问题
pr-test-impact-analysis 决策门禁残余风险有接受人与日期不进入下一阶段

容易踩的坑

  1. 只按文件名选测试,漏掉共享库和事件消费者。
  2. 用“改动很小”跳过高风险契约和历史缺陷。
  3. 只列要跑的测试,不记录被排除的范围和理由。
  4. PR 更新后继续使用旧选集,导致新改动没有验证。

相关 Skill

PR 测试影响分析要和代码改动、回归范围及最终选择接起来:

交付前复核:把判断落到证据

Skill 输出拿到手后,先核对四件事:输入版本是否明确,范围是否完整,每条结论能否回到证据,下一步由谁执行。少一项,报告就容易变成漂亮的猜测。

项目需要留下缺失时
输入边界版本、环境、时间窗口和本次范围标记假设,不写成事实
证据索引日志、报告、Trace、截图或命令输出标记 evidence_pending
结论状态verifiedassumptionblockedpending停止扩大结论
后续动作最小验证命令、负责人和截止时间交付为待办,不进入门禁
source_version: [版本或提交]
scope: [本次包含和排除的对象]
evidence: [日志、报告、Trace 或命令输出]
status: pending
owner: [负责人]
next_action: [最小验证动作]

分析类 Skill 要保留查询条件和时间窗口;执行类 Skill 要保留命令、退出码和失败产物。人工修改也要记录,下一次复核才知道结论从哪里变化。

安装与调用

安装这个 Skill:

npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/pr-test-impact-analysis -g

安装后,直接使用下文的 pr-test-impact-analysis 调用词,并附上本次的真实材料。

常见问题

输入还不完整,能开始吗?

能。先交付受限初版:列出已知事实、假设、缺口和最小验证动作。环境、数据或权限缺失时,不写执行结论。

什么时候需要人工确认?

范围取舍、风险接受、生产操作、数据权限和发布决定必须由对应负责人确认。Skill 负责整理证据与选项,不替团队做授权决定。

先用一份真实材料跑通 PR 测试影响分析,把输入、产物、人工修改和验证证据留在同一个工作链里。下一次变化发生时,才有东西可以复用。

参考

分享