什么是软件测试？软件测试的目的是什么？
👔 Raina面试官： 先聊最基础的——你怎么理解软件测试？它到底是为了干什么？
🙋 候选人：
- 我的理解是：软件测试是在有限资源下，用系统化手段验证产品是否满足需求、是否达到可交付质量。
- 目的不止找 Bug。更核心的是降低发布风险、给干系人提供质量信息、支撑上线决策。测试要回答：功能对不对、体验好不好、关键场景稳不稳、出了错能不能兜底。
- 所以测试既是验证手段，也是质量反馈机制——越早发现问题，修复成本越低。
👔 Raina面试官： 那测试能证明软件完全没有缺陷吗？
🙋 候选人：
- 不能，这也是七大原则之一——测试只能证明缺陷存在，不能证明缺陷不存在。
- 我们能做的是在已知风险范围内，用优先级和覆盖率把高风险路径测透，让残留缺陷在可接受范围内。面试里我会强调：测试的价值是风险管理，不是追求零缺陷神话。
软件测试和质量保证（QA）有什么区别？
👔 Raina面试官： 很多人把测试和 QA 混着说，你觉得两者本质区别在哪？
🙋 候选人：
- 一句话：测试偏验证产品，QA 偏保障过程。
- 测试工程师关注用例执行、缺陷发现、版本质量评估，工作重心在测什么、怎么测、测到什么程度。QA 更看流程是否规范——需求评审有没有测参与、变更有没有评估、发布有没有门禁、度量是否闭环。
- 小公司往往一人兼两职；大团队里 QA 定标准和审计，测试负责落地执行。两者目标一致，都是提升交付质量，但视角不同。
👔 Raina面试官： 实际项目里 QA 和测试怎么配合才不打架？
🙋 候选人：
- 关键是分清门禁和执行。QA 定义准入准出标准、缺陷分级规范、发布 checklist；测试按标准执行并反馈数据。
- 比如发布前 QA 看测试报告是否达标，测试负责把报告做实。避免 QA 只提要求不管资源，也避免测试只埋头跑用例不管流程漏洞。
软件测试的七大原则是什么？请举例说明。
👔 Raina面试官： 七大原则背得出来吗？别光列名字，举两个你项目里真用过的例子。
🙋 候选人：
- 我常用的几条：缺陷集群（二八法则）、测试依赖于上下文、穷尽测试不可能，再加上早测、杀虫剂悖论、缺陷不存在证明、群检谬误。
- 缺陷集群：支付模块历史 Bug 多，回归和探索性测试会加权投入。测试依赖上下文：ToB 后台重权限和数据一致性，C 端 App 重兼容和性能，同一套方法权重不同。
- 杀虫剂悖论：老用例反复跑发现不了新问题，所以每迭代会补充边界和变更相关用例，而不是只跑存量回归。
👔 Raina面试官： 穷尽测试不可能这条，面试时怎么跟业务解释？
🙋 候选人：
- 我会用风险驱动选范围来说：登录有无穷组合输入，但 P0 是合法登录、鉴权失败、锁定策略，P2 才是极端字符集。
- 业务要的是核心路径可靠，不是每个字段测一千遍。用优先级 + 等价类 + 边界值，把资源花在刀刃上，这本身就是专业测试该做的事。
软件测试在软件开发生命周期中处于什么位置？
👔 Raina面试官： 测试在 SDLC 里到底站在哪个环节？是开发完了才进场吗？
🙋 候选人：
- 现代项目里测试贯穿全生命周期，而不是瀑布末尾的验收关卡。
- 需求阶段参与评审、识别可测性和风险；设计阶段对照方案写测试策略；开发阶段单元测试和联调测试并行；系统测试和 UAT 验证整体验收；上线后还有监控验证和生产问题复盘。
- 所以测试的位置是嵌入式的——每个阶段都有对应测试活动，而不是等代码写完才开始。
👔 Raina面试官： 敏捷迭代里测试怎么跟得上发版节奏？
🙋 候选人：
- 靠分层测试 + 自动化 + 持续回归。Story 进 Sprint 就拆验收标准，开发提测前跑冒烟，合并主干触发核心自动化，迭代末做探索性补漏。
- 测试不是最后一个 gate，而是和开发同频的 quality partner——Daily 同步阻塞，Retro 复盘漏测根因，把反馈写进下一迭代。
黑盒测试、白盒测试、灰盒测试分别是什么？各适用于什么场景？
👔 Raina面试官： 黑盒、白盒、灰盒三种测试，你怎么区分？各自适合干什么？
🙋 候选人：
- 黑盒不看实现，白盒看代码结构，灰盒介于两者之间——知道架构和部分内部逻辑。
- 黑盒适合功能验收、UI 测试、业务场景验证，站在用户视角。白盒适合单元测试、分支覆盖、代码走查，开发或懂代码的测试做。灰盒适合接口测试、集成测试——知道数据库表结构和缓存策略，但不逐行读代码。
- 实际项目里功能测试以黑盒为主，接口和性能常带灰盒视角，单元测试是白盒领地。
👔 Raina面试官： 接口测试算黑盒还是灰盒？
🙋 候选人：
- 多数算灰盒。入参出参从外部验证像黑盒，但我会看日志、数据库落库、MQ 消息来确认内部行为，这已经用到内部知识。
- 如果完全不知道后端实现只测契约，偏黑盒；如果还要核对 SQL 执行计划或代码分支，就偏白盒了。关键是匹配目标，不必贴死标签。
单元测试、集成测试、系统测试、验收测试的区别是什么？
👔 Raina面试官： 单元、集成、系统、验收四层测试，区别和侧重点分别是什么？
🙋 候选人：
- 按测试粒度和参与角色来分：单元测最小代码单元，集成测模块协作，系统测完整产品，验收测是否满足业务目标。
- 单元测试：函数/类级别，Mock 依赖，开发主导，追求快和可重复。集成测试：服务间、DB/缓存/MQ 联调，验证接口契约和数据流。系统测试：端到端功能、兼容、非功能，测试团队主导。验收测试：UAT 或 Alpha/Beta，业务方或真实用户确认能不能用。
- 越往上越接近用户场景，执行成本越高，所以测试金字塔建议底层多、顶层精。
👔 Raina面试官： 很多团队只有系统测试没有单元测试，你怎么看？
🙋 候选人：
- 能跑但反馈慢、定位难。一个字段校验 Bug 可能要等全链路测完才发现，修复后再跑一大套回归。
- 理想状态是单元测试在 CI 里秒级反馈，集成和系统测试覆盖关键路径。测试工程师不必写所有单元测试，但要推动开发有覆盖率门禁，自己专注集成以上层次。
冒烟测试和回归测试有什么区别？各自在什么阶段执行？
👔 Raina面试官： 冒烟和回归经常一起提，你觉得核心区别是什么？分别在什么时候跑？
🙋 候选人：
- 冒烟是广度很窄的深度检查，回归是变更影响范围内的重复验证。
- 冒烟：新版本能不能测——主流程通不通、服务起没起、阻塞性 Bug 有没有，一般 15-30 分钟，提测准入第一道关。回归：修 Bug 或改需求后，把受影响模块和相关联模块再测一遍，防引入新问题，贯穿测试后期和发版前。
- 冒烟不过直接打回；冒烟过了才展开全量功能测试和自动化回归。
👔 Raina面试官： 回归范围怎么定？全量回归现实吗？
🙋 候选人：
- 全量回归只在大版本或核心架构变更时做，日常靠影响分析 + 自动化分层。
- 我会看代码变更关联的需求、历史缺陷热点、依赖链路，圈定 P0/P1 回归集。自动化覆盖核心接口和主流程，人工补探索性。既控制成本，又不让变更悄悄带毒上线。
什么是测试左移和测试右移？你在项目里怎么落地？
👔 Raina面试官： 左移右移说了好多年，你用大白话解释一下，项目里怎么落地的？
🙋 候选人：
- 左移是把测试活动往前挪——需求和设计阶段就介入；右移是上线后持续从生产环境获取质量反馈。
- 左移落地：需求评审测试必参加，验收标准（AC）测试来写或共建；开发自测 checklist；静态扫描和单元测试进 CI。右移落地：线上监控告警、用户反馈通道、生产日志分析、A/B 实验数据、故障复盘补用例。
- 两边不矛盾——左移防缺陷产生，右移补测试环境覆盖不到的盲区。
👔 Raina面试官： 左移会不会让测试在需求还没定稿时就背锅？
🙋 候选人：
- 不会，前提是左移是参与不是背锅。测试在评审里提可测性问题和风险，不替产品拍板需求。
- AC 随需求变更同步更新，测试报告里写清楚测了啥、没测啥、假设是什么。这样左移是共建质量，而不是提前签收不确定的需求。
测试计划里通常包含哪些内容？
👔 Raina面试官： 让你写测试计划，核心会写哪些块？不用逐条背模板，说关键项就行。
🙋 候选人：
- 我按范围、策略、资源、进度、风险五块来写。
- 范围：测什么不测什么、测试类型（功能/接口/兼容/性能）。策略：优先级划分、环境、数据、工具、准入准出标准。资源：人员分工、设备账号。进度：里程碑对齐版本计划。风险：需求变更、环境不稳定、第三方依赖，附应对预案。
- 小迭代可以精简成测试方案一页纸，但这五块逻辑不能缺，否则执行时容易扯皮。
👔 Raina面试官： 测试计划和测试方案有什么区别？
🙋 候选人：
- 计划偏项目级管理文档——谁、何时、多少资源；方案偏技术执行文档——怎么测、用什么方法、覆盖哪些场景。
- 大项目先有计划再拆各模块方案；敏捷里常合并，但心里要分清：计划回答能不能按时保质测完，方案回答具体怎么测。
如何评估一个项目的测试是否充分？你会看哪些指标？
👔 Raina面试官： 老板问测试充不充分，你怎么回答？会看哪些指标？
🙋 候选人：
- 我不会只报用例通过率，而是多维度看：需求覆盖、风险覆盖、缺陷趋势、残留风险。
- 需求覆盖：P0/P1 需求是否有对应用例且执行过。风险覆盖：核心链路、历史缺陷区、变更影响区是否测到。缺陷趋势：提测后缺陷是否收敛，严重 Bug 是否清零。残留风险：已知未测项、环境差异、第三方依赖有没有书面说明。
- 自动化覆盖率、代码覆盖率是辅助，不能替代业务风险判断——100% 行覆盖也可能漏关键场景。
👔 Raina面试官： 用例执行率 100% 是不是就能上线了？
🙋 候选人：
- 不一定。执行率只说明跑完了，不说明测对了。用例本身可能遗漏场景，或者数据/environment 不代表生产。
- 上线决策我会看：P0 场景是否全过、是否有 open 的严重缺陷、未覆盖项业务是否签字接受、回归和冒烟是否通过。指标是输入，风险判断才是输出。
数据库测试主要测什么？和功能测试的边界在哪里？
👔 Raina面试官： 数据库测试主要测什么？跟功能测试的边界你怎么划？
🙋 候选人：
- 数据库测试核心是数据层正确性、约束生效和持久化行为，功能测试则是端到端业务是否满足需求。
- 数据库侧要验：CRUD 后数据是否落库正确、主外键/唯一/非空约束是否生效、事务提交/回滚是否符合预期、索引和查询结果是否一致。功能测试从用户操作出发，可能只断言页面或接口返回值，不一定穿透到库表。
- 边界上：功能测业务对不对，数据库测存对了吗、约束守住了吗。比如下单功能测——功能看订单状态流转；数据库测库存扣减、订单行、支付记录是否原子一致。两者有重叠但不等价，关键链路我会做 DB 断言补位。
👔 Raina面试官： 是不是所有功能测试都要查库？
🙋 候选人：
- 不是。按风险和可观测性分层：涉及金额、库存、权限、审计的数据必查库；纯展示类可依赖接口断言。
- 自动化里常用 test DB 直连或 API 返回 internal_id 再反查。原则是有持久化副作用的核心写操作，至少抽一条 happy path + 一条异常回滚 path 做库级验证。
如何验证数据的完整性约束（主键、外键、唯一性、非空）？
👔 Raina面试官： 主键、外键、唯一、非空这些完整性约束，你怎么系统化验证？
🙋 候选人：
- 我按正向合规 + 逆向违规两条线设计用例，不只测应用层，还要确认数据库层兜底。
- 非空：必填字段空串/null/缺字段提交，期望应用拦截；若绕过应用直写 SQL，DB 应 reject。唯一：重复 username、重复业务单号，第二次 insert/update 应失败并返回明确错误。主键：自增/UUID 不重复；手动指定冲突主键应失败。外键：删父记录、插不存在的外键值，应被约束拦住或走级联策略。
- 还要测边界：软删 vs 硬删对外键的影响、复合唯一键、部分索引场景。自动化可直接构造 SQL 或通过 API 触发，断言 error code + 库中无脏数据。
👔 Raina面试官： 外键级联删除这种，测试要注意什么？
🙋 候选人：
- 先对齐设计文档里的 ON DELETE/UPDATE 策略，再测实际行为是否一致。
- CASCADE 要验子表是否全删；RESTRICT 要验删父失败且子数据完整；SET NULL 要验关联字段被置空而非误删。很多线上 bug 是文档写 RESTRICT 实际没建外键——我会用 information_schema 核对 DDL 和测试结果。
存储过程、触发器、视图怎么测？
👔 Raina面试官： 存储过程、触发器、视图这种数据库对象，测试怎么做？
🙋 候选人：
- 思路一样：输入边界 + 副作用 + 与上层调用链对齐，只是执行入口可能在 DB 层。
- 存储过程：参数组合（null、超长、非法枚举）、分支覆盖、返回值/OUT 参数、异常时是否 rollback。触发器：在 insert/update/delete 前后验审计表、计数器、级联字段是否按规则变化；特别注意 bulk 操作和 ORM 批量更新是否触发。视图：简单视图验 join 结果正确；可更新视图要测 insert/update/delete 是否映射到基表且约束仍生效。
- 我会拉一份对象清单，标注谁调用（应用/定时任务/DBA），优先测有业务副作用的 trigger 和复杂 procedure，避免只测 happy path。
👔 Raina面试官： 触发器导致性能问题，测试能提前发现吗？
🙋 候选人：
- 能部分发现。大数据量 batch 操作 + 执行计划/耗时对比是有效手段。
- 比如同一批 1 万行 update，有 trigger 和无 trigger 环境对比耗时；再看是否锁表过长。这类更像性能+功能交叉，我会在 migration 或 trigger 变更时加专项 case，而不是日常全量跑。
数据库 Migration（结构变更）测试你会关注什么？
👔 Raina面试官： 数据库 Migration 测试你会盯哪些点？
🙋 候选人：
- Migration 测的是可重复、可回滚、不丢数据、不停服或可控停服四件事。
- 正向：空库、有历史数据的库、接近生产量级抽样库各跑一遍 upgrade，验 schema 版本、新列默认值、索引是否创建成功。数据迁移脚本要抽样对比 row count、checksum、关键字段分布。反向：downgrade 能否执行、回滚后应用是否兼容旧 schema。
- 还要关注锁表时间、长事务、online DDL 是否真 online。我会要求 migration 在 CI 对 test DB 自动跑，staging 用生产脱敏副本再验一次，并保留 rollback drill 记录。
👔 Raina面试官： 加字段带默认值，大表有什么坑？
🙋 候选人：
- 经典坑是全表 rewrite 锁表。MySQL 8 某些 instant add column 行为、PostgreSQL 版本差异都要查 release note。
- 测试时在 staging 大表上测 migration 窗口和锁等待；应用层要验新字段 nullable 期间老版本是否仍能读写。灰度发布期间新旧代码共存，migration 必须 backward compatible。
大数据量场景下，数据库相关的功能测试要注意什么？
👔 Raina面试官： 数据量很大的时候，数据库相关功能测试要注意什么？
🙋 候选人：
- 小数据测逻辑，大数据测性能退化、分页边界和统计准确性，两者都要。
- 功能上：深分页（最后一页、空页、排序稳定性）、聚合报表在百万行下是否超时或结果偏差、唯一约束在 bulk import 下是否仍有效。还要测归档/分区表逻辑——查历史数据是否漏查、冷热分离是否一致。
- 环境上尽量用脱敏生产快照或合成数据达到量级，否则索引失效、慢查询在小库根本测不出来。我会给大数据 case 单独标 P1，发版前在 staging 大库跑子集。
👔 Raina面试官： 测试数据怎么造到百万级？
🙋 候选人：
- 常用脚本批量 insert + 模板化生成，或用 sql 工具/copy 灌入，避免手工。
- 注意外键顺序、索引先删后建加速灌数。造完后跑 ANALYZE/统计信息更新，否则优化器行为和生产不一致。数据可以假，但分布要接近真实——比如 80% 订单集中在近 30 天。