客户是一家在线教育平台，提供互动课程、作业、学生和家长个人账户以及在线支付。业务有明显季节性：九月新生最多，开学头几周平台停摆就意味着永久失去客户。公司没有内部 QA 团队，开发人员只能在其他工作间隙测试；发布前的回归测试要花三天，仍会漏掉付款、预约课程和进入课堂等关键场景。客户在一次支付故障导致学校失去部分夏季报名线索后找到了我们。
从零建立质量保障流程：
根据业务风险安排测试优先级、自动化关键场景、把检查集成到 CI，并在九月高峰前进行负载测试。限制条件是开发不能停：版本仍每周发布，而九月不会等待。
我们没有从自动化测试开始，而是先做风险分析：哪些场景最常出错，哪里出错代价最大。自动化严格按照这份清单推进。
- 审计质量：分析过去半年的缺陷，访谈各团队，梳理问题最严重的场景——付款、课程预约、进入课堂和家长通知。
- 编写测试策略：制定测试层级、责任范围、功能完成定义和缺陷报告规范，供三个开发团队统一执行。
- 自动化关键路径：用 Playwright 为 Web 平台编写 E2E 场景，为后端编写 API 测试，并在每次发布前运行 smoke 测试集。
- 将 QA 门禁嵌入 CI：smoke 测试未通过就不能发布；完整回归每晚运行，结果在 GitLab 中向所有团队公开。
- 用 k6 进行负载测试：模拟九月高峰流量，找出瓶颈，并在旺季前与后端团队一起解决。
- 把流程交给客户团队：提供文档和规范，并培训 QA 工程师使用自动化测试与流水线。
关键决策是根据业务风险排序，而不是追求看起来「漂亮」的覆盖率。我们没有刻意追求 100% 自动化：关键场景覆盖率达到 75% 就已获得大部分收益，因为保护的正是平台赚取收入或流失客户的关键路径。其余场景在重要发布前通过人工探索式测试覆盖。
主要经济效果是把缺陷发现时点前移：在 CI 中被自动测试发现的缺陷，修复成本比被学生家长在生产环境中发现的缺陷低数十倍。平台带着更强的韧性进入旺季，团队也能更频繁地发布更改，而不再担心「周五效应」。此外，业务部门的信任提高了：销售团队现在可以坦诚地向合作学校承诺，招生高峰期间平台依然稳定。
| 指标 | 结果 |
|---|---|
| 生产环境关键缺陷 | 每月 5–7 个 → 每季度 1–2 个 |
| 发布前回归测试 | 人工 3 天 → 自动化测试 4 小时 |
| 九月负载高峰 | 每年都有事故 → 0 起事故，无性能下降 |
| 缺陷发现时机 | 大多在生产环境 → 自动测试在发布前发现 |
指标取自案例原始材料。仅在来源明确记录时注明统计周期。
- 每季度关键缺陷（此前每月 5–7 个）
- 1–2
- 自动化回归测试（此前人工需 3 天）
- 4小时
- 的关键场景由自动化测试覆盖
- 75%
- 九月高峰期的事故数
- 0
自动化测试覆盖的关键场景
生产环境关键缺陷
数值越低越好发布前回归测试
数值越低越好示意刻度：将 3 天换算为 72 小时。计算条形长度时，将每月缺陷范围乘以三换算为季度范围；比较的是上限。
- 01提交代码
- 02冒烟测试集测试未通过，不予发布
- 03发布每周
- 04每晚运行完整回归测试
建议平台下一步推进：
- 视觉回归测试：自动检查课程、邮件和个人账户的布局。
- 测试数据工厂：每次运行都生成真实的学生、班级和付款数据。
- 生产环境 QA：使用 feature flags 和金丝雀发布，逐步启用新功能。
我们不再害怕发布。以前每个星期五都可能变成处理投诉的会议，现在上线生产环境只是十五分钟的例行操作。
— 在线学校 CTO