3、自动化测试基础：自动化测试金字塔、分层测试策略、测试框架选型
好，咱们进入自动化测试的核心部分。说实话，我见过太多团队一上来就搞UI自动化，结果维护成本高得吓人，最后全烂尾了。为什么会这样？说白了，就是没搞懂自动化测试的分层逻辑。
今天咱们就聊聊三个关键问题：测什么、怎么分、用什么工具。
3.1 自动化测试金字塔——别把鸡蛋放一个篮子里
这个概念你可能听过，但真正用好的团队不多。我个人的理解是：金字塔不是教条，而是一种风险控制策略。
经典的测试金字塔长这样：
| 层级 | 比例 | 速度 | 维护成本 | 典型场景 |
|---|---|---|---|---|
| UI测试（顶层） | 10% - 20% | 慢（秒级） | 高 | 关键业务流程、用户主路径 |
| 服务/API测试（中间层） | 30% - 40% | 快（毫秒级） | 中 | 业务逻辑、接口契约、数据校验 |
| 单元测试（底层） | 50% - 60% | 极快（微秒级） | 低 | 函数逻辑、边界条件、异常处理 |
我在项目中遇到过一种情况：团队花了三个月写UI自动化，结果每次页面改版，脚本就全崩。后来我们调整策略，把重心放到API测试上，UI只覆盖最核心的5条路径。嗯，效果立竿见影。
3.2 分层测试策略——低代码平台怎么落地
低代码平台有它的特殊性。你想想看，普通应用是固定页面，低代码平台是动态生成页面。所以分层策略要调整一下。
我一般把低代码平台的自动化测试分成四层：
- 组件层测试：每个原子组件（输入框、下拉框、表格）的独立功能。比如一个「日期选择器」，要测它的格式校验、范围限制、联动逻辑。
- 逻辑层测试：页面编排、数据绑定、事件触发。这部分我习惯用接口测试来覆盖，因为页面渲染结果不稳定，但后端逻辑是稳定的。
- 流程层测试：跨页面的业务流程。比如「创建表单→填写数据→提交→审批→归档」。这种场景用API串联测试，比UI稳定得多。
- UI层测试：只覆盖用户最关心的视觉和交互。比如「按钮是否可点击」「弹窗是否正常显示」。这部分我控制在10%以内。
避坑指南： 我曾经犯过一个错误——把所有测试都放在UI层。结果每次组件升级，测试脚本就要重写。后来我改成「组件层用单元测试，逻辑层用接口测试，流程层用契约测试」，维护成本直接降了60%。
3.3 测试框架选型——别盲目追新
框架选型这事儿，我见过太多人踩坑了。有人看社区火就选，有人看大厂用就选。其实最关键的指标就三个：团队熟悉度、生态成熟度、维护成本。
我整理了一个对比表，供你参考：
| 测试类型 | 推荐框架 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| 单元测试 | Jest / Vitest | 速度快、断言丰富、快照测试 | 对DOM操作支持一般 | 组件逻辑、工具函数 |
| API测试 | Postman + Newman / Supertest | 易上手、可集成CI、支持数据驱动 | 复杂场景需要写脚本 | 接口契约、数据校验 |
| UI测试 | Cypress / Playwright | 可视化、调试方便、支持网络拦截 | 速度慢、环境依赖强 | 关键用户路径、回归测试 |
| 组件测试 | Testing Library + Storybook | 贴近用户行为、可独立运行 | 需要额外配置 | 低代码组件库 |
我个人习惯是：单元测试用Jest，API测试用Supertest，UI测试用Playwright。为什么选Playwright？因为它支持多浏览器、网络拦截、自动等待，对低代码平台的动态页面特别友好。
3.4 实战建议——从零搭建测试体系
如果你现在要从零开始，我建议按这个顺序来：
- 先搭单元测试：把核心组件和工具函数覆盖掉。这一步能帮你发现80%的逻辑错误。
- 再搭API测试：把业务接口的增删改查、异常场景覆盖掉。这一步能保证后端逻辑的稳定性。
- 最后搭UI测试：只覆盖3-5条核心用户路径。比如「登录→创建应用→发布→预览」。
- 持续集成：把测试脚本集成到CI/CD流水线中。每次提交代码自动跑，失败就阻断发布。
嗯，这里有个小技巧：测试用例的命名要规范。我一般用「模块_功能_场景_预期结果」的格式。比如：form_submit_empty_field_should_show_error。这样一眼就能看出测的是什么。
我的经验： 低代码平台的测试，最难的不是写脚本，而是维护测试数据。我建议用「测试数据工厂」模式，每次测试前自动生成干净的数据，测试完自动清理。这样就不会出现「测试数据污染」的问题。
好了，这一章的内容就这些。记住一句话：自动化测试不是越多越好，而是越稳越好。下一章咱们聊聊「低代码平台的组件测试实战」，到时候我会手把手带你写一个完整的组件测试用例。