回归测试需要注意什么因素，怎么设计回归测试用例？
回归测试需要注意什么因素，怎么设计回归测试用例？ 回归测试时，用例还要单设计？
[解决办法]
“回归测试用例”，其实准确说来应该是“回归测试范围”或者“回归测试用例集”，虽然理论上每次回归都应该完全回归之前的所有测试用例，但是工作量巨大，所以在实际工作中可以进行选择性（非全部用例）的进行回归。如评估变化对软件的影响范围，进而限定回归时所使用哪些测试用例，这个“用例集”就经常被人们说为“回归测试用例”
但是正如楼上所说，本身并不会针对回归测试设计单独（全新）的测试用例。所以不是如何设计回归测试用例，而是如何选择回归测试时使用的测试用例集。
最后，我们其实可以把回归测试，看成其它行业的日常维护检查，北京2012暴雨过后，应该如何测试一下房屋的安全问题啊，这就需要策略（回归的范围选择问题）。
[解决办法]
辛苦写那么多，竟然没有回复成功，这次简说吧
回归测试理论上应该在变化后（程序自身改变，环境改变，操作方式改变等都是改变）执行先前的所有测试用例，这就是回归。但是由于工作量巨大，所以人们经常采用的方式是变化后选择性（也就是非全部）的执行先前的测试用例。这个选定的测试用例集，就是人们常说的“回归测试用例”，所以准确来说，应该称之为“某回归测试所使用的测试用例集”
既然这样，就如楼上所说，没有“回归测试用例”，不会设计单独（全新）的测试用例，而是策略的选择之前用例的部分（或全部）集合。
理解回归测试完全可以类比其它行业的日常检查，如体检，全部检查项目很多，但是根据变化（如自身年龄增长，工作环境从科室改到了井下作业），就应该选择不同的体检项目，这就是回归测试。
[解决办法]
一般回归测试都是使用第一次功能测试的用例进行执行的；
但也不是非得所有用例都执行，要看情况：
1、如果系统目前为止已经比较稳定，那回归测试的用例，可以根据8/2原则来挑选（80%的缺陷出现在20%的功能模块中），可以根据各模块缺陷的情况，将出现问题较多的模块进行执行用例；其他缺陷不多的模块，可以将缺陷相应的功能点进行用例执行；
2、业务程度较复杂的，用户使用较频繁的功能模块进行回归测试；
3、开发近期对某个功能模块进行了小功能的修改时，也需要进行回归测试，因为开发进行功能点修改或者优化时，不怕一万就怕万一，所以进行回归测试，保守一点。
个人觉得回归测试没有必要重新设计用例，因为进行回归测试的时候，一般都是项目后半期，或者某一个阶段的后期，这时候重新设计用例，势必会影响成本，建议挑选用例，结合之前对项目的熟悉度，进行测试，我想效率肯定不会很低。
