醉里乾坤大,壶中日月长

测试工程师的角度思考如果做好自动化测试

上一篇 / 下一篇  2011-05-16 17:15:04 / 个人分类:细节思考

    转眼过去五个月,在新岗位工作的五个月中,也积累了一些新的思考,和大家分享。

自动化测试工作也四年有余,从开始的激动到懵懂到怀疑,经历了很多,到现在,在这个岗位,亲身经历了自动化测试于测试带来的巨大补充,感觉非常兴奋,也坚定了在这个行业继续努力的决心。

最近认为,做好自动化测试,有如下一些关键点需要注意:
1.     
相信自动化测试测试:

        可能很多人都觉得这点多余,既然投身了这个行业,在这个岗位,就会认为自动化测试是可行的,存在即合理吗。我却不这么认为。刚才提及过,从刚开始工作到现在,已经工作四年有余了,除了一开始接触QTP时带来的认知冲击,可以说,在后续的这三年中,我基本都处于一种怀疑状态:怀疑自动化测试是否真的能够带来合理的投入产出比,更直接点说吧,就是怀疑自动化测试是否有其存在的意义。

       为什么有这种怀疑呢?一个比较普遍的认知:自动化测试的本质是写软件测试软件。既然是写软件,我们自动化测试工作人员的水平是否能够写出有现实意义的测试软件?如果自己写的代码冗余,效率低下,当然,这些都不可怕,可怕的是我们写代码甚至频繁出错,而且不具有平台兼容性,可以知道,那么我们所谓的自动化测试不但不能给测试带来正向的推进,反而可以说是阻碍。

        所以,我一直认为,相比于实际可运行的大量自动化测试代码只是自动化测试人员的部分工作,而主要工作是输出测试技术:简单来说,就是拓展测试领域,深化测试技术。这也是在过去的两年中我一直追求的。

        在新的岗位,以一种新的模式进行自动化测试,看到了自动化测试带来的巨大收益。在手工测试人员提交的自动化测试评估报告中,使用我们提供的框架和基础库进行用例编写,基本效率可以提高80%左右,这非常令人鼓舞,也是我在现实的产品测试中,第一次看到自动化测试带来真正的现实意义。

 

2.  以做产品的态度来做自动化测试:

        之前的公司,自动化测试岗位也是测试岗位,行政上隶属于QA部门。平时我们的工作也是手工测试和自动化测试代码编写相混杂:忙的时候就手工测试,闲下来就做自动化测试代码编写工作。基本上每个人上来都能写代码,但普遍理解不深刻。

        那个时候觉得自动化测试的推进在于自我驱动,于自动化测试意识。比如一个测试点,需要重复性操作,可能对于有自动化测试意识并且愿意付诸实践的人,就会代码化;而对于意识偏弱或者不愿意写代码的人,就可以倾向于手工测试。

        在现在的公司,自动化测试团队是开发岗位,虽然在行政上还是隶属于QA部门,但保持相对的独立性。不再进行手工测试工作,与产品测试组是一种典型的客户服务模式,由产品测试组进行需求的提出,而有个关键人的存在,来筛选需求和理性并排优先级,最终需求会提交到自动化测试组这块,进行需求的实现。在需求的实现过程中,和产品组的人员可以不断的沟通(当然,沟通是需要技巧的),同时可以采用类敏捷的模式,这就要看双方的时间是否可以同步了。

        刚开始的时候,我非常不熟悉这种模式。写的代码总是按照之前的工作习惯,留出充分的接口,希望测试人员来自己实现一些扩展功能。而且,重逻辑轻展示。这都是之前在Linux上编程的习惯。在这里,被屡次狠批,验收我提交工具的人员总是说:你提交的工具完全搞不懂该怎么用。

        有过几次这样的经历,同时,由于在公司不断的接受其它研发的洗脑,逐渐培养起来了一种做产品的态度。昨天晚上看到一个同事桌子上的一本书:《不要让我思考》,这本书很有名气,我觉得,当前我的工作也是要以此为标杆要求。在投入大量精力做代码开发之余,也要投入足够的精力挖掘隐藏的需求,而且将这些需求最终翻译为便于操作的软件模式。

 

3.     高效简捷稳定的自动化测试框架:

        在这个标题上有三个形容词:搞笑、简捷、稳定,同等重要。所谓测试框架这个词目前已经有些滥了,言必框架。在之前的公司,我也做过一款框架,那是和业务紧密贴合的,为了处理跨Windows Linux平台的测试需求的一款工作辅助工具。不过由于技术有限,抽象层面不高,也不具有太多的普适意义。

        在这面见识了也是自开发的一款框架,短短几千行,基本上通用的功能都已经集合与此:用例的管理,批量执行,Log展示,结果的报表格式展示,跨平台的处理,跨浏览器的处理等等,充分应用了Python语言的特性,很多特性之前都没有接触过,在这里都得到了淋漓的展示。

        有了这款框架,让系统的编写代码逻辑成为可能,测试人员可以很快的在指导下编写可执行的测试用例,简单方便,大大节约了测试时间。

 

