什么场景适合自动化？什么场景不适合？
👔 Raina面试官： 自动化不是万能药，你觉得什么场景值得做自动化，什么场景反而别硬上？
🙋 候选人：
- 我的判断标准就两条：重复执行 + 结果可断言。回归主流程、核心接口、冒烟门禁、数据驱动的大批量校验，ROI 通常很高。
- 不适合的也很明确：需求还在频繁变、UI 还在大改、探索性测试、一次性验证、强依赖人工审美或主观判断的场景。还有那种跑 10 分钟才出结果、维护成本比手工测还高 3 倍的，不如先手工把业务摸清楚。
- 别为了有自动化而自动化，先算投入产出：这条用例一年跑多少次？失败时能快速定位吗？
👔 Raina面试官： 如果老板要求全部自动化，你怎么回应？
🙋 候选人：
- 我会用数据说话：分层自动化，而不是 100% UI 自动化。
- 先定门禁清单——P0 接口和核心链路 CI 必跑，UI 只覆盖最稳的主路径。把金字塔比例、维护人力、预期节省的回归时间摆出来，让决策基于 ROI 而不是口号。
自动化测试金字塔是什么？你怎么理解各层的比例？
👔 Raina面试官： 自动化测试金字塔你应该听过，各层比例你怎么理解？别只背图。
🙋 候选人：
- 金字塔的核心思想是：越底层越便宜、越稳定、跑得越快。单元测试最多，接口/集成居中，UI 最少。
- 理想比例没有绝对标准，我常见的是 70:20:10 或 60:30:10，看项目形态。后端重的服务可以单元+接口占 90%；前端交互复杂的产品 UI 层会略高，但也不该倒金字塔——全是 UI 自动化，CI 又慢又脆。
- 比例是结果不是 KPI，关键是每层测的东西不重复：单元测逻辑，接口测契约，UI 测用户关键路径。
👔 Raina面试官： 你们项目金字塔是倒过来的，怎么改？
🙋 候选人：
- 先止血再建设：冻结新增 UI case，把重复断言下沉到接口层；选 5-10 条最稳的主路径保留 UI。
- 同时推动开发补单元测试，接口层接契约测试。每季度 review 各层 case 数和失败率，用数据证明迁移效果。
UI 自动化、接口自动化、单元自动化各有什么优缺点？
👔 Raina面试官： UI、接口、单元三层自动化，各有什么优缺点？你会怎么搭配？
🙋 候选人：
- 单元测试：快、定位准、成本低，但测不了跨模块集成和真实用户路径，需要开发深度参与。
- 接口自动化：速度和稳定性平衡最好，适合回归核心业务逻辑，但不覆盖前端渲染和浏览器兼容。
- UI 自动化：最接近真实用户，能发现集成问题，但慢、脆、维护贵，元素一变就挂。我的搭配是：单元保逻辑，接口保业务，UI 只保关键旅程。
👔 Raina面试官： 只有一个测试，你会投在哪层？
🙋 候选人：
- 看产品形态。纯 API 服务投接口；前后端分离的 B 端系统也是接口为主 + 少量 UI 冒烟。
- C 端重交互的产品 UI 不能没有，但我会先确保接口层覆盖了 80% 的业务断言，UI 只验证页面能走通。
Selenium 和 Playwright 有什么区别？你会怎么选型？
👔 Raina面试官： Selenium 和 Playwright 都做过 UI 自动化的话，你觉得核心差异在哪？怎么选型？
🙋 候选人：
- Playwright 的优势主要在自动等待、浏览器上下文隔离、网络拦截和 trace 调试，开箱即用，flaky 率通常比 Selenium 低。Selenium 生态更老、语言绑定多、团队存量大，和 Grid 集成成熟。
- 选型我会看：团队技术栈、现有资产、是否需要多浏览器/移动端。新项目我倾向 Playwright；已有大量 Selenium 资产且运行稳定，没必要为了追新而全量迁移。
- 工具只是手段，Page Object、数据驱动、CI 集成这些工程化能力比选哪个驱动更重要。
👔 Raina面试官： Playwright 能完全替代 Selenium 吗？
🙋 候选人：
- 大多数 Web 场景可以，但不是 100%。老系统、特殊浏览器、已有 Grid 集群的场景 Selenium 仍有价值。
- 我会做 POC：选 10 条典型 case 两种都跑，对比稳定性、执行时间和团队上手成本，再定方案。
自动化测试框架一般包含哪些模块？
👔 Raina面试官： 如果让你从零搭一个自动化测试框架，一般会包含哪些模块？
🙋 候选人：
- 我会拆成这几块：用例层、Page/API 封装层、驱动层、数据层、配置层、报告层、CI 集成层。
- 用例层只写业务步骤；Page Object 或 API Client 封装定位和请求；驱动层统一管理 WebDriver/HTTP Client；数据层做参数化和 test data factory；配置层管环境切换；报告层出 Allure/HTML + 失败截图；CI 层负责触发、重试、通知。
- 再加日志、重试策略、公共断言和工具类，框架才算能长期维护。
👔 Raina面试官： 小团队资源有限，最小可用框架是什么？
🙋 候选人：
- 最小集：pytest + requests/Playwright + 配置文件 + Allure 报告。
- 先跑通 10 条核心 case 和 CI 门禁，别一上来搞分布式执行和复杂 DSL。框架是生长出来的，不是设计出来的。
Page Object 模式是什么？解决了什么问题？
👔 Raina面试官： Page Object 模式是什么？它到底解决了什么问题？
🙋 候选人：
- Page Object 就是把页面元素定位和操作封装成类，测试用例只调业务方法，不直接写 locator。
- 解决的问题很实在：UI 改版时只改 Page 类，不用改几十条用例；定位逻辑集中维护，可读性也好——用例读起来像登录 → 搜索 → 下单，而不是一堆 findElement。
- 进阶还有 Page Factory、Component Object，大页面可以拆成 Header、Sidebar 等组件复用。
👔 Raina面试官： Page Object 写不好会怎样？
🙋 候选人：
- 最常见的问题是Page 类变成垃圾场——什么逻辑都塞进去，断言也写在 Page 里，反而更难维护。
- 我的原则：Page 只做怎么操作页面，断言和业务流程留在 Test 层；一个 Page 对应一个页面或一个明确的功能区块，别搞上帝类。
自动化用例不稳定（Flaky Test）常见原因有哪些？怎么治理？
👔 Raina面试官： Flaky Test 太折磨人了，常见原因有哪些？你怎么治理？
🙋 候选人：
- 常见原因我归纳几类：时序问题（没等元素就绪）、测试数据冲突、环境不稳定、用例间耦合、第三方依赖。
- 还有硬编码 sleep、并发跑同一账号、网络抖动、数据库没清理干净——都会随机失败。
- 治理上：先量化 flaky rate，失败 case 打标签；禁止无脑 sleep，改用显式等待；用例隔离数据和账号；CI 里 flaky case 连续失败 N 次自动 quarantine，修好了再放回。
👔 Raina面试官： 开发说偶发失败不算 bug，你怎么处理？
🙋 候选人：
- 偶发失败恰恰最危险——团队会逐渐 ignore 红灯，CI 就废了。
- 我会要求：flaky case 要么修、要么暂时 skip 并建 ticket，绝不允许重跑就好成为常态。同时出 flaky 排行榜，每月 review 清零。
自动化测试数据怎么准备和管理？
👔 Raina面试官： 自动化测试数据怎么准备和管理？这块很容易踩坑。
🙋 候选人：
- 我的原则是：数据隔离、可重复、可清理。
- 准备方式：API 前置造数、数据库脚本、Factory 模式动态生成。每条用例用独立数据，避免并发冲突。测完 teardown 清理，或用唯一前缀标记测试数据定期批量删。
- 敏感数据走配置中心或 vault，别硬编码在代码里。大数据量场景可以用 snapshot 还原或专用 test schema。
👔 Raina面试官： 造数成本太高怎么办？
🙋 候选人：
- 分层处理：冒烟用固定最小数据集，回归用 Factory 按需造。
- 和业务方共建 test data API，让造数像调接口一样简单。能复用的 baseline 数据放 fixture，只变增量字段。
持续集成（CI）里自动化测试怎么接入？失败怎么处理？
👔 Raina面试官： CI 里自动化测试怎么接入？失败了怎么处理？
🙋 候选人：
- 接入分阶段：PR 触发轻量冒烟（5-10 分钟），合并后进 test 环境跑全量回归， nightly 跑完整套件。
- 门禁策略：P0 case 失败 block merge；P1 失败 warn 但不 block（看团队成熟度）。报告推送到 PR 评论或群通知，附失败截图和 trace。
- 失败处理：自动重试 1 次排除环境抖动；仍失败则 assign 给最近提交者；flaky 和历史失败分开统计，避免狼来了。
👔 Raina面试官： 全量跑太慢，PR 门禁怎么取舍？
🙋 候选人：
- 用测试分级 + 变更影响分析：只跑改动模块关联的 case 集，核心 smoke 必跑。
- 维护 code→case 映射或 tag，Monorepo 可以用路径触发。全量放 nightly，PR 追求 10 分钟内给反馈。
自动化覆盖率怎么衡量？100% 覆盖有意义吗？
👔 Raina面试官： 自动化覆盖率怎么衡量？100% 覆盖有意义吗？
🙋 候选人：
- 覆盖率要看测什么维度：需求覆盖率（核心场景有没有自动化）、代码覆盖率（单元/集成）、接口覆盖率（API 清单覆盖比例）。
- 100% UI 自动化覆盖通常没意义——成本高、维护地狱、还测不到探索性场景。更有意义的是：P0 业务 100% 有自动化门禁，P1 80%，长尾手工+抽样。
- 别用覆盖率数字糊弄老板，要能说清楚哪些风险被自动化兜住了，哪些没有。
👔 Raina面试官： 代码覆盖率 90% 是不是质量就很好？
🙋 候选人：
- 不一定。覆盖率高不等于测得对——断言太弱、只走 happy path，90% 也可能是空指标。
- 我会结合 mutation testing 或 review 断言质量，关注分支覆盖和关键路径覆盖，而不是单纯追求数字。