如何提高回归测试的效率？

歇斯底里

在很多情况下，测试人员都是在做大量的回归测试（针对是手工功能测试），大量重复的工作有时候实在是让人觉得很厌烦，如何提高回归测试的效率，节省测试人员的时间，保证软件的质量变得犹为重要。开发代码的微小改动，就会引起很多意想不到的变化。各种情况都考虑到去测试基本上是不可能的。
是否有一个比较可行的方案。。或者说在开发流程上或者测试本身哪些方面可以改善这个情况呢？

月野幻儿

我也有此疑问．

JerryYe

回归测试种类：
1.        集成测试中在集成了某个新的功能模块后的回归测试
2.        系统测试中在修复了bug后的回归测试
回归测试策略：首先测试新增模块的功能是否准确，在此基础上
再测试新增模块对原有系统可能造成影响的部分的关联测试，时间允许的话再
对整个系统核心功能做一跑测。

猫猫的拖鞋

貌似这个问题很多公司都会遇到，想项目强壮点，但是又没有多少时间用来测试，往往开发到一定阶段就会出现大量的bug和隐藏的bug；
回归测试往往也只是测曾经遇到的bug，新增的功能+项目已经开发的功能，想要一个大体的测试又需要花很长的时间，但是测试的同时项目也在不断变化，一些细小的改动也许就能造成本来没有错误的功能报错，这时候，前面做的回归测试又不到位！
怎么办？
鱼和熊掌可以兼得？

歇斯底里

当然，对于修改比较大的模块可以针对性的进行回归测试，通跑以前的用例。
但是对于整个系统来说呢，特别是一个版本发布以后，要发布另外一个版本。那就不仅要对整个系统的核心进行回归，很多细节上也需要。。个人感觉花费的时间太大了。。
而且对于测试人员来说，大量重复工作肯定会有一些烦躁的情绪，很多功能上也往往会忽视，或许想不到的一些模块会出错。。

我觉得
1.开发在修改每一个问题或者bug后能告诉测试人员修改的重点十分必要。测试需要整理每天代码的变动情况。
2.测试要提高自己的工作效率，case的审核，更新，修改，case的等级划分也十分重要。必要的时候可以专门针对每一个业务流程进行case的设计。每次在保证这些case通过的情况下，再细分，看时间是否允许。

RYAN.D

对于这个问题, 我觉得有两种方案可以稍微提高一下回归测试的效率, 如下:

方案一: 适当引入自动化测试, 每当有新的版本产生时, 跑一次所有的自动化脚本, 保证每次的版本都可以通过基本的功能测试和某些bug的回归测试.
使用限制: 所在的测试团队需要有一定的自动化测试基础.

方案二: 在需求阶段建立需求点-功能点矩阵, 在测试设计阶段建立功能点-测试点矩阵和测试点-测试用例矩阵; 每次有新版本待测试时, 有开发经理或项目经理统一发送版本的改动情况(哪些功能点做了修改, 改成怎样), 然后测试经理可以根据这些信息找到改动影响到的范围(通过上述的几个矩阵进行查找), 从而将回归测试的范围缩小到一个适当的程度, 一定程度的较少了测试工作量.
使用限制: 上述的多个矩阵需要有专人来维护, 同时在任何时候这些矩阵都应该是能反映出需求的.
潜在风险: 可能会由于矩阵的不完整性而出现漏测情况.
新增的工作量: 开发经理和测试经理需要商讨出一个可执行的矩阵变更实施流程(矩阵的维护流程)

可能还存在其他更好的方案, 欢迎大家指点.

Thanks in advance.

WayneT

自动化 回归测试 可能是最常用的方法

msnshow

自动化也是需要代价的哦,有些项目中用不上自动化,如WEB应用!

toshiba

我现在就在测试一个产品，就是回归测试的···终于知道什么叫做回归测试了···

gezi_024

对5楼和6楼的观点，说说自己的看法。
1、自动化测试的引入的确可以减少，因测试人员重复工作而漏测问题的现象，这一点我比较赞同。
2、开发人员修改代码后，在问题单中标明因本问题的修改会影响到的功能点，这样测试人员在回归问题的时候会比较有针对性。潜在的风险，如果开发人员本身对软件需求理解不是很深入，会存在考虑不到，或者测试人员会依赖开发人员，过分信赖开发人员，也会存在问题。
3、需求跟踪矩阵，可能会有不少公司在用，虽然在理论上是比较好的，但具体没推向下去，维护比较麻烦。
4、交叉测试，如果时间允许一定要交叉测试，尽量减少问题。
5、宏观把握功能点的关联，对关联部门需分析透彻。

kuerzhao

同意楼上的观点，需要补充的是：
1 自动化测试的维护工作量太大，如果不是做产品的公司，感觉可行性不大
4 交叉测试非常的有用，尤其是新员工，能发现很多的潜在问题。

creatysun

我谈一下我的看法，目前自动化测试还没有推广起来，商业化的自动化测试工具价格不菲，测试脚本的开发代价也很大，自己开发测试框架就更难了，不是大多数公司能做到的，为了优化回归测试的效率，还是要从测试本身出发，从测试设计着手，要清楚所有测试用例对应覆盖的需求，在做过大量的测试分析后，会对各个模块及模块间的关联有比较清楚的认识，对用例划分重要程度，根据测试需要可以舍弃部分不重要的用例。另外，要对开发的变更管理好，要开发设计人员，对每次变更评估涉及范围，如果明确涉及的面比较小，就没必要全部回归了。

archonwang

如果是针对项目的，那么建议还是使用重要程度方法选定回归的范围。但是所有的资源肯定是非常有限的。如果缺乏这方面的专业人才，其投入和最终产出绝对是不合算的。

如果针对产品或是维护性项目，则必须设计回归的基本策略和框架。当然，需要资深的自动化回归方面的专家/设计师。这部分的前期投入非常大，但是一旦形成体系后，后续的工作将相对简单轻松。