随着需求一点点增加，功能点象滚雪球一样越来越多，这时候大家都是如何做回归测试的呢？对此，我有几点疑问：
1、回归测试的范围？
2、回归测试的深度？
3、回归测试的测试用例？

我说说我现在做的项目这方面的情况，目前我们没有特别明确的回归测试策略和方法
1、所有的功能块都要做回归测试，无论该功能块是否有改动。
2、由于回归测试时间分配很少，基本上就是主要逻辑跑一遍，保证大概功能无误。
3、没有专门的回归测试用例，用的测试用例是功能测试时设计的，比较详细，不是很适用，以致实际测试常脱离测试用例，更多凭个人经验。
我很怀疑这种做法的科学性，是否就是广种薄收的例子呢？各位在确定回归测试的广度和深度方面有什么经验？希望能听到经过实践的切实可行的建议。感谢！

不科学，但也没辙，没时间

如果你们公司有条件可以考虑使用自动化测试工具引入到回归测试中来，不过这点对测试用例的要求比较高，而且数据要能比较好地覆盖用例及业务流程
但往往许多公司很难做到这点 即使做了也难得做好。
一般对于重点模块和逻辑要关注（80-20原则），如果某一功能点或模块变动的话，做回归测试至少要保证覆盖的是与该模块或功能点（逻辑点）直接有关联的部分。

楼上说得不错.

建议使用 自动化工具 来保证回归测试, 如果你们公司有条件(人力,资源)上的话.

给我一个支点，我可以翘起地球，条件就是这么回事，如果有条件的话世界上就没有任何问题了，就是因为条件有限才有问题啊，大家还是出点实际一些的主意，难道测试人都是这么喜欢沉浸在幻想之中么？

因为还不是最终产品，变动很大，还不到做自动测试的时机。
在这里提出来，是想有没有好的实践办法，而不是仅仅凭一两个人的经验，或者比较盲目地做回归测试。

Regression work itself is a boring task, why do you want to make it more easy...you just do that, before you have any good idea, maybe automation is a good resolution, and it is not so hard.

其实楼主的几个问题都是大家比较头疼的，关键是配置管理和质量保证没有跟上，导致需求，功能以及版本总是变更，对于这类的问题，并没有一个完全的解决方案，之前我说的那些点也只是我平时工作中所积累的，因为时间紧，如果项目大，肯定只能对于经常出现问题或是业务流，功能流上的要点进行回归测试，或者是相互关联的几个变更功能点来进行测试，如果测试需求分析得完全，测试用例复用性比较好，直接能转化为自动化测试script，引入到自动化测试中来，这也是回归测试的几个基本思路和方法。
  对于楼主最后说的无法将功能用例用在回归测试中的问题，我个人觉得是在设计时未对测试数据和测试过程分离的原因，导致用例复用性不高，如果在后期遇到这样的问题，想要提高效率，要么就用机器代替手工，要么就选择性得执行测试用例。
   最后要说一点的是：现在国内的测试也只是处与起步阶段，大家对于测试都是自己在摸索，并没有所谓的高手，既然来讨论，无论好的坏的也都是为了解决问题，大家也只能给发帖的人一些个人建议，最终还是要靠自己结合实际情况来进行选择或是考虑，所以各位请不吝扔砖头。

[[i] Last edited by takiro on 2005-7-11 at 13:13 [/i]]

首先得你的软件初具规模了再来回归，不然烦死你，稍稍改动就又要测试了
其次，可以重复利用以前的测试用例以防止引入新的错误
还有，就是根据添加的功能添加必要的新的测试用例
自己编写好的测试脚本实现自动测试是好方法（如批处理、Perl）