【转】一个测试人员的自我总结

2016/01/13 11:13
阅读数 25

关于UI:
其实在四年以前,我刚刚来到澳洲,在面试的时候我就表示UI自动化的弊病太多了,比如速度慢,不稳定,以及在做浏览器兼容性的时候时间成本会以倍数上升等等,所以我们应该适当的往下走。只可惜没有一个人认同我的观点,他们觉得时间增加了那就申请更多的测试机,不稳定就多跑几次,维护成本高那就多加人。这点个人感觉国内做的相对好一些,对于新鲜想法的接受程度也更高。可喜的是慢慢大家发现,UI测试随着用例数的增加会变的越来越痛苦。我现在的项目,在我加入之前完全是UI驱动,有大概2000个自动化用例,平均每个用例要消耗5-10分钟执行,由于UI结构很复杂,selenium经常会出现异常,所以每次执行有40%的用例会因为selenium失败。然后不得不再重新把这40%的用例重新执行,以此类推。每次回归要在四个机器上执行,大概需要消耗一周多的时间,后来提出要在不同浏览器上回归,结果整个自动化项目就无法继续下去了。当然这个问题不止是UI的问题,还有很多其他地方需要去优化,只可惜当时的经理比较固执,我只能硬着头皮维护下去,而且根本没有精力去添加新的用例。

关于框架:
在我还比较不清醒的时候,我也是一个框架的狂热份子,我觉得能写一个框架是一件很伟大的事情。以至于后来在百度的时候自己还从头写了一个算是keyword驱动的框架吧,不基于任何其他框架,现在不客气的说很多人说自己搭了个框架其实就是在各种xUnit上面加了一些功能而已。如果真的写一个框架,需要自己实现用例的收集和加载,用例执行和结构规范以及结果的格式化,只有实现了这三个功能才能说自己写了个框架。在成了那个框架以后我们组5个人在一周时间内添加了1200多个用例,把一个以前需要几个月测试的东西在半个小时内搞定了。但是后来我发现,其实这个成就根本不来自于这个框架,而是我们组织用例的方法很高效。后来我用了一晚上的时间放弃了这个简陋的东西并移植到了nosetest上面。说实话,现在新的框架其实也都是在原有的基础上炒炒概念而已。就说现在很多公司都标榜的BDD吧,其实无非就是把一句话里的词map到后台的函数里面,这个不就是keyword的变种么,如果我们把动作也看做是一种变数,那keyword也就可以变成data driven。所以对于自动化来说别再纠结于什么框架,好好想想怎么把维护成本降下来,速度提上去更实际。

关于技术:
测试技术在这几十年其实并没有什么大的发展,究其原因,测试的核心问题就是怎么把一个无限大输入域有效的分割成有限个数的区域的问题,但是至今也没有一个算法可以做到,不过如果真的有了那我们可能就都失业了。就像monkey所说现在整个行业是螺旋上升,何为螺旋,我认为现在我们更应该关注于其他技术和测试的结合,比如docker在测试的应用。借助和其他方面技术的结合来提高测试的有效性。

关于发展:
首先说说传统意义上的测试,我记得09年在thoughtworks的conference上有个即兴演讲环节,有个人上去以后很自豪的说,自动他会写单元测试(后来在他的描述中我才知道其实就是接口测试)了以后就受到了开发的尊重。我不知道现在有多少人依旧认为测试存在的意义要靠会写代码体现,这个想法其实很幼稚。我说一个真实的例子,在淘宝X组,有一个人完全不会写代码,他以前也不是什么专业的测试,他在一个X平台做了很多年的客服。但是由于他对于业务的深度了解,以至于很多其他人根本发现不了的问题他都能找出来,而且产品和开发都要向他去请教很多问题。所以如果你是在项目中,不是一个专门写代码开发测试框架和工具的,那就别把精力全都放在自动化和框架上了,很多有意义的事情可以做。

展开阅读全文
打赏
1
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
1
分享
返回顶部
顶部