写在前面：
“抖腿”App 准备上线“直播间打赏”功能。这涉及到金钱、并发、动画特效，逻辑极其复杂。 周五下午，开发老张和小王终于把代码合完了，拍拍屁股说：“提测了！”
测试小姐姐刚打开App，还没等点开直播间，程序就崩了。 测试怒了：“这怎么测？连基本逻辑都没跑通！” 老张一脸无辜：“我本地跑得好好的，可能环境有问题吧，你再排查下？”
这就是典型的“测试滞后”引发的灾难。 在敏捷中，我们提倡：测试不应该是一个“阶段”，而应该是一个“过程”。
一、 为什么要让测试“提前进场”？
有一个著名的质量成本模型：
- 在需求阶段发现一个Bug，成本是1。
- 在开发阶段发现一个Bug，成本是10。
- 在上线前测试发现一个Bug，成本是100。
- 如果上线后被用户发现，成本是1000（涉及退款、口碑、甚至法律风险）。
测试左移的核心逻辑就是：越早发现问题，修复的代价就越低。
二、 落地指南：测试人员在不同阶段该干什么？
不懂技术的项目经理往往以为：没有代码，测试就没活干。其实，高段位的测试人员在代码写出来之前，就能消灭掉50%的Bug。
1. 需求评审阶段：测试是“逻辑杠精”
当PM在讲PRD（需求文档）时，测试人员不应该只是听，而要开启“破坏性思维”。
- PM说：“用户点击打赏，屏幕出现大火箭动画。”
- 测试问：“如果用户余额不足怎么办？如果用户连点10次怎么办？如果打赏时网络断了钱扣了但没动画怎么办？如果两个人同时打赏，动画会重叠吗？”
效果：这些问题会逼着PM和开发在写代码前就补齐逻辑漏洞。这叫“缺陷预防”。
2. 开发编码阶段：测试在“修堡垒”
当老张写代码时，测试小姐姐不应该在旁边刷手机，而要做两件事：
- 编写测试用例：基于PRD和技术方案，提前写好测试路径。
- 接口测试（API Testing）：后端接口写好一个，测试就用Postman测一个。不需要等App界面出来，直接测数据逻辑。
效果：当App界面做好的时候，底层的接口已经是稳固的了，不会出现“一调接口就报错”的低级问题。
3. 提测门槛：冒烟测试自动化
利用我们在第14讲学过的“冒烟测试”，将其自动化。开发每提交一次代码，系统自动跑一遍核心流程。
效果：像老张那种“安装就崩溃”的版本，根本进不了测试小姐姐的门，直接被系统打回。
三、 项目经理的协调艺术：如何让开发接受“测试进场”？
开发人员（特别是像老张这种工作多年的老油条）最讨厌别人在自己写代码时“指手画脚”。项目经理要通过机制来化解矛盾。
1. 建立“测试驱动开发”的氛围（ATDD）
你可以推行“验收测试驱动开发”。 在迭代开始的第一天，测试人员就把“验收标准”列出来给开发看。 “你们只要你能跑通这5条路径，我就算你们过关。”
效果：给开发一个“开卷考试”的提纲。开发会觉得测试是在帮他提早发现Bug，而不是在找他麻烦。
2. 碎片化提测（Small Batches）
不要等整个“直播间”功能做完再提测。
- 第一天：跑通“进入直播间”接口 ->提测。
- 第三天：跑通“余额查询”逻辑 ->提测。
- 第五天：跑通“动画渲染” ->提测。
效果：测试的工作量被摊平到整个迭代中，不会在最后两天突然爆仓。
四、 真实职场中的“深水坑”：测试成了“保姆”？
警告：实施测试前置时，容易出现一个偏差——开发变得依赖测试。 “反正测试会提前帮我找Bug，我写完不测了，直接扔给他们。”
PM必须划清界限：
- 开发必须写单元测试：自己的逻辑底线由自己守住。
- 冒烟测试不通过不收货：只有通过了基础测试，测试人员才介入复杂的探索性测试。
五、 总结：质量是全团队的责任
敏捷团队中，测试人员不应该是“抓Bug的人”，而应该是“质量顾问”。
当测试人员提前进场，PM会发现：
- 迭代后期的“Bug高峰”消失了。
- 开发和测试之间的“撕逼”减少了。
- 演示会（Review）时的底气更足了。
【第21讲·思考】
场景回顾：“直播间打赏”功能上线前夕。测试小姐姐在需求评审阶段提出了一个问题：“如果用户在疯狂点火箭打赏的时候，正好来了个电话，App切换到后台，这钱是扣了还是没扣？”
当时老张觉得这是“极端情况”，没理会。结果灰度测试后，真的发现有用户因为接电话导致打赏失败且扣了钱，引发了大规模投诉。
请思考并回答：
- 复盘题：既然测试已经提前提出了风险，为什么这个Bug还是流到了线上？是流程中缺失了哪个环节？（提示：关于Bug的跟踪与闭环）。
- 策略题：作为项目经理，你如何确保测试人员提出的这种“逻辑假设”，能够被开发真正落地到代码里，而不是被当作“耳边风”？