如何有效的选择回归测试用例？

今天看到51testing上有这个问题，觉得很值得探讨一下，就在此谈谈我的看法。51Testing软件测试网Ee j(b'AP

9n1ytp:~+PWz0关于这个问题，我粗粗的搜索以下网上的关于这个问题的说法，大都是空空理论之谈，实际操作起来并不一定适合。51Testing软件测试网S"CG'^5@

pX7MNm%J1TU#h2R0说到回归测试用例，先说什么是回归测试。顾名思义，回归测试就是修改完bug之后对程序的新的一轮测试，据微软的统计，按照他们的经验，一般开发人员解决3~4个bug会衍生出一个新的bug，这就是必须作回归测试的原因。简单的说，就是检测一下解决了bug之后有没有带进新的问题，以免把聋子给治成哑巴，就得不偿失了~~51Testing软件测试网C p5`+Du.c

)U#~.DQ"YF0一般的软件测试的流程是后期快速迭代的，bug在后期是快速收敛的，debug和测试的周期也是越来越短，频率是越来越高，譬如说第一轮测试需要花上10天跑用例，那么到后期就没那么长的时间，可能就是1~2天的测试时间，在后期有时候一天就有一个新的版本，这时候就要求测试人员能快速的进行一轮回归测试。51Testing软件测试网ku7kzDi%D

一般来说，覆盖越高，风险越低，但是效率就越差，反之亦然。所以如果时间允许的话，能把所有的用例都再跑一边是最好不过的，但是一般不会有那么多的时间，这就需要在效率和覆盖之间有一个适当的平衡，选择其中一部分测试用例用来作回归测试。51Testing软件测试网,G,jA'S5\e Mh4aq%J

'MeL7QJQ0选择回归测试的时候，首先要确定的是，回归测试用例的比例，这个要根据时间情况了，100%是最好了，我个人一般这个比例在60%左右。然后要确定回归测试用例的优先级。根据我的经验，一般有如下必须回归的用例：51Testing软件测试网eS'Y6WU|d h#r

)J*Ex)Gz'X0第一，新修改的功能，这个显然是重点

1C/~1AZ\8PkQ
V1RM0第二，新修改的功能的关联功能，就是有耦合的部分，这个一般最好咨询一下开发人员

'V|Z%D9|ymPJ l0第三，程序最有卖点或者说亮点的部分，这个地方一旦有问题，会使程序质量大打折扣

%kj4n%d [J7Y0第四，程序中最致命的部分，譬如说安全隐患，数据泄露，加密注册，51Testing软件测试网HQ.~W6]1z(|V1o:|

第五，程序中比较脆弱的部分，这个要咨询开发人员，一般就是他们心中最没底的地方51Testing软件测试网p6n3g vM3y;O#?Z]

.e#`i#R/B;{0第六，程序的主干功能

第七，如果以上做完，还有时间的话，最好把用例中级别比较高的用例再执行一遍。

OK ，以上是回归测试用例的选择优先级。51Testing软件测试网&t:vL
px"AO+f L

M7al;NIT`[0其实，即使这样做，还是有风险的。最根本的解决方法是自动化测试工具加上手工测试。具体就是常用的程序主干功能，主要功能，用自动化测试，保证每一个版本都能够执行一遍，其他修改频繁的小功能手工测试了。

说了这么多，好像比较乱，总结一下。51Testing软件测试网!G!{f:Y/JZT7LS:YW

个人觉得解决这个回归测试的终极解决方案是：51Testing软件测试网(U!LDW&\

,`"U6cBH} y'\0a.作每日构建

-DOiHW4A(w%c0b.基线功能自动化51Testing软件测试网u4CrO:jN0Y

H2Z'N+? y_*^0c.编写用例时一定要分级（按照风险度，常用度，重要度）

d.手工执行回归测试用例（就是我上面说的7项）

7K.X.R Vw*N(?cIumC0好了，这是我对这个问题的解决方案，欢迎大家补充，讨论，拍砖~~~~~~~~