a) 背景介绍

        基于当前互联网敏捷开发的现状，手工人力测试已不足以满足当前快速的版本迭代；以下将介绍一种可实现的自动化设计与使用。

b) 当前版本迭代流程

1. 研发同学从代码库master分支拉出新代码进行研发工作得开发
2. 开发完成之后提交到代码库
3. 测试同学介入，在流水线上开始用当前测试分支部署测试环境
4. 测试环境搭建完毕，开始测试验证
5. 验证完成，研发合并开发分支之uat-master代码并部署到uat环境待验收
6. 业务验收完，拉发布计划合并online分支代码进行部署后发布线上环境
7. 发布完成，业务无反馈，合并online分支至master

        可以发现最终每次push完代码后卡点得地方都在与验证，所有的环境部署后测试介入验证都是人工介入，且进度完全取决于验证人员的效率。所以在当前快速迭代版本里面往往会出现因为回归链路耽搁整个发布流程。

当前人工回归带来的问题：

1、按照周版本2次发布计划，意味着一周至少俩天上线要凌晨完成（大版本）

2、回归链路复杂的情况下，完全依赖相关测试人员把控，依赖性太强

3、人工测试难免有遗漏之处，意味着后续可能因为这个点需要回滚或者补数据（大工程）

c) 自动化接入

根据以上的流程链路，是否可以考虑拆解一下：

1. 能否搭建独立的auto环境用于自动化专属运行环境
2. 是否可以编写自动化代码，提交后在jenkins上运行
3. 能否当部署完毕后执行这个job任务
4. 能否job执行完成之后告知流水线成功与否

以上的问题拆解完成之后，你会发现：当我用分支部署环境的时候，auto环境也会跟着更新，并且自动触发自动化job，执行完成之后流水线有个测试报告成功与否，执行成功的job待发布完成后告知jenkins进行代码合并。

一)  如何编写自动化程序

        这个地方以接口自动化为例，其他自动化的实现可以自行探索。框架的选型最终都是辅助工具，没有最好的，只有更适合自己的.

httprunner框架是一个开源的测试框架，网上有很多对着干框架的描述，假设我们已经用这个框架编写好了我们要的自动化程序

ps：可以参考这篇文章

二）如何执行自动化

当你拥有jenkisn时：

• 新建一个job，配置信息将你的git地址给上
• HttpRunner 版本：3.1.0
• git 版本1.8.3.1
• 配置shell脚本：这个地方执行sh run.sh，还可以统计成功与失败的cases（我这个地方用的allure，所以读取这里面的log进行统计）

failcount=$(cut -d : -f 3 log/allure-results/*.json  | cut -d , -f 1 | grep -Eiwo 'broken' |  sort | uniq -c | awk '{print $2": "$1}' |grep -v grep|awk '{print $2}')

当你没有jenkins时：

手把手教你怎么使用jenkins

关于自动化环境：

1、部署模块与线上一致：为了满足后面部署线上代码的同时可以部署到auto环境

2、autoh环境的配置文件全部锁死，防止被代码的配置冲突；chattr -R -i

3、为了满足日常验证，另起新文件用于服务打包

三）部署改造思路

首先将自动化环境的地址加入到需要判定执行自动化的NS上

        举个例子：假如需要在上预发环境时执行自动化程序，那么上到预发环境的NS（一般都用NS解析出IP不会直接用IP）就可以配置为解析出俩个IP,一个是预发IP，一个是Auto IP。

这样的话，经过jenkins打包后，上线服务会将包部署到预发的同时也部署到Auto环境

然后在加一个配置文件用于解析是否执行自动化

例如：xxx.yml

AAA:

        AAA_test_auto_job

BBB:

        BBB_test_auto_job

程序判断当前服务AAA，存在配置AAA_test_auto_job，那么会调用jenkins接口触发job任务的执行

四）回调改造思路

主要就是记录当前job执行情况，并定时查询返回

d）通知对接

对接企业微信：企业微信发送消息

测试报告模版：最全allure测试插件