一、前言软件测试活动中测试用例设计始终是质量保障体系的核心环节之一。然而在实际项目中测试用例编写的主要成本往往并不体现在「撰写」动作本身而体现在需求理解、业务规则提炼、边界条件补全、异常路径覆盖以及历史测试经验复用等前置分析过程。随着系统复杂度持续增长、需求迭代周期不断缩短传统依赖人工经验驱动的测试用例设计模式正在面临效率、质量与复用性多重压力。在大语言模型LLM快速发展的背景下利用生成式 AI 辅助测试用例设计已成为具有现实意义的技术方向。大语言模型在自然语言理解与结构化内容生成方面具备显著优势能够在一定程度上缓解测试分析与用例组织的重复性工作负担。然而若仅依赖简单的 prompt 驱动模式将需求文本直接输入模型并期望获得高质量测试用例通常难以满足工程落地要求。其主要原因在于模型缺乏领域知识上下文约束难以准确继承团队已有测试规范生成结果可能存在边界覆盖不充分、业务规则偏离与内容幻觉等问题模型输出过程通常缺乏配置管理、质量审计与可追溯机制。基于上述问题TestPilot被设计为一个面向测试场景的智能测试用例生成与管理平台其目标并非构建单纯的「AI 对话式生成工具」而是建立一条围绕测试用例生成、测试用例维护、测试用例导出、需求分析、知识养成与检索、内容生成、AI测试助手、质量检测与配置管理的完整工程链路。该平台以 LLM 为生成引擎以知识库增强检索RAG为上下文供给手段以自研幻觉检测机制为质量控制手段并通过轻量化向量存储架构与配置中心实现工程级部署能力从而使 AI 生成测试用例的过程从「可尝试」向「可控、可审计、可复用、可成长」演进。二、引入 LLM 参与测试用例生成的必要性测试用例生成本质上是一项知识密集型工作其输入不仅包括自然语言需求描述还包括业务规则、数据约束、异常处理逻辑、团队历史用例、测试规范以及经验性判断。此类任务同时具备「理解复杂语义」与「输出结构化结果」的双重特征因此天然适合引入大语言模型进行辅助处理。从能力边界看大语言模型在以下两个方面具有显著适配性对自然语言需求进行语义理解与关键信息提取在给定上下文约束下输出结构化测试内容。然而大语言模型仅解决了「生成能力」问题并未自动解决「工程可信性」问题。若缺少检索增强、质量控制和运行时配置能力模型生成内容通常会暴露以下缺陷无法继承团队既有测试方法论与历史经验无法准确绑定项目真实业务规则与术语体系无法避免生成内容中的事实性偏差或逻辑性幻觉无法提供统一的质量审核、配置管理与变更追踪能力。因此LLM 在测试工程中的价值并不主要体现在「是否能够生成文本」而体现在其是否能够被嵌入一条可控的工程链路之中。换言之真正需要回答的问题不是「模型能否写出测试用例」而是模型生成之前是否已经获得高质量、可验证的业务上下文模型生成之后是否存在可执行的质量检测与风险处理策略模型行为是否能够通过配置进行约束、调整与审计整套能力是否能够在团队范围内稳定复用而非停留在一次性演示阶段。TestPilot 的整体设计即以此为出发点展开。三、TestPilot 的系统定位面向测试工程的智能流水线TestPilot 的定位不是「对话式 AI 工具」而是面向测试工程场景的智能测试用例生成流水线。其核心任务不是简单地产出一段测试文本而是在需求输入后经过分析、检索、生成、检测与管理等多个阶段输出更具可用性与可追溯性的结构化测试用例结果。系统主要包含以下核心环节模块说明需求分析模块支持多种需求文档格式解析执行关键词提取、业务规则抽取、约束识别与复杂度评估知识库增强模块将历史测试用例、需求文档、测试规范等资料向量化存储用于生成前的上下文补全多策略检索模块融合语义检索、关键词检索、混合检索与上下文感知检索以提升召回质量LLM 生成模块在增强上下文基础上执行结构化测试用例生成而非无约束「自由生成」幻觉检测模块从模式匹配、逻辑分析与置信度评估等维度对生成内容执行质量检测与风险处置配置中心模块实现模型、阈值、检索策略、敏感参数等配置项的统一管理、动态生效与审计追踪。测试用例生成模块基于需求输入与知识库上下文完成从需求到结构化测试用例的完整流水线支持单条/批量生成、优先级与测试类型分配、RAG 增强、幻觉检测及导出与统计AI 测试助手模块面向测试场景的对话式助手支持流式回复、会话上下文记忆、知识库增强与预置模板引导可结合幻觉检测对回复内容做质量提示。由此TestPilot 所解决的问题不再是「让 AI 输出测试文本」而是建立一套具备以下属性的测试用例生成基础设施结果具有明确上下文依据生成过程具备一定可解释性风险能够在系统内被主动识别与约束配置能够统一管理与审计整体架构能够落地部署、扩展与迁移。四、TestPilot 针对测试场景所解决的关键问题4.1 测试用例编写效率低在复杂业务系统中测试工程师通常需要投入大量时间用于阅读需求、确认流程、分析约束与补全边界条件。许多工作并非「撰写」动作本身而是前置分析过程的重复劳动。TestPilot 将这一部分流程结构化通过需求预处理、知识检索与增强生成等方式将大量基础性工作前移至系统自动处理阶段从而显著降低测试用例设计的重复成本。4.2 测试用例质量不稳定不同测试人员的经验、抽象能力和覆盖意识存在差异因此测试用例质量在不同个体之间常常波动较大。TestPilot 在生成阶段引入知识库增强在输出阶段引入幻觉检测与分级处理策略试图从机制层面对生成内容的规范性、完整性与可信性进行约束从而降低因个体差异导致的质量不稳定问题。4.3 历史测试经验难以复用在多数团队中历史测试用例、规范文档和经验沉淀通常分散于不同项目和存储载体中难以在新需求场景下被高效调用。TestPilot 将此类资料纳入知识库体系通过向量化存储和智能检索使「经验文档」转化为「可召回的上下文资产」从而将历史测试经验直接纳入新一轮测试用例生成链路中。4.4 AI 生成内容存在幻觉风险在测试场景下内容幻觉的风险远高于一般文本生成场景因为错误测试用例不仅会降低文档质量还可能直接误导测试设计与执行路径。TestPilot 将幻觉检测设计为核心能力之一而非附属功能。系统从表述模式、逻辑一致性、上下文支撑程度及置信度等维度对生成内容进行综合评估并根据阈值采取警告、修正、重生成、人工审核或过滤策略。4.5 需求文档解析工作量大需求文档通常来源多样、格式不一、表达方式复杂人工抽取测试要点与规则约束成本较高。TestPilot 在文档处理阶段支持多格式解析与预处理并通过关键词提取、业务规则识别和复杂度分析将需求内容转化为更适合后续检索与生成的结构化输入。4.6 知识库检索效果不稳定单纯依赖关键词匹配难以准确表达语义相关性单纯依赖向量检索又可能丢失关键术语对召回效果的约束作用。TestPilot 因而采用多策略检索机制并在当前主架构下使用FTS5与sqlite-vec组成两阶段混合检索流程以在相关性、性能与部署复杂度之间取得平衡。五、TestPilot 的工作机制与数据流转过程从系统视角出发TestPilot 的核心数据链路可以抽象为如下过程在该链路中有两个设计原则尤为关键。第一检索质量决定生成质量。LLM 生成并非凭空完成而是显著依赖上下文质量。因此TestPilot 将多策略智能检索设计为质量基础设施而不是单纯的增强选项。第二生成结果必须接受后处理质量控制。在测试场景中生成完成并不意味着流程结束。能够进入实际使用阶段的内容必须经过可靠性检测与风险筛选从而降低错误结果直接进入测试管理体系的概率。5.1 一个示例场景假设输入需求为用户登录功能支持账号密码登录连续输错密码 5 次后锁定 30 分钟。系统首先会抽取「登录」「账号密码」「连续失败」「锁定」「30 分钟」等核心信息并以此为基础执行知识库检索召回与登录、鉴权、锁定策略相关的历史测试用例和规范文档。随后系统将需求原文与检索结果共同输入生成模块输出结构化测试点例如正确账号密码登录成功错误密码登录失败连续输错 5 次后账号被锁定锁定期间再次尝试登录的处理逻辑30 分钟后锁定是否自动解除锁定前后提示信息是否符合预期边界条件下失败次数统计是否准确。生成完成后系统继续对上述结果执行质量检测以识别潜在逻辑冲突、表述异常或幻觉风险并根据置信度进行后续处置。{cases:[{case_id:TC-LOGIN-01,module:登录,title:正确账号密码登录成功,preconditions:用户已注册且账号未被锁定登录页面可正常访问。,steps:[1. 打开登录页面,2. 输入正确的账号和密码,3. 点击登录按钮],expected:[1. 登录成功,2. 跳转至系统首页或指定页面,3. 显示用户身份信息],priority:P0,test_type:功能测试,test_method:正向验证,tags:[登录,账号密码,正常流程]}]}六、向量检索架构演进从 ChromaDB 到 SQLite sqlite-vec FTS5TestPilot 在早期曾采用ChromaDB作为向量存储与检索方案。然而随着项目目标逐渐转向「可部署、可迁移、可内网落地」的工程场景原有架构开始暴露出若干问题需要额外维护独立组件部署链路与运行依赖相对更重备份、恢复与迁移过程复杂度较高在单机、内网与离线场景下不够轻量。基于上述考虑当前 TestPilot 的主架构已经切换为SQLitesqlite-vecFTS5FastEmbedONNX/CPU需要强调的是ChromaDB 在当前项目中仅保留为历史方案或兼容回滚路径不再作为主架构推荐方案。6.1 当前架构的技术组成当前向量检索架构可概括为层级技术选型说明Embedding 层FastEmbedONNX/CPU无需 PyTorch向量存储层SQLite 单文件数据库 sqlite-vec 扩展向量与元数据同库全文索引层FTS5 虚拟表用于关键词召回混合检索机制FTS5 候选召回 → sqlite-vec 向量精排两阶段检索。这种设计具备以下工程优势单文件数据库易于部署与备份向量数据、元数据与全文索引均可整合于同一数据库体系中便于迁移、备份和恢复。轻量化运行依赖FastEmbed 基于 ONNX/CPU降低了模型部署对 GPU 与重型推理依赖的要求。适合单机、内网与离线环境无需额外维护独立向量服务更符合中小团队内部平台的部署需求。兼顾关键词与语义相关性混合检索机制使关键术语约束与语义相似性能够共同参与结果排序。6.2 两阶段混合检索机制当前检索流程采用两阶段设计第一阶段FTS5 关键词召回系统首先基于 FTS5 全文索引进行快速候选召回。为避免固定候选规模带来的召回不足或计算浪费系统使用自适应候选策略简单查询可适当扩大召回范围复杂查询可适当缩小候选集候选规模受MAX_FTS_CANDIDATE_K约束。第二阶段sqlite-vec 向量精排在候选集合基础上系统使用vec_distance_cosine计算向量距离并将其映射为相似度分数再按相关性返回 topK 结果。相较于直接对全量文档进行向量扫描两阶段检索在数据规模提升后更具工程可控性。6.3 工程级约束与容错策略「限制与回退机制」的显式管理EMBEDDING_DIM 不可随意变更向量数据库结构与 Embedding 维度存在绑定关系因此一旦确定EMBEDDING_DIM不可直接变更。若维度改变必须先重建向量数据库。SQLite IN 参数上限已做分批处理SQLite 默认 IN 参数存在上限。为避免在大候选集合下触发异常系统已经对高候选规模执行自动分批查询与结果合并。sqlite-vec 扩展失败时允许自动退化若 sqlite-vec 扩展不可用系统自动降级为全表扫描模式虽然性能下降但功能仍可维持可用状态。FTS5 返回为空时自动回退若 FTS5 不可用或召回为空系统自动切换为纯向量检索路径。所有退化路径均有 warning 日志相关 fallback 行为不会静默发生而是显式记录 warning 日志便于排查与运维。# 向量存储后端默认 sqlite历史上支持 sqlite/chroma当前推荐仅使用 sqliteVECTOR_BACKENDsqlite# Embedding 模型配置必须与实际模型一致EMBEDDING_MODEL_NAMEBAAI/bge-small-en-v1.5EMBEDDING_DIM384# 重要维度一旦确定不允许再变更sqlite-vec 要求# SQLite 向量存储配置可选SQLITE_VECTOR_DB_PATH# 如果为空使用 vector_store/vector_store.dbSQLITE_VEC_EXTENSION_PATH# sqlite-vec 扩展路径可选未设置时自动尝试加载# 混合检索配置ENABLE_HYBRID_RETRIEVALtrue# 是否启用混合检索FTS5 sqlite-vecFTS_CANDIDATE_K200# FTS5 召回候选数量默认 200适用于 topK5~10七、幻觉检测机制的设计意义在生成式测试平台中幻觉检测并非附属模块而是质量保障体系的一部分。TestPilot 当前采用多维度检测机制其主要维度包括模式匹配识别常见幻觉表述模式逻辑分析检测输出内部是否存在逻辑矛盾或自相矛盾置信度评估综合上下文支撑程度与规则特征形成量化分值。在处理策略上系统根据置信度阈值选择不同动作警告模式置信度 0.3仅提示用户注意自动修正0.3 ≤ 置信度 0.5尝试自动修正重新生成0.5 ≤ 置信度 0.7使用LLM重新生成人工审核0.7 ≤ 置信度 0.9标记为需要人工审核过滤处理置信度 ≥ 0.9直接过滤掉这使得 TestPilot 的输出不再是「一次生成即直接交付」而是先进入风险检测与分级处理链路从而提升整体可用性。# 幻觉检测配置ENABLE_HALLUCINATION_DETECTIONtrueHALLUCINATION_SIMILARITY_THRESHOLD0.8HALLUCINATION_CONFIDENCE_THRESHOLD0.7HALLUCINATION_WARN_THRESHOLD0.3HALLUCINATION_AUTO_CORRECT_THRESHOLD0.5HALLUCINATION_REGENERATE_THRESHOLD0.7HALLUCINATION_FILTER_THRESHOLD0.9#幻觉检测相关接口-POST /api/hallucination/detect- 检测内容中的幻觉问题 -GET /api/hallucination/report/{id}- 获取检测报告 -POST /api/hallucination/handle- 处理检测到的幻觉问题 -GET /api/hallucination/config- 获取幻觉检测配置#幻觉检测相关代码块│ │ ├── utils_ai_quality/# AI内容质量检测│ │ │ ├── hallucination_detector.py# 幻觉检测器│ │ │ ├── hallucination_handler.py# 幻觉处理器│ │ │ └── hallucination_reporter.py# 幻觉报告器八、配置中心与工程可管理性对于模型驱动系统而言配置管理能力决定了平台是否具备团队级可用性。TestPilot 当前支持配置中心统一管理其设计重点包括配置按功能分类组织敏感项加密存储配置格式与必填项校验审计日志记录变更历史配置动态生效。其配置优先级为配置中心 .env 默认值这意味着系统既支持环境变量方式快速启动也支持在 Web 界面中对关键配置进行统一调整而无需频繁修改代码或重启服务。从工程角度看配置中心之所以必要是因为一旦系统引入以下能力多模型接入、检索策略切换、阈值与评分控制、API Key 管理、性能调优参数、幻觉检测规则就无法长期依赖手工编辑 .env 文件来满足团队协作需求。配置中心将这些原本分散的变更操作纳入统一管理体系从而使平台具备更高的可维护性与可审计性。# 配置中心相关接口-GET /api/config- 获取所有配置项 -GET /api/config/category- 获取指定分类的配置 -POST /api/config/category- 批量更新指定分类的配置 -GET /api/config/item/key- 获取单个配置项 -PUT /api/config/item/key- 更新单个配置项 -DELETE /api/config/item/key- 删除配置项 -GET /api/config/audit- 获取配置审计日志九、技术架构与项目结构设计从系统架构上看TestPilot 采用典型的分层设计层级技术组成前端展示层Bootstrap 5 ES6 Modules Chart.jsAPI 服务层Flask Blueprints RESTful API业务逻辑层CaseService、KnowledgeService、ChatService 等核心能力层LLM 集成、RAG 检索、幻觉检测、关键词提取、复杂度分析、配置中心数据存储层SQLite sqlite-vec FTS5 文件系统这一设计的目标并非形式上的「架构完整」而是通过职责分离降低后续扩展与维护成本。9.1 后端选型FlaskFlask 的优势在于轻量、直观与可扩展性强。对于内部工具型平台和快速迭代型项目而言Flask 能够在保持较低心智负担的前提下通过 Blueprint 与服务层封装实现清晰的模块拆分。9.2 前端选型Bootstrap ES6 ModulesTestPilot 并未采用重型前端框架而是以 Bootstrap 5 与原生 ES6 Modules 构建页面交互。原因在于该平台的核心竞争力不在复杂前端生态而在测试工程链路本身。轻量前端方案更有利于快速验证、维护与部署。9.3 项目目录组织为避免项目演化为脚本堆叠结构TestPilot 在目录设计上进行了明确分层核心结构如下TestPilot/ ├── app.py / run.py # 应用入口 ├── config/ # 核心配置 ├── blueprints/ # API 路由层 ├── services/ # 业务服务层 ├── models/ # 数据模型层 ├── templates/ static/ # 前端页面与静态资源 ├── utils/ # 模型、检索、文档处理、质量控制等工具层 ├── scripts/ # 初始化、导入、检查与运维脚本 ├── tests/ # 测试代码 ├── docs/ # 详细文档 └── vector_store / uploads / logs # 数据与运行产物进一步细分后可看到utils_ai_models/负责模型接入utils_ai_quality/负责幻觉检测utils_intelligent_retrieval/负责多策略检索utils_document_processing/负责文档处理utils_config_management/负责配置管理scripts/目录则负责数据库初始化、向量库初始化、配置中心初始化、知识库导入与系统检查等。这种分层方式有助于将「模型能力」「检索能力」「质量能力」「配置能力」进行解耦使平台在后续扩展中具有更好的工程弹性。十、可运行性与部署能力TestPilot 并非仅停留在概念层面而是已经具备清晰的运行路径。最基础的启动过程包括克隆项目创建虚拟环境安装依赖预下载 FastEmbed 模型配置 .env初始化数据库初始化向量数据库基于run.py启动应用。#!/usr/bin/env python3 TestPilot 应用启动文件 支持开发和生产环境的启动配置 支持跨平台运行Windows、Linux、Mac importosimportsysimportthreadingfrompathlibimportPathfromutils.utils_core.loggerimportinit_logging,get_logger# 添加项目根目录到Python路径project_rootPath(__file__).parent sys.path.insert(0,str(project_root))fromappimportcreate_appfromutils.utils_core.common_utilsimportget_local_ip,open_browserfromutils.utils_core.platform_utilsimportget_platform,get_wsgi_serverdefmain():主启动函数# 初始化日志系统init_logging()loggerget_logger(__name__)# 获取环境变量debugos.getenv(DEBUG,False).lower()trueportint(os.getenv(PORT,5001))# 获取本地IP地址hostget_local_ip()ifnothost:logger.warning(无法获取本地IP使用0.0.0.0)host0.0.0.0try:# 创建Flask应用appcreate_app()logger.info(f启动TestPilot应用...)logger.info(f平台:{get_platform()})logger.info(f环境:{开发ifdebugelse生产})logger.info(f地址: http://{host}:{port})# 在开发环境下自动打开浏览器ifdebugandhost!0.0.0.0:browser_threadthreading.Thread(targetopen_browser,args(host,port))browser_thread.daemonTruebrowser_thread.start()# 启动应用ifdebug:# 开发环境app.run(hosthost,portport,debugTrue,threadedTrue,use_reloaderFalse)else:# 生产环境使用平台特定的WSGI服务器wsgi_serverget_wsgi_server()logger.info(f生产环境WSGI服务器:{wsgi_server})ifwsgi_serverwaitress:# Windows平台使用Waitresswaitress_availableFalsetry:fromwaitressimportserve waitress_availableTrueexceptImportError:serveNone# 定义为None以满足linter要求ifwaitress_available:logger.info(使用Waitress服务器 (Windows))serve(app,hosthost,portport,threadsint(os.getenv(WORKERS,4)),channel_timeout30,cleanup_interval30,asyncore_use_pollTrue)else:logger.warning(Waitress未安装使用Flask内置服务器)logger.info(提示: 运行 pip install waitress 安装Waitress)app.run(hosthost,portport,debugFalse,threadedTrue)else:# Linux/Mac平台使用Gunicorngunicorn_availableFalsetry:importgunicorn.app.wsgiappasgunicorn_app gunicorn_availableTrueexceptImportError:gunicorn_appNone# 定义为None以满足linter要求ifgunicorn_available:logger.info(使用Gunicorn服务器 (Linux/Mac))# Gunicorn配置# noinspection SpellCheckingInspectiongunicorn_config{bind:f{host}:{port},workers:os.getenv(WORKERS,4),worker_class:eventlet,worker_connections:1000,timeout:30,keepalive:2,max_requests:1000,max_requests_jitter:100,preload_app:True,accesslog:logs/access.log,errorlog:logs/error.log,# Gunicorn官方配置项名称loglevel:info}# 设置环境变量给Gunicornforkey,valueingunicorn_config.items():os.environ[fGUNICORN_{key.upper()}]str(value)# 启动Gunicornsys.argv[gunicorn,app:create_app()]gunicorn_app.run()else:logger.warning(Gunicorn未安装使用Flask内置服务器)logger.info(提示: 运行 pip install gunicorn 安装Gunicorn)app.run(hosthost,portport,debugFalse,threadedTrue)exceptExceptionase:logger.error(f启动应用失败:{str(e)})sys.exit(1)if__name____main__:main()在离线部署场景下基于Pyinstaller打包将已下载的FastEmbed 模型缓存支持提前下载并迁移至目标环境从而满足内网或无外网环境的运行要求。echo off chcp65001nul REM TestPilot PyInstaller Build Script REM Windows PlatformechoechoTestPilot PyInstaller Build Scriptechoecho. REM Checkifrunninginvirtual environment python-cimport sys; sys.exit(0 if hasattr(sys, real_prefix) or (hasattr(sys, base_prefix) and sys.base_prefix ! sys.prefix) else 1)if%errorlevel% neq0(echo[WARNING]Virtual environment not detected, recommend runninginvenv echo.)REM CheckifPyInstaller is installed python-cimport PyInstaller2nulif%errorlevel% neq0(echo[ERROR]PyInstaller not installed, installing... pipinstallpyinstallerif%errorlevel% neq0(echo[ERROR]PyInstaller installation failed pauseexit/b1))echo[INFO]Cleaning old build files...ifexist buildrmdir/s /q buildifexist distrmdir/s /q distifexist TestPilot.spec del /q TestPilot.spececho[INFO]Starting build... echo. REM Build using specfilepyinstaller build.specif%errorlevel% neq0(echo[ERROR]Build failed pauseexit/b1)echo.echoechoBuild completed!echoecho.echoExecutable location: dist\TestPilot.exe echo.echoNotes:echo1. Make sure .envfileis configured before first runecho2. Ensure target machine has necessary runtime librariesecho3. Recommend packaging the entire dist directoryfordistribution echo. pause十一、适用对象与应用价值从应用场景判断TestPilot 适合以下几类对象测试工程师与测试开发人员适用于希望降低重复测试设计成本、提升历史经验复用率同时又不愿完全放弃人工质量把控的使用者。QA 负责人或测试经理适用于关注测试规范沉淀、团队用例质量一致性、模型切换能力与配置审计能力的管理角色。LLM RAG 工程实践研究者适用于关注如何将需求分析、知识检索、生成与质量控制整合成可落地工程系统的开发者或研究人员。十二、结论TestPilot 的设计目标并非将「AI 测试」概念化包装而是围绕一个实际问题展开测试用例生成能否从「辅助尝试」演进为「进入工程流程的基础能力」。从目前的实现路径看这一目标并不能单纯依赖更强的模型也不能依赖更复杂的 prompt而需要将以下能力统一纳入系统设计需求分析知识库建设多策略检索结构化生成幻觉检测配置管理部署与运维能力。正因如此TestPilot 最终并未被设计为一个「对话式生成工具」而被设计为一套面向测试工程场景、具备可配置、可审计、可迁移与可部署能力的智能平台。如果关注的是测试用例自动生成、测试知识库复用、RAG 在测试场景中的落地或希望参考一套相对轻量的 Flask SQLite sqlite-vec FTS5 工程实现路径那么 TestPilot 具有一定的实践参考价值。如果该项目对相关研究或工程实践有所启发欢迎进一步交流、提出问题。