RF规范

 

一、分支管理

1、分支管理的总体原则

分支开发，分支线上环境运行通过后，合并主干。

没有提交代码权限的同学请本组内有权限的同学进行审核及提交，提交前确保执行通过。

2、分支的分类

开发分支（develop/branch）：正在开发的代码分支，通常用于新功能的开发。可针对实际的情况，一个项目拉一个分支或者一个人拉一个分支。

主干分支（master/trunk）：稳定的ALL CASE PASS的代码分支，分支跑过后即提交到主干分支。

3、分支的创建

3.1 创建切换分支 $ git checkout -b dev   #在本地master分支上创建一个新的分支dev，并checkout到新分支 $ git push --set-upstream origin dev    #将新的分支push到远程库中   3.2 修改提交 $ git add test.txt #比如添加了test.txt $ git commit -m "add test" #提交到分支dev $ git push origin dev #提交远程库   3.3 合并分支 $ git checkout master #dev分支工作完成，切换回master $ git merge dev #把dev分支内容合并到master分支上 $ git push origin master #提交远程库   3.4 删除分支 $ git branch -d dev #删除本地分支 $ git push origin --delete dev #合并完成，删除远程分支（如果仅是自己用）   3.5 查看分支 $ git branch #查看本地分支 $ git branch -a #查看远程分支，dev分支没有了，当前分支前有个*号（git鼓励大量使用分支）   其他：Git 基础命令.pdf

二、目录管理

1、目录管理的总体原则

小驼峰法标识，遵循路径名称具有清晰的描述性。

2、目录结构

--librarys 公用自定义库（jar包）

--report 报告相关等

--resources 各个方向抽取的公共资源文件，关键字文件等

--方向名

--划分方向、功能目录/具体公共资源或关键字文件

--suites 各个方向的用例

--方向名

--划分方向、功能执行目录/具体case（线上-可线上自动化执行，线下-可测试环境自动化执行：case满足覆盖全业务流程，可以实现数据初始化，例如，支付完成后解绑卡，确保再次执行可绑卡成功，本地-包括可进行自动化+可执行单接口:不需要考虑数据初始化，为了测试单接口方便，绑卡一次，在支付时协议号固定等）

--teardown 初始化数据，还原现场

--values 环境&账户变量&请求地址

--环境（huidu、prod、test：api1-api5）

--具体的环境配置文件

如果只能在test环境执行case的系统，不需要配置灰度及生产环境的参数及url，可以在values文件夹下创建一个该方向的文件夹存放适用于所有test环境公用的参数文件，但是url的存储还是

需要在test多个测试环境中配置对应的url，确保可随意选择test环境进行脚本执行。

3、目录命名

3.1  名字应该尽可能具有描述性。例如cashier、standardPayment等；

3.2  小驼峰标识，不带符号，单词间无分隔。小驼峰法：除第一个单词之外，其他单词首字母大写。例如：standardPayment；

三、用例管理

1、用例管理的总体原则

按要求命名标识，使用清晰的关键字以及合适的抽象级别，验证核心点。

2、用例文件命名

2.1  名字应该尽可能具有描述性以及合适的抽象级别。例如 BindCardAndQuickPay.robot等；

2.2  case文件名称统一用英文，小驼峰标识，不带符号，单词间无分隔。小驼峰法：除第一个单词之外，其他单词首字母大写。例如：bindcardAndQuickPay.robot；

3、TestCase命名

3.1  名字应该尽可能具有描述性，并且不要过长。例如 绑卡不验证短信_解绑卡，九信理财_登录_预下单_快捷支付等；

3.2  名字统一用中文，仅允许有下划线_符号存在。例如：订购直接支付，绑卡不验证短信_商户自验短信_解绑卡等；

4、Keywords命名

4.1  名字应该尽可能具有描述性。例如 绑卡发短信Bind Card Send Message等；

4.2  大驼峰标识，不带符号，单词间空格分隔。大驼峰法：每个单词首字母大写，其他字母小写。例如：Quick Pay Use Message；

4.3  关键字不要过长，不建议超过5个单词。

5、代码编写规范

5.1  测试用例应该简单易懂避免编程风格，每一个test case应该只测试一种场景,根据case复杂程度的不同场景同样可大可小。

5.2  应该不需要任何的文档和备注就可以解释清楚这个测试是做什么的。例如：测试用例本身或者背景太过复杂是有用的，此时还是鼓励用的。

5.3  应具有迁移性减少依赖。例如：可变参数一定要抽离，不能依赖；

6、检查点规范

6.1  根据测试用例的侧重点设置检测点。例如：例如case执行结果中返回码的校验；

6.2  设置检测点要全面。例如：在了解测试操作影响前提下，一定要设置重要检测点（但不要过多），避免出现遗漏的检测点；比如支付，不只验证返回码，还要验证订单金额等；

6.3  置检测点要灵活。例如：判断是否包含关键字，判断函数的使用，特别是对动态数据的验证；

7、代码结构规范

7.1  用例分层规范 。

7.1.1 case即case：

Case集里只含可以执行的Case以及所必须的变量，不含有keyword的定义。

例如：refund.robot  这个case集里是退款的case，里面的keyword是通用的封装，来源于resources。

7.1.2  action即action：

对提交类动作/场景封装成keyword，校验核心场景主流程。

例如：standardPayment.robot 这个keword集里是各种场景的快捷支付的提交动作，增加必要的关键字功能注释。

7.2 优点

a.一次编写，到处引用（提交类or校验类keyword封装好后，在case中各处随引随用）；

        b.RF-case层次感分明，框架结构清晰（case就是case，动作就是动作，查询结果类校验就是期望值校验）；

        c.代码可读性强，易于理解；

8、扩展库开发规范

8.1  python扩展库开发，查询所需方法是否已有，已有则直接使用，没有完全符合的方法，但有相似功能，在原方法上进行整合优化（确保不影响原本功能）；

8.2  python方法尽量进行多条件判断及异常情况的考虑；

9、核心代码合并规范

9.1   xxx

10、代码review规范

10.1   xxx

四、项目源管理

1、源管理的总体原则

核心用例提交到git上，本地测试可单独维护独立的git源。

五、参考文档

1.接口项目分层 https://www.cnblogs.com/jinjiangongzuoshi/p/7750810.html

2.接口设计规范 https://www.cnblogs.com/jinjiangongzuoshi/p/7750771.html

3.接口测试断言 https://www.cnblogs.com/jinjiangongzuoshi/p/7750837.html

4.写好用例 https://www.cnblogs.com/donfire/p/3985770.html