自动化工具 pytest 内核测试平台落地初体验

测试平台，有人说它鸡肋，有人说它有用，有人说它轮子，众说纷纭，不如从自身出发，考虑是否要做测试平台：

第 1 阶段，用 Python+requests 写接口自动化。
第 2 阶段，选择 unitttest 或 pytest，更熟悉 pytest 选了 pytest。
第 3 阶段，快速搭建 pytest 项目脚手架，封装 tep 测试工具。
第 4 阶段，通过 Git 管理测试脚本，多分支合并代码。
第 5 阶段，去除本地环境同步麻烦，方便团队共享脚本。
需要有个测试平台。

使用篇
环境变量
环境变量是字符串键值对，全局作用域。比如不同环境不同域名：

使用：env_vars.name。

fixtures

fixtures 即 pytest 的 fixture，可以添加自定义函数，供测试用例使用。比如封装登录接口返回 token：

 

 测试用例

在前端网页写代码，1 条用例对应 1 个 pytest 的test_name.py文件。比如调用login fixture 登录：

 本地编写

PyCharm 写代码体验更好，正确姿势是从平台下载包含环境变量和 fixtures 等项目结构代码，本地编写用例，调试，跑通后，粘贴到平台上共享和维护：

 

扩展能力

用例是 Python 代码，理论上所有 Python 能写出来的，平台都能支持，比如 HTTP、WebSocket、Protobuf 等协议。

原理篇

pytest 内核

vue2-ace-editor作为前端代码编辑组件。
前端把代码通过 HTTP 请求传给后端。
后端把代码存入 MySQL 数据库。
运行用例，从数据库取出代码，生成 pytest 文件。
Shell 命令调用pytest -s test_name.py，执行测试。
后端把运行结果日志返给前端展示。
之所以要折腾数据库，是因为每次部署后 docker 容器里面的文件会被清掉，只能动态生成。

tep 脚手架
测试平台功能是从 tep 项目脚手架中抽取出来的：

• 把fixture_env_vars.py做成了环境变量功能。
• 把fixture_login.py等做成了fixtures功能。
• 把tests做成了测试用例功能。

运行用例

整体流程如下：

 

ep startproject project_name

运行用例时，判断项目目录是否存在，如果不存在就调用tep startproject project_name创建项目脚手架。

更新 conf.yaml 中 env

把前端传的当前运行环境更新到conf.yaml文件中：

动态生成或更新 fixture_env_vars.py 文件

根据环境变量功能模块的数据，动态生成fixture_env_vars.py文件：

动态生成或更新 fixtures 目录下所有文件

根据fixtures功能模块的数据，动态生成fixture_login.py等所有文件：

 

动态生成或更新 tests 某个 test_文件

从数据库拿到用例代码，动态生成test_文件。

Shell 执行 pytest 命令

从上一步拿到case_path，调用pytest -s case_path执行测试。

计划后续添加 suite 和 marker 两种批量执行用例方式。