测试金字塔与自动化分层策略¶

教程简介

测试金字塔用于帮助团队决定：哪些测试应该多写，哪些测试应该少写，哪些测试应该手工探索。它不是固定比例公式，而是一种控制测试成本和反馈速度的策略。

前置要求¶

项目	要求	获取方式
软件测试理论基础	了解测试分类、测试级别	软件测试理论基础教程

新手导读¶

很多新手一听自动化，就想直接写 UI 自动化。但真实项目里，如果 UI 自动化太多，常见结果是：运行慢、误报多、维护成本高。测试金字塔就是提醒我们，不要把所有质量保障都压在 UI 层。

第一遍先记住：

单元测试：快，定位准，开发主导。
接口测试：稳定，性价比高，测试常重点参与。
UI 测试：最接近用户，但慢且维护成本高，只覆盖核心流程。
手工探索：发现脚本想不到的问题，不能被自动化完全替代。

一、测试金字塔是什么¶

经典测试金字塔大致分为三层：

        UI / E2E 测试
       ───────────────
       服务 / 接口测试
     ───────────────────
       单元 / 组件测试

层级	特点	适合覆盖
单元 / 组件测试	快、便宜、定位准	函数、类、组件、规则计算
服务 / 接口测试	稳定、性价比高	接口业务逻辑、数据流、权限、异常
UI / E2E 测试	接近用户、成本高	登录、下单、支付前置、核心冒烟

金字塔不是要求所有项目都按固定比例写测试，而是提醒：

底层测试应该多，提供快速反馈。
中层测试覆盖业务逻辑，性价比高。
顶层 UI 测试应该精简，覆盖真正关键的用户路径。

二、为什么不能全靠 UI 自动化¶

UI 自动化的优点是接近用户真实行为，但它也有明显成本：

问题	说明
运行慢	打开浏览器、加载页面、等待接口都耗时
定位脆弱	页面结构和文案变化会导致脚本失败
失败原因复杂	可能是前端、后端、网络、数据、环境或脚本问题
数据准备麻烦	下单、支付、权限等场景需要复杂前置数据
维护成本高	页面改版后需要批量修改定位器和断言

反模式：

       大量 UI 自动化
      ───────────────
       少量接口测试
     ───────────────
       几乎没有单元测试

这种结构像“倒置金字塔”或“冰淇淋筒”，短期看起来覆盖很多，长期会因为不稳定和维护成本拖垮团队。

三、每一层应该测什么¶

3.1 单元测试¶

适合：

金额计算。
优惠规则。
参数转换。
日期处理。
权限判断函数。
状态流转规则。

例子：

优惠券满 100 减 20：
输入金额 99，不能使用。
输入金额 100，可以减 20。
输入金额 101，可以减 20。

测试人员不一定负责写单元测试，但要能和开发讨论：哪些核心规则应该在单元层先保障。

3.2 接口测试¶

适合：

登录接口。
商品查询接口。
创建订单接口。
订单详情接口。
取消订单接口。
权限和越权验证。
数据一致性验证。

接口测试优势：

比 UI 稳定。
能覆盖更多异常参数。
能直接验证业务码、字段和数据库。
容易接入 CI。

创建订单接口可以覆盖：

场景	应放层级
商品不存在	接口测试
库存不足	接口测试
未登录	接口测试
重复提交	接口测试
订单金额计算	单元 + 接口测试
页面点击下单按钮	UI 冒烟测试

3.3 UI / E2E 测试¶

适合：

登录成功。
搜索商品。
加入购物车。
创建订单前置流程。
权限页面跳转。
核心冒烟流程。

不适合第一版大量自动化：

活动页视觉细节。
频繁变化的运营页面。
第三方真实支付。
很复杂的数据组合。
后台低频配置。

UI 自动化的目标不是覆盖所有细节，而是每天快速确认用户最重要的路径没有断。

四、手工测试和探索式测试放在哪里¶

测试金字塔不代表“手工测试没价值”。自动化适合重复、稳定、明确断言的场景；手工和探索式测试适合发现未知问题。

适合手工探索：

新需求第一次测试。
业务规则不清楚。
页面交互复杂。
用户体验判断。
异常流程和组合场景。
高风险模块上线前。

探索式测试可以按下面方式组织：

目标：探索购物车金额计算是否稳定
范围：优惠券、满减、库存、勾选、删除
时间：60 分钟
记录：发现的问题、疑问、风险、后续用例

优秀测试策略应该是：

自动化负责稳定重复的检查。
手工探索负责发现新风险和未知问题。

五、自动化分层决策表¶

遇到一个测试点时，可以用这张表判断放在哪一层：

问题	如果答案是“是”	建议
是否是纯函数或规则计算	是	单元测试
是否不需要页面就能验证业务	是	接口测试
是否需要验证用户页面路径	是	UI 自动化或手工
是否变化频繁	是	先手工，稳定后再自动化
是否很难准备数据	是	优先接口层或保留手工
是否每天都要回归	是	自动化优先
是否只有人能判断体验	是	手工探索

例子：

测试点	推荐层级
密码长度校验	单元 + 接口
登录成功返回 token	接口
登录页输入账号密码跳转首页	UI
订单金额计算	单元 + 接口
用户 A 访问用户 B 订单	接口
首页按钮是否美观	手工
活动页复杂交互体验	手工探索
创建订单后库存扣减	接口 + 数据库校验

