如何有效的进行bug回归

　　在软件测试工作中，测试人员大的目标是尽可能的提升产品质量，减少bug数量。因而bug长期以来都困扰着广大测试工程师，如何尽可能减少bug数，在测试的各个阶段都有不同的解决方案，下面以我经常犯错的bug回归阶段的bug遗漏问题说起。

　　回归阶段的bug遗漏通常有几种原因：

　　1、bug回归人员对回归bug所对应的功能不够熟悉，不能或没有举一反三，没有将所测功能的其他入口点遍历

　　2、用例不规范，无法建立bug和用例的对应，回归测试不完整

　　3、用例更新不及时，例如需求变更，随机测试等所发现的bug没有对应的测试用例，回归随机性很大

　　4、项目进度紧，没有时间进行更细致的回归

　　5、测试人员对bug如何修复不了解，错误评估测试回归范围

　　针对上面所遇到的问题，我们主要从两方面思考问题解决方案：方法层面和思想层面

　　从思想层面：

　　思想层面的总结终形成的是一种意识形态上的思考，适合有经验的测试工程师，那么我们可以从如下几个方面去规范我们的思想：

　　1、加强所负责模块的熟悉程度，及时梳理模块功能逻辑及各种入口。

　　2、提升对于bug回归在测试过程中重要性的理解。

　　虽然一个项目下来，我们会发现bug分散于各个模块之中，但是在深入一步看的话，你会发现其实bug也是有一定聚集性的，也是我们经常看到的某某开发工程师的产品经常出问题，某个功能出问题。在例如项目后期阶段，以点辐射开来找bug的效率应该是大于随机测试找bug的效率的。

　　3、加强项目中的文档管理，维护和更新。

　　4、加强项目风险预测和项目时间管理。

　　这样项目预定的流程才能够被执行，不至于因为时间来不及而影响到测试工程师的执行心态及执行成效。

　　5、加强与开发工程师的沟通。

　　方法层面：

　　测试工程师重要的还是实践动手能力，反映到问题总结上面，是需要有一个切实可行的方案出来。

　　针对于bug回归阶段的bug遗漏问题，我认为可以从如下几个方面

　　1、测试用例设计阶段，设计并维护一个各个功能入口的说明文档。

　　其实这个文档的作用很大，一方面对于bug回归阶段的人来说，这是用于提醒的；另外一个方面，在随机测试的时候，随机程度也能有所提高，测试人员能够自己随意组合可能的路径。当然，一样一份文档也能提升文档设计人员，文档阅读人员对于模块的整体认识

　　2、Bug提交阶段，评估阻塞用例说明。

　　在项目初期，尤其是版本刚提交的时候，往往会出现功能无法使用或者没有实现的问题，这时候我们提交bug并不仅仅是说明预期没有实现，更重要的是我们如何备忘这件事情，如何保证没有实现的功能在终版中实现，那么在提交bug的时候，我们需要注明，哪些case被阻塞，该功能没有验证会影响到哪些其他模块和功能的验证等

　　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如何进行回归的一些想法，更希望大家能有一个讨论的空间。