原创项目 on 测试开发刚哥

Python处理接口数据，这个函数太香了

Mon, 19 Jan 2026 00:00:00 +0000

Python处理接口数据

接口数据通常是JSON格式，Python处理起来并不轻松。

方法一，json文件。额外编写代码读取文件，接口参数很多，文件变多，难维护。

方法二，字典。JSON可以直接粘贴到代码中，Python认作字典，但语法有差异，JSON的语法是true/false/null，Python的语法是True/False/None，不兼容。

这两种方法都有共同的缺点，需要编写表达式来定位某个节点。

比如：body["a"][0]["x"]["m"]

字符串与占位符

占位符是一种很常见的文本替换技术，在任何编程语言中都有广泛应用。

Python语法有个很特别的字符串，三引号字符串：

test_json = """
{
 "bool": true,
  "x": null,
  "customerId": "123456",
  "items": [
    {
      "productId": "987654",
      "quantity": 2,
      "price": 199.99
    }
  ],
  "shippingAddress": {
    "recipientName": "张三",
    "streetAddress": "北京市朝阳区某街道123号",
    "city": "北京",
    "state": "北京",
    "postalCode": "100000",
    "country": "中国"
  },
  "paymentMethod": {
    "type": "CreditCard",
    "cardNumber": "4111111111111111",
    "expiryDate": "12/25",
    "cvv": "123"
  },
  "orderNotes": "请尽快发货，谢谢！"
}
"""

基本思路是，把JSON写在三引号字符串中，这能保留原生JSON格式，就像很多测试平台的做法一样，然后再通过占位符，直接替换其中的节点值。占位符不用编写表达式定位节点，在JSON字符串标记即可。

年度大版本，tep3回归纯粹Python接口测试框架

Sun, 18 Jan 2026 00:00:00 +0000

回顾

tep是基于pytest开发的接口测试框架，上个版本从小工具升级为了关键字驱动框架，通过pystats发现最近半年仍然有4000+人次在安装使用tep。时隔1年后，我对tep进行了一次大版本改造，抛弃tep2的Java代码风格，重新回归到tep1的纯粹Python风格。

纯粹Python

所谓纯粹Python，体现在两个方面，一个方面是tep源码进行了重写，更加Pythonic，自动化用例写起来也更加简单易懂；另一方面是抛弃了依赖Java的Allure和依赖C++的loguru，分别使用Python技术栈的pytest-html和logging替代。

tep3版本

简介

tep是Try Easy Pytest的首字母缩写，帮你轻松上手pytest。

框架特点：

基于pytest封装，成熟、稳定且扩展性强。
框架完全由Python构建，没有混杂其他语言。
原生Python语法，学习Python，零成本使用框架。
HAR包转换pytest用例。

安装

支持Python3.8以上版本

创建虚拟环境：python -m venv venv

激活虚拟环境，Windows用户：activate.bat Mac用户：source venv/bin/activate

安装tep：pip install tep

验证安装成功：tep -V

目录结构

data
file
fixture
report
scripts
tests
.gitignore
conftest.py
pytest.ini
run.py

tep new demo就能快速创建项目名称为demo的项目脚手架。

用例示范

简单的请求：

from tep import request


def test():
    response = request("get", url="http://httpbin.org/status/200")
    assert response.status_code == 200

复杂的场景：

from tep import request
from tep import v

from data.global_data import GlobalData


class Data:
    v({
        "domain": GlobalData.domain,
        "skuNum": 2,
        "payAmount": 0.2
    })
    body_add_cart = '{"skuId":"${skuId}","skuNum":${skuNum}}'
    body_order = '{"skuId":"${skuId}","price":${skuPrice},"skuNum":${skuNum},"totalPrice":${totalPrice}}'
    body_pay = '{"orderId":"${orderId}","payAmount":${payAmount}}'


def test():
    url = v("${domain}/searchSku?skuName=book")
    response = request("get", url=url, headers=GlobalData.headers)
    assert response.status_code < 400
    v("skuId", response.jsonpath("$.skuId")[0])
    v("skuPrice", response.jsonpath("$.price")[0])

    url = v("${domain}/addCart")
    body = v(Data.body_add_cart)
    response = request("post", url=url, headers=GlobalData.headers, json=body)
    assert response.status_code < 400
    v("skuNum", response.jsonpath("$.skuNum")[0])
    v("totalPrice", response.jsonpath("$.totalPrice")[0])

    url = v("${domain}/order")
    body = v(Data.body_order)
    response = request("post", url=url, headers=GlobalData.headers, json=body)
    assert response.status_code < 400
    v("orderId", response.jsonpath("$.orderId")[0])

    url = v("${domain}/pay")
    body = v(Data.body_pay)
    response = request("post", url=url, headers=GlobalData.headers, json=body)
    assert response.status_code < 400
    assert response.jsonpath("$.success")[0] == "true"

用例和数据

数据怎么存放，这里给出了一个参考方案，在用例内定义class Data，然后通过类变量存放数据。不同的项目，不同的场景，不同的参数，可以考虑不一样的存放方式。

tep1.0.0教程

Sat, 17 Jan 2026 00:00:00 +0000

正式版教程： https://dongfanger.gitee.io/blog/tep.html

当Pytest遇上MVC分层设计自动化用例就该这么写

Fri, 16 Jan 2026 00:00:00 +0000

引子

数据写在代码里，追求快速编写用例，是我设计tep的一个特点，这在个人编写时是一种非常良好的体验。但相比于HttpRunner、JMeter等来说，总觉得还差点意思。思考良久，总结为三个字：工程化。工程化是我近一年在学习Java并参与了2个测试平台模块开发，和写了几个小工具后，感受到的一种编程思想。而其中最明显的就是Spring的MVC分层设计。为了让tep更工程化，后续版本将以MVC模块编写用例为准，同时会兼容之前的脚本式快速编写。

示例

目录结构

测试用例都放在一个文件夹下：

test_case：用例主程序；

steps：测试步骤；

data：纯粹的json；

测试用例

test_case.py是测试用例，包含的只有测试步骤：

import allure

from examples.tests.LoginToPayFlow.steps.step_add_cart import step_add_cart
from examples.tests.LoginToPayFlow.steps.step_order import step_order
from examples.tests.LoginToPayFlow.steps.step_pay import step_pay
from examples.tests.LoginToPayFlow.steps.step_search_sku import step_search_sku
from utils.cache import TepCache
from utils.step import Step

"""
测试登录到下单流程，需要先运行utils/fastapi_mock.py
"""


@allure.title("从登录到下单支付")
def test(login, env_vars, case_vars):
    case_vars.put("token", login["token"])
    cache = TepCache(env_vars=env_vars, case_vars=case_vars)

    Step("搜索商品", step_search_sku, cache)
    Step("添加购物车", step_add_cart, cache)
    Step("下单", step_order, cache)
    Step("支付", step_pay, cache)

TepCache是“缓存”，包括global_vars、env_vars、case_vars三个级别的变量池。

Step是一个泛化调用类，作用是打日志，调用第二个参数对应的步骤函数。

测试步骤

from utils.cache import TepCache
from utils.func import data
from utils.http_client import request


def step_search_sku(cache: TepCache):
    url = cache.env_vars["domain"] + "/searchSku"
    headers = {"token": cache.case_vars.get("token")}
    body = data("查询SKU.json")

    response = request("get", url=url, headers=headers, params=body)
    assert response.status_code < 400

    cache.case_vars.put("skuId", response.jsonpath("$.skuId"))
    cache.case_vars.put("skuPrice", response.jsonpath("$.price"))

from utils.cache import TepCache
from utils.func import data
from utils.http_client import request


def step_add_cart(cache: TepCache):
    url = cache.env_vars["domain"] + "/addCart"
    headers = {"token": cache.case_vars.get("token")}
    body = data("添加购物车.json")
    body["skuId"] = cache.case_vars.get("skuId")

    response = request("post", url=url, headers=headers, json=body)
    assert response.status_code < 400

    cache.case_vars.put("skuNum", response.jsonpath("$.skuNum"))
    cache.case_vars.put("totalPrice", response.jsonpath("$.totalPrice"))

步骤函数以step开头，尤其注意的是cache借助Python Typing提示，可以在编写下面代码时，获得PyCharm语法提示，所以一定不要忘了加上: TepCache：

tep支持pytest-xdist分布式执行用例及合并Allure报告

Thu, 15 Jan 2026 00:00:00 +0000

