回归测试的策略
（1） 可以选择完全重复测试。把所有的测试用例，全部再完全的执行一边，以确认问题修改的正确性和修改后周边是否受到影响。
缺点：由于要把用例全部执行，所以会增加项目成本，也会影响项目进度。所以很难来完全执行，所以引出了回归测试策略
（2） 可以选择性重复测试。可以选择一部分进行执行，以确认问题修改的正确性和修改后周边是否受到影响。
那么我们怎样去选择用例呢？这里有三个方法：
（1）覆盖修改法，针对发生错误的模块，选取这个模块的全部用例进行测试。这样只能验证本模块是否还存在缺陷，但不能保证周边与它有联系的模块不会因为这次改动而引发缺陷。
（2）周边影响法，除了把出错模块的用例执行之外，把周边和它有联系的模块的用例也执行一遍，保证回归测试的质量。当然我们还可以用量化的角度去分析模块的质量，比如：经过上面的一系列回归测试后，看看遗留的缺陷率是否已经在允许的范围之内了，那么我们以此为标准可以结束本次回归测试。
（3）指标达成法，在测试全部完成后，看看我们有没有达到既定的指标。
3.回归测试的流程
1．在测试策略制定阶段，制定回归测试策略
2．确定回归测试版本
3．回归测试版本发布，按照回归测试策略执行回归测试
4．回归测试通过，关闭缺陷跟踪单
5．回归测试不通过，缺陷单返回开发人员．等重新修改，再次做回归测试．
每当一个新的模块被当作集成测试的一部分加进来的时候，软件就发生了改变。新的数据流路径建立起来，新的I/O 操作可能也会出现，还有可能激活了新的控制逻辑。这些改变可能会使原本工作得很正常的功能产生错误。在集成测试策略的环境中，回归测试是对某些已经进行过的测试的某些子集再重新进行一遍，以保证上述改变不会传播无法预料的副作用。
在更广的环境里，（任何种类的）成功测试结果都是发现错误，而错误是要被修改的，每当软件被修改的时候，软件配置的某些方面（程序、文档、或者数据）也被修改了，回归测试就是用来保证（由于测试或者其他原因的）改动不会带来不可预料的行为或者另外的错误。
回归测试可以通过重新执行所有的测试用例的一个子集人工地进行，也可以使用自动化的捕获回放工具来进行。捕获回放工具使得软件工程师能够捕获到测试用例，然后就可以进行回放和比较。回归测试集（要进行的测试的子集）包括三种不同类型的测试用例：
* 能够测试软件的所有功能的代表性测试用例。
* 专门针对可能会被修改影响的软件功能的附加测试。
* 针对修改过的软件成分的测试。
在集成测试进行的过程中，回归测试可能会变得非常庞大。因此，回归测试应当设计为只对出现错误的模块的主要功能进行测试，每当进行一个修改时，就对每一个程序功能都重新执行所有的测试是不实际的而且效率很低的。
4.最后，我想说的
其实，之前从来没有做过类似的作业，把自己每周学到的东西写成技术博客分享到这上面来。其实一开始真的觉得很无聊，也觉得没什么大用处，但后来我的想法完全改变了。这种方法不仅可以督促我们的学习进度，帮助我们学到更多的关于软件测试的内容，还可以帮助同学们和网友们互相交流经验分享日常学习到的知识。有不会的问题只要在找找看里搜索关键字就可以看到很多相关专业的朋友们分享的知识，这令我觉得受益良多。
下一届的学弟学妹们~~等你们做这个作业的时候欢迎来这里交流经验哟~那么~先拜拜啦~