4.     综合的基础技能:

        最终还是要回归人的因素。自动化测试人员不同于常规意义的编程人员。可能在整个产品的开发周期中,作为一名产品开发工程师,只需要关注有限的领域,可以在此领域不断的深入技术,达到专家的层面。而作为一名自动化测试工程师,可能需要的知识面要宽广些,由于涉猎的内容太多,也很难在某一领域深入的太多,需要更多的时间打磨。

        比如我们所开发的内部产品,业务逻辑自不必说,一般还要有windows页面控件的操作,这些就需要windows系统api的知识,浏览器的http交互,一些基本的Http协议要了解,包括tcp/ip的基本知识,最终还要给出展示页面,也要会写些html

        这些内容可能都并不是什么高深的技术,可是要在一个项目中有机的结合起来,满足需求还是需要不断的学习与历练。

 

最终,我还是非常想强调思考能力。在新的公司,新的岗位,能够看到自动化测试有效推进,我很幸运。然而这种模式是否就真的能够长期有效?至少从我的角度,长此以往,由于严格分割了自动化测试和手工测试,手工测试人员的技术层面提高还是问题。可以在短期看到自动化测试的成果,但自动化测试的真正成熟还任重道远。

我很少去品评同事,不过在这里也和领导沟通过:为什么这面的同事都不太勤于思考?工作如果想做好,如果不投入精力去思考,去尝试,那很难有个理想的结果。特别是手工测试人员,需要的是思考后的灵光一现。

 

每个阶段对于技术的理解,对于业务的理解都不同,留备后改。


TAG:

散步的SUN的个人空间 引用 删除 散步的SUN   /   2011-06-03 11:38:23
路过...在帖子看到你了
端午节要到了,给朋友来祝个节日快乐
又看了一遍你帖子
“高效简捷稳定的自动化测试框架:

        在这个标题上有三个形容词:搞笑 、简捷、稳定,同等重要

给你提一个BUG,我本来以为这是一个对自动化测试框架的幽默说法呢,后来仔细斟酌了一下,好像不是。。。“搞笑”的自动化测试框架是怎么一种框架呢
逍遥客 引用 删除 xiaoyaoke   /   2011-05-30 10:24:19
原帖由lyscser于2011-05-27 08:52:58发表
如果能够把标题那俩“如果”改掉就好了


哈哈,我的性格不太适合做测试,平时也总出错~
@槽神刘叫兽 引用 删除 lyscser   /   2011-05-27 08:52:58
如果能够把标题那俩“如果”改掉就好了
tanjiang的个人空间 引用 删除 tanjiang   /   2011-05-18 09:23:23
5
xin_晴的个人空间 引用 删除 xin_晴   /   2011-05-17 11:11:27
您好,我是51Testing软件测试网的编辑,您的本篇博文被推荐至51Testing软件测试网首页发表:http://www.51testing.com/html/09/n-236809.html
感谢您关注并支持51Testing博客,期待您更多的优秀原创博文。
吴增谂 引用 删除 wuzengshen   /   2011-05-16 23:02:13
http://bbs.51testing.com/thread-449645-1-1.html
吴增谂 引用 删除 wuzengshen   /   2011-05-16 21:59:09
金山软件WPS高薪招聘系统测试工程师
http://bbs.51testing.com/thread-449645-1-1.html
@槽神刘叫兽 引用 删除 lyscser   /   2011-05-16 21:16:47
到处都有老孙你的影子……
楼主有想法,赞一个,同上面那个兄弟:交个朋友吧,呵呵
散步的SUN的个人空间 引用 删除 散步的SUN   /   2011-05-16 18:42:29
很高兴能够见到同道
很喜欢这句话:以做产品的态度来做自动化测试。
其实我确实也一直在思考,自动化的效益这个问题,如何去看待自动化带来的效益问题,如果能把这个相通了,一直做下去的话底气才能越来越足
很喜欢这篇文章,交个朋友吧,我们同样是思考者而已
 

评分:0

我来说两句

日历

« 2024-03-19  
     12
3456789
10111213141516
17181920212223
24252627282930
31      

数据统计

  • 访问量: 72435
  • 日志数: 106
  • 建立时间: 2009-06-05
  • 更新时间: 2011-09-09

RSS订阅

Open Toolbar