字节跳动测试面试题

本题清单

  1. 为登录功能设计测试用例，并说明优先级
  2. 设计抖音视频流「下拉刷新」测试方案
  3. 微信发图片/视频后闪退，怎么排查？
  4. Selenium / Appium 元素定位不到怎么办？
  5. 如何设计可维护的接口自动化框架？
  6. Pytest 的 Fixture 怎么用？和 unittest 有何区别？
  7. 如何用 LLM 生成边界用例？如何评估质量？
  8. AI 问答（流式返回）怎么测？
  9. 经典场景：怎么测试一部电梯？
  10. 线上接口超时怎么定位？
  11. 有序链表删除所有重复元素（含本身）——手撕常见
  12. 项目拷打：实习里最难的业务怎么测？（如提现计税多公式）
  13. 如何用 Fiddler/Charles Mock 接口？如何模拟 404、断网、慢响应？
  14. 自动化用例经常 flaky，你怎么治理？
  15. 为一个「搜索框」设计完整测试方案
  16. 接口依赖链（A 依赖 B 的结果）在自动化里怎么处理？
  17. App 线上 Crash 率突然升高，你怎么排查与止血？
  18. 如何评估一套自动化的投入产出比？哪些不该自动化？

1. 为登录功能设计测试用例，并说明优先级

考察意图：不是让你背 50 条用例，而是看你会不会分层、定优先级、选对方法。

参考答案：

我会按「先定范围 → 再选方法 → 再定优先级 → 最后补非功能」来答。

1）先明确被测对象
登录通常不止「输账号密码点按钮」，还包含：账号体系（手机号/邮箱/第三方）、验证码、密码策略、失败锁定、Token/Session、多端互踢或共存、找回密码入口等。面试里先跟面试官确认边界，避免答偏。

2）用例设计方法怎么用

  • 等价类：有效（正确账号+正确密码）；无效（账号错/密码错/都错/空值）。
  • 边界值：密码最短/最长/超长 1 位；验证码有效时长临界（过期前 1 秒、过期后 1 秒）。
  • 场景法：主成功流；失败后重试成功；锁定后解锁再登；登录成功跳转原页面。
  • 错误推测：SQL 注入、XSS、复制粘贴空格、大小写、验证码大小写敏感等。

3）按优先级组织（面试一定要主动说 P0/P1/P2）

优先级典型用例为何这个优先级
P0正确登录成功；错误密码失败且提示正确；空密码前端/后端双拦；连续 N 次失败锁定核心路径与风控底线，冒烟必跑
P1用户名/密码长度边界；验证码错误/过期/重发间隔；第三方登录绑定冲突高频异常与合规相关
P2多设备同时登录策略；弱密码拦截；注销后再登录；国际化文案策略类、体验类，可迭代补

4）非功能与安全（容易漏，说出来很加分）

  • 安全：越权（A 的 Token 访问 B）、暴力破解限流、抓包改包、验证码绕过。
  • 兼容：主流浏览器 / App 机型。
  • 异常：弱网、超时、服务端 5xx、依赖的短信网关失败时的降级提示。

5）收尾怎么说
「P0 进每次构建冒烟和发布门禁；P1 进迭代回归；P2 用探索性测试或按变更触发。我不会追求穷尽，而是风险驱动。」

常被追问

  • 前端校验和后端校验不一致怎么办？→ 以后端为准，两边都要有用例，并提 Bug 对齐。
  • 锁定策略测完怎么恢复环境？→ 测试账号工厂 + 解锁接口/改库权限受控。

2. 设计抖音视频流「下拉刷新」测试方案

考察意图：C 端高并发场景的全维度方案，不是只列功能点。

参考答案：

下拉刷新看起来是一个交互，实际串了客户端手势、推荐接口、缓存、去重、埋点。我会按质量维度拆，并标明哪些走自动化、哪些靠专项。

