回归测试测试用例选择方法

来源：年旅网

回归测试测试⽤例选择⽅法

回归测试就是修改完bug后对程序的新⼀轮测试，根据微软的统计，按照他们的经验，⼀般开发⼈员解决3~4个bug会衍⽣出⼀个新的bug，这就是必须作回归测试的原因。

⼀般的软件测试流程是后期快速迭代的，bug在后期是快速收敛的，debug和测试的周期也是越来越短，频率是越来越⾼，譬如说第⼀轮测试需要花上10天跑⽤例，那么到后期就没那么长的时间，可能就是1~2天的测试时间，在后期有时候⼀天就有⼀个新版本，这时候就要求测试⼈员能快速的进⾏⼀轮回归测试。

⼀般来说，覆盖越⾼，风险越低，但是效率就越差，反之亦然。如果时间允许的话，能把所有⽤例都再跑⼀遍最好不过，但是⼀般不会有这个时间，这就需要在效率和覆盖间找⼀个适当的平衡，选择⼀部分⽤例来进⾏回归测试。回归测试时需考虑效率和覆盖度有效配合，通常的策略有以下⼏种：

基于风险选择测试：

哪些功能是软件的特⾊？哪些功能是⽤户最常⽤的？

哪些功能出错将导致⽤户不满？

哪些程序是最复杂、最容易出错的？哪些程序最容易扩散错误？

哪些程序是开发者最没有信⼼的？

只有有效的避免最⼤的风险，⽤户反感的问题，回归测试可以说达到了70%任务!

回归测试优先选择

第⼀，新修改的功能，这个显然是重点

　　第⼆，新修改的功能的关联功能，就是有耦合的部分，这个⼀般最好咨询⼀下开发⼈员　　第三，程序最有卖点或者说亮点的部分，这个地⽅⼀旦有问题，会使程序质量⼤打折扣　　第四，程序中最致命的部分，譬如说安全隐患，数据泄露，加密注册

　　第五，程序中⽐较脆弱的部分，这个要咨询开发⼈员，⼀般就是他们⼼中最没底的地⽅　　第六，程序的主⼲功能

　　第七，如果以上做完，还有时间的话，最好把⽤例中级别⽐较⾼的⽤例再执⾏⼀遍。

因篇幅问题不能全部显示，请点此查看更多更全内容

查看全文