前言&摘要：工作中总难免遇到一些不想见到的问题，但是遇到问题总需要去解决。解决问题的时候我们不提倡一条路走到黑，但是也绝不鼓励“朝三暮四”、“朝秦暮楚”等各种浅尝辄止。就像我们在做自动化测试的过程中，有些问题是始终无法回避的，如：测试工具缺陷、测试数据使用难以及开发人力投入较多等诸多妖魔鬼怪。我们若不去逐个斗过，也不知道自己战斗力到底有多强，最终也无法取得真经、修成正果。
关键字：自动化测试；QTP；SELENIUM；测试数据；测试工具
摆一摆自动化测试中的问题
大约前几天，一位同事为了Selenium处理模态窗口问题而纠结，而她之前是常年与QTP为伍的，她悻悻地说：这破玩意，以前用QTP的时候根本就不会存在这个问题！我奸笑一声，对她狠狠地说：既然QTP那么好用，那你之前还不好好写你的脚本，现在领导觉得QTP在你的系统可能不适用了才开始推行Selenium，你还抱怨……那你得怨恨到什么时候呢？作为一个习惯了我“叫兽”风格的同事，她对我给予的挖苦不以为意，嘿嘿一笑继续忙她的了。当然，她最终搞定了这个问题，自然地，欢呼雀跃一下也是在所难免的。我后来跟她说：其实你之前只要多花一点时间把你的QTP开发质量提高一个档次，现在也不会有人逼着你花时间来解决这个问题，而且接下来前面还有什么问题等着你谁也不知道；现在是花很多时间，以前也要花很多时间，什么时候花都一样，自动化测试在我们这里绝不是应付了事，所以，我们始终都得面对开发投入这个现实！而且，早一点投入，产出效益也会更加明显一些。
再往前几个月，有一个开发经理向我们组同事咨询QTP在自动化测试中的使用情况，可碰巧被咨询的这位同事是个QTP盲。出于对技术仔的仰慕，我主动找到他，问他想了解一些什么东西，他说他想在集成环境中用QTP做集成测试。我就问：你们的单元测试做的咋样嘛？他说：还不错啊，用JUnit尝试了一下，不过JUnit测试完了还是无法确保移交的版本质量和可测性。我又问：你们尝试过Selenium么？那玩意是开源的，对你们来说应该很好用，如果用JAVA来做，估计你们单元测试代码可以复用不少呢。他回了一句：测试数据不好弄啊，数据又少又复杂，不知道QTP在这方面有没有什么优势？我就瞬间丢失了作为一个粉丝应有的姿态，嘟囔了一句：优势个屁，如果想绕过测试数据这关来做你的集成测试，你趁早还是别做了，早点移交给我们，让我们多点系统测试时间吧。当然这个我不敢明说，只好书面的回了一句：不管我们用什么工具，测试数据的使用、管理都是我们不得不面对的问题，这是测试的核心要素，所以没有什么UI工具能跨越业务逻辑来使用测试数据。
再往前一两年的样子，部门里有个QTP技术仔同事私下里和我探讨，他对QTP运行环境要求高和运行速度慢、对象经常莫名其妙不识别等等问题深恶痛绝。他问我：据说LR运行不是基于页面的，你懂吗？我说：略懂，LR是基于协议的，靠模拟客户端请求去执行测试的。他立马来了劲，兴奋地说：那就是不受页面对象变化的影响咯？如果这样，你觉得我们如果用LR去写脚本做回归测试会不会很爽？至少速度快，受环境影响非常小。我一身冷汗，心想别让我又造了孽，误导了别人吧，赶紧劝阻：千万别，要是这样，WEB页面最基本的JS控制项都被可以忽略了，测试结果根本不可信啊。看他将信将疑，我赶快找了几份生产缺陷事件报表发给他看，后来他研究了很久，好歹总算把这个想法给否定了。同样，我们可以看得出，无论技术是否过硬，测试工具本身的弱点是无法回避的，但是既然被称为工程师，我们始终要面对这些问题，并且必须要尝试解决它们。否则，就算是换一种测试工具那又能如何，这世界上存在完美的东西么？
该如何面对自动化测试的学习
其实稍微想一下我们就知道，自动化测试的学习和研究也是我们不得不面对的问题之一。《师说》有云：“人非生而知之者，孰能无惑？”所以我们在自动化测试学习或者实施的过程中也难免会遇到很多不可预知的问题，遇到问题的时候是该“求鱼”还是该“求渔”，是该自力更生还是求助于人，是该谷歌还是谷歌，工具和技术应该学到什么水平……这些都是应该事先弄清楚的。
……………………
查看全文请点击下载：http://www.51testing.com/html/13/n-806213.html
一个人如果对自动化测试若只是初窥门径或者尚未入门则罢了，若是要熟练掌握一种测试工具的使用，那就该从基本的功能到框架的搭建都能了然于胸。熟练之后，如果有精力的话，就可以去深入研究和分析自动化测试抛开形形色色的工具之后又该是什么一种意识形态，有什么规律和章法。若非如此，我们对自动化测试的认识始终停留在对一种测试工具的理解上，而不是对测试的理解上。这样，你把QTP的录制、参数化叫做你的测试框架，把Selenium使用JUnit的框架叫做你的测试框架，把我们建设起来的自动化测试管理平台工具叫做你的测试框架。可惜对真正帮助组织我们的自动化测试开发、运行，优化我们的自动化测试开发、运行的一套方法没有去摸索，或者没有将之与我们的系统测试结合起来落地执行，更没有去做方法论上的提炼升华与实例化的开发。如此这般，我们就错过了很多凌驾于测试工具本身的，有价值的、有趣的一些东西，而得到这部分东西，哪怕只是其中的一部分，我们就会明白，只要是做测试，核心的东西还是操作描述、测试数据、预期结果那点东西；知道这一点，就会知道用什么工具来做自动化，差别只是在手段上而已。真正精通自动化测试的人，其实并不见得他们对测试工具本身使用或者编码的技术是最强的人，但他们至少是懂得如何把“测试”和“自动化”这两个关键字有机结合的一些人；在他们看来，在自动化实施过程中，规划和需求要比技术和工具本身重要得多。
可能有人会说：先莫唱高调，你觉得我们该如何学习和研究呢？我的回答是：很简单，就是把自己实践得到的经验加上别人实践得到的经验揉合一下，其实总结起来有三点（当然如果你愿意的话，你可以去分成十三点、二百五十小点去说）：
● 不停的实践：使用一两种工具在不同类型、不同架构、不同行业的系统上去实践。真能用心学习和实践，一年半载便足够了，至少工具驾驭上应该不输现在90%的人，但像QTP的使用，能够坚持数年录制、参数化而不改变的人，不在我们讨论的范围之内。我见到过有位仁兄，09年的时候还在在论坛询问一些很简单很基础的QTP工具使用问题，10年就已经自己搞了一些很有技术含量的专题讲座了，学习速度让我很惊讶也很佩服。这都是他通过一点点摸索尝试获得的成果，相信将来更大的成就对他来说也不会很远。
● 多听多看：听别人如何说，看别人如何做。除了要多于自己身边的同事多学习沟通之外，平时抽空多到网上去看看别人的说法和做法，结合自己在实践中的感受和困惑进行思考总结。拿句套话来说，这是一个“去伪存真”的过程，面对海量的信息，如果缺了有效的鉴别，很可能就会被别人的观点所迷惑或者造成更多的困惑。其实无论作者观点的对与错、是否有价值并不在于他这篇文章本身，我们只有认真地读了、想了、实践了，有所斩获了，才能不枉作者码字的一番心血。
● 看书不如看帮助文档：无论是谁写的书，写的什么书，书中所讲述的观点都是依照作者的知识、阅历去陈述的。而最可悲的是有些作者著书的动机可能会不单纯，或为名、或为利，而知识共享与传承神马的对他们来说都是次要的。这样一来，书中可能会充斥着“绝对”、“一定”这类字眼，将一些不成熟甚至是错误的观点灌输给读者。时过境迁，作者未必不知道当初自己错了或者有疏漏，但是鲜有人肯出面勘误澄清，所以说：读书有风险，购买须谨慎。别的行业我不敢说，但是关于自动化测试，我见过这样的工具说明书，好几本，读起来感觉就是花几十块钱雇了个蹩脚的翻译，把英文的帮助文档给丢三落四的翻译了一通。至于英文的著述如何，我就没再研究了，总之学的过程中若想看参考说明书，我还是建议配上一本词典，去看帮助文档吧。如果刚入门就想凭借一本书变精通，那么观念里面有些东西可能以后很难改变了，无论它是对的还是错的。
……
查看全文请点击下载：http://www.51testing.com/html/13/n-806213.html
版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
