简介基于Vue和Python构建的免费开源接口自动化测试平台设计源码面向接口测试工程师、前端开发者及测试平台二次开发人员支持单接口与多场景串联、接口间数据依赖、延迟调用、性能测试、定时任务、模拟接口数据、测试数据与用例分离等完整功能。压缩包共462个文件大小26.26MB核心文件包括57个Python后端逻辑文件、39个Vue前端组件、90个JS交互脚本、97个CSS样式文件以及图片、说明文档、矢量图标等辅助内容前后端分离架构清晰目录含后端、前端、部署等模块并附Docker部署文件便于快速搭建开发与测试环境。已有671人学习下载。项目通过Python处理接口请求发送、响应接收与断言执行Vue界面简化了配置和报告查看流程使用文档与目录结构能帮助读者快速上手开源许可声明清晰便于按需扩展、定制或集成到现有研发流程。 接口自动化测试这件事做浅了就是一堆Postman集合做深了就是一套完整平台。我在不同项目里见过太多种落地方式有人用Excel维护用例跑挂了就翻日志有人在JMeter里写断言报告全靠截图还有人直接用Python脚本一把梭代码和用例完全耦合在一起。这些方案不是不能用但随着接口数量上来维护成本高到让人崩溃。所以我自己动手写了一套免费开源的接口自动化测试平台前端用Vue 3后端用Python FastAPI核心只解决三件事用例低成本维护、执行结果可视化、团队快速上手。这篇文章会把平台的设计思路、核心源码结构以及二次开发时最容易踩的坑完整讲清楚。无论你是测试开发工程师还是后端想搭一套内部工具都可以直接参考甚至拿源码去改造。1. 为什么我用了 Vue Python 这个组合而不是直接上现成平台1.1 现成平台的尴尬很多人提到接口自动化测试第一反应是去部署一套现成的开源平台。市面上确实有功能完整的方案但中小团队实际用起来会遇到两个硬伤一是技术栈偏重部署一套Java微服务加前端工程再加数据库光环境准备就能折腾一两天二是二次开发门槛太高改一个小功能要翻半天源码团队根本不敢动。我自己是从测试转过来的最清楚这种痛。团队需要的不是功能最全的平台而是一个接口用例能集中管理、环境能一键切换、报告能自动生成、代码还看得懂的轻量级工具。这个定位听起来简单但市面上的方案总有一头不满足要么太重要么太封闭。1.2 技术选型背后的理由后端选Python原因是写起来快而且生态里和接口测试关系最密切。requests库做HTTP调用基本是大半个测试行业的默认选择断言、数据提取的代码可以写得很简洁如果后续要做数据驱动、跟CI/CD集成Python脚本也可以嵌入到流水线的任意环节。后端框架我选了FastAPI而不是Flask或Django。原因有三个自带OpenAPI接口文档前端联调时直接打开/docs就能看到所有接口定义原生支持异步执行并发测试任务时不容易卡死基于Pydantic做参数校验前端传过来的用例数据结构不对会自动报错省掉一大堆手写校验逻辑。前端选Vue 3加TypeScript。Vue的响应式数据流在编辑测试用例这种表单密集场景下非常顺手Element Plus把表格、树形控件、弹窗、表单都覆盖了做后台管理界面效率很高Vue全家桶Router、Pinia、Axios组合的开发门槛相对低测试和运维的同事要改前端界面也更容易上手。我常用的选型对比大致是这样模块我的选型理由后端框架FastAPI自带接口文档、异步支持、Pydantic校验HTTP调用requests测试行业默认扩展方便前端框架Vue 3 Element Plus组件生态成熟表单场景效率高数据库SQLite起步可切换MySQL轻量优先量大了再换任务调度APScheduler比Celery轻中小项目够用我没有采用微前端或者重型状态管理方案因为这套平台的复杂度远没到那个程度。很多项目死在过度设计上平台类工具最重要的就是简单到大家都愿意用。1.3 平台的边界定位这套平台面向的是中小团队的接口回归测试和冒烟测试场景重点做用例集中管理、跑完有报告、失败能定位这个闭环。它不是压测平台也不会替代Postman做日常调试——那是另一个维度的事情。把边界明确之后所有设计都围绕轻量、可读、可改三个词展开。后面我会从项目结构、后端核心、前端核心再到部署和二次开发把整套源码的思路完整讲一下。2. 项目目录和用例模型先定约束再写功能2.1 前后端目录怎么分一个开源项目能不能让人看下去第一印象就是目录结构。我见过太多项目把代码堆在几个模块里几个月后连作者自己都找不到逻辑。这套平台的后端目录是这样划分的backend/ ├── app/ │ ├── main.py # FastAPI入口 │ ├── core/ │ │ ├── config.py # 全局配置(数据库、token密钥、文件存储目录) │ │ └── security.py # 用户认证相关 │ ├── api/ │ │ ├── testcase.py # 用例相关接口 │ │ ├── execute.py # 执行相关接口 │ │ ├── report.py # 报告相关接口 │ │ └── env.py # 环境配置相关接口 │ ├── models/ │ │ └── schemas.py # Pydantic模型定义 │ ├── services/ │ │ ├── executor.py # 测试执行引擎 │ │ ├── assertion.py # 断言服务 │ │ ├── extractor.py # 数据提取服务 │ │ └── report_gen.py # 报告生成服务 │ └── database.py # 数据库连接 ├── requirements.txt └── run.py这样划分之后每个文件的职责基本能从名字看出来。开发中我特别强调一个原则路由层不要写业务逻辑业务逻辑全部放services层。好处是后面你要加命令行入口或者定时任务入口直接调用services层就好不需要走HTTP。前端同样讲究分层src/api统一封装后端接口请求src/views放页面级组件src/components放可复用组件src/stores放Pinia状态src/router管路由。合理拆分组件比写一个超级页面重要得多这一点在多人协作时尤其明显。2.2 测试用例数据模型的设计取舍测试用例是整个平台的核心。一个用例怎么建模直接决定执行引擎怎么写也决定前端用例编辑器长什么样。我最终确定的是一个用例包含多个步骤的模式而不是一个HTTP请求就是一个用例。原因是真实接口测试里存在大量依赖关系先登录拿token再创建订单再查询订单。如果把每个请求都独立成用例token不知道该存在哪里串联会非常痛苦。所以模型是这样设计的# app/models/schemas.py 关键模型 from pydantic import BaseModel from typing import List, Optional, Dict, Any class Step(BaseModel): name: str # 步骤名称 method: str # HTTP方法 url: str # 接口地址 headers: Optional[Dict[str, Any]] {} # 请求头 params: Optional[Dict[str, Any]] {} # query参数 body: Optional[Dict[str, Any]] None # 请求体(支持json/form) extract: Optional[List[Dict]] [] # 提取字段列表 assertions: Optional[List[Dict]] [] # 断言列表 sleep: float 0 # 步骤间延时 class TestCase(BaseModel): name: str description: str env: str dev # 默认使用环境 variables: Optional[Dict[str, Any]] {} # 用例级变量 steps: List[Step] priority: str P1 # 优先级P0/P1/P2这个模型里几个字段值得说明extract是列表结构每个元素表示从本次响应中提取某个值命名为某个变量assertions也是列表结构每个元素表示一条断言sleep字段是踩过坑之后加的有些接口处理是异步的下单后立刻查询会查不到加一个可选的延时字段执行引擎按顺序执行时自动sleep比在用例里硬编码时间戳规范得多。前端编辑器和后端执行引擎都是围绕这套模型展开的。模型不复杂但它是整个系统稳定运行的前提。2.3 环境配置与变量池设计接口测试最怕的是改完测试环境结果把生产环境也带崩了。所以平台的环境配置模块单独拎出来支持配置多套环境dev、test、staging、prod。每个环境下面维护base_url、账号、密码、公共请求头这些信息用例里的URL只写相对路径执行时由引擎把环境的base_url拼上去。有了这层抽象一套用例可以在多个环境之间来回跑只需要在执行时选择环境即可不用改任何用例内容。执行时还有一个全局变量池的概念环境配置里的变量和用例里的variables会合并进变量池每个步骤的提取结果也写入变量池。这个设计让环境差异和用例逻辑彻底解耦——开发环境连开发库测试环境连测试库但用例内容一个字都不用改。3. 后端执行引擎请求、提取、断言的三步流水线3.1 执行引擎整体流程执行引擎是平台里技术含量最高的部分。它的核心逻辑是一条流水线变量解析、发送请求、提取数据、执行断言、生成报告。具体流程如下加载用例和当前环境配置把所有变量合并到变量池。遍历用例的每一步先做变量替换把url、body、headers里的${变量名}替换成变量池中的实际值。用requests发送请求。根据步骤的extract配置从响应中提取字段写入变量池。根据步骤的assertions配置执行断言记录通过或失败。处理完所有步骤后汇总生成报告。这个流程看着简单真正做起来有几个细节很容易出错下面重点说变量替换和数据提取。3.2 变量替换与数据提取的实现接口测试里最常用的功能就是上下文传参。比如登录后把token提取出来后续请求都要带上。我实现了两种提取方式JSONPath和正则表达式。JSONPath适合JSON响应用$.data.token这样的语法取嵌套字段非常直观正则是兜底方案响应是文本或者需要从一个HTML页面里取隐藏字段时也能处理。提取结果统一放入变量池下一步直接用${变量名}引用。跨请求的数据传递因此变得非常灵活。核心的变量替换逻辑是一个递归函数import re from typing import Any, Dict def replace_variables(data: Any, variables: Dict[str, Any]) - Any: 递归替换 data 中所有字符串里的 ${var} 占位符 if isinstance(data, str): def repl(match): var_name match.group(1) value variables.get(var_name, ) return str(value if value is not None else ) return re.sub(r\$\{(\w)\}, repl, data) elif isinstance(data, dict): return {k: replace_variables(v, variables) for k, v in data.items()} elif isinstance(data, list): return [replace_variables(item, variables) for item in data] return data这段递归函数几乎是所有接口自动化平台都离不开的。关键点在于占位符格式必须统一我定的是${variable}前端编辑时提示更友好后端正则处理也简单。如果你要自己扩展注意嵌套结构里也要递归处理否则body里的变量漏替换是最常见的bug。3.3 断言机制与并发执行接口测试里的断言其实就那么几类不需要设计得太复杂。我实现的基础断言类型如下断言类型含义示例status_codeHTTP状态码200, 201json_equalJSON字段精确匹配{code: 0}json_containsJSON路径存在$.data.tokenresponse_time响应时间上限1000(毫秒)regex_match正则匹配响应体包含指定模式我要特别强调一点很多人写接口断言只查status_code但接口返回200不代表业务成功了异常提示时状态码往往也是200。所以我实际使用中把断言拆成三层第一层状态码断言第二层业务成功标识断言比如JSON中code字段是否等于0第三层关键业务字段断言比如列表长度是否大于0、用户ID是否已生成。三层检查下来才算完整验证了一个接口。并发执行方面我引入了ThreadPoolExecutor做多线程执行默认并发数控制在5避免把测试环境打爆。每个请求都设置超时默认10秒。这两点是线上跑出来的教训并发太高目标服务直接拒绝连接报告全红不设超时一个假死接口会拖到整个任务超时后面所有用例全卡住。4. 前端核心Vue 3 Element Plus 把用例编辑做到顺手4.1 用例编辑器怎么设计后端执行引擎的难度在逻辑前端最难的是用例编辑器。一个用例少则一两个步骤多则十几个步骤每个步骤又要填URL、请求头、参数、提取、断言这些信息。如果全部用普通表单堆出来页面会非常长填起来体验很差用户根本不愿意维护。我的方案是左侧步骤列表 右侧步骤属性编辑的布局类似Postman的编辑体验。左侧是一个步骤列表每个步骤一行支持拖拽排序、点击切换、右键复制和删除右侧是选中步骤的属性表单按请求信息、数据提取、断言、延时四个Tab分组。body参数做了JSON格式和Key-Value格式两种编辑模式因为有的接口是restful风格的JSON请求体有的还是传统form表单两者都得支持。核心是把StepEditor封装成一个独立组件根据当前步骤的method类型动态渲染不同的表单字段。这个组件写好了用例编辑体验就顺了一大半。4.2 试运行与实时执行反馈用过Postman的人都知道写接口时要立刻看响应结果不然根本不知道请求对不对。所以平台里做了一个单步试运行功能在步骤编辑时点试运行前端直接调用后端/api/execute/step接口后端执行完单个步骤并把响应体、状态码、耗时返回前端显示在页面下方。这个功能改起来不复杂但直接决定平台好不好用。没有它每次调一个用例都得等整条跑完才能看到结果排错效率会特别低。任务级执行时我用了WebSocket推送执行日志而不是轮询。前端ExecLogPanel组件监听WebSocket的message事件每跑完一个步骤就往日志面板追加一行状态。用WebSocket的优势是延迟低、不占多余请求而且用户能看到正在执行第3个步骤这样的实时状态不会以为跑挂了。4.3 报告页面的可视化与通知报告部分用ECharts做了几个基础图表通过率饼图、失败用例列表、每个步骤的耗时柱状图。报告页面尽量做到一看就懂顶部是本次执行的总体信息包括总用例数、通过数、失败数、通过率、耗时中间是按模块分组的失败用例列表点开任意失败用例能看到失败步骤和断言信息底部是响应时间分布图。后续要接企业微信或钉钉通知只需要在报告模块加一个webhook配置即可。平台本身不把通知渠道写死避免依赖具体的通信工具。5. 快速启动、常见坑和二次开发建议5.1 本地快速启动后端启动很简单创建一个虚拟环境装依赖然后跑起来cd backend pip install -r requirements.txt python run.py启动后浏览器打开http://127.0.0.1:8000/docsFastAPI自动生成的接口文档就能直接用每个接口都能在线调试。前端启动cd frontend npm install npm run dev访问http://127.0.0.1:5173默认账号admin/admin123登录就可以开始创建用例了。5.2 踩过的四个坑第一个是跨域问题。前端vite运行在5173端口后端在8000端口浏览器默认会拦截跨域请求。解决方式是在后端加CORS中间件允许前端地址访问。如果你自己二次开发记得修改前端的baseURL配置为后端真实地址。第二个是Python版本。FastAPI新版本对Python版本要求比较高建议直接用Python 3.10以上。我在一台老服务器上装过Python 3.7跑起来一堆兼容问题后来干脆升级环境才解决。第三个是Node版本。Vite 4以上需要Node 14.18最好直接用Node 16或18。很多npm install报错其实都是node版本不对引起的这个坑比后端多得多。注意遇到npm install报错先检查node -v是不是满足要求别一上来就卸载重装依赖。第四个是数据库初始化。平台默认使用SQLite零配置即可运行但部署到正式环境建议改成MySQL把数据库连接串配置到环境变量里不要写死在代码里。5.3 二次开发从哪里入手如果你是第一次拿到这套源码建议按这个顺序读先读backend/app/models/schemas.py理解用例数据模型再读backend/app/services/executor.py理解执行引擎然后读frontend/src/views/CaseEdit.vue对应前端编辑界面最后看stores目录理解状态流转。二次开发的第一件事我建议不要急着加功能而是先跑通一个最简单的用例用浏览器调试工具看完整请求链路是什么样。把链路摸熟了后面改任何模块都有底气。最后再分享一个小技巧如果你要在团队里推广这套平台不要一上来就让所有人去配环境。先在服务器上部署一套共享实例把登录、环境配置、几个典型用例都垫好让同事打开浏览器就能看到现成的报告。工具这东西用顺手了才有继续折腾的兴趣。平台本身是开源的跑起来只是第一步真正有价值的部分是你们团队沉淀下来的那批用例。本文还有配套的精品资源点击获取