分页列表接口/页面，你会设计哪些测试点？
👔 Raina面试官： 分页列表，接口和页面分别有哪些测试点？
🙋 候选人：
- 接口侧：pageNum/pageSize、默认值、边界页、超出总页数、排序字段、total 计数准确性。
- 页面侧：首页、末页、跳转指定页、每页条数切换、无数据空态、加载态、快速连点翻页。数据一致性：增删记录后 total 和当前页是否刷新正确；最后一页删光只剩空页时的表现。
- 还要测 pageSize 超大值、负数、0、非数字等非法参数，期望 400 或兜底默认。
👔 Raina面试官： 深分页性能问题测试要关注吗？
🙋 候选人：
- 要，尤其offset 很大时响应变慢。功能测试可测第 1 页 vs 第 1000 页耗时差异，发现慢则提性能优化建议（游标分页等）。
- 这不完全是性能测试范畴，但功能测试最早能发现深分页超时或 OOM 的苗头。
文件上传功能有哪些常见的测试场景？
👔 Raina面试官： 文件上传有哪些常见测试场景？说全一点。
🙋 候选人：
- 分文件本身、交互流程、安全合规三类。
- 文件：类型允许/禁止、大小超限、空文件、0 字节、超大文件名、特殊字符名、损坏文件。流程：单/多文件、拖拽、取消上传、断点续传、重复上传覆盖。安全：可执行文件、双扩展名、MIME 与后缀不符、病毒扫描、存储路径遍历。
- 还有进度条、失败重试、并发上传、弱网中断、上传后预览和下载链接是否有效。
👔 Raina面试官： 前端限制了格式，后端还要测吗？
🙋 候选人：
- 必须测，前端限制可绕过。用 Postman 或抓包改 Content-Type 和文件名直调接口，验证服务端校验。
- 安全相关校验永远不能只信任客户端，这是上传测试的基本功。
表单校验（必填、格式、长度）用例怎么系统化设计？
👔 Raina面试官： 表单校验用例怎么系统化设计？必填、格式、长度一堆规则。
🙋 候选人：
- 我按字段矩阵来：每个字段列规则，每规则对应等价类和边界值。
- 必填：空、仅空格、正常值。格式：邮箱、手机、身份证各取合法/非法代表值。长度：min-1、min、max、max+1。还要测多字段联动——A 选某值时 B 才必填。
- 前端即时校验和后端二次校验都要测，提交时绕过前端 JS 直接调接口。
👔 Raina面试官： 错误提示文案和焦点定位要测吗？
🙋 候选人：
- 要，属于体验验收。第一个错误字段应获焦点，提示要明确到字段级而非笼统提交失败。
- 多个错误同时存在时，是全部展示还是只展示第一个，要和 UX 规范一致，这类细节面试能体现你测得细。
权限控制相关的用例你会怎么设计？
👔 Raina面试官： 权限控制用例你怎么设计？RBAC 项目里重点测什么？
🙋 候选人：
- 核心思路：垂直越权、水平越权、未登录访问三类必测。
- 垂直：普通用户调管理员 API、访问管理菜单。水平：用户 A 改 ID 访问用户 B 的数据。未登录：直接访问需鉴权 URL 和接口，期望 401/403 或跳转登录。
- 还要测角色变更后权限即时生效、按钮级/字段级权限隐藏 vs 禁用、导出和批量操作的权限边界。
👔 Raina面试官： 前端按钮藏了就算测过了吗？
🙋 候选人：
- 不算，UI 隐藏不等于 API 安全。必须直接请求接口验证服务端鉴权。
- 我会维护角色-权限矩阵表，每个敏感操作至少两个角色各测一次——有权限成功、无权限拒绝且不留数据副作用。
测试用例写得太细和太粗各有什么问题？你怎么把握粒度？
👔 Raina面试官： 用例写太细和太粗各有什么问题？你怎么把握粒度？
🙋 候选人：
- 太细：维护成本高、需求小改大量用例作废、执行像机器人操作说明书。太粗：不同的人执行理解不一致、漏步骤、缺陷难复现。
- 我的原则：一步能对应一个明确验证点，但不断裂到点击每一个像素。P0 用例步骤清晰可自动化；探索性场景用粗粒度 charter。粒度跟用途走——回归自动化要细，冒烟可以粗。
👔 Raina面试官： 敏捷里需求天天变，用例怎么维护？
🙋 候选人：
- 用模块化用例 + 需求 ID 关联，变更时只改受影响模块。
- Acceptance criteria 驱动，避免过度前置细节。定期清理冗余用例，合并重复场景。自动化优先覆盖稳定核心，变动大的区域用手工+探索性更划算。
测试用例评审你会关注哪些点？怎么组织评审？
👔 Raina面试官： 用例评审你会盯哪些点？一般怎么组织？
🙋 候选人：
- 评审关注：覆盖完整性、步骤可执行性、预期结果可判定、优先级合理、与需求一致。
- 组织上：需求稳定后、编码前或编码初期召开，参与方产品+开发+测试。产品确认场景全，开发确认可实现且可测，测试主持走查。
- 用 checklist：P0 需求是否都有用例、边界异常是否考虑、测试数据是否可准备、是否有不可测项及原因。
👔 Raina面试官： 开发说没时间参加评审怎么办？
🙋 候选人：
- 至少异步 review——发用例链接和摘要，开发 24h 内评论遗漏的技术边界。
- P0 模块必须有人代表开发确认，否则评审流于形式。可以拆成 30 分钟短会只评核心模块，降低参与成本。
功能测试的基本流程是什么？从需求到上线的关键节点有哪些？
👔 Raina面试官： 功能测试从需求到上线，完整流程和关键节点说一下。
🙋 候选人：
- 我习惯分六段：需求理解 → 测试设计 → 环境准备 → 执行 → 缺陷跟踪 → 报告与准出。
- 关键节点：需求评审（测试介入）、用例评审、提测准入（冒烟）、系统测试执行、回归、UAT 支持、上线 checklists、生产验证。
- 每个节点有交付物：测试方案/用例、执行记录、缺陷报告、准出报告，避免口头质量。
👔 Raina面试官： 提测标准达不到，但开发说必须测，你怎么办？
🙋 候选人：
- 按准入标准执行——冒烟不过可以测但报告里标注质量风险和不完整范围，缺陷可能含环境问题。
- 同时推动原因修复：是自测缺失还是需求变更未同步。测试不是挡箭牌，但不能在已知不可信版本上给虚假绿灯。
需求文档不清晰时，你怎么开展功能测试？
👔 Raina面试官： 需求文档写得糊里糊涂，你怎么开展测试？
🙋 候选人：
- 第一步别急着写用例，先澄清并书面化假设。
- 把歧义点列成问题清单找产品确认；参考竞品、历史版本、原型交互补理解；和开发对齐当前实现意图。确认结果写进测试备注或 AC 补充文档。
- 测试过程中发现的新歧义即时升级，避免测完才说需求不清。
👔 Raina面试官： 产品说按你的理解来，你怎么办？
🙋 候选人：
- 把我的理解和决策记录发给产品邮件或 IM 留痕，测试按此执行。
- 上线前再让产品验收签字，防止事后甩锅。测试可以帮产品想方案，但不能替产品做产品决策——留痕是关键。
测试工程师需要掌握到什么程度的 SQL？你会写哪些常见语句？
👔 Raina面试官： 测试岗 SQL 要学到什么程度？你平时会写哪些？
🙋 候选人：
- 测试岗 SQL 不用到 DBA 级别，但要能独立查数、验数、造数，把功能结果和库表对得上。
- 常用 SELECT + WHERE + ORDER BY + LIMIT 查单条/列表；GROUP BY + HAVING 做聚合统计；JOIN 关联多表验业务链路；INSERT/UPDATE/DELETE 造测试数据和清理。子查询、EXISTS 查重复和异常也够用。
- 进阶一点会看 EXPLAIN 判断慢查询、会用事务做可回滚造数。原则是能支撑缺陷定位和数据断言，复杂优化交给 DBA，但读 SQL 和 DDL 变更要能看懂。
👔 Raina面试官： 不会写存储过程影响大吗？
🙋 候选人：
- 日常功能测试影响不大，除非项目大量逻辑在 DB 层。
- 我会优先掌握能直接支撑断言的查询和造数脚本；存储过程、触发器变更时再针对性补读，配合开发或 DBA 验证即可。
INNER JOIN、LEFT JOIN、RIGHT JOIN 有什么区别？举个业务例子。
👔 Raina面试官： INNER、LEFT、RIGHT JOIN 区别是啥？结合业务举个例子。
🙋 候选人：
- 核心区别在保留哪一侧的全部行：INNER 只留两表都匹配的行；LEFT 留左表全部、右表无匹配填 NULL；RIGHT 相反。
- 业务例子：订单表 LEFT JOIN 支付表——能查出所有订单，包括还没支付的（支付字段为 NULL）；若用 INNER JOIN，未支付订单会被过滤掉，对账统计会漏数。
- RIGHT JOIN 实际很少手写，一般改写成 LEFT JOIN 更清晰。测试时要确认报表/接口用的 join 类型是否符合产品预期，避免 join 写错导致数据口径偏差。
👔 Raina面试官： LEFT JOIN 会不会查出重复行？
🙋 候选人：
- 会。右表一对多时，左表一行会被复制多行。
- 比如一个订单有多条支付记录，LEFT JOIN 后订单信息重复。测试聚合报表时要验 COUNT 是否该用 DISTINCT 或子查询，这也是 join 场景常见 bug。