基于AI的智能接口测试平台,支持AI生成测试用例、批量执行、智能结果分析和邮件通知。
- 后端框架: Flask + Blueprint模块化设计
- 消息队列: RabbitMQ (任务分发)
- 缓存系统: Redis (结果存储 + 缓存)
- 异步任务: Celery (后台任务处理)
- 数据库: MySQL (业务数据持久化)
- 监控系统: Prometheus (性能监控)
- AI集成: DeepSeek API (智能分析)
- 开发语言: Python 3.7+
用户创建接口 → AI根据接口内容生成测试用例 →提交批量执行 → Celery异步处理任务 → RabbitMQ任务分发 → 并发执行HTTP请求 → 结果存储Redis → AI分析测试结果 →生成智能报告 → 邮件通知用户
用户管理、应用管理、接口管理、AI用例生成、测试执行、AI结果分析、报告生成、邮件通知
每张表的创建sql文件全部已经导出 测试平台SQL.zip
apps(应用管理):存储应用配置、环境信息、基础URL等应用级别信息
api_interface(接口管理):定义API接口信息、请求参数、响应结构、接口路径和方法
api_testcase(测试用例):存储AI生成的测试用例、断言规则、优先级、请求数据
api_testbatch(测试批次):管理批量执行的批次信息、执行状态、汇总统计
api_result(执行结果):记录每次测试执行的详细结果、响应时间、错误信息
logs/
├── service.log # 应用日志
- DEBUG: 详细调试信息
- INFO: 正常业务流程记录
- WARNING: 警告信息,如参数异常、性能问题
- ERROR: 错误信息,如接口调用失败、数据库连接异常
- CRITICAL: 严重错误,系统无法正常运行
完整的Postman测试集合已导出为JSON文件: 接口测试脚本.zip
包含以下测试场景:
- 用户注册登录
- 应用管理
- 接口定义和管理
- AI生成测试用例
- 批量执行测试
- 查询执行结果
- 获取AI分析报告
- 邮件通知测试
# 系统要求
Python >= 3.7
MySQL >= 8.0
Redis >= 6.0
RabbitMQ >= 3.8
# 安装Python依赖
pip install -r requirements.txt
# 启动基础服务
sudo systemctl start mysql redis-server rabbitmq-server
# 初始化数据库
mysql -u root -p < database/init.sql# 1. 启动Celery Worker
celery -A app.celery worker --loglevel=info --detach
# 2. 启动Flask应用
python app.py- 主应用: http://localhost:5000
- Prometheus监控: http://localhost:9091/metrics
- RabbitMQ管理: http://localhost:15672
- Redis监控: redis-cli monitor
使用Locust对平台性能进行测试(针对平台登录接口的测试用例)
- ai测试全流程:生成12个测试用例,完整业务流程平均为64s左右
-

- ai降级测试全流程:表示当ai服务失效,使用模拟生成测试用例(9个)的方式,每个完整业务流程平均为6s左右
-

- 用例执行接口:800个用户,每秒处理350个请求,平均响应为0.4s左右
-