tep0.11.1版本升级内容：

1、pytest-xdist分布式执行用例，合并Allure报告；

2、global_vars全局变量配置；

分布式执行用例

借助于pytest-xdist，在命令行执行时添加参数-n auto：

pytest -n auto

pytest-xdist会自动根据本地机器硬件配置，设置最优并发，并分发用例，分布式执行。

测试时先运行main.py，然后在case100目录下执行pytest -n auto --tep-reports：

第一次串行，第二次xdist并行：

执行时间从50s一下降到5s，性能提升还是非常的明显。

合并Allure报告

pytest-xdist分布式执行，只要把allure源文件，也就是那一堆json文件，存到同一个目录下，报告的数据就是一体的，不需要单独合并。但是有个问题，tep封装了--tep-reports 命令行参数一键生成Allure报告，背后的逻辑是在pytest_sessionfinish hook函数里面实现的，分布式执行时，每个xdist的node都是一个单独的session，多个node就会生成多份报告：

10个node生成了11份报告，其中1份master节点生成的。pytest-xdist的原理如图所示：

master节点不运行任何测试，只是通过一小部分消息与节点通信。子节点执行后会通过workeroutput把数据回传给master节点。所以只需要通过是否有workeroutput属性来判断master节点：

def _is_master(config):
    """
    pytest-xdist分布式执行时，判断是主节点master还是子节点
    主节点没有workerinput属性
    """
    return not hasattr(config, 'workerinput')

然后只在主节点的pytest_sessionfinish，生成1次报告，就能避免生成多份报告。这样在xdist分布式执行模式下，--tep-reports也只会生成1份合并后的包含所有测试用例的Allure HTML报告。

完整实现代码：

import time
import shutil

import allure_commons
from allure_commons.logger import AllureFileLogger
from allure_pytest.listener import AllureListener
from allure_pytest.plugin import cleanup_factory

reports_path = os.path.join(Project.root_dir, "reports")
allure_source_dir_name = ".allure.source.temp"
allure_source_path = os.path.join(reports_path, allure_source_dir_name)


def _tep_reports(config):
    """
    --tep-reports命令行参数不能和allure命令行参数同时使用，否则可能出错
    """
    if config.getoption("--tep-reports") and not config.getoption("allure_report_dir"):
        return True
    return False


def _is_master(config):
    """
    pytest-xdist分布式执行时，判断是主节点master还是子节点
    主节点没有workerinput属性
    """
    return not hasattr(config, 'workerinput')


def pytest_addoption(parser):
    """
    allure测试报告 命令行参数
    """
    parser.addoption(
        "--tep-reports",
        action="store_const",
        const=True,
        help="Create tep allure HTML reports."
    )


def pytest_configure(config):
    """
    这段代码源自：https://github.com/allure-framework/allure-python/blob/master/allure-pytest/src/plugin.py
    目的是生成allure源文件，用于生成HTML报告
    """
    if _tep_reports(config):
        if os.path.exists(allure_source_path):
            shutil.rmtree(allure_source_path)
        test_listener = AllureListener(config)
        config.pluginmanager.register(test_listener)
        allure_commons.plugin_manager.register(test_listener)
        config.add_cleanup(cleanup_factory(test_listener))

        clean = config.option.clean_alluredir
        file_logger = AllureFileLogger(allure_source_path, clean)  # allure_source
        allure_commons.plugin_manager.register(file_logger)
        config.add_cleanup(cleanup_factory(file_logger))


def pytest_sessionfinish(session):
    """
    测试运行结束后生成allure报告
    """
    if _tep_reports(session.config):
        if _is_master(session.config):  # 只在master节点才生成报告
            # 最近一份报告的历史数据，填充allure趋势图
            if os.path.exists(reports_path):
                his_reports = os.listdir(reports_path)
                if allure_source_dir_name in his_reports:
                    his_reports.remove(allure_source_dir_name)
                if his_reports:
                    latest_report_history = os.path.join(reports_path, his_reports[-1], "history")
                    shutil.copytree(latest_report_history, os.path.join(allure_source_path, "history"))

            current_time = time.strftime("%Y-%m-%d-%H-%M-%S", time.localtime(time.time()))
            html_report_name = os.path.join(reports_path, "report-" + current_time)
            os.system(f"allure generate {allure_source_path} -o {html_report_name}  --clean")
            shutil.rmtree(allure_source_path)

global_vars全局变量

在使用环境变量模版时，有些变量需要在多个模版重复设置，tep新增了global_vars全局变量fixture，可以将重复设置的变量，定义在resources/global_vars.yaml：

tep时隔8个月迎来重大全新升级

Wed, 14 Jan 2026 00:00:00 +0000

tep此次更新，旨在从“工具”升级为“框架”，为此做了大量的代码整洁工作，重新设计了部分功能，项目脚手架也焕然一新。

接口自动化项目落地之HTTPBin网站

Tue, 13 Jan 2026 00:00:00 +0000

接口自动化项目落地系列

找个开源网站或开源项目，用tep实现整套pytest接口自动化项目落地，归档到电子书，作为tep完整教程的项目篇一部分。自从tep完整教程发布以后，tep被越来越多小伙伴了解。教程只是纯理论，是骡子是马，拉出来遛遛才知道。做接口自动化项目落地，一方面是为了让自己脑海中的构想实实在在的呈现出来，现实和理想存在多少差距，不断尝试去弥补和修缮；另一方面也是方便读者朋友们学习使用，借助实际项目来练习，才能在赛道中弯道超车。

HTTPBin网站

httpbin.org是一个简单的在线提供HTTP服务的网站：

它能够用来对HTTP进行在线测试。

测试报告

HTTPBin网站的接口自动化项目包含11个用例集：

67条测试用例：

自动化执行正确率98.5%，其中有1条错误结果，是我故意为之的，因为想展示下断言失败的效果。

环境配置

包含http和https两套环境，因为HTTPBin支持HTTP&HTTPS：

fixtures/fixture_env_vars.py

#!/usr/bin/python
## encoding=utf-8

from tep.fixture import *


@pytest.fixture(scope="session")
def env_vars(config):
    class Clazz(TepVars):
        env = config["env"]

        """变量定义开始"""
        # 环境变量
        mapping = {
            "http": {  # http环境
                "domain": "http://httpbin.org",
            },
            "https": {  # https环境
                "domain": "https://httpbin.org",
            }
            # 继续添加
        }
        # 定义类属性，敲代码时会自动补全
        domain = mapping[env]["domain"]
        """变量定义结束"""

    return Clazz()

配置默认为http环境：

conf.yaml

env: http

用例集

http-methods

import allure
from tep.client import request


@allure.title("get请求")
def test(env_vars):
    # 描述
    # 数据
    # 请求
    response = request(
        "get",
        url=env_vars.domain + "/get",
        headers={'Host': 'httpbin.org', 'Proxy-Connection': 'keep-alive', 'accept': 'application/json',
                 'User-Agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.109 Safari/537.36',
                 'Referer': 'http://httpbin.org/', 'Accept-Encoding': 'gzip, deflate',
                 'Accept-Language': 'en-US,en;q=0.9,zh-CN;q=0.8,zh;q=0.7'},
        params={}
    )
    # 提取
    # 断言
    assert response.status_code < 400

auth

民间流转的pytest项目结构设计

Mon, 12 Jan 2026 00:00:00 +0000

创建上图的pytest项目结构，只需要一条命令即可：

tep startproject demo

前提是安装tep0.9.8版本：

pip install tep==0.9.8

示例代码单独放在了samples文件夹下，可以放心将整个目录删除。其中的db演示了连接MySQL数据库，http演示了requests常见用法和tep request的猴子补丁，login_pay演示了从登陆到下单该如何编写脚本，包括httprunner、mvc（不推荐）、tep（强烈推荐）三种写法。

fixtures从conftest.py文件中单独拎了出来。这个设计与Django不谋而合，Django也有个叫做fixtures的文件夹，用来存放测试数据。其实pytest的fixture的本意是可以用来做setup和teardown的，从这个意义来说，fixtures就是存放测试数据的，比如封装登录接口为用例提供token。

utils存放了一些工具。比如自带的fastapi项目，request猴子补丁，mitmproxy抓包自动生成用例。request猴子补丁可以自定义日志输出格式，在发送请求前后完成任何你想做的操作。

tep0.9.8版本正式发布，对项目脚手架进行了精简，是为接下来的**《tep完整教程帮你突破pytest》**做好准备。

