如何做回归测试？

山风寂寂

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

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

周鱼

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

takiro

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

wsly

楼上说得不错.

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

周鱼

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

山风寂寂

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

calven

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.

takiro

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

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

Chenny

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

mlj_12

怎样自己编写测试脚本，楼上的教教我

Michael0112

1.范围：这是一个很模糊的概念，要视你的项目的成本控制，测试周期等因素来具体确定。
2.深度：你首先要理解回归测试的真正理念。回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入 新的错误或导致其他代码产生错误。
3.用例：了测试用例库的维护方法和回归测试包的选择策略，回归测试可遵循下述基本过程进行: 　　(1). 识别出软件中被修改的部分； 　(2). 从原基线测试用例库T中，排除所有不再适用的测试用例，确定那些对新的软件版本依然有效的测试用例，其结果是建立一个新的基线测试用例库T0。 　　(3). 依据一定的策略从T0中选择测试用例测试被修改的软件。 　　(4). 如果必要，生成新的测试用例集T1，用于测试T0无法充分测试的软件部分。 　　(5). 用T1执行修改后的软件。 　　第(2)和第(3)步测试验证修改是否破坏了现有的功能，第(4)和第(5)步测试验证 修改工作本身。

千里

回归测试一般来说有四种方法：
1.对缺陷进行回归，这是最简单的回归方式。
2.对涉及到有修改的模块进行重新测试。
3.对涉及到有修改的模块以及周边模块进行测试。
4.对全部功能模块进行测试。
这四种方法没有正确、错误之分，在不同时机采用不同策略而已。