增量测试与影响分析：只跑受变更波及的用例
一、全量回归的时间税
改一行代码，CI 把成千上万条用例全跑一遍。绝大多数用例与本次变更无关，却要陪着等。十分钟反馈，思路早凉了。全量回归保障的是"不漏"，代价是"太慢"。
团队为了提速，开始跳过测试，风险更大。快与全，似乎不可兼得。测试影响分析（TIA）破解这个矛盾。它基于代码变更，只选跑受影响的用例。
无关的跳过，相关的必跑。本文探讨其落地与边界。
二、依赖图与变更扩散机制
TIA 的核心是一张"依赖图"。节点是文件与函数，边是调用关系。测试用例挂在实际测的代码节点上。变更发生时，从改动点出发，沿依赖边扩散。
所有被波及的节点，其挂载的用例入选。未被波及的，跳过。下面是 TIA 的选择链路：
关键在"扩散的完整性"。静态依赖图可能漏算动态调用与反射。漏算意味着漏跑，漏跑意味着假绿。依赖图的精度，决定 TIA 的可信度。
图的构建靠静态分析。解析 AST 抽取 import 与调用关系，连成有向图。反向边表示"谁依赖了我"，变更沿反向边扩散到上游调用方。正向边表示"我依赖谁"，用于判断改动是否触及外部库。
静态图有盲区。反射、动态导入、字符串路由，AST 看不见。这些边要靠运行时插桩补全，或用覆盖率数据回填。纯静态图只能覆盖七成左右的真实依赖，剩下三成是地雷。
扩散深度也要控。无限制扩散会把整张图都选中，失去增量意义。实践中按调用链深度截断，超过六七层基本是噪音。
三、生产级测试选择器实现
下面用 Python 实现一个基于依赖图的测试选择器。
python
from dataclasses import dataclass, field
@dataclass
class DependencyGraph:
"""依赖图：节点 -> 其直接依赖的节点集合"""
edges: dict[str, set[str]] = field(default_factory=dict)
# 每个节点挂载的测试用例名
tests: dict[str, list[str]] = field(default_factory=dict)
def add_edge(self, src: str, dst: str) -> None:
# src 调用 dst，变更 dst 会反向波及 src
self.edges.setdefault(dst, set()).add(src)
def attach_test(self, node: str, test: str) -> None:
self.tests.setdefault(node, []).append(test)
def select_tests(
graph: DependencyGraph,
changed: set[str],
max_depth: int = 10,
) -> set[str]:
"""从变更点出发沿依赖图反向扩散，收集受影响用例"""
affected: set[str] = set()
frontier = set(changed)
depth = 0
while frontier and depth < max_depth:
# 限制扩散深度，防止图过大时全选，失去增量意义
next_frontier: set[str] = set()
for node in frontier:
affected.add(node)
# edges[node] 是依赖 node 的上游，变更会波及它们
next_frontier |= graph.edges.get(node, set())
frontier = next_frontier - affected
depth += 1
# 收集所有受影响节点上挂载的测试
selected: set[str] = set()
for node in affected:
selected.update(graph.tests.get(node, []))
return selected
if __name__ == "__main__":
g = DependencyGraph()
g.add_edge("api/handler.py", "services/user.py")
g.add_edge("services/user.py", "models/user.py")
g.attach_test("services/user.py", "test_user_service")
g.attach_test("api/handler.py", "test_handler")
# 只改了 models/user.py，应波及上游两个测试
print(select_tests(g, {"models/user.py"}))真实系统会把依赖图持久化，增量更新。并用覆盖率数据校准：用例实际跑了哪些行。覆盖率回填，比纯静态推断更准。图要增量更新，而非每次全量重建。
每次构建只解析变更文件及其邻居，局部刷新边。全量重建在大仓上要几分钟，增量只需几百毫秒，反馈速度天差地别。选择率是 TIA 的核心指标。选跑用例数除以全部用例数，反映增量效果。
健康的选择率在 10% 到 30% 之间。长期接近 1 说明图太粗或变更太散，增量名存实亡。应回头排查图构建逻辑，而非自欺欺人报喜。
四、增量测试与影响分析的代价与边界
TIA 提速明显，但漏跑是头号风险。
动态调用的盲区。反射、动态导入、字符串路由。静态图看不见这些边，漏算就漏跑。应用覆盖率数据回填，补全真实执行路径。
图的时效性。代码在变，依赖图也要跟着变。图过期了，选择就不可信。应在每次构建时增量更新图，而非周期性全量重建。
假绿的代价。漏跑的用例没跑，CI 绿了但不可信。比"慢但全"更危险的是"快但假"。应设补偿机制：定期全量回归，夜间跑兜底。
用例粒度的影响。用例越粗（如端到端），挂载越模糊。一个用例挂多个节点，选跑意义不大。应鼓励单元测试，粒度细才能精准选择。
TIA 的"补偿机制"不能省。增量选择再准，也有漏跑概率，必须搭配定期全量回归作为安全网，比如夜间跑全量、发版前跑全量。另一个被忽视的点是"覆盖率回填的时效"：依赖图若只靠静态分析，动态调用永远是盲区。建议把 CI 的覆盖率数据回写到依赖图，用实际执行路径校准静态推断，精度提升立竿见影。最后，TIA 上线后要监控"选择率"（选跑用例除以全部用例），若长期接近 1，说明依赖图太粗或变更太散，增量失去意义，应回头排查图构建逻辑而非自欺欺人地报喜。
五、总结
测试影响分析，本质是用"依赖图扩散"换"增量选择"。机制上从变更点出发，沿依赖边反向波及，收集受影响用例。工程上以覆盖率回填校准，以定期全量兜底。落地路线：先构建并持久化依赖图；变更时按图扩散选跑；用覆盖率数据回填校准；夜间与发版前全量回归兜底。测试不再全跑，但该跑的一个不漏。