回归测试详解（定义⽬的、策略以及什么叫做回归等）
⽬录
1. 定义&⽬的
回归测试(Regression Test)是指在软件项⽬中，开发⼈员在修改了软件的代码以修复已经发现的bug后，测试⼈员在需要重新测试前⾯已经测试过的内容，以确认此次修改没有引⼊新的错误。 也就是说，回归测试的⽬的就是检查开发⼈员在修复已有bug时是否⼜导致了新的bug。
在维基百科中，对于回归测试的定义原⽂是Regression testing is re-running functional and non-functional tests to ensure that previously developed and tested software still performs after a change. If not, that would be called a regression，按照这个定义，回归测试就是指的是重新运⾏以前的测试(功能性和⾮功能性)，以确保先前开发和测试的软件在修改后仍能够正常运⾏。⽽根据定义后⾯来看，回归(regression)指的则是⼀个导致软件不能正常运⾏的bug，也就是说造成软件退步或者说衰退(不如修改前)的⼀个bug就叫做⼀个回归bug，也叫做回归(regression)。之所以说回归测试叫衰退测试，也是因为regression的汉语意思是回归、退化、倒退的意思。
2. 触发回归测试的变化
按照上⾯所述，回归测试是指软件在发⽣某种变化后⽽引起的，根据维基百科所述，这种变化⼀般有以下⼏个：
1. 错误或者说bug修复(bug fixed)
2. 软件的增强(software enhancements)： ⽐如软件增加/删除/优化了功能等等
3. 配置的更改(configuration changes)
4. 电⼦元件的替代(substitution of electronic components)
不过，在原⽂描述中，电⼦元件的替代只是有可能会引起回归测试的发⽣，具体是否需要进⾏回归测试还要看具体的情况，原⽂为“include … and even substitution of electronic components”。
3. 回归测试的策略
从回归测试的定义可以看出，软件在其⽣命周期的任何⼀个阶段，只要发⽣了上述的⼏种类型的变化，就有可能会引⼊新的问题，为了减少这类新出现的问题，我们引⼊了回归测试。显⽽易见的是，随着软件的开发和迭代，以前测过的测试⽤例也会越来越多，也就是说回归测试的⼈⼒和时间成本会越来越⼤，⽽现在对于⼯作的效率和有效性要求都⽐较⾼。在这种情况下，我们就需要有针对性的进⾏回归测试，也就是说有策略的进⾏回归测试。
中垂线怎么画回归测试的策略集中体现在对于回归测试的测试⽤例的选择上⾯，⼀般来讲，总体分为两⼤类，⼀种是完全回归，⼀种是部分回归，⽽部分回归⼜分为⼏种具体的回归⽅法，完全回归和部分回归的定义如下：
1. 完全回归(Retest all)： 完全回归是指测试时选择基线测试⽤例库中的所有⽤例进⾏回归测试，这是⼀种最为保险的策略，相对于部分
回归策略，其可以将遗漏回归bug(regression bug)的概率降到最低，但这种⽅式同时也是所有策略中成本最⾼的⼀种⽅式，尤其是越往后，随着测试⽤例的不断增多，最后完全回归所需要的时间和成本往往超出了预算。
2. 部分回归： 部分回归是指在回归测试时选择基线测试⽤例库中的⼀部分⽤例进⾏回归测试，⽽不是所有⽤例全部执⾏，相对于完全回
归测试，这种测试策略效率很⾼，并且所需要的时间和成本⽐较少，但也没有完全回归覆盖率⾼(或者说遗漏回归bug的概率⽐完全测试⾼)。
根据部分回归的定义，部分回归需要选择⼀部分测试⽤例来进⾏回归测试，那么⾃然就要有具体的选择⽅法，也就是说如何选择出这⼀部分的测试⽤例来执⾏回归测试，⼀般来讲，在部分回归测试时，选择测试⽤例的⽅法分为以下⼏种：
1. 基于风险选择测试⽤例： 这种⽅法是指按照⼀定的风险标准从基线测试⽤例库中选择回归测试⽤例(回归测试包)。⾸先运⾏最重要
一家手机店的、关键的和可疑的测试⽤例，⽽跳过那些⾮关键的、优先级别低的或者稳定性⾼的测试⽤例，因为这些⽤例即便可能测试到缺陷，这些缺陷的严重性也仅有三级或四级。⼀般⽽⾔，测试从主要特征到次要特征。
2. 基于操作剖⾯选择测试⽤例： 如果基线测试⽤例库的测试⽤例是基于软件操作剖⾯开发的，那么测试⽤例的分布情况就反映了系统的
实际使⽤情况。回归测试的测试⽤例个数可以由测试预算确定，回归测试可以优先选择那些针对最重要或最频繁使⽤功能的测试⽤例，释放和缓解最⾼级别的风险，有助于尽早发现那些对可靠性有最⼤影响的故障。这种⽅法可以在⼀个给定的预算下最有效的提⾼系统可靠性，但实施起来有⼀定的难度。
3. 针对修改的部分选择测试⽤例(再测试修改的部分)： 当测试者对修改的局部化有⾜够的信息时，可以通过相依性分析分析识别软件的
无花果口感修改情况并分析修改的影响，将回归测试集中在被改变的模块和它的接⼝上。通常，⼀个回归错误⼀定涉及⼀个新的、修改的或删除的代码段。在允许的条件下，回归测试尽可能覆盖受到影响的部分。
附： 软件操作剖⾯是软件质量管理之中的概念，其包含了各种操作的集合以及每种操作出现的概率，其是对软件使⽤⽅式的数值描述，也可以理解为各种使⽤⽅式的概率。
4. 测试⽤例库
在实际的软件项⽬中，项⽬组会将测试编写的测试⽤例放在⼀起，形成⼀个测试⽤例库(测试⽤例库中包含的是不仅仅是功能测试的测试⽤例，也有其他类型测试的测试⽤例，⽐如⾃动化测试脚本⽤例)，并且会不断的对其进⾏维护和管理。每当得到⼀个软件的基线版本(软件的基线版本是指软件⽂档或源码以及其它产出物的⼀个稳定版本，它是进⼀步开发的基础)时，⽤于基线版本测试的所有测试⽤例就构成了⼀个基线测试⽤例库。在进⾏回归测试的时候，就可以根据回归测试中测试⽤例的选择策略，从基线测试⽤例库中提取合适的测试⽤例组成回归测试的⽤例包，通过运⾏回归测试的⽤例包来实现回归测试。
上⾯说过需要对测试⽤例库进⾏维护，有关测试⽤例库的维护详述如下。
>测试⽤例库的维护
为了最⼤限度地满⾜客户的需要和适应应⽤的要求，软件在其⽣命周期中会频繁地被修改和不断推出新的版本，修改后的或者新版本的软件会添加⼀些新的功能或者在软件功能上产⽣某些变化。随着软
件的改变，软件的功能和应⽤接⼝以及软件的实现发⽣了演变，导致测试⽤例库中的⼀些测试⽤例可能会失去针对性和有效性，⽽另⼀些测试⽤例可能会变得过时，还有⼀些测试⽤例将完全不能运⾏。为了保证测试⽤例库中测试⽤例的有效性，必须对测试⽤例库进⾏维护。同时，对于被修改的或新增添的软件功能，仅仅靠重新运⾏以前的测试⽤例并不⾜以揭⽰其中的问题，所以还要追加新的测试⽤例来测试这些新的功能或特征。因此，测试⽤例库的维护⼯作还应包括开发新测试⽤例，这些新的测试⽤例⽤来测试软件的新特征或者覆盖现有测试⽤例⽆法覆盖的软件功能或特征。测试⽤例的维护是⼀个不间断的过程，通常可以将软件开发的基线作为基准，维护的主要内容包括下述⼏个⽅⾯：
1. 删除过时的测试⽤例： 因为需求的改变等原因可能会使⼀个基线测试⽤例不再适合测试被测试系统，这些测试⽤例就会过时。例如，
某个变量的界限发⽣了改变，原来针对边界值的测试就⽆法完成对新边界测试。所以，在软件每次修改后都应将过时的测试⽤例从测试⽤例库中删除。
2. 改进不受控制的测试⽤例： 随着软件项⽬的进展，测试⽤例库中的⽤例会不断增加，其中会出现⼀些对输⼊或运⾏状态⼗分敏感的测
手掌脱皮是怎么回事试⽤例。这些测试不容易重复且结果难以控制，会影响回归测试的效率，需要进⾏改进，使其达到可重复和可控制的要求。
3. 删除冗余的测试⽤例： 如果存在两个或者更多个测试⽤例针对⼀组相同的输⼊和输出进⾏测试，那么这些测试⽤例是冗余的。冗余测
试⽤例的存在降低了回归测试的效率。所以需要定期的整理测试⽤例库，将冗余的⽤例删除掉。
4. 增添新的测试⽤例： 如果某个程序段、构件或关键的接⼝在现有的测试中没有被测试，那么应该开发新测试⽤例重新对其进⾏测试。
并将新开发的测试⽤例合并到基线测试包中。
维护测试⽤例的库的好处在于不仅改善了测试⽤例的可⽤性，⽽且也提⾼了测试库的可信性，同时还可以将⼀个基线测试⽤例库的效率和效⽤保持在⼀个较⾼的级别上。
>回归测试包的选择
在软件⽣命周期中，即使⼀个得到良好维护的测试⽤例库也可能变得相当⼤，这使每次回归测试都重新运⾏完整的测试包变得不切实际。⼀个完全的回归测试包括每个基线测试⽤例，时间和成本约束可能阻碍运⾏这样⼀个测试，这时就不得不选择⼀个缩减的回归测试包来完成回归测试。回归测试的价值在于它是⼀个能够检测到回归错误的受控实验。当选择缩减的回归测试包时，有可能删除了将揭⽰回归错误的测试⽤例，消除了发现回归错误的机会。不过，如果采⽤了代码相依性分析等安全的缩减
技术，就可以决定哪些测试⽤例可以被删除⽽不会让回归测试的意图遭到破坏。
5. 回归测试的测试过程
好家风作文在有了测试⽤例库的维护⽅法和回归测试包的选择策略的基础上，回归测试的过程⼤致可以分为如下的⼏步：
1. 识别出软件被修改的部分；
2. 从原基线测试⽤例库中剔除掉所有不再适⽤的测试⽤例，保留对新版本的软件依然有效的测试⽤例，然后形成⼀个新的基线测试⽤例
库；
3. 从形成的新的基线测试⽤例库中依据选择测试⽤例的策略选择测试⽤例来执⾏测试；
八一短信4. 如果需要，还可以形成新的测试⽤例集，以测试上⼀步选择的测试⽤例集⽆法覆盖或者⽆法充分覆盖到的软件部分；
5. 执⾏上⾯新形成的测试⽤例集。
2元人民币在上⾯的步骤中，其中第2步和第3步是验证软件的修改是否造成了软件的衰退(或者说破坏了软件现有的功能)，⽽第4步和第5步则是验证修改⼯作本⾝了。
6. 回归测试的优缺点及其⽤途(Benefits、drawbacks and us)
1. 优点： 可以确定当对软件的现有功能进⾏更改后，此次的更改没有影响软件现有的功能，这些功能是不变的。
2. 缺点： 在敏捷软件开发中，软件开发⽣命周期⾮常短，资源稀缺，对软件的更改⾮常频繁-回归测试可能会带来⼤量不必要的开销。
在⼀个倾向于使⽤来⾃第三⽅的⿊匣⼦组件的软件开发环境中，执⾏回归测试可能是很困难的，因为第三⽅组件的任何更改都可能⼲扰系统的其余部分(并且对第三⽅组件执⾏回归测试是困难的，因为它是⼀个未知的实体)。
3. ⽤途： 回归测试不仅可⽤于测试程序的正确性，还可⽤于跟踪其输出的质量。例如，在编译器的设计中，回归测试可以跟踪代码⼤⼩
以及编译和执⾏测试套件所需的时间案例。理论上，每次修复后，必须运⾏之前针对系统运⾏的整个测试⽤例，以确保系统没有以模糊的⽅式损坏。在实践中，回归测试也必须以这个理论思想为指导来
进⾏。
7. 回归测试在测试中的实践
好书排行榜
根据第6部分中关于回归测试⽤途的描述，可以知道在实际⼯作中，回归测试需要反复的执⾏(软件发⽣改变就需要执⾏)，⽽当测试⼈员不断的去执⾏这些重复的测试⽤例时，不仅会让⼈⼼⽣厌烦，⽽且随着时间的推移，需要执⾏的测试⽤例的数量也越来越多，导致整个回归测试的效率降低。因此，在回归测试时，需要通过测试⾃动化的思想，运⽤⾃动化测试⼯具来提⾼回归测试的效率。 ⽽对于测试的⼯具的要求就是其要⾜够灵活和具有⼀定的通⽤性，以便满⾜不同回归测试⽬标的要求。
在实际对软件进⾏回归测试时，应⽤多种测试技术是常见的，并且在回归测试时选择多种回归测试策略也可以增加⼈们对修改软件的信⼼。⽽且需要注意的是，回归测试并不会减少对系统新功能和特征的测试需求，并且回归测试包应包括软件新功能和特征的测试，如果回归测试⽤例包不能达到要求的覆盖率，则必须从以前的⽤例中再选取新的测试⽤例来补充回归测试⽤例包，使其达到要求的覆盖率。
还有⼀点就是回归测试是重复性较多的活动，容易使测试⼈员感到疲劳和厌倦，降低测试效率，在实际⼯作中可以采⽤⼀些策略减轻这些问题。例如，安排新的测试⼈员完成⼿⼯回归测试，分配更有经验的测试⼈员开发新的测试⽤例，编写和调试⾃动测试脚本，做⼀些探索性的或ad-hoc测试(ad- hoc
测试就是为了某个特定⽬的进⾏的测试，以后不会再执⾏这个测试了)。还可以在不影响测试⽬标的情况下，⿎励测试⼈员创造性地执⾏测试⽤例，变化的输⼊、按键和配置能够有助于激励测试⼈员和揭⽰新的错误。
最后，组织回归测试时要注意两点，⼀个是各测试阶段发⽣的修改⼀定要在本测试阶段内完成回归，以免将错误遗留到下⼀测试阶段。另⼀个是回归测试期间应对该软件版本冻结，将回归测试发现的问题集中修改，集中回归。 在实际的⼯作中，可以将回归测试和兼容性测试放在⼀起结合起来进⾏，在新的配置条件下运⾏旧的测试可以发现兼容性问题，⽽同时也可以揭⽰编码在回归⽅⾯的错误。
参考资料：
《regression test》
