说说测试金字塔，自动化怎么分层？

测试金字塔是三层：底层单元测试最多、跑得最快最稳；中层接口自动化适量、覆盖业务流；顶层 UI 自动化最少、只做关键路径。比例大致 7:2:1。这样分层是因为越往上越脆弱越慢，全压 UI 层会又慢又难维护。反面是冰淇淋筒——大量手工加厚 UI 层，回归一次要一周。

我在团队落地的分层：单测由开发负责纳入 CI 门禁，覆盖率阈值卡新增代码；接口层用 pytest 加 requests 覆盖核心业务流，每次提测自动跑，20 分钟出报告；UI 层只保留登录、下单、支付十条主链路，夜里定时跑。结果是回归从两天人工到一夜自动，UI 脚本维护量降七成。

金字塔我讲本质而不是形状：自动化分层的依据是反馈成本与稳定性——反馈越早定位越便宜，所以要左移；投资回报决定各层的量。我也会讲现代变体：微服务下对独立消费契约测试的重视、前后端分离后 UI 层进一步收窄、以及谷歌对不写中层而重小测试的实践。教条套形状不如讲清决策逻辑。

追问『UI 自动化为什么克制』：脆弱、慢、定位维护成本高，业务价值密度低；『接口自动化怎么起步』：先覆盖资金和核心交易流，数据构造用工厂函数，断言数据落库而非仅看响应码；『覆盖率卡多少』：看增量而非全量，核心模块高要求，工具类 80% 以上，为凑数写的测试无价值。