第九章：功能测试流程与自动化脚本
序言
功能越来越多了，你开始遇到一个崩溃的现象："打地鼠"。你刚修复了"登录页"的 Bug，结果"注册页"又打不开了；你优化了首页的样式，结果购物车按钮点不动了。
老师傅告诉你，要防止这种"牵一发而动全身"的惨案，得两手抓：
首先是"内功"：合理规划代码结构。不要把所有逻辑都堆在一个文件里，而是拆分到独立模块（components/ 放组件、lib/ 放工具函数、app/ 放页面）。结构清晰了，改动 A 模块就不容易误伤 B 模块。
其次是"外功"：回归测试。每次修改后把以前的功能都测一遍，确保没有被新代码"误伤"。但人肉点点既累又容易漏，这时候才需要考虑自动化测试。
不过，老师傅也给了一句务实的忠告： 自动化虽然爽，但也不是必须的。如果你的项目一共就两个页面，或者还在疯狂改需求的阶段，那还是直接上手点点更实惠。不要为了自动化而自动化，陷入写脚本的时间比写代码还长的陷阱。
自动化测试的投入产出比
何时需要自动化测试？
✅ 应该自动化：
- 项目有 5+ 个页面
- 核心业务流程超过 3 个步骤
- 团队规模超过 2 人
- 需要频繁修改代码
- 已经遇到过"修复 Bug A 引入 Bug B"的情况
❌ 暂不自动化：
- 原型验证阶段（需求还在快速变化）
- 一次性项目（做完就不再维护）
- 非常简单的页面（如静态展示页）
记住：测试是为了提高信心，而不是为了完成任务
测试分层
老师傅给你画了一张测试金字塔：
- 单元测试（底层，最多）：测试单个函数、组件
- 集成测试（中层）：测试模块之间的协作
- E2E 测试（顶层，最少）：模拟真实用户操作完整流程
在 AI 编程时代，你的角色从"写测试代码"转变为"设计测什么"。让 AI 生成测试，你负责审查和调整。
本章学习路径
- 测试策略与分层 → 何时需要自动化、测试金字塔
- API 测试实战 → 比 UI 测试更稳定的接口测试
- E2E 测试与问题诊断 → E2E 陷阱、日志定位、Playwright 简介
- TDD 与自动化工作流 → 测试驱动开发、提交前自动运行测试
Playwright 定位：E2E 测试工具之一，本章作为补充内容介绍，非核心重点
AI 编程时代的测试新范式
传统测试流程（耗时）：
手动写测试代码（1小时）
→ 运行测试
→ 修复错误
→ 重复AI 辅助测试流程（快速）：
让 AI 生成测试（10秒）
→ 运行测试
→ 让 AI 修复错误（10秒）
→ 完成关键转变：
- 从"如何写测试" → 转变为"设计什么测试"
- 从"手动编写" → 转变为"审查与调整"
- 从"测试覆盖率" → 转变为"测试价值"
你的角色：测试架构师，而非测试代码工
API 测试
老师傅提醒你：API 测试比 UI 测试更稳定。页面报错不一定是按钮坏了，可能是后端接口挂了。而且 UI 经常变（按钮换个位置、改个样式），但 API 接口相对稳定。
让 AI 生成 API 测试很简单：引用 app/api 文件夹，告诉 AI 为每个接口生成测试，覆盖正常请求和错误场景。AI 会自动分析出注册、登录、获取数据等接口，并生成对应的测试代码。
这种方式能快速定位问题：是前端展示逻辑错了，还是后端数据处理有问题？
E2E 测试与陷阱
老师傅介绍了 E2E（端到端）测试——模拟真实用户操作完整流程。但它有几个常见陷阱：
- 测试不稳定（Flaky）：同样的测试有时过有时不过
- 过度测试：把所有功能都用 E2E 测，维护成本爆炸
- 数据依赖：测试之间共享数据，一个挂了连锁反应
问题诊断：当 E2E 测试失败时，看日志是关键。老师傅教你从日志中定位：是元素没找到？还是接口超时？还是断言失败？
Playwright 是 E2E 测试工具之一，支持录制操作自动生成代码。但记住：它只是工具选项之一，本章作为补充内容介绍。
TDD 与自动化
老师傅介绍了更高级的玩法：测试驱动开发（TDD）。不是先写代码再补测试，而是先写测试，再写代码。
TDD 工作流：
- 写测试 → 明确预期输入输出
- 运行失败 → 确认测试能捕获错误
- 写最少代码 → 让测试通过
- 运行通过 → 测试变绿
- 重构 → 优化代码，保持测试通过
写测试的过程其实是在"设计接口"——思考方法应该接收什么参数、返回什么结果。
自动化工作流：配置 Git Hooks，在 git commit 前自动运行测试。测试失败就阻止提交，确保有问题的代码不会进入仓库。
上一章：第八章：安全与用户认证