什么是回归测试?
回归测试就是当开发人员对软件产品的基线版本做出任何改变时，测试人员针对这些改变进行的有针对性的测试活动。文章源自玩技e族-https://www.playezu.com/191861.html
以上所说的对软件产品做出的改变包括:文章源自玩技e族-https://www.playezu.com/191861.html
·开发人员为了修复一个软件缺陷而对软件产品进行的修改。文章源自玩技e族-https://www.playezu.com/191861.html
·开发人员在需求变更时，为满足新的需求而对软件产品做出的修改。·在稳定的软件产品中加入(集成）一个新的模块。文章源自玩技e族-https://www.playezu.com/191861.html
回归测试与软件产品的基线版本有着很大的联系，因为回归测试就是针对于软件产品的基线版本的改变所做的测试。文章源自玩技e族-https://www.playezu.com/191861.html
面试试题1文章源自玩技e族-https://www.playezu.com/191861.html
什么是软件的基线版本( baseline） ?文章源自玩技e族-https://www.playezu.com/191861.html
解答:文章源自玩技e族-https://www.playezu.com/191861.html
软件产品的基线版本就是软件在开发的过程中某一时刻的快照( snapshot)。在这一时刻的软件产品的版本一定是一个稳定的版本，一定可以作为继续在其上做开发的依据。文章源自玩技e族-https://www.playezu.com/191861.html
此后开发人员要继续开发就必须在基线版本中拉出一条分支( branch)。待新的功能开发完成并经过测试稳定之后，再经过项目管理人员、开发团队负责人、测试团队负责人、软件配置管理人员（SCM）检视通过之后形成新的基线版本。需要注意的是，新的基线版本同样必须是稳定的。文章源自玩技e族-https://www.playezu.com/191861.html
如果新的基线版本在后续的开发及测试中发现有不稳定的现象甚至是影响软件功能或项目进度的严重的设计缺陷或软件缺陷，则此时新的基线版本可能就会被抛弃。而产品将会会滚( rollback）到之前的那个稳定的基线版本。当然，这种现象不是经常发生的，也是项目相关人员最不愿意看到的。
基线版本的来源:有些软件项目是从零开始做起的，其软件产品通过逐步的集成会形成–个包含主要模块并且逐步趋于稳定的版本。当其版本足够稳定时，软件配置管理人员会将其编译为基线版本，并通知项目中的其他角色项目的基线版本已经产生。此后的开发都基于此版本。
有些软件项目是基于以前较成功的产品进行开发的，在这种情况下可以挑选以前产品中较稳定并兼具扩展性的版本作为新产品的基线版本。此后的开发都基于此版本。
面试试题2
为什么要做回归测试?
解答:
因为回归测试就是针对于软件产品的基线版本的改变所做的测试，因此通过对产品进行回归测试可以。
验证开发人员所承诺修复的软件缺陷是否已被正确修复。
验证新的软件修改是否影响了原有的稳定模块的正确性和稳定性。验证新的软件修改是否引入了新的缺陷。
·验证新的软件版本是否稳定，从而成为新的基线版本，以备后续开发使用。
面试试题3
什么时候开始做回归测试?
解答:
从回归测试的定义（回归测试就是当开发人员对软件产品的基线版本做出任何改变时，测试人员针对这些改变进行的有针对性的测试活动）可以看出，首先正在开发的软件产品必须形成了基线版本。当然，这个基线版本可以是某一个模块的基线版本（即产品的某一个模块的版本趋于稳定，此后在这个模块上的开发都基于该版本)，也可以是整个项目的基线版本。
另外，还必须要有对基线版本的修改。此时软件配置管理人员（SCM）会将修改后的代码编译成新的版本，然后分发给测试部门进行回归测试。
面试试题4
怎么做回归测试?
解答:
我们不难看出回归测试是贯穿于集成测试、系统测试和用户体验测试等测试阶段的一种测试行为。它的目的是为了评估在以上阶段中修复软件缺陷、引入新的模块等行为对整个基线版本的质量产生的影响以及新的修改自身的质量。
下面以系统测试阶段的回归测试活动为例来讲述怎么做回归测试。
正在开发的软件产品进入系统测试阶段之后，软件配置管理人员(SCM）就会为这个可以进行系统测试的版本打上系统测试阶段的基线版本标签（Label)，而系统测试部门就可以开展系统测试了。
此时测试人员按照事先开发完成的测试用例及测试脚本对此基线版本进行测试。测试人员发现疑似软件缺陷后对其进行复查并确认，如果是软件缺陷，就将其记录在缺陷跟踪管理系统中以备跟踪。这时测试人员、开发人员、项目管理人员和软件质量管理人员就会对缺陷的严重性和修复的优先级进行定级。在这一轮(cycle）的系统测试结束之后，以上人员将对在缺陷跟踪管理系统中的所有在这个基线版本上发现的缺陷进行讨论，以确定所有缺陷的修改进入到软件新版本的日程。
同时，需求人员、测试人员和开发人员等还有可能提出新的软件功能的需求。这些新的功能扩展的描述也将被记录在一个跟踪系统中(有时和缺陷跟踪管理系统是同一系统)。这时该需求将被需求人员、测试人员、开发人员、项目管理人员和软件质量管理人员进行讨论并评估其风险(该风险包括计划进度的风险及引入新功能对原有功能模块的影响)。如果讨论和评估通过,则开发人员就可以开始对新的功能进行开发。待新的功能模块经过测试并且稳定之后就可以在某个时刻集成入原有的软件系统中。
当以上两者情况的修改都确定要进入新的软件版本时，测试人员就需要对这些修改设计新的回归测试计划。
设计回归测试计划的策略。
·在设计新的回归测试计划时，可以将用于覆盖上一基线版本的所有测试用例加入到新的回归测试计划中。之后，还必须加入针对新功能模块开发的新测试用例。这种策略的优点是测试用例覆盖率最高，缺点是执行回归测试计划人员的工作量巨大。
·另一种策略是在新的回归测试计划中只包括对所有软件缺陷修复的验证及对新加入功能的系统级的验证。这种策略的优点是执行回归测试计划人员的工作量最小，缺点是测试用例覆盖率最低。
·最后一种策略是在新的回归测试计划中包括对所有因软件缺陷修复而产生的修改的覆盖。这就意味着除了验证软件缺陷的修复还必须评估这些修复对原有的稳定的模块的影响。
因此，还必须加入一些用于验证与被修复的缺陷有密切关系的模块稳定性的一些测试用例。这些测试用例可以是原有的测试用例，也可以是测试人员新开发的用例。同理,对于新加入的功能，除了验证其本身还要对可能被其影响到的模块进行再一次的验证。这种策略的优点是执行回归测试计划人员的工作量较小，测试用例覆盖率较高。缺点是新的回归测试计划的质量和测试覆盖率受开发该计划的人员的经验、能力的影响较大，此外开发新的回归测试计划所需的工作量也较大。
此后测试人员又回到了测试的执行阶段。待测试完成之后，测试负责人给出测试报告以反映软件的质量。当软件的质量还不够稳定时，就将进入下一轮的缺陷修复与回归测试。如果软件的质量趋于稳定时就可对其进行检视以确定软件是否符合系统测试的出口要求以进入软件测试的下一阶段。
我们不难看出对软件进行持续的回归测试是使软件质量趋于稳定的一个重要手段。在一轮又一轮的回归测试中软件的缺陷数量应该是一个逐渐收敛的趋势(在不加入新的功能并不引入大量新缺陷的情况下)。当缺陷数量或比例到达某一个预先设定的值时，我们就认为该软件的质量已经满足这一测试阶段的出口要求了。此时，有的公司还会对产品软件产品进行一次全回归测试（FullRegression Test)。只有当全回归测试计划中包括能够覆盖整个软件产品的所有测试用例时，这个全回归测试的测试报告才能被用来作为认定该软件的质量是否已经满足这一测试阶段的出口要求的依据。