为什么做这个?这是什么?
为了做冒烟测试, BVT(Build Verification Testing)。
在daily build(构建版本)建立后,对系统的基本功能进行简单的测试或者功能完整性测试,也就是说冒烟测试是随着每一次构建而执行的。
冒烟测试并非研发流程中的测试阶段,而是一个开关。
通过了,你可以继续后面的测试。
不通过,直接返工等待下一次的构建。
这才是冒烟测试应有的态度。
思考:
就像地铁安检,如果你身上携带了违禁物品,你还能继续过去吗?
Rethink:
冒烟测试的最佳实践最好被自动化,在CI中每一个Build都自动的去执行主流程的测试,确保其是一个基本可用的版本。
怎么做?
我们主要做的是接口冒烟测试的python脚本,并结合业务项目里的单元测试一起做集成测试。工程师开发项目可能用的是JAVA、Go、C++等项目经理不熟悉的开发语言,为了让这个事儿简单易学好使,我们用最简单的Python+UnitTest+Requests来实现接口覆盖率测试脚本(以下简称“Python脚本”)的代码编写。
工具介绍
- Python3:我们使用Python3这个大版本,保持新鲜,持续动力
- UnitTest:Python官方单元测试框架,我们主要是用各种断言语句足以
- Requests:一个很有趣的Python HTTP库,用来实现GET/POST/PATCH/DELETE/OPTION等请求行为
- Nose2:Nose2是UnitTest的扩展插件,用于向CLI/XML输出覆盖率百分比等信息
学习路径
在工具介绍中提及的所有工具都会用到,应当熟悉。
学习顺序及掌握程度
- Python3 会声明变量/常量、function、if else,知道Python格式化要求,知道没有括号这些就可以写脚本了。
- UnitTest 掌握各种断言语句足以。
- Requests 不用懂,太简单,用过一次就掌握了。
- Nose2 只是个扩展插件,在CLI下通过一行命令执行一下就可以了,出现问题时问搜索引擎就可以了。
准备工作
- 首先准备一个合适的IDE/编辑器,比如VSCode、Atom或者更专业的PyCharm
- 安装好Python3,并且可以在命令行下输入 python3 -version,如果不能,请检查环境变量
- 安装requests和nose2
- 安装好Docker,MacOS首次安装后需要准备 default env,建议安装Docker-for-mac
- 安装好git,在你负责的业务项目分组中创建一个新的git project存放python脚本
何时写
在Sprint A(Scrum flow)结束后,基于后端工程师撰写的Swagger文档进行Python脚本的编写,并在首个Scrum周期结束之际,完成以及部署到python所在的 git CI/CD和后端git CI/CD。
你可以只写系统的基本功能进行简单测试的部分(核心业务流程接口),也可以做功能完整性测试(所有接口)。
- 根据每一个接口的请求方式,使用
requests.get(url)
等或requests.patch(url,data=data,headers=headers)
等requests框架的方法来执行接口请求。 - 执行后,根据服务器端返回的HTTP状态值判断是否执行成功。
- 如果接口使用到了自定义状态值,则还需要根据状态值近一步判断操作是否成功,并且HTTP状态值的作用转变为判断是否请求成功,而非执行成功。关于这一个认知,可以查看我另一份文档《接口文档协作规范》中5.2 返回状态说明。
参考代码
python代码可以我整理至github的仓库。
文件结构介绍
.
├── Dockerfile
├── README.md
├── function
│ └── common.py // 常用方法库
├── nose2.cfg // nose2的配置文件,非必须
├── gitlab-ci.yml // CI配置
├── requirements.txt // 初始化Dockerfile时,需要pip3 install的包名称
└── tests
├── __init__.py
└── api_testing
├── __init__.py
├── for_upload.jpg //上传用到的文件
├── test_manager.py // 运营端测试脚本
├── test_web.py // 客户端测试脚本
└── test_mini_program.py // 小程序端测试脚本
文件名必须遵守的约定
测试文件必须以test_
开头,nose2才能检测到。
如何执行测试脚本
有两个做法:
- 使用python3执行测试脚本:python3 脚本名
- 使用nose2执行全部测试脚本:nose2
最终,我们只会统一使用nose2来执行所有测试脚本的。
写README.md
写README.md只有一个目的:能够让任何同行看了都能明白怎么通过docker build一个容器并run起来,然后可以进去正确的执行nose2。
README.md是一个Peer review的标准
写Dockerfile
在这里,我选择创建一个/app
做为工作目录,将git中的文件全部拷贝至/app
,在requirements.txt
中,要求安装nose2和requests,调用pip3去安装。
写完Dockerfile后,执行docker build
命令创建容器。
接下来,我们需要进入这个运行中的容器里执行一下nose2来确保容器中的脚本工作良好。
到这里,python脚本的开发和dockerfile工作结束。接下来我们需要配置gitlab-ci.yaml
文件来让Gitlab的 CI/CD自动运行nose2 。
写Gitlab-ci.yml
先来说一下python所在的git的gitlab-ci.yml如何写以及有哪些思考,有些长,建议全部阅读。
如果只需要yml文件,请直接看python git仓库中的gitlab-ci.yml文件,然后跳过本章的阅读。
(基础知识,stages是顺序执行的)
stages
:只有一个test job就够了test job
: 使用python3.8镜像做为gitlab runner在当前job里所使用的docker容器script
:依次告知需要执行的命令,最后执行nose2only
:告诉CI,当前job只需要执行develop分支下的代码when
:任何使用都执行这个job
到这里,这份gitlab-ci.yml是可以独立运作的,我们可以删掉dockerfile,因为没有用到。
但很遗憾,这无法实现自动化部署测试的目的。我们需要在后端的git仓库里做一个设定(后端git的gitlab-ci.yml中),这个设定可以在每次后端的git有更新时,CI会调用 python git里的容器,然后执行nose2 。
为达到这一目的,需要容器贯通。因此我们需要python git里有dockerfile,让容器部署在hub.dev.domain.com服务器上,就可以让其他容器(每一个git项目都是一个容器)调用了。这么做的是为了实现最小容器化的规范目的。
下一章,我们以实际操作来呈现这一过程。
自动化的gitlab-ci.yml
与之前最大的区别就是build阶段,将容器上传至你的Docker Server,可以用Harbor搭建 。
${ HUB_DEV_ADDR }
这些变量是gitlab-shell(linux user)
设置的,是在gitlab server上配置的,这里我们无需过多了解,变量全部照抄即可,注意要修改PROEJCT_NAME
和REPO_NAME
。
这里我用的IMAGE_TAG
始终是同一个,而没有使用代表commit id的${CI_COMMIT_SHA}
,如此一来这个容器的地址永远都是: hub.dev.domain.com/**/python:v0.0.1,当我在其他git中要使用这个容器的test job时就很方便。
而在test job里,我们使用的镜像是刚刚build阶段的容器,在dockerfile里我们早早就已经让安装了python3.8、requests、nose2 ,此时就只需要执行nose2即可。
提交代码到gitlab,会在Pipelines中看到刚刚提交的执行结果,这里有2个勾,说明运行成功。
我们还需要进入test job,查看执行日志与预期是否一致。
当我们看到nose2的执行结果出来了,就说明一切正常。
后端git的gitlab-ci.yml
接下来我们还需要修改backend的gitlab-ci.yml,以实现daily build后执行测试计划。
只用加入我们自己的job就行,其他无需改动:
python-test:
stage: test
image: hub.dev.domain.com/groupname/python:v0.0.1
script:
- nose2
only:
- develop
这样一来,我们就实现了开发提交代码后,自动触发gitlab-runner拉取executor镜像执行单元测试。
单元测试通过后,gitlab-runner 执行 python测试脚本,然后执行覆盖率分析(下一章“配置CI/CD”),分析结果可供徽章调用后显示在README.md。
配置CI/CD
访问python git 的Settings -> CI/CD,展开“General pipelines”找到“Test coverage parsing”添加正则:
/TOTAL.+ ([0-9]{1,3}%)/
或者在gitlab-ci.yml文件的test job里增加以下内容:
如此,以后任何test job 执行完后,进入jobs页面就可以看到coverage的百分比了。
显示覆盖率徽章
gitlab有一个徽章功能,可以方便的添加到任何markdown文档中。在这里我用到了pipeline status和test coverage这2个徽章。
[![pipeline status](https://git.domain.com/web-v2/python/badges/develop/pipeline.svg)](https://git.domain.com/web-v2/python/commits/develop) [![coverage report](https://git.domain.com/web-v2/python/badges/develop/coverage.svg)](https://git.domain.com/web-v2/python/commits/develop)
可以将python的覆盖率放在后端git里展示,效果如下:
发表回复