【背景】
　　老师，我想问一下，bug 应该是见一个回归一个，还是集中一大串 bug 回归好呢？我喜欢见一个杀一个，但问题是他如果后面的代码改出问题的话很麻烦。集中一起回归的话，又很浪费时间。怎么办好呢？
　　【你问】
　　什么才是验证 bug 的正确姿势？
　　【我答】
　　验证 bug 是测试工程师基本的工作之一，是在发现 bug 之后，提交给开发工程师修复之后，在新的测试包里需要做的事情，一般包括两部分内容：第一，先按照 bug 的重现步骤执行一下，确认 bug 不存在了，已经被修复了；第二，再根据开发提供的测试建议和你自己分析判断出的范围进行回归测试；
　　当这两部分都完成后，bug 验证工作才算全部完成。一般的测试项目，每个测试包提交到测试这边时，都是要求先完成 bug 的验证和回归测试，再开始继续其他功能或需求的测试，目的是要先确保这个测试包没有太多因为修复 bug 而引发的回归性问题。
　　这个 bug 是改一个验证一个，还是等改了一批再一起验证的问题，其实各有利弊。
　　首先，从测试细度上看的话，前者肯定细于后者，但前者需要测试跟开发有较为频繁的沟通，因为每一个 bug 修复的影响范围都需要被确定。
　　其次，从工作量上看的话，前者肯定大于后者，因为前者是改一个验证一个，而后者可以集中验证，按修复的范围整体回归测试。
　　再者，前者遗漏回归性 bug 的几率也大于后者，因为开发也不可能百分之百给出准确的修复影响范围，所以，可能在后面修复某个 bug 的时候，影响到了前面已经回归过的一个功能点，而开发和测试都没有想到，这样会遗漏。
　　另外，补充一点，是不管是什么类型的产品，或者是什么类型的项目。一定需要有测试版本管理，哪怕是有持续集成支撑的项目，都不建议只要开发有 checkin code，会 build 一个测试包部署到测试环境供测试工程师测试，而是要计划好每天或者每周的 build 频率。
　　我们之前快也做到了 Daily Build，因为自动化测试脚本也无法百分之百覆盖所有的回归性测试，如果无计划无节奏的 build，测试工程师很难保证每个 build 的所有功能都是正常的。
　　只有一种情况需要 build 计划外的测试包，那是某个测试包存在 block bug，不修复的话，某个功能或者有一大片功能点都无法正常继续测试了，这时候必须要求立即修复，然后 build 一个测试包出来给测试工程师。
　　从效率上说，如果有几个 bug 是一条业务流程路径上的，可以通过走一条用例，完成了几个 bug 的验证和回归测试，而如果分开验证，同一条路径，有几个 bug 需要执行几次。
　　从注意力上说，你集中几个属于一个功能模块或业务流程路径上的 bug 做验证，注意力会比你一个个 bug 验证，频繁的在不同的功能模块或路径上切换，来的更集中，质量更好。