日志分析平台（ELK、Loki）对测试工作有什么帮助？
👔 Raina面试官： ELK、Loki 这些日志平台，对测试工作有什么帮助？
🙋 候选人：
- 日志平台是测试的事后显微镜和线上哨兵，四个用法最实在。
- 缺陷定位：按 traceId/requestId 串全链路，比让开发翻服务器快十倍。测试设计：看生产高频错误和慢查询，反哺用例补边界。发布验证：灰度后盯错误率、5xx 关键词，比纯 UI 冒烟更早发现问题。自动化辅助：接口 case 失败时自动拉同一时段日志附到报告里。
- ELK 功能全、Kibana 可视化强；Loki 轻量、和 Grafana/Prometheus 生态好，适合 K8s 团队。测试至少要会写基本查询（按服务、级别、关键词、时间窗），不用会搭集群。
👔 Raina面试官： 测试环境日志量巨大，怎么快速找到有用的？
🙋 候选人：
- 建立测试专属标签：自动化 runId、用例名、测试账号写进 log MDC。
- 跑完用例用 runId 一搜就是本次全部日志，不用在海量里捞。推动开发规范日志字段，测试推动的成本收益比最高。
缺陷密度、逃逸率、测试效率你平时会跟踪吗？
👔 Raina面试官： 缺陷密度、逃逸率、测试效率这些指标你平时会跟踪吗？
🙋 候选人：
- 会跟踪，但看趋势不看绝对值，看行动不看 KPI 游戏。
- 缺陷密度：每千行代码或每 story point 的 bug 数，对比版本趋势，突然升高要追问需求和代码变更。逃逸率：线上 bug / 总 bug，反映测试有效性，要分 severity——P0 逃逸必须归零目标。测试效率：单位时间执行用例数、自动化占比、平均缺陷验证周期。
- 反对为了好看而 defer bug 到下个版本、或把 enhancement 标成 bug 刷密度。指标要和复盘挂钩：逃逸率高 → 补哪类用例、哪条链路要加强。
👔 Raina面试官： 领导只盯逃逸率，压力很大怎么办？
🙋 候选人：
- 把分层逃逸率 + 根因分类摆出来谈。
- 区分需求遗漏、环境差异、真实漏测、已知风险放行——不是全是测试的锅。推动发布前风险签字，已知低优问题逃逸要文档化，别事后单方面追责。
如何建立项目的质量基线（Baseline）？
👔 Raina面试官： 项目质量基线你怎么建立？
🙋 候选人：
- 质量基线是可度量、可对比、可门禁的一组起点数据，不是一句我们要高质量。
- 步骤：一、选指标——P0 用例通过率、核心接口 RT P95、线上错误率、逃逸率、自动化覆盖率。二、在稳定版本上采样 2-4 周形成 baseline 数值。三、写成文档：各指标定义、采集方式、阈值。四、嵌入 CI/CD 和发布 checklist——新版本的指标不能显著劣于 baseline（比如 RT 劣化 >20% 要评审）。
- 基线要分环境：测试环境 baseline 用于回归对比，生产 baseline 用于发布后监控对比。每季度 review 一次，业务规模变了基线要调。
👔 Raina面试官： 新项目没有历史数据怎么办？
🙋 候选人：
- 用行业参考 + 首个稳定迭代 + 逐步收紧。
- 第一版先定零容忍类指标（P0 全过、无 blocker）；跑两三个 sprint 后把实际数据固化成 baseline，别一上来设不切实际的门禁导致天天红灯麻木。
测试充分性的度量指标有哪些？各有什么局限？
👔 Raina面试官： 测试充分性有哪些度量指标？各有什么局限？
🙋 候选人：
- 常用指标我列几个，每个都有盲区，必须组合看。
- 需求覆盖率：需求点是否有对应用例——局限：有 case 不等于测深。代码覆盖率：执行到的代码比例——局限：不保证断言正确。缺陷发现率：测试阶段 bug 数——局限：和需求复杂度强相关，不能横向比项目。风险覆盖率：高风险项是否都有测试——局限：风险识别本身可能不全。回归通过率、逃逸率：见前面。
- 没有单一指标能回答测够了没。我的做法是 risk-based：高风险路径 100% 覆盖+自动化，低风险抽样+探索性。充分性是持续判断，不是某个数字达标就停。
👔 Raina面试官： 产品经理问能不能发版，你怎么回答？
🙋 候选人：
- 给风险清单 + 数据 + 建议，不给非黑即白。
- P0/P1 全过，已知 2 个 P2 体验问题，支付链路压测达标，建议可发；搜索排序有个未验证策略需灰度观察——让决策基于信息而不是感觉。
风险驱动的测试（Risk-Based Testing）怎么实践？
👔 Raina面试官： 风险驱动的测试你怎么在实践中落地？
🙋 候选人：
- RBT 的核心是把有限资源投到最可能出事、出事后果最重的地方。
- 实践步骤：一、和 PM/架构一起列风险清单——资损、合规、安全、性能、品牌。二、每个风险评概率×影响，排优先级。三、测试设计对齐：高风险多 case、深测、自动化+压测；低风险抽样或延后。四、发布决策用风险剩余量说话——哪些风险已缓解、哪些接受遗留。
- 落地技巧：需求评审就标风险标签；用例库按风险分级而不是平铺；迭代末做 risk review 调整下轮重点。避免平均用力——低危模块测 100 遍，支付链路没压过。
👔 Raina面试官： 业务方觉得某功能低风险，但你认为高风险，怎么办？
🙋 候选人：
- 拿数据和案例沟通，不是凭感觉杠。
- 类似功能历史事故、监管要求、资金流经路径——写成一页 risk brief 拉会过。实在达不成共识，要求书面签字接受风险，测试留痕。
探索性测试和 scripted testing 怎么搭配？
👔 Raina面试官： 探索性测试和 scripted testing 你怎么搭配？
🙋 候选人：
- 我的比例大约是70% scripted + 30% exploratory，阶段不同会调。
- Scripted：需求明确、回归、合规、自动化——用例可重复、可审计。Exploratory：新功能首轮、复杂集成、刚合完大分支、怀疑有隐藏问题——用 charter 导向（比如折腾 90 分钟支付异常路径），边测边记，结束产出 bug 和补充用例。
- 搭配节奏：新 story 先探索摸坑 → 沉淀成 scripted case → 进自动化。大版本前留探索日；线上事故后针对性探索复现。探索不是随便点点，要有时间盒、目标和 session 记录。
👔 Raina面试官： 探索性测试的发现怎么沉淀？
🙋 候选人：
- 每次 session 结束30 分钟 debrief：新 bug、新用例、新风险写入仓库。
- 好的探索发现 24 小时内转成 regression case，否则下个版本还会踩。用 mind map 或 charter 模板统一记录格式。
版本发布 checklist 你一般会包含哪些项？
👔 Raina面试官： 版本发布 checklist 你一般包含哪些项？
🙋 候选人：
- Checklist 要可勾选、可追责、覆盖回滚，我分六块。
- 质量：P0/P1 缺陷清零或已签字接受；自动化回归全绿；核心链路手工冒烟通过。配置：生产配置 diff 已 review；Feature Flag 默认状态确认；密钥和证书未过期。数据：DB migration 已验证可回滚；缓存预热策略确认。依赖：第三方服务版本和 SLA 确认；降级开关可用。发布：发布窗口和值班人；监控大盘和告警规则就绪；回滚方案和演练。合规：审计日志、隐私文案版本正确。
- 每项有 owner 和证据链接（报告 URL、截图），不是口头测过了。大促 checklist 另附压测和限流项。
👔 Raina面试官： checklist 太长团队敷衍怎么办？
🙋 候选人：
- 分 P0 必检和 P1 选检，P0 不过硬拦发布。
- 用 CI 自动勾选的项（回归通过、覆盖率）别让人手工打勾。每季度根据线上事故更新 checklist，删从不执行的僵尸项。