测试范围确定：代码变更影响分析、UI组件依赖图、变更波及范围评估
话说回来，很多团队做UI回归测试时最容易踩的坑就是「全量回归」。你想想看，一个大型应用少说几百个页面，每次改一行代码就跑全量？那不仅测试周期拖到崩溃，开发效率也直接归零。所以这节我们专门聊——怎么精准锁定测试范围。
我曾经带过一个项目，前端改了一个按钮的颜色，结果回归测试跑了三天。后来一查，那个按钮被十几个页面复用了……说白了，没有依赖分析，你怎么死的都不知道。今天我把这套方法拆成三步：代码变更影响分析、UI组件依赖图、变更波及范围评估。
第一步：代码变更影响分析
我的习惯是这样：先搞清楚这次改了什么，再想它影响了谁。不是凭感觉，而是靠工具和规则。
| 输入 | 方法 | 产出 |
|---|---|---|
| Git diff + 变更文件列表 | 静态分析：AST比对、import链提取 | 变更函数/组件/样式清单 |
| 模块依赖关系 | 动态分析：运行时调用栈采集 | 受影响模块集合 |
| 历史缺陷库 | 相似变更模式匹配 | 高风险区域标记 |
- 实例：某次只改了一个工具函数
formatDate，但被 23 个组件引用。我建议先跑这些组件的快照测试，而不是全量。 - 避坑指南：我曾经遇到过改CSS变量名，以为只影响当前页面，结果主题系统全局换肤全崩了。所以一定要检查
css custom properties的引用链。
核心原则：变更影响分为「直接引用」和「间接引用」。间接引用往往藏在第三层之后，容易漏掉。
第二步：UI组件依赖图构建
UI组件依赖图，说白了就是把组件之间的父子关系、跨层级引用、状态共享都画出来。我建议每个项目至少维护一张运行时依赖图，而不是只看代码静态引用。
嗯，这里要注意：静态import只能告诉你「可能引用」，但运行时条件渲染会导致某些依赖在特定场景才激活。比如一个弹窗组件，只有用户点击后才渲染，但它的内部子组件可能依赖全局Context——这些静态分析抓不到。
SVG图来了，这次我们画一个典型的组件依赖图，展示变更传播路径。
第三步：变更波及范围评估
有了依赖图，接下来要量化到底要测多少东西。我一般按三层维度评估：
- 直接波及层：变更组件的父、子、兄弟组件。比如改了表格组件的CSS，它的父容器布局可能受影响。
- 间接波及层：通过Context/Redux/事件总线共享状态的组件。改了某个store字段，所有订阅它的组件都要验证。
- 边界波及层：跨模块的样式引用、设计、国际化文案。这些往往藏在包依赖里。
git diff --name-only列出变更文件，再用 npm ls 反向追踪谁引用了这个模块。但注意，只能查直接依赖，查不到运行时条件引入。这时候我会结合性能监测工具录一次用户操作，看实际加载了哪些组件。
我曾经接手一个老旧项目，组件依赖图完全靠手动维护。后来我写了个小脚本，遍历webpack的stats文件，自动生成JSON依赖树。嗯，就是这张图的前身。有了它，我们每次发布前只用跑受影响模块的测试，时间从3小时降到15分钟。
评估结果如何转化为测试用例？
步骤很简单：
| 影响范围等级 | 建议测试策略 | 预算时间 |
|---|---|---|
| L1 - 仅修改组件自身样式 | 视觉回归快照 + 手动确认 | 5分钟 |
| L2 - 修改组件逻辑+影响子组件 | 单元测试 + 集成测试 + 视觉回归 | 30分钟 |
| L3 - 修改公共模块/自定义Hook | 全量相关页面 E2E 测试 | 2小时 |
| L4 - 修改路由/全局状态 | 全量回归（但可并行） | 1天 |
你想想看，如果每次改个按钮都按L4测，不累死才怪。但有了依赖图和影响分析，我们可以大概率把80%的变更归到L1或L2。
落地时我常用的工具链
- dependency-cruiser：前端代码依赖可视化，生成类似上图的关系。
- jest --changedSince：只跑变更相关的测试。
- storybook interactions：组件级交互测试，配合依赖图定向覆盖。
- chromatic or happo：视觉回归，自动标记变更截图。
说白了，测试范围确定不是玄学，是一套可以量化的工程方法。你把依赖图画清楚，把变更层级分明白，回归测试就能从「大海捞针」变成「精准打击」。我们团队现在每周发布两次，全靠这套流程撑着，很少出线上事故。