一、功能正确性

  1. 有新内容：下拉触发请求，列表顶部插入新卡片，旧内容下移，不丢用户当前浏览上下文（若产品要求保留）。
  2. 无新内容：友好提示「暂时没有更多」，不出现空白或重复请求死循环。
  3. 去重：新刷内容与已展示内容 ID 不重复；服务端若返回重复，客户端要有去重兜底。
  4. 首刷/空态：新用户空列表、仅少量视频时的表现。
  5. 与播放态关系：正在播放时下拉，是否暂停、是否保留进度——以 PRD 为准，用例写清预期。

二、性能与稳定性

  1. 客户端：首刷耗时、连续快速下拉是否防抖/节流（避免打爆接口）。
  2. 服务端：刷新接口 QPS、错误率、TP99；推荐超时是否降级为热门/缓存。
  3. 弱网：2G/丢包下是否一直转圈、是否可取消、失败是否可重试。
  4. 内存：频繁刷新是否泄漏（尤其视频封面与播放器）。

三、体验
下拉阻尼与动画是否跟手；Loading 与错误态文案；无障碍或大字体下布局。

四、数据与策略
刷新次数、曝光、点击埋点是否齐全；推荐策略/实验参数变更后，要有固定回归集（固定用户画像 + 固定种子内容），否则「感觉不对」无法复现。

五、测试策略怎么落地

  • 接口层：Mock 各种返回（空、重复、超时、部分失败）做自动化。
  • UI 层：只保核心手势与关键文案，控制维护成本。
  • 线上：看刷新成功率、空结果率、Crash 率。

常被追问
「刷新和上拉加载更多有什么区别？」→ 刷新偏「拉新到顶部」，加载更多偏「向历史/向下取」；去重、分页 cursor、是否重置推荐上下文都不同。

3. 微信发图片/视频后闪退，怎么排查？

考察意图：线上问题的闭环能力：复现 → 定位 → 止血 → 防再发。

参考答案：

这类问题我按「先稳住现场，再缩小范围」处理。

第一步：定性与复现
收集：机型与系统版本、App 版本、图片/视频大小与格式（HEIC、超长视频、高码率）、网络（Wi-Fi/4G）、是否刚发版或灰度、是否必现。
能必现就在测试环境用同机型复现；不能必现就看 Crash 聚合平台是否有共同堆栈。

第二步：看崩溃证据

  • iOS：Crash 日志、 fortify、OOM 标记。
  • Android：tombstone、ANR traces、Java 异常栈。
  • 业务埋点时间线：选图 → 压缩 → 上传 → 发送，卡在哪一步之后崩。

第三步：分层怀疑（由近到远）

  1. 客户端解码/压缩：大图 Bitmap 未采样导致 OOM；视频转码失败未捕获。
  2. 上传链路：超时重试风暴、回调在已销毁页面上更新 UI。
  3. 权限：相册/麦克风权限拒绝后的空指针。
  4. 混合栈：原生与 WebView 传大 base64。
  5. 系统差异：特定 ROM、特定系统版本的编解码 bug。

第四步：对比实验
同包小图正常、大图崩 → 内存/压缩问题；新包崩旧包不崩 → 回归 diff；仅某格式崩 → 编解码。

第五步：止血与闭环

  • 止血：灰度回滚、关闭新压缩算法开关、限制上传大小并提示。
  • 根因修复后：补用例（极大图、特殊格式、上传中杀进程、权限拒绝）。
  • 防再发：Crash 率告警、上传失败率看板、打点覆盖压缩前后内存。

答题时避免：一上来就猜「肯定是内存」，而没有复现和证据链。

4. Selenium / Appium 元素定位不到怎么办？

考察意图：自动化稳定性经验，看你是否只靠死等。

参考答案：

定位不到我会按原因分类处理，而不是盲目加重试。

1）元素本身变了
前端改了 DOM：绝对 XPath 最脆弱。优先 data-testid / 业务稳定 id / 可访问性 label；其次相对定位；最后才坐标。

2）时机问题（最常见）
页面异步渲染：用显式等待等「可点击/可见」，不要写死 sleep(3)。区分 presence（在 DOM）和 visible（真能点）。

