Clean Code的思想在功能测试自动化重构中的应用
上一篇 /
下一篇 2012-08-09 09:37:51
/ 个人分类:自动化测试
t+D)h*jlK0 项目背景介绍:
Y3J$SH;y(W4IaF0x~'wxa0 最近在给一个团队做测试用例的
重构,重构最主要的原因是由于不同team的测试执行了相同的操作,但是却有不同的检查点。偏偏这些操作又是非常耗时的,所以从整个部门的角度看,这些测
试的效率就是不高的。然后我们又在做持续集成,自然对测试的效率有极高的要求,所以就决定做测试用例的重构,PO分配了一些有经验的测试工程师来做这个事
情,我帮助他们解决自动化测试上的问题。
^#I-r
UT Dm051Testing软件测试网R)G&n7b"xw2L
I5R 问题介绍:
._R`8D_C#Z:{051Testing软件测试网c'U"D4sin
be%f 涉及到的软件模块有一个是大型电信分布式系统的管理模块,主要管理系统的告警,故障恢复,启动时序等功能。模块的功能基本上可以理解为各种各样的policy的制定。(这个模块有点类似政府部门,呵呵)51Testing软件测试网 R)\lK
_6F Pyfn:y
51Testing软件测试网;Y_^S;I
l
t+Vz 比较有意思的一点软件功能的边界有很多模糊的地方,用通俗的话说就是“水很深”。有点像中国的政策,按原则是一套,但是实际执行的时候考虑到一些系统自身的限制,又做了很多妥协,所以就造成了系统中的诸多灰色地带。51Testing软件测试网9s-m%wE6s)b&V
51Testing软件测试网7U$zn+W&^B c-? 对测试人员的影响是碰到问题以后,和开发人员沟通,往往最后的结论是诸如“一般情况下应该是这样的,但是现在出了不一样的情况也是正常”的等等。(作为一个测试人员,你会不会郁闷?呵呵)51Testing软件测试网f
dq(mlYw gZ.`
F{;N\vn#aSA0 对于手工测试人员来说,经过“打磨”一段时间后,这样的“弹性”是可能去建立的,但自动化测试却不同,往往是自动化测试的期望结果是简单一刀切,结果失败了并不是软件真的需要改的Bug。限制地松了,则可能任何问题都发现不了。所以测试人员挺郁闷的,都开始反感自动化测试了!
e{S!sz I0{*_D*E;o j8V3Ml0 问题原因的分析: