之前讨论到似乎自动化的程度挺高的,从自动装包(Automatic deployment),自动执行(Automatic
Execution),自动上传结果(Automatic Uploading),自动生成结果报告(Automatic Reporting),自动化测试的各个阶段都已经实现了。
n6d:n){$@B4m'}L:i0 套用一句话,看起来挺美的。可是,真的是这样吗?
jJjE{cU)XWa051Testing软件测试网H%dI]V,_g 毛主席教育我们要从群众中来,到群众中去。我们还是应该听听,一线测试人员以及team的反应,他们说:51Testing软件测试网,~"z_(C/X,Q3|B
"I1V7Z!vYp0 自动化测试还是不能帮助我们发现太多的问题,与此同时,我们投入地还是太多。
/g'i@$s'|
DC{"NH051Testing软件测试网*n#S1{6B;\"ktk 测试人员普遍不愿意持续地来维护CRT,感觉持续地做这个事情,学习的地方不多。51Testing软件测试网]:vMa%} Iy&{$x
51Testing软件测试网i
m`AA2v 自动化测试的误报概率还是太高,很多时候case失败了,并不是真正的软件问题,甚至连什么问题都不清楚。
6pS1YhG
_3d051Testing软件测试网W;N1Q5@-l)qb ...51Testing软件测试网}1O HE(S'|7hRc
TZ F6rOB8F/mA0 看起来,事情远远没有我们想象的那么完美。51Testing软件测试网CdIE6cX7d&RK
51Testing软件测试网$WO au&p5Q 从我的角度看,看到了以下几点:
q6W4LB%EW"ufv09qt/h$KKe0
我们的自动化测试离incremental build/incremental testing还是有很大的距离。我们虽然提供了所谓的daily
build,但是daily build并没有得到很好的测试。关键是在代码check in之前,以及代码check
in之后,以及在正式的编包之前,我们的测试做得并不是很充分。在代码check
in之后,只会做UT,然后就是几百个软件模块在一起集成测试,这个测试的跨度还是太大了,所以不符合CI的精神,即每个很小的软件变化(delta)都
能被测试到。因为软件版本在你check in之前还是好的,现在check in之后不好了,那很大的可能这个问题就是由于你的这次check
in引起的,哪怕你的这次check
in是没问题的,只是引发了以前的一个隐藏的问题,那你也应该负责把问题查清楚,并且解决掉问题。所以我们如果对软件进行持续的集成测试,如果我们集成的
频率足够地频繁,甚至代码的每次check in都可以把所有的case跑一遍,我们出现的问题应该很容易定位。
FEf%okNP,oi)D!h$X051Testing软件测试网0{U#R!X^b"Z"aQ6Z 但是现状和理想还是相距挺远的。关键问题就是我们的case跑的时间还是太长了。比如说,当时部门里面大约总共有1500个自动化测试用例,
差不多分配到10个team,然后每个team自己跑自己的case,差不多每个team要跑一个晚上了。而且我们的case执行都是独占式的,即一个
case跑得时候,别的case是不能在同一台机器上面跑的。我曾经做过一个统计,所有的测试用例跑完,差不多要50个小时,这个离我们的理想显然是太遥
远了。51Testing软件测试网*\wi
U1_
51Testing软件测试网.U-[W Xt7Z:D 一个新的版本发布出来以后,的确很快能达到95%的通过率,但是似乎也很难再提高了,而且依靠这种外部的监督来达到这种状态,可能也不是一种很理想的状态。Team讨论起CRT的问题来,总是觉得很难,但是总又觉得解决问题无从下手。51Testing软件测试网m%g/q9Hy{B8}5[
51Testing软件测试网t,om&mQk~
所以我们就在想,如果有一个Golden
Testbed,它可以持续不断的执行测试用例,然后一有问题就通知相关的有问题的team,然后team只需要解决问题,并不需要把时间花在这些重复的
环境准备上。如果我们排除了环境问题,那么只要我们的case足够地健壮,那么理论上来,发现的问题应该都是team应该花精力解决的问题了吧。51Testing软件测试网}Xt#ScC%A1r
7L`.n5M R
h0 这样看起来,当前的焦点集中在测试的执行时间上,具体到每个case的测试时间,如果不到team里面去,可能连case都看不懂,也很难解决实际的问题。于是,我又来到了team里面。51Testing软件测试网+}8ni6y;O{-t$`
Jv i3K9hV*T/z&f2g0 一开始我和他们一起来执行测试用例,然后过了一段时间后,对他们的测试用例也逐渐熟悉起来了,于是可以开始来思考如何优化测试用例本身了。
,B%MU!?f!wlq'r\O051Testing软件测试网hS_!cRa Q 具体的技术细节这里就不多论述了,可以说的是,经过一段时间的case refactory以后,原来5个team分开来执行,各自要执行4-5个小时的case,现在在一起只需要一个晚上就可以执行完了。51Testing软件测试网2JL^#MLl#w`4H)~E
_ IZ!O&UG0
这个时候,我们的想法也大胆成型了,即把比较成熟的几个team的case,放在一个golden
testbed上来统一执行,然后team不需要花时间来装包,维护环境。唯一需要做的就是当他们的测试用例fail的时候,他们需要来分析以及解决问
题。也就是说,假如他们的测试用例质量很高的话,他们所负责的软件模块也很稳定的话,Team基本上就不需要花太多的effort在这个上面了。这样的
话,也可以从另一个角度来激励team不断地改进Case的质量,从而可以尽可能地少花不必要的effort。51Testing软件测试网ff~iz,M~7wu$R
51Testing软件测试网~/MT8L-m kI 这个想法也得到了我们PO(Product Owner)的赞同,为了能够把这个事情做好,PO还专门成立了一个Task force来做这个事情。重点放在以下几个方面:51Testing软件测试网 EJ~ @'~W"A? YUX
3n]sX7C0 每个软件模块check in之后,在UnitTest之后,会自动部署到目标设备上最新的一个daily build上,执行Smoke Test,大约执行时间一分多钟,包括前面的部署时间的话,总的时间控制在8分钟以内。只有功能测试也通过的话,才会编到最终的package里面。51Testing软件测试网)C Y#],k}$^n9K\P4a
'l.XI*p
qc,W5_V0 每天的中午或者下午,会把所有有变化的软件模块放在一起,执行Light Weight RT,即把feature最核心的一些测试用例抽出来。
-?6P q%N"z?051Testing软件测试网A8f2P)y7r)K!jB,@ 等到晚上的时候,当前Pate里面应该是最新的daily build+通过smoke test的各个软件模块,基本上,这个组合代表了我们软件当前最新的一种状态。然后利用晚上的时间,对其进行充分的回归测试。
;W]wPpr051Testing软件测试网p(zwmfn:wbcw+N 基本上这是我们敏捷开发的自动化话回归测试的现状,现在还不确定这个模式会不会引入新的一些问题,如果碰到新的问题的话,我们可以再分析解决。
${$e~9R9[[jGu051Testing软件测试网Z:ah6H]^ 等到晚上,我们可以在跑Regression Test
(k%hgqg+sK$I051Testing软件测试网Yks,N(p3O.qdq)t相关链接:51Testing软件测试网'U9uBA7^ j`#Sh@
y^Rw,a*^J0从瀑布开发走向敏捷开发模式下的自动化测试(1)51Testing软件测试网5|a,feWf
51Testing软件测试网W \_9zq从瀑布开发走向敏捷开发模式下的自动化测试(2)
QaSn
c-\)b vC0