teprunner测试平台入门级部署手册发布啦

Sun, 11 Jan 2026 00:00:00 +0000

很多朋友是因为teprunner，也就是这个小众的pytest内核测试平台关注的公众号。为了让大家更好的上手teprunner，我更新了它的README，希望能让小伙伴们根据这些文档内容，一步一步的在自己本地电脑上把项目跑起来。项目跑起来之后，就可以参考前面一系列的学习教程，自己动手做一遍，在做的过程中和teprunner进行对比，不懂的点逐一突破，由点到面，完整实现。**这种学习方式能更快速的掌

tep集成mitmproxy录制流量自动生成用例

Sun, 11 Jan 2026 00:00:00 +0000

使用

操作过程非常简单，流程如下：

①配置过滤域名

必须配置，不然会有很多无效流量造成数据冗余。

②启动代理

「示例」使用了反向代理，tep自带FastApi启动Mock服务：

③录制流量

「示例」通过Postman发起请求：

自动生成用例

用例就在tests/mitm实时生成好了，用例文件名为当前时间：

每录制一个请求，就能在测试用例中看到实时添加了一条测试步骤：

    # 接口描述
    # 数据
    # 请求
    response = request(
        "{method}",
        url="{url}",
        headers={headers},
        {body_grammar}
    )
    # 数据提取
    # var = response.jmespath("expression")
    # 断言
    assert response.status_code < 400

录制完成以后，就可以再次编辑测试用例完善它。

原理

utils/mitm.py源码如下：

#!/usr/bin/python
## encoding=utf-8

## mitmproxy录制流量自动生成用例

import os
import time

from mitmproxy import ctx

project_dir = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
tests_dir = os.path.join(project_dir, "tests")
## tests/mitm
mitm_dir = os.path.join(tests_dir, "mitm")
if not os.path.exists(mitm_dir):
    os.mkdir(mitm_dir)
## 当前时间作为文件名
filename = time.strftime("%Y%m%d_%H_%M_%S", time.localtime()) + ".py"
case_file = os.path.join(mitm_dir, filename)
## 生成用例文件
template = """from tep.client import request


def test():
"""
if not os.path.exists(case_file):
    with open(case_file, "w", encoding="utf8") as fw:
        fw.write(template)


class Record:
    def __init__(self, domains):
        self.domains = domains

    def response(self, flow):
        if self.match(flow.request.url):
            # method
            method = flow.request.method.lower()
            ctx.log.error(method)
            # url
            url = flow.request.url
            ctx.log.error(url)
            # headers
            headers = dict(flow.request.headers)
            ctx.log.error(headers)
            # body
            body = flow.request.text or {}
            ctx.log.error(body)
            with open(case_file, "a", encoding="utf8") as fa:
                fa.write(self.step(method, url, headers, body))

    def match(self, url):
        if not self.domains:
            ctx.log.error("必须配置过滤域名")
            exit(-1)
        for domain in self.domains:
            if domain in url:
                return True
        return False

    def step(self, method, url, headers, body):
        if method == "get":
            body_grammar = f"params={body}"
        else:
            body_grammar = f"json={body}"
        return f"""
    # 接口描述
    # 数据
    # 请求
    response = request(
        "{method}",
        url="{url}",
        headers={headers},
        {body_grammar}
    )
    # 数据提取
    # var = response.jmespath("expression")
    # 断言
    assert response.status_code < 400
"""


## ==================================配置开始==================================
addons = [
    Record(
        # 过滤域名
        [
            "http://www.httpbin.org",
            "http://127.0.0.1:5000"
        ],
    )
]
## ==================================配置结束==================================

"""
==================================命令说明开始==================================
## 正向代理
mitmdump -s mitm.py
## 反向代理
mitmdump -s mitm.py --mode reverse:http://127.0.0.1:5000 --listen-host 127.0.0.1 --listen-port 8000
==================================命令说明结束==================================
"""

通过mitmproxy命令启动代理后，获取当前时间作为文件名在tests/mitm下生成用例文件，给addons添加插件Record类，通过response钩子捕获请求信息，对请求进行域名过滤，域名匹配成功的请求就使用测试步骤代码模板，填充method、url、headers、body数据，追加到测试用例文件中。

tep0.9.5支持自定义扩展request

Sat, 10 Jan 2026 00:00:00 +0000

tep0.9.5更新了以下内容：

teprunner重磅更新Git打通PyCharm与测试平台

Sat, 10 Jan 2026 00:00:00 +0000

经过Python测试交流群的小伙伴群策群力，teprunner添加了一个重要功能，把PyCharm中的代码，通过Git同步到测试平台中，生成测试用例。这样，teprunner就成了一个名副其实的pytest脚本在线管理平台。

teprunner测试平台定时任务这次终于稳了

Fri, 09 Jan 2026 00:00:00 +0000

teprunner测试平台已经有一个多月没有更新了，主要原因是定时任务不够稳定，经过反复试错，找到了解决办法，这次终于稳定了。

tep支持MVC架构实现用例数据分离

Fri, 09 Jan 2026 00:00:00 +0000

大家好，我是刚哥。

teprunner测试平台用例编写等体验响应式升级

Thu, 08 Jan 2026 00:00:00 +0000

本文开发内容

在免费开源的测试平台中，teprunner的UI界面应该算得上第一梯度了，BUT，美中不足，在不同分辨率显示器（比如13.3寸小屏笔记本）下布局大的弹出窗口，表现不尽如人意。而这又是核心功能代码编辑的界面，比如用例编写、fixture编写，很有必要优化升级。除此之外还有滚动条的问题：竖向双滚动条和横向滚动条，也对体验造成影响。本文将对这些内容进行改造，具体如下：

编写用例页面，从弹窗改为子页面。
编写fixture页面，从弹窗改为子页面。
代码编辑区域高度自适应。
缩小左侧菜单，移动项目环境和新增按钮同一行，扩大编辑区面积。
消除所有双向滚动条。
消除所有横向滚动条。
语法说明添加环境变量和fixtures示例代码。
其他细节优化。

响应式是指同一套前端代码在不同浏览器（PC端、移动端等）都能适配，Element UI已经是响应式设计了，本文的响应式体现在代码编辑区行高根据window.innerHeight自动计算设定。

升级效果展示

左侧菜单栏变窄；添加环境变量和fixtures示例代码。

项目环境和新增按钮同一行显示，扩大有效内容可视面积。

fixtures的新增和编辑从弹窗改为子路由页面，代码编辑区高度自适应，纵向滚动条只出现一个。

消除横向滚动条；缩小了用例描述列以外其他列宽；替换操作按钮文字为图标。

用例的新增和编辑从弹窗改为子路由页面，代码编辑区高度自适应，纵向滚动条只出现一个。

用例运行结果的新增和编辑从弹窗改为子路由页面，代码编辑区高度自适应，纵向滚动条只出现一个。

测试计划的新增，编辑，运行结果也做了相同调整。

整体而言，有效信息的可视面积和可操作面积都尽可能扩大了！

关键技术点

前端代码修改文件如下：

比较繁琐，没有新知识，这里就不一一讲解了，而是选择用到的关键技术点来进行知识回顾：

template添加<router-view></router-view>
主页面div添加v-if="$route.name === 'name'"
在router/index.js中添加children子路由
跳转页面前，存localStorage
新页面create()时，取localStorage
this.$router.push跳转路由
div同行显示用float: left，紧跟的div换行用clear: both
window.innerHeight获取屏幕高度

小结

本文完成了对teprunner测试平台前端UI界面的体验升级，已经适配13.3寸到27寸显示器，如果还在担心不好用的话，那么现在可以好好试试了。定时任务从目前优化效果来看，已经趋于稳定，不久就会和大家见面。

tep集成HttpRunner与Flask实现开箱即用

Thu, 08 Jan 2026 00:00:00 +0000

大家好，我是刚哥。

teprunner测试平台测试计划批量运行用例

Wed, 07 Jan 2026 00:00:00 +0000

本文开发内容

上一篇文章已经把pytest引入到测试平台中，通过多线程和多进程的方式，运行测试用例。有了这个基础，做批量运行用例的功能就很简单了，只需要前端传入一个CaseList即可。本文的后端代码是增删改查和复用run_case相关代码做个run_plan。前端代码将学习如何通过LocalStorage在非父子组件之间传递数据。具体开发内容如下：

测试计划增删改查
测试计划动态添加移除测试用例
运行测试计划，批量运行用例
计划运行结果、用例运行结果

编写后端代码

编辑teprunner/urls.py文件，添加测试计划的路由：

编辑teprunner/models.py文件，添加3张表的model：

Plan存放测试计划，PlanCase存放计划和用例关联关系，PlanResult和CaseResult类似，这里之所以把单独出来一张结果表，是为了和用例结果CaseResult相互独立，防止计划结果覆盖用例结果，毕竟CaseResult一般是手工跑出来的，PlanResult一般是定时任务跑出来的，功能数据解耦后处理起来也更方便。

编辑teprunner/serializers.py文件，添加序列化器：

为了前端展示需要，这里额外关联了一些字段进行展示。尤其是：

caseNum用例总条数，passedNum成功条数，failedNum失败条数，errorNum错误条数。成功定义为：只有passed，没有failed和error的用例。失败定义为：只有failed，没有error的用例。错误定义为：只要有error的用例。

本文还展示了，如果序列化器的某个字段只在存库时使用，返回响应时不展示，该怎么处理：

重写to_representation方法，把不需要返回的字段pop移出去。这里output在计划运行结果不需要，在用例运行结果才需要，为了减少传输数据，就在计划运行结果的接口响应中移出去了。

最后来写View，新增teprunner/views/plan.py文件：

重写list方法，添加查询条件。重写destroy方法，判断必须先删除关联测试用例，才能删除测试计划。

PlanCaseView类似：

添加add方法：

在添加用例时写入plan_case表。添加remove方法：

在移除用例时从plan_case表删除数据。继续：

result视图用来返回计划运行结果，根据searchType来分别查询用例总条数、成功条数、失败条数、错误条数。

继续：

plan.case_result和case.case_result类似，返回测试计划的每条用例的运行结果。

在测试计划添加用例的时候，有个用例列表，需要增加2个过滤条件，编辑teprunner/views/case.py文件：

第一个过滤条件是排除当前计划已经添加过的用例：exclude_plan_id由前端传入，根据PlanCase关联关系找到已添加的用例进行过滤；第二个查询条件是关键字：用例ID或用例描述，跟PlanCaseView.list()里面一样。

最后，编辑teprunner/views/run.py文件，增加批量运行用例的功能：

添加delete_plan_result方法，在运行用例前，先把已有结果删掉，注意这里的model是PlanResult。继续：

修改pytest_subprocess函数，添加plan_id字段。继续：

修改save_case_result函数，判断没有plan_id就存case_result表，有plan_id就存plan_result表。

复制run_case的代码为run_plan：

修改case相关代码为plan。值得注意的是中间那段代码，根据plan_id从PlanCase中找到关联用例，生成了case_list，这样就复用run_case的多线程和多进程代码，批量运行测试用例了。

编写前端代码

编辑src/router/index.js文件，添加测试计划相关路由：

		{
            path: "plan",
            name: "plan",
            meta: {
              title: "测试计划",
            },
            component: () => import("@/views/teprunner/plan/PlanManagement.vue"),
            children: [
              {
                path: "addPlan",
                name: "addPlan",
                meta: {
                  title: "添加计划",
                },
                component: () => import("@/views/teprunner/plan/PlanEditor"),
              },
              {
                path: "editPlan",
                name: "editPlan",
                meta: {
                  title: "编辑计划",
                },
                component: () => import("@/views/teprunner/plan/PlanEditor"),
              },
              {
                path: "caseList",
                name: "caseList",
                meta: {
                  title: "用例列表",
                },
                component: () => import("@/views/teprunner/plan/CaseList"),
              },
              {
                path: "planResult",
                name: "planResult",
                meta: {
                  title: "计划运行结果",
                },
                component: () => import("@/views/teprunner/plan/PlanResult"),
                children: [
                  {
                    path: "caseResult",
                    name: "caseResult",
                    meta: {
                      title: "用例运行结果",
                    },
                    component: () => import("@/views/teprunner/plan/CaseResult"),
                  },
                ],
              },
            ],
          },

跟之前做增删改查不一样的地方是：**在父组件中，不会import子组件，而是通过LocalStorage进行组件之间传值。**因此这里增加了添加计划、编辑计划等路由。

原创pytest辅助工具tep0.9.1版本恢复项目初始化文件

Wed, 07 Jan 2026 00:00:00 +0000

最近几个月时间有些小伙伴问到为什么tep项目初始化文件没有了？

teprunner测试平台Django引入pytest完整源码

Tue, 06 Jan 2026 00:00:00 +0000

本文开发内容

pytest登场！本文将在Django中引入pytest，原理是先执行tep startproject命令创建pytest项目文件，然后从数据库中拉取代码写入文件，最后调用pytest命令运行用例。为了提高运行效率，用例运行是并行的，采用了多线程和多进程，两个都有，这在最后有个单独小结进行比较完整的说明。因为用例运行是异步的，所以前端并不知道什么时候执行完才能拿到运行结果，可以发多个HTTP请求轮询，但这种方式并不优雅，本文将采用WebSocket来实现用例结果查询。具体内容为：

cases/<int:pk>/run运行用例接口
ws/teprunner/cases/<int:case_id>/result/用例结果查询接口
projects/<int:pk>/export下载项目环境接口
前端添加WebSocket请求

知识点涉及有点多：tep、pytest、同步、异步、多线程、多进程、回调函数、WebSocket、长连接、全双工、ASGI、WSGI、打ZIP包、文件字节流传输。

编写后端代码

编辑requirements.txt，添加tep和channels：

tep==0.6.9
channels==3.0.3

tep是用来创建pytest项目的，channels是用来实现WebSocket的。

编辑teprunner/urls.py文件，添加HTTP路由：

首先实现run接口，新建teprunner/views/run.py文件：

这是运行用例的主体流程：

第一步从请求中获取用例id、运行环境、运行人，这里演示了获取user数据的两种方式：接口传参和从token中解析。然后根据project_id，run_env，user_id定义了pytest项目的路径。
第二步使用tep startproject创建项目文件，清空fixtures和tests目录，目的有两个：一是清掉tep默认fixtures和示例cases，防止对平台产生干扰；二是保证每次运行目录都是干净的，就不用单独去处理前端手动删掉fixture/case后，文件残留的问题。然后从数据库中拉取环境变量、fixtures等数据更新文件。
起多个线程，分别执行用例，执行前先拉取用例代码写入文件，这里是单条用例运行，之所以要用for循环，是因为用例迟早是要批量执行，在设计时就考虑到，避免后面走弯路。然后删掉数据库运行结果，通过subprocess起子进程调用pytest命令，最后在线程的回调函数中根据pytest_result保存用例结果到数据库中。

图中很多函数和类是我封装的，一个一个拆解来看：

这里定义了Django中存放pytest项目的目录文件，project_temp_name是按照project_id、env_name、user_id来划分的，目的是让运行目录尽量隔离开来，不要相互影响，借鉴了Docker容器的思想，可以把这个目录视为用例运行容器。继续：

tep startproject命令创建pytest项目，pytest文件有特定组织方式，比如conftest.py文件等，tep提供了脚手架一条命令创建项目结构。继续：

fixture_env_vars.py里面存放了tep的环境变量，Django这里每次都从数据库的env_var表中获取数据，动态更新到文件里面。setdefault是个骚操作，这行代码等价于：

if env_name in mapping.keys():
    mapping[env_name][name] = value
else:
    mapping[env_name] = {name: value}

继续：

分别从数据库中获取代码写入fixture文件和case文件，把前端传参的运行环境写入conf文件。继续：

清空fixtures目录，清空tests目录。继续：

pull_tep_files是写环境变量，写fixture文件，写conf文件三步的集合，复用代码。pull_case_files通过yield定义为了生成器，它和list的区别是不会一次把所有数据产生到内存中，而是每次用的时候产生一次，节约内存开销。delete_case_result用于运行用例前删除case_result表里面已经存在的这条用例的数据。case_result按照用例id和运行人存的多条，每个运行人都有一条属于自己的运行数据，避免数据相互干扰，返给前端的是运行时间最新的那一条！

继续：

subprocess.getoutput()可以执行shell命令并返回执行结果，这里就拿到了pytest控制台日志，这个函数是在线程池中异步执行的，主线程不能一直等待它执行，所以需要有个回调函数，等它自己执行完了去调用这个回调函数。save_case_result就是个回调函数，它的入参pytest_result等于pytest_subprocess函数返回的元组，拆包后就能拿到outout、cmd、case_id、run_env、run_user_nickname，从中解析出result和elapsed后，就可以存库了，无则新增，有则更新。

run接口做好了，再接口做下载环境接口，编辑teprunner/views/project.py：

打包的代码是从网上找的，把source_dir打包成zip_filename文件。继续：

file_iterator函数也是网上找的，把二进制文件读取为字节流，传输给前端，需要使用StreamingHttpResponse对象并添加Content-Type和Content-Disposition。红框的代码跟run接口类似，区别在于目录换成了export_temp_dir()，且不包含测试用例，生成zip文件后会把导出临时目录删掉，防止冲突。

两个HTTP接口做完了，开始实现WebSocket。WSGI一种网关接口，是Python为了解决Web服务器端与客户端之间的通信问题而产生的，不支持WebSocket；ASGI是WSGI的扩展，意思是异步网关接口，支持WebSocket。编辑teprunnerbackend/urls.py文件：

添加了WebSocket路由。编辑teprunnerbackend/asgi.py文件：

添加websocket的URLRouter，http保持默认。编辑teprunnerbackend/settings.py文件：

INSTALLED_APPS中添加channels，继续：

添加ASGI应用配置和CHANNEL配置。CHANNEL_LAYERS是一种通信系统，允许多个Consumer实例之间互相通信，以及与外部Django程序实现互通。学习版这里使用的InMemory。

生产中不建议使用InMemory，可能会有性能问题，而是应该使用Redis：

CHANNEL_LAYERS = {
    "default": {
        "BACKEND": "channels_redis.core.RedisChannelLayer",
        "CONFIG": {
            "hosts": [("127.0.0.1", 6379)],
        },
    },
}

最后，编辑teprunner/views/case.py文件：

tep环境变量、fixtures、用例三者之间的关系

Tue, 06 Jan 2026 00:00:00 +0000

tep是一款测试工具，在pytest测试框架基础上集成了第三方包，提供项目脚手架，帮助以写Python代码方式，快速实现自动化项目落地。

tep0.6.0更新聊聊pytest变量接口用例3个级别复用

Mon, 05 Jan 2026 00:00:00 +0000

tep是一款测试工具，在pytest测试框架基础上集成了第三方包，提供项目脚手架，帮助以写Python代码方式，快速实现自动化项目落地。fixture是pytest核心技术，本文聊聊如何使用fixture完成变量、接口、用例3个级别复用。

teprunner测试平台开发用例管理不只有增删改查

Mon, 05 Jan 2026 00:00:00 +0000

本文开发内容

用例管理是对用例进行增删改查，按照前面文章的思路，把它做出来应该不难，如果你已经自己写好了，那么可以和本文提交的代码比较下看看。除了增删改查，用例管理还需要提供运行用例的入口，在操作列添加一个运行按钮，单条用例运行，并弹窗展示运行结果。用例列表需要能看到每条用例执行情况，添加表格列用于展示，其中“运行结果”列要有超链接，点击查看上次运行结果。为了避免修改别人用例出错，还需要有个复制用例功能。除了在线编辑，平台应支持下载项目环境到本地，无缝切换到PyCharm，让新用户快速上手。综上所述，本文开发内容如下：

用例增删改查。
运行按钮，点击后弹出“运行用例结果”。
添加表格展示列，其中“运行结果”用颜色区分不同结果状态：passed，failed，error，点击超链接后弹出“查看用例结果”。
复制按钮，点击后生成一条复制的新用例。
新增/编辑页面，添加运行按钮。
运行/查看页面，添加编辑按钮。
下载环境到本地。

工作量主要在前端，后端先做一部分。

编写后端代码

编辑teprunner/urls.py，添加路由：

除了增删改查，还添加了2个接口，一个用于获取用例运行的结果，一个用于复制测试用例。

编辑teprunner/models.py，添加模型：

第一个Model是Case，没有定义name字段，实际上用例ID和用例描述已经够用了，name不知道填什么，有点多余。第二个Model是CaseResult，会记录运行结果，这个运行结果是从pytest执行日志最后一行的Summary截取出来的，比如1 passed，1 failed，耗时也是从Summary截取出来的。output存放代码运行后打到控制台的输出日志。最后三个字段记录运行环境、运行人和运行时间，运行时间取的数据库记录被添加/更新的时间。添加好以后迁移到数据库中：

python manage.py makemigrations
python manage.py migrate

编辑teprunner/serializers.py，添加序列化器，第一个序列化器是CaseSerializer：

只关联了Case模型的字段。

第二个序列化器是CaseListSerializer：

它主要用来返回用例列表的数据，除了用例本身，还需要用例结果。serializers.SerializerMethodField用于自定义序列化字段，定义好字段后，在下面添加get_前缀+字段名的方法，这是Django的规则，然后在方法内部添加取值代码，比如get_result()，instance是指Meta.model定义的模型，这里就等同于Case，通过instance.id获取到Case.id并赋值给case_id变量，从CaseResult的对象中过滤case_id匹配的用例结果，按运行时间倒序，取最新1条结果的result字段的值。其他字段的处理是类似的，runTime这里做了下日期格式化：

第三个序列化器是CaseResultSerializer：

只关联了CaseResult模型的字段，runTime同样做了日期格式化。从这里也能更清晰的看到，instance就是指的自己！

新建teprunner/views/case.py文件，添加视图，先把简单的两个视图做了，第一个视图是case_result：

这里是个知识点，采用@api_view注解的函数视图，如果想用序列化器，那么采用这种方式。

第二个视图是copy_case：

根据case_id查找到现有Case对象，在case.desc后面添加--复制后缀，其他字段数据复用，保存，就完成复制用例了。

第三个视图是CaseViewSet：

继承了ModelViewSet，重写了list列表查询，因为如果不重写，默认返回的结果是serializer_class = CaseSerializer序列化器的内容。我们需要的是CaseListSerializer这个序列化器的内容。这里也是一个知识点！如果想在类视图中，使用serializer_class以外的序列化器加分页，采用这种方式。

重写的list方法首先添加了project_id、case_id、desc、api四个过滤条件，与前端的当前项目、用例ID搜索框、用例描述搜索框、API路径搜索框一一对应。__icontains表示包含，相当于模糊匹配，i忽略大小写。接着用到了自定义分页的类，按照统一的分页格式，返回序列化器的数据。

最后，重写了update方法，用现有的创建人进行更新。

编写前端代码

编辑router/index.js，添加路由：

编辑views/teprunner/index.vue，添加菜单项：

新建views/teprunner/case/CaseManagement.vue文件，增删改查基础代码不再另加赘述，挑选新代码：

在运行结果列，添加了超链接，点击后打开用例结果弹窗，这个弹窗查看和运行用例都会用到，用第一个参数type做区分：

getResultColor方法返回颜色样式：

由于用例结果弹窗和用例列表表格都会有这个字段，于是把resultColor方法提取到了utils/commonMethods.js文件中：

CaseManagement.vue是一个父组件，它有3个子组件，如下图所示：

通过import后，添加标签代码引入：

是否显示弹窗通过DialogFormVisible的true/false来控制，DialogTitle指定弹窗标题。:开头是父组件向子组件传值， @开头是接受子组件发过来的emit事件通知，从而调用父组件中方法。这样就把这几个组件绑定在一起了！

teprunner测试平台用例前置模块开发

Sun, 04 Jan 2026 00:00:00 +0000

本文开发内容

现在正式进入测试相关功能开发。teprunner测试平台底层是pytest，中间层是tep，还没了解的朋友可以先看看tep的文章，整个平台的设计思路和后面用例的执行都会基于这个工具。tep的测试用例是放在.py文件里面的，全局变量或者说环境变量是引用的env_vars，公共函数和复用接口是引用的fixtures，在做成平台后，需要把这两个部分独立为两个功能模块。多个项目的接口自动化数据需要隔离开来，要有个项目管理功能。本文将开发四个用例前置模块：

后台管理–项目管理
接口自动化–语法说明
接口自动化–环境变量
接口自动化–fixtures

编写后端代码

先创建名为teprunner的app：

django-admin startapp teprunner

在settings的INSTALLED_APPS中添加配置让app生效：

并在urls.py添加路由：

编辑user/fixtures/user.json，添加一个接口自动化的菜单：

截图只截了管理员，测试和开发角色，也需要添加上。access均为true，这三个角色都可以访问。添加后把数据同步到数据库：

python manage.py loaddata user

编辑teprunner/models.py，新增模型：

包括了项目、环境变量和fixture三张表。Project.env_config用于给项目配置多个环境。不同项目不同环境的环境变量不一样，在EnvVar中添加了project_id和env_name，并按(“project_id”, “env_name”, “name”)作为唯一键，不允许重复。不同项目的fixtures不同，不关心环境，在Fixture中只添加了project_id。

models编写好后，迁移到数据库：

python manage.py makemigrations
python manage.py migrate

新建teprunner/serializers.py文件，新增序列化器：

数据库字段的命名是用的下划线，接口返回前端和前端传参是用的驼峰，所以这里通过source这种方式给env_config、project_id、env_name、creator_nickname进行了序列化器的重命名。为了前端更方便处理，使用serializers.CharField把int转化为了str，由于请求时id非必须，增加参数required=False。

teprunner会有很多视图，写在一个文件里面有点臃肿，这里创建views文件夹，新增views/project.py项目视图：

Django REST framework的ModelViewSet视图类能节省很多代码，只需要三行就把项目增删改查接口做了。project_env是函数视图，请求方法为GET，它的作用是返回项目环境列表，当前项目和当前环境，默认为第一个项目和第一个环境。

新建views/envvar.py新增环境变量视图：

环境变量跟项目和环境是强关联的，需要根据项目环境进行过滤，所以重写了list方法，从前端请求拿到curProjectId和curEnvName，通过EnvVar.objects.filter进行过滤。from django.db.models import Q支持多种过滤条件，这在后面的代码中还能看到，比如模糊匹配。

新建views/fixture.py新增fixture视图：

fixture跟项目是强关联的，需要根据项目进行过滤，所以重写了list方法，从前端请求拿到curProjectId，通过Fixture.objects.filter进行过滤。Fixture有个creatorNickname字段，新增fixture时使用的是当前登录用户的昵称，修改fixture时需要用已保存的创建者，重写update方法来实现这个处理。

最后，新建teprunner/urls.py文件，把视图添加到路由中：

编写前端代码

编辑package.json，添加依赖：

fixtures是代码形式的，这是测试平台第一次使用代码编辑组件。添加依赖后记得执行npm install进行安装。

编辑router/index.js：

添加接口自动化的路由，并把home重定向改为语法说明路由。children表示子路由。path是路由地址。meta.title用于显示菜单名。

编辑views/console/index.vue：

添加项目管理菜单。新建ProjectManagement.vue和AddProject.vue，添加项目管理增删改查代码，跟用户管理类似，不再另加赘述。值得注意的是环境配置placeholder="请输入环境英文名（多个环境英文逗号分隔）"，因为tep.env_vars.mapping会用到环境名作为key，所以只能用英文名！

编辑components/WrapComponent.vue，添加一个插槽：

如何用tep完成增删改查接口自动化

Sun, 04 Jan 2026 00:00:00 +0000

tep的设计理念是让人人都可以用Python写自动化，本文就来介绍如何用tep完成增删改查接口自动化。

pytestx容器化执行引擎

Sat, 03 Jan 2026 00:00:00 +0000

系统架构

前端、后端、pytest均以Docker容器运行服务，单独的容器化执行引擎，项目环境隔离，即用即取，用完即弃，简单，高效。

前端容器：页面交互，请求后端，展示HTML报告
后端容器：接收前端请求，启动任务，构建镜像，触发运行pytest，挂载HTML报告
pytest容器：拉取项目代码，指定目录执行，生成HTML报告

系统流程

支持2种运行模式配置：容器和本地。

容器模式：判断是否支持docker，如果支持，构建pytest镜像，在构建时，通过git拉取项目代码，再运行容器，按照指定目录执行pytest，生成测试报告，并将报告文件挂载到后端。如果不支持，降级为本地运行。

本地模式：模拟容器行为，在本地目录拉取代码，执行pytest，生成测试报告。

效果展示

任务管理：

容器模式：

本地模式：

平台大改造

pytestx平台更轻、更薄，移除了用例管理、任务关联用例相关功能代码，只保留真正的任务调度功能，backend的requirements.txt解耦，只保留后端依赖，pytest相关依赖转移到tep-project。

那如何管理用例呢？约定大于配置，我们约定pytest项目已经通过目录维护好了一个稳定的自动化用例集，也就是说需要通过平台任务调度的用例，都统一存放在目录X下，这些用例基本不需要维护，可以每日稳定执行，然后将目录X配置到平台任务信息中，按指定目录执行用例集。对于那些不够稳定的用例，就不能放到目录X下，需要调试好以后再纳入。

为什么不用marker？pytest的marker确实可以给测试用例打标记，也有人是手动建立任务和用例进行映射，这些方式都不如维护一个稳定的自动化用例集方便，在我们公司平台上，也是维护用例集，作为基础用例集。使用pytest项目同理。

核心代码

一键部署

#!/bin/bash
PkgName='backend'

Dockerfile='./deploy/Dockerfile.backend'
DockerContext=./

echo "Start build image..."
docker build -f $Dockerfile -t $PkgName $DockerContext
if [ $? -eq 0 ]
then
    echo "Build docker image success"
    echo "Start run image..."
    docker run -p 8000:80 $PkgName
else
    echo "Build docker image failed"
fi

FROM python:3.8

ENV LANG C.UTF-8
ENV TZ=Asia/Shanghai

RUN /bin/cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime && echo 'Asia/Shanghai' >/etc/timezone

WORKDIR /app
COPY ./backend .
RUN pip install -r ./requirements.txt -i \
    https://pypi.tuna.tsinghua.edu.cn/simple \
    --default-timeout=3000

CMD ["python", "./manage.py", "runserver", "0.0.0.0:80"]

数据库表

teprunner测试平台部署到Linux系统Docker

Sat, 03 Jan 2026 00:00:00 +0000

本文是一篇过渡，在进行用例管理模块开发之前，有必要把入门篇开发完成的代码部署到Linux系统Docker中，把部署流程走一遍，这个过程对后端设计有决定性影响。

开源测试平台开发期待你的加入

Sat, 03 Jan 2026 00:00:00 +0000

背景

在2022年7月6日我曾组织过一次开源测试平台开发报名，有50+人报名，到2023年1月28日项目暂停，如大家在Gittee看到的，除我以外，只有1个人真正提交了代码：奉孝。

原因如其中一位同学所说：“感觉我们大部份还是缺少从0到1的经验，负责的内容有时候不要知道从哪下手，又少了点积极性”。描述得很贴切，可能刚开始动力很足，但因为缺少经验，不够积极，最后实践不了。说的很好，就是做不到。也很无奈。

二次启动，分为2个阶段，第一个阶段是学习阶段，我带着大家一起把teprunner平台从0到1开发一遍，把需要掌握的知识先学一遍，保证有一定基础，挑战能够独立完成模块开发。第二个阶段是开发阶段，共同完成EasyPytest测试平台开发，学以致用，加深对前后端分离项目开发的理解，具有真实的平台开发实践。

学习阶段

你都不维护了，我为什么还要学teprunner？Django没意思？我想学FastAPI？

teprunner有一套完整教程，包括前后端源码、11篇电子书教程、2小时视频讲解，虽然我因为工作原因没有继续维护teprunner，但是它仍然非常适合初学者入门学习测试开发，掌握里面的知识，对于后续学习其他技术，都有很大帮助。我的技术提升除了二刷《流畅的Python》和编写了tep开源工具，最大的提升就是完成了teprunner测试平台开发，如果你也能自己动手完成一遍，一定有极大提升。

Django、Flask、FastAPI、SpringBoot，我认为从入门者角度来说，Django是最适合的，它属于开箱即用的框架，很多东西都给你准备好了，你用就行，避免刚开始就陷入环境搭建，三方库拼装、数据库维护的麻烦中，降低理解门槛和操作难度。学会了Django，再学其他的，也很简单，一通百通。刚开始学习，学哪个不是最重要的，最重要的是先学会一个，迈出第一步。以我的经验来说，学习成熟框架Django是个正确选择。

开发阶段

EasyPytest的后端把Django切换为了FastAPI，掌握了Django，再对比FastAPI，就能对后端开发框架有更深入的理解。就像我学Python和Java一样，只学一门百思不得其解，对比一看，豁然开朗。目前已经完成了登录、首页、用户管理的开发，Gitee也有相应源码。未来的规划，是做teprunner的升级版，实现pytest平台化，80%工作本地开发脚本，20%工作交给平台编排运行。

