RFS的web自动化验收测试——第15讲 RF结合Jenkins（下）
引言：什么是RFS——RobotFramework+Selenium2library，本系列主要介绍web自动化验收测试方面。
（ @齐涛-道长 新浪微博）
我搞了个RobotFramework自动化测试公众号
欢迎大家扫一下加入。
这里有最新的安装指南，本文里的版本都比较旧了。
前面一篇已经介绍了怎样从头搭建Jenkins并能够和RF结合起来运行我们的自动化测试案例。
不过在前一篇主要是为了快速搭建，所以省略了部分内容，这一篇把一些遗漏的内容介绍一下。
构建的含义：感觉不需要我解释太多吧，就当作是运行了一次Job就行了，对于开发Job的构建一般是进行了一次代码的打包、编译、部署，对于RF的Job的构建，就是运行了一次RF自动化测试案例。
原本打算弄个master+slave的图，后来实在懒得画了，就是一个master为中心，很多slave连上来，大家自行脑补一下吧
一、slave机器的配置
你可以用物理机或者虚拟机来布置你的slave执行机，用来执行RF自动化案例的机器需要安装或配置以下内容：
1、Java环境，用来启动slave连接Jenkins
2、RF环境，和博客置顶里的一样，也就是和你本机执行的环境一样即可。如果本地安装了什么测试库，要在slave上安装相同的测试库，因为实际执行就是在slave上调用pybot.bat来执行的，所以如果漏了安装某个测试库，可能会导致案例执行失败。
3、修改RF的编码，还记得我以前提过的修改编码将cp437改成cp936么？如果不修改的话，有可能会出现控制台输出的页面看不到中文，可能是一堆????
二、多配置项目
前面介绍的Job是自由风格的项目，那么有些情况下可能也需要多配置项目，那么我介绍一下他和自由风格有什么不同。
1、配置不同
首先是指定标签的Restrict where this project can be run没有了，取而代之的是Configuration Matrix
点击Add axis有几个选项，通常前2个就够用了，第3个我也没用过。
第一个Label expression是输入Label的表达式，和自由风格的Restrict类似。
第二个Slaves比较省事：
这里面有Labels和nodes两种选择。
Labels就是我们之前建立节点时添加的标签，如果多个slave都有同样的Label，那么他们就是一个group了。
这种比较适合有多个Job在多台slave上执行的情况，因为如果指定具体的一个slave会出现抢占资源的情况，而指定一个group的话，那么资源会按空闲进行合理分配。
例如：我在管理部门内的十几台机器就是这样来分配的，每个测试组的机器都有单独的标签，整体上所有的机器也有统一的标签，这样在后续调用的时候可以根据情况合理分配。
Individual nodes其实就是节点管理里的那些节点，大家可以自己点进去看。
2、显示执行结果不同
选多配置项目和自由风格的差别除了在配置选slave标签的差别，另外就是显示执行结果上的差别了。
我先选1个标签slaveA来执行一下。
a、在Jenkins首页可以看到，多配置项目的Robot Results是空的
b、在Job的首页也没有RF的结果
因为我只配置了一个标签，所以只显示了default，点击default就能看到默认配置的运行结果。
如果设置了多个标签，那么在首页就能看到每个配置的链接。（我后加了个master，但是没运行案例，所以是灰色）
点击slaveA进去看看，这样才是自由风格那种Job首页的显示：
以上就是多配置和自由风格的差异，大家自己选择。
三、其他有用的Job配置
1、丢弃旧的构建
勾选丢弃旧的构建，有几个选项选择，如图：
保持构建的天数：每个构建能保留多少天
保持构建的最大个数：最多保留多少个构建
这样可以降低一些master的存储和Job的构建历史记录，根据自己需要进行设定吧。
2、源码管理
有很多种源码管理工具可以选择，如果没有的话可以下载相应的插件。下面是默认已有的几种
比较合适的做法是将你的RF案例用svn管理，本地提交更新，然后每次Job运行时从svn下载最新的代码来运行。
RepositoryURL就是你的svn路径，Local module directory就是下载后的本地路径，默认是当前工作目录，也可以自己定义个目录。例如下图：
我的执行命令当然也是用相对路径来写案例：
pybot.bat --test * -v url:http://url -i REGTEST -d .\Result test\testsuite.txt
运行后再看下工作区，会整齐一些。
3、构建触发器
这里也是比较有用的，有几种触发方式：
a、在其他项目构建完成后才执行：这种就是持续集成时比较适合的，前一个Job负责编译部署系统，或者是执行自动化单元测试，然后来驱动当前的RF的Job执行自动化验收测试。
b、给定一个时间表达式，指定什么时间运行。具体可以参考帮助或者百度。
MINUTE HOUR DOM MONTH DOW
| MINUTE | Minutes within the hour (0–59) |
| HOUR | The hour of the day (0–23) |
| DOM | The day of the month (1–31) |
| MONTH | The month (1–12) |
| DOW | The day of the week (0–7) where 0 and 7 are Sunday. |
对于测试来说，基本上前面2个够用了。
4、工作空间workspace
在Job页面的左侧有个链接，工作空间
每次运行的输出结果都会在这里，如果指定了output目录那就可能不在这里了。
RF的插件还有一个作用就是把每次的output文件从slave拷贝到master上，如果以后你的master上空间不够了就要考虑一下是不是每次拷贝过去的文件太多太大了，也可以用丢弃旧的构建清理一下。
清理工作空间也是不错的选择，他主要是清理Slave上的这个Job的workspace。
5、权限管理
我目前做的演示都没有涉及到权限管理，这个具体要看你想做什么样的权限控制，如果公司里用windows的域来管理的，那么可以用Active Directory的进行配置（貌似默认有，如果没有就去下载插件安装）。
在系统管理的系统设置页面，有一个启用安全的选项（第一次设置请在系统管理页面点安全设置）
然后选择AD，配置上你们自己的域控制器的地址就可以了。
你也可以用Jenkins自己的用户数据库，允许用户注册，然后再授权。
但是我其实最想说的是大家要注意下面的授权策略：
这个授权策略如果你想只允许管理员来设置的话，就要启用安全矩阵或项目矩阵授权策略。
切记：保存之前千万不要忘记把自己的用户加入到矩阵里，否则没人能进系统管理了。
这事儿我干过，后来我只能清空Jenkins的所有目录，然后重新搞。
下图的添加用户/组就是给你增加用户权限的，然后记得在矩阵里把该勾选的权限都勾选上。
小提示：这里的用户权限包括项目的用户权限都是大小写敏感的，虽然大小写的用户名都可以登录，但是如果矩阵授权的是小写，那么大写用户登录进来实际上是没有权限的。如果遇到授权用户登录后没有权限操作，极其有可能是这种情况。
实际上Jenkins不仅是持续集成可以用，实际上我们目前在自动化回归测试上也在使用，因为现在公司很关注每日构建（每天跑自动化测试案例）的结果以及回归日的自动化测试结果。而且因为Jenkins平台的开放性，我们并不仅仅是RF的整合，使用其他测试工具也是可以整合进来的，甚至被大家慢慢抛弃的QTP也有Jenkins的插件（我试着用了用，还不错）。
关于RF和Jenkins的融合我就介绍这么多了，基本没有怎么介绍开发的部分，这个不是我的重点了，相信网上也有很多例子，需要了解的朋友可以自己去搜索一下。
希望这部分内容能帮助到大家快速搭建自己的Jenkins服务器，让你的RF自动化测试自己跑起来。也希望在Jenkins上测试人员和开发人员融合的更好~