测试的目标不是证明"系统能用"，而是找出它在什么情况下不能用。下面五类测试覆盖了实际项目里绝大多数上线上事故来源。
一、功能测试
照着需求文档的验收标准走。重点不在"正常流程走得通"，而在每条规则是否真的生效：必填校验拦不拦得住、重复数据能不能录进去、计算结果是几位小数。
二、边界测试
- 空值：什么都不填直接提交，会发生什么
- 极值：数量填 0、填负数、填一个超大数字
- 长度：名称填 1 个字、填 500 个字
- 特殊字符：带引号、带空格、带 emoji 的内容
- 重复提交：连点两次"保存"会不会生成两条
边界测试往往能一次性暴露最多问题，性价比最高。
三、并发测试
| 场景 | 要观察什么 |
|---|---|
| 多人同时提交同一张单据 | 会不会重复入库、编号会不会撞 |
| 多人同时导出大报表 | 系统是否卡死、内存是否飙升 |
| 定时任务与人工操作同时发生 | 数据是否被写坏 |
| 手机端与电脑端同时操作同一记录 | 后提交的是否覆盖先提交的 |
四、异常恢复测试
- 网络中断后再提交，数据是否一致（不能出现"对方收到了我这边显示失败"）
- 服务重启后未完成的任务能否继续
- 数据库备份当场恢复一次，确认可用
- 断电/强制关机后重启，数据不丢、不重复
五、权限测试
权限测试的关键动作是绕过前端：直接用低权限账号请求高权限接口，看服务端有没有拦住。只在前端隐藏按钮的做法，在测试里必须判为不通过。
测试用例怎么写
不需要复杂表格，三列就够：操作 / 期望结果 / 实际结果。"操作"要写到别人能照着复现的程度。
操作：用"业务员"账号登录，直接在地址栏访问 /admin/user/list
期望：跳转到登录页或提示无权限
实际：（填写）六、上线必须配回滚预案
- 上线前的数据库与代码各自打一个版本标签
- 写清回滚步骤，并至少演练一次
- 约定回滚的触发条件（比如出现哪类问题就立即回滚，不再讨论）
- 上线安排在人少的时间段，并留人值守
提醒：很多团队的回滚预案是"把旧版本重新部署一遍"，但从没试过。真出事时才发现旧数据库结构已经装不回新数据了。