Raina测试学习指南Raina测试学习指南
导读
面试题
对话式面试题
AI 测试教程
软件测试教程
🌍 知识星球
学习交流群
  • Raina测试工具集
  • Raina常用网站&工具合集
  • 小红书
  • B站
  • 作者介绍
导读
面试题
对话式面试题
AI 测试教程
软件测试教程
🌍 知识星球
学习交流群
  • Raina测试工具集
  • Raina常用网站&工具合集
  • 小红书
  • B站
  • 作者介绍
  • 基础测试对话

    • 测试基础理论
    • 测试用例设计
    • 功能测试
    • 接口测试
    • 自动化测试
    • 性能测试
    • 安全测试
    • 移动端与兼容性测试
    • 测试管理与工程实践
    • 综合与开放题
    • 数据库与数据测试
    • Linux 与测试环境
    • 微服务与分布式系统
    • Web 前端专项
    • DevOps 与 CI/CD
    • 业务领域专项
    • 测试工具与效率
    • 质量度量与测试策略
    • 软技能与职业发展
    • 进阶综合题
    • 网络与 HTTP 协议(高频)
    • SQL 与数据库基础(高频)
    • 自动化落地细节(高频)
    • 缺陷与质量过程(高频)
    • 经典业务 / 场景设计题(高频)
    • Web / App 实战补充(高频)
    • 接口与联调实战(高频)
    • 性能与稳定性补充(高频)
    • 编程与工具基础(高频)
    • 行为面试与综合高频
  • AI 测试对话

    • AI 测试基础与方法论
    • 大模型(LLM)功能测试
    • Prompt 与对话质量测试
    • Agent / Skill / MCP 测试
    • RAG 与知识库测试
    • 评测体系与 Eval
    • 自动化测试与 CI/CD
    • 性能、成本与稳定性
    • 安全、合规与伦理
    • 测试工程实践与职业发展

复现概率低的 Bug(偶现)你怎么跟进?

👔 Raina面试官: 偶现 Bug 很难搞,你一般怎么跟进?

🙋 候选人:

  • 偶现 Bug 核心是攒证据、缩范围、提概率,不能一句无法复现就关单。
  • 第一步:详细记录每次出现的条件——时间、并发、账号、数据状态、网络。第二步:保留现场——日志、traceId、录屏、内存/CPU 快照。第三步:尝试放大触发条件,比如压测、特定数据量、切换网络。
  • 和开发约定:偶现也要开缺陷单,状态可以是 Investigating,定期 sync 进展。超过两个迭代仍无进展,升级并评估是否加监控或 feature flag 兜底。

👔 Raina面试官: 开发坚持无法复现拒绝修,你怎么推动?

🙋 候选人:

  • 用生产数据或相似环境证明不是个例——同类日志出现了几次、影响了多少用户。
  • 提议加 defensive fix 或日志增强,哪怕先上观测再修根因。若涉及资金或安全,必须推动 hotfix 或临时降级方案,不能无限期挂起。


开发说是环境问题或数据问题,你怎么举证?

👔 Raina面试官: 开发说是环境问题或数据问题,你怎么举证?

🙋 候选人:

  • 举证靠对照实验:同版本、同步骤,换环境或换数据看现象是否一致。
  • 环境问题:对齐配置清单——分支、Feature Flag、中间件版本、时区、依赖服务地址。我在测试环境复现后,让开发连同一环境操作;或我在预发按生产配置再跑一遍。数据问题:导出脱敏样本,说明哪条数据触发;对比正常数据和异常数据的字段差异。
  • 缺陷单里写清已排除的变量,比如已换干净账号仍复现,就不是脏数据。举证目的是把扯皮变成可验证的假设。

👔 Raina面试官: 确实只有特定环境才复现,算 Bug 吗?

🙋 候选人:

  • 算,环境也是交付物的一部分。
  • 若生产/预发必现、本地不复现,说明环境差异未文档化或配置漂移,缺陷类型可以是环境一致性或部署问题。要求开发修配置模板、IaC 或启动检查,而不是让测试永远背环境锅。


什么是需求 Traceability Matrix(需求追溯矩阵)?有什么用?

👔 Raina面试官: 需求追溯矩阵 RTM 是什么?实际有什么用?

🙋 候选人:

  • RTM 是需求、用例、缺陷之间的映射表,回答每条需求有没有被测到、测出了什么。
  • 行通常是需求 ID/用户故事,列关联设计文档、测试用例、执行结果、关联缺陷。用处:评估测试覆盖是否完整;需求变更时快速定位要改哪些用例;审计和合规场景证明验证完整性;发布前检查是否有没有用例的需求或没有需求的用例。
  • 不必追求 Excel 大而全,工具里用需求-用例链接、覆盖率报告也能实现同样目标,关键是双向可追溯。

👔 Raina面试官: 敏捷迭代快,RTM 会不会太重?

🙋 候选人:

  • 轻量做法:每个 Story 至少一条 AC 对应用例,在 Jira/禅道里链起来就行。
  • 金融、医疗、车规等强合规域才要完整矩阵;一般互联网团队用需求覆盖率 + 变更影响分析替代,迭代 retro 抽查遗漏需求。


测试准入、准出标准一般怎么定?

👔 Raina面试官: 测试准入准出标准你们一般怎么定?

🙋 候选人:

  • 准入看能不能开测,准出看能不能发布,要和项目组书面共识。
  • 常见准入:需求/AC 已评审冻结;开发自测通过;冒烟用例全绿;测试环境可用且版本号正确;测试数据就绪。常见准出:P0/P1 用例 100% 执行且无 open 阻塞缺陷;P2 执行率达标(如 95%);已知遗留缺陷有 PO 签字;回归和自动化通过;性能/安全门禁达标(若适用)。
  • 标准要可量化、可检查,别写测试完成这种模糊话。每个迭代入口检查准入,出口出报告对照准出,例外走变更和风险接受流程。

👔 Raina面试官: 时间不够,准出标准能打折吗?

🙋 候选人:

  • 可以调整范围或时间,不默默降标准。
  • 例如缩小发布范围、延后非核心 Story、增加 hotfix 窗口。任何未达准出的发布必须书面风险接受,测试报告里如实写未满足项,不留口头默契。


冒烟测试不通过,你会怎么处理版本?

👔 Raina面试官: 提测后冒烟没过,你会怎么处理这个版本?

🙋 候选人:

  • 冒烟不过=版本打回,不进入全面测试,这是测试效率的硬门禁。
  • 立即通知开发和项目经理,附上失败用例、日志、环境信息。版本状态改回开发自测或 Rejected,不边测边等修——否则后面大量用例可能白跑。同时要求开发给修复 ETA 和根因说明,修完再跑一轮冒烟,通过后才开全量测试。
  • 若连续多个迭代冒烟失败,要复盘:提测标准是否形同虚设、开发自测是否缺失、冒烟用例是否过时。

👔 Raina面试官: 业务催得紧,能不能冒烟失败也先测别的模块?

🙋 候选人:

  • 阻塞级冒烟失败(系统起不来、核心链路断)不建议并行测,浪费人力。
  • 非阻塞失败(某个次要模块)可和 PM 协商测不受影响区域,但要在报告标注测试范围受限、结论不可用于全量发布。原则:冒烟保护的是测试投入产出比,不是为难开发。


上线前最后一天发现阻塞缺陷,你会怎么决策和沟通?

👔 Raina面试官: 上线前一天发现阻塞级缺陷,你怎么决策和沟通?

🙋 候选人:

  • 先分级影响、给选项、推动决策,测试不替业务拍板发不发。
  • 15 分钟内整理:缺陷现象、影响用户范围、有无 workaround、修复 ETA、回归范围。同步项目经理、开发、产品开短会,给出三个选项——延期修复后发、带缺陷发布(需风险签字)、缩小发布范围/回滚功能开关。
  • 沟通用数据和场景,别说我觉得不能发。会后结论、责任人、时间节点写进邮件或群公告留痕,测试报告更新 open 阻塞项和发布建议。

👔 Raina面试官: 业务坚持要带缺陷上线,你怎么办?

🙋 候选人:

  • 要求书面风险接受,明确监控、回滚预案、客服话术和 hotfix 窗口。
  • 测试侧补上线后验证清单和加强监控项。我的职责是确保决策层知情,不是无限挡发布。若涉及合规或资损,会升级至更高层级并记录反对意见。

请你设计一套微信发红包的测试用例。

👔 Raina面试官: 请你设计一套微信发红包的测试用例,你怎么拆?

