一个Bug的生命周期是从创建开始到关闭结束，而Bug能否关闭就取决于回归测试的结果，测试人员可能很多都对Bug灵敏度有较高要求，但是对于回归测试的把控或质量掌握的程度却比较模糊。而关于回归测试的范围、回归测试的开展正是本文讨论的重点。
回归测试是软件测试中不可忽视的一部分，回归测试是对问题修改后，重新进行测试并确认修改没有引入新错误，或者导致其他程序出现错误。
作为软件生命周期的一部分，回归测试在整个软件测试过程中占据着相当大的分量，在敏捷测试的每个阶段都要进行多次回归测试。
开发人员修改的局部问题时，可能已经处理了表面症状，所以主要测试其修改的页面和它的底层逻辑上。
但是也可能存在未触及到根本原因，所以还需要测试交互模块。Bug本身可能得到了修复，但修复也可能造成其他错误，所以有必要为每个修复的错误，设计回归测试。
关闭Bug有哪些注意事项最重要的，要看Bug的原因分析和解决方案是否正确，能否对应。
在原因和解决方案都看懂了的情况下开始进行回归验证。该问题在发现时是百分百的出现概率，那么按照操作步骤验证改好之后可以直接关闭。
该问题在发现时是int问题，那么最好要提高操作次数，回归20次（概率5%回归20次），再视操作结果关闭Bug。
有些开发解决Bug的习惯比较好，会附上回归建议，此时再额外按照建议回归下即可。如果在条件允许的情况下，最好跟开发人员沟通交流，讨论Bug的根因、修改方案及修改影响，结合开发人员的开发习惯，再结合测试人员自身的经验，梳理相关回归思路。这样基本就可以将Bug一网打尽。
下面我们看两个Bug回归的经典案例：
这个案例中，问题出现的原因是对该线索进行操作，签约状态的值传的不对，没有定义这个状态的值，导致线索状态没有变化。
我们在回归时，除了验证原Bug中操作的场景，还需要验证其他不同流程，保证线索的状态都是正确变化的，从而确认没有引入新的问题。比如：
1）线索由待跟进转换为跟进中，提交后状态显示正确；
2）线索由跟进中转换为已签约，提交后状态显示正确；
3）线索由已签约转换为已失效，提交后状态显示正确。
而这个Bug就相对比较简单，问题原因就是普通线索和商盟线索没有加商盟标志，导致和普通线索一样展示在了原来的区域，验证时除了按照原来步骤操作，还需要查看数据库中商盟的线索有这个值就代表改好了。
快速进行回归测试的最佳方法之一是使回归测试的简单场景转换成自动化用例。我们可以创建一系列回归测试脚本，并应在每次修改到这部分逻辑时对该脚本进行部分修改和审查，以确保其覆盖到修改的地方。
然后在手工执行回归测试时，这部分自动化脚本就可以帮我们测试其他常用的基础功能，保证修改不会引入严重问题，自动化测试脚本应涵盖所有可能的基础场景的测试用例。自动化回归测试将大大降低系统测试阶段、维护升级等阶段的人力和时间成本。
除了上述的关于回归测试的采取的必要手段，回归测试也可以借鉴平常测试的一些方法，比如交换测试，邀请别的小伙伴站在用户角度对该模块进行验证，也可以发现一些测试者自己发现不了的隐蔽问题。
学习资源分享最后感谢每一个认真阅读我文章的人，看着粉丝一路的上涨和关注，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走 
这些资料，对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！加入我们下方交流群就可以免费获取了，希望对大家有所帮助…….
