Robot Framework在软件接口自动化测试中的研究与应用

赵明明，周静，补冲

（1 咪咕互动娱乐有限公司，南京 210041；2 咪咕音乐有限公司，成都 610000）

在早期的软件开发过程中，测试常常由开发人员自行完成，大家对测试的关注度和重要性认识都不够全面。直到1972年，美国北卡罗来纳大学召开了首届软件测试技术会议之后，软件测试才作为软件工程中的一个重要分支开始逐步发展。1983年，Bill Hetzel在其著作中对软件测试做了定义：“测试是以评价一个程序或者系统属性为目标的任何一种活动”。随着软件系统越来越复杂，软件工程师们普遍意识到，必须要借助工具才能对系统进行快速而充分的测试，同时，伴随着国外很多机构和学者投入大量的研究工作，测试工具开始逐渐受到人们的重视。

软件自动化测试的主要原理是针对测试人员对于手工测试所进行的设计，通过一定的技术方法进行自动化测试程序编写以及运行来达到模拟普通测试人员对软件系统的操作过程，并且对结果进行检。常见的自动化测试方法包括脚本录制回放、数据驱动、关键字驱动。

1 自动化测试工具分类

常见的自动化测试工具包括QTP、RFT、Selenium、Watir、Phoenix Framework、Robot Framework（ 以下简称RF）等。自动化测试工具从功能实现上可以分为两类：一类是提供了可重用的基础自动化测试能力，如Selenium、Watir等，它们可以进行基础的自动化测试，比如打开一个程序，模拟鼠标点击被测对象，最后验证被测对象的属性以判断程序的正确性。另外一类是提供了自动化测试执行和管理的能力，如Phoenix Framework、Robot Framework等，它们本身不具备基础的自动化测试能力，只是用于组织、管理和执行那些独立的自动化测试用例，测试完成后统计测试结果，这类工具往往可以集成多个提供基础自动化测试能力的工具，以满足不同类型的自动化需求，使用较灵活，可扩展性也更强。

Robot Framework最初是由Nokia Networks公司开发的一个开源自动化测试框架，框架基于Python语言实现，包含丰富的测试工具及测试库，同时具有很强的扩展性。RF框架通过集成不同的测试工具，可以进行各种自动化测试，如Web自动化测试、Http接口自动化测试、移动App的自动化测试等。

2 软件接口自动化测试的重要性

分层的自动化测试倡导在产品的不同阶段（层次）都需要开展自动化测试，并且不同阶段的投入比重有所不同。如Google的产品，70%的自动化投入为单元测试，20%为接口测试，10%为UI层的自动化测试。因为越往上层，开展自动化测试的成本越高，相反，越是底层的自动化，收益却越高。

不同阶段的测试关注点不同，UI层关注的是页面展示逻辑及页面前端与服务端的集成验证，而服务层的接口测试更关注系统整体业务逻辑实现的验证，相对于UI层自动化，服务层的接口测试自动化更加稳定，测试用例也更容易维护。因此，项目在开展自动化测试过程中，接口自动化测试投入更多的人力，是重要而明智的。

3 RF在软件接口自动化测试中的应用

3.1 自动化工程结构及测试词库的封装

RIDE是Robot Framework提供的自动化脚本管理工具，通过RIDE可以创建或导入自动化工程、创建资源文件、创建测试套、编辑调试自动化脚本、查看脚本执行日志等。如图1左侧展示的AutoTestProject是我们某个项目的自动化工程，工程根目录下的TestCases、Keywords和Resources目录分别用于存放测试套、测试词库资源文件、变量类资源文件。按照被测系统的特性，测试人员可以在TestCases目录下新建多个子目录，分别存放不同特性对应的测试套。

根据不同的自动化需求，测试人员在Keywords目录下分别创建资源文件，用于保存不同类型的上层关键字，这类资源文件我们称为词库，如Http请求词库、Redis操作词库、Kafka操作词库、数据库操作词库等，如图1所示。每个词库分别引用相关的开源扩展库或自定义库，独立管理和维护。词库中的关键字由多个内置库或扩展库或自定义库中的底层关键字组合而成，如图1右侧展示的是数据库操作词库中数据库校验关键字的构成，这类满足RF语法由底层关键字组合而成的关键字我们称为上层关键字。在项目自动化实施过程中，底层自定义关键字的开发和上层关键字的封装，都由具备一定代码基础的测试开发人员完成，普通的测试人员只需要了解上层关键字的用法，即可完成自动化脚本的写作。

