自动化框架那点事
这一节本来准备是简要介绍一下watir的一些基本知识以及开发时所用到的一些必备工具，但是思量再三，笔者认为还是先介绍一下关于框架的、而你所不熟知的一些事情。
很多年前，还是年少无知、天真幼齿的我不小心看到了一部名为《日本沉没》的电影。在无限的爱国热诚和民族自豪感的强势驱动下，我极力希望影片中所发生一切能够在现实中上演。后来我等了许多天，YY了N多年，电影里的剧情一直没有上演。而后半大不小的终于明白，原来电影和现实始终是有些差距的，我们不可能生活中在电影和动画片里，就如同我们不可能生活在新闻联播中一般。
想明白了这一点的我，后来渐渐的不吃反胃的菠菜、不再死死的盯着炭火期待熏陶出传说中的火眼晶晶；也不再去寻找只有一只耳朵的老鼠，更不再总是剃个光头、盘腿而坐、闭目片刻然后再高亢而低调的说声：“休息休息”。同学们均纷纷表示留起头发的我渐渐变得帅气了，我笑而不语，开始将内裤穿在外，那时候的我已经不信一休改信超人。
再大一些的时候，我学会了几句日语，认识了一些德艺双馨且具有献身精神的日本艺术家，那儿时强烈对于日本沉没且完蛋的期盼，早已被扔进了那个叫做回忆的保留地里。后来又离开了家，经历了许多人、许多事，那块叫做回忆的保留地也遇到了拆迁队，被现实敲打得四分五裂、面目全非，记忆中的一切已经变形和扭曲。那时的那个“她”已经被人丫丫呓语的喊做妈妈；而那时的那个我，也早已经跟天真纯情散了伙。你有你的房子和家，我有我的，天涯。
前两日，日本发生了9级地震。后来看了图片及影像报道，发现震中的景象比之日本沉没这部电影中所描述的是远远的有过之而无不及。儿时天天YY的情景也算是部分实现。地震引发的海啸铺天盖地，冲垮了房屋桥梁、冲走了汽车及居民、也让某位女艺术家香消玉损，只剩遗作可以凭吊。
灾难发生时，才感到人力的渺小；玉损香消后，方感叹硬盘之重要。
我们一直被条条框框束缚着，像是活在深圳的公车里，四面八方都是脸孔，紧紧的将你压迫；在条条框框面前，我们仿佛是井底之蛙，只看到头顶上的那边天空，却不曾想过海洋大远大。就像是儿时的我，放弃诅咒日本沉没而改信一休哥，随后又弃那小和尚而去，转而模仿超人的内衣外穿的混搭风。偶像一箩筐，终究却忘了自身这幅臭皮囊。
原来我一直都在盲目的追求，却不曾停下想一想自己需要的是什么。
我想测什么？我想要测SOSO能不能搜索出腾讯首页。
我想该怎么测？我首先要打开soso首页，然后在搜索框中输入“腾讯首页”，点击搜索按钮。我不想手工去点击打开浏览器，转到soso首页等等，我想使用自动化测试工具来代替我手工输入。
用什么工具来代替手工？用watir吧，简单好用。
该怎么开始？先使用watir打开浏览器，然后再让waitr帮我们识别出搜索框并在搜索框里输入“腾讯首页”四个字，然后利用watir来点击搜索按钮。
怎么判断测试结果是否正确？如果搜索结果里包含“腾讯首页”这四个字的话，那么测试通过，否则测试失败。
如何让测试用例能够复用？我想复用上面的测试，这次我想验证soso是不是可以搜索到腾讯微博。很简单，将需要在搜索框中搜索的内容独立出来，放到文件或者是写到数据库里，然后每次执行用例的时候读文件或数据库取出需要输入的内容就可以了。
测试结果出来了，我怎么才能让这个结果更加易读，让项目组的所有成员都看得懂？可以自己写一些代码来格式化输出结果，然后把结果以邮件或者其他形式展现给其他人。
把上面这些问题回答出来，并且系统的组织好，那么一个自动化测试框架便自然而然的诞生了。
下面抽象一点，自动化测试实际上要做的最主要事情只有下面3件：
更抽象一些，自动化测试的核心是解决并组织以下3个问题：
测试对象我们可以使用一些测试工具来帮我们获取和操作，例如watir， selenium， QTP等。当然，我们也可以自己写工具来达到这一目的。
测试步骤和测试预期实际上就是测试用例中的一部分。测试步骤指导如何我们一步一步的进行测试；而测试预期告诉我们这个步骤下，正确的结果应该是怎样，这样我们才能发现错误与不符合需求之处。
测试数据也是测试用例中的一部分。我们把它单独拿出来是因为我们有很多的用例实际上数据驱动的用例。比如上面的soso用例，测是否能搜索出腾讯首页和是否能搜索出腾讯微博的步骤是一样的，唯一的区别就是两次的输入数据不同。自动化测试的一个很大优势就在于其能快速敏捷使用不同的数据测试同一场景。而将数据独立出来管理也便于我们以最少的代码实现尽可能多的用例，从而极大的提升了自动化测试的覆盖率。
上面的问题理解了，于是自动化测试框架的概念也就呼之欲出了，是的，就跟这几年志玲姐姐的上围一般。
首先自动化测试框架要解决上述的3个核心问题：测试对象，测试步骤预期、测试数据。
在实现了核心功能以后，再辅以用例组织优化——如使用一些第三方类库组织测试用例，让测试用例更加容易编写、阅读、维护；加上对象的深层管理——如将对象以一定的逻辑组织维护起来，尽量降低由于UI变动而导致的代码修改问题；最后配上友好的报告输出、定时执行、定量执行、持续集成等机制，让框架更加的有血有肉，功能强大。
现在真相大白了，自动化测试框架其实也没有那么神秘，框架的一切都来自于我们的需求，需求驱动框架，框架满足需求。
这时候可能有人要奋起反诘：我勒个去！你说的框架怎么跟百度上google到的说法不一样？
其实答案很简单，不要拘泥于那些个看似公理定理般神圣不可侵犯的定义和专业观点，不要以为框架框架就是要被条条框框束缚绑架。一切从需求出发，以需求驱动开发，以需求驱动测试，这样得到的结果比单纯的生搬硬套应该要好得多。
后续我们所分享的内容可能会侧重于测试对象的识别操作，以及测试数据的组织封装和选取。至于测试步骤和预期，这个跟测试业务的业务逻辑密不可分，尽管有些方法可以设计和筛选出最高效适宜的测试步骤，但这并不是本文所关注的知识点。
最后我们再举个例子来实际剖析一下所谓的框架。
我们以某知名自动化测试框架为例：
以上这些模块就组成了某知名自动化测试框架。我们很容易可以看出，框架来自需求，由需求驱动。测试技术和测试工具只是框架的一个组成部分而已，不可混为一谈。需求决定框架的开发，而测试工具和测试技术是用来满足需求的描述。所谓的框架，如是而已。
在这里我们对于框架的探寻和思考暂且告一段落。后续我们将深入的了解waitr对象识别和操作的基本及高级技巧。
很多年前，还是年少无知、天真幼齿的我不小心看到了一部名为《日本沉没》的电影。在无限的爱国热诚和民族自豪感的强势驱动下，我极力希望影片中所发生一切能够在现实中上演。后来我等了许多天，YY了N多年，电影里的剧情一直没有上演。而后半大不小的终于明白，原来电影和现实始终是有些差距的，我们不可能生活中在电影和动画片里，就如同我们不可能生活在新闻联播中一般。
想明白了这一点的我，后来渐渐的不吃反胃的菠菜、不再死死的盯着炭火期待熏陶出传说中的火眼晶晶；也不再去寻找只有一只耳朵的老鼠，更不再总是剃个光头、盘腿而坐、闭目片刻然后再高亢而低调的说声：“休息休息”。同学们均纷纷表示留起头发的我渐渐变得帅气了，我笑而不语，开始将内裤穿在外，那时候的我已经不信一休改信超人。
再大一些的时候，我学会了几句日语，认识了一些德艺双馨且具有献身精神的日本艺术家，那儿时强烈对于日本沉没且完蛋的期盼，早已被扔进了那个叫做回忆的保留地里。后来又离开了家，经历了许多人、许多事，那块叫做回忆的保留地也遇到了拆迁队，被现实敲打得四分五裂、面目全非，记忆中的一切已经变形和扭曲。那时的那个“她”已经被人丫丫呓语的喊做妈妈；而那时的那个我，也早已经跟天真纯情散了伙。你有你的房子和家，我有我的，天涯。
前两日，日本发生了9级地震。后来看了图片及影像报道，发现震中的景象比之日本沉没这部电影中所描述的是远远的有过之而无不及。儿时天天YY的情景也算是部分实现。地震引发的海啸铺天盖地，冲垮了房屋桥梁、冲走了汽车及居民、也让某位女艺术家香消玉损，只剩遗作可以凭吊。
灾难发生时，才感到人力的渺小；玉损香消后，方感叹硬盘之重要。
我们一直被条条框框束缚着，像是活在深圳的公车里，四面八方都是脸孔，紧紧的将你压迫；在条条框框面前，我们仿佛是井底之蛙，只看到头顶上的那边天空，却不曾想过海洋大远大。就像是儿时的我，放弃诅咒日本沉没而改信一休哥，随后又弃那小和尚而去，转而模仿超人的内衣外穿的混搭风。偶像一箩筐，终究却忘了自身这幅臭皮囊。
引用
转入正题，记得刚入行的时候，有前辈告诉我，自动化测试的最高境界在于框架，能独立写出框架，那么你便站在整个行业的巅峰。
我吞了吞口水，无比崇拜的问他道：“那什么是框架，您能跟我解释一下么？”
前辈扶了扶眼镜，微微抬起下巴，眼睛望着窗外，狠狠的吸了口烟说道：“唉，我也不知道！”
后来我又问了许多人什么是框架，他们纠结而又坦诚的告诉我：去谷歌上百度一下吧。
于是乎那几年，框架这个词在我心中成了如同阿娇、啊Sa一样脱俗的存在。后来阿娇倾情演出了艳照门，而阿Sa也偷偷的离了婚…
再往后我弄清楚了艳照门，但是框架是个什么玩意却依然是云里雾里。
直到有一天，我在向一位高人讨教什么是框架时，那位高人很迷惑的看着我说道：“框架？这个你先不要管，最本质的问题是，你想要测什么，怎么测？你要清楚自己想做什么。”
一时间烟消云散，醍醐灌顶。
我吞了吞口水，无比崇拜的问他道：“那什么是框架，您能跟我解释一下么？”
前辈扶了扶眼镜，微微抬起下巴，眼睛望着窗外，狠狠的吸了口烟说道：“唉，我也不知道！”
后来我又问了许多人什么是框架，他们纠结而又坦诚的告诉我：去谷歌上百度一下吧。
于是乎那几年，框架这个词在我心中成了如同阿娇、啊Sa一样脱俗的存在。后来阿娇倾情演出了艳照门，而阿Sa也偷偷的离了婚…
再往后我弄清楚了艳照门，但是框架是个什么玩意却依然是云里雾里。
直到有一天，我在向一位高人讨教什么是框架时，那位高人很迷惑的看着我说道：“框架？这个你先不要管，最本质的问题是，你想要测什么，怎么测？你要清楚自己想做什么。”
一时间烟消云散，醍醐灌顶。
原来我一直都在盲目的追求，却不曾停下想一想自己需要的是什么。
我想测什么？我想要测SOSO能不能搜索出腾讯首页。
我想该怎么测？我首先要打开soso首页，然后在搜索框中输入“腾讯首页”，点击搜索按钮。我不想手工去点击打开浏览器，转到soso首页等等，我想使用自动化测试工具来代替我手工输入。
用什么工具来代替手工？用watir吧，简单好用。
该怎么开始？先使用watir打开浏览器，然后再让waitr帮我们识别出搜索框并在搜索框里输入“腾讯首页”四个字，然后利用watir来点击搜索按钮。
怎么判断测试结果是否正确？如果搜索结果里包含“腾讯首页”这四个字的话，那么测试通过，否则测试失败。
如何让测试用例能够复用？我想复用上面的测试，这次我想验证soso是不是可以搜索到腾讯微博。很简单，将需要在搜索框中搜索的内容独立出来，放到文件或者是写到数据库里，然后每次执行用例的时候读文件或数据库取出需要输入的内容就可以了。
测试结果出来了，我怎么才能让这个结果更加易读，让项目组的所有成员都看得懂？可以自己写一些代码来格式化输出结果，然后把结果以邮件或者其他形式展现给其他人。
把上面这些问题回答出来，并且系统的组织好，那么一个自动化测试框架便自然而然的诞生了。
下面抽象一点，自动化测试实际上要做的最主要事情只有下面3件：
- 获取并操作测试对象
- 组织测试步骤 明确测试预期
- 组织管理测试数据
更抽象一些，自动化测试的核心是解决并组织以下3个问题：
- 测试对象
- 测试步骤 测试预期
- 测试数据
测试对象我们可以使用一些测试工具来帮我们获取和操作，例如watir， selenium， QTP等。当然，我们也可以自己写工具来达到这一目的。
测试步骤和测试预期实际上就是测试用例中的一部分。测试步骤指导如何我们一步一步的进行测试；而测试预期告诉我们这个步骤下，正确的结果应该是怎样，这样我们才能发现错误与不符合需求之处。
测试数据也是测试用例中的一部分。我们把它单独拿出来是因为我们有很多的用例实际上数据驱动的用例。比如上面的soso用例，测是否能搜索出腾讯首页和是否能搜索出腾讯微博的步骤是一样的，唯一的区别就是两次的输入数据不同。自动化测试的一个很大优势就在于其能快速敏捷使用不同的数据测试同一场景。而将数据独立出来管理也便于我们以最少的代码实现尽可能多的用例，从而极大的提升了自动化测试的覆盖率。
上面的问题理解了，于是自动化测试框架的概念也就呼之欲出了，是的，就跟这几年志玲姐姐的上围一般。
首先自动化测试框架要解决上述的3个核心问题：测试对象，测试步骤预期、测试数据。
在实现了核心功能以后，再辅以用例组织优化——如使用一些第三方类库组织测试用例，让测试用例更加容易编写、阅读、维护；加上对象的深层管理——如将对象以一定的逻辑组织维护起来，尽量降低由于UI变动而导致的代码修改问题；最后配上友好的报告输出、定时执行、定量执行、持续集成等机制，让框架更加的有血有肉，功能强大。
现在真相大白了，自动化测试框架其实也没有那么神秘，框架的一切都来自于我们的需求，需求驱动框架，框架满足需求。
这时候可能有人要奋起反诘：我勒个去！你说的框架怎么跟百度上google到的说法不一样？
其实答案很简单，不要拘泥于那些个看似公理定理般神圣不可侵犯的定义和专业观点，不要以为框架框架就是要被条条框框束缚绑架。一切从需求出发，以需求驱动开发，以需求驱动测试，这样得到的结果比单纯的生搬硬套应该要好得多。
后续我们所分享的内容可能会侧重于测试对象的识别操作，以及测试数据的组织封装和选取。至于测试步骤和预期，这个跟测试业务的业务逻辑密不可分，尽管有些方法可以设计和筛选出最高效适宜的测试步骤，但这并不是本文所关注的知识点。
最后我们再举个例子来实际剖析一下所谓的框架。
我们以某知名自动化测试框架为例：
- 对象识别操作核心：watir提供
- 测试步骤及预期管理：rspec提供
- 测试数据管理：yaml提供
- 测试报告输出：rspec提供
- 持续集成及其他支持：hudson提供
以上这些模块就组成了某知名自动化测试框架。我们很容易可以看出，框架来自需求，由需求驱动。测试技术和测试工具只是框架的一个组成部分而已，不可混为一谈。需求决定框架的开发，而测试工具和测试技术是用来满足需求的描述。所谓的框架，如是而已。
在这里我们对于框架的探寻和思考暂且告一段落。后续我们将深入的了解waitr对象识别和操作的基本及高级技巧。