RF（二）工程规范

一、公共部分
###1 公共配置(publicConfig):
(1) 变量(publicVariable_config.txt)
存放高复用的、会因版本迭代改变的变量
(2) 常量(publicNormal_config.txt)
存放高复用、不因版本迭代变化的变量
(3) 环境配置(API_configDetail)
存放不同环境的：数据库、redis、域名，为切换测试环境准备

###2 公共资源(publicResource):
(1) 公共关键字
封装了不涉及业务的基础关键字
(2) 会话集合
此会话配置用于： Suite Setup，集中管理会话连接
(3) 数据库操作资源
封装了常用的数据库连接、查询等公共关键字
(4) 时间戳处理资源
封装了获取各种时间戳的公共关键字

###3 资源引用统一入口(public_config.txt):
将资源的引用放置在此文件，开发时资源引用只需引用此文件即可，避免了资源引用的繁杂

二、资源部分
###1.业务公共资源(API_publicResource):
减少用例的冗余，提高基础步骤复用
(1)资源关键字
报文资源层，只进行接口报文拼接和参数化
资源层接口变量名，需以请求方式区分：GET/POST
如：POST注册苏宁易购账号/GETPP视频账号登录
(2)关键字
基础关键字层，与报文资源层一一对应；调用资源关键字，进行二次封装，校验接口响应码，简单处理接口返回数据
(3)业务公共资源引用文件
将基础关键字集中归类至此文件，便于调用

###2.业务资源(API_**Resource):
(1)资源关键字
(同上)
(2)关键字
(同上)
(3)业务资源引用文件
(同上)

资源及关键字归类：
1.原则上 资源及关键字依据现有 业务模块的菜单划分及操作功能分布，进行类聚；
2.目的：方便功能关键字的查找，和统一维护；

三、API用例部分
###API测试项目（目前分为三层）：
1.第一层(报文资源层)，用于记录，和解析接口报文，进行参数化；
2.第二层(基础关键字层)，与资源层进行一一对应，对资源进行封装，简单的进行返回报文处理，和基础业务处理，
一般只处理对应的一个接口或者业务关系紧密的几个报文；
3.第三层(标准用例或者业务关键字层)
标准用例层：使用第二层关键字进行业务组合，完成一定的业务流程验证，用例简单直观，有较多的冗余和说明，主要用于新业务的开发；
业务关键字层：将一段被多次使用的业务流程片段进行有效的组合，避免冗余；

四、用例及参数命名
所有英文命名都为驼峰式命名方式，首字母小写后续单词首字母大写，缩略词全部大写，缩略词与单词以下划线连接，不以下划线等特殊字符开头命名变量
###资源层：
1.“R_” 业务关键字名称开头；
###关键字层：
1.“K_” 业务关键字名称开头；
2.以下划线分隔并描述关键字中的主体业务，如：
K_注册_发送短信验证码
###用例层：
1.以下划线分隔并描述用例的主体业务，如：
app会员_观赛券_观赛券使用
admin会员_观赛券_观赛券渠道新增
2.“CK_” case模块再次封装keyword，接口名
###变量：
(1)公共变量
${P_} 以P开头的变量，都是来源于配置文件的变量；
(2)用例变量
${S_} 以S开头的变量，都是用来用例间传值的suite级别的变量；

五、代码提交
禁止在master分支上进行开发，合分支的时候如果遇到冲突，需要解决冲突重新提交；冲突未解决不允许合入master

当前分支为自己分支(yourBranch)，修改后提交

1 git add -A ## 添加修改文件
2 git commit -m “提交内容的备注” ## 提交至本地仓库
3 git push origin yourBranch ## 推送至远端自己的分支
4 git checkout master ## 切换至master分支
5 git pull origin master ## 远端拉去master最新代码
6 git checkout yourBranch ## 切换至本地自己的分支
7 git merge master ## 将master分支合入自己的分支
8 git checkout master ## 切换至master分支
9 git merge yourBranch ## 将自己的分支合入master
10 git push origin master ## 将master分支推送至远端
11 git checkout yourBranch ## 切换回自己的分支