中国软件测试联盟

 找回密码
 注册

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!
查看: 161|回复: 0

软件测试中回归测试风险及测试用例维护

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

   “但是,它仅仅是一个很小很小的改动!我们怎么会预先想到它会造成这么大的问题?”
    怎么会,确实!
    回归(向后追溯)是软件系统的现实生活。即使之前是很好地工作的,但是不能确保它会在最近的“很小”的改变后也能工作。是的,模块设计和充分的系统架构可以减少这种问题的出现,但是不能完全消除。
    回归测试是永远都需要的。但是我们在非常有限的时间里测试一个“很小”的改动,我们怎么进行充分的回归测试呢?我们怎么知道查找哪些方面?我们怎么减少出现问题的风险?
回归的问题
    回归的问题根源是软件系统的内在复杂性。随着系统的复杂性的增加,更改产生难以预见的影响的可能性也增加了。即使开发人员使用最新的技术也不可避免。
    随着系统构建的时间越长回归的问题也会增多。在几年后,可能已经被更改了很多次,通常是由那些原本不在开发组中的人来修改的。即使这些人努力理解底层的设计和结构,更改与原本设计主题思想非常匹配也是很难做到的。这样的更改越多,系统变得越复杂直到变得非常脆弱。
    脆弱的软件就像脆弱的金属。被弯曲和扭转了这么多次以致你对它做的任何事都可能导致它的破裂。当一个软件系统变得脆弱,人们实际上会很害怕改变它。他们知道他们做的任何事情都可能导致更多的问题。易脆(不可维护)是旧的软件系统被替换的主要原因之一。
回归测试的困难
    因为任何系统都需要回归,所以回归测试非常重要。但是谁有时间对每一个小的更改都完全地重新测试系统呢?对一个只是1周多点的开发,我们肯定不能承受1个月的完全重新测试整个系统。我们有一个星期的时间测试就很幸运了;更通常的情况是,只允许几天的时间。
    既然完全的重测不可能,我们必须决定如何使用很好的时间来进行测试。但是我们怎么知道怎么做呢?我们怎么预见这些不可预见的问题呢?(就像老板要求你把这些会出现的意外情况做个列表一样可笑!)
    现实中,我们总是有测试压力,即使当测试一个新的系统时。总是不够时间去完成所有应该完成的测试,因此我们必须充分利用可用的时间,用最好的方法去测试。我们在这种情况下我们必须使用“基于风险的测试方法” 。
基于风险的测试
    基于风险的测试的本质是我们评估系统不同部分蕴含的风险,并专注于我们的测试在那些最高风险的地方。这个方法可能让系统的某些部分缺乏充分的测试,甚至完全不测,但是它保证了这样做的风险是最低的。
    “风险”对于测试与风险对于其他任何情况是一样的。为了评估风险,我们必须认识到它有两个截然不同的方面:可能性和影响。
      -“可能性”是可能出错的机会。不考虑影响程度,仅仅考虑出现问题的机会有多大。
      -“影响”是确实出错后造成的影响程度。不考虑可能性,仅仅考虑出现的问题的情况会有多糟糕。
    假设一个会计系统,我们更改了分期付款的利息。更改会用3天的时间,我们会用2天的时间来测试。因为我们不能在两天时间内完全充分测试这个会计系统,我们需要评估所作的更改给其它系统部分带来的风险。
      -分期付款模块的功能会很可能出错,因为这些是更改的部分。它们同时是对系统来说相对影响重大的部分,因为它们影响收入。既是高可能性的,又是高影响程度的,意味着系统的这部分必须投入充分的测试。
      -应收款模块拥有中等程度的错误可能性,因为改变的功能是这个模块的一个紧密组成部分。因为收款模块影响收入,因此出错的影响程度是高的。所以收款模块也需要投入足够的测试关注,因为它拥有中-高程度的风险。
      -总账模块拥有低程度的错误可能性。但是如果错误会对公司有重大的影响。因此总账模块拥有低-高程度的风险。
      -最后,应付款出错的可能性很低,因为更改功能与它没有什么关系。而且这个模块错误后的影响最多也是中等程度的。因此拥有低-中程度风险,不需要投入太多的测试。
使用这些风险信息,我们可能选择这样分配我们的测试:
      - 50%的测试专注于新改的分期付款模块
      - 30%的测试放在应收款模块
      - 15%的测试放在总账模块
      - 5%的测试时间放在应付款模块
    使用基于风险的测试策略不能保证没有回归。但是会显著地减少对一个大系统进行的小更改的风险。
回归测试中测试用例的维护
  通过运行已经开发的测试用例,可以提高回归测试的效率。测试用例的维护主要有以下几个方面:
  (1)、删除过时的测试用例因为需求的改变等原因可能会使一个基线测试用例不再适合被测试系统,这些测试用例就会过时。例如,某个变量的界限发生了改变,原来针对边界值的测试就无法完成对新边界测试。所以,在软件的每次修改后都应进行相应的过时测试用例的删除。
 
  (2)、改进不受控制的测试用例随着软件项目的进展,测试用例库中的用例会不断增加,其中会出现一些对输入或运行状态十分敏感的测试用例。这些测试不容易重复且结果难以控制,会影响回归测试的效率,需要进行改进,使其达到可重复和可控制的要求。
 
  (3)、删除冗余的测试用例如果存在两个或者更多个测试用例针对一组相同的输入和输出进行测试,那么这些测试用例是冗余的。冗余测试用例的存在降低了回归测试的效率。所以需要定期的整理测试用例库,并将冗余的用例删除掉。
 
  (4)、增添新的测试用例如果某个程序段、构件或关键的接口在现有的测试中没有被测试,那么应该开发新测试用例重新对其进行测试。并将新开发的测试用例合并到基线测试包中。
分享到: 更多
中国软件测试联盟(www.51sqae.com),一个免费权威的讨论新软件技术的论坛。
您需要登录后才可以回帖 登录 | 注册

本版积分规则

关闭

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

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

GMT+8, 2018-2-23 12:19

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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