# 1. 测试金字塔（Unit/Integration/E2E）模型，各层的测试投入比例和覆盖目标？ A E2E 测试数量应最多以覆盖所有场景 B 单元测试无法提供任何反馈价值 C 三层测试投入比例应完全相等 D 测试金字塔主张底层单元测试数量多、速度快、成本低，顶层 E2E 少而精，覆盖关键业务路径 ✓ 正确答案
# 2. 测试奖杯(Testing Trophy)模型（Kent C. Dodds），Static/Unit/Integration/E2E 四层中为何强调 Integration 测试的投入？与金字塔的核心分歧？ A 测试奖杯模型以单元测试为主体 B 测试奖杯忽略 E2E 测试 C 测试奖杯与测试金字塔完全一致 D 测试奖杯模型强调以集成测试为主体，因为前端缺陷多发生在组件交互与用户行为层面，并纳入静态分析 ✓ 正确答案
# 3. 测试策略文档的构成要素与评审时机，测试范围、层级、自动化与风险的决策如何记录 A 测试策略文档只需在项目启动时写一次 B 测试策略文档与风险无关 C 测试策略文档不需要记录测试范围 D 测试策略文档应记录范围、层级、自动化、风险等决策，并在需求/里程碑/复盘等关键节点评审更新 ✓ 正确答案
# 4. 测试策略的制定，如何根据项目特征（团队规模、技术栈、业务风险）设计测试分层？ A 所有项目都应使用相同的测试分层比例 B 应根据团队规模、技术栈、业务风险动态设计测试分层，在成本、反馈与风险间取得平衡 ✓ 正确答案 C 测试分层与业务风险无关 D 小团队也应做完整的大规模自动化
# 5. 测试蜂巢(Honeycomb)模型，以 Integration 测试为核心、减少 Unit 和 E2E 的策略在什么架构下合理？其风险是什么？ A 蜂巢模型以单元测试为核心 B 蜂巢模型以集成测试为核心，适合风险集中在服务/组件集成的架构，但需防范环境耦合导致的 flaky 与单元覆盖不足 ✓ 正确答案 C 蜂巢模型完全不需要 E2E 测试 D 蜂巢模型适用于所有架构
# 6. 基于风险的测试分配(Risk-Based Test Allocation)，如何根据模块的变更频率、缺陷历史、业务影响度动态调整测试投入？ A 测试资源应平均分配给所有模块 B 风险分配一旦确定就不再调整 C 风险评分只考虑变更频率 D 按变更频率、缺陷历史、业务影响度加权评分，把测试资源向高风险模块倾斜并动态调整 ✓ 正确答案
# 7. 敏捷测试四象限与测试金字塔的映射，面向业务/技术、支持编程/评分的象限如何指导策略 A 四象限只关注功能测试 B 四象限主张只做自动化测试 C 四象限与测试金字塔无关 D 四象限用"业务/技术"与"编程/评分"两维度划分测试，Q1 对应单元测试、Q2 对应验收测试、Q3/Q4 对应 E2E 与非功能测试，指导完整平衡的测试策略 ✓ 正确答案
# 8. 测试策略如何随产品阶段演进，MVP 快速验证期、成长期与稳定期的测试投入重心变化？ A 测试投入应随产品成熟度与风险上升而增加，重心从 MVP 的快速验证转向成长期/稳定期的质量保障 ✓ 正确答案 B 所有阶段都应保持相同的测试投入 C MVP 期应做最完整的自动化测试 D 稳定期不需要回归测试
# 9. 如何向管理层解释测试投入，用缺陷成本、发布风险与反馈速度等语言沟通测试策略价值？ A 应使用大量技术术语展示测试专业性 B 用缺陷成本、发布风险、反馈速度等业务语言，结合 ROI 与对比数据论证测试投入对业务目标的支撑 ✓ 正确答案 C 管理层不需要理解测试价值 D 测试投入无法用数据衡量
# 10. 测试金字塔的反模式，冰淇淋（Ice-Cream Cone）与纸杯蛋糕（Cupcake）模型为何危险，如何把过度 E2E 的用例重构下沉？ A 冰淇淋（E2E 过多）与纸杯蛋糕（缺集成层）都导致反馈慢、成本高，应把 E2E 中验证组件行为与交互的用例重构下沉为单元/集成测试 ✓ 正确答案 B 冰淇淋模型是健康的最优结构 C 纸杯蛋糕模型无需集成测试 D 反模式只影响测试数量、不影响反馈
# 11. 测试分层与 CI 阶段的映射，单元/集成/E2E 分别在提交、PR、合入与发布阶段的执行策略，反馈速度与门禁如何设计？ A 所有测试都应在发布阶段一次性执行 B E2E 测试应每次都全量执行 C 单元/静态分析在提交与 PR 阶段快速反馈，集成/E2E 在合入与发布阶段把关，按层级分级执行并设计门禁 ✓ 正确答案 D 单元测试应在发布阶段才执行
# 12. 测试执行时长与并行化，当 E2E 用例过多导致流水线超时，如何用分层、并行与按影响范围筛选控制总时长？ A 只能增加机器一次性解决 B E2E 用例越多越好，无需关心时长 C 通过分层下沉、并行执行、按影响范围筛选与分级门禁的组合，可把 E2E 总时长控制在流水线预算内 ✓ 正确答案 D 并行化无需处理测试间依赖
# 13. 测试右移(Shift-Right)，生产环境监控、混沌工程、A/B 测试在测试策略中的定位？ A 测试右移可完全替代左移测试 B 混沌工程与稳定性验证无关 C 右移只用于开发阶段 D 测试右移通过生产监控、混沌工程、A/B 测试验证真实环境下的行为，与左移互补、共同构成完整保障闭环 ✓ 正确答案
# 14. 微服务架构下的测试策略设计，服务间契约测试、消费者驱动测试、端到端场景测试的比例如何确定？如何处理分布式事务的测试？ A 微服务下应大量使用 E2E 测试验证所有集成 B 分布式事务必须保证强一致，无需测试补偿 C 微服务不需要契约测试 D 以单元测试为主，契约/消费者驱动测试保障接口一致，E2E 只覆盖关键链路；分布式事务重点验证最终一致性与补偿逻辑 ✓ 正确答案
# 15. 金字塔各层自动化的维护成本如何平衡？ A E2E 自动化维护成本最高，应通过控制 E2E 数量、提升稳定性、减少实现耦合、定期重构来平衡维护成本 ✓ 正确答案 B 各层维护成本完全相同 C 单元测试维护成本最高 D 维护成本与测试层级无关
# 16. B2B 与 C 端产品的测试策略差异，长链路业务 vs 高并发流量的测试重点如何取舍？ A B2B 重点在长链路业务正确性与数据一致性，C 端重点在高并发性能、稳定性与兼容性，测试投入应随产品风险特性取舍 ✓ 正确答案 B 两类产品的测试重点完全相同 C C 端产品不需要性能测试 D B2B 产品不需要集成测试
# 17. 数据密集型系统的测试策略，数据质量、血缘与对账如何融入分层测试设计？ A 应通过数据质量校验、血缘追踪与对账验证，把数据正确性校验融入分层测试并纳入门禁 ✓ 正确答案 B 数据密集型系统只需测试 SQL 代码是否运行 C 数据血缘与对账无测试价值 D 数据测试无法自动化
# 18. 测试策略与团队成熟度的关系，团队工程能力不足时如何分阶段推进策略落地？ A 测试策略应与团队成熟度匹配，从基础单测与 CI 起步，分阶段由易到难推进，配套培训提升能力 ✓ 正确答案 B 无论团队能力如何，都应一步到位推行完整测试策略 C 团队能力不足时不需要测试策略 D 成熟度低的团队应直接上混沌测试
# 19. 测试策略中的覆盖率与质量度量，行/分支覆盖、需求覆盖率与缺陷逃逸率如何组合使用，防止被单一指标误导？ A 只要行覆盖率达标就说明质量可靠 B 缺陷逃逸率低就说明测试很好，无需其他指标 C 需求覆盖率与代码覆盖无关 D 应组合行/分支覆盖、需求覆盖率与缺陷逃逸率，并关注测试有效性，避免被单一可刷指标误导 ✓ 正确答案
