起步于系统工程师,迈进入测试工程师,从起初的C/S系统到互联网时代的B/S系统,从事过电信增值业务、软交换、烟草OA、公安技侦和电子商务等行业的软件测试开发和管理多年,愿与大家共同分享共同交流,关注软件项目管理、测试团队管理、软件流程控制和软件性能测试及自动化测试技术。互联网时代,技术推动进步,欢迎人才推荐:jonas.wangl@alibaba-inc.com

回归测试的风险

上一篇 / 下一篇  2008-11-19 17:21:54 / 个人分类:黑盒测试

)E#d/QFp-j8b,I0    假设设置一个场景:   “但是,它仅仅是一个很小很小的改动!我们怎么会预先想到它会造成这么大的问题?”

wshD!n![yG051Testing软件测试网T#lJm2|:d d

    怎么会,确实!没有回归到的功能点可以造成很大的问题。

O)R9x-@y051Testing软件测试网*]5GD0G@p

    回归(向后追溯)是软件系统的现实生活。即使之前是很好地工作的,但是不能确保它会在最近的“很小”的改变后也能工作。是的,模块设计和充分的系统架构可以减少这种问题的出现,但是不能完全消除。51Testing软件测试网^)v;J"[0[?3l

51Testing软件测试网-m(j [(k&gV

    回归测试是永远都需要的。但是我们在非常有限的时间里测试一个“很小”的改动,我们怎么进行充分的回归测试呢?我们怎么知道查找哪些方面?我们怎么减少出现问题的风险?

B EX9a*A ee051Testing软件测试网&e9BN%Dl8e:l

    回归的问题

+zr^zs-i051Testing软件测试网"ufv,N#g(gMj7U

    回归的问题根源是软件系统的内在复杂性。随着系统的复杂性的增加,更改产生难以预见的影响的可能性也增加了。即使开发人员使用最新的技术也不可避免。51Testing软件测试网 I1zg"}TU;i

9}? k#b }]o j0    随着系统构建的时间越长回归的问题也会增多。在几年后,可能已经被更改了很多次,通常是由那些原本不在开发组中的人来修改的。即使这些人努力理解底层的设计和结构,更改与原本设计主题思想非常匹配也是很难做到的。这样的更改越多,系统变得越复杂直到变得非常脆弱。51Testing软件测试网)}Nu{4I bA

a#Ra"l&^%m C)_f-uG0    脆弱的软件就像脆弱的金属。被弯曲和扭转了这么多次以致你对它做的任何事都可能导致它的破裂。当一个软件系统变得脆弱,人们实际上会很害怕改变它。他们知道他们做的任何事情都可能导致更多的问题。易脆(不可维护)是旧的软件系统被替换的主要原因之一。51Testing软件测试网)tr6EU'aZ

B({M"^%V-mS\A k0    即使现在我们用自动化来回归主干流程,但也不能回归到很小的点,只能检查出不会有大的问题,小的问题还是要我们去回归测试的51Testing软件测试网GJoJ[Dm?,A

0A9p&H7[{9o y0    回归测试的困难51Testing软件测试网"N"_iKJ} a+H8] qhM

51Testing软件测试网;w5L.IQ~e*J

    因为任何系统都需要回归,所以回归测试非常重要。但是谁有时间对每一个小的更改都完全地重新测试系统呢?对一个只是1周多点的开发,我们肯定不能承受1个月的完全重新测试整个系统。我们有一个星期的时间测试就很幸运了;更通常的情况是,只允许几天的时间。51Testing软件测试网qt2f$@E

MbQSx0    既然完全的重测不可能,我们必须决定如何使用很好的时间来进行测试。但是我们怎么知道怎么做呢?我们怎么预见这些不可预见的问题呢?(就像老板要求你把这些会出现的意外情况做个列表一样可笑!)51Testing软件测试网5~ Ldj7bX

51Testing软件测试网 Gcf7eM&l!\

    现实中,我们总是有测试压力,即使当测试一个新的系统时。总是不够时间去完成所有应该完成的测试,因此我们必须充分利用可用的时间,用最好的方法去测试。我们在这种情况下我们必须使用“基于风险的测试方法” 。

xR\*j&PO0

,ZsR:}.}5gXb ^0    基于风险的测试

;z6N3W.ok(R;hM0

-j\rV2tDB|0    基于风险的测试的本质是我们评估系统不同部分蕴含的风险,并专注于我们的测试在那些最高风险的地方。这个方法可能让系统的某些部分缺乏充分的测试,甚至完全不测,但是它保证了这样做的风险是最低的。

$j*n)R.l2o5pJQFI0

oK,Z*JD0    “风险”对于测试与风险对于其他任何情况是一样的。为了评估风险,我们必须认识到它有两个截然不同的方面:可能性和影响。

4U0L d/Z^ DZ+c0

Iq&tD&Mq!P3z0      -“可能性”是可能出错的机会。不考虑影响程度,仅仅考虑出现问题的机会有多大。51Testing软件测试网!w#@"N![-c \Q

51Testing软件测试网Y(M;|R#c4\#y$IH

      -“影响”是确实出错后造成的影响程度。不考虑可能性,仅仅考虑出现的问题的情况会有多糟糕。51Testing软件测试网R%B ^.ud2n2U E\B

tL0O7G G q*?OAGJ0       使用这些风险信息,我们可能选择这样分配我们的测试:

+CK2Jp%n P#F+RM6\051Testing软件测试网]/^.P;?#ndP-gD!HP

      -50%的测试专注于新改的模块51Testing软件测试网"G#C;J#DdK0D1nV

51Testing软件测试网rK4?;X9@"I

      -30%的测试放在与新改模块相连的模块

7uQ$B v8~$|,F U9~&lL051Testing软件测试网O9y|JN`Q~6\

      -15%的测试放在与新改模块相关的模块

zYm(ZK051Testing软件测试网$W3|U&j!Wgy

      -5%的测试时间放在与新改模板不太相关的模块

6N+b:S%Oy/a051Testing软件测试网M;Ks2V7p V8]S3a&X

    使用基于风险的测试策略不能保证没有回归。但是会显著地减少对一个大系统进行的小更改的风险。现在我们就是采用自动化做全网回归测试来检查是否有重大问题,从运行的效果来看,成效应该说很不错的,几次发现了A类故障的问题,都是在非正式环境下扼杀掉,不然就可想而知了。。。

D0{a&W5A%B M051Testing软件测试网;bb;{YAU J'R

    我们如何把回归测试做的很全面,很到位,其实就现在用自动化来跑的话还不是很智能,因为中间会有很多因素影响到自动化回归的功能和回归范围。这个问题还在思考中。51Testing软件测试网kKY0b*N,y*Y


TAG: 黑盒测试

 

评分:0

我来说两句

Open Toolbar