六、电商项目分层示例¶

以电商系统为例：

单元 / 组件层¶

模块	测试点
价格计算	原价、折扣、满减、优惠券、运费
库存规则	库存为 0、库存不足、扣减和释放
订单状态	待支付、已支付、已取消、退款中
权限规则	普通用户、客服、管理员可操作范围

接口层¶

接口	测试点
`/api/login`	正常登录、密码错误、锁定、token
`/api/products`	分页、筛选、搜索、无结果
`/api/cart`	添加、修改数量、删除、库存不足
`/api/orders`	创建订单、未登录、商品下架、重复提交
`/api/orders/{id}`	查询自己的订单、越权查询

UI 层¶

流程	断言
登录	页面显示用户昵称或退出按钮
搜索商品	搜索结果出现目标商品
加入购物车	购物车出现商品名称、数量和价格
订单前置	确认订单页金额和地址展示正确

手工探索¶

主题	关注点
优惠叠加	优惠券、满减、会员价组合
多端购物车	Web 和 App 同时修改购物车
支付异常	页面关闭、网络中断、重复回调
权限边界	修改 URL、替换 token、直接请求接口

七、CI/CD 中怎么分层运行¶

不同层级的测试不应该全部放在同一个流水线步骤里。

测试集	触发时机	内容	目标
快速冒烟	每次提交	少量接口 + 少量 UI	快速发现主流程断裂
接口回归	合并前或每日	P0/P1 接口	覆盖核心业务逻辑
Web 回归	每日定时	稳定主流程 UI	验证用户路径
性能基线	发版前	核心接口压测	对比容量变化
安全检查	发版前	越权、敏感信息、基础扫描	降低安全风险

GitHub Actions 分层思路：

push -> 运行快速冒烟
pull_request -> 运行接口回归
schedule -> 夜间运行 Web 回归
release -> 运行性能基线和安全检查

八、常见反模式¶

8.1 只追求自动化数量¶

错误表现：

我们有 1000 条 UI 自动化，所以质量很好。

问题：

数量多不代表有效。
如果误报多，团队会不信任自动化。
如果失败难定位，反馈价值很低。

正确关注：

通过率。
稳定性。
失败定位速度。
缺陷发现价值。
维护成本。

8.2 把所有手工用例转成脚本¶

不是所有手工用例都适合自动化。适合自动化的通常是：

稳定。
高频。
可重复。
断言明确。
数据可控。

不适合自动化的通常是：

需求还没稳定。
页面频繁变化。
需要人为体验判断。
数据准备成本过高。
第三方依赖不稳定。

8.3 UI 用例没有分层¶

错误写法：

一个 UI 用例从注册、登录、搜索、下单、支付、退款一直跑到底。

问题：

任意一步失败都会导致整条用例失败。
定位困难。
数据清理麻烦。

更好的做法：

UI 只覆盖关键路径。
前置数据尽量通过接口准备。
复杂业务校验放到接口层。
UI 用例失败时保留截图、Trace、日志。

九、落地步骤¶

第一步：列出核心业务流程¶

例如：

登录
商品搜索
加入购物车
创建订单
支付回调
取消订单

第二步：按风险排序¶

模块	风险	优先级
支付	金额错误、重复扣款	P0
订单	库存超卖、状态错误	P0
权限	数据泄露、越权	P0
商品	搜索不准、库存展示错误	P1
个人中心	展示错误	P2

第三步：决定测试层级¶

测试点	单元	接口	UI	手工
金额计算	是	是	少量	是
库存扣减	是	是	少量	是
登录成功	否	是	是	是
越权访问	否	是	少量	是
页面布局	否	否	少量	是

第四步：建立最小自动化集¶

不要一开始就写完整框架。先建立最小集：

接口冒烟：
- 登录成功
- 商品详情查询
- 创建订单成功
- 未登录创建订单失败
- 用户不能查看他人订单

UI 冒烟：
- 登录成功
- 搜索商品
- 加入购物车

第五步：持续复盘¶

每周或每个迭代复盘：

哪些缺陷是自动化发现的。
哪些缺陷自动化没覆盖到。
哪些用例经常误报。
哪些 UI 用例可以下沉到接口层。
哪些高风险模块还缺覆盖。

十、练习任务¶

练习 1：给登录模块分层¶

请把下面测试点放到合适层级：

测试点	推荐层级
用户名为空	接口 + UI 少量
密码错误	接口
连续输错 5 次锁定	接口 + 数据库校验
登录按钮不可点击样式	手工 / 少量 UI
token 过期访问用户信息	接口
登录成功跳转首页	UI 冒烟

练习 2：给订单模块设计最小自动化集¶

参考答案：

层级	用例
单元	金额计算、优惠券计算、订单状态流转
接口	正常创建订单、库存不足、商品下架、未登录、重复提交、越权查询
UI	登录后加购物车并进入确认订单页
手工探索	优惠叠加、多端修改购物车、支付异常、退款流程

十一、参考资料¶

测试金字塔的重点不是画图，而是用更低成本、更快反馈、更清晰定位的方式保障质量。