中国软件测试联盟

 找回密码
 注册

QQ登录

只需一步,快速开始

http://www.wanmeiff.comJS of wanmeiff.com and vcpic.com Please keep this copyright information, respect of, thank you!JS of wanmeiff.com and vcpic.com Please keep this copyright information, respect of, thank you!
查看: 468|回复: 0

高效地进行回归测试及测试用例选择方法

[复制链接]
发表于 2018-1-23 15:03:28 | 显示全部楼层 |阅读模式
织雀教育-物联网测试的黄埔军校,专注软件测试人才培养

  看到这个问题,好多人觉得这是测试人员的事,其实我觉得如何更高效的进行回归测试应该是开发人员和测试人员共同的事。
  为什么这么认为呢?举个简单的例子:一些开发人员修改完bug,他们觉得自己的bug都已经fixed,然后兴高采烈地通知配置管理员发布新的版本,结果测试人员刚跑几个模块,系统就崩溃了。这怎么让回归测试进行下去呀?所以我觉得要进行高效的回归测试,按角色分应该从以下几个方面着手。
  首先,开发人员应该做到以下两个方面:
  第一,开发人员在发布新的版本之前要做smoke testing,尽可能早的发现一些影响测试的严重bug;
  第二,开发人员在修改bug状态的时候,要注明修改了哪个模块的哪些函数,这些信息有助于懂代码的测试人员去分析判断该bug是否真的修复好并对系统产生哪些影响。
  其次,测试人员应该尽可能的从以下几个方面着手:
  第一,要熟悉系统的业务流程。对于该bug(或新增功能)的业务需求以及关联模块要很清楚,可以尽快进入测试状态并保证测试的质量;
  第二,及时更新测试用例,保证执行的测试用例是最新的;
  第三,要掌握测试用例的优先级别,也就是分清孰轻孰重,把时间花在刀刃上。对于优先级高的功能优先并充分测试,时间允许的前提下再测试优先级低的功能;
  第四,借助自动化工具测试相对稳定的功能;
  第五,沟通,及时与开发人员进行有效的沟通,更多地了解业务及系统,及时反馈测试情况;
  第六,有效的测试管理,作为测试经理应该对于自己的组员有足够的了解,根据测试人员的技能,合理分配测试任务;
  最后,我觉得测试人员应该熟悉系统开发的语言。

  众所周知软件测试这个职业有一个为从业者不悦的一个特点就是有时特别烦琐,要经常做重复性的东西,相信同行或多或少都会有这个感慨,而罪魁祸首就是回归测试。如果每次测试的功能点都是新的,每次招生的测试用例都是未曾执行过的话,我相信同行都不会觉得厌烦反而很有兴致想看下新的功能是怎样的,执行起用例来也特认真。我也是如此,如果做久了一个项目特别是总是推迟发布的话每天就祈祷着当前项目快点了结。一接到新项目就有如获新生的感觉……确实回归测试次数多了,测试员不由变得烦躁起来,特别如果是回归测试策略又不妥当的话简直令人发疯……
 
  我深受其害。进新公司近半年来还没有完全是自己负责的项目,除了花了一定的时间做自动化方面的东西外,其它的时间就是执行测试用例了,当然也就有大量的回归测试了。更郁闷的是没有相应的回归测试策略,而且不少测试用例已经不再适用了,数量又多(以前新功能测试的用例),我逐渐变得厌烦,然后是麻木,最后几近崩溃。一个汗啊……痛苦泥潭中的只好搜索相关资料并结合自己的实践,总结下如何更有效地做回归测试,让回归测试做得更有意义。
 
  所谓回归测试就是当软件发生改变时,重新测试已经通过测试的测试区域,以验证修改的正确性及其影响。其实我们做测试的大部分工作也是在做回归测试,严格按照定义的话一旦软件作了修改就必须进行回归测试。我想对修改过后的软件要进行回归测试应该就是无可厚非的,无论是教科书上的介绍还是前人的经验总结都知道回归测试的必要性与重要性。那非要做回归测试,那样怎样才能做得更为有效有意义呢?显然这都需要从测试用例着手。
 
  首先我们必须有个管理良好的测试用例库,这个用例库中的所有用例必须是有效的,有达到足够的覆盖率,并且是容易查找组织的。这需要有良好的测试管理工具,并有相应的资源(时间与人力)去维护这个测试用例库,务必使其中没有过时,冗余的测试用例,并达到一定的覆盖率。如何管理组织好测试用例已是一个很值得深入研究的课题,在此不再阐述(我也没有很好的见解……)总之,要做好回归测试,组织管理良好的测试用例库是前提。
 
  有了测试用例库,那我做回归测试时就执行所有有效的测试用例?这个没有绝对的答案,在很多的时候如果你有足够的资源用全部测试用例来做回归测试是最佳选择。 但现实中呢?有足够资源这个理想状态比较少,并且有些时间也没有必要这样做。如果只是修改了某个警告对话框中的单词就要执行完所有测试例以确保其修改正确性及其影响?或许你会说只有疯子才会那么做,但事实上有时候我们正是那个疯子。基本上很多时候连开发自己都不敢肯定会不会影响到其它部分,所以我们就不得不扩大测试范围。那应该如何选择回归测试使用呢?前人已经总结了很多,主要是如下4种。
 
  1>选择全部测试用例
