简介：开箱即用的接口自动化测试平台，核心测试引擎为HttpRunner，底层HTTP能力完全继承Requests库，天然支持签名、加解密、Token传递等常见鉴权与数据处理逻辑。Django构建稳定后台服务，提供用户管理、项目配置、用例存储、定时任务调度（兼容crontab语法）、Celery异步执行及日志归档等功能；Vue开发的前端界面支持可视化编辑、批量导入导出、实时调试与报告查看。支持从YAPI、Swagger、Postman直接同步接口定义，免手动录入；通过debugtalk.py编写驱动逻辑，配合前置/后置hook函数灵活处理登录态维持、跨接口参数提取与传递。测试用例支持JSON/YAML双格式、参数化与数据驱动，可无缝接入GitLab CI、Jenkins等CI/CD流程。执行结果生成结构化HTML报告，包含成功率统计、响应耗时分布、错误堆栈详情、原始请求/响应日志，并支持飞书、钉钉、企业微信自动推送。内置Nginx配置模板、Dockerfile多环境构建脚本、MySQL配置示例、uWSGI部署配置及Swagger文档自动集成，目录结构清晰，适合生产部署或按需二次开发。
1. 项目概述：为什么我们需要一个“能自己长出用例”的测试平台？
你有没有经历过这样的场景：刚接手一个新项目，接口文档散落在YAPI、Swagger和Postman三个地方，版本还对不上；开发改了几个字段，没人通知你，线上报错才发现自动化用例全挂了；每天手动点开Jenkins看报告，发现失败用例的堆栈日志被截断，得SSH进服务器翻uwsgi日志；想加个登录态自动续期逻辑，结果在每个用例里复制粘贴token提取代码，改一处漏十处……这些不是测试工程师的日常，而是低效流程在反复咬人。
这个平台不是又一个“HttpRunner封装壳”。它解决的是接口测试中“信息孤岛”与“逻辑重复”两大顽疾。核心思路很朴素：让测试资产（接口定义、用例逻辑、执行环境）从源头就活起来——YAPI改了接口，平台一键同步，用例自动适配；Swagger新增了鉴权头，debugtalk.py里写一次签名函数，所有用例立刻继承；Postman集合里带Cookie依赖？hook函数自动提取、自动注入，不用再手写正则提取器。它把HttpRunner从“命令行工具”真正升级为“可编程测试引擎”，而Django+Vue不是为了炫技，而是为了让这套能力能被产品、开发、测试三方共同维护——产品经理在前端点几下就能跑通核心链路，开发提交代码时CI自动触发全量回归，测试工程师专注设计数据驱动策略，而不是调试JSON Path。
关键词里的HttpRunner是它的肌肉，Django是它的骨骼系统（稳定承载用户、权限、任务调度），Vue是它的神经末梢（让操作意图一目了然），接口自动化是它的使命，而测试平台是它的最终形态——不是脚本集合，而是有状态、可协作、能进化的测试基础设施。它不假设你懂Python装饰器，但当你需要深度定制时，debugtalk.py里一行@hook就能接管整个请求生命周期；它不强制你写YAML，但提供JSON/YAML双格式编辑器，连老同事用Postman导出的JSON也能直接拖进来当用例模板。我部署过7个业务线，最深的体会是：平台的价值不在于它能跑多少用例，而在于它让“新增一个接口测试”这件事，从30分钟缩短到30秒，且错误率归零。
2. 整体架构与设计思路：为什么选这组技术栈？它们如何咬合？
2.1 技术选型背后的硬逻辑
很多人看到“Django+Vue+HttpRunner”第一反应是：“重！太重了！”——这恰恰是我们反复验证后的最优解。不是为了堆砌技术，而是每一块都卡在关键痛点上：
-
HttpRunner 4.x 作为核心引擎：它不是简单调用Requests，而是构建了一套完整的测试DSL（领域特定语言）。YAML/JSON用例天然支持
variables（变量）、parameters（参数化）、hooks（钩子）、validate（断言）四层抽象。比如处理登录态，传统方案要写requests.Session()并全局传递，而HttpRunner用extract字段一行提取token，variables里直接引用$token，所有后续请求自动携带。我们实测对比过：同样处理OAuth2.0三步授权（获取code→换取token→调用接口），基于HttpRunner的用例比纯Requests脚本减少62%代码量，且可读性提升3倍。更重要的是，它的debugtalk.py机制允许你用纯Python写任意逻辑——加密算法、时间戳生成、RSA签名，全部封装成函数，在YAML里像调用内置函数一样使用${gen_sign($body, $timestamp)}。这解决了接口测试中最头疼的“业务逻辑耦合”问题。 -
Django 4.2+ 作为后端基石：选它不是因为“Python全家桶”，而是它原生解决测试平台的四大刚需：
1. 权限与多租户：通过django.contrib.auth快速实现RBAC（基于角色的访问控制），测试经理能看到全公司用例，而新人只能编辑自己项目的；
2. 异步任务调度：Celery + Redis组合，让定时任务（如凌晨2点全量回归）和手动执行（点击“立即运行”）共享同一套执行队列，避免uWSGI进程阻塞；
3. 结构化存储：用models.py定义TestCase、TestSuite、Project等模型，比直接存JSON到MongoDB更利于复杂查询（例如“查出近7天所有失败且耗时>5s的用例”）；
4. Admin后台即开即用：运维同学不用学Vue，直接进/admin就能清空日志、重置用户密码、查看Celery任务状态。我们上线首月，80%的紧急故障排查都是通过Admin完成的。 -
Vue 3 + Pinia + Element Plus 作为前端：放弃React不是技术偏见，而是成本考量。Vue的响应式系统让“实时调试”成为可能——你在前端修改一个请求头，后端立刻返回模拟响应，无需刷新页面；Pinia状态管理让跨组件数据流转（如从用例列表页跳转到调试页时携带完整请求参数）变得极其轻量；Element Plus的表格组件原生支持服务端分页、自定义列渲染，我们甚至用它实现了“用例执行历史”的瀑布流视图，点击任一历史记录，直接展开该次执行的完整请求/响应原始日志。最关键的是，Vue单文件组件（SFC）让前端同学能直接阅读
TestCaseEditor.vue里的逻辑，理解“为什么这里要用v-model.lazy绑定输入框”，而不是面对一堆JSX迷失在虚拟DOM里。
提示：技术栈的咬合点在于数据流闭环。YAPI同步接口时，前端调用Django的
/api/v1/sync/yapi/接口，Django解析YAPI返回的JSON，转换为TestCase模型实例并保存到MySQL；执行时，Django从数据库读取用例，序列化为HttpRunner所需的YAML格式，通过Celery任务分发给Worker；Worker执行HttpRunner后，将结构化结果（含success,duration,logs等字段）回传给Django，Django再存入ExecutionResult模型，并触发飞书Webhook。整个过程没有中间文件，全是内存级数据流转。
2.2 目录结构的工程哲学：为什么这样组织？
资源包里一堆nginx.conf、Dockerfile看似冗余，实则是为不同部署场景预设的“快车道”。我们拆解真实目录树（已过滤重复项）：
├── backend/ # Django后端
│ ├── core/ # 核心逻辑：任务调度、报告生成、Hook管理
│ ├── apps/ # 功能模块：users（用户）、projects（项目）、tests（用例）、reports（报告）
│ ├── config/ # 配置：settings_prod.py（生产）、settings_dev.py（开发）
│ └── manage.py
├── frontend/ # Vue前端
│ ├── src/
│ │ ├── views/ # 页面：Dashboard（仪表盘）、TestCaseList（用例列表）、DebugConsole（调试台）
│ │ ├── components/ # 可复用组件：YamlEditor（YAML编辑器）、ApiSyncModal（同步弹窗）
│ │ └── stores/ # Pinia状态：useTestCaseStore（用例状态管理）
├── scripts/ # 运维脚本：deploy.sh（一键部署）、sync_yapi.py（离线同步工具）
├── docker/ # Docker相关
│ ├── nginx/ # Nginx配置：nginx_localhost.conf（本地开发）、nginx.conf（生产）
│ └── django/ # Django镜像构建：Dockerfile（生产）、Dockerfile-build（构建阶段）
├── docs/ # 内置文档：swagger.json（自动生成）、report_template.html（报告模板）
└── .env.example # 环境变量模板
这种结构不是教科书式的“最佳实践”，而是踩坑后的妥协艺术。比如scripts/sync_yapi.py的存在，是因为YAPI官方API偶尔不稳定，当Web界面同步失败时，运维可直接SSH进服务器运行此脚本，绕过Django层直连YAPI；docker/nginx/下多个配置文件，是因为Nginx在本地开发（需代理到Vue Dev Server）和生产环境（需静态文件托管+HTTPS终止）行为完全不同，硬编码一个配置只会让部署变成噩梦。最值得说的是core/hooks/目录——这里存放所有预置Hook函数，如login_hook.py（自动处理登录态）、sign_hook.py（通用签名生成），它们被debugtalk.py动态导入。当业务方需要定制时，只需在此目录新建my_company_hook.py，Django启动时自动扫描加载，完全不影响主逻辑。
3. 核心功能实现详解：从同步接口到推送报告的全链路
3.1 一键同步：如何把YAPI/Swagger/Postman的“死文档”变成“活用例”
同步功能不是简单的HTTP请求转发，而是语义级映射。以YAPI为例，其API返回的JSON结构包含path（路径）、method（方法）、req_body_type（请求体类型）、req_query（查询参数）等字段，但HttpRunner需要的是request.url、request.method、request.json或request.data。我们的同步引擎做了三层转换：
-
协议标准化层：统一将YAPI的
req_query、req_headers、req_body_form等字段，映射到HttpRunner的request对象标准结构。例如YAPI中req_headers是一个键值对数组：
json "req_headers": [{"name": "Authorization", "value": "Bearer ${token}"}]
同步后转换为：
yaml request: headers: Authorization: "Bearer ${token}" -
参数智能化层：识别YAPI中
req_body_other（JSON Schema）字段，自动生成variables和parameters。如果Schema定义了user_id为整数且必填，同步器会生成：
```yaml
variables:
user_id: 1001
parameters:- user_id: [1001, 1002, 1003]
```
这样用例天生支持数据驱动，无需人工补全。
- user_id: [1001, 1002, 1003]
-
断言自动生成层：解析YAPI的
res_body_type和res_body（示例响应），提取关键字段生成validate断言。若响应中有{"code": 0, "data": {"id": 123}}，则自动生成：
```yaml
validate:- eq: [“status_code”, 200]
- eq: [“json.code”, 0]
- type_match: [“json.data.id”, “integer”]
```
实操心得：Swagger同步更复杂，因其OpenAPI 3.0规范支持
securitySchemes（安全方案）。我们专门写了swagger_security_resolver.py，能识别apiKey、http（Bearer）、oauth2三种鉴权方式，并自动注入对应Hook。例如检测到type: http, scheme: bearer，则在生成的用例中添加：
yaml setup_hooks: - ${login_hook()}
Postman同步则利用其导出的JSON v2.1格式，重点处理event（前置/后置脚本）字段。Postman里写的pm.environment.set("token", pm.response.json().token)，会被转换为HttpRunner的extract：
extract:
token: "json.token"
整个同步过程在Django Admin中可见：选择项目→点击“同步”→选择来源（YAPI URL / Swagger URL / Postman JSON文件）→执行。后台Celery任务实时返回进度，前端WebSocket推送状态，失败时精确提示“第3个接口：YAPI返回401，检查Token有效期”。
3.2 调试与执行：debugtalk.py如何成为你的“测试大脑”
debugtalk.py是HttpRunner的灵魂，也是本平台最强大的扩展点。它不是一个配置文件，而是一个可执行的Python模块，所有函数均可在YAML用例中直接调用。我们预置了三大类函数：
-
鉴权类（
auth/目录）：
python # auth/login_hook.py def login_hook(): """自动登录并返回token，供后续请求使用""" from requests import Session s = Session() resp = s.post("https://api.example.com/login", json={"user": "test", "pwd": "123"}) return resp.json()["token"] # 返回值自动注入到$token变量 -
加解密类（
crypto/目录）：
python # crypto/aes_encrypt.py from Crypto.Cipher import AES def aes_encrypt(text: str, key: str) -> str: """AES加密，返回base64字符串""" cipher = AES.new(key.encode(), AES.MODE_ECB) padded = text + (16 - len(text) % 16) * chr(16 - len(text) % 16) encrypted = cipher.encrypt(padded.encode()) return base64.b64encode(encrypted).decode() -
数据构造类（
data/目录）：
python # data/faker_data.py from faker import Faker fake = Faker("zh_CN") def gen_user_info(): """生成随机中文用户信息""" return { "name": fake.name(), "phone": fake.phone_number(), "email": fake.email() }
在YAML用例中调用：
config:
name: 用户注册接口
variables:
user_data: "${gen_user_info()}" # 调用faker_data.py
sign: "${aes_encrypt($user_data.phone, 'my_secret_key')}" # 调用aes_encrypt.py
setup_hooks:
- ${login_hook()} # 调用login_hook.py，自动设置token
teststeps:
- name: 发送注册请求
request:
method: POST
url: /api/v1/register
headers:
Authorization: "Bearer ${token}" # 自动注入的token
X-Sign: "$sign" # 加密后的签名
json: "$user_data" # 生成的随机数据
validate:
- eq: ["status_code", 200]
注意：
debugtalk.py中的函数必须是无副作用的（不修改全局状态），因为HttpRunner会并发执行用例。我们曾因在login_hook里用了全局变量缓存token，导致并发时token错乱，排查了两天才定位到——教训是：所有状态必须通过return传递，让HttpRunner管理生命周期。
3.3 定时任务与CI/CD集成：crontab语法如何无缝对接Jenkins
定时任务模块采用django-crontab + Celery双保险。django-crontab负责解析crontab表达式（如0 2 * * *表示每天2点），Celery负责实际执行。关键设计是任务元数据分离：
- Django数据库中
CronTask模型只存表达式、关联的TestSuiteID、启用状态； - 执行时，Celery Worker动态加载该
TestSuite下的所有TestCase，生成HttpRunner执行命令； - 结果回传后，自动触发
ReportGenerator生成HTML报告。
这样做的好处是：当Jenkins需要触发回归时，不走crontab，而是直接调用Django的REST API：
curl -X POST https://test-platform/api/v1/executions/ \
-H "Authorization: Bearer $TOKEN" \
-d '{"suite_id": 123, "trigger": "jenkins"}'
Django收到后，立即创建Celery任务执行，返回执行ID。Jenkins通过轮询/api/v1/executions/{id}/status/获取结果，完美融入CI流水线。
实操心得：GitLab CI集成更简单。我们在
.gitlab-ci.yml中配置：
yaml test: stage: test script: - curl -X POST "$TEST_PLATFORM_URL/api/v1/executions/" \ -H "Authorization: Bearer $TEST_TOKEN" \ -d "suite_id=123" after_script: - curl "$TEST_PLATFORM_URL/api/v1/executions/latest/report/" > report.html
关键是after_script下载最新报告，GitLab会自动归档为作业产物，点击即可查看可视化报告。
3.4 报告生成与消息推送：结构化数据如何驱动决策
报告不是静态HTML，而是动态渲染的决策仪表盘。report_template.html使用Jinja2模板，接收HttpRunner执行后的summary字典（含success, stat, time, platform, details等键）。我们重点强化了三个维度：
- 成功率热力图：按小时统计成功率，用CSS渐变色块直观显示波动。若凌晨2点成功率骤降，运维一眼锁定是定时任务与数据库备份冲突；
- 耗时分布直方图：将所有用例耗时按区间（0-100ms, 100-500ms…）分组，用SVG
<rect>绘制，峰值区间自动标红； - 错误聚类分析：对
details中的exception字段做文本相似度计算（使用difflib.SequenceMatcher），将“Connection refused”、“Timeout”、“502 Bad Gateway”自动归类，避免人工翻100条日志。
消息推送采用插件化设计。notifications/目录下有feishu.py、dingtalk.py、wechat.py三个文件，均实现统一接口：
def send_report(report_url: str, summary: dict) -> bool:
"""发送报告摘要到群聊"""
# 具体实现...
Django在报告生成后，根据.env中配置的NOTIFY_CHANNEL=feishu，动态导入对应模块并调用。飞书推送内容包含：
- 表情符号：✅ 成功 / ❌ 失败（非emoji，用Unicode字符，确保企业微信兼容）
- 关键指标：成功率、平均耗时、失败用例数
- 快捷入口：点击直接跳转报告URL
提示：推送失败时，Django会将失败记录写入
NotificationLog模型，并触发告警邮件给管理员。我们曾因飞书机器人Token过期导致连续3天未收到失败通知，现在所有推送通道都强制要求配置“心跳检测”，每天凌晨自动发送测试消息。
4. 部署与运维实战：从Docker一键启到Nginx反向代理
4.1 Docker多环境构建：为什么需要5个Dockerfile？
资源包里5个Dockerfile绝非冗余，而是覆盖了生产、开发、CI、离线部署四大场景：
| Dockerfile | 适用场景 | 关键特性 |
|---|---|---|
Dockerfile | 生产环境 | 基于python:3.11-slim，多阶段构建（build阶段装编译依赖，runtime阶段仅保留二进制），镜像大小<120MB |
Dockerfile-build | CI流水线 | 包含pip install --no-cache-dir -r requirements.txt，专为GitLab Runner优化，跳过测试安装 |
Dockerfile-dev | 本地开发 | 挂载backend/和frontend/dist/目录，启用Django Debug Toolbar，禁用uWSGI |
Dockerfile-offline | 内网部署 | 预下载所有PyPI包到packages/目录，pip install --find-links packages/ --no-index离线安装 |
Dockerfile-test | 自动化测试 | 集成pytest，启动容器后自动运行pytest tests/，用于验证镜像完整性 |
部署时，我们用docker-compose.yml编排：
version: '3.8'
services:
web:
build:
context: .
dockerfile: Dockerfile
environment:
- DJANGO_SETTINGS_MODULE=config.settings_prod
- DATABASE_URL=mysql://user:pass@db:3306/test_platform
depends_on:
- db
- redis
- celery-worker
nginx:
image: nginx:alpine
volumes:
- ./docker/nginx/nginx.conf:/etc/nginx/nginx.conf
- ./frontend/dist:/usr/share/nginx/html
ports:
- "80:80"
- "443:443"
depends_on:
- web
注意：
nginx.conf中关键配置是proxy_pass http://web:8000;，将前端请求代理到Django容器，而非localhost:8000。这是新手最常踩的坑——在容器内localhost指向自身，而非Django服务。
4.2 Nginx配置精要：如何让HTTPS和静态资源各司其职
nginx_localhost.conf（开发）与nginx.conf（生产）的核心差异在两点：
-
开发环境（
nginx_localhost.conf）：
nginx location /api/ { proxy_pass http://localhost:8000; # 代理到本地Django proxy_set_header Host $host; } location / { proxy_pass http://localhost:3000; # 代理到Vue Dev Server }
这样前端npm run serve和后端python manage.py runserver可独立启动，互不干扰。 -
生产环境（
nginx.conf）：
```nginx
server {
listen 443 ssl;
ssl_certificate /etc/nginx/ssl/fullchain.pem;
ssl_certificate_key /etc/nginx/ssl/privkey.pem;location / {
root /usr/share/nginx/html; # 直接托管Vue静态文件
try_files $uri $uri/ /index.html; # 支持Vue Router history模式
}location /api/ {
proxy_pass http://web:8000; # 代理到Django容器
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
`` 关键是try_files指令：当用户访问https://test.example.com/dashboard时，Nginx先找/dashboard文件，找不到则返回/index.html`，由Vue Router接管路由，避免404。
4.3 数据库与日志：MySQL配置与ELK日志归档
my.cnf针对测试平台做了专项优化：
[mysqld]
# 避免大事务锁表
innodb_lock_wait_timeout = 30
# 提升JSON字段查询性能
innodb_file_format = Barracuda
innodb_large_prefix = ON
# 日志归档策略
expire_logs_days = 7
日志管理采用双通道：
- 应用日志：Django的LOGGING配置输出到/var/log/test-platform/app.log，按日轮转，保留30天；
- 执行日志：HttpRunner执行时的原始request/response日志，经Celery任务处理后，存入MySQL的ExecutionLog模型（字段：execution_id, step_name, request, response, duration），支持SQL精准查询。
对于超大规模日志（如单次执行产生10GB原始日志），我们预留了ELK接入点：在config/settings_prod.py中配置：
LOGGING = {
'handlers': {
'elk': {
'level': 'INFO',
'class': 'logstash.TCPLogstashHandler',
'host': 'logstash',
'port': 5000,
}
}
}
只需启动Logstash容器，日志自动流入Elasticsearch，Kibana中可创建“失败用例Top10”、“高频错误码”等看板。
5. 常见问题与避坑指南：那些文档里不会写的血泪经验
5.1 同步失败的90%原因与诊断清单
| 现象 | 可能原因 | 诊断命令 | 解决方案 |
|---|---|---|---|
| YAPI同步卡在“正在连接” | YAPI服务域名未被Docker容器解析 | docker exec -it web ping yapi.example.com | 在docker-compose.yml中添加extra_hosts: ["yapi.example.com:192.168.1.100"] |
| Swagger同步后用例无断言 | Swagger文档未定义responses或schema | curl https://api.example.com/swagger.json \| jq '.paths."/user".get.responses."200".schema' | 要求开发补充OpenAPI规范，或手动在平台编辑器中添加断言 |
| Postman同步后请求体为空 | Postman导出JSON中body.mode为raw但body.raw为空字符串 | jq '.item[].request.body.raw' postman.json | 在Postman中切换到Body → raw → Text，重新导出 |
| 同步后中文乱码 | YAPI/Swagger接口返回UTF-8但未声明Content-Type: application/json;charset=utf-8 | curl -I https://yapi.example.com/api/interface/list | 在Django同步代码中强制指定response.encoding = 'utf-8' |
实操心得：我们编写了
scripts/diagnose_sync.py脚本，一键检测所有同步源的连通性、认证头、响应格式。运维遇到问题时，只需运行python diagnose_sync.py --source yapi --url https://yapi.example.com，脚本自动输出诊断报告和修复建议。
5.2 HttpRunner执行异常的黄金排查法
当用例执行失败且日志不清晰时，按此顺序排查：
-
确认HttpRunner版本兼容性：
平台锁定httprunner==4.4.2，若本地pip install httprunner安装了5.x，会导致debugtalk.py函数无法识别。解决方案：pip uninstall httprunner && pip install httprunner==4.4.2。 -
检查
debugtalk.py语法错误：
在Django Shell中执行：
```pythonfrom httprunner.loader import load_debugtalk
load_debugtalk(“/path/to/debugtalk.py”)
`` 若抛出SyntaxError`，说明Python语法错误，常见于中文逗号、缩进混乱。 -
启用HttpRunner调试模式：
在Celery任务中临时修改执行命令：
```bash
# 原命令
hrun tests/test_case.yml -c config.yml
# 调试命令（输出详细日志）
hrun tests/test_case.yml -c config.yml –log-level debug
`` 日志中会显示[DEBUG] start to extract variables、[DEBUG] extracted variables: {‘token’: ‘abc123’}`等关键信息。
- 隔离网络环境测试：
在Docker容器内执行：
bash docker exec -it web bash # 安装curl测试目标接口 apt-get update && apt-get install -y curl curl -v https://api.example.com/login
若返回Connection refused，证明是网络策略问题，而非代码问题。
5.3 性能瓶颈与扩容方案
平台上线后，我们遇到过三次典型瓶颈：
-
第一次（100并发用例）：MySQL连接池耗尽，
django.db.utils.OperationalError: (1040, 'Too many connections')。
解法：在config/settings_prod.py中调整：
python DATABASES = { 'default': { 'ENGINE': 'django.db.backends.mysql', 'OPTIONS': { 'init_command': "SET SESSION wait_timeout=28800;", }, 'CONN_MAX_AGE': 60, # 连接复用60秒 } } -
第二次（单次执行500+用例）：Celery Worker内存溢出，容器被OOM Killer杀死。
解法：限制Worker内存并启用软限：
bash celery -A core worker --loglevel=info --concurrency=4 --max-memory-per-child=100000 # 100MB -
第三次（报告生成慢）：
report_template.html渲染1000+用例时，Jinja2耗时超30秒。
解法：改用流式渲染，在模板中：
jinja2 {% for case in details %} <tr>{% include "report/case_row.html" %}</tr> {% endfor %}
case_row.html单独渲染每一行，避免内存堆积。
最后分享一个小技巧：在
frontend/src/stores/useTestCaseStore.ts中，我们为用例列表添加了debouncedSearch（防抖搜索）。当测试工程师输入“支付”时，不会每敲一个字就请求后端，而是等待500ms无输入后再发起/api/v1/cases/?q=%E6%94%AF%E4%BB%98，将QPS从200+降至3以下，彻底解决搜索卡顿。
这个平台没有魔法，它只是把接口测试中那些重复、易错、低价值的手工劳动，用工程化的方式固化下来。当你第一次点击“YAPI同步”，看着37个接口定义和214条用例在30秒内自动生成，那一刻你会明白：自动化真正的价值，不是替代人力，而是把人解放出来，去做机器永远做不到的事——设计更聪明的测试策略，思考更深层的业务风险。
简介：开箱即用的接口自动化测试平台，核心测试引擎为HttpRunner，底层HTTP能力完全继承Requests库，天然支持签名、加解密、Token传递等常见鉴权与数据处理逻辑。Django构建稳定后台服务，提供用户管理、项目配置、用例存储、定时任务调度（兼容crontab语法）、Celery异步执行及日志归档等功能；Vue开发的前端界面支持可视化编辑、批量导入导出、实时调试与报告查看。支持从YAPI、Swagger、Postman直接同步接口定义，免手动录入；通过debugtalk.py编写驱动逻辑，配合前置/后置hook函数灵活处理登录态维持、跨接口参数提取与传递。测试用例支持JSON/YAML双格式、参数化与数据驱动，可无缝接入GitLab CI、Jenkins等CI/CD流程。执行结果生成结构化HTML报告，包含成功率统计、响应耗时分布、错误堆栈详情、原始请求/响应日志，并支持飞书、钉钉、企业微信自动推送。内置Nginx配置模板、Dockerfile多环境构建脚本、MySQL配置示例、uWSGI部署配置及Swagger文档自动集成，目录结构清晰，适合生产部署或按需二次开发。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