3）上下文不对

  • Web：在 iframe 里要先 switch_to.frame。
  • App：原生与 H5 混合页要切 context；多窗口要切到正确 window。
  • Shadow DOM：要走 shadow root API 或前端配合暴露测试钩子。

4）被遮挡 / 动画中
等动画结束、滑入可视区、关广告弹窗；必要时用 JS click，但要谨慎（可能绕过真实用户路径）。

5）App 特殊情况
系统弹窗（权限）、WebView、Canvas/游戏控件（自动化价值低，改走接口或图像方案）。

6）工程化兜底
失败自动截图、保存 page source、有限次重试、把公共等待与弹窗处理收进基类。稳定性差的用例降级或隔离，避免拖垮整条流水线。

常被追问：「隐式等待和显式等待区别？」→ 隐式全局轮询找元素；显式针对条件。两者混用容易导致等待时间叠加难排查，团队通常以显式为主。

5. 如何设计可维护的接口自动化框架？

考察意图：测开核心题，要听到分层、隔离、CI、失败归因。

参考答案：

我会把框架拆成「可替换的层」，而不是一堆散脚本。

1. 配置与环境层
dev/test/pre/prod 配置分离；域名、超时、账号池走配置中心或 env；密钥不进仓库（用 CI Secret）。同一套用例能一键切环境。

2. HTTP 客户端封装
统一 request：自动带 TraceId、鉴权 Token 刷新、超时、有限重试（仅幂等 GET 或明确可重试码）、请求响应日志（脱敏）。业务用例不直接调 requests.get。

3. 数据驱动与用例层
用例数据 YAML/JSON：入参、期望码、期望字段。流程型用例写 Python，纯校验型尽量数据化。命名规范：模块_场景_预期。

4. 断言体系（决定好不好维护）
分层断言：HTTP 状态码 → 业务 code → 关键字段 schema → 可选 DB/缓存比对。避免「整个 JSON 字符串相等」（太脆）。

5. 测试数据与隔离
数据工厂创建用户/商品/订单；用例结束清理或标记过期；并发跑时每 worker 独立账号段。这是平台级稳定性的关键。

6. 报告与 CI
Allure 分类展示；MR 触发核心集，夜间跑全量；门禁：核心链路失败阻断合入；失败自动归类（环境/数据/产品）。

选型怎么讲
「选 Pytest 是因为 fixture 和插件生态；选 Allure 是因为步骤和附件可读；没用纯 Postman 集合做主回归，是因为复杂逻辑与权限校验不好维护。」

常被追问：「UI 自动化和接口自动化比例？」→ 接口为主做回归，UI 保极少核心端到端。

6. Pytest 的 Fixture 怎么用？和 unittest 有何区别？

参考答案：

和 unittest 的差别（面试官常用来开场）

  • 断言：Pytest 用原生 assert，失败时有 introspection；unittest 用 self.assertEqual 等。
  • 用例发现：test_ 前缀即可，不必继承 TestCase。
  • 生态：pytest-xdist 并行、rerunfailures、html/allure 插件成熟。
  • 夹具：Fixture 比 setUp/tearDown 更灵活，可分层注入。

Fixture 怎么用

@pytest.fixture(scope="module")
def db():
    conn = create_conn()
    yield conn          # 前面初始化，后面清理
    conn.close()

def test_order(db, login_token):  # 声明式注入依赖
    ...
  • scope=function：每用例新建（最隔离）。
  • module/session：贵重资源（浏览器、DB 连接池）复用，但要注意脏数据。
  • yield 后半段做清理，比只 setup 不 teardown 重要。

参数化
@pytest.mark.parametrize 一组数据驱动多用例，适合登录、边界值。

依赖管理原则
能独立就独立。必须「先下单再支付」时，优先用 fixture 产出 order_id，而不是用例 A 失败导致 B 全挂的硬顺序。

常被追问：conftest.py 的作用？→ 就近共享 fixture，目录级复用，避免循环导入。

