【架构研习】欲善其事先利其器-Robot Framework实战演练之框架的选择

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

    以前有提到过，本身曾基于公司业务系统从无到有码过一套测试框架，但因为开发时的思想同时受限于公司业务及框架的适用性上，致使最终虽然框架可完美支持业务，但在易用性、兼容性及可扩展性方面依然存在必定问题，维护成本较高。后有幸结识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在框架或平台各个层级的特色。这里结合通常开展自动化工做的人和事来讲。

1、测试开发阶段：

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

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

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

    测试执行就阶段分能够分为执行阶段和分析阶段。

    执行阶段就是咱们一般说的跑。跑的方式有不少种，能够分为半自动化和全自动化。前者是我有一个自动化测试执行团队，每人负责几台测试机，人为的手动取代码更新到运行库，而后根据这次运行要求，是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符合快速搭建自动化测试框架（平台）的基本要求，也便于咱们快速的开展工做。