导读：在敏捷开发快速迭代的今天，如何平衡测试覆盖率与开发效率？本文分享了一个完整的 AI 测试用例生成系统的架构设计与实现细节，涵盖前后端全栈开发、禅道深度集成、大模型应用等核心技术点。全程无复杂代码堆砌，专注架构思路与实战经验。
注：我们可以同步禅道需求，上传用例模板，生成的用例按照模板格式导出 ，可以直接上传用例管理系统
一、为什么我们要做这个系统？
1.1 测试人的日常痛点
相信每个测试同行都经历过这样的场景：
产品经理丢过来一个需求文档，要求两天内输出完整的测试用例
开发功能已经上线，测试用例还在 Word 里躺着
相似的功能模块，每次都要重复编写几乎一样的测试步骤
需求变更三次，测试用例更新跟不上节奏
这些痛点背后，本质上是人工编写效率与快速迭代需求之间的矛盾。
1.2 AI 能帮我们做什么？
我们想要的不是完全替代人工，而是让 AI 成为测试人员的"智能助手"：
快速生成初稿：AI 根据需求描述，30 秒生成基础测试用例框架
需求自动同步：直接从禅道拉取需求，避免信息传递偏差
智能补全场景：AI 基于历史数据，推荐容易遗漏的边界场景
格式自动转换：一键导出为 Excel，适配现有评审流程
带着这些目标，我们开始了这个项目的探索。
二、系统整体架构设计
2.1 技术选型思路
前端为什么选 Vue3？
我们团队对 Vue 技术栈比较熟悉，而且 Vue3 的 Composition API 在处理复杂状态管理时确实比 Options API 更清晰。加上 Element Plus 的组件库支持，能快速搭建出美观的界面。
后端为什么用 Django？
Django 的"开箱即用"特性太适合这种中后台系统了。自带的 Admin 后台、ORM 框架、用户认证系统，让我们能把精力集中在业务逻辑上，而不是重复造轮子。
AI 能力如何集成？
初期接入了国内主流的大模型 API，通过精心设计的 Prompt 工程，让 AI 按照我们指定的格式输出测试用例。后续会考虑接入多个模型，提供差异化服务。
2.2 核心架构分层
整个系统分为四层：
第一层：用户界面层 这是用户直接看到的部分，包括左侧的会话列表、中间的 AI 对话区域、右侧的测试用例展示区。采用经典的三栏布局，符合大多数 IM 工具的使用习惯。
第二层：业务逻辑层 负责处理核心的业务流程，比如会话管理、用例生成、需求同步等。这一层封装了所有的业务规则，前端调用起来非常简单。
第三层：数据持久层 使用 MySQL 存储会话、用例、聊天记录等数据。特别设计了 JSON 字段来存储聊天历史和测试步骤，方便灵活扩展。
第四层：外部集成层 对接禅道数据库、AI 模型 API、文件存储服务等外部系统。这一层做了大量容错处理，确保外部服务不稳定时不影响核心功能。
三、核心功能背后的设计思考
3.1 会话管理：像聊天一样生成用例
设计理念
我们把每次测试任务看作一次"会话"，就像和 AI 助手聊天一样自然。用户可以随时切换不同的项目会话，每个会话都有独立的上下文。
关键实现细节
在前端状态管理上，我们踩过一个坑。最初直接从后端获取聊天历史数组赋值给响应式变量，结果发现切换会话时会出现数据串话的问题。
排查后发现是 JavaScript 的引用问题——两个会话的聊天数组实际上指向了同一块内存空间。解决方案很简单但容易被忽视：使用扩展运算符创建全新的数组副本。
这个教训告诉我们：Vue3 的响应式系统虽然强大，但处理数组和对象时还是要小心引用关系。
用户体验优化
新建会话时采用"乐观更新"策略，先立即显示在列表中，后台异步创建真实数据
搜索功能带防抖，避免频繁请求后端
分页器自动处理边界情况，删除数据后智能跳转页码
3.2 AI 对话生成：不仅仅是调用 API
交互流程设计
用户输入测试需求 → 前端校验 → 添加到聊天窗口 → 调用后端 AI 接口 → 流式返回用例 → 保存到数据库 → 刷新界面展示
看起来简单的流程，其实有很多细节要考虑：
- 问候语的特殊处理 我们发现很多用户会把 AI 当聊天机器人，发"你好"、"在吗"之类的消息。如果每次都调用 AI 接口生成正式回复，既浪费资源又显得生硬。 解决方案是在前端做一层拦截：检测到问候关键词时，直接返回预设的友好回复。这样既快速又亲切。
- 非测试问题的礼貌拒绝 对于询问时间、天气等与测试无关的问题，我们设计了一套标准话术："抱歉，我专注于测试用例生成..."既表明了定位，又不会让用户觉得被冒犯。
- 聊天记录的持久化 每次生成用例成功后，会异步把完整的聊天历史同步回服务器。这样做的好处是用户下次打开会话时，能看到完整的对话过程，而不仅仅是最终的用例结果。 3.3 禅道需求集成：为什么选择数据库直连？ 方案对比 在同步禅道需求时，我们调研过三种方案： 方案一：禅道开放 API 优点是规范安全，缺点是功能受限，批量查询效率低 方案二：爬虫抓取网页 实现复杂，稳定性差，不推荐 方案三：数据库直连 性能最好，灵活性高，但需要处理好权限控制 最终我们选择了方案三，主要基于两点考虑： 内部系统部署在同一个内网环境，安全性可控 需要批量查询特定 ID 的需求，SQL 查询最高效 实现要点 单次最多同步 100 条需求，避免性能问题 数据库连接信息加密存储到本地 支持 Excel/JSON 文件格式的需求文件上传作为补充 同步完成后自动加载到前端面板，立即可用 前端展示设计 需求面板采用卡片式布局，每条需求显示： 需求 ID 和标题（醒目） 状态标签（活跃/关闭） 内容摘要（自动去除 HTML 标签，限制 100 字） 版本号标识 "用作提示词"按钮（一键填入输入框） 特别值得一提的是 HTML 清洗功能。禅道导出的需求内容包含大量 HTML 标签，直接展示会影响阅读。我们通过创建一个临时 DOM 元素，利用浏览器自身的能力提取纯文本，简单高效。 3.4 可拖拽布局：小功能大体验 为什么要做拖拽？ 在实际使用中发现，不同用户的偏好差异很大： 有人希望 AI 对话区域宽一些，方便查看长文本 有人更关注用例展示，希望右侧区域更大 固定比例的布局无法满足这些个性化需求，所以我们实现了可拖拽分割线功能。 用户体验提升 虽然这个功能使用频率不高，但一旦需要调整时，用户会觉得很贴心。好的用户体验往往藏在这些不起眼的细节里。
四、数据库设计的取舍
4.1 会话表的设计
会话表核心字段包括：
标题（用户自定义）
所属项目（外键关联）
聊天历史（JSON 类型）
创建/更新时间
这里有个设计亮点：聊天历史使用 JSON 字段而非单独建表。
为什么这么设计？
传统做法是为聊天消息单独建立一张表，通过外键关联会话 ID。但我们分析发现：
聊天记录很少单独查询，总是跟随会话一起加载
消息之间没有复杂的关联关系
需要频繁插入新消息
使用 JSON 字段后：
✅ 查询会话时一次性取出所有消息，无需联表
✅ 插入新消息只需更新一个字段
✅ 结构灵活，可以随时扩展消息的元数据
当然也有缺点，比如无法对单条消息做精细化查询，但在这个场景下利大于弊。
4.2 测试用例表的设计
用例表包含以下关键字段：
会话 ID（外键）
标题、描述、预期结果
测试步骤（JSON 数组）
优先级（P0-P3）
标签（JSON 数组）
步骤为什么用 JSON？
测试步骤通常是有序列表，比如：
打开登录页面
输入用户名和密码
点击登录按钮
用 JSON 数组存储天然契合这种结构，前端渲染时也方便遍历。
标签的设计
标签字段同样使用 JSON 数组，用户可以自由添加如"登录"、"支付"、"边界测试"等标签，方便后续筛选和统计。
五、踩过的坑与解决方案
5.1 响应式数据污染问题
问题现象
用户在 A 会话中生成了 5 条用例，切换到 B 会话后又生成了 3 条。奇怪的是，B 会话的用例列表里出现了 A 会话的数据。
排查过程
检查后端接口，返回数据正常
检查前端赋值逻辑，语法没错
打印两个会话的数组引用地址，发现问题所在
// 错误写法
chatMessages.value = sessionData.chat_history || []
经验总结
这个问题给我们敲响了警钟：在 Vue3 中处理从服务器获取的数组/对象时，无论看起来多安全，都要做深拷贝处理。
六、实际使用效果
6.1 效率提升数据
我们在三个项目组试点使用后，统计了以下数据：
用例编写时间对比
传统方式：平均每个功能模块 2.5 小时
使用系统后：平均 40 分钟（含人工审核修改）
效率提升：73%
测试覆盖率
人工编写：平均覆盖率 78%
AI 生成 + 人工补充：平均覆盖率 92%
覆盖率提升：18%
需求变更响应速度
传统方式：用例更新滞后 1-2 天
使用系统后：即时生成，当天完成审核
响应速度提升：80%
6.2 用户反馈
收集到的一线测试人员反馈：
"以前写用例最头疼的就是重复劳动，现在 AI 生成的初稿能有 80% 可以直接用，剩下的稍作修改就行。"
"最喜欢禅道需求同步功能，不用来回切换系统看需求文档了。"
"希望能增加更多模板，现在的导出格式还不够丰富。"
七、给想入坑的同学一些建议
7.1 技术储备建议
如果你想开发类似的系统，建议掌握以下技能：
前端方面
Vue3 基础（响应式原理、Composition API）
TypeScript 类型系统
Element Plus 或其他 UI 组件库
Axios 请求封装
后端方面
Django REST Framework 快速开发
MySQL 数据库设计
Celery 异步任务处理
PyMySQL 数据库连接
AI 集成方面
Prompt 工程设计技巧
流式响应处理
内容格式校验
7.2 避坑指南
- 不要过度设计 我们一开始想得很复杂，什么微服务、消息队列都要上。后来发现对于这种中后台系统，简单直接的架构反而维护成本更低。
- 一定要做错误处理 外部服务（AI API、禅道数据库）都可能失败，要做好降级方案。比如 AI 接口超时时，可以返回缓存的示例数据。
- 重视日志记录 在关键节点打印日志，包括： 接口请求参数和响应 异常堆栈信息 性能耗时统计 这样排查问题时才能快速定位。
ITP 体验网址： http://1.95.215.79:18899/ tester(88888888) ITP 项目地址： https://gitee.com/hp631012651/itp
