Robot Framework实践分享
第一篇：RF实践-账务下一代
近来很多公司都推行DevOps转型，为了达到快速转型的目的项目团队会采用主流的Jenkins持续集成工具，Jenkins支持各种各样的插件，而RobotFramework就是能与之完美结合自动化测试工具。本次将分享如何基于RF来构建一个通用、开源的自动化测试持续集成管理平台解决方案，从而可实现APP、Web、桌面应用、接口、后台等自动化测试，并在Testing in DevOps中展示其威力。
一、关于自动化工具选型
为了满足最终局方系统中台化的目的，BOSS将大部分的后台、接口重新梳理并进行云化改造。改造涉及代码体量巨大且BOSS系统还在线上不断有新业务的扩展，带来了诸多代码合并后的全量回归验证的问题。我想很多传统软件企业都将面临这样的问题。
基于这个大背景下自动化测试势在必行。而选择什么样的自动化测试工具成为了当时最紧迫的问题。选择测试工具，我们考虑的问题：
能否支撑系统的自动化测试？
能否快速建设自动化能力？
能否支持集成DevOps流水线？
1.1 能否支撑系统的自动化测试？
接口测试需满足下述功能：
数据库初始化、同时分发新旧系统的URL、比对乱序的返回报文、剔除正常差异的节点、Oracle、Altibase数据库准确性校验、失败用例的错误信息详细展示、完善的结果报告。
下一代自动化测试示意图
后台测试需满足下述功能：
数据库初始化、启停后台、Oracle、Altibase数据库准确性校验、ftp文件（上传和下载）、文件内容的断言、文件内容和数据库值的比较、完善的结果报告。
1.2 能否快速建设自动化能力？
由于时间和成本的问题，不可能重新开发一套完善的个性化自动化测试系统，时间和成本上面hold不住。
1.3 能否支持集成DevOps流水线？
项目组使用业界比较流行的Jenkins作为持续集成工具，而我们的自动化测试工具就必须能够和Jenkins契合，能够通过Jenkins集成到整个项目管道中。
1.4 自动化工具选型敲定
综合上述3大制约因素的考虑我们逐一淘汰了下述的自动化工具：
LR\QTP
收费！框架沉重！无法定制服务！直接OUT。
现有
工具
当时对现有的自动化工具进行了定制化的改造，服务部分的自动化测试已经支持了，但是由于结果报告、后台自动化、DevOps兼容等问题还是很遗憾的宣告放弃。
最终经过多方调研、Demo制作、多轮评审后对于RobotFramework自动化测试框架的开源、通用、可高度定制化、无缝衔接Jenkins等特点，非常契合当前项目的需求，所以就快速的启用RF作为自动化测试框架的方案。
当时RF框架的建设大概花了3周时间（基于技术人员对于业务非常了解，python、 RF也有一定的开发经验），就已经把整个测试框架建设和评审通过。评审主要是针对功能性、扩展性、复用性进行了两轮的全项目组评审。
二、自动化测试的设计
2.1 三层模式接口自动化
第一层：请求报文模板关键字
第二层：报文测试关键字
第三层：自动化测试用例
三层模式什么好处？
主要是数据和执行分离，提高代码复用率，降低维护成本。
| 2.1.1 第一层：请求报文模板层 |
本层只做请求报文的生成，编写规范就是要将<order_req>下的节点以及accept_id，request_time做参数化处理，后续所有调用该报文的服务都只要调这个模板。
| 2.1.2 第二层：报文测试层 |
本层主要实现：
数据库初始化
调用第一层的报文模板
设置不比对节点
现网和下一代的返回乱序报文比对
精确的检查点设置
3.设置不比对节点
在前面开篇提到目前我们boss的所有接口都做了改造，需要保证下一代BOSS和当前的BOSS业务功能保持不变，要将两套系统的返回报文做一致性校验，而像系统时间节点可能因为两套环境的系统时间不一致，或者返回时长的不同所产生的差异算是正常的情况，所以我们在校验的要剔除这种“合理的差异”。
4. 现网和下一代的返回乱序报文比对
由于无现成的关键字满足本比对需求，所以要扩展一个自定义的比对关键字来完成乱序比对功能。部分的实现代码如下：
5.精确的检查点设置
如果把④比作AOE的范围伤害那么这一步就是ADC的精确物理输出。
通过预设的返回报文节点值：
{'.//order_resp/row/payment_user_id':'591600006909313',
'.//order_resp/row/amount_limited':'10000',
'.//order_resp/row/user_id':'591900006011986'}
和实际报文的返回节点值比对，一致则校验通过，不一致则失败。
| 2.1.3 第三层：测试用例层 |
本层主要实现：
初始化流水和请求时间等个性化的变量，方便后续跟踪日志。
调第二层的接口报文层，这里开始做传参，前面两步都是参数传递，只有在顶层测试用例做参数的传入。
将服务分成查询类和受理类两种，查询类主要检查返回报文（大部分不做数据库更新）。
受理类主要检查数据库（会更新数据库）
现在再来举个简单的例子，来说明三层结构的好处。
缴费业务：
我要给3个类型用户缴费（正常、欠费、不存在），我只需要在测试用例这一层，传用户这个变量的时候把号码换掉就可以了，而不需要从最底层的报文模板开始，这就体现了代码复用。
维护成本：在第二层有个 报文比对关键字，等到我们项目上线以后就不需要做代码比对这一步，那我只需要去改这个关键字，把分发报文改成定向发送，把比对功能剔除就可以了。
2.2 后台测试自动化
后台测试的基本手工测试步骤：
初始化数据库（也可能是put文件、插MQ等等）
登入后台服务器
进入后台启动脚本的路径
执行启动脚本
各种断言（数据库、文件、MQ等）
所以将这些固有套路的测试步骤写成一个单独的后台测试模板，减少测试用例的代码量，提高复用率：
后台测试模板具备了初始化脚本（支持不初始化）、登入主机批量执行shell命令、数据库检查（支持不检查）。
后台的自动化测试用例层调用后台模板并送入本用例需要的参数。
一些个性的处理就可以写在用例上，如上述“天猫对账后台”例子，要对后台生成的对账文件做行数检查，做文件和数据库的一致性检查，这些都属于本后台个性的业务，其他后台用不到，所以这些就单独在用例中编写即可，不需要再集成到服务的模板中。
结语
综上已经完成了账务下一代所需自动化测试的所有功能支持，目前已经完成了100%账务服务和80%的批处理后台自动化测试用例的编写。并且还在持续的编写和优化用例、定时构建和分发结果报告邮件。在后续的Testing In DevOps篇中将介绍如何将搭建好的单机版RF自动化测试框架做快速的版本传播和如何加入项目组的DevOps流水线。
- 待续 -
新大陆软件评测中心
地址：福州市经济开发区儒江大道1号新大陆科技园B楼3层
邮箱：nlsetc@newland.com.cn
电话：0591-8397 9159
专业测试，成就卓越