7. 如何用 LLM 生成边界用例？如何评估质量？

考察意图（2025–2026）：你会不会「用 AI 做测试」，而不是只会聊概念。

参考答案：

1）Prompt 要结构化，而不是「帮我写用例」
模板示例要点：

  • 角色：资深测试工程师。
  • 输入：粘贴 PRD/接口文档原文。
  • 约束：必须覆盖边界、异常、权限、并发；每条含「前置 / 步骤 / 预期 / 优先级」。
  • 输出格式：表格或 JSON，便于入库。

2）用业务例子说明你会评估
比如「微信红包」，我会检查模型是否覆盖：金额 0/负数/超限、个数与金额不匹配、过期、重复领取、并发抢完、断网、作弊改包等。漏了关键项就迭代 Prompt 或人工补。

3）质量怎么评估（重点）

  • 覆盖率对照：需求点 × 用例矩阵，看缺口。
  • 抽检：随机抽 20% 人工审，统计幻觉率（编造不存在的规则）。
  • 风险分级：支付/安全/隐私类生成结果必须人审；展示类可放宽。
  • 回归沉淀：过审的进用例库，下次 Prompt 变更用同一批评估集对比。

4）落地边界
LLM 提效「起草与补洞」，不能替代测试策略与上线签字。我会明确说：「生成是草稿，准入靠人和门禁。」

8. AI 问答（流式返回）怎么测？

参考答案：

流式问答要同时测「协议正确」和「内容质量」，且接受非确定性。

协议与工程层（可自动化）

  1. 分片顺序与完整性：多个 chunk 拼接后与最终一致。
  2. 首包时延、总时延、token 速率。
  3. 中途取消/断网重连：是否停写、是否重复计费、UI 是否卡住。
  4. 错误帧：模型超时、限流、内容安全拦截时的错误码与兜底文案。
  5. 并发连接数与连接泄漏。

内容与安全层（评测集）

  1. 指令遵循、格式（JSON/Markdown）、拒答策略。
  2. 幻觉：事实类问题用 golden 答案或引用校验。
  3. 注入/越狱：忽略系统提示、套取系统 Prompt。
  4. 同一题多次：允许表述差异，用评分阈值（如 LLM-as-Judge + 人工抽检），不要 assert equal 全文。

回归策略
Prompt、模型版本、检索库变更都触发评测集；分「阻断集」（安全/核心业务）和「观测集」。

常被追问：「和普通接口测试最大区别？」→ 普通接口期望确定；LLM 要评测体系，工程层仍要确定。

9. 经典场景：怎么测试一部电梯？

考察意图：陌生物体的结构化拆解，字节特色送分题。

参考答案：

先声明：我不熟悉电梯硬件细节，但会用质量模型把风险拆全，再标优先级。

  1. 功能性：呼梯上下、轿厢内选层、开关门、楼层显示、超载报警、紧急呼叫、消防/检修模式。
  2. 性能效率：满载运行时间、高峰多梯调度等待时间、反复开关门响应。
  3. 可靠性：长时间运行、传感器故障后的安全态（就近停靠还是锁梯）。
  4. 安全性（最高优先）：防夹、超速保护、门锁联锁、断绳/停电应急、儿童误操作。
  5. 易用性：按键布局、盲文、语音报站、残障通行。
  6. 兼容/环境：不同楼层高度、单双层停靠、极端温度。
  7. 异常场景：停电、火灾、关人、通信中断。

收尾：「安全相关是 P0，必须有标准与认证；体验类次之。面试里展示的是分类能力，不是假装我测过电梯。」

10. 线上接口超时怎么定位？

参考答案：

超时是症状，要找「哪一段慢/失败」。

1. 先看全局，再下钻
监控：该接口错误率、TP99、影响机房/集群、是否发布或配置变更窗口、依赖方是否同时告警。先判断局部故障还是雪崩。

2. 用链路追踪拆耗时
网关 → 服务内业务逻辑 → DB → 缓存 → MQ → 第三方。看 span 哪段占比最大。没有 Trace 就靠日志时间戳和慢查询。

