回归测试就是修改完bug后对程序的新⼀轮测试,根据微软的统计,按照他们的经验,⼀般 开发⼈员解决3~4个bug会衍⽣出⼀个新的bug,这就是必须作回归测试的原因。
⼀般的软件测试流程是后期快速迭代的,bug在后期是快速收敛的,debug和测试的周期也是越来越短,频率是越来越⾼,譬如说第⼀轮测试需要花上10天跑⽤例,那么到后期就没那么长的时间,可能就是1~2天的测试时间,在后期有时候⼀天就有⼀个新版本,这时候就要求 测试⼈员能快速的进⾏⼀轮回归测试。
⼀般来说,覆盖越⾼,风险越低,但是效率就越差,反之亦然。如果时间允许的话,能把所有⽤例都再跑⼀遍最好不过,但是⼀般不会有这个时间,这就需要在效率和覆盖间找⼀个适当的平衡,选择⼀部分⽤例来进⾏回归测试。回归测试时需考虑效率和覆盖度有效配合,通常的策略有以下⼏种:
基于风险选择测试:
哪些功能是软件的特⾊?哪些功能是⽤户最常⽤的?
哪些功能出错将导致⽤户不满?
哪些程序是最复杂、最容易出错的?哪些程序最容易扩散错误?
哪些程序是开发者最没有信⼼的?
只有有效的避免最⼤的风险,⽤户反感的问题,回归测试可以说达到了70%任务!
回归测试优先选择
第⼀,新修改的功能,这个显然是重点
第⼆,新修改的功能的关联功能,就是有耦合的部分,这个⼀般最好咨询⼀下开发⼈员 第三,程序最有卖点或者说亮点的部分,这个地⽅⼀旦有问题,会使程序 质量⼤打折扣 第四,程序中最致命的部分,譬如说 安全隐患,数据泄露,加密注册
第五,程序中⽐较脆弱的部分,这个要咨询开发⼈员,⼀般就是他们⼼中最没底的地⽅ 第六,程序的主⼲功能
第七,如果以上做完,还有时间的话,最好把⽤例中级别⽐较⾼的⽤例再执⾏⼀遍。
因篇幅问题不能全部显示,请点此查看更多更全内容
Copyright © 2019- oldu.cn 版权所有 浙ICP备2024123271号-1
违法及侵权请联系:TEL:199 1889 7713 E-MAIL:2724546146@qq.com
本站由北京市万商天勤律师事务所王兴未律师提供法律服务