测试分层的真实成本：用例越多，维护负担越重

测试分层的常见误解是按数量分配：底层大量、中层若干、上层少量。但分层的核心是责任划分，数量只是结果。真正需要回答的是：某一类错误由哪一层负责发现？如果同一类错误被三层重复覆盖，就会同时付出三份维护成本。

上层用例最贵。它依赖完整环境，执行慢，且界面文案、按钮位置一变动就要调整。如果让上层去覆盖各种边界条件，维护负担会迅速累积，最后团队选择直接删掉这些用例，覆盖率出现断崖。更稳的做法是上层只验证关键业务流程能否走通，把边界交给更下层。

中层用例承担主要压力，负责模块之间的协作与规则。它的成功要素是可控的环境：外部依赖用可替换的实现顶上，让用例只测自己的逻辑。一旦中层测试里也引入了真实网络或存储，它就会逐渐变得和上层一样不可靠，失败原因难以判断。

底层用例便宜但不万能。它跑得快、定位准，适合覆盖判断分支与计算细节。问题在于，底层全绿并不代表系统可用——模块各自正确而组合出错的情况，底层测不到。把质量完全押在底层数量上，容易形成虚假的安全感。

一个实用的自检方式：每次出现线上缺陷，先问这个缺陷应该由哪一层拦住。如果答案是上层，说明中层责任缺位；如果哪一层都拦不住，说明这块设计本身缺少可测试的边界。测试金字塔要维护的是这套责任关系，而不是每次补一批用例。