📚 测试知识沉淀方法
1. 为什么测试知识需要沉淀
测试团队最大的成本不是工具或人力，而是重复踩坑。同一个线上事故、同一个配置遗漏、同一个边界场景——如果没有文档化，每个新人都会重蹈覆辙。知识沉淀就是把个人经验变成团队资产。
💡 核心理念如果一个问题被发现了两次，说明知识沉淀失败了。好的沉淀让问题只发生一次。
2. 需要沉淀的六类测试知识
| 类型 | 内容 | 产出物 | 更新频率 |
|---|---|---|---|
| 1. 测试用例库 | 通用场景、边界用例、异常用例 | 用例文档、自动化脚本 | 每个版本 |
| 2. 常见缺陷模式 | 某类功能的高频Bug类型 | 检查清单（Checklist） | 每月 |
| 3. 环境配置指南 | 各环境搭建步骤、常见坑点 | 环境手册 | 环境变更时 |
| 4. 故障复盘报告 | 线上事故的原因、影响、改进 | 复盘文档 | 每次事故后 |
| 5. 测试工具使用手册 | 工具安装、配置、常用脚本 | 操作手册 | 工具升级时 |
| 6. 业务领域知识 | 业务流程、规则、行业术语 | 业务知识库 | 业务变更时 |
3. 测试用例库模板
📄 可复用测试用例模板
============================================
测试用例：[用例标题]
模块：[所属模块] | 类型：功能/性能/安全
============================================
【基本信息】
用例编号：TC-ORDER-001
优先级：P0 / P1 / P2 / P3
创建人：张三
创建日期：2026-05-28
最后更新：2026-06-15（李四补充了并发场景）
【前置条件】
1. 用户已登录，角色为"普通用户"
2. 购物车中有至少2件商品
3. 账户余额 ≥ 订单总金额
【测试数据】
- 测试账号：test_user_001
- 商品SKU：SKU-88421（单价99元）× 2
- 优惠券：无
【测试步骤】
| 步骤 | 操作 | 预期结果 |
|------|------|----------|
| 1 | 进入购物车页面 | 显示2件商品，总计198元 |
| 2 | 点击"去结算" | 跳转到结算页面 |
| 3 | 确认收货地址 | 地址信息正确显示 |
| 4 | 点击"提交订单" | 弹出支付确认框 |
| 5 | 确认支付 | 跳转支付成功页，订单状态为"待发货" |
【检查点】
✅ 订单金额计算正确（198元）
✅ 订单号生成且唯一
✅ 库存扣减正确（SKU-88421 库存 -2）
✅ 订单状态流转正确
✅ 用户收到订单确认通知
【关联信息】
- 关联需求：REQ-ORDER-2026
- 关联自动化脚本：tests/order/test_create_order.py
- 已知缺陷：ORD-105（并发创建时偶发重复订单号）4. 常见缺陷检查清单模板
📄 功能模块检查清单（Checklist）
============================================
订单模块测试检查清单 v3.2
适用版本：v2.0+ | 最后更新：2026-05-28
============================================
【一、金额计算（高频Bug区⚠️）】
☐ 单品金额 × 数量 = 小计？
☐ 多商品小计之和 = 总金额？
☐ 优惠券金额是否正确扣减？
☐ 满减活动是否存在边界问题（刚好满/刚好不满）？
☐ 运费计算规则是否正确？
☐ 金额精度：小数位数是否一致（避免0.01元误差）？
【二、状态流转】
☐ 待付款→已付款→待发货→已发货→已完成
☐ 取消订单后库存是否回滚？
☐ 超时未支付是否自动取消？
☐ 状态回退是否被正确拦截（如已完成不能变为待付款）？
【三、并发场景】
☐ 同一用户同时提交2个订单？
☐ 库存仅剩1件时，2人同时购买？
☐ 优惠券仅剩1张时，2人同时使用？
☐ 支付回调与用户手动刷新同时发生？
【四、数据一致性】
☐ 订单金额与支付记录金额一致？
☐ 订单商品快照与下单时商品信息一致？
☐ 退款后订单金额与退款记录金额一致？
【五、边界值】
☐ 订单金额 = 0 元（积分全额兑换）？
☐ 订单金额 = 99999.99 元（最大值）？
☐ 商品数量 = 999（最大购买数）？
☐ 收件地址含特殊字符？5. 故障复盘报告模板
📄 故障复盘报告（Postmortem）
============================================
故障复盘报告 - #INC-2026-042
日期：2026-05-28 | 作者：张三
============================================
【一、故障概要】
时间：2026-05-28 14:23 - 14:58（持续35分钟）
影响：支付接口超时，约1200笔订单支付失败
级别：P0（核心业务中断）
【二、时间线】（精确到分钟）
14:20 - 运维执行数据库索引优化（计划内变更）
14:23 - 监控告警：支付接口响应时间 > 5s
14:25 - 客服反馈用户支付失败，值班开发介入
14:28 - 确认是新索引导致慢查询，执行回滚
14:30 - 索引回滚完成，但缓存已过期
14:35 - 缓存重建完成，支付恢复
14:58 - 所有积压请求处理完毕
【三、根因分析】
直接原因：新增的复合索引导致支付查询的
执行计划从索引查找变为全表扫描
根本原因：索引变更前未在预发布环境验证
查询性能，缺少索引变更的测试规范
【四、影响评估】
- 用户：约1200笔支付失败，预计流失率3%
- 金额：直接损失约12万元（用户放弃支付）
- 客服：增加约200通咨询电话
【五、改进措施】
| 措施 | 负责人 | 截止日期 |
|------|--------|----------|
| 制定数据库变更测试规范 | 张三 | 6/5 |
| 索引变更必须先过预发布验证 | 李四 | 6/5 |
| 增加慢查询告警（阈值2s） | 王五 | 6/10 |
| 支付接口增加自动降级策略 | 赵六 | 6/20 |
【六、经验教训】
1. 任何生产环境变更必须有回滚预案
2. "小改动"也要走完整的测试验证流程
3. 缓存依赖是双刃剑——加速的同时增加了恢复复杂度6. 知识沉淀的四步工作流
1️⃣ 记录
发现问题/经验后立即记录，不要相信记忆
当时/当天2️⃣ 整理
归类到对应的知识库，补充背景和上下文
每周3️⃣ 分享
团队内宣讲，确保不止一个人知道
每月分享会4️⃣ 更新
定期回顾和修订，剔除过时内容
每季度📝 工具推荐用 Confluence/Notion 做 Wiki 文档库，用 Git 管理自动化脚本和测试数据，用 TAPD/Jira 关联需求→用例→缺陷的追溯链。