别再纠结于那些自动化测试不得不面对的现实z
转自：http://kan.weibo.com/con/3522877245597301
作者：@测试仔刘毅
前言&摘要
工作中总难免遇到一些不想见到的问题，但是遇到问题总需要去解决。解决问题的时候我们不提倡一条路走到黑，但是也绝不鼓励“朝三暮四”、“朝秦暮楚”等各种浅尝辄止。就像我们在做自动化测试的过程中，有些问题是始终无法回避的，如：测试工具缺陷、测试数据使用难以及开发人力投入较多等诸多妖魔鬼怪。我们若不去逐个斗过，也不知道自己战斗力到底有多强，最终也无法取得真经、修成正果。
阅读关键字
自动化测试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控制项都被可以忽略了，测试结果根本不可信啊。看他将信将疑，我赶快找了几份生产缺陷事件报表发给他看，后来他研究了很久，好歹总算把这个想法给否定了。同样，我们可以看得出，无论技术是否过硬，测试工具本身的弱点是无法回避的，但是既然被称为工程师，我们始终要面对这些问题，并且必须要尝试解决它们。否则，就算是换一种测试工具那又能如何，这世界上存在完美的东西么？
该如何面对自动化测试的学习
其实稍微想一下我们就知道，自动化测试的学习和研究也是我们不得不面对的问题之一。《师说》有云：“人非生而知之者，孰能无惑？”所以我们在自动化测试学习或者实施的过程中也难免会遇到很多不可预知的问题，遇到问题的时候是该“求鱼”还是该“求渔”，是该自力更生还是求助于人，是该谷歌还是谷歌，工具和技术应该学到什么水平……这些都是应该事先弄清楚的。
平常闲逛的时候，经常在坛子里面看到有人在那里喊：“来个高手来教我QTP啊”，“广州有自动化测试的高手吗？带带我吧”——哦哟，拜托你们不要再卖萌了啦，人家会受不了的啦！在我看来这基本上都是不肯面对现实，不愿意主动去学习的表现，到坛子里只是找个倾诉的对象或者说精神的寄托而已。因为你真的不知道哪位菩萨心肠的大师会去主动找到你，给你传道授业解惑。如果自己都没有仔细的去动手尝试，没有去找到自己的困惑点在哪里，再高的高手也无法三两句话能给你解释清楚，你还真以为可以随随便便移植一下记忆么？就像一个虔诚的信徒在哪里求上帝：上帝啊，求求你，让我中大奖吧！上帝回答他：那你（TMD，语气助词）也得先买注彩票先！道理很简单：若要得到别人帮助，必须先保证在求助于别人之前自己已经尽了最大的努力了；不愿意一点点把基础打牢的人是浮躁的人，若无神奇因缘，指望别人将他们的问题一扫而光基本是不可能的事情。
我熟悉的测试工具不多，但是也了解不少，我比较讨厌比较这这那那的工具，在抵制工具至上论的同时，我也不介意反复再三地宣扬我的观点：我们是做测试的，但绝大多数不是做测试工具的测试的，所以没必要为了工具的好坏去争论；我们以我们的被测系统为核心，我们以满足自己的测试需求为根本目标，一切工具都只是整个测试过程中的一些手段而已，没有什么事情是以手段为核心而对根本目标置之不理的。我们部门有位对WEB开源测试工具比较熟悉的同事，他自己出了一本关于Selenium实践经验的书，据说口碑还不错，只可惜他在封面上就开始痛批QTP的种种不是，我看了之后感觉五味杂陈，不知该以之为荣还是该为之伤心。之所以该伤心，并不单单是因为他对QTP工具本身的贬低，因为他这么说恰恰说明我可能在QTP的使用上比他熟悉得多。我主要是对这种妄下结论，排斥性太强的看法与做法很不以为然，说难听一点，简直是死脑筋嘛，这不是我们学习自动化测试工具与方法所应有的态度。我觉得要想全面学习自动化测试，一定要抛开测试工具的门户之见，否则很容易陷入偏执的僵局，真的会被一叶障目。
一个人如果对自动化测试若只是初窥门径或者尚未入门则罢了，若是要熟练掌握一种测试工具的使用，那就该从基本的功能到框架的搭建都能了然于胸。熟练之后，如果有精力的话，就可以去深入研究和分析自动化测试抛开形形色色的工具之后又该是什么一种意识形态，有什么规律和章法。若非如此，我们对自动化测试的认识始终停留在对一种测试工具的理解上，而不是对测试的理解上。这样，你把QTP的录制、参数化叫做你的测试框架，把Selenium使用JUnit的框架叫做你的测试框架，把我们建设起来的自动化测试管理平台工具叫做你的测试框架。可惜对真正帮助组织我们的自动化测试开发、运行，优化我们的自动化测试开发、运行的一套方法没有去摸索，或者没有将之与我们的系统测试结合起来落地执行，更没有去做方法论上的提炼升华与实例化的开发。如此这般，我们就错过了很多凌驾于测试工具本身的，有价值的、有趣的一些东西，而得到这部分东西，哪怕只是其中的一部分，我们就会明白，只要是做测试，核心的东西还是操作描述、测试数据、预期结果那点东西；知道这一点，就会知道用什么工具来做自动化，差别只是在手段上而已。真正精通自动化测试的人，其实并不见得他们对测试工具本身使用或者编码的技术是最强的人，但他们至少是懂得如何把“测试”和“自动化”这两个关键字有机结合的一些人；在他们看来，在自动化实施过程中，规划和需求要比技术和工具本身重要得多。
可能有人会说：先莫唱高调，你觉得我们该如何学习和研究呢？我的回答是：很简单，就是把自己实践得到的经验加上别人实践得到的经验揉合一下，其实总结起来有三点（当然如果你愿意的话，你可以去分成十三点、二百五十小点去说）：
不停的实践：使用一两种工具在不同类型、不同架构、不同行业的系统上去实践。真能用心学习和实践，一年半载便足够了，至少工具驾驭上应该不输现在90%的人，但像QTP的使用，能够坚持数年录制、参数化而不改变的人，不在我们讨论的范围之内。我见到过有位仁兄，09年的时候还在在论坛询问一些很简单很基础的QTP工具使用问题，10年就已经自己搞了一些很有技术含量的专题讲座了，学习速度让我很惊讶也很佩服。这都是他通过一点点摸索尝试获得的成果，相信将来更大的成就对他来说也不会很远。
多听多看：听别人如何说，看别人如何做。除了要多于自己身边的同事多学习沟通之外，平时抽空多到网上去看看别人的说法和做法，结合自己在实践中的感受和困惑进行思考总结。拿句套话来说，这是一个“去伪存真”的过程，面对海量的信息，如果缺了有效的鉴别，很可能就会被别人的观点所迷惑或者造成更多的困惑。其实无论作者观点的对与错、是否有价值并不在于他这篇文章本身，我们只有认真地读了、想了、实践了，有所斩获了，才能不枉作者码字的一番心血。
看书不如看帮助文档：无论是谁写的书，写的什么书，书中所讲述的观点都是依照作者的知识、阅历去陈述的。而最可悲的是有些作者著书的动机可能会不单纯，或为名、或为利，而知识共享与传承神马的对他们来说都是次要的。这样一来，书中可能会充斥着“绝对”、“一定”这类字眼，将一些不成熟甚至是错误的观点灌输给读者。时过境迁，作者未必不知道当初自己错了或者有疏漏，但是鲜有人肯出面勘误澄清，所以说：读书有风险，购买须谨慎。别的行业我不敢说，但是关于自动化测试，我见过这样的工具说明书，好几本，读起来感觉就是花几十块钱雇了个蹩脚的翻译，把英文的帮助文档给丢三落四的翻译了一通。至于英文的著述如何，我就没再研究了，总之学的过程中若想看参考说明书，我还是建议配上一本词典，去看帮助文档吧。如果刚入门就想凭借一本书变精通，那么观念里面有些东西可能以后很难改变了，无论它是对的还是错的。
例行总结
最后，我想说句话与大家共勉：不要盲目崇拜什么权威、什么技术专家，只要能够勇于面对你本该面对的问题，并且努力解决它，很快你就是专家。当然，你这个专家与其他专家一样，都是可以被很快超越的，所以也不要迷恋自己专家的头衔；继续虚心学习，方能立于不败之地。这些都是很俗套、很简单的道理，看得开，一切都是风轻云谈、海阔天空；看不开，则有可能走火入魔、害己害人！
武侠崇尚的是：天下武功，唯快不破！同样，在自动化测试领域中，要想做高手，那么你要快快地工作，快快地遇到问题，快快地解决问题，快快地进步吧；然后快快地被赏识，快快地涨薪升职吧。
作者：@测试仔刘毅
前言&摘要
工作中总难免遇到一些不想见到的问题，但是遇到问题总需要去解决。解决问题的时候我们不提倡一条路走到黑，但是也绝不鼓励“朝三暮四”、“朝秦暮楚”等各种浅尝辄止。就像我们在做自动化测试的过程中，有些问题是始终无法回避的，如：测试工具缺陷、测试数据使用难以及开发人力投入较多等诸多妖魔鬼怪。我们若不去逐个斗过，也不知道自己战斗力到底有多强，最终也无法取得真经、修成正果。
阅读关键字
自动化测试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控制项都被可以忽略了，测试结果根本不可信啊。看他将信将疑，我赶快找了几份生产缺陷事件报表发给他看，后来他研究了很久，好歹总算把这个想法给否定了。同样，我们可以看得出，无论技术是否过硬，测试工具本身的弱点是无法回避的，但是既然被称为工程师，我们始终要面对这些问题，并且必须要尝试解决它们。否则，就算是换一种测试工具那又能如何，这世界上存在完美的东西么？
该如何面对自动化测试的学习
其实稍微想一下我们就知道，自动化测试的学习和研究也是我们不得不面对的问题之一。《师说》有云：“人非生而知之者，孰能无惑？”所以我们在自动化测试学习或者实施的过程中也难免会遇到很多不可预知的问题，遇到问题的时候是该“求鱼”还是该“求渔”，是该自力更生还是求助于人，是该谷歌还是谷歌，工具和技术应该学到什么水平……这些都是应该事先弄清楚的。
平常闲逛的时候，经常在坛子里面看到有人在那里喊：“来个高手来教我QTP啊”，“广州有自动化测试的高手吗？带带我吧”——哦哟，拜托你们不要再卖萌了啦，人家会受不了的啦！在我看来这基本上都是不肯面对现实，不愿意主动去学习的表现，到坛子里只是找个倾诉的对象或者说精神的寄托而已。因为你真的不知道哪位菩萨心肠的大师会去主动找到你，给你传道授业解惑。如果自己都没有仔细的去动手尝试，没有去找到自己的困惑点在哪里，再高的高手也无法三两句话能给你解释清楚，你还真以为可以随随便便移植一下记忆么？就像一个虔诚的信徒在哪里求上帝：上帝啊，求求你，让我中大奖吧！上帝回答他：那你（TMD，语气助词）也得先买注彩票先！道理很简单：若要得到别人帮助，必须先保证在求助于别人之前自己已经尽了最大的努力了；不愿意一点点把基础打牢的人是浮躁的人，若无神奇因缘，指望别人将他们的问题一扫而光基本是不可能的事情。
我熟悉的测试工具不多，但是也了解不少，我比较讨厌比较这这那那的工具，在抵制工具至上论的同时，我也不介意反复再三地宣扬我的观点：我们是做测试的，但绝大多数不是做测试工具的测试的，所以没必要为了工具的好坏去争论；我们以我们的被测系统为核心，我们以满足自己的测试需求为根本目标，一切工具都只是整个测试过程中的一些手段而已，没有什么事情是以手段为核心而对根本目标置之不理的。我们部门有位对WEB开源测试工具比较熟悉的同事，他自己出了一本关于Selenium实践经验的书，据说口碑还不错，只可惜他在封面上就开始痛批QTP的种种不是，我看了之后感觉五味杂陈，不知该以之为荣还是该为之伤心。之所以该伤心，并不单单是因为他对QTP工具本身的贬低，因为他这么说恰恰说明我可能在QTP的使用上比他熟悉得多。我主要是对这种妄下结论，排斥性太强的看法与做法很不以为然，说难听一点，简直是死脑筋嘛，这不是我们学习自动化测试工具与方法所应有的态度。我觉得要想全面学习自动化测试，一定要抛开测试工具的门户之见，否则很容易陷入偏执的僵局，真的会被一叶障目。
一个人如果对自动化测试若只是初窥门径或者尚未入门则罢了，若是要熟练掌握一种测试工具的使用，那就该从基本的功能到框架的搭建都能了然于胸。熟练之后，如果有精力的话，就可以去深入研究和分析自动化测试抛开形形色色的工具之后又该是什么一种意识形态，有什么规律和章法。若非如此，我们对自动化测试的认识始终停留在对一种测试工具的理解上，而不是对测试的理解上。这样，你把QTP的录制、参数化叫做你的测试框架，把Selenium使用JUnit的框架叫做你的测试框架，把我们建设起来的自动化测试管理平台工具叫做你的测试框架。可惜对真正帮助组织我们的自动化测试开发、运行，优化我们的自动化测试开发、运行的一套方法没有去摸索，或者没有将之与我们的系统测试结合起来落地执行，更没有去做方法论上的提炼升华与实例化的开发。如此这般，我们就错过了很多凌驾于测试工具本身的，有价值的、有趣的一些东西，而得到这部分东西，哪怕只是其中的一部分，我们就会明白，只要是做测试，核心的东西还是操作描述、测试数据、预期结果那点东西；知道这一点，就会知道用什么工具来做自动化，差别只是在手段上而已。真正精通自动化测试的人，其实并不见得他们对测试工具本身使用或者编码的技术是最强的人，但他们至少是懂得如何把“测试”和“自动化”这两个关键字有机结合的一些人；在他们看来，在自动化实施过程中，规划和需求要比技术和工具本身重要得多。
可能有人会说：先莫唱高调，你觉得我们该如何学习和研究呢？我的回答是：很简单，就是把自己实践得到的经验加上别人实践得到的经验揉合一下，其实总结起来有三点（当然如果你愿意的话，你可以去分成十三点、二百五十小点去说）：
不停的实践：使用一两种工具在不同类型、不同架构、不同行业的系统上去实践。真能用心学习和实践，一年半载便足够了，至少工具驾驭上应该不输现在90%的人，但像QTP的使用，能够坚持数年录制、参数化而不改变的人，不在我们讨论的范围之内。我见到过有位仁兄，09年的时候还在在论坛询问一些很简单很基础的QTP工具使用问题，10年就已经自己搞了一些很有技术含量的专题讲座了，学习速度让我很惊讶也很佩服。这都是他通过一点点摸索尝试获得的成果，相信将来更大的成就对他来说也不会很远。
多听多看：听别人如何说，看别人如何做。除了要多于自己身边的同事多学习沟通之外，平时抽空多到网上去看看别人的说法和做法，结合自己在实践中的感受和困惑进行思考总结。拿句套话来说，这是一个“去伪存真”的过程，面对海量的信息，如果缺了有效的鉴别，很可能就会被别人的观点所迷惑或者造成更多的困惑。其实无论作者观点的对与错、是否有价值并不在于他这篇文章本身，我们只有认真地读了、想了、实践了，有所斩获了，才能不枉作者码字的一番心血。
看书不如看帮助文档：无论是谁写的书，写的什么书，书中所讲述的观点都是依照作者的知识、阅历去陈述的。而最可悲的是有些作者著书的动机可能会不单纯，或为名、或为利，而知识共享与传承神马的对他们来说都是次要的。这样一来，书中可能会充斥着“绝对”、“一定”这类字眼，将一些不成熟甚至是错误的观点灌输给读者。时过境迁，作者未必不知道当初自己错了或者有疏漏，但是鲜有人肯出面勘误澄清，所以说：读书有风险，购买须谨慎。别的行业我不敢说，但是关于自动化测试，我见过这样的工具说明书，好几本，读起来感觉就是花几十块钱雇了个蹩脚的翻译，把英文的帮助文档给丢三落四的翻译了一通。至于英文的著述如何，我就没再研究了，总之学的过程中若想看参考说明书，我还是建议配上一本词典，去看帮助文档吧。如果刚入门就想凭借一本书变精通，那么观念里面有些东西可能以后很难改变了，无论它是对的还是错的。
例行总结
最后，我想说句话与大家共勉：不要盲目崇拜什么权威、什么技术专家，只要能够勇于面对你本该面对的问题，并且努力解决它，很快你就是专家。当然，你这个专家与其他专家一样，都是可以被很快超越的，所以也不要迷恋自己专家的头衔；继续虚心学习，方能立于不败之地。这些都是很俗套、很简单的道理，看得开，一切都是风轻云谈、海阔天空；看不开，则有可能走火入魔、害己害人！
武侠崇尚的是：天下武功，唯快不破！同样，在自动化测试领域中，要想做高手，那么你要快快地工作，快快地遇到问题，快快地解决问题，快快地进步吧；然后快快地被赏识，快快地涨薪升职吧。