🙋 候选人:

  • 我会按发红包、抢红包、到账与异常三条主链路拆,再叠加金额、并发和风控边界。
  • 发红包:普通/拼手气/专属红包,金额上下限、个数与总额校验、余额不足、支付密码错误、取消与超时退回。抢红包:手慢无、重复抢、自己抢自己的、群解散后状态、网络中断重试是否幂等。到账:零钱/银行卡入账时效、明细展示、对账与退款路径。
  • 非功能重点:高并发抢红包不超发不少发,弱网/断网重连,多端同步;安全侧防刷、防篡改金额、防重放。用状态机画红包生命周期,比堆功能点更不容易漏。

👔 Raina面试官: 拼手气红包金额随机,怎么验公平性和总额?

🙋 候选人:

  • 做统计校验 + 边界断言:大量样本下总额恒等于设定值、单个金额在合法区间、末包兜底逻辑正确。
  • 自动化可 Mock 随机种子或跑 Monte Carlo;手工重点验只剩 1 个红包时金额是否等于剩余总额。


电梯控制系统你会怎么测?

👔 Raina面试官: 电梯控制系统你会怎么测?这类题怎么下手?

🙋 候选人:

  • 先建状态机 + 调度策略模型,再分功能、异常和安全三层测。
  • 功能:单梯上下行、停层开门关门时序、超载报警、检修模式、消防返基。多梯:请求分配策略(最近梯、同向优先)、高峰模式、一梯多组控制。输入:各层内外呼、轿厢内选层、开关门、急停。输出:楼层显示、运行方向、门状态、到达音。
  • 异常:门夹阻重开、断电恢复、通信中断后是否安全停层;边界:最高最低层、连续同向请求、空载满载。嵌入式场景还要测响应时间和故障降级,不能只看 happy path。

👔 Raina面试官: 两个电梯同时来同一层,怎么设计用例?

🙋 候选人:

  • 固定调度规则后做可重复场景:同时外呼 → 断言只有一梯响应或按优先级分配。
  • 变参:两梯位置不同、一梯检修、一梯满载,验证策略一致且不出现双梯开门。


如何测试一个购物车功能?

👔 Raina面试官: 电商购物车你怎么测?重点在哪?

🙋 候选人:

  • 核心验证商品状态、价格数量、合并结算三件事,购物车是下单前的最后一道聚合层。
  • 加购:有货/无货/下架/限购/多 SKU;数量边界 0、1、库存上限、超卖提示。改删:勾选、全选、批量删、失效商品置灰。价格:促销变价、会员价、优惠券预览是否实时刷新。
  • 跨端:登录前后合并、多端同步、离线加购上线合并冲突。结算跳转:勾选部分结算、跨店铺拆单、运费凑单。还要测并发改数量和秒杀抢库存时的乐观锁提示。

👔 Raina面试官: 购物车里的价格和结算页不一致怎么办?

🙋 候选人:

  • 这是 P0,用例要覆盖变价时点:加购后促销开始/结束、进结算页前后各断言一次。
  • 记录价格快照字段,对比接口返回与页面展示,不一致应阻断下单并提示刷新。


验证码(图形 / 短信 / 滑块)怎么测?有哪些边界?

👔 Raina面试官: 图形、短信、滑块验证码分别怎么测?边界有哪些?

🙋 候选人:

  • 统一框架:正确验证、错误耗尽、防刷限流、安全绕过,再按类型加专项。
  • 图形:大小写、相似字符、过期刷新、错误 N 次锁定、OCR 抗性抽样。短信:格式校验、60 秒重发、同一手机号/ IP 日上限、验证码有效期、输错次数。滑块:轨迹异常(直线/过快)、缺口偏移容差、重复提交 token 一次性。
  • 边界:空输入、超长、特殊字符、并发双发;弱网下发延迟导致用户用旧码;换设备同 session 是否失效。还要测无障碍替代方案是否合规。

👔 Raina面试官: 自动化怎么测验证码?

🙋 候选人:

  • 测试环境开万能码或 Mock 网关,测业务链路;生产形态用接口层 bypass 仅测频控逻辑。
  • 滑块可用测试桩返回固定轨迹校验结果,专项安全测试另做渗透,不阻塞日常回归。

最近更新: 2026/8/21 08:07
Contributors: weixin_55062269
Prev
业务领域专项
Next
质量度量与测试策略