自动化测试公约

代码从gitlab下载到生产环境

本地代码传到gitlab后，可以直接从生产环境上git pull取回最新代码。以下操作就是在服务器上通过命令行来做：
git clone
第一次down代码
git clone [git.url]
会把代码down到sqlaudit目录中
之后可以通过pull来更新
git pull和代码回滚

#如果之前已经正确clone后，可以通过git pull进行同步代码，可指定分支
git pull #是pull当前分支的最新代码
git pull origin dev #表示fetch origin 的dev分支到当前目录,并与当前分支合并,相当于git fetch origin dev && git merge origin dev,取下来再合并
git pull origin dev:master #表示从远端origin dev取下代码，并与本地的master分支合并（非当前分支）
git branch #查看当前分支
git reset --hard 08b07fd34cba9c8a69f72da09d142409baf81cee  #回滚代码到08b..这个版本（此版本可从gitlab获取到）

git保存密码
在git clone之后git pull一次，会让输入用户名和密码，输入后执行
git config credential.helper store
将会在当前项目的.git/config中添加一行
[credential]
helper = store
表示密码已经被保存了，下次就不需要输入密码了，适合使用脚本同步时使用

一、代码提交

一种是命令进行提交
一种是Pycharm工具进行提交

二、git提交相关规范

团队协作，多个人情况下：

方式1

未编码之前，先pull，保证现编码分支最新
编码后，提交前先commit
再push

方式2

编码完成后，提交前先commit
先pull
再push

三、不规范导致的问题

已经跨版本提交，push失败，远程拒绝
同时提交也会出现push失败，远程拒绝
commit后，版本有差别，pull失败

方法：

先备份好自己已经编写的代码，回滚版本，pull最新内容，commit，再push；
本地已经出现代码冲突，需要解决的时候，同样也是备份好代码，选择checkout，重置到最新代码版本，保证最新代码版本，commit后再提交；
保证远程代码仓库不出问题，自己可以多尝试不同的方法，试错再解决。

代码冲突：

1.在本地修改与远程代码无冲突的情况下，优先使用：pull->commit->push
2.在本地修改与远程代码有冲突的情况下，优先使用：commit->pull->push

那么我们怎么去确定是否有冲突呢？
一般我们在合作开发一个项目的过程中，都会有分工，有时会两个人同时修改一个类，有时整个类都是你自己在开发。
如果都是自己在开发的类，当然优先使用pull->commit->push，为什么我更倾向这种方式呢，因为这样会减少Git没有必要的merge。

如果有冲突的情况下，先pull了会出现什么问题呢？
如果你的判断失误，在本地修改与远程代码有冲突的情况下，先执行了git-pull，即使是这样也不用担心，git会给你一个错误提示，这时候你再去执行commit->pull->push也是没有问题的。

总结

单人开发：pull->commit->push
多人开发：commit->pull->push

四、问题分析：

现在远程有一个仓库，分支就一个，是master。本地的仓库是从远程的master上clone下来的，再在自己本地改好，再commit → pull → push。

1、那我本地这个也算是个分支？还是就是一个本地仓库？

本地和远程的关系相当于两个分支,你感觉一样是因为git pull 的时候已经自动给绑定好对应关系了

2、如果我在远程新建了个分支，然后我pull了下来，那我本地到底有分支这个说法吗？我本地的分支是不是就是那个远程新建的分支？

远程新建了一个分支拉到本地的道理是一样的,属于复制了一份,但是本地分支和远程分支已经是两个东西了。

3、本地仓库和本地分支有什么区别？

本地分支属于本地仓库里,是包含关系,一个仓库里可以有很多分支, 如果是 tag 的话可以分离出独立的仓库

4、commit是提交到本地仓库，然后push，这个push是把所有代码推到远程仓库，还是只是把commit的地方推到远程仓库？

肯定不会全量推送到远程的,是通过对比 commit 的记录,如果本地高于远程就直接把多出来的commit 给怼上去,如果本地的这几个
commit 和远程的 commit 有冲突的部分就merge,然后根据提交时间排序再新建一个merge 的 commit 记录再怼上去。

