（原创文章，转载请注明出处。）

之前有提到过，自己曾基于公司业务系统从无到有码过一套测试框架，但由于开发时的思想同时受限于公司业务及框架的适用性上，导致最终虽然框架可完美支持业务，但在易用性、兼容性及可扩展性方面依然存在一定问题，维护成本较高。后有幸结识 RF，甚为喜欢。

为什么呢?

这就要从框架本身说起。关于对测试框架的认识，其实可大可小，各人理解不一。比如说如 Junit 等 xxUnit 系列，可以说是单元测试的框架，以白盒的方式调函数，调模块，加 setup、加 assert，覆盖代码段的功能，可以在代码层面做任何测试，但不太会用它做接口的联调或业务的串联测试。如 TestNG+xxx 等，偏向于用例及流程的控制，TestNG 本身并不调用业务逻辑。相对全一点的，早期如 Rational 系列，从 CQ 到 TM 再到 Rational Robot，覆盖从需求到测试再到测试管理，但实在是太重。后期如大家最熟知的 QC+QTP／LR，全开发流程串联，功能强大，但同样的问题，一是略重，二是要用你的业务系统去适应 QTP，当然用的好的话可以直接自己写测试 agent 作为第三方测试工具连 QC，但除了调用接口要跟 QC 完美契合外，Report 也用适应 QC 本身的报表，需要人力成本。再者 QC 的二次开发难度较大（ps:有需要的可以找我），需大量时间做研究实践。

那我们来谈谈 RF 在框架或平台各个层级的特点。这里结合一般开展自动化工作的人和事来说。

一、测试开发阶段：

我们一点点展开说。测试开发，指的是测试脚本的开发工作。可以用纯语言写，如 Java、Py 等，用 VB6 写个连接程序也能放 QC 上跑。也可以用工具，采用半写半录的方式，直接用 QTP 或 Rational Robot 去跑。但不管用任种方式，我们都会需要或者说在逐步演进的过程中都会意识到需要以下几点内容：一、要有一个便于开发者使用的 IDE。RF 的 IDE，有 RIDE 或者 PyCharm 的插件，界面几户无异，均比较容易上手。二、需要有核心库或者公共库的概念。好比自己写代码会写 Lib，用 QTP 会写 vbs 核心库等。RF 中有 Library 和 Resource 的概念，既可引用开源库，也可以封装核心的业务动作。一般一个自动化团队会有 1-2 名成员去维护核心库代码，负责控制代码的 check in。其他若干人员负责脚本的设计或业务流的串联。一旦形成，任何接口的变动或更新，只需要更新核心库的代码即可，无须逐个更新脚本。三、数据驱动、关键字驱动、数据代码分离。KWD 是很早就有的概念，大多数商用工具里都支持数据的剥离，RF 同样可以实现。虽然 RF 同样支持诸如同一个用例跑一个数据文件，逐一跑文件中包含的三组不同的数据，但如何把这样的模式应用到测试场景中，如何通过好的布局将关键字驱动及数据驱动相结合，并将各个独立的验证点加入进去才是需要不断思考和优化的地方。四、快速对接待测业务接口或识别界面元素。好比 Jmeter 内置了 http 协议，所以大家习惯用它做页面压力测试。RF 可以快速 pip 相关的 Library，可以兼容各类接口，几乎涵盖各类协议及前后台。另外 Lib 里还附带了各类操作，甚至直接调用 python 语句，非常方便。 五、快速形成业务逻辑测试脚本。当代码实现了各种接口调用、界面元素调用，并参数化和抽象后，需要思考自动化脚本开发人员如何快速的将之整合形成业务逻辑。RF 可以通过简单的拖拽形成业务逻辑。但之前说的脚本开发人员不是一个人，而是很多人，所以在应用工具的同时还必须建立规范。设计完善加之管理适当的话，以上提到的脚本设计人员其实不需要过多的接触代码，只需要编排关键字，然后改改数据就可以形成可用的业务逻辑了。六、代码、数据版本管理。由于 RF 脚本本身是 txt 的，所以可以利用 Git 或 SVN 做版本控制。IDE 本身也包含相关插件。

二、测试执行（运维）阶段：

测试脚本完成业务串联并调试通过后，会打上版本标签，并从开发库转移到执行库，就此正式开始测试执行工作。我们的讨论会就测试执行定义一些分类，以便展开说。

测试执行就阶段分可以分为执行阶段和分析阶段。

执行阶段就是我们通常说的跑。跑的方式有很多种，可以分为半自动化和全自动化。前者是我有一个自动化测试执行团队，每人负责几台测试机，人为的手动取代码更新到运行库，然后根据此次运行要求，是 full 还是 sanity，框一个范围，每人分几台机器去跑。后者是我有一个自动化测试平台，在平台上勾选我要的范围，平台自动 allocate 机器并 assign 用例，运行过程中还会做 load balance。对于第一种方式，RF 的 RIDE 本身就可以建多层次的文件夹及测试集，可以构建出业务模块，在任何一台测试机上均可以 git 到代码并点选相关模块去运行。对于第二种方式，刚接触 RF，暂时还没有看到现成的开源代码，但还是可以通过用 remoting 调用 agent 的方式并做简单的控制实现，但这还都是老套路。如果能实现第二种模式，那恭喜你，你基本已经实现了自动化测试从脚本化到框架化再到平台化的演进了，不考虑实际效能的话，已经可以说是圆满了，但如果要走出最后一步产品化，要有很多额外的事要做，这里暂时就不细说了。脚本触发的方式也有很多种，可以分为手动和自动。利用 RF 自带的 pybot，可以通过命令行直接调用项目层级、测试集层级，可以轻易的植入 Jenkins 作为冒烟测试。

分析阶段其实是最花时间的。为了提高效率，需要考虑以下几点。首先需要有详尽的 Log，并且 Log level 是可调的。RF 包含了 None、Debug、Trace 等多个层级。Trace 层级，可以看到所有变量的值，并追溯到具体的报错内容，十分详尽。其次是清晰的测试报告。RF 的测试报告也是分层级的，可以通过一层层点击定位问题，比较方便。并且可以通过简单的设置，保存每次运行的结果，便于日后查验。但即使如上述种种，跟业务相关的排错还是需要有经验的人去做，快速定位问题。

由此可见，RF 符合快速搭建自动化测试框架（平台）的基本要求，也便于我们快速的开展工作。