在搭建Robot Framework环境之前，先对Robot Framework进行扫盲。
Robot Framework是个通用的自动化测试框架，那什么是自动化测试框架呢？
如果你已经对自动化测试有了一些经验，例如使用了一些其他的自动化工具，那你可能可以安全的掠过这一部分了，否则我更想从一个简短的相关问题谈起：什么是自动化测试？它和手工执行的测试有什么区别呢？Micheal Bolton写的一篇博客给出了非常好的答案，我们可以把它概括成下面这句话：
检查是机器就能干的，测试需要人的智慧。
请注意，在后续讨论自动化测试的时候，我们仍将使用“检查”和“测试”这两个术语。
让我们来看一些保险公司的评价引擎这样的具体例子。他们都会对特定的输入参数（数字）进行计算。这显然是一个好的例子，当我们知道算法的时候，我们可以做很多“检查”，而判别算法本身是否正确和明显的需要人的智慧！
假设我们有一个基于一些数据库表和批处理程序的接口：向一张表插入数据，执行算法，并且在另一张表查看结果。
现在我们需要一些基本的测试脚本来开始工作（依据人们的偏好，实现的形式可能是Shell、Perl、Java或者其他任意形式）。另外，我们还需要一些基本的测试功能。访问数据库表，执行另一个脚本，以某种报表的形式返回结果。完成这些后，我们可以同样开始实现我们的检查了。现在我们基本上一家说出来一个典型的自动化框架需要提供的组件。
上图画的是一个非常简单的自动化测试框架。一个能够执行测试脚本的核心系统（a core system），核心系统还可以做一些报表工作，可以提供一个把自定义的测试功能插入的接口。新功能加入的相关工作越简单越好。当然这会引发一个基本问题：当使用一个特定测试框架时，我该使用哪种语言实现我的测试功能（插件）呢？我将会在后面详细的回答这个问题，但是现在我们可以说Robot Framework的架构允许大家使用多种语言来实现。在我们能够深入讲解Robot Framework的架构之前，我们必须先讨论一个Robot Framework相关的核心术语：关键字驱动测试。
什么是关键字驱动测试？
每当我试着解释什么是关键字时，我把它比作一个能够测试（或者帮助测试）被测物（SUT，我们把被测物叫做真正酷和真正给力的事情是：我们能够用一些关键字实现另一些关键字。这是我们经常谈论的）
- 高阶关键字：测试被测物的业务逻辑。
- 低阶关键字：在一个合适的粒度实现高阶关键字，高阶关键字通常把功能分解成一些低阶关键字。
- 技术关键字：提供技术层面的实现（访问并且测试被测系统）
下面的图通过一个例子描绘了关键字分层：
典型的技术关键字可以用几乎所有编程语言来实现。其他类型的关键字用已有关键字的组合形式来实现。虽然在本章我们更加关注抽象的部分，让我们来看看一些关键字实际的定义方式。
上表展示了Google Search这个关键字是如何定义的：使用了Selenium Library。这告诉我们，在被叫做测试库（Test Libraries）的东西里已经有了很多被预先定义好的关键字，这就引出了我们开始要说的话题：我们终于说到了对Robot Framework的概述，当你安装Robot Framework后，你得到了核心框架和随安装包绑定的的一系列标准库。
除了标准库还有很多外部扩展库可用，这些库通常都是Robot Framework社区贡献的，它们能够实现特定的功能。关于这些库的一个非常棒的地方是，你可以把不同库中的关键字进行混用来定义你自己的关键字或者编写特定用例。因此你可以很容易的使用Selenimu Library中的关键字来实现对web的远端操作，同时使用Database Library来查看web操作对数据库造成的影响。在理想状态下，这些都能够通过组合现有关键字而不用编写真正的代码来实现。
除了核心功能和测试库以外，Robot Framework还提供了一个图形用户界面，叫做RIDE。RIDE能够帮助你很好的编辑和管理用例、保存关键字的资源文件等。请注意在RIDE里不能编辑测试库中的技术关键字，技术关键字使用高级语言如java（可以依据你的喜好使用eclipse或者其他IDE）编写。
Robot Framework的主要构成
- 测试组件（Testsuite）：测试用例被实现的地方。每个工程都会有至少一个测试组件，在大一些的工程中，把不同功能点的测试切分成多个测试组件是合理的。
- 资源文件：在测试组件中定义一些高阶关键字，把这些关键字定义到一些外部文件中，这些文件就是资源文件。从测试设计的角度来分析，人们总是需要定义高阶关键字，额就是人们基本上会使用资源文件。特别是在产品研发过程中，或者在一些生命周期比较长的项目中，针对产品或者项目开发一些能够被整个团队复用的高阶关键字是很方便的。
- 测试库：一般是不用写新的技术关键字的，这需要编写新的测试库来实现，除非正在使用一些非常特殊的技术，编写新测试库的可能性是存在的，但也不会太复杂。
注：无论关键字是在测试库层面由编程语言实现还是使用现有关键字组合成，使用的时候都不会有什么区别。
使用哪种语言来实现测试功能呢？
Robot Framework本身和它的核心功能是使用Python编写的，如果你熟悉Pyhon，最好使用它来编写你的测试库，但如果Robot Framework仅限于此，那它是不成功的。于是就有了Jython。通过Jython，我们可以在Java虚拟机上跑Python代码。这就让我们能够使用Java或者任何能够被编译成Java字节码的语言来编写测试库。
Robot Framework是从上图左侧（没有RIDE）的安装栈演进过来的。如果你需要Java支持，使用左侧栈也没有问题，这些类型的安装都比较麻烦。
这个问题造就了Robot Framework的Jar安装模式。所有相关内容都被打进Jar包，你所需要的Python编写的测试库和Jython也被打到Jar包里（Java编写的测试库可以通过设置classpath添加）。这样做的已非常大的好处就是你既能把这个Jar包放到你的源代码管理器上又能把它放到本地的Maven私服上去。这种方式能够保证所有团队成员都使用同一个版本的Robot Framework，同是安装和升级非常方便。
但是它也有坏处，在Jar包模式下，RIDE无法给出关键字提示（因为它们被包在Jar包里了），当然RIDE你还得单独安装。
远程库（Remote Library）
我们已经大致了解了本地或者Server安装的Robot Framework，安装的内容全部在一台物理机上。现在讲一种使用Python，Jython甚至纯Java启动Robot Framework的方法。
Remote库允许我们使用所有支持XML-RPC协议的语言编写测试库，并且能够按需在不同的机器上运行它们。
使用Remote库和使用普通测试库没有什么区别，只是在它们引用到测试用例文件或在资源文件的时候有所不同另一个很大的优点是RIDE全面支持这项特性，并且能够从远程库获取文档（显示帮助时用）。如果你想看看远程库是怎么实现的，你能从Database Library的源码中找到答案。远程库本身是现有测试库的一个增强（它本身不实现什么功能，它的作用是提供了让本地库远程执行的能力）
Remote库当做一个远程服务器启动，Robot Framework这时候更像一个客户端。当然你可以在本地运行所有的库。
关于持续集成
把Robot Framework整合到持续集成服务器非常简单，因为Robot Framework的核心系统就是脚本文件实现的。Java版本的也可以用Maven整合。如果你使用Jenkins，Robot Framework也有一个Robot Framework PlugIn。