3.2 数据驱动的自动化脚本实现

图1 自动化工程结构及测试词库关键字的构成

开展接口自动化测试的过程中，一个接口往往定义一个测试套（由一组自动化脚本构成），测试套下包含该接口所有的自动化脚本。由于接口的测试报文结构基本是固定的，不同的脚本往往只是修改报文中某个或某几个参数的值，如果在每个脚本中都带上测试报文，就会造成数据冗余、维护成本高的问题，尤其在报文结构复杂，脚本数量多的情况下格外突出。为此，我们的自动化脚本在实现上使用数据驱动的模式，将脚本与测试报文分离。首先，在测试套同级目录下保存一个.conf后缀的文本文件，文件中保存一条完整的测试报文，自动化脚本先从该文件中读取报文，再根据需要修改报文中某个或某几个字段的值，然后将请求发送给被测系统并进行结果校验。图2左侧展示的是一个脚本示例，其中${Req_Data_File}变量指向了.conf后缀的文件，我们建议将其定义为测试套变量，变量值使用RF的内置变量，例如${CURDIR}${/}订单查询接口.conf，可以自动适配Windows和Linux操作系统。

3.3 接口参数校验场景的自动化脚本实现

接口测试存在很多参数校验的场景，例如字段为空、字段超长、字段取值错误等，这类脚本往往占据全部自动化脚本的50%以上。而参数校验类的测试用例或自动化脚本步骤基本一致，唯一的区别就是响应结果中错误码和错误提示的差异，鉴于此，我们对参数校验类的测试用例和自动化脚本的写作方法进行了优化。

测试用例的设计阶段，针对某个接口各种参数校验的场景，整合为一个测试用例。针对该测试用例，在测试套同级目录下新增.error后缀的文本文件。有多少个参数校验场景，该文件就包含多少行，每行的第一列表示要校验的场景，如appId为空、appId取值错误、报文缺少appId等，如涉及多个参数的校验，使用英文逗号隔开，校验参数使用JsonPath语法描述，例如$.appId：100001，$.userId：20001，从第二列开始表示该场景下要校验的内容，例如错误码、错误提示等，多列之间使用tab键分隔。

自动化脚本写作阶段，首先从.conf后缀的文件中获取一条测试报文，然后循环从.error文件中获取要校验的场景，解析后替换到报文中，并发送请求到被测系统，最后进行错误码、错误提示等的校验。经过关键字封装，最终的自动化脚本仅包含图2右侧展示的两个步骤。从项目实施经验看，经过以上优化，接口自动化脚本的数量可以减少50%以上，不仅提升了脚本写作效率，也降低了测试人员后期维护自动化脚本的工作量。

3.4 自动化脚本与测试环境的解耦

产品迭代开发过程中，可能会有多套被测环境，如果自动化脚本不进行相关约束，那么切换被测环境必然会导致大量的脚本执行失败，此时又需要投入测试人力修改脚本，这个问题经常会影响到项目自动化测试开展的及时性。为此，我们采用以下方法，解决了切换被测环境引起的脚本修改问题。

在项目自动化脚本写作过程中，和被测环境相关的信息，必须全部定义为变量，存放在资源文件中，自动化脚本引用资源文件中定义的变量，不能直接使用被测环境的信息。如针对服务端URL地址，我们会定义变量 ${G_URL}=http：//10.138.10.10：8080， 自 动 化脚本发送请求关键字的参数必须使用${G_URL}变量，不能写死http：//10.138.10.10：8080。由于可能存在多套被测环境，因此，我们在Resources目录下新建多个资源文件，如Test_Env_Alpha.robot、Test_Env_Beta.robot、Test_Env_Gamma.robot，分别代表不同的测试环境，如图1所示，这些文件中存放自动化脚本中引用的与被测环境相关的变量，其中变量名完全一致，区别在于变量值不同。最后我们新增资源文件Test_Env_Cur.robot，该文件引用当前生效的被测环境资源文件，如Test_Env_Alpha.robot，所有的测试套都引用Test_Env_Cur.robot，经过以上处理，如果需要切换测试环境，仅需要修改Test_Env_Cur.robot文件中引用的资源文件名即可，自动化脚本不需要做任何修改，实现了自动化脚本与测试环境的解耦。