报名方式

添加微信cekaigang，备注参加平台开发，进群。

现开启学习阶段报名：

按需选择，10元/节，录播+直播集中答疑。报名后会获得一份录播+一次集中答疑直播+一个每节课源码。每节课源码跟GitHub上源码不同，只会包含当前这节课进度的源码，一步一步的看到测试平台是如何开发出来的。

课表链接： https://eqgvpqzl6c.feishu.cn/mindnotes/bmncndM8oei2B0MIFE1RMrGuKjd

开发阶段报名需至少参与一节学习课程，从优秀学员或积极学员中选择，时间另行通知。

当然，如果你已经具备奉孝这样的技术能力和积极性，欢迎直接与我联系，请提供你的开源项目地址或在Gitee提交Pull Requests，以证明能够独立完成模块开发，直接参与EP平台共建。

框架V2.0.0开发指南

Sat, 03 Jan 2026 00:00:00 +0000

温馨提示：开发指南，根据V2.0.0编写，不随版本更新维护，仅供入门参考。最新实现请结合教程和源码阅读，教程会在版本发布后维护。

一次全量数据对比工具发现问题的过程与思考

Sat, 03 Jan 2026 00:00:00 +0000

如果没有这次全量数据对比工具，那么也许这个历史问题会继续隐藏着，直到发生线上事故才暴露出来，毕竟人工抽样验证发现的概率只有5.8%。

pytestx重新定义接口框架设计

Fri, 02 Jan 2026 00:00:00 +0000

概览

脚手架：

用例代码：

"""
测试登录到下单流程，需要先启动后端服务
"""

test_data = {
    "查询SKU": {
        "skuName": "电子书"
    },
    "添加购物车": {
        "skuId": 123,
        "skuNum": 2
    },
    "下单": {
        "orderId": 222,
        "payAmount": "0.2"
    },
    "支付": {
        "skuId": 123,
        "price": 0.1,
        "skuNum": 2,
        "totalPrice": 0.2
    },
}
case_vars = dict()


def test(http, login_headers, file_data):
    # 搜索商品
    url = file_data["domain"] + "/api/tasks/mock/searchSku"
    body = test_data["查询SKU"]

    response = http("get", url=url, headers=login_headers, params=body)
    assert response.status_code < 400

    case_vars["skuId"] = response.jsonpath("$.skuId")
    case_vars["skuPrice"] = response.jsonpath("$.price")

    # 添加购物车
    url = file_data["domain"] + "/api/tasks/mock/addCart"
    body = test_data["添加购物车"]
    body["skuId"] = case_vars["skuId"]

    response = http("post", url=url, headers=login_headers, json=body)
    assert response.status_code < 400

    case_vars["skuNum"] = response.jsonpath("$.skuNum")
    case_vars["totalPrice"] = response.jsonpath("$.totalPrice")

    # 下单
    url = file_data["domain"] + "/api/tasks/mock/order"
    body = test_data["下单"]
    body["skuId"] = case_vars["skuId"]
    body["price"] = case_vars["skuPrice"]
    body["skuNum"] = case_vars["skuNum"]
    body["totalPrice"] = case_vars["totalPrice"]

    response = http("post", url=url, headers=login_headers, json=body)
    assert response.status_code < 400

    case_vars["orderId"] = response.jsonpath("$.orderId")

    # 支付
    url = file_data["domain"] + "/api/tasks/mock/pay"
    body = test_data["支付"]
    body["orderId"] = case_vars["orderId"]

    response = http("post", url=url, headers=login_headers, json=body)
    assert response.status_code < 400
    assert response.jsonpath("$.success") == "true"

页面下载脚手架

启动平台前后端服务后，从页面下载脚手架，平台会拉取开源项目tep-project最新代码，打成压缩包，生成下载文件，弹窗下载。

tep用户手册帮你从unittest过渡到pytest

Fri, 02 Jan 2026 00:00:00 +0000

unittest和pytest是Python的2个强大的测试框架，经常用来做UI自动化或接口自动化。unittest是PyCharm的默认集成工具，也是我们大多数人入门自动化的首选框架。pytest提供了更丰富的功能，相对的上手难度也要高一点。如果学了pytest后，想快速用pytest写项目，用于工作实践，那么可以试试我写的这款测试工具：tep，try easy pytest。

功能测试用例自动生成算法Pairwise工具

Fri, 02 Jan 2026 00:00:00 +0000

Pairwise算法是什么

对于以下测试场景：

浏览器：M，O，P
操作平台：W（windows），L（linux），i（ios）
语言：C（chinese），E（english）

该如何设计功能测试用例呢？

根据数学统计分析，73%的缺陷（单因子是35%，双因子是38%）是由单因子或2个因子相互作用产生的。19%的缺陷是由3个因子相互作用产生的。也就是说，大多数的bug都是条件的两两组合造成的。

Pairwise算法是L. L. Thurstone在1927年首先提出来的，他是美国的一位心理统计学家。Pairwise算法基于两两组合，过滤出性价比高的用例集。它的思路是：如果某一组用例的两两组合结果，在其他组合中均出现，就删除该组用例，从而精简用例。

对于上述测试场景，可以通过笛卡尔积设计18条两两组合的测试用例：

1，M W C
2，M W E
3，M L C
4，M L E
5，M I C
6，M I E
7，O W C
8，O W E
9，O L C
10，O L E
11，O I C
12，O I E
13，P W C
14，P W E
15，P L C
16，P L E
17，P I C
18，P I E

对于第18条用例P I E来说，两两组合是PI ，PE ，IE，PI在17号，PE在16号，IE在12号出现过，所以第18条用例可以过滤掉。按照这个算法继续过滤，最终剩下9条用例：

坚持开发原创测试平台

Fri, 02 Jan 2026 00:00:00 +0000

不管测试平台有没有实际用处，具备测试平台开发能力，是测试开发工程师的必备技能之一。 测试平台的实际收益有多少，仁者见仁智者见智，这是一个辩证问题。测试平台开发能力是否具备，一清二楚，这是一个现实问题。我们能做的只有提高自己，解决现实问题。

学习版pytest内核测试平台开发万字长文入门篇

Fri, 02 Jan 2026 00:00:00 +0000

前言

2021年，测试平台如雨后春笋般冒了出来，我就是其中一员，写了一款pytest内核测试平台，在公司落地。分享出来后，有同学觉得挺不错，希望能开源，本着“公司代码不要传到网上去，以免引起不必要麻烦”的原则，只能在家从头写一个，边重新梳理代码边温习巩固知识点，以学习交流为目的，定义为“学习版”。

功能展示

接口自动化

接口自动化–Dashboard：

接口自动化–环境变量：

接口自动化–fixtures：

接口自动化–用例管理：

接口自动化–用例管理–编辑用例：

接口自动化–测试计划：

接口自动化–语法说明：

小工具

小工具–共享脚本：

小工具–HTTP状态查询：

后台管理

后台管理–用户管理

后台管理–项目管理

本文开发内容

登录，登出
首页，修改密码，个人信息
后台管理，用户管理
JWT认证

本文先打个基础，既是测试平台基本结构，也可以作为CMS基础框架，定制开发各种小型项目。

技术栈

Node.js 12.16.3
Vue 4.5.11
Python 3.8
Django 3.1.3
Django REST framework 3.12.2
SQLite 3

IDE编辑器推荐PyCharm旗舰版，既能写Django也能写Vue项目。数据库使用Django自带SQLite ，省去安装MySQL和Navicat/Workbench麻烦，轻量级开发。SQLiteStudio为SQLite数据库可视化工具，只需要下载即可，无需安装，解压就用：：

https://sqlitestudio.pl/

由于会用到models.JSONField，SQLite默认不兼容，所以需要下载sqlite3.dll文件替换下：

https://www.sqlite.org/download.html

根据Python版本选择，比如我的windows安装的Python38-32，下载了sqlite-dll-win32-x86-3340100.zip这个软件包，解压后将D:\Program Files (x86)\Python38-32\DLLs\sqlite3.dll替换。

创建Vue项目

设置npm淘宝镜像：

npm config set registry https://registry.npm.taobao.org

安装Vue CLI：

npm install -g @vue/cli

创建teprunner-frontend项目：

EasyPytest测试平台开发日志之系统设计

Thu, 01 Jan 2026 00:00:00 +0000

EasyPytest测试平台，帮你高效管理Pytest测试用例。

japi项目需求分析阶段

