如何提高回归测试效率，你知道么？

测试积点老人

一个Bug的生命周期是从创建开始到关闭结束，而Bug能否关闭就取决于回归测试的结果，测试人员可能很多都对Bug灵敏度有较高要求，但是对于回归测试的把控或质量掌握的程度却比较模糊。而关于回归测试的范围、回归测试的开展正是本文讨论的重点。

　Bug回归的重要性
　　回归测试是软件测试中不可忽视的一部分，回归测试是对问题修改后，重新进行测试并确认修改没有引入新错误，或者导致其他程序出现错误。
　　作为软件生命周期的一部分，回归测试在整个软件测试过程中占据着相当大的分量，在敏捷测试的每个阶段都要进行多次回归测试。
　　开发人员修改的局部问题时，可能已经处理了表面症状，所以主要测试其修改的页面和它的底层逻辑上。
　　但是也可能存在未触及到根本原因，所以还需要测试交互模块。Bug本身可能得到了修复，但修复也可能造成其他错误，所以有必要为每个修复的错误，设计回归测试。


这个案例中，问题出现的原因是对该线索进行操作，签约状态的值传的不对，没有定义这个状态的值，导致线索状态没有变化。
　　我们在回归时，除了验证原Bug中操作的场景，还需要验证其他不同流程，保证线索的状态都是正确变化的，从而确认没有引入新的问题。比如：
　　1）线索由待跟进转换为跟进中，提交后状态显示正确；
　　2）线索由跟进中转换为已签约，提交后状态显示正确；
　　3）线索由已签约转换为已失效，提交后状态显示正确。


而这个Bug就相对比较简单，问题原因就是普通线索和商盟线索没有加商盟标志，导致和普通线索一样展示在了原来的区域，验证时除了按照原来步骤操作，还需要查看数据库中商盟的线索有这个值就代表改好了。


　　如何提高回归测试的效率
　　快速进行回归测试的最佳方法之一是使回归测试的简单场景转换成自动化用例。我们可以创建一系列回归测试脚本，并应在每次修改到这部分逻辑时对该脚本进行部分修改和审查，以确保其覆盖到修改的地方。
　　然后在手工执行回归测试时，这部分自动化脚本就可以帮我们测试其他常用的基础功能，保证修改不会引入严重问题，自动化测试脚本应涵盖所有可能的基础场景的测试用例。自动化回归测试将大大降低系统测试阶段、维护升级等阶段的人力和时间成本。
　　除了上述的关于回归测试的采取的必要手段，回归测试也可以借鉴平常测试的一些方法，比如交换测试，邀请别的小伙伴站在用户角度对该模块进行验证，也可以发现一些测试者自己发现不了的隐蔽问题。