测试策略
为什么测试不亚于开发？
很多新手觉得"代码写完就完了"。
现实:
- 写完的代码，90% 有问题
- 不测试就上线，用户就是测试员
- 用户发现 bug，体验很差，可能直接流失
我的观点: 测试的重要性不亚于开发本身。
测试的残酷真相
你不可能测试完整。
现实情况:
- 用户的使用场景千奇百怪
- 有些 bug 只在特定条件下出现
- 有些问题只能上线后用户反馈才发现
真实案例: 邮件提醒变骚扰
在 AI News RSS 的 SaaS 版本中:
- 功能: 订阅到期前提醒用户续费
- 测试阶段: 只测了邮件能否发送成功 ✅
- 上线后: 用户投诉"每天都收到提醒邮件，太烦人了"
- 原因: 到期前7天开始，每天发一次
- 问题: 测试时没考虑频率和用户体验
修复:
- 改为: 到期前3天、1天各发一次
- 提供"关闭提醒"选项
教训:
- 测试要模拟真实使用场景
- 涉及时间的功能要测试频率
- 用户体验不只是功能实现
怎么办？
不是"测试到100%完美"，而是:
- 开发阶段尽可能测全
- 核心功能必须测
- 快速响应用户反馈
接受不完美，但要尽力。
我的测试方法: AI + 手动
两层测试策略
功能开发完成
↓
第1层: AI 自己测（写测试脚本，自己跑）
↓
AI 测试通过
↓
第2层: 我手动测（真实环境，实际操作）
↓
测试通过，功能完成1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
第1层: AI 自己测试
具体操作
让 AI 写测试并运行:
你: "刚才写的用户登录功能，帮我写测试脚本，测试:
1. 正常登录
2. 密码错误
3. 用户不存在
4. 空输入
写完后自己运行测试，告诉我结果"
AI: "测试结果:
✅ 正常登录 - 通过
✅ 密码错误 - 通过
❌ 用户不存在 - 失败，返回了500错误而不是404
✅ 空输入 - 通过"
你: "修复用户不存在的问题，返回404，然后重新测试"
AI: [修改后] "全部通过 ✅"1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
AI 测试的局限
AI 测不出来的:
- 真实环境的问题（网络、数据库、部署配置）
- 用户体验问题（界面、交互、提示文案）
- 真实使用场景（比如邮件发送频率）
所以需要第2层测试。
第2层: 手动测试
为什么必须手动测？
AI 测试通过 ≠ 功能可用。
你要在真实开发环境，像用户一样实际操作。
测什么？
1. 正常流程 按照预期使用，每个步骤都操作一遍
2. 异常情况 输入错误数据、网络断开、重复操作、快速点击
3. 边界情况 空输入、超长输入、特殊字符、并发操作
4. 真实场景
- 这个功能上线后，用户会怎么用？
- 高频使用会不会有问题？
- 长时间使用会不会出现问题？
测试的优先级
MVP 阶段: 够用就行
必须测的:
- ✅ 核心功能的正常流程
- ✅ 常见的异常情况
- ✅ 能否部署上线
可以省略的:
- ❌ 自动化测试框架
- ❌ 单元测试全覆盖
- ❌ 性能压力测试
正式产品: 逐步完善
上线后根据用户反馈修 bug，针对高频功能加测试。
不要一开始就追求完美测试。
实用技巧
1. 边写边测
错误做法:
写功能A → 写功能B → 写功能C → 一起测试1
发现问题，不知道是哪个功能的。
正确做法:
写功能A → 测试A → 写功能B → 测试B1
问题立即发现，容易定位。
2. 用 AI 生成测试场景
不知道测什么？让 AI 列出所有测试场景。
你: "用户登录功能，帮我列出所有需要测试的场景"
AI: [列出10+个场景]
你: [照着测]1
2
3
4
5
2
3
4
5
3. 记录 bug 和修复
每次发现 bug，记录: 什么功能、怎么复现、怎么修的。
好处: 类似问题不会再犯。
4. 模拟真实使用
思考: 用户会怎么用？高频使用会有什么问题？
示例: 测试支付功能时，不只测能否支付成功，还要测:
- 支付失败后怎么办？
- 重复支付会怎样？
- 用户取消订单呢？
测试清单
每个功能完成后
AI 测试:
- [ ] AI 写测试脚本并运行
- [ ] 修复 AI 发现的问题
- [ ] 确认 AI 测试全通过
手动测试:
- [ ] 部署到开发环境
- [ ] 正常流程走一遍
- [ ] 测试3-5个异常情况
- [ ] 思考: 用户会怎么用？有什么问题？
上线前
- [ ] 所有核心功能测一遍
- [ ] 在真实环境测试
- [ ] 准备回滚方案
上线后:
- [ ] 监控错误日志
- [ ] 快速响应用户反馈
记住
1. 测试不亚于开发
不测试就上线，就是拿用户当测试员。
2. AI + 手动，两层测试
AI 先测基础功能，你再手动测真实环境。
3. 不可能测试完美
接受不完美，但尽力在开发阶段测全。
4. 边写边测
不要攒到最后，问题立即发现立即修。
5. 模拟真实使用
不只测功能实现，还要测用户体验和真实场景。
核心思想: 测试是为了让产品能用，不是为了完美。够用就行，快速迭代。