规范--自动化代码规范

  自动化其实有很多种方式实现，有的用pyhon，有的用Java，也有的用c语言，规范可能也不尽相同，今天着重分享下用Java+git 写自动化的一些规范。

第一，代码规范

1、命名规范

• 包名：小写：例如service.impl；

• 类名：大写开头的驼峰命名规则（可读性）；

• 接口名: 大写开头的驼峰命名规则（可读性）；
  

  例如： image.png

• VO: 大写开头的驼峰命名规则（可读性）RequestVO, ResponseRes;

• Entity: 大写开头的驼峰命名规则（可读性，和表名一致）如：FinLoanTaskEntity；

• Mapper：大写开头的驼峰命名规则（可读性，和表名一致）如：FinLoanTaskMapper；

• 用例类名：以大写开头的驼峰命名规则，且以TestXXX开头：如： TestQueryFinLoanTask；

• 测试用例方法名： 以小写开头的驼峰命名规则，且以testXX开头，如：testQueryFinLoanTask；

2、注意事项

• 用例之间不能相互依赖，如果需要调用相关业务场景，需要业务方提供基础方法；
• 自动化测试数据需要与用例隔离，数据配置需要单独存放特定文件（利于业务方数据维护）；
• check模块需要独立实现，暂时在common模块中进行公用分装，但是不要在用例里面写过多的Assert.xxx()；
• 各个业务方需要提供各种数据构造场景的实现，方便其它业务线进行直接调用；
• 请求vo和返回vo等共用的在common模块进行对象封装，业务相关的需要各个业务线在自己所属模块封装；
• 测试用例中，需要对步骤进行详细注解；
• 接口日志需要打印：入参，出参，数据查询结果相关详情信息；
• entity 和mapper需要和相关的表对应（命名）；
• 入参的bean 同一以VO结尾，返回的bean封装命名同一以Res结尾；
• mybatis和mybatis plush 都支持；
• 不要在用例中直接调用mapper注解，需要单独抽一个dbservice，统一注入mapper；
• 通过配置实现多环境的切换；

第二、公共模块实例

• common包下的base.BaseTest 是所有子模块的测试入口；
• common包下的common.base 是http请求和mapper的入口；
• common包下的cofing 将外部文件动态注入到bean；
• common包下的database 主要实现数据源的动态切换；
• common包下的enums 通过枚举封装常量；
• common包下的util 主要封装一些常用共有方法；
• ext 包下主要提供一些共有的service（例如：登录）；
• loan 包下主要提供常用的共有vo,entity,mapper；

• applicationContext 只在common包存在，各个业务线需要在Common包中添加；

  
  image.png

第三、分支合并master规范

image.png

说明：

• 1、从Remote Master 分支拉取代码至本地 （本地会生成一个Local-Master Branch）；
• 2、在本地建立自己项目的分支（Local-owner Branch）；
• 3、切换（check out）成自己的项目分支（Local-owner Branch），并在该分支上进行自动化代码的编写；
• 4、提交commit并review；
• 5、Review通过后，则将自己本地分支的代码（Local-owner Branch）提交至远程服务器所对应的远程分支仓库（Remote-owner Branch）; 如果review不通过，则重新在本地分支（Local-owner Branch）上做修改，修改完成后重新提交commit，进行review，直至本次修改Review通过；
• 6、在本地切换（check out）成Local-Master Branch分支，并拉取（pull）一下最新的Remote Master分支的代码（这一步确保你本地的代码是最新的，和Remote repository上的代码一致）；
• 7、在Local-Master Branch分支上Merge下自己提交的代码；
• 8、将Local-Master Branch分支的代码Push至Remote Master Branch分支；
• 9、在本地切换成本地分支，重新开发，如此循环；