兼容性测试的矩阵怎么设计？
👔 Raina面试官： 兼容性测试矩阵怎么设计？机型、系统、浏览器怎么取舍？
🙋 候选人：
- 矩阵三维：设备/浏览器 × 操作系统版本 × 分辨率/屏幕尺寸，再加网络和应用版本。
- 不是全排列，用数据分析：看线上用户分布 TOP N 机型/浏览器/OS，覆盖 80-90% 用户。
- Web：Chrome/Firefox/Safari/Edge 最新两版 + IE 如需支持。Mobile：iOS 最新两版 + Android 主流 5-8 款。每季度根据 analytics 更新矩阵。
👔 Raina面试官： 矩阵太大测不完怎么办？
🙋 候选人：
- 分P0 必测组合 + P1 轮换 + P2 云测平台批量扫。
- 核心流程在 P0 全组合跑，次要页面轮换覆盖。用 BrowserStack/Sauce Labs 做广度，真机做深度。
前后台切换、杀进程、来电中断等场景怎么覆盖？
👔 Raina面试官： 前后台切换、杀进程、来电中断这些场景怎么覆盖？
🙋 候选人：
- 这些是移动端稳定性的经典场景，我按生命周期列 checklist：
- 前台 → 后台 → 恢复：数据是否丢失、页面状态是否保留。杀进程重启：能否恢复会话、草稿是否保存。来电/闹钟/低电量弹窗：操作是否中断、返回后状态是否正确。
- 分场景测：编辑中切换、支付中切换、上传中杀进程——风险最高的操作必测。
👔 Raina面试官： 这些能自动化吗？
🙋 候选人：
- 部分可以。Appium 可以模拟 background/home/activate，杀进程可以 adb shell am force-stop。
- 来电中断真机手工更可靠。我的策略是关键路径自动化 + 探索性手工补长尾。
App 升级、降级、首次安装各有哪些测试点？
👔 Raina面试官： App 升级、降级、首次安装各有哪些测试点？
🙋 候选人：
- 首次安装：安装流程、权限申请、引导页、首次登录、本地数据初始化、推送注册。
- 升级：覆盖安装后数据迁移、登录态保留、配置兼容、新功能可用、旧功能不 regression。要测跨版本升级（如 v1.0 → v3.0 跳版）。
- 降级：通常不支持，但要测能否阻止降级安装、降级后数据是否损坏、服务端是否兼容旧版协议。
👔 Raina面试官： 升级测试最容易漏什么？
🙋 候选人：
- 本地缓存/DB schema 迁移——新版本改了表结构，老用户升级后 crash 是高频线上问题。
- 还要测升级中途断网/杀进程的容错，以及灰度发布时新旧版本共存的数据兼容性。
测试工程师和开发工程师如何高效协作？
👔 Raina面试官： 测试和开发怎么高效协作？你平时怎么做？
🙋 候选人：
- 几个实践：左移参与需求和设计评审、缺陷描述标准化、共用 Definition of Done、测试环境自助化。
- Bug 报告附复现步骤、日志、截图/录屏、期望 vs 实际，减少来回扯皮。Daily standup 同步 blockers。
- 不是对立关系——共同目标是质量，测试提前暴露风险，开发提供可测性（日志、测试 hook、单元测试）。
👔 Raina面试官： 开发觉得测试找茬怎么办？
🙋 候选人：
- 用用户视角和影响面沟通，而不是你代码写错了。
- Severity 和 Priority 标准团队共识，P3 不追着吵，P0/P1 摆数据。建立互信：测试也帮开发复现和缩小范围，不是扔个 Bug 就甩手。
项目时间紧、测试不充分，你怎么做优先级排序？
👔 Raina面试官： 时间紧测试不充分，你怎么做优先级排序？
🙋 候选人：
- 用风险驱动：影响面 × 失败概率 × 修复成本。
- P0：核心交易链路、安全、数据一致性、新改动直接相关的 regression。P1：次要功能、兼容矩阵抽样。P2：边缘 case、UI 细节。
- 和产品/开发对齐本次发布接受的风险清单，书面确认，别默默跳过然后背锅。
👔 Raina面试官： 产品说全部都要测呢？
🙋 候选人：
- 摆时间和风险 trade-off：全测需要 X 天，当前只有 Y 天，建议砍哪些、风险是什么。
- 提供选项 A/B/C 让决策层选，而不是测试单方面扛或单方面放行。
如何推动开发修复 Bug？遇到「这不是 Bug」怎么办？
👔 Raina面试官： 怎么推动开发修 Bug？遇到这不是 Bug怎么办？
🙋 候选人：
- 推动修复靠证据 + 标准 + 升级机制。
- 证据：复现步骤、日志、用户影响。标准：对照需求文档/设计稿/行业惯例。
- 说不是 Bug时：先确认是按设计如此还是需求理解不一致——前者找产品确认，后者拉三方对齐。仍不认可走 defect review 会议，Tech Lead/PM 裁定。
- 别情绪化，对事不对人。P0 直接升级，不卡在争论里。
👔 Raina面试官： 开发改 Bug 优先级很低呢？
🙋 候选人：
- 用用户影响和数据说话：多少用户触达、是否阻塞发布、是否有 workaround。
- Sprint planning 里测试代表 voice，Bug backlog 和 feature 同级排优先级，别永远排最后。
测试文档（用例、报告、缺陷）怎么保证团队可复用？
👔 Raina面试官： 用例、报告、缺陷这些测试文档，怎么保证团队可复用？
🙋 候选人：
- 标准化模板 + 统一工具：用例管理工具（TestRail/禅道）、缺陷模板固定字段、报告模板化。
- 用例写法：前置条件、步骤、期望、优先级、关联需求 ID，避免写测一下登录这种不可执行的描述。
- 缺陷：标题概括现象、步骤可复现、附环境版本。报告：结论前置、数据支撑、风险清单。定期 review 文档质量，淘汰过时 case。
👔 Raina面试官： 文档没人看、没人维护呢？
🙋 候选人：
- 文档价值要和流程绑定——发布门禁依赖用例覆盖报告、缺陷必须关联 case。
- Assign owner 做季度 audit，过时文档比没有文档更害人，该删就删。
敏捷 / Scrum 团队里测试角色是什么？
👔 Raina面试官： 敏捷/Scrum 团队里测试角色是什么？和瀑布有什么不同？
🙋 候选人：
- 敏捷里测试不是阶段末尾的质量警察，而是全程参与的 quality advocate。
- Sprint 内：参与 planning 估点、和 dev 并行写/跑测试、Daily 同步、Review/Demo 验收。左移做需求评审和 ATDD，右移参与监控和线上验证。
- 和瀑布的区别：不是等开发全做完再测，而是迭代内完成开发+测试+修复闭环；文档轻量但可执行；自动化是 Sprint 交付的一部分。
👔 Raina面试官： Sprint 时间不够测试怎么办？
🙋 候选人：
- 说明DoD 被违反了——Done 的定义应包含测试通过，不是代码合并就 Done。
- 推动 story 拆小、测试左移写 AC、自动化覆盖 regression，让每 Sprint 的测试量可控。
你怎么做测试任务的估时和风险评估？
👔 Raina面试官： 测试任务怎么估时？风险评估你怎么做？
🙋 候选人：
- 估时拆解：用例设计 + 环境准备 + 执行 + 回归 + 自动化/报告，每块单独估，加 20-30% buffer。
- 参考历史：类似 story 上次花了多久。新模块没有历史就偏保守。
- 风险评估看：需求变更频率、依赖方是否就绪、环境稳定性、技术复杂度、是否新技术栈。高风险项提前 flag 给 PM，不是到期了才说做不完。
👔 Raina面试官： 估少了被催怎么办？
🙋 候选人：
- 及时** re-estimate 并同步 trade-off**，不是默默加班扛。
- 说明少估的原因（需求膨胀/环境 block），给出调整方案：砍 scope、加人、延 timeline。透明比硬扛好。
新人测试工程师 onboarding，你会怎么带？
👔 Raina面试官： 新人测试工程师 onboarding，你会怎么带？
🙋 候选人：
- 我通常分四周：第 1 周熟悉产品和环境，第 2 周跟测+写简单 case，第 3 周独立负责小模块，第 4 周参与评审和自动化。
- 给文档包：环境搭建指南、业务 glossary、核心流程导图、工具账号。Assign buddy 日常答疑。
- 安排有反馈的任务——不是只跑 case，而是 review 他写的缺陷和用例，讲为什么好/为什么不好。
👔 Raina面试官： 新人上手慢影响进度呢？
🙋 候选人：
- Onboarding 是投资不是成本——前期多带，后期才能独立扛模块。
- 安排低风险任务练手，别第一天就扔核心支付链路。定期 1:1 了解困难，调整节奏。