回归测试的策略及方法
上一篇 /
下一篇 2012-06-20 09:24:10
/ 个人分类:杂谈
业界的回归测试策略基本上有两种:v \\~vgy0A,B:S0 ● 全部回归,也就是把之前的所有的测试用例,无论是手动的,还是自动的,全部跑一遍
;T [d+Z:R5p01L
R0vh5Z*t@0 ● 部分回归,定性分析代码改动有哪些影响,代码改动的文件/模块和其他的文件/模块的依赖性,然后选择被影响到的文件/模块相应的测试用例来跑一遍
&O*h(vpH2CqAiO051Testing软件测试网-MzD3N3v2e7c 第一种的好处就是,通过大量的跑测试用例,可以尽量多的发现哪些功能是否有被影响到,缺点就是如果你的测试用例库很大,那这个是相当消耗时间和人力的;51Testing软件测试网3A&^nw!rP!`7n
51Testing软件测试网a+I~0b5x|? 第二种的好处就是,不需要消耗大量的时间和人力,缺点就是因为是定性分析,所以有可能漏掉一些没有被分析出的影响;51Testing软件测试网!k,T:w:A&b4i*`d
51Testing软件测试网%^w1j5p
Q;irH#m 那么有没有其他第三种办法,用定量分析的方法来进行回归测试,答案是肯定的,可以依赖代码覆盖这个方式。
[m&Ttr6|K*G051Testing软件测试网|;nwp]bPr&?rJ 总的来说是这样的:51Testing软件测试网#^z6nD+~3t.{
*q]tm!j!r M9v~0 1、每次跑完一个测试用例就把对应的代码覆盖情况录入关系型数据库,这样数据库里面就有了测试用例和代码覆盖率的一一对应的表格。(代码覆盖率可以是文件级别或者是函数,类级别的)详情可以见下图:
G&uW"Y]W051Testing软件测试网+pe/F#d$yFX!C B 2、对于修改的代码,分析是属于哪个函数,类或者是文件的,然后去数据库查找所对应的测试用例
&n'z4HgBQj3L g051Testing软件测试网X%D'D4QiA7u} 3、这些对应的测试用例就是我们需要的,可能会因为代码改变而受到影响的测试用例。
*N3Ecr*[O051Testing软件测试网&}-ef"wk2eU f 测试用例 F8b7Kc+o:G1\fb0 |
v'D T4ejo]?0代码覆盖(文件级别)51Testing软件测试网{f8[!dG%VU |
ce1xy h(a[!l0TC1 5^"cLN%Q @0 | 51Testing软件测试网vAM8bBir File1, File2 V9[A}9A/Oq0 |
,J b$@&k2|I#Q4u0TC2 +yszX"o6c0Q0 | 3@lU:xU
U5Q0File1, File2,File3 Y.vbD:iz0 |
51Testing软件测试网&CP"M#nY
S;T4Yw2a TC351Testing软件测试网g
K)e8Dz | h2RO,F;}q9w+T V0B
VM0File351Testing软件测试网QFda*e"@@ |
...... /t@m{wvA"lL?!K0 | 51Testing软件测试网W(d0] p)?'jg-x ...... }[%sfEbB6^l0 |
Y3A6}9{ Z0U
U n0TCn51Testing软件测试网Y%VK:?} | 51Testing软件测试网}KB)ld~)[O"x File1, o
X!@"D9^0 |
比如,数据库里面已经有上面这样一张表格,那么假如开发修改了文件File3里面的代码,根据上面的表格我们知道TC2,TC3是和File3有关联的测试用例,所以我们可以挑出TC2,TC3出来执行,这样就是通过定性的方法来执行回归测试。51Testing软件测试网n8m1T
En2N$t-q4U
当然你的代码覆盖也可以是函数级别的:
!dCuE/r6Kfa;?3F)Y0-^W!E7bI0测试用例51Testing软件测试网o5Ak%mf)M#r | 51Testing软件测试网8gg{T0x 代码覆盖(函数级别)51Testing软件测试网J4E9S H.Q@\@aN? |
9M%h.co w+g+zWC0TC151Testing软件测试网;D]i,`IxH | 51Testing软件测试网%[oc0~{,B^ Func1,func2,func351Testing软件测试网*Ptt&l-P&@H |
51Testing软件测试网:Xhs'`0A&P;Tn6KT TC2 9i|{&g
SF%m0 | 51Testing软件测试网vMJG JG Func1,func2 *@,?%tB'F^ bO0 |
Gx#Jh8S6e*n,~ ~!WT0TC3 *D'cc6bov0 | 51Testing软件测试网 iV E0H-tCyc`8G*_ Func1,func3 V&r6k5Um1T
t0 |
...... | 51Testing软件测试网"l+P]O9lu^ ......51Testing软件测试网ud7[)b1kgYMX'n+S |
Ox+q@@ L8z#N0TCn51Testing软件测试网^P4_m8j([ N5k5f:c | 51Testing软件测试网zKO
`$P6wVZ 51Testing软件测试网+F"es+n6f!j-F :kq-y2^D+\#] R2[0Func1 g0PO6Fa^
Q2R0 |
那么当func3函数有修改,我们就知道TC1,TC2,TC3都是相关的测试用例,就可以挑出TC1,TC2,TC3出来跑。(对于新增的函数,我们
只能通过文件级别的代码覆盖表格来找,因为之前没有这个函数对应的测试用例,但是有这个函数所在的文件所对应的测试用例)。
0N&rW)K,P&A_MZ*k0
此外,也可以通过数据挖掘,寻找出文件与文件直接,或者是控件(dll)与控件之间的依赖性,比如文件A引用了文件B的函数(可以通过“函数名”在代码
库里面进行全文搜索,就知道那些函数被其他函数引用了),那么他们就有了依赖性(A对B有依赖,如果C对A有依赖,那么C对B也有了依赖,这里面设计到递
归),控件1含有文件A,控件2含有文件B,那么控件1对2就有了依赖性;通过数据挖掘把依赖性寻找出来以后,如果文件B被修改,那么所有对它有依赖的文
件/控件有可能受到影响,我们就可以把这些对应的测试用例找出来跑一遍;
{h;N|C2}4v|3a0 另外一种数据挖掘的方法是,通过bug数据库来挖掘, 比如在执行TC1(目的是为了测试Component A)的时候发现的Bug,她的root cause是Compoent B,那么Component A和Compoent B就有了耦合关系,以此类推,就知道Compoent。51Testing软件测试网0I'_:yt@A/J
收藏
举报
TAG: