回归测试流程
一、回归测试概念和目的
回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
在软件生命周期中的任何一个阶段，只要软件发生了改变，就可能给该软件带来问题。
软件的改变可能是源于发现了错误并做了修改，也有可能是因为在集成或维护阶段加入了新的模块。
当软件中所含错误被发现时，如果错误跟踪与管理系统不够完善，就可能会遗漏对这些错误的修改；而开发者对错误理解的不够透彻，也可能导致所做的修改只修正了错误的外在表现，而没有修复错误本身，从而造成修改失败；修改还有可能产生副作用从而导致软件未被修改的部分产生新的问题，使本来工作正常的功能产生错误。
同样，在有新代码加入软件的时候，除了新加入的代码中有可能含有错误外，新代码还有可能对原有的代码带来影响。
因此，每当软件发生变化时，我们就必须重新测试现有的功能，以便确定修改是否达到了预期的目的，检查修改是否损害了原有的正常功能。
同时，还需要补充新的测试用例来测试新的或被修改了的功能。
为了验证修改的正确性及其影响就需要进行回归测试。
回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。
在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。
因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是非常有意义的。
二、回归测试范围
在进行回归测试的时候，必须确定回归测试的范围，具体表现为：
1.测试所有修改或修正的功能模块
2.测试与被修改的模块相关的模块
3.测试所有新增加的功能模块
4.测试整个系统。
表现1,2,3中只是进行了部分的回归测试，这样的测试时不健全的，因为在软件系统中，对本地代码的修改可能对整个系统都产生副作用。
三、回归测试策略
有效、合理的回归测试策略对整个回归测试的最终成功是至关重要的，因此，为了有效地进行回归测试，需要为回归测试选择相应的策略。
(一)回归测试人员的选择
回归测试一般选择独立的测试人员来进行测试，比如，如果让程序员进行代码回归测试，程序员可能会因为自身开发的局限性陷入误区。
因此，在进行回归测试时，人员的选择是至关重要的。
(二)回归测试管理
回归测试的管理包括：
A.测试用例库管理和维护
随着软件的改变，软件的功能和应用接口以及软件的实现发生了演变，测试用例库中的一些测试用例可能会失去针对性和有效性，而另一些测试用例可能会变得过时，还有一些测试用例将完全不能运行。
为了保证测试用例库中测试用例的有效性，必须对测试用例库进行维护。
(1)、删除过时的测试用例
因为需求的改变等原因可能会使一个基线测试用例不再适合被测试系统，这些测试用例就会过时。
例如，某个变量的界限发生了改变，原来针对边界值的测试就无法完成对新边界测试。
所以，在软件的每次修改后都应进行相应的过时测试用例的删除。
(2)、改进不受控制的测试用例
随着软件项目的进展，测试用例库中的用例会不断增加，其中会出现一些对输入或运行状态十分敏感的测试用例。
这些测试不容易重复且结果难以控制，会影响回归测试的效率，需要进行改进，使其达到可重复和可控制的要求。
(3)、删除冗余的测试用例
如果存在两个或者更多个测试用例针对一组相同的输入和输出进行测试，那么这些测试用例是冗余的。
冗余测试用例的存在降低了回归测试的效率。
所以需要定期的整理测试用例库，并将冗余的用例删除掉。
(4)、增添新的测试用例
如果某个程序段、构件或关键的接口在现有的测试中没有被测试，那么应该开发新测试用例重新对其进行测试。
并将新开发的测试用例合并到基线测试包中。
通过对测试用例库的维护不仅改善了测试用例的可用性，而且也提高了测试库的可信性，同时还可以将一个基线测试用例库的效率和效用保持在一个较高的级别上。
B.测试执行的管理
C.计划跟踪管理
填写回归测试报告
(一)人员管理
四、回归测试方法
选择回归测试策略应该兼顾效率和有效性两个方面。
常用的选择回归测试的方式包括：
A.再测试全部用例
选择基线测试用例库中的全部测试用例组成回归测试包，这是一种比较安全的方法，再测试全部用例具有最低的遗漏回归错误的风险，但测试成本最高。
全部再测试几乎可以应用到任何情况下，基本上不需要进行分析和重新开发，但是，随着开发工作的进展，测试用例不断增多，重复原先所有的测试将带来很大的工作量，往往超出了我们的预算和进度。
B.基于风险选择测试
可以基于一定的风险标准来从基线测试用例库中选择回归测试包。
首先运行最重要的、关键的和可疑的测试，而跳过那些非关键的、优先级别低的或者高稳定的测试用例，这些用例即便可能测试到缺陷，这些缺陷的严重性也仅有三级或四级。
一般而言，测试从主要特征到次要特征。
C.基于操作剖面选择测试
如果基线测试用例库的测试用例是基于软件操作剖面开发的，测试用例的分布情况反映了系统的实际使用情况。
回归测试所使用的测试用例个数可以由测试预算确定，回归测试可以优先选择那些针对最重要或最频繁使用功能的测试用例，释放和缓解最高级别的风险，有助于尽早发现那些对可靠性有最大影响的故障。
这种方法可以在一个给定的预算下最有效的提高系统可靠性，但实施起来有一定的难度。
D.仅测试修改的部分
当测试者对修改的局部化有足够的信心时，可以通过相依性分析识别软件的修改情况并分析修改的影响，将回归测试局限于被改变的模块和它的接口上。
通常，一个回归错误一定涉及一个新的、修改的或删除的代码段。
在允许的条件下，回归测试尽可能覆盖受到影响的部分。
再测试全部用例的策略是最安全的策略，但已经运行过许多次的回归测试不太可能揭示新的错误，而且很多时候，由于时间、人员、设备和经费的原因，不允许选择再测试全部用例的回归测试策略，此时，可以选择适当的策略进行缩减的回归测试。
在回归测试时，常常采用多种测试技术，表现在以下两个方面：
1.测试者对一个修改的软件进行回归测试时，回归测试中可以采用多种回归测试方法，
例如回归测试工具，进而增加对修改软件的信心。
2.不同的回归测试者可能会根据自己的经验和判断选择的不同的回归测试技术和方
法。
各种回归测试方法比较如下表。
回归测试人员可以根据表全面地分析系统可靠性、
风险和项目成本，最终选择一种合适的回归测试方法。
五、有效的选择回归测试包
在测试过程中，会产生很多测试用例，形成庞大的测试用例库，这样，在进行回归测试时，如何选择合理、适用、有效的回归测试包是非常关键的。
在软件生命周期中，即使一个得到良好维护的测试用例库也可能变得相当大，这使每次回归测试都重新运行完整的测试包变得不切实际。
一个完全的回归测试包括每个基线测试用例，时间和成本约束可能阻碍运行这样一个测试，有时测试组不得不选择一个缩减的回归测试包来完成回归测试。
回归测试的价值在于它是一个能够检测到回归错误的受控实验。
当测试组选择缩减的回归测试时，有可能删除了将揭示回归错误的测试用例，消除了发现回归错误的机会。
然而，如果采用了代码相依性分析等安全的缩减技术，就可以决定哪些测试用例可以被删除而不会让回归测试的意图遭到破坏。
回归测试包选择策略如下
1.选择全部用例组成回归测试包，这是一种比较安全的方法，但随着开发工作的进推进，
测试用例不断增多，重复原先所有的测试将带来很大的工作量，往往超出了我们的预算和进度，使测试成本增加。
2.选择重要的、关键的和可疑的测试用例，跳过那些非关键的、优先级别低的和高稳定的
测试用例。
六、回归测试过程和执行
在实际工作中，回归测试需要反复进行，当测试者一次又一次地完成相同的测试时，这些回归测试将变得非常令人厌烦，而在大多数回归测试需要手工完成的时候尤其如此，因此，需要通过自动测试来实现重复的和一致的回归测试。
通过测试自动化可以提高回归测试效率。
从而2者并存。
人工回归测试流程
自动化测试流程
1.人工回归测试流程
a)由测试人员编写测试计划
b)由测试人员编写测试需求到QC
c)由测试人员编写测试用例到QC
d)由测试人员准备业务流数据
e)由测试人员执行测试
f)测试人员提交缺陷到QC
g)由测试人员验证待复测的模块
h)待修复模块完成后，由测试人员编写报告或者测试评估
i)测试人员提交报告给测试组长
2.自动化测试流程
a)由测试人员编写测试计划
b)由测试人员编写测试需求到QC
c)由测试人员编写和设计自动化测试框架和脚本
d)执行测试脚本并验证结果
e)由测试人员验证待复测的模块
f)待修复模块完成后，由测试人员编写报告或者测试评估
g)测试人员提交报告给测试组长
七、回归测试文档
1.回归测试开始前所需文档
●测试计划
●需要进行的测试列表
●回归测试用例
2.回归测试结束后递交文档
●回归测试报告
●回归测试记录。