图2 数据驱动的自动化脚本实现及接口参数校验脚本实现

3.5 测试用例与自动化脚本的互相转换

很多公司都有自己的测试用例管理系统，支持Excel文档的导入导出。产品迭代开发过程中，测试人员往往都是根据需求先梳理Excel格式的测试用例，然后导入用例管理系统，最后根据测试用例描述，完成自动化脚本的写作。

为了提升自动化脚本的写作效率，我们对RIDE工具做了定制开发，支持将Excel格式的测试用例与自动化脚本互相转换。如图3所示，Tools菜单下新增了Convert Excel To Test Suite功能，单击后选择某个测试用例Excel文档，工具会按照Excel文档的目录结构自动生成同样目录结构的测试套文件，并将测试用例名称、编号、测试步骤等信息写入自动化脚本的Documentation部分，测试人员只需要添加脚本步骤即可完成自动化脚本的写作，省去了很多从测试用例文档到测试套的复制粘贴工作。

相反的，只要测试人员按照规范要求，在自动化脚本的Documentation中写入用例名称、编号、测试步骤等信息，右键自动化工程的TestCases目录或其子目录，然后选择Convert to Test Case，就可以将选中目录下的测试套转换为Excel格式的测试用例文档，如图3所示，转换生成的文档可直接导入测试用例管理系统。

测试用例转换为测试套的功能，一定程度上提升了自动化脚本的写作效率；测试套转换为测试用例的功能，用于自动化脚本先于测试用例之前完成，可以由自动化脚本转换生成一份测试用例，方便后续测试用例的管理和维护。

3.6 自动化脚本规范问题静态检查

为了提升RF自动化脚本的质量，我们会要求测试人员按照规范写作自动化脚本，但是，由于人员能力参差不齐，对规范的掌握程度也不尽相同，所以测试人员输出的自动化脚本往往需要经过多次评审和优化才能达到要求。为了提早发现脚本规范问题、提升脚本评审的效率，我们将一些常见的脚本问题归类，开发了相应的规范检查工具，用于自动识别脚本中存在的问题。测试人员在提交脚本前，先主动执行静态检查，就可以提前识别出一些不符合规范的问题并加以修改。

图3 测试用例与自动化脚本的互相转换

图4 自动化脚本静态检查工具及报告

检查规则分为强制和建议两种，目前实现的如图4所示的8条，其中每条检查规则都对应一条脚本写作规范。如我们的规范要求自动化脚本不能使用Sleep关键字进行强制等待（除非有特殊的业务要求），规则2会扫描所有的测试套文件，识别出使用了Sleep关键字的脚本步骤；规范要求自动化脚本必须包含结果校验，规则4会扫描所有的测试套文件，识别出缺少结果校验步骤的自动化脚本。最后，检查工具会按照规则输出问题统计报告，并给出详细的问题位置及文件路径。从项目实施经验看，检查工具使用前期会发现很多问题，如图4是我们一个项目第一次扫描的结果，上千个同类问题，如果依赖人工评审，需要耗费的时间难以估量，随着脚本的不断优化及测试人员对规范的掌握，相关问题会越来越少。这些检查规则的自动化可以有效牵引测试人员提升自动化脚本的质量，我们也在积极扩展实现其它的检查规则，进而不断提升团队的测试效率。

4 结束语

Robot Framework是一个开源的自动化测试框架，基于关键字驱动，使用灵活，可扩展性良好。经过我们的优化，该框架既具备关键字驱动的灵活性和可重用性，又具备数据驱动框架的低耦合，很大程度的降低了开展自动化测试的成本投入。从真实的项目实施情况看，接口自动化覆盖率可以达到100%，在小步快跑、快速迭代的大趋势下，可以有效缩短回归测试时长，提升自动化测试的价值，本文所阐述的方法很值得在相关软件测试领域推广使用。