自动化其实有很多种方式实现，有的用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、在本地切换成本地分支，重新开发，如此循环；
网友评论