- 在
services/或apis/目录下创建一个新的Python文件,例如new_module.py。
- 在新模块文件中,导入Flask和创建蓝图。示例代码如下:
from flask import Blueprint
# 创建蓝图实例
new_module_blueprint = Blueprint('new_module', __name__)
# 添加路由
@new_module_blueprint.route('/new_route', methods=['GET', 'POST'])
def new_route():
return "This is a new route!"在主程序文件(如 app.py 或者 init.py)中注册新创建的蓝图。确保在Flask应用实例之后进行注册:
from flask import Flask
from apis.new_module import new_module_blueprint
app = Flask(__name__)
# 注册新模块的蓝图
app.register_blueprint(new_module_blueprint)
if __name__ == '__main__':
app.run(debug=True) - 整个平台里最关键的也是花时间最长的部分是关于大模型在测试上的使用。思路是通过大模型帮助接口测试智能化。大模型的具体参与在于测试用例的生成和测试结果的分析。我的目标是生成一份准确、覆盖率高的测试用例,且速度不能太慢。因此,如何选择合适的大模型、如何编写有效的提示词、以及如何解析和补全生成的用例,是整个系统中最关键的问题,同时也是本平台的主要优化方向。
- 在选择大模型时,主要考虑的问题:
- 复杂性与速度:复杂的大模型通常能生成更准确和丰富的测试用例,但可能导致响应速度较慢。简单的蒸馏模型速度快,但可能在准确性和覆盖率上有所欠缺。因此,需要在这两者之间进行权衡。
- 编写有效的提示词是大模型生成高质量用例的关键。提示词应当明确、具体,并包含足够的上下文信息。以下是一些提示词的参考(明确、具体是重中之重,接口测试是比较稳定的、比较简单的任务,不需要大模型的“创造力”,尽量少给模型自由发挥的空间,它的空间越多,需要的去监督调整的人力也就越多):
- 角色设定:明确指定角色,例如“作为资深测试工程师,我需要生成针对用户登录API的测试用例”。
- 具体请求:清晰地描述所需的测试用例类型和覆盖范围,例如“请生成包含边界值和异常情况的测试用例”。
- 格式要求:说明特定格式或结构要求,例如“生成的测试用例应包括输入数据、预期结果和实际结果”。
- 在生成测试用例后,解析和补全能确保用例可用:
- 解析生成的用例:检查生成的用例是否符合预期的格式和逻辑,确保其包含所有必要的参数和步骤。
- 补全缺失信息:对于生成过程中可能遗漏的部分,提供补全方案,例如补充边界条件、异常处理等。
-
整体分析:
- 评估整个系统的成功率、失败率和覆盖率。
-
局部分析:
- 集中分析失败的测试用例,找出具体原因。
-
奇思妙想:
- 能不能分析完结果,基于覆盖率指标或者针对不同业务的背景,制定不同的指标。
- 当结果没有达到预期指标时,分析结果反馈给大模型作为“补充提示词”,再次调用生成测试用例,执行用例...,分析结果
- 判断是否达到预期指标,当结果没有达到预期指标时,重复上面步骤,直到优化到达到预期。
-
针对奇思妙想的胡思乱想:
- 分析结果都不一定准确,还能作为输入?
- 在没有人工监督的情况下大模型输出喂给大模型效果能持续优化?有可能,在一个绝对正确的知识体系下有可能?
- 能不能用强化学习的思想,给大模型激励和惩罚,生成的测试用例好给激励,或者比上次好也给激励,效果变差给惩罚?但是效果好坏评判是由大模型给出的,他会不会偷懒把好的说成坏的?但如果我能界定什么是好的,什么是坏的,那就可以实现了。
- 怎么让大模型明白什么是好,什么是坏呢?微调?用以往业务相关测试用例训练?好像这个确实可以,针对某块业务,把用例设计思路,设计结果给它,训练一下。那是不是也可以直接把需求文档、开发设计文档给它呢?好像还真可以?
- 所以我是要让大模型思想上就确定固化什么是好,什么是坏是吗?上一个思想钢印作为绝对准则?
- 人为什么可以处理这种任务呢?给大模型人的思考思路可以吗?但是这样需要提出很多种可能性情况输入给大模型告诉他怎么做。或者只界定不能做的禁止的?比如如果不确定是好是坏就直接丢弃该结果或者通知人审核?好像是可以的
- 提出“禁止的”远比穷尽可能性要来的方便,像法律一样?法无禁止即可作?感觉可行
- 。。。。。。
- 听起来很简单,但随便优化个参数都要好久......
- ai配置文件中的大模型API密钥等都已删除,使用ai功能之前需填写自己的信息;邮箱信息也已删除,需要填写。 上述两项如果没有填写信息,全流程接口也可以正常运行,ai连不上会降级采取模拟测试用例,邮箱没填会只生成report。
- 描述:在安装库时可能会遇到依赖版本不兼容的问题。
- 解决方案:使用虚拟环境,并在项目根目录下重新生成
requirements.txt文件,通过逐一安装确认依赖。
- 描述:在代码中使用
localhost作为API请求的URL,可能导致速度很慢。 - 解决方案:使用实际的服务器IP或域名,避免DNS解析带来的延迟。例如:
- 替换
http://localhost:5000/api/v1/resource为http://yourserver.com/api/v1/resource
- 替换
- 描述:使用Flask默认日志时,日志信息缺乏上下文。
- 解决方案:使用全局日志配置,结合logging模块,添加请求上下文信息。