接口测试 RobotFrameWork 接口分层设计

狂师 · 2017年10月29日 · 2370 次阅读

1. 前言

上一篇文章介绍了在设计接口用例之前应遵守的设计规范，详见《RobotFramework 接口设计规范》，当然读者公司的内部规范也不一定非得完全遵循笔者所提到的，适合自己公司内部的一套就可以了。

由于现在公司新项目的启动和自身负责的开发工作量的增剧，基本上更新文章都只能利用周末零碎时间来写，一个字一个字的码出来的，另外透露一下，下面分享的内容有部分核心思想笔者是将之前发表过的技术专利中的内容开放了一小部分哦，还是有些干货内容值得借鉴的，也希望各位读者多多支持一下。

接下来，我们来聊聊，RobotFramework 接口设计的分层玩法和常用的控制方式。

2. RF 分层推荐玩法

说到分层，大家最容易想到的就是著名的测试金字塔的分层结构，如：

那么 RobotFramework 设计的接口框架分层该怎么来分呢，当然分层的好处和作用笔者就不在这里过多的说了，也不是本文的重点，相信大家也都能体会到。

分层原则: 【分层目标：接口数据和接口业务分离】

可再细分为：

项目目录结构分层
接口数据、接口用例、接口业务分离
公共方法、数据分离

3. 分层实施

3.1、项目结构分离

具体要实施接口自动化的产品项目，一般可作为一个自动化工程的主目录。

其中，项目主目录中，按分层思想，又可根据接口功能分成不同模块，不同模块可作为二级目录。在这里模块可划分成两类，一类为按功能模块，在命名时，以具体功能作为命名，如评论模块，可命名为 Comment，且功能模块主要用来验证某个单一模块下各接口功能上是否符合预期，另一类为模块业务，在命名时，以 Business 命名，所有业务功能验证均存放在此目录下，主要用来验证实现具体业务功能时，各接口的关联组合调用验证，如验证某个视频播放功能时，其中，对于视频播放这一具体的业务来说可能会涉及到很多接口之间的调用，包括接口前置条件，接口之间传递数据，接口数据清理等。

* 项目的功能模块划分以具体的项目而定，在实际的接口自动化项目开展中，需要求开发人员，提供项目接口对接文档。接口测试人员，依据接口对接文档描述，划分具体的功能模块及某个功能模块下包含了哪些具体接口。

3.2、接口业务分离

不同接口模块下，又可根据子功能的不同，划分成不同接口。主要又包含两部分，一部分为接口业务关键字（对应在其它编程语言中，这里所说的关键字，其实就是封装的函数、方法），通常一个接口下，可以根据测试的业务不同，定义多个不同的关键字。另一部分就是接口功能用例，接口用例下仅需填测试数据即可。通常不同的用例存放不同的测试数据，即业务关键字的入参，业务关键字根据接收到不同测试数据而去自动执行对应的业务流程。

* 通常将具体的一组动作序列封装一个业务关键字，测试用例中之所以只存放测试数据的设计核心就是在于将测试业务与测试数据分离。因为通常测试过程中，一个业务关键字的动作序列不会经常变更，需要变更的是测试数据，通常不同的测试数据，会导致业务关键字的产生的结果不同。

3.3、公共方法数据分离

包括三部分，公共方法（Public）、项目配置文件 (Config)、数据构造文件 (xx_var.py)。其中：

公共方法，主要提供各个不同项目接口之间都会调用到的一些公共方法，如数据加密、解密，接口数据校验、接口统计等。
主配置文件，主要存储接口在各个不同环境下（通常一个产品，开发完成后，都需要在测试环境验证通过后，才可发布到线上环境，这里所说的不同环境指的就是测试环境、线上环境）的访问地址，通常做法可在业务关键字编写脚本时，将接口访问地址通过变量来控制，然后此变量访问主配置文件对应的接口地址即可，通常接口环境分定义为测试环境下的接口访问地址、预发布环境接口地址、线上接口环境地址等 (可参照下述截图部分)。
数据构造文件，由于在不同环境下，需要用到的测试数据可能会有所不同，所以可通过构建对应环境下的变量文件来为接口在不同环境下执行时提供测试数据，变量控制文件中主要存储一些可变的变量文件，或通过函数来构造测试数据然后再将构建数据方法返回到具体变量中提供给测试用例或业务关键字使用。

数据控制文件的设计核心在于，在变量文件中定义构造数据的函数方法，然后将方法的返回值赋给一个变量，在具体的接口引用该变量。