IBM Rational Robot实际是一个套件， 在安装Robot后会有两个运行程序， 一个是开发脚本的Robot， 另一个是运行脚本的TestManager.

Robot是以前瀑布型开发的产物. 该工具的假设是Robot只上在软件产品的后期由专门的测试人员对软件产品进行测试， 因此测试脚本语言是Visual Basic.  此外，虽然RUP提出要进行迭代化开发， 要尽早测试. 但由于Robot开发的脚本是存储在专门的存储库中(也就是Rational Test Project)， 很难进行版本管理， 而尽早测试必然要求对脚本进行版本管理， 所以尽早测试这个最佳实践很难通过Robot来落实.

总结来看， Robot做功能测试面临如下不足:
1. Robot采用专业的测试脚本语言， 从而导致需要学习专门的API以及专门的语法外， 用过程化的Visual Basic作为脚本语言， 导致脚本重用受到很大限制.
2. Robot和测试管理工具耦合太紧， 不能对脚本进行很好的版本管理， 也无法进行灵活的测试执行.
3. Robot不能和IDE集成， 这样导致开发人员不想学. 测试自动化技术不是只能由专业的测试人员才能用.
4. Robot在识别非标准控件上扩展能力不强， 导致Robot的使用范围受到限制.

基于上述不足， IBM Rational决定在全新的架构上开发Functional Tester. Functional Tester具有如下特点:
1. 采用Java或VB .NET作为测试脚本语言， 避免学习新语言的成本. 而且测试人员在学习了RFT后， 可平滑过度到承担软件开发工作.
2. 直接嵌在Eclipse以及Visual Studio .NET中， 这样开发人员也可以开发自动化测试脚本.
3. 测试脚本基于文件系统， 容易进行版本控制
4. 和测试管理工具耦合低， 可实现灵活的测试执行策略.
5. 提供对非标准控件的扩展编程接口.

因此， 进行自动化测试， Functional Tester是一个更好的选择.