3、Bug提交阶段，在bug描述中备注回归时的路径说明。

　　测试工程师提交bug时是在当时的环境下的，也就是说对测试目录，前后操作及路径都非常清楚，对于其他可能的入口或者操作，测试工程师是知道的，因而在提交bug的时候，测试工程师除了提交出现bug的操作步骤之外，如果能补充一下其他可能的路径说明，一方面开发在修复bug的时候可以作为参考，另外一方面测试工程师在bug回归的时候也能够进行更全面高效的回归

　　4、Bug提交完毕，对非用例内影响因素或路径更新到测试用例或者进行备忘。

　　测试影响因素包括各个方面，因为测试工程师的经验，知识储备等各方面原因，测试设计往往会有一定的遗漏，这是不可避免的，在测试过程中我们往往会突然想到某个影响因素或者测试路径，这时候我们往往会去执行一下是否有问题，如果有问题，则会有bug提交，如果没有bug呢？往往我们会去继续去执行下一条case去了。实际上这种情况是对测试工程师脑力的一种浪费，不利于测试工程师经验的积累。

　　我们试想如果我们将这种问题更新进用例，或者至少以某种方式，例如项目便签的方式对这些问题进行记录，当项目完成之后总结阶段，我们将这些问题拿出来，整理，分析，更新文档，更新测试知识库，那么首先我们不用去抓耳挠头想有什么可总结的东西，其次下一次用例设计时我们就可以直接思考到这个因素，而无需执行过程中突然想到了。

　　5、测试过程中，对需求变更等文档进行有效管理。

　　测试过程中因为各种原因，例如需求权限，开发实现的成本，bug影响等，会导致产品需求的变更，测试工程师需要及时相应需求变更，更新测试用例并验证信需求，但是往往因为项目进度或其他原因，测试工程师没有这个时间，我们在回归的时候，如何保证这部分需求变更测试通过呢？那么一个测试整理的需求变更文档是必要的，这其中可以记录产品的原始需求变更，以及测试记录的测试要点。当项目总结阶段，再进行统一的维护，这对产品项目而言是很有效和清晰的方法。

　　6、测试管理中，bug的两阶段回归。

　　其实这个想法并不成熟，仅仅作为参考。在项目过程中，开发和测试是并行的，也就是说到了一定阶段，新建bug是处于收敛而修复bug是发散的。这时候我们往往会进行bug回归，但是我们经常会发现到了上线的时候，某些bug又出现了，或者因为代码提交的问题，或者因为其他模块修改的问题或者逻辑变更的问题，但是一个问题，线上有bug！其实我一直在想，对于这些bug，我们是否可以在上线前的某段时间进行一次粗略的回归呢？

　　7、Bug回归时，尽可能与开发沟通bug原因及修改方案。

　　这个在实际操作时是有困难的，因为哪些bug需要与开发沟通，开发是否有时间等都是影响因素，当然有人会提出由开发在处理bug时提交修改说明，这当然是最好的方式，但是与国内实际环境是不符的，因而我们是尽可能的与开发了解bug原因及修改方案，然后在bug跟踪系统中或者其他什么方式进行一个简明的说明，例如是初始化数据错误这样的原因，那么在后期我们进行bug分析时，就能从一个统计意义上的数据来对测试的测试设计及执行进行一个指导

　　上面就是我对bug如何进行回归的一些想法，更希望大家能有一个讨论的空间。