如何选择自动化测试用例进行回归测试？

tiantian010

用自动化进行回归测试，往往是在系统相对稳定的时候进行的，它是为了确保新的功能和版本完成之后，已有的功能没有收到影响的测试实现。在目前的企业当中，自动化测试的用例往往是在已有的测试用例（用于manual的）选择出来了。
那么我们用例选择策略和原则是怎样的呢？占的比重是多少呢？

Jackc

其实很多测试问题都是纠结在如果控制测试的粒度上。

在回归测试的粒度上，策略取决于资源的多寡。虽然你们使用的自动化工具，但是脚本的多寡直接影响维护成本，所以，只能根据实际测试团队的承受能力来决定回归测试的用例数。

至于比重系数，这个数据就更难说了，比如相同的模块，不同的测试团队的测试用例总数不同（分母就不同了），而不同的研发团队周期不同，决定了回归测试的时间不同，测试团队的人数不同，决定了单位时间内单个团队完成的任务量不同（总之，就是分子不同）；那么，比重系数自然也不具备参考价值了。

如果LZ只是希望得到一个实际数据，我手里有一个NOKIA的数据，可惜使用的是手工黑盒：

功能模块简述：基于3.5G的GPRS的流媒体传输

测试团队：3人

黑盒功能测试用例：3000+（这个数据只是最新平台的数据，由于最新平台移植这个功能的时候，功能已经很稳定了，所以阿尔法测试用例比以前少了很多。）

回归测试（贝塔测试）用例：250+（一共分为4个部分，每个部分60~70个用例，按照版本发布的顺序逐次乱换。）

版本释放周期：每周

8596991

一般的公司，测试人员并不太多，自动化测试，能够占到15%左右的比重，已经非常不错了。当然，外企的自动化测试会多一些。
你选择的测试用例，肯定不是盲目的，一是在目前的技术水平下，能够很快的写出来自动化测试脚本；二是和研发部沟通，对变化少的模块进行自动化测试；三，对手工测试很难把握覆盖率与稳定的模块进行自动化。
当然，具体的策略，还是得看测试周期以及测试人员的水平

havards

有可能的话，使用Visual Studio,全搞定

tiantian010

以上说的都在理儿,在实际的项目中,我们在系统初期要设计成百上千个用例,此时系统的bug曾出不穷,当随着系统版本的稳定,我们测试的测试用例也在慢慢变少,但是有一点是明确的,那些主要功能流程和核心业务流程的用例在回归测试的时候每个版本是都要跑到的,这是站在用户的角度考虑问题.但是我想应该还有一些其他的用例选择标准,也许这些标准不是成文规则,也许只是自己部门使用的规则,可以拿出来共享和讨论,至于比重嘛,大家觉的5%-10%是不是可以呢?在保证兼顾核心业务覆盖和变更影响模块覆盖的要求下?

Jackc

赞成，特别是在产品研发后期，可以将回归测试与自由随机测试结合在一起，为产品的整体提供一些额外的质量评估数据。

楠族开心果

对的，后期还是要手工测试的