Thu, 01 Jan 2026 00:00:00 +0000

项目简介

japi项目，是一个接口自动化平台开发项目，由【交流群】招人共建，基于JMeter，参考MeterSphere，以学习为目的，完成一个SpringBoot+Vue技术栈的纯粹的接口自动化平台开发。

项目成员

经过"填写人员分工表"以后，最终有38人参与了本次项目：

刚哥、布鲁、嘉宥、守正、大刚、风雨、奉孝、大姚、畅月、渔夫、小禹、钰琪、天湖、迷龙、肥涵、胖子、局长、呼呼、明亮、安宁、木棉、番茄、玥玥、哈瑞、虚竹、十五、阿新、卡罗、大白、库昊、左右、小涌、古风、玉洁、小韩、小卷、千凝、昆明。

随着项目进行，后续“提交学习总结”等环节层层递进，真正留下来的项目成员，会在GitHub的README中署名。

在填表时收集了大家的历史经验，这里汇总整理了一下，供参考：

“Vue+Django写过测试平台；SpringBoot写过后端应用；Python小工具开发；Python+Pytest+Requests搭建接口自动化框架；Python+Unittest或Pytest自动化测试框架搭建及脚本开发；各类开源自动化测试平台搭建，如：HttpRunnerManager、流马、Yapi、Sonic等；js+Django2实现UI自动化测试平台；使Testng框架进行接口测试；Vue+fastapi写过测试平台；python+selenium UI自动化；python+httprunner，接口文档解析自动生成字段校验用例；python+RobotFramework做过UI；Java做过单元测试，熟悉基础语法；学过JavaSE，JavaEE，实战经验不多；Python Pyqt GUI工具开发；Python 接口自动化、APP自动化框架设计及编码；独立负责主导Python+Locust性能测试；三方库和标准库：unittest、pytest、appium、selenium、request、httprunner；画过简单的html、css；App UI自动化框架搭建：pytest+appium+allure+jenkins接口自动化框架搭建：pytest+request+allure+jenkins二次开发及维护过flask+vue接口测试平台；二次开发及维护过springboot+angularUI测试平台；Pytest+Playwright UI自动化脚本编写；”

我总结了几个关键字：Vue、Django、SpringBoot、Flask、FastAPI、ElementUI、RobotFramework、脚本开发、工具开发、平台开发、接口自动化、UI自动化、APP自动化。

项目计划

招募，人员分工，需求分析，设计，编码，测试，上线。

由于是以学习为目的，加上都是业余时间投入，也有其他事情要忙，所以该项目不会像真正项目那样，设置里程碑和交付节点，会给足够的学习时间，战线拉得比较长，过程大于结果。

需求分析

MeterSphere官方给出的功能列表，接口自动化相关的模块有接口定义和接口自动化。

接口定义包括以下功能：

在线添加并编辑接口定义; 以树状形式展示项目的模块及对应接口; 支持HTTP、Dubbo、SQL、TCP类型接口请求; 支持通过MeterSphere Json、Postman、Swagger 等多种格式文件快速导入接口，Swagger可通过URL定时同步; 支持接口快捷调试; 根据接口定义快速配置HTTP、TCP协议Mock服务; API列表、CASE列表、文档模式多种模式灵活切换; 接口页面API、TEST、CASE、MOCK多种操作灵活切换; 测试环境信息管理功能; 单接口用例支持引用环境; 支持正则匹配、jsonpath、xpath等多种类型的断言规则; 支持正则匹配、jsonpath、xpath等多种类型的参数提取; 支持BeanShell、Python、Groovy、JavaScript等多种语言的前后置脚本; 支持前置SQL、后置SQL; 支持上传并引用自定义Jar包; 支持查看接口及用例变更历史; 手动执行、定时任务、Jenkins插件触发等多种执行方式; API、CASE一键复制; CASE一键创建性能测试; 接口定义依赖关系设置;

接口自动化包括以下功能：

创建多接口串联的场景化测试; 从接口列表中快速导入接口或接口用例; 跨项目的场景引用功能; 客户端SSL证书认证配置; 场景用例支持引用环境; 支持条件、循环、事务、等待等多种类型的控制器; 支持正则匹配、jsonpath、xpath等多种类型的断言规则; 支持正则匹配、jsonpath、xpath等多种类型的参数提取; 支持BeanShell、Python、Groovy、JavaScript等多种语言的前后置脚本; 场景变量提供多种类型; 提供Mock数据和JMeter变量表达式; 环境配置增加区分模块、路径两种方式添加域名; 增加全局前置脚本、全局后置脚本; 基于插件机制实现其他协议; 支持上传并引用自定义Jar包; 支持查看场景用例变更历史; 手动执行、定时任务、Jenkins插件触发等多种执行方式; 串行、并行两种批量执行方式自由选择; 支持指定测试资源池远程执行; 可多场景串行、并行执行; 场景一键创建性能测试; 场景一键复制; 场景批量执行可自由选择独立报告或集合报告; 场景一键添加到测试计划；

除此之外还有：

JSON转SQL小工具源码分享

Thu, 01 Jan 2026 00:00:00 +0000

将key-value的JSON数据，转换为insert的SQL语句，进而实现网页数据存储到数据库。

pytest内核测试平台落地初体验

Thu, 01 Jan 2026 00:00:00 +0000

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

tep首次开源V0.2.3介绍

Thu, 01 Jan 2026 00:00:00 +0000

『 tep is a testing tool to help you write pytest more easily. Try Easy Pytest! 』

聚焦于任务调度的测试平台pytestx

Thu, 01 Jan 2026 00:00:00 +0000

设计理念

聚焦于任务调度，接口自动化80%本地编写，20%交由平台管理。

如果使用pytest做接口自动化，那么个人认为最好的编写工具是PyCharm，任何低代码测试平台都无法取代。当然不会代码，或者不使用pytest，那低代码测试平台，或者yaml，甚至excel写自动化用例，都是可以接受的。而在使用pytest这个特定场景里面，要做平台化，平台的功能就需要仔细斟酌。既然编写用例最好使用PyCharm，平台也就只能专注于用例编排和任务调度，即创建任务，关联用例，批量运行，以及定时，并行，通知等。

pytestx正是基于此理念设计的一款纯粹的任务调度平台。

平台架构

tep1.0.0的延续

tep1.0.0版本已经封版，在pytestx中对它进行了延续。

从pypi到git

tep是上传到pypi的，通过pip命令安装，使用tep startproject命令创建项目脚手架，代码结构分为项目代码和tep代码。改造后的tep只有项目代码，存放在：

https://gitee.com/dongfanger/tep-project.git

也就是说，在这个项目中，能看到整个tep全貌。之前的tep内核代码，比如fixtures自动寻找、内置fixture、环境变量等，全部迁移到了项目代码里面，尤其是conftest.py的文件内容。pip install tep顺带安装的依赖包，也整理到了requirements.txt，按照说明安装即可。

pytest-html替换allure

由重到轻，化繁为简，pytest-html能够满足数据+日志的报告需要，最新的V3.2.0版本的界面尚可。诚然allure漂亮，但安装Java、下载Allure、配置环境变量、安装pytest-allure、添加pytest hook还是相对麻烦。更重要的是，要支持平台在线查看报告，减少存储占用，pytest-html无疑是更好的选择。

下载脚手架

既可以从使用git clone下载代码，也可以从页面下载，就像spring.io那样：

fastapi到django

之前的示例代码是调用的fastapi启动的应用，pytestx则将示例代码的接口换成了Django自身的mock接口。

teprunner的延续

pytestx的基础代码是从teprunner来的，对数据库设计、代码规范、项目结构做了优化。

任务管理

一、同步项目

同步项目，是把项目配置的Git仓库地址和分支，更新到本地沙箱中，项目之间完全隔离。

并把用例落库：

二、任务关联用例

创建任务，任务关联用例，就形成了新的用例集。

三、容器化运行

当前是假容器，未真正引入Docker，所谓容器，是指每次运行，都将用例拉取到新的目录，批量执行：

四、生成报告

pytest命令生成html报告，存放于reports，借助于Django挂载页面，从页面点击，在线查看报告：

体验平台

下载源码：https://github.com/dongfanger/pytestx

安装依赖：前端（npm install）后端（pip install -r requirements.txt）

启动服务：前端（npm run serve）后端（python manage.py runserver）

即可畅快体验。

学习交流

添加微信cekaigang，加入交流群，欢快讨论吧。