回归测试时用例的选择

在软件开发过程当中，一旦软件代码做了修改，就有可能引入新的问题，所以这个时候就需要把已经完成了的验证用例重新跑一下，以确保代码的修改没有对已经验证过的功能造成影响。我们把这一个过程叫做回归测试。
一般的软件测试流程是后期快速迭代的，bug在后期是快速收敛的，debug和测试的周期也是越来越短，频率是越来越高，譬如说第一轮测试需要花上10天跑用例，那么到后期就没那么长的时间，可能就是1~2天的测试时间，在后期有时候一天就有一个新版本，这时候就要求测试人员能快速的进行一轮回归测试。
一般来说，覆盖越高，风险越低，但是效率就越差，反之亦然。如果时间允许的话，能把所有用例都再跑一遍最好不过，但是一般不会有这个时间，这就需要在效率和覆盖间找一个适当的平衡，选择一部分用例来进行回归测试。
回归测试时需考虑效率和覆盖度有效配合，通常的策略有以下几种：
基于风险选择测试：
哪些功能是软件的特色？
哪些功能是用户最常用的？
哪些功能出错将导致用户不满？
哪些程序是最复杂、最容易出错的？
哪些程序最容易扩散错误？
哪些程序是开发者最没有信心的？
只有有效的避免最大的风险，用户反感的问题，回归测试可以说达到了70%任务!
回归测试优先选择
第一，新修改的功能，这个显然是重点
第二，新修改的功能的关联功能，就是有耦合的部分，这个一般最好咨询一下开发人员
第三，程序最有卖点或者说亮点的部分，这个地方一旦有问题，会使程序 质量大打折扣
第四，程序中最致命的部分，譬如说 安全隐患，数据泄露，加密注册
第五，程序中比较脆弱的部分，这个要咨询开发人员，一般就是他们心中最没底的地方
第六，程序的主干功能
第七，如果以上做完，还有时间的话，最好把用例中级别比较高的用例再执行一遍。