专栏进度：04 / 10 (测试理论专题)
在不同的架构（单体、微服务、前端驱动）下，测试资源的分配比例是完全不同的。盲目套用模板是测试经理最容易犯的错误。
一、 经典模型：测试金字塔 (Testing Pyramid)
由 Mike Cohn 提出，是自动化测试的基石。其核心逻辑是：越往底层，测试越快、越稳定、成本越低。
单元测试 (Unit) - 底层：
对象：函数、类。
比例：70% 以上。
价值：极速反馈，毫秒级执行，精准定位代码行。
集成/接口测试 (Service/API) - 中层：
对象：组件间的通信、API 接口。
比例：20% 左右。
价值：验证业务逻辑流转，不依赖 UI，稳定性高。
UI/端到端测试 (UI/E2E) - 顶层：
对象：真实用户路径。
比例：10% 甚至更少。
价值：最后一道防线，确保用户能跑通完整闭环。
二、 现代演进：测试奖杯与测试蜂巢
随着技术栈的演变，金字塔不再是唯一的真理。
- 测试奖杯 (Testing Trophy)
由 Kent C. Dodds 针对 前端/React 领域提出。
核心：扩大集成测试 (Integration) 的比例。
理由：在现代前端框架中，组件间的交互远比单一函数的逻辑复杂。单纯的单元测试无法保证页面不崩，而 UI 测试又太慢。因此，奖杯模型建议将重心放在"接口与组件交互"上。
- 测试蜂巢 (Testing Honeycomb)
由 Spotify 针对 微服务架构 提出。
核心：极致压缩单元测试，由于微服务内部逻辑通常很薄，重心应放在集成测试。
理由：微服务最容易出问题的地方是"跨服务调用"。
三、 动态决策：我该选哪种阵型？
在 CSDN 的硬核实践中，你需要根据项目特点进行"因材施教"：
项目类型 推荐模型 核心逻辑
底层框架/算法库 金字塔 逻辑极深，必须通过海量单元测试锁死逻辑。
现代 Web 应用 奖杯 侧重组件交互和 API 调用，平衡速度与真实性。
微服务集群 蜂巢 重点测试服务间的契约（Contract Testing）和通信。
短期活动 H5 倒金字塔(冰淇淋) 时间极短，不求代码质量，只求 UI 流程能跑通。
四、 避坑指南：警惕"测试冰淇淋"反模式
测试冰淇淋 (Ice Cream Cone) 是最危险的状态：底层测试几乎没有，全靠昂贵的 UI 自动化和手工测试撑着。
后果：测试运行一次要几小时，且经常因为网络闪断、UI 变动导致误报（Flaky Tests）。开发人员会逐渐不再信任测试报告。