写在前面的话
自动化测试是什么时候开始火的？已经记不清了，只记得08年毕业的时候，QTP和load runner就已经成为了各大民间测试培训组织的必备课，学员们装着盗版的QTP，LoadRunner，在课堂上一遍又一遍虐待着百度的搜索框，然后感觉自己棒棒哒，出了学校，发现实际用到自动化测试的公司并不多。说这话可能有人要捡砖头开拍，北上广深杭这些大地方笔者真的没去工作过，不敢说人家那边自动化测试在行业内的推广最早是什么时候，当时又到了何种程度，只是在作者工作的这个地方，自动化测试时至今日依旧是一个尴尬的存在，抱怨几句，大家都在一股脑的推自动化，可是什么样的项目适用自动化，要用在测试哪个阶段，用到何种程度，却依旧没有个行业标准。大多数的人只看到了自动化测试可以减少人工，就吵着嚷着说自己也要用自动化，说我们是敏捷团队，能让项目加速的都是我们要做的，何其可笑，还是暂且打住这个话题。
闲来看了看当前测试工程师招聘的JD，发现很多公司已经把“能独立搭建并应用自动化测试框架”作为招聘需求。墙里墙外扒拉了一下，发现了RobotFrameWork这个东西，看了一个礼拜大概弄清楚了一点，寻思着就把弄清楚的这一点点先写出来，给同样是菜鸟的少年们看看，也是给自己留个记录。
翻了翻网上关于RobotFrameWork的文章，大部分内容套路都差不多，根据我这几天的研究成果，这次我们直接写个基于测试实例代码分析的RobotFrameWork学习。这个系列的文章我不打算按照正常的套路从安装讲起到如何应用结束，相反，咱们先来看看测试实例，再分析代码，最后看看安装过程。如果看完第一篇，感觉有兴趣，再往下看，没有兴趣就直接看别的就好啦。
闲话不多说了，我们开始。
Robot Framework 是一款由Nokia公司开发，使用Python编写的功能自动化测试框架。凭借其良好的可扩展性，在引入各种资源包后，可用于web功能自动化测试，接口测试，手机app自动化测试，windows app测试以及数据库自动化测试等。相较于其他自动化测试框架，Robot Framework 的最大优势在于：
完美地将底层大部分操作代码封装成关键字，最重要的是支持使用变量，循环，以及if else逻辑判断。同时，在依旧无法满足测试需求的情况下，支持将多个系统内建的关键字再次封装为用户自定义关键字。
语法类似自然语言，对于code要求极低，直接使用文本文件作为测试用例。使测试人员将更多地精力放在测试逻辑上。
良好的测试文档管理结构，包括测试用例管理（分类，有选择地执行），资源统一存放等。同时HTML格式的测试报告具有良好的可读性。
本文一改其他框架介绍文章的结构，不从安装开始，而是借助一个简单的测试实例，通过对测试用例的分析来对robot framwork+selenium2library框架在测试中的应用进行一个初步介绍，在读者感觉此框架真正有用之后，再进行安装，使用的具体介绍。
测试实例的介绍
“…一次一次地折磨Baidu的id=kw,su,你考虑过它们的感受么？”
我们这次的待测系统是Orelly 在线图书馆
业务需求如下：
注册页面的input box未填写时，点击注册按钮，每个文本框下方会出现错误提示信息
当输入任何信息后，红色的错误提示信息会消失
Email地址栏输入的验证
a. 单独字母数字特殊符号无法通过
b. 字符+@无法通过验证
c. @+字符无法通过验证
d. 字符+除@外其他特殊字符+字符无法通过验证
e. 正常的邮件地址可通过验证通过何种渠道了解到本站”的拉列表值符合预定义值
成功注册的happy flow
下面让我们来看一下要实现对上述5点需求的功能自动化测试，RFS的代码量是多少。
首先来看编写RFS自动化测试代码的UI IDE工具 –RIDE，使用RIDE可以极大的增加代码编写效率，同时也可以避免使用命令行的形式来运行测试用例。
由图中我们可以看出，整个Demo由一个包括4条测试用例的testsuite以及一个资源管理文件 resource.robot组成。
首先我们看测试用例的代码。在RIDE中，Test Suite是一个虚拟的套件，切换到测试代码Tab后我们发现，所有功能的测试代码只有区区60行出头：
我们再来看resource资源管理文件的代码量
我们在资源文件中，引入了几个常用的测试库及工具库，并且对待测网址，测试浏览器，无效的Email Address地址以及下拉列表期待值进行了变量化的封装，全部代码也只有15行。
结束~
的确，如果是一个刚刚接触自动化测试的新手，通过这简单的不到100行代码，就可以完成多个需求的测试，如果使用原始的selenium+python代码，即使有一定的经验，提前把webdriver.Chrome(),driver.get(“Http://www.xxxxx.com”)， driver.getElementBy()等方法进行封装，然后再在测试用例中进行调用，代码量也会远超100行，更别提这其中涉及到的下拉列表取值和对比。
最后我们来看一下全部执行完成后的测试报告以及自定义关键步骤的截图：
- 测试运行Log
随着测试用例的执行，RIDE本身会在控制台打印出各个用例的log情况，方便追踪报错以及测试失败情况。在控制台log的最下方，打印出了测试报告，测试long存放的地方。
- 测试报告
测试运行完成后，由于我们没有设置制定的报告存放地址，报告默认存在[User]/AppData/Local/Temp/路径下。打开文件夹，我们发现里面有5个文件：
a. geckodriver.log， 这个是selenium以及浏览器运行时的log，与我们这次要介绍的内容没有关系，暂时忽略
b. argfile.txt，储存了log文件夹的存放的地址，暂时忽略
c. Output.xml – RFS运行完成后，将整个测试的详细流程，包括具体的操作以及使用的变量等和对应操作的结果，在这个XML文件中展现。当测试体量不断增大，需要使用分布式执行测试的模式时，可以采用工具将每个子节点测试机器的output.xml合并起来，得到一个总体，详细的测试结果，这样的文档型测试结果也方便用户保存及使用版本控制工具来管理测试结果。
d. report.html | log.html – 这两个HTML文件就是整个测试最终的报告。在report.html中，对当前测试进行了总结，并给出了各种统计结果。
在这里我们可以按照用例的分类，标签的分类， 套件的分类等进行筛选，然后通过点击链接进入对应的详细log查看
e. 最后，我们来看一下测试的截图。在代码中，我们指定了截图保存的地址是测试代码文件夹，打开对应的文件夹，我们可以看到2张截图已经成功保存到这里，对应的文件名分别为：
name = input_all_info_3.jpg / signup_successful_2.jpg
本次介绍的第一部分就结束了，在接下来的部分我们会具体分析这个测试实例的代码，来展示RFS在自动化测试过程中的高效，便捷。