3. 机器与运行时
top/vmstat 看 CPU、内存、IO；线程池是否打满；连接池是否耗尽；jstack 看是否锁等待。

4. 常见根因对照

  • 慢 SQL / 缺索引
  • 下游超时未设或过长，导致线程堆积
  • 重试放大（客户端+网关+服务三重试）
  • GC、磁盘满、DNS 抖动
  • 流量超容量未限流

5. 止血与复盘
扩容、降级、拉长超时要谨慎（可能拖垮自己）；优先限流、熔断、回滚。事后补：超时用例、依赖失败注入、告警阈值、压测基线。

11. 有序链表删除所有重复元素（含本身）——手撕常见

参考答案：

题意：1→2→3→3→4→4→5 → 1→2→5，重复的整段都删。

思路：

  1. 建 dummy 指向头，避免头节点本身就要删。
  2. pre 指向当前已确定保留的尾；cur = pre.next。
  3. 若 cur 与 cur.next 值相同，记下 val，一路跳过所有该值节点，然后 pre.next = 跳过之后的节点。
  4. 若不相同，pre = cur 前进。

复杂度：时间 O(n)，空间 O(1)。

自测用例（写完主动说）：空链；单节点；全相同；头尾有重复；无重复；两两重复。

代码结构口述即可，边写边说不变量：「pre 之后要么结束，要么是一个尚未判定为重复的节点。」

12. 项目拷打：实习里最难的业务怎么测？（如提现计税多公式）

参考答案（用 STAR 讲透）：

Situation：提现累计金额不同适用不同税率/公式，规则多、易算错，且涉及资金。
Task：保证计税正确、账务可对上、并发提现不乱。

Action（重点展开）

  1. 先和产品/税务规则对齐，画状态机与决策表（累计区间 × 公式）。
  2. 表设计：累计字段、流水、公式版本号（规则变更可追溯）。
  3. 用例：每个区间边界金额（临界上下 0.01）、跨区间累计、退票回滚后累计回退、精度（分/角）。
  4. 自动化：规则引擎输入输出表驱动；和对账脚本比「应计税 vs 实计税」。
  5. 并发：同时两笔提现，累计与锁/事务是否正确；幂等防重复扣。

Result：用「拦截了多少错账」「对账差异降到 0」「回归从 X 小时到 Y 分钟」量化。

复盘：规则变更要有版本与回归集，否则下次改税率必翻车。

13. 如何用 Fiddler/Charles Mock 接口？如何模拟 404、断网、慢响应？

考察意图：验证你是否真的做过客户端联调与异常注入，而不只会点正常路径。

参考答案：

1）Mock 的基本做法
用 Charles/Fiddler 做中间人代理，对指定 URL 启用 Map Local / Map Remote / Breakpoints：

  • Map Local：把响应替换成本地 JSON/文件，模拟后端各种业务码。
  • Map Remote：转到另一台 mock 服务。
  • Rewrite：改状态码、改字段、加延迟。

HTTPS 要装并信任证书；只对测试包/调试包开启，避免误伤。

2）典型异常怎么造

  • 404/500：Rewrite 把状态码改成 404/500，看客户端是否有兜底页、是否反复重试。
  • 断网：系统飞行模式、代理断连、或工具里 drop connection；验证离线缓存、错误提示、恢复后续传。
  • 慢响应：Throttle 限速，或对响应加 Delay（如 3s/10s）；验证 loading、超时文案、是否卡死主线程。
  • 脏数据：返回缺字段、null、超大 body、错误 Content-Type。

3）和自动化的关系
手工用抓包工具做探索；稳定后把同类场景做到接口层 WireMock / mitmproxy 脚本，进入回归。

常被追问：「Mock 会不会测不到真实后端？」→ 会。Mock 测客户端容错；真实契约与联调仍要有；两者互补。

14. 自动化用例经常 flaky，你怎么治理？

参考答案：

