如何构造和管理测试数据库的数据？
👔 Raina面试官： 测试库的数据你怎么构造和管理？
🙋 候选人：
- 我坚持可重复、可隔离、可清理三原则，避免测试互相污染。
- 构造方式：SQL seed 脚本、Factory 模式（按实体关系链式创建）、Fixture 文件、接口前置步骤造数。管理上用命名规范（test_ 前缀账号）、每用例独立数据或事务 rollback、跑完清理脚本。共享 test 库则按 suite 分区或定时 reset。
- 敏感数据绝不从生产明文拷贝；脱敏+抽样。版本化管理 seed，跟 migration 同步更新，避免 schema 新了 seed 旧了全挂。
👔 Raina面试官： 并行自动化跑的时候数据冲突怎么办？
🙋 候选人：
- 优先每 worker 独立 schema/库，或 UUID 后缀保证唯一键不撞。
- 其次事务隔离（能 rollback 的用例）。最差才用锁或串行——那要标在 CI 配置里。我会把可并行作为造数方案的设计要求，而不是跑挂了再修。
数据备份与恢复流程怎么测？
👔 Raina面试官： 备份恢复流程你怎么测？
🙋 候选人：
- 不是看备份任务绿了就完事，要定期做真恢复演练（restore drill）。
- 测备份：全量/增量策略是否按 RPO 执行、备份文件完整性（checksum）、权限和加密。测恢复：从备份恢复到新实例，验 row count、关键业务抽样、应用能否连上并读写。还要测 PITR（时间点恢复）是否满足 RTO 承诺。
- 文档里写每日备份不够，我会要求每季度至少一次在 staging 完整走 restore + 冒烟，输出耗时和问题清单。
👔 Raina面试官： 云数据库托管备份，测试还要自己做吗？
🙋 候选人：
- 要。托管的是机制，验证的是你的流程和权限。
- 确认备份 retention、跨区复制、恢复权限谁有、恢复后连接串怎么切。事故时能不能在 SLA 内恢复，只有练过才知道。测试侧至少参与 DR 演练验收，不是 DBA 独家作业。
读写分离、主从延迟场景怎么验证？
👔 Raina面试官： 读写分离和主从延迟，测试怎么验证？
🙋 候选人：
- 核心场景是写后立即读从库可能读到旧数据，要看产品是否接受以及代码有没有补偿。
- 验证路径：写主库后立刻调走从库的读接口，断言是旧值还是新值；测写后读自己的数据是否强制走主库（read-your-writes）。延迟注入或 throttle 从库 replay，放大 lag 做边界。还要测主挂掉 failover 后数据是否丢、应用重连是否正常。
- 业务上：刚下单列表看不到、刚改密码旧 token 仍有效——都是 lag + 缓存叠加问题，测试要把架构图画清楚再设计 case。
👔 Raina面试官： 怎么模拟主从延迟？
🙋 候选人：
- 几种办法：从库人为 pause apply、网络限速、或测试环境用小规格从库。
- 也可以在应用层 mock lag 开关（仅 test env）。关键是可重复、可度量 delay 秒数，而不是偶尔自然发生。测完要恢复，别污染后续用例。
事务的 ACID 特性在测试中怎么体现？
👔 Raina面试官： 事务 ACID 在测试里你怎么体现？别只背概念。
🙋 候选人：
- 每个字母都要能落到可执行的 case 和断言。
- A 原子性：转账扣 A 增 B 中途失败，两表余额都回到初始。C 一致性：违反业务规则（余额为负）整体 rollback。I 隔离性：并发两笔扣同一库存，最终库存正确、无超卖——对应 READ COMMITTED/REPEATABLE READ 下行为。D 持久性：提交后 kill 进程/重启 DB，数据仍在（配合 WAL 理解）。
- Isolation 最难测，要用并发脚本或两个 session 交错执行，不是单线程点点点。我会跟开发确认隔离级别，避免测错预期。
👔 Raina面试官： 脏读、幻读这种要全测吗？
🙋 候选人：
- 按数据库隔离级别 + 业务风险选代表 case，不必把大学题库全跑一遍。
- 金融库存类重点测不可重复读/幻读是否导致超卖；只读报表可放宽。知道 InnoDB 默认 RR 下 snapshot 行为，测试才有依据。
数据库死锁问题测试能覆盖吗？怎么配合开发排查？
👔 Raina面试官： 数据库死锁测试能覆盖吗？你怎么配合开发查？
🙋 候选人：
- 很难稳定复现，但可以测并发冲突路径和死锁后的恢复行为，不能指望功能测试 100% 抓死锁。
- 覆盖：高并发更新同一批行（按不同顺序加锁）、批量 job 与用户请求抢资源。断言：一方失败时错误码明确、业务可重试、无半提交脏数据。死锁发生后连接是否释放、重试是否成功。
- 配合排查：复现时开 innodb deadlock log / pg log，保留 SQL、事务顺序；测试提供操作时间线和并发步骤。我会推动加监控（deadlock count 告警）和统一重试策略，而不是只报偶发失败。
👔 Raina面试官： 偶发失败你怎么判断是不是死锁？
🙋 候选人：
- 看错误信息里deadlock detected / 1213 / 40001 等特征码，对照 DB 日志时间戳。
- 测试报告要写清：并发模型、发生频率、是否可 retry 消掉。若不能稳定复现，标为环境/并发风险项，建议开发优化加锁顺序或缩小事务粒度。
缺陷的生命周期是什么？严重程度和优先级怎么区分？
👔 Raina面试官： 缺陷从发现到关闭走哪些状态？严重程度和优先级是一回事吗？
🙋 候选人：
- 典型生命周期：新建 → 打开/确认 → 修复中 → 待验证 → 关闭，中间可能有拒绝、延期、重新打开。
- 严重程度（Severity）描述技术影响：崩溃、数据错误、界面错位、文案问题。优先级（Priority）描述修复先后：是否阻塞发布、是否影响核心用户。两者独立——错别字 Severity 低但 Priority 可能高（大促前首页文案错误）；后台统计偏差 Severity 高但 Priority 低（可下版本修）。
👔 Raina面试官： 开发说这不是 Bug 是需求，你怎么处理？
🙋 候选人：
- 先对齐预期：拿需求文档、AC、产品口头确认记录来对照。真是需求变更就走变更流程，测试更新用例；确实是缺陷就保持打开并写清复现步骤和影响。
- 避免测试和开发在 issue 里拉扯定性，拉上产品三方定夺，结论同步到缺陷单，后面可追溯。
什么情况下你会拒绝关闭一个 Bug？
👔 Raina面试官： 开发修完把 Bug 关了，什么情况下你会打回去拒绝关闭？
🙋 候选人：
- 几种典型情况我会Reopen：复现步骤仍成立、修复引入新问题、只修了表象没修根因、环境与描述不符需要开发亲自验证。
- 还有修复说明写无法复现但没给日志——我会要求补充信息而不是直接关。关闭前必须按原步骤回归，涉及数据的还要核对库表和缓存，不能只看界面好了就点 Verified。
👔 Raina面试官： 开发说设计如此，拒绝修复，你怎么办？
🙋 候选人：
- 若产品确认接受现状，缺陷转已知问题或 Won't Fix，写清业务影响和 workaround，不是默默关单。
- 若我认为影响用户体验或合规，会升级给产品和项目负责人，用数据说话——影响多少用户、有无替代方案。测试的职责是暴露问题并推动决策，不是单方面强行 Reopen。
测试报告应该包含哪些核心内容？
👔 Raina面试官： 迭代结束要出测试报告，你会写哪些核心内容？
🙋 候选人：
- 报告要回答测了什么、结果怎样、能不能发、还有什么风险四件事。
- 具体包括：测试范围与版本信息、环境说明、用例执行统计（按优先级）、缺陷汇总（按严重度/模块/状态）、未执行/阻塞项及原因、质量评估与发布建议、遗留风险和后续计划。
- 读者可能是项目经理和产品，所以结论放前面，数据放后面，别让人翻到最后才知道能不能上线。
👔 Raina面试官： 通过率 95% 但还有 2 个严重 Bug，报告里怎么写结论？
🙋 候选人：
- 结论写不建议发布，除非业务接受并书面确认风险。通过率是参考，严重 Bug 是门禁。
- 报告里单独列出 open 严重缺陷的影响面和 workaround，让决策层签字，而不是用 95% 美化。测试报告的价值是诚实传递质量信息，不是帮发布凑数。
线上发现 Bug 和测试环境发现 Bug，处理流程有什么不同？
👔 Raina面试官： 线上 Bug 和测试环境 Bug，处理流程有什么不一样？
🙋 候选人：
- 线上 Bug优先级更高、流程更严、涉及止损和沟通。
- 测试环境：标准缺陷流程，按迭代修复验证。线上：先分级响应——P0 可能 hotfix、回滚、公告；要保留现场日志、用户影响范围、是否数据修复；修复后往往还要补回归用例和根因分析，防止同类再发。
- 线上 Bug 还会触发复盘：为什么测试没测到？是环境差异、用例缺失还是需求理解偏差，结论要回流到测试策略。
👔 Raina面试官： 线上复现不了怎么办？
🙋 候选人：
- 靠日志、链路追踪、用户操作录屏、数据快照还原。让运维协助查对应时段的请求和异常栈。
- 测试侧补环境对齐检查——配置、数据量、并发、灰度策略是否和线上一致。复现不了也要先止损，再慢慢补监控和用例覆盖。
你怎么理解质量是测出来的这句话？认同吗？
👔 Raina面试官： 有人说质量是测出来的，你认同吗？
🙋 候选人：
- 半认同。测试能验证和暴露问题，但质量根本上是设计和开发出来的。
- 测出来的意思是：没有测试，很多缺陷不会主动现身，质量信息离不开测试。但如果代码写得烂、需求含糊，测试只能当过滤器，越测越累、越测越晚。
- 所以我更认同质量是全员责任，测试是质量防线的重要一环，不是唯一来源。
👔 Raina面试官： 那测试团队 KPI 设缺陷数合适吗？
🙋 候选人：
- 单纯数 Bug 容易误导——找得多可能是开发质量差，找得少可能是测得浅。
- 更合理的是：生产缺陷率、逃逸缺陷数、核心场景覆盖率、发布成功率、复盘行动闭环率。测试的价值是降低线上风险，不是和开发比谁找 Bug 多。
常见的测试用例设计方法有哪些？各举一个适用场景。
👔 Raina面试官： 用例设计方法你能说几种？每种举个实际适用的场景。
🙋 候选人：
- 常用有等价类、边界值、判定表、场景法、状态迁移、错误推测等。
- 等价类+边界值：输入框年龄 18-60 岁。判定表：多种条件组合决定折扣规则。场景法：电商下单到支付完整业务流程。状态迁移：订单待支付→已支付→已发货。错误推测：断网、重复提交、权限越界等经验性异常。
- 实际设计往往是组合使用，不是单押一种方法。
👔 Raina面试官： 方法很多，时间紧怎么选？
🙋 候选人：
- 按需求类型选主方法：有明确输入规则用等价类边界值；多条件组合用判定表；有状态机用状态迁移；复杂业务流用场景法；时间不够再叠加错误推测补异常。
- 先覆盖 P0 正向主路径，再用方法系统化扩边界和异常，避免拍脑袋漏项。
等价类划分法和边界值分析法怎么配合使用？
👔 Raina面试官： 等价类和边界值经常一起说，具体怎么配合用？
🙋 候选人：
- 等价类先划有效/无效分区，边界值在分区交界处取点，因为缺陷爱出在边界。
- 例：密码长度 8-20 位。等价类：无效短于 8、有效 8-20、无效长于 20。边界值：7、8、9、19、20、21 各测一点，有效类里再抽中间值如 12 代表即可。
- 无效类通常各取一个代表值，不必穷举所有无效输入，节省用例数又保证覆盖。
👔 Raina面试官： 如果边界是开区间还是闭区间文档没写清楚呢？
🙋 候选人：
- 这正是边界值要测 on/off/nominal 的原因——7、8、20、21 一跑就知道实现和产品预期是否一致。
- 发现歧义立刻找产品确认，并把结论写进用例和 AC，避免开发按猜测实现、测试按猜测验收。
判定表法适合解决什么问题？请举一个业务例子。
👔 Raina面试官： 判定表法解决什么问题？举个业务上的例子。
🙋 候选人：
- 适合多个条件组合决定不同结果、容易漏组合的场景。
- 例：会员折扣——条件有是否 VIP、订单满 200、是否首单。动作有 9 折、95 折、无折扣。列条件桩和动作桩，穷举合法组合，每行一条用例，避免只测 VIP+满减却漏掉非 VIP 首单。
- 条件太多时可用化简规则合并无关条件，控制表规模。
👔 Raina面试官： 和因果图是什么关系？
🙋 候选人：
- 因果图是梳理条件约束和因果关系的中间步骤，最终往往转成判定表执行。
- 有些条件互斥或依赖，因果图帮助去 impossible 组合，判定表负责可执行的用例矩阵。面试里能说清：判定表是落地，因果图是分析工具。