bug的生命周期是从创建到关闭，bug能否关闭取决于回归测试的结果。很多测试人员可能对bug敏感度要求很高，但是回归测试的控制或者质量控制的程度就比较模糊了。回归测试的范围和回归测试的发展是本文的重点。BugRegression的重要性回归测试是软件测试中不可忽视的一部分。回归测试就是修改问题后重新测试，确认修改没有引入新的错误或者导致其他程序出错。回归测试作为软件生命周期的一部分，在整个软件测试过程中占有相当大的比重，在敏捷测试的每个阶段都会进行多次回归测试。开发者在修改局部问题时，可能已经治标不治本，所以主要是测试修改后的页面及其底层逻辑。但也可能有根本原因没有触及，所以还需要测试交互模块。bug本身可能被修复了，但是修复也可能导致其他的bug，所以需要针对每一个被修复的bug设计回归测试。关闭bug有哪些注意事项？最重要的是看bug的原因分析和解决方案是否正确，是否可以解决。了解原因和解决方案后，开始回归验证。该问题在发现时有100%的概率出现，所以按照操作步骤验证修正后直接关闭即可。这个问题发现的时候是int问题，所以最好增加操作次数，返回20次（probability<5%返回30次，probability>5%返回20次），然后根据情况关闭bug运算结果。有些开发者解决bug的习惯比较好，会附上回归建议。这时，他们可以根据建议返回。如果条件允许，最好与开发人员进行沟通，讨论bug的根源、修改方案以及修改的影响。结合开发人员的开发习惯和测试人员自身的经验，整理出相关的回归思路。这样，基本上就可以把bug消灭了。我们来看两个典型的bug回归案例：本案例中，问题的发生是因为操作了线程，错误的传递了contractstatus的值，而没有定义这个state的值，导致没有变化线程状态。返回时，除了验证原bug中的运行场景外，还需要验证其他不同的流程，确保线程的状态变化正确，从而确认没有引入新的问题。例如：线程由等待跟进改为跟进，提交后状态显示正确；跟帖由跟帖转为签约，提交后状态显示正确；lead由contracted转为expired，提交后状态显示正确。但是这个bug比较简单。出现问题的原因是普通线索和商盟线索没有商盟标识，导致它们和普通线索一样显示在原区域。除了按照原来的步骤进行验证外，还需要查看数据库中的商业联盟。如果线索有这个值，就说明它已经被改变了。如何提高回归测试的效率快速进行回归测试的最佳方法之一是将回归测试的简单场景转换为自动化用例。我们可以创建一系列的回归测试脚本，每次修改这部分逻辑时，都要对脚本进行局部修改和审核，确保覆盖修改的地方。那么在手动进行回归测试的时候，这部分自动化脚本可以帮助我们测试其他常用的基础功能，保证修改不会引入严重的问题。自动化测试脚本应涵盖所有可能的基本场景的测试用例。自动化回归测试将大大减少系统测试阶段、维护升级阶段的人力和时间成本。回归测试除了上面提到的回归测试的必要手段外，回归测试还可以借鉴一些正常测试的方法，比如交流测试，邀请其他小伙伴站在用户的角度对模块进行验证，有的测试人员也可以找自己出来不能隐藏问题。