Flaky 会直接摧毁团队对自动化的信任，必须当故障治理。

1）先识别
统计「同一用例在无代码变更下红绿交替」；CI 上标记 flaky，与真失败分开。

2）常见根因

  • 等待不足或固定 sleep
  • 依赖执行顺序/脏数据
  • 环境抖动、并行抢资源
  • 时间相关（刚好跨天、定时任务）
  • 动画/弹窗偶发遮挡
  • 第三方不稳定

3）治理手段

  • 显式等待与稳定定位；去掉隐式依赖。
  • 数据工厂隔离；禁止共享可变账号。
  • 失败自动归档截图/日志/Trace，便于归因。
  • 有限次重跑只能当缓冲，不能替代修根因；重跑仍失败才阻断。
  • 连续 flaky 的用例隔离出主门禁，修完再加回。
  • 周会看 flaky Top N，定责任人。

收尾：「稳定率」应成为自动化健康度指标，和覆盖率一起看。

15. 为一个「搜索框」设计完整测试方案

参考答案：

搜索框是字节高频场景题，按维度拆：

功能
空搜、正常关键词、联想/补全、历史记录、清除、热词点击、取消返回、回车与点击按钮一致性。

输入边界
超长、空格、表情、SQL/XSS 字符、多语言、复制粘贴。

结果与体验
有结果/无结果/加载中/失败重试；结果点击跳转正确；快速输入时请求取消，避免乱序覆盖。

性能
联想防抖、首字延迟、弱网。

安全隐私
敏感词、搜索历史是否账号隔离、是否上传隐私内容。

埋点
query、点击、曝光。

策略：接口测规则与防抖；UI 测主路径；线上看无结果率异常。

16. 接口依赖链（A 依赖 B 的结果）在自动化里怎么处理？

参考答案：

典型如：登录拿 Token → 下单拿 orderId → 支付。

做法

  1. Fixture/前置步骤：用代码编排，把上游结果注入下游，而不是把三个接口糊成一个巨型用例无法定位。
  2. 可拆可组合：每个接口仍有独立正反例；链路用例只覆盖主成功流与关键失败补偿。
  3. 失败定位：步骤级日志，标明卡在哪一环。
  4. Mock 策略：测 A 时 Mock B（契约）；测整链时走真实或测试桩。
  5. 数据回滚：链路跑完清理，避免库存/券被耗尽。

避免「全链路 UI 点点点」做主回归，接口层链路性价比更高。

17. App 线上 Crash 率突然升高，你怎么排查与止血？

参考答案：

止血优先：看是否灰度/全量新版本 → 回滚或关开关；确认影响面（机型、系统、渠道）。

排查

  1. Crash 平台聚合堆栈，看 Top 符号与版本分布。
  2. 对照发版变更：新 SDK、新页面、编译选项。
  3. 分维度：某厂商 ROM？低内存机？特定入口？
  4. 用同版本包 + 问题机型复现；结合埋点时间线。

闭环：热修/回滚 → 补回归（该堆栈路径）→ 门禁增加相关自动化或 Monkey 定向 → 复盘。

18. 如何评估一套自动化的投入产出比？哪些不该自动化？

参考答案：

适合自动化：稳定、高频回归、规则清晰、数据可构造的接口/核心链路；计算型校验、对账。

不适合或慎用：需求狂变的 UI、强视觉主观、强依赖人工判断的探索、一次性验证、环境极不稳定的路径。

ROI 怎么算（口述）

  • 成本：编写 + 维护 + 基建时间。
  • 收益：每次回归节省人工 × 运行次数 + 抓住的逃逸缺陷价值。
  • 维护成本一旦高于人工回归，就要删或降级用例。

字节喜欢听「你会砍用例」，不是堆覆盖率。

速查： 多练「场景拆解要细、手撕要自测、项目能三连问、AI 评测常识」；少踩「用例只有清单没有优先级；项目讲不清数据」。

最近更新:
MIT LicensedCopyright © 2026 Raina测试, All rights reserved.