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加解密方法
4教程目录大纲（已更新）
RobotFrameWork环境搭建（基于HTTP协议的接口自动化）
5下节预告
《RobotFramework接口项目分层和通用控制方式》
