68 lines
4.1 KiB
Markdown
68 lines
4.1 KiB
Markdown
---
|
||
id: frontend.fe-testing-perf.interview
|
||
title: 前端测试与性能面试题
|
||
type: interview
|
||
domain: frontend
|
||
stack: [fe-testing-perf]
|
||
tags: [测试, 性能优化, Web Vitals, 面试]
|
||
level: intermediate
|
||
related: [frontend.fe-testing-perf.testing, frontend.fe-testing-perf.web-vitals]
|
||
week: [7, 16]
|
||
---
|
||
|
||
# 前端测试与性能面试题
|
||
|
||
## 基础
|
||
|
||
### 【基础】单元测试、组件测试、端到端测试的区别？
|
||
|
||
**参考答案**：单元测试验证函数和模块，快、数量多；组件测试在模拟 DOM 中验证组件与用户交互的行为；端到端测试在真实浏览器中走完整业务流程，最接近用户但慢且脆弱，只覆盖关键路径。
|
||
|
||
**追问**：你们项目各层大概怎么分配？→ 以单元和组件测试为主，端到端只覆盖登录、下单、核心流程等少量用例。
|
||
|
||
### 【基础】LCP、INP、CLS 分别是什么？
|
||
|
||
**参考答案**：LCP 衡量加载（最大内容渲染时间，良好 ≤ 2.5 秒）；INP 衡量交互响应（良好 ≤ 200 毫秒）；CLS 衡量视觉稳定性（良好 ≤ 0.1）。按 75 分位评估。
|
||
|
||
**追问**：INP 和 FID 的区别？→ FID 只测第一次交互的输入延迟；INP 考察整个访问期间的交互，并包含处理和渲染时间，2024 年起取代 FID。
|
||
|
||
### 【基础】怎么测试带防抖的组件？
|
||
|
||
**参考答案**：使用假定时器，触发多次输入后推进时间，断言请求只发一次且参数是最后一次输入；推进时间要包在 `act` 中让状态更新生效。
|
||
|
||
**追问**：为什么不用真实等待？→ 慢且不稳定，CI 机器负载高时容易超时。
|
||
|
||
## 进阶
|
||
|
||
### 【进阶】Testing Library 为什么推荐用 `getByRole` 查找元素？
|
||
|
||
**参考答案**：贴近用户和辅助技术的使用方式，不依赖实现细节（类名、结构），重构时测试稳定；同时倒逼组件有正确的语义和可访问性。
|
||
|
||
**追问**：什么时候用 `data-testid`？→ 实在没有语义化的查找方式时作为最后的选择。
|
||
|
||
### 【进阶】页面交互卡顿怎么排查和优化？
|
||
|
||
**参考答案**：用性能面板录制交互，找长任务和调用栈；看是否大量重新渲染、同步计算过重、布局抖动。优化：切分任务让出主线程、Web Worker、虚拟列表、减小渲染范围、防抖节流、React 的并发特性。
|
||
|
||
**追问**：线上怎么发现？→ RUM 采集 INP 和长任务，按页面和版本聚合。
|
||
|
||
### 【进阶】端到端测试不稳定（时好时坏）怎么办？
|
||
|
||
**参考答案**：使用自动等待的定位器和断言而不是固定等待；隔离测试数据（每个用例自己准备数据或拦截接口）；避免用例之间共享状态；失败时保存截图、录像和 trace 方便排查；对确实不稳定的用例标记并修复，而不是无限重试。
|
||
|
||
**追问**：怎么让 CI 跑得快？→ 并行、分片执行，只在关键流程上跑全量浏览器矩阵。
|
||
|
||
## 场景题
|
||
|
||
### 【场景题】客服工作台“越用越卡”，你怎么治理并防止退化？
|
||
|
||
**参考答案**：RUM 采集定位最差页面 → 性能面板找长任务 → 针对性优化（虚拟列表、流式输出批量渲染、状态拆分）→ CI 中加 Lighthouse 和体积预算、关键逻辑测试 → 用 75 分位前后对比汇报。详见[性能治理场景](scenarios/perf-regression.md)。
|
||
|
||
**追问**：“越用越卡”还可能是什么原因？→ 内存泄漏：事件监听、定时器、订阅没有清理，缓存无限增长；用内存快照对比排查。
|
||
|
||
### 【场景题】AI 帮你写了一个组件，你怎么证明它是对的？
|
||
|
||
**参考答案**：先写清楚预期行为（包括边界：空输入、失败、竞态），为这些行为写测试；运行测试，并故意破坏关键逻辑（例如删除中止请求的代码）确认测试会失败——证明测试有效；再做类型检查、代码审查和手动验证。
|
||
|
||
**追问**：如何把这个过程作为面试材料？→ 保留会话记录（脱敏）、测试代码、失败和通过的输出，作为“AI 编程 + 验证方法”的案例，见 [AI 编程专题](../../ai/ai-coding/index.md)。
|