选择测试用例库中的所有测试用例作为回归测试用例,这是一个较为保险的方法。在理想的状态下(有足够的资源,测试人员不知疲惫),这种方法绝对是首选。但理想与现实的差距是惨不忍赌的,测试资源缺乏是行内常情,特别是由于进度而导致测试时间极为苛刻,而且测试人员会因多次执行相同用例而产生厌烦,这对测试质量影响是非常大的。所以,从现实资源考虑还是从成本上考虑都不可能每次回归测试包都是选择所以测试用例。
 
2>基于风险选择测试用例
这是基于一定的风险标准从测试用例库中选择部分测试用例形成测试包。按测试优先级来来选择最重要的、关键的和可疑的测试,而跳过那些非关键的、优先级别低的或者高稳定的测试用例。这样测试任务会大为减轻但效果并不差,因为由此没有被发现的缺陷是较少并严重性较低的。
 
3>基于操作剖面选择测试用例
这种方法适用于测试用例是基于软件操作剖面开发的,测试用例的分布情况反映了系统的实际使用情况。回归测试时可以优先选择那些针对最重要或最频繁使用功能的测试用例,释放和缓解最高级别的风险,有助于尽早发现那些对可靠性有最大影响的故障。
 
4>再测试修改部分
这种是基于开发对修改的影响区域有较大把握时所采取的一个策略。通过相依性分析识别软件的修改情况并分析修改的影响,将回归测试局限于被改变的模块和它的接口上,此时只选择相应的测试用例来做回归测试。此策略风险最大,但成本也是最能低的,通常用于做小回归测试。
 
  以上四种回归测试策略各有优缺点,实际应用中应根据项目的资源,进度及项目开发的模式等实际情况来选择最优策略。1>一般情况在在一个非用于基线的 build中作了小修改,
建议采用策略4,只测试修改部分,因为现在的开发流程中build更新较快特别是极限编程中,要进行完全的回归测试是比较不现实的,即使有自动化工具的辅助亦未必能实现。2>在一个milestone中,一个作为基线的build中则可采用策略2或3,基于一定的风险选择测试,这是一个较为折中的办法,但如果资源允许的话建议进行全回归测试。3>较重要的mileStone或是最终版本,最好选择全回归测试。因为如果一般来说此时软件改动会较大,选择全部测试较为保险。当然这还是要依据当时的实际出发。
 
  但无论采取何种策略,回归测试还是让人弃之不做却又不得不做的一种测试,因为它重复多并且经常工作量大但经常发现的缺陷相对工作量来说太少。但是谁都不敢承担不做回归测试带来的后果,真是食之无味,弃之不能。所以在做回归测试时我们必须采取一些较为有效的方法来保证做好回归测试。例如安排新的测试者完成手工回归测试,让更有经验的测试者开发新的测试用例,编写和调试自动测试脚本,做一些探索性的或ad hoc测试。或是采取轮流执行不同模块,尽量避免一人一直测试某一模块,不论从测试感受还是测试效果来看,这都是一个不好的方法。但我觉得最重要的就是基于实际可行的话引进自动化测试,因为机器不会累,可以日夜跑。
 
  回归测试这个令人头痛的问题需要根据项目跟测试资源等实际情况来采取更有效的策略来解决。其中需要注意的是必须重视回归测试,在测试计划中有很好的进度安排及选择相应的回归,重视测试用例的维护,借助于自动化工具。
分享到: 更多
中国软件测试联盟(www.51sqae.com),一个免费权威的讨论新软件技术的论坛。
织雀教育-物联网测试的黄埔军校,专注软件测试人才培养
您需要登录后才可以回帖 登录 | 注册

本版积分规则

关闭

站长推荐上一条 /1 下一条

本站资源仅供学习交流,非营利性质,如有侵权等行为,请联系管理员删除|中国软件测试联盟 ( 京ICP备17018412号;京公网安备11010802017997

GMT+8, 2018-8-16 01:12

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表