5、那为什么要先commit，然后pull，然后再push，我pull了，岂不是把自己改的代码都给覆盖掉了嘛，因为远程没有我改的代码，我pull，岂不是覆盖了我本地的改动好的地方了？那我还怎么push？

这个先 commit 再 pull 再 push 的情况就是为了应对多人合并开发的情况：

commit 是为了告诉 git 我这次提交改了哪些东西,不然你只是改了但是 git 不知道你改了,也就无从判断比较;
pull是为了本地 commit 和远程commit 的对比记录,git 是按照文件的行数操作进行对比的,如果同时操作了某文件的同一行那么就会产生冲突,git
也会把这个冲突给标记出来,这个时候就需要先把和你冲突的那个人拉过来问问保留谁的代码,然后在 git add && git commit &&
git pull 这三连,再次 pull
一次是为了防止再你们协商的时候另一个人给又提交了一版东西,如果真发生了那流程重复一遍,通常没有冲突的时候就直接给你合并了,不会把你的代码给覆盖掉
出现代码覆盖或者丢失的情况:比如A B两人的代码pull 时候的版本都是1,A在本地提交了2,3并且推送到远程了,B 进行修改的时候没有commit 操作,他先自己写了东西,然后 git pull 这个时候 B 本地版本已经到3了,B 在本地版本3的时候改了
A 写过的代码,再进行了git commit && git push 那么在远程版本中就是4,而且 A 的代码被覆盖了,所以说所有人都要先
commit 再 pull,不然真的会覆盖代码的

6、两个分支，A和B，A合并B和B合并A，有区别吗？

两个互相合并的唯一区别就是 A->B 的时候 B 分支上会产生一个 merge_commit 的信息,这个时候 B 是合并状态而 A
未合并状态,如果现在没有发生任何改动执行 B->A 就直接切换过去了,连 merge_commit 都不会生成了

五、分支管理

master作为构建自动化脚本执行的分支，为了保证其分支的稳定性，每个人都创建自己的test分支，在test/XXX分支下进行代码开发、调试，脚本调试成功之后在push到自己的test分支下，需要合并到master分支提交一个merge requests，选择我与组内人员进行代码review。

创建分支：在pycharm右下角点击分支 -> 点击New Branch -> 填写 test/XXX -> create；
保证脚本在本地已调试成功；
创建并入master分支审核请求：
push代码到test分支之后打开gitlab页面，在工程内进入MergeRequests页面，点击New merge request，按提示创建，召集小伙伴进行代码review

六、脚本开发公约

目录结构

脚本放在根目录下test文件夹
第一层以脚本类型命名（interface、UI）
第二层以业务线命名（basic、core、ecology）
第三层以yapi内项目命名（dmc）
接口组成配置放在framework/conf文件夹下
接口方法封装放在framework/service文件夹
目录层级命名同脚本规则

pytest命名规范

工程内的脚本能被pytest识别，需要遵循pytest脚本命名规范

除非pytest命令指定到测试用例文件，否则测试用例文件命名应该以 test_开头或者以_test结尾。
测试函数命名，测试类的方法命名应该以test_开头。
测试类命名应当以Test开头。
测试类的不应该有构造函数。

业务类封装

业务类内封装接口组成、功能
不给脚本直接或者只被其他封装方法调用的方法置为内置函数
命名尽量一看就懂，完善注释，明确方法作用、使用场景、传参
脚本中看到一大串代码只是为了做一件事，可以考虑封装起来

脚本编写

全自动化，不要有某些参数或者步骤是需要人工去赋值去操作的
独立性，数据解耦，不轻易编写有依赖关系的脚本，最起码不要有跨python文件的依赖
可重复，不依赖环境、不依赖状态，能够反复执行成功
脚本内尽量做到不存在固定数据
每个步骤一定要写检查点，没有断言的脚本都是耍流氓

报告展示

在脚本中合理使用Allure标识（@allure.feature、@allure.story、@allure.title、with allure.step、allure.attach）
● feature标识测试应用和模块，一个文件夹下所有py文件使用同一个feature
● story标识测试的功能点，代表这个py文件测试的范围，一个py文件使用同一个story
● title标识，一个test方法使用一个title
● step标识，用来包裹一个测试步骤或测试点