接口测试 RobotFrameWork 接口设计规范

狂师 · 2017年10月29日 · 最后由 龙俊 回复于 2017年10月30日 · 1589 次阅读

1. 前言

继前面一章《RobotFramework 环境搭建》介绍了在本地如何将接口自动化实施过程所需要的基础环境搭建好,在这里假设大家都已经知道环境如何搭建了,如果不清楚的可直接查看上一章节 RobotFrameWork 环境搭建(基于 HTTP 协议的接口自动化),那么环境一切 ready 了,是不是代表就可以开干了呢?

不急,对于一个 team 在开展这类大工程的时候,要考虑到团队多人协作,如何让自己的东西,别人能更快看懂上手,如何让大家风格保持统一,这里就还需要在真正开始之前,制定一些针对团队达到统一共识的约定或者规范。就好比我相信任何一个较成熟的研发团队,都会有自己内部的一套编码规范如:Java 编码规范、Python 编码规范、JavaScript 编码规范等。

那么接口在开始之前,你觉得需要有哪些规范呢?下面我就介绍一下以前我在公司开展接口项目时,制定的一些针对接口项目的约定规范。(当然不同公司可以根据公司文化、项目差异自行制定,不一定我们的就是最好的,找到一套适合自己的才是关键)

2. 规则细分

那对于开展接口自动化来讲,有哪些地方规范需要注意呢,这里我分几部分进行介绍:

目录结构规则 -> 接口命名规则 -> 用例命名规则 -> 用例分类规则 -> 用例编写规则 -> 公共方法命名规则

3. 规则说明

3.1、用例目录结构规则

好的目录结构可以让项目呈现一目了然,假如公司统一采取 git 仓库来管理各项目的接口,这里假定 git 仓库地为:git@xx.xx.xx.xx:xx/robotframework-interface-cn.git,那各个业务项目组可以通过不同分支的形式来管理各业务接口,如公司某产品通过业务线分为移动端业务线和 web 网站业务线,那么可为两个业务线开各自独立分支如 develop-mobile、develop-web,至于详细的代码管理形式,后面再另开一章节来介绍,再此就不再过多的说明了。

另一方面通过好的目录结构可以很好的区分开各接口归类,建议最多 3 层目录层级,比如一个直播混合 app,那么第 1 层目录可以按模块调用方划分,比如 Mobile_Show(直播看模块)、Mobile_Sing(直播听模块)、H5_Mobile(H5 页面调用的接口)、Mobile_Socket(前端调用 socket 协议的接口)。

第 2,3 层目录主要按产品应用模块来划分或者根据接口 url 的路径来划分,比如: mobileshow/json/v2/cdn/mv/supportStatus 接口可划分到 Mobile_Show 目录的子目录 MV 下。

3.2、接口命名规则

自动化脚本中接口命名通常可以按照接口部分 url+ 接口方法类型组成,部分 url 是指非参数部分的最后两级路径。Http 接口方法类型主要分为:get、post 等,例如:

/json/v2/cdn/user/getUserInfo 接口命名为: user_getUserInfo_get

/json/v2/user/getUserInfo 接口命名为:user_getUserInfo_post

3.3、用例命名规则

用例命名主要为了区分用例验证点和用例作用,这里建议可以按照以下 4 种:

  • Class_序号:表示常规经典值用例,可以理解为最常用的数据,按照等价类的原则,此处每组用例所需要达到的作用应该是一致的,序号当存在多条用例的时候使用,用两位数值,如:Class_01,Class_02;

  • Field_序号_结果:表示字段校验用例,序号由 2 位数字组成,2 位数字表示字段验证序号,结果通常可以分为三类,当有错误码时为错误码,当无错误码返回为空时为 Null,当有数据返回时为 data,例如:

返回错误码:Field_01_1100018;

返回空:Field_02_null;

返回数据:Field_05_data;

  • Business_序号:表示业务用例,主要用例验证业务逻辑,序号由 2 位数字组成,表示验证序号,如:Business_01,Business_02,Business_03;

  • Safe_序号:表示此用例验证安全方面,序号由 2 位数字组成,表示字段验证序号,如:Safe _01,Safe _02,Safe _03;

3.4、用例分类规则

用例会随着不断的接口迭代越来越多,而且有时在跑接口巡检时,也会随着测试范围的不同,而希望选取不同的测试集下的用例来运行。

所以最好的方式是在在设计之初的阶段就要考虑好用例的分类,而在 RobotFramework 中通过标签 Tag 的形式,很方便就可以将用例划分成不同归类。

那么最常用的用例分类原则,有 3 类:

第 1 类,按照环境划分:按笔者经验,可以分成四类不同运行环境的用例,如:online-线上环境、test-测试环境、general-预发布环境、develop-开发环境;

第 2 类,按用例编写者来划分:如这条用例是张三编写的还是李四编写的,所以需要增加用例所属者的标签,如 zhangsan;

第 3 类,按照特性标签来划分:特性标签可由使用用途来自行定义,根据特殊场景来定义,比如每日巡检如果跑主流程的核心接口,则可以增加 main 标签代表此条用例是核心接口用例。

3.5、用例编写规范

  • a. 公共方法类和公共用例的脚本,需要每句注解其作用;

  • b. 接口定义方面需要有属于如个版本需求、用途。如用接口有修改需要增加修改原因和版本及其用途记录;

  • c. 测试用例对业务用例需要注解其验证点,其它类型可自行要求。

  • d. 接口请求公共字段放在公共方法中

3.6、公共方法

接口项目用到的公共方法需要单独抽离到公共库层,不能和用例层混在一起,可以根据应用产品及方法作用来命名,当各产品项目都适用可不带产品名称直接用方法来命名,如:

mobile_show_post: 表示直播看模块的 post 请求公共方法

md5_encode: 表示 md5 加解密方法

附带说明 - 该文章目前在我的公公号中连载,为了避免存在打广告的嫌疑,所有原文中涉及到的链接将被取消

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 3 条回复 时间 点赞
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册