大数据深度学习|计算机毕设项目|计算机毕设答辩|基于大语言模型的测试用例生成及分析平台

标题：基于大语言模型的测试用例生成及分析平台

文档介绍：

第1章 绪论

1.1 选题背景与意义

软件测试是保障软件质量的核心环节，贯穿于软件开发的全生命周期。随着软件行业的快速发展，软件系统的复杂度不断提升，对测试用例的数量和质量提出了更高的要求。传统软件测试用例主要依靠测试人员手工编写，该过程存在效率低下、成本高昂、覆盖度不足等问题。对于中小型开发团队而言，专业测试人员的缺失导致测试环节往往被简化，大量边界场景和异常场景无法得到有效覆盖，进而增加了软件上线后的故障风险。对于大型企业而言，即使配备了完善的测试团队，人工编写测试用例仍需耗费大量时间，难以适应敏捷开发模式下快速迭代的需求。

近年来，大语言模型技术取得了突破性进展，在自然语言理解、代码生成与分析等领域展现出强大的能力。大语言模型能够从源代码和自然语言需求中提取核心逻辑，自动生成符合规范的测试用例，为解决传统测试用例生成的痛点提供了新的技术途径。FastAPI 作为一款轻量级、高性能的 Python Web 框架，具备异步编程、类型提示、自动生成 API 文档等特性，能够快速构建 AI 辅助开发平台，为大语言模型的工程化落地提供了有力支撑。

然而，当前市场上的大语言模型测试用例生成工具大多存在功能单一的问题。多数工具仅能实现基础的用例生成功能，缺乏完善的质量评估体系和多维度的对比分析功能。同时，现有工具对多编程语言的支持不够完善，不同模型和提示策略的效果难以进行统一对比，无法满足课程设计和毕业设计场景下的实验需求。针对上述问题，本课题开发了基于 FastAPI 的测试用例生成及分析平台，实现了测试用例生成、质量评估、结果对比与研究结论聚合的全流程自动化。

本课题的研究具有重要的实际应用价值和学术实践价值。在实际应用方面，平台支持 Java、Python、C++ 三种主流编程语言，集成了 Gemini 3.0、GPT-4.0、Claude 3.5、Qwen 四款主流大语言模型，提供零样本、少样本、模块化及自定义四种提示策略。平台构建的多维度质量评估体系能够对生成的用例进行量化评估，并支持不同模型和策略的效果对比。该平台能够帮助中小型开发团队快速生成高质量的测试用例，降低测试成本，提升测试效率。在学术实践方面，本课题验证了大语言模型在软件测试领域的落地可行性，探索了 FastAPI 框架在 AI 辅助开发平台中的应用模式。通过开展实证研究，分析了不同编程语言、不同模型和不同提示策略对测试用例生成质量的影响，得出了具有实际指导意义的结论。同时，本课题完成了从需求分析、系统设计、代码实现到实验验证的全流程开发，巩固了计算机专业的核心知识，提升了工程实践能力。

1.2 国内外研究现状

在国外，大语言模型辅助测试用例生成的研究起步较早。OpenAI 公司推出的 GPT 系列模型在代码生成领域表现突出，相关研究表明，GPT-4.0 模型能够生成符合规范的单元测试用例，其生成质量在部分场景下已接近人工水平。Google 公司的 Gemini 系列模型同样具备强大的代码理解能力，能够支持多种编程语言的测试用例生成。此外，一些商业公司也推出了基于大语言模型的测试工具，如 GitHub Copilot、Sourcery 等，这些工具能够集成到开发环境中，为开发人员提供实时的测试用例生成支持。

国内在该领域的研究也取得了显著进展。阿里巴巴的通义千问、百度的文心一言、字节跳动的豆包等国产大语言模型在代码生成能力上不断提升，逐渐应用于软件测试领域。国内高校和科研机构也开展了相关研究，探索了提示工程优化、质量评估体系构建等关键技术。例如，清华大学的研究团队提出了基于代码结构的提示词设计方法，有效提升了测试用例的生成质量。然而，国内的相关研究大多集中在单一模型或单一编程语言的测试用例生成上，缺乏集生成、评估、对比、研究于一体的综合性平台。

综合来看，现有研究和产品在大语言模型测试用例生成方面取得了一定的成果，但仍存在以下不足：一是对多编程语言的支持不够完善，多数工具仅能支持 Python 一种语言；二是提示策略单一，缺乏对不同提示策略效果的系统对比；三是质量评估体系不完善，多数工具仅能进行简单的语法检查，无法对用例的覆盖度和有效性进行量化评估；四是缺乏一体化的研究分析功能，无法满足科研和教学场景下的实验需求。本课题针对上述不足，开发了集多语言支持、多模型对比、多提示策略、多维度评估于一体的测试用例生成及分析平台。

下述表1-1对比了国内外主流测试用例生成工具的功能特性，明确了本课题的研究切入点。

表1-2 国内外主流测试用例生成工具对比表

1.3 可行性分析

1.3.1 理论可行性

从理论层面来看，大语言模型的代码理解与生成能力已经得到了充分验证。大语言模型通过学习海量的代码数据，能够掌握不同编程语言的语法规则和编程范式，从源代码中提取函数、类、分支等结构信息，并生成对应的测试用例。软件测试用例设计的理论基础成熟，等价类划分、边界值分析、异常场景测试等方法为测试用例的质量评估提供了理论依据。FastAPI 框架基于 Python 语言开发，具备异步编程、类型提示、自动生成 API 文档等特性，能够快速构建高性能的 Web 服务。因此，本课题的技术方案具有理论可行性。

1.3.2 技术可行性

从技术层面来看，本课题所使用的技术栈均为成熟的开源技术。FastAPI、Vue3、SQLite 等技术拥有完善的文档和活跃的社区支持，开发人员能够快速掌握并应用。Python 原生 ast 库和 tree-sitter 工具能够实现跨语言的代码结构解析，为质量评估提供基础。httpx 库能够统一调用不同大语言模型的 API，实现多模型的集成。ECharts 和 jsPDF 库能够分别实现数据可视化和 PDF 导出功能。本科阶段所学的后端开发、前端开发、数据库等知识能够支撑本课题的开发工作。因此，本课题的技术方案具有技术可行性。

1.3.3 非技术因素可行性

从非技术因素来看，本课题的开发环境易于搭建，所需的硬件设备为普通个人计算机，软件工具均为免费开源软件。大语言模型的 API 调用成本较低，能够满足实验需求。项目周期为四个月，时间安排合理，能够按时完成平台开发和实验验证工作。因此，本课题具有非技术因素可行性。

1.4 论文结构安排

本论文共分为六章，整体逻辑遵循从项目立项到系统完成的全流程。

第一章为绪论，主要介绍课题的选题背景与意义、国内外研究现状、可行性分析及论文结构安排。

第二章为相关技术及知识介绍，详细阐述本课题所使用的大语言模型、软件测试理论、平台开发技术等相关知识。

第三章为平台需求分析与整体设计，明确平台的功能性和非功能性需求，完成系统架构、功能模块、数据库等方面的设计。

第四章为平台核心功能实现，介绍后端服务、代码输入与 AST 解析、测试用例生成、质量评估、前端界面等核心模块的实现细节。

第五章为平台展示与实验验证分析，展示平台的主要功能，并通过实证研究分析不同编程语言、不同模型、不同提示策略对测试用例生成质量的影响。

第六章为总结与展望，总结本课题的主要研究成果，分析平台存在的不足，并对未来的研究方向进行展望。

第2章 相关技术及知识介绍

本章围绕课题开发所需的核心技术展开说明，内容仅选取与项目实现直接相关的部分，不引入超出本科知识范围的复杂理论。相关技术主要包括大语言模型应用技术、软件测试与质量评价理论、后端与前端开发框架、代码解析技术、数据存储与接口调用技术等。上述技术共同构成测试用例生成及分析平台的实现基础，保障平台功能可落地、运行稳定、扩展便捷。

2.1 大语言模型相关技术

大语言模型是本课题实现测试用例自动生成的核心支撑。这类模型通过大规模代码与文本数据训练，具备代码理解、结构分析、代码生成与逻辑补全能力，可根据输入的源代码自动生成对应的单元测试代码与测试用例。本课题不涉及模型底层训练与架构修改，仅以调用方式完成工程化集成，重点使用模型的代码生成能力。

本课题选取四款具有代表性的大语言模型进行对比实验，分别为 Gemini 3.0、GPT-4.0、Claude 3.5、Qwen。四款模型均提供标准化 API 接口，支持多编程语言代码生成，可稳定输出可运行的测试代码。平台通过统一网关对这些模型进行封装，使前端与业务逻辑无需关注各厂商 API 差异，即可完成调用与结果解析。

提示工程是提升测试用例质量的关键手段。平台设计零样本、少样本、模块化与自定义四种提示策略。零样本策略直接向模型提交源码与任务要求，不提供示例；少样本策略在提示中加入典型示例，引导模型输出规范格式；模块化策略将源码结构、测试目标、评估指标拆分为独立部分，提升模型理解准确度；自定义策略允许用户直接编辑提示词，满足个性化实验需求。提示词的结构与内容均贴合平台实际生成逻辑，以提高生成结果的规范性与可执行性。

2.2 软件测试与测试用例质量评价理论

软件测试是通过执行程序发现缺陷、保障功能正确性的过程，单元测试是其中最基础、执行频率最高的环节。单元测试以函数、方法为最小测试单位，通过输入指定参数并校验输出结果，验证最小代码单元逻辑是否正确。人工编写单元测试成本高、易遗漏分支，本课题借助大语言模型实现单元测试代码的自动生成。

测试用例是单元测试的核心载体，完整的测试用例包含输入数据、执行步骤、预期结果与实际结果。高质量测试用例应具备正确、完整、清晰、可执行的特点，能够覆盖正常流程、边界条件与异常场景。传统测试用例质量依赖人工判断，本课题在此基础上构建可量化的多维度评价体系。

测试用例质量评价指标是平台实验分析的核心依据。结合现有研究与工程实践，平台选取六项指标进行评估：准确率、编译通过率、行覆盖率、分支覆盖率、有效率、检错率。各项指标以代码文本信号与结构信息为依据，采用启发式计算方式得出分数，不依赖复杂的动态执行环境，符合轻量化实验平台的定位。该套评价体系可直接复现、便于对比，满足课程设计与毕业设计的实验要求。

2.3 平台开发相关技术

2.3.1 后端开发技术

平台后端采用 FastAPI 框架构建，该框架基于 Python 语言，具备开发效率高、类型约束清晰、自动生成接口文档、支持异步请求等优势，适合快速搭建实验类 Web 服务。FastAPI 通过 Pydantic 完成请求与响应参数的校验，降低接口出错概率。平台所有业务接口统一返回标准格式数据，便于前端解析与异常处理。

数据持久化采用 SQLite 轻量数据库。该数据库无需独立部署，文件形式存储，适合单机演示与毕业设计场景。平台使用 SQLite 存储用户账号、解析后的源码信息、实验记录、评估结果等数据，启动时自动建表，无需人工配置，降低使用门槛。

平台通过 httpx 库实现大语言模型 API 调用。该库支持超时控制、异常捕获与异步请求，可统一封装不同厂商模型的调用逻辑。平台设计 LLM 网关模块，根据用户选择的模型名称自动路由到对应提供商接口，使上层生成逻辑与底层模型解耦。

2.3.2 代码解析技术

代码结构解析采用 AST 抽象语法树实现。AST 可将源码转换为结构化树状信息，提取函数、类、方法、参数、条件分支等关键结构，为提示词构建与质量评估提供依据。Python 代码使用语言自带 ast 库解析；Java 与 C++ 代码使用 tree‑sitter 工具解析；解析失败时自动回退到正则表达式提取关键信息，保障多语言兼容性。

2.3.3 前端开发技术

前端采用 Vue3 + Vite + TypeScript 技术栈，以组件化方式开发单页应用。该方案构建速度快、类型约束完善，界面交互流畅，适合毕业设计类项目快速开发。界面按业务模块划分为代码输入、参数配置、结果展示、研究结论、数据管理等页面，流程清晰、操作简洁。

数据可视化使用 ECharts 图表库，实现指标评分、模型对比、策略对比等图形展示。平台使用柱状图与折线图呈现多维度实验结果，直观反映不同语言、模型、策略的效果差异。结果导出使用 jsPDF 库在浏览器端直接生成 PDF 文件，支持实验信息、指标图表、测试代码一键导出，满足实验存档与报告撰写需求。

2.4 数据集与实验环境

2.4.1 实验数据集

平台实验数据集来源于公开代码集，包括 HumanEval‑X、Kaggle 与 GitHub 开源项目，选取 Java、Python、C++ 三种语言的典型函数。数据集覆盖简单逻辑、条件分支、循环结构、异常处理等常见场景，保证实验结果具有代表性。数据集用于测试用例生成、质量评估、模型对比与策略验证，可复现、可替换，满足实验严谨性要求。

2.4.2 实验环境

硬件环境以普通个人计算机为主，无需高性能 GPU，符合毕业设计硬件条件。软件环境使用 Python 3.12、Node.js 18 及以上版本，依赖库通过配置文件统一管理，环境搭建步骤简单、可复现。平台前后端分离运行，后端启动后提供 API 服务，前端通过网络请求完成交互，本地运行即可完成全部实验。

2.5 本章小结

本章介绍了支撑平台实现的全部关键技术，包括大语言模型与提示工程、软件测试理论与质量评价体系、后端 FastAPI 与前端 Vue3 开发技术、AST 代码解析、多模型统一调用、数据可视化与导出等内容。各项技术均选择轻量化、易落地、适合本科毕业设计的方案，与平台需求高度匹配。相关理论与工具的组合，为后续需求分析、系统设计、功能实现与实验验证奠定稳定基础。

第3章 平台需求分析与整体设计

3.1 需求分析

3.1.1 功能性需求

基于大语言模型的测试用例生成及分析平台面向课程设计与毕业设计场景，旨在为用户提供从源码输入到测试用例生成、质量评估、结果导出与研究结论汇总的一站式服务。通过对课题目标和用户使用场景的深入分析，平台的核心功能性需求可归纳为以下七个方面：

1.用户注册登录：平台需提供用户注册与登录功能，支持用户名和密码方式认证。注册时对用户名进行合法性校验（仅允许字母、数字、下划线、点和中横线），密码采用 PBKDF2 算法加盐哈希存储，登录成功后签发 HMAC 令牌用于后续接口鉴权。验收标准：用户可成功注册并登录，未登录用户无法访问受保护接口。

2.代码输入与AST 解析：平台需支持 Java、Python、C++ 三种编程语言的源码输入，提供代码粘贴和文件上传两种方式。输入后自动执行代码规范化（统一换行符、去除首尾空行），并调用 AST 解析模块提取函数、类、方法、分支等符号信息，解析结果与源码一同入库保存。验收标准：三种语言的源码均可正确解析并返回符号列表和解析摘要。

3.参数配置与测试用例生成：平台需提供模型选择（Gemini 3.0、GPT-4.0、Claude 3.5、Qwen）、提示策略选择（零样本、少样本、模块化、自定义）、评估指标选择等配置项。用户可预览提示词内容并支持手动编辑，确认后触发生成。后端调用 LLM 生成测试用例代码（test_case_code）和单元测试代码（unit_test_code）。验收标准：用户选择参数后可预览提示词，执行生成后返回完整的测试代码。

4.多维度质量评估：平台需对生成的测试用例进行六维度质量评估，包括准确率、编译通过率、行覆盖率、分支覆盖率、有效率和检错率。评估基于源码 AST 结构与生成代码文本信号进行启发式评分，用户可按需勾选评估指标。验收标准：生成完成后可对选定指标进行评估，返回各指标评分及评估详情。

5.单实验结果展示与导出：平台需以可视化图表展示单次实验的评估指标评分，支持不同模型间的对比功能。同时支持将实验结果导出为 JSON、CSV、PDF 三种格式，PDF 导出包含实验信息、指标评分、模型对比和生成代码。验收标准：实验结果页可正确展示图表和对比数据，三种格式导出文件内容完整。

6.研究结论聚合与可视化：平台需按语言、模型、提示策略三个维度对历史实验数据进行聚合统计，计算各指标均值和综合均分，自动生成结论摘要和推荐方案。支持按时间范围筛选实验数据，以柱状图和折线图展示统计结果。验收标准：研究结论页可正确展示聚合统计图表和结论摘要。

7.实验数据管理：平台需提供实验历史和源码历史的分页查询、编辑和删除功能，支持按关键字搜索源码记录。验收标准：数据管理页可正确展示分页列表，支持增删改查操作。

图 3-1 平台用例图

表 3-1 平台功能性需求清单

3.1.2 非功能性需求

除功能性需求外，平台还需满足以下非功能性需求，以保障系统的可用性、安全性和可扩展性：

1.性能需求：平台单次测试用例生成的响应时间应控制在 60 秒以内（含 LLM 调用时间），页面常规查询接口响应时间不超过 2 秒。系统应支持至少 10 个并发用户同时操作，不出现请求阻塞或服务崩溃。验收标准：常规接口平均响应时间 ≤ 2 秒，LLM 生成接口响应时间 ≤ 60 秒。

2.易用性需求：平台界面应简洁清晰，操作流程符合直觉。用户从注册到完成一次完整实验（代码输入→参数配置→生成→评估→导出）的操作步骤不超过 10 步。核心页面需提供操作提示和状态反馈。验收标准：新用户可在 5 分钟内完成首次完整实验流程。

3.安全性需求：用户密码必须使用 PBKDF2 算法加盐哈希存储，禁止明文保存。所有受保护接口必须通过 HMAC 令牌鉴权，令牌有效期可配置。前端与后端之间通过 HTTPS 传输敏感数据。验收标准：密码不以明文存储，未携带有效令牌的请求返回 401 状态码。

4.可扩展性需求：平台架构应支持新增大语言模型和提示策略，新增模型只需实现 Provider 接口并在网关注册，无需修改核心业务逻辑。提示策略通过模板机制扩展，支持用户自定义模板。验收标准：新增模型或策略的代码改动量不超过 50 行。

表 3-2 平台非功能性需求指标表

3.2 整体设计

3.2.1 系统架构设计

平台采用前后端分离的三层架构，由前端展示层、后端服务层和数据层组成，各层之间通过 RESTful API 进行通信，数据格式统一采用 JSON。

前端展示层基于 Vue 3 + TypeScript 构建，负责用户界面渲染、交互逻辑处理和状态管理。该层通过浏览器端的 fetch API 调用后端接口，所有请求自动注入 Bearer Token 进行身份认证。前端按业务模块划分为代码输入、参数配置与生成、单实验结果与导出、研究结论、数据管理五个核心视图，使用 ECharts 实现数据可视化，jsPDF 实现 PDF 导出。

后端服务层基于 FastAPI 框架构建，负责业务逻辑处理、LLM 调用和数据持久化。该层通过 api_router 汇总所有接口路由，使用 Pydantic 进行请求参数校验和响应序列化，统一通过 ResponseEnvelope 封装返回数据。核心服务包括认证服务、代码输入服务、AST 解析服务、提示词构建服务、LLM 网关服务、评估服务、实验管理服务、研究结论服务和导出服务。后端通过 httpx 客户端与外部 LLM API 通信，统一由 LLM 网关路由到对应的 Provider。

数据层采用 SQLite 作为持久化存储，存储用户信息、解析源码记录和实验运行记录。实验详情数据同时以 JSON 文件形式持久化到 outputs 目录，便于离线查看和批量脚本读取。前后端之间通过 HTTP 协议通信，请求和响应均采用 JSON 格式，接口前缀统一为 /api/v1。

图 3-2 平台系统架构图

3.2.2 功能模块设计

根据需求分析，平台划分为七个核心功能模块，各模块功能边界清晰，通过定义良好的接口进行交互，实现了模块间的解耦设计。

(1)用户认证模块：负责用户注册、登录、密码加密和令牌管理。注册时对用户名进行合法性校验，密码使用 PBKDF2-HMAC-SHA256 算法加盐哈希后存储；登录成功后签发 HMAC-SHA256 令牌，令牌包含用户 ID、用户名和过期时间；受保护接口通过依赖注入方式统一校验令牌有效性。

(2)代码输入与 AST 解析模块：负责源码的输入、规范化和结构解析。代码输入支持粘贴和文件上传两种方式，上传时自动推断语言类型；代码规范化统一换行符并校验文件大小；AST 解析对 Python 使用原生 ast 库，对 Java 和 C++ 优先使用 tree-sitter 解析，失败时回退到正则解析，提取函数、类、方法、分支等符号信息。

(3)参数配置与生成模块：负责模型选择、提示策略配置、提示词构建和测试用例生成。提示词构建服务根据策略类型选择对应模板，填充语言、源码、AST 摘要和测试目标等变量；LLM 网关根据模型名路由到对应 Provider，统一调用 OpenAI 兼容接口；生成结果解析后提取 test_case_code 和 unit_test_code。

(4)质量评估模块：负责对生成结果进行多维度启发式评分。六个评估指标分别基于源码符号信息和生成代码文本信号计算，评估结果保存到实验记录中，支持批量评估。

(5)结果展示与导出模块：负责实验结果的查询展示和多格式导出。前端通过 ECharts 柱状图展示指标评分，支持模型对比；后端支持 JSON 和 CSV 格式导出，前端支持 PDF 格式导出。

(6)研究结论模块：负责历史实验数据的聚合统计和结论生成。按语言、模型、提示策略三个维度聚合各指标均值，计算综合均分，自动推荐最优模型和策略组合，生成结论摘要文本。

(7)数据管理模块：负责实验记录和源码记录的增删改查。支持分页查询和关键字搜索，实验状态流转为 created → generated → evaluated → exported。

各模块间通过服务层接口交互，避免直接耦合。例如生成模块调用提示词构建服务和 LLM 网关服务，评估模块调用 AST 解析服务获取符号信息，研究结论模块调用实验管理服务获取历史数据。这种设计使得各模块可独立开发和测试，便于后续维护和扩展。

图 3-3 平台功能模块结构图

3.2.3 模型集成设计

平台通过设计统一的 LLM 网关实现大语言模型与后端服务的集成。LLM 网关的核心设计思想是将不同模型的 API 差异封装在各自的 Provider 中，对外提供统一的调用接口。

LLM 网关维护一个模型名到 Provider 函数的映射表（_PROVIDER_MAP），当前支持 gemini-3.0、gpt-4.0、claude-3.5、qwen 四个模型。当收到生成请求时，网关根据模型名查找对应的 Provider 函数并调用，同时记录调用耗时。每个 Provider 均实现统一的签名 generate(prompt, language) -> GenerationOutput，内部通过 call_openai_compatible_chat 函数调用 OpenAI 兼容的 Chat Completions 接口，各模型的 base_url、api_key 和 model_name 通过 Settings 配置管理。

提示词构建流程采用模板机制。系统预定义了三种策略模板：零样本模板直接提供源码和 AST 摘要要求生成测试；少样本模板在零样本基础上增加上下文示例引导；模块化模板将生成过程分为识别函数与分支、设计测试场景、输出单元测试代码三个步骤。自定义策略允许用户编写包含 {language}、{code} 占位符的模板。构建时根据策略类型选择模板，填充语言、源码、AST 摘要和测试目标等变量生成最终提示词。

模型调用的异常处理机制包括三个层次：第一层为 httpx 超时异常捕获，当请求超过 llm_request_timeout_seconds（默认 60 秒）时返回超时错误；第二层为 HTTP 状态码校验，当响应状态码 ≥ 400 时返回请求失败错误；第三层为网关层异常转换，将 ProviderError 统一转换为 LlmGatewayError，由 API 层捕获并返回 400 状态码和错误详情。

图 3-4 LLM 网关调用流程图

3.2.4 测试用例生成流程设计

从用户提交源码到生成测试用例的完整流程包含以下步骤：

(1)代码输入与规范化：用户通过代码粘贴或文件上传方式提交源码，系统自动识别语言类型（文件上传时根据后缀推断），执行代码规范化处理（统一换行符为 \\n，去除首尾空行），并校验代码大小不超过 2MB。

(2) AST 解析与符号提取：根据语言类型选择解析策略：Python 使用原生 ast 库解析，遍历 AST 节点提取 ClassDef、FunctionDef、If/For/While 等符号；Java 和 C++ 优先使用 tree-sitter 解析，通过节点类型映射（如 method_declaration、class_declaration、if_statement 等）提取符号，tree-sitter 不可用时回退到正则匹配。解析结果生成摘要文本和符号列表。

(3)提示词构建：根据用户选择的提示策略，从预定义模板库中选择对应模板，将语言、规范化代码、AST 摘要和测试目标填充到模板中生成提示词。用户可在预览后手动编辑提示词内容。

(4) LLM 调用与结果生成：LLM 网关根据模型名路由到对应 Provider，通过 httpx 客户端向 OpenAI 兼容接口发送 Chat Completions 请求。请求包含 system 消息和 user 消息，temperature 设为 0.2 以保证生成稳定性。

(5)结果解析：Provider 收到 LLM 响应后，通过 parse_generation_text 函数解析原始文本。解析策略依次尝试：提取命名段落（test_case_code、unit_test_code）、提取代码块（```标记）、判断文本是否像代码。最终生成包含 test_case_code、unit_test_code 和 explanation 的 GenerationOutput 对象。

(6)质量评估：调用评估服务对生成结果进行多维度评分，评估结果保存到实验记录中。

流程中的异常处理机制包括：代码输入阶段校验空代码和超限大小；AST 解析阶段 tree-sitter 失败自动回退正则解析；LLM 调用阶段捕获超时和 HTTP 错误；结果解析阶段对空响应和非结构化响应进行兜底处理。整个流程不支持自动重试，用户可在生成失败后重新提交请求。

图 3-5 测试用例生成全流程图

3.2.5 质量评估流程设计

平台设计了六维度的测试用例质量评估体系，各指标基于源码 AST 结构与生成代码文本信号进行启发式评分，评分范围为 0-100 分。

准确率（accuracy）：衡量生成测试代码对源码函数的覆盖程度。从 AST 中提取函数名和方法名列表，统计在生成代码文本中出现的函数名数量，计算命中率。公式为：accuracy = 30 + (命中函数数 / 总函数数) × 70。当源码无函数时默认 55 分。

编译通过率（compile_pass_rate）：衡量生成代码的语法正确性。根据语言类型检测不同的编译信号：Python 检测 "def test"、"assert"、"pytest"；Java 检测 "@test"、"assert"、"junit"；C++ 检测 "assert"、"test"。存在编译信号时评 85 分，否则评 45 分。

行覆盖率（line_coverage）：估算生成测试代码对源码行的覆盖程度。统计生成代码中覆盖信号词（if、else、case、assert、exception、null、none）的出现次数，结合源码符号数量计算。公式为：line_coverage = 35 + (信号词次数 / 符号数) × 20。无符号时默认 40 分。

分支覆盖率（branch_coverage）：估算生成测试代码对源码分支的覆盖程度。统计生成代码中分支信号词（if、else、case、boundary、edge）的出现次数，结合源码分支节点数计算。公式为：branch_coverage = 30 + (分支信号次数 / 分支节点数) × 35。无分支节点时按 branch_coverage = 60 + 分支信号次数 × 1.5 计算。

有效率（validity）：衡量生成代码的有效程度。检测生成代码中的占位符（todo、placeholder），每个惩罚项扣 20 分。基础分为 88 分，公式为：validity = 88 – 惩罚项。

检错率（defect_detection）：衡量生成测试代码检测缺陷的能力。统计生成代码中缺陷检测信号词（invalid、error、exception、negative、overflow、boundary）的出现次数。公式为：defect_detection = 40 + 信号词次数 × 7。

综合均分为六个指标评分的算术平均值。评估流程首先对源码执行 AST 解析获取符号信息，然后合并 test_case_code 和 unit_test_code 的文本，对每个选定的指标调用对应的计算函数，最后将所有评分结果保存到实验记录中。

图 3-6 质量评估流程图

表 3-3 质量评估指标计算方法与评分标准表

3.2.6 数据库设计

平台使用 SQLite 作为持久化存储，核心数据表包括用户表（users）、解析源码表（parsed_sources）和实验运行记录表（run_records）。此外，实验详情数据通过 JSON 文件存储在 outputs 目录中，每个实验对应一个独立目录。

(1)用户表（users）：存储用户账户信息，包括用户 ID（主键）、用户名（唯一约束）、密码哈希值、密码盐值和创建时间。用户名采用小写存储并设置唯一约束，确保不重复。

(2)解析源码表（parsed_sources）：存储用户提交的源码及其解析结果，包括源码 ID（主键）、语言类型、来源方式（paste/upload）、文件名、规范化代码、AST 摘要、AST 符号 JSON 和创建时间。AST 符号信息以 JSON 字符串形式存储，查询时反序列化为列表。

(3)实验运行记录表（run_records）：存储实验的完整信息，包括实验 ID（主键）、语言类型、模型名称、提示策略、源码代码、提示词文本、生成输出 JSON、评估结果 JSON、创建时间和更新时间。生成输出和评估结果均以 JSON 字符串形式存储，支持灵活的数据结构。

三张表之间的关联关系为：用户通过认证令牌与实验记录关联（逻辑关联，非外键约束）；解析源码表与实验运行记录表通过源码内容关联（实验记录中存储源码代码原文）。实验详情的完整数据（包括 GenerationOutput 和 MetricResult）同时持久化到 outputs/{experiment_id}/experiment.json 文件中，与数据库记录互为补充。

图 3-7 数据库 E-R 图

3.2.7 安全与性能设计

(1)安全设计

平台的安全措施围绕身份认证、数据保护和接口鉴权三个方面展开：

用户密码采用 PBKDF2-HMAC-SHA256 算法加盐哈希存储。注册时为每个用户生成 32 字节随机盐值（secrets.token_hex(16)），使用 120000 次迭代的 PBKDF2 算法计算密码哈希值，盐值和哈希值分别存储在 users 表的 password_salt 和 password_hash 字段中。登录验证时使用 hmac.compare_digest 进行常量时间比较，防止时序攻击。

接口鉴权采用 HMAC-SHA256 令牌机制。登录成功后，将用户 ID、用户名、签发时间和过期时间编码为 Base64URL 格式的载荷段，使用服务端密钥对载荷段进行 HMAC-SHA256 签名，生成"载荷.签名"格式的令牌。令牌有效期默认 24 小时，可通过 auth_token_expire_hours 配置。前端在所有 API 请求的 Authorization 头中携带 Bearer Token，后端通过 require_auth 依赖注入函数统一校验令牌签名和有效期。

受保护接口通过 FastAPI 的依赖注入机制实现统一鉴权。api_router 将认证接口（注册、登录）设为公开路由，其他所有业务接口纳入 protected_router 并添加 require_auth 依赖，确保未认证请求直接返回 401 状态码。前端在 main.ts 中重写 window.fetch，自动为 API 请求注入 Token，并监听 401 响应触发全局登出。

(2)性能设计

平台的性能优化措施围绕异步处理、请求控制和数据缓存三个方面展开：

a．LLM 调用采用 httpx 同步客户端，通过 llm_request_timeout_seconds（默认 60 秒）控制请求超时，避免长时间阻塞。各 Provider 通过统一的 call_openai_compatible_chat 函数发起请求，复用 HTTP 客户端配置。

b.上传文件大小通过 max_upload_size_bytes（默认 2MB）限制，防止大文件占用服务器资源。代码输入服务在规范化阶段校验代码大小，超限时直接拒绝。

c.实验数据采用内存缓存加文件持久化的双重存储策略。experiment_service 在内存中维护 _STORE 字典缓存实验记录，首次访问时从 outputs 目录加载 JSON 文件，后续查询直接从内存读取，避免频繁的磁盘 I/O。数据库操作使用 SQLite 连接池模式，每次操作获取独立连接，查询完成后自动释放。

第 4 章 平台核心功能实现

4.1 后端服务基础实现

4.1.1 FastAPI 项目搭建与路由管理

后端项目采用模块化目录结构，各目录职责明确。backend/app/api 目录存放接口路由文件，每个文件对应一个业务模块；backend/app/services 目录存放核心业务逻辑服务；backend/app/schemas 目录存放 Pydantic 数据模型；backend/app/core 目录存放配置、常量和日志；backend/app/models 目录存放领域模型（如提示词模板）。main.py 作为应用入口，负责初始化 FastAPI 实例、注册中间件和挂载路由。

路由管理采用分层汇总策略。各业务模块定义独立的 APIRouter 并设置 prefix 和 tags，router.py 中通过 api_router 汇总所有路由。认证相关路由直接挂载到 api_router，其他业务路由统一纳入 protected_router 并添加 require_auth 依赖注入，实现受保护接口的统一鉴权。最终 api_router 在 main.py 中以 /api/v1 前缀挂载到 FastAPI 应用。

请求和响应参数校验通过 Pydantic 模型实现。每个接口定义对应的 Request 和 Response 模型，字段使用 Field 约束（如 min_length=1、ge=0、le=100），枚举类型使用 Literal 限定可选值（如 ModelType = Literal["gemini-3.0", "gpt-4.0", "claude-3.5", "qwen"]）。FastAPI 自动根据模型定义生成 Swagger API 文档，提供在线接口调试功能。

统一响应格式通过 ResponseEnvelope 泛型模型实现，所有接口返回数据封装在 data 字段中，同时包含 success 和 message 字段。错误响应通过 HTTPException 抛出，FastAPI 自动将异常转换为标准错误格式。

4.1.2 用户认证模块实现

用户认证模块由 auth_service.py 和 api/auth.py 协同实现，核心逻辑包括注册、登录和令牌管理三个部分。

注册流程：用户提交用户名和密码后，auth_service 首先对用户名进行规范化处理（去除首尾空格并转小写），然后使用正则表达式校验用户名合法性（仅允许字母、数字、下划线、点和中横线），接着查询数据库判断用户名是否已存在，最后生成 32 字节随机盐值，使用 PBKDF2-HMAC-SHA256 算法（120000 次迭代）计算密码哈希值，将用户信息存入users表。

登录流程：用户提交用户名和密码后，auth_service 查询数据库获取用户记录，使用存储的盐值重新计算密码哈希值，通过 hmac.compare_digest 进行常量时间比较验证密码正确性。验证通过后调用 issue_access_token 签发令牌，令牌载荷包含用户 ID（uid）、用户名（un）、签发时间（iat）和过期时间（exp），使用 Base64URL 编码载荷段，再使用 HMAC-SHA256 算法和服务端密钥生成签名段，最终令牌格式为"载荷段.签名段"。

接口鉴权通过 require_auth 依赖注入函数实现。该函数从请求的 Authorization 头中提取 Bearer Token，调用 verify_access_token 验证签名和有效期，验证通过后返回用户信息字典。protected_router 中所有接口均添加了 Depends(require_auth) 依赖，确保未认证请求返回 401 状态码。

表 4-1 用户认证核心接口设计表

4.1.3 数据存储服务实现

数据存储服务由 storage_service.py 实现，负责 SQLite 数据库的初始化和数据的增删改查操作。

数据库初始化在应用启动时通过 init_storage() 函数执行，该函数读取 settings.sqlite_db_path 配置确定数据库文件路径（默认为 data/app.db），创建数据库连接并执行 CREATE TABLE IF NOT EXISTS 语句建表。数据库连接使用 sqlite3.connect 并设置 row_factory = sqlite3.Row，使查询结果以字典形式返回，便于业务层使用。

数据查询操作通过参数化 SQL 语句实现，防止 SQL 注入。list_parsed_sources 函数支持关键字搜索，对 source_id、language、source、file_name 四个字段进行 LIKE 模糊匹配，查询结果按 created_at 降序排列并限制返回数量。分页查询通过 LIMIT 子句实现，前端传入 limit 参数控制返回条数。

数据写入操作使用 INSERT … ON CONFLICT DO UPDATE 语法实现 Upsert 语义。save_generation_record 函数在插入新记录时，若 experiment_id 已存在则更新已有记录，确保重复提交不会产生重复数据。所有写操作通过 with _connect() as conn 上下文管理器自动提交事务。

4.2 代码输入与AST解析模块实现

4.2.1 代码输入模块实现

代码输入模块由 code_input_service.py 和 api/code_input.py 协同实现，支持代码粘贴和文件上传两种输入方式。

代码粘贴方式通过 POST /api/v1/code-input/normalize 接口实现。用户提交包含 language、source（固定为"paste"）、code 字段的请求，code_input_service 执行规范化处理：首先将 Windows 换行符（\\r\\n）和旧 Mac 换行符（\\r）统一替换为 Unix 换行符（\\n），然后去除首尾空行，最后校验代码内容非空且大小不超过 2MB。

图4-3 代码输入示例图

文件上传方式通过 POST /api/v1/code-input/upload 接口实现。用户上传代码文件，后端通过 FastAPI 的 UploadFile 和 Form 参数接收文件内容和可选的 language 参数。当用户未指定语言时，code_input_service 根据文件后缀自动推断语言类型（.py → python、.java → java、.cpp/.cc/.cxx/.hpp/.h → cpp）。文件内容先尝试 UTF-8 解码，失败后尝试 GBK 解码，均失败则返回编码不支持的错误。解码成功后执行与粘贴方式相同的规范化处理。

源码记录的持久化通过 storage_service.save_parsed_source 函数实现，将规范化代码、AST 摘要和符号信息保存到 parsed_sources 表，返回 source_id 供后续配置和生成使用。

4.2.2 AST 解析模块实现

AST 解析模块由 ast_parser_service.py 实现，核心挑战在于支持三种编程语言的跨语言解析。模块采用"优先精确解析，失败回退正则"的策略，确保在任何情况下都能返回解析结果。

Python 解析使用标准库 ast 模块。首先调用 ast.parse 将源码解析为 AST 树，然后通过 _attach_parents 函数为每个节点附加 parent 属性，最后遍历 AST 节点提取符号：ClassDef 节点提取为 class 类型符号，FunctionDef 节点根据 parent 是否为 ClassDef 区分为 method 或 function 类型，If/For/While/Match 节点提取为 branch 类型符号。

Java 和 C++ 解析优先使用 tree-sitter。模块通过 tree-sitter-languages 库获取对应语言的解析器，解析源码为语法树后，通过 _walk_tree_sitter 递归遍历节点。节点类型映射表定义了各语言的函数节点（Java: method_declaration, constructor_declaration；C++: function_definition）、类节点（Java: class_declaration, interface_declaration, enum_declaration；C++: class_specifier, struct_specifier）和分支节点（Java: if_statement, switch_expression, for_statement 等；C++: if_statement, switch_statement, for_statement 等）。每个匹配节点通过 child_by_field_name("name") 提取标识符名称。

当 tree-sitter 不可用时，回退到正则解析。_parse_c_like 函数使用正则表达式匹配类声明、方法声明和分支语句，逐行扫描源码提取符号信息。

解析结果生成摘要文本，格式为"parsed N symbols: X functions, Y classes, Z methods, W branches"，同时返回符号列表，供提示词构建和评估使用。

图 4-3 AST 解析结果示例图

表 4-2 代码输入与 AST 解析核心接口设计表

4.3 参数配置与测试用例生成模块实现

4.3.1 参数配置模块实现

参数配置模块在前端 ConfigView.vue 中实现，提供模型选择、提示策略选择、评估指标选择和提示词预览编辑四大配置功能。模型选择下拉框提供 Gemini 3.0、GPT-4.0、Claude 3.5、Qwen 四个选项，与后端 constants.py 中的 SUPPORTED_MODELS 保持一致。提示策略下拉框提供零样本、少样本、模块化、自定义四个选项。评估指标区域提供六个复选框，用户可按需勾选。提示词预览区域展示根据当前配置动态生成的提示词内容，用户可直接编辑覆盖默认提示词。

图4-5 参数配置示例图

4.3.2 提示词构建服务实现

提示词构建服务由 prompt_service.py 和 models/prompt_template.py 协同实现。系统预定义了三种策略模板，每种模板包含 {language}、{code}、{ast_summary}、{test_goal} 四个占位符：

零样本模板（zero_shot）直接提供语言、目标、源码和 AST 摘要，要求生成测试用例和单元测试代码。模板内容为："You are a test generation assistant. Language: {language}. Goal: {test_goal}. Code: {code}. AST Summary: {ast_summary}. Generate test cases and unit test code."

少样本模板（few_shot）在零样本基础上增加上下文示例引导，模板内容增加"Follow the in-context examples pattern and generate unit tests."引导语。

模块化模板（modular）将生成过程分为三个步骤：第一步识别函数和分支，第二步设计测试场景，第三步输出单元测试代码。这种分步引导策略有助于 LLM 更系统地分析源码结构。

自定义策略要求用户提供 custom_template 字段，模板必须包含 {language} 和 {code} 两个必需占位符，否则返回校验错误。构建时通过 Python 的 str.format 方法将变量填充到模板中生成最终提示词。

当用户在参数配置页手动编辑提示词后，前端将编辑后的内容作为 manual_prompt 字段提交到生成接口，后端优先使用 manual_prompt，仅在 manual_prompt 为空时才调用提示词构建服务。

图 4-4 提示词构建流程图

4.3.3 LLM 网关实现

LLM 网关由 llm_gateway.py 和 services/providers/ 目录下的四个 Provider 协同实现。网关维护 _PROVIDER_MAP 映射表，将模型名映射到对应的 Provider 函数：

– gemini-3.0 → gemini_provider.generate

– gpt-4.0 → gpt_provider.generate

– claude-3.5 → claude_provider.generate

– qwen → qwen_provider.generate

每个Provider 的实现逻辑高度一致，均调用 call_openai_compatible_chat 函数，传入各自的 base_url、api_key 和 model_name 配置。配置通过 Settings 类从 .env 文件读取，支持统一API Key和按模型分别配置两种方式。当模型专属 Key 为空时，回退使用统一 Key。

a.call_openai_compatible_chat 函数封装了 OpenAI 兼容的 Chat Completions 接口调用逻辑。请求体包含 model、messages（system 消息和 user 消息）和 temperature（0.2）三个字段。响应解析首先提取 choices[0].message.content 获取原始文本，然后调用 parse_generation_text 函数解析生成结果。

b.parse_generation_text 函数采用多级解析策略：首先尝试提取命名段落（test_case_code、unit_test_code、explanation），然后尝试提取 Markdown 代码块（```标记），如果仍无法提取则判断文本是否包含代码特征（def、class、import、assert 等关键字），最后兜底将整个响应文本作为测试代码。Token 使用量优先从响应的 usage.total_tokens 字段获取，否则按文本长度除以 4 估算。

开发过程中遇到的主要问题是不同模型 API 的参数差异。解决方案是采用统一的 OpenAI 兼容接口格式，通过 302.ai 中转服务将不同模型的 API 统一为 Chat Completions 格式，各 Provider 只需配置不同的 base_url 和 model_name 即可，无需处理各厂商的原生 API 差异。

表4.3.4 测试用例生成结果解析与存储

生成接口的完整处理流程如下：首先检查 manual_prompt 是否为空，为空则调用提示词构建服务生成提示词；然后创建或获取实验记录（若请求中包含 experiment_id 则使用已有记录，否则创建新记录）；接着调用 LLM 网关执行生成，将生成结果更新到实验记录并持久化到 outputs 目录和数据库；最后返回包含 experiment_id、language、model 和 output 的响应。

生成结果存储采用双写策略：experiment_service 将完整的 ExperimentRecord（包含 GenerationOutput 和评估结果）序列化为 JSON 写入 outputs/{experiment_id}/experiment.json 文件；storage_service 将关键字段（experiment_id、language、model、prompt_strategy、source_code、prompt_text、generation_output_json）写入 run_records 数据库表。双写策略确保了数据的可靠性，JSON 文件便于离线查看和批量脚本读取，数据库表便于结构化查询。

4.4 质量评估模块实现

4.4.1 评估指标实现

质量评估模块由 evaluation_service.py 实现，六个评估指标的具体实现逻辑如下：

（1）准确率（_calc_accuracy）：首先从 AST 解析结果中提取所有 function 和 method 类型的符号名称，然后在合并后的测试代码文本（test_case_code + unit_test_code，转小写）中搜索每个函数名。使用 re.search 配合 \\b 单词边界确保精确匹配，统计命中数量后按公式计算评分。当源码无函数时返回默认 55 分。

（2）编译通过率（_calc_compile_pass_rate）：根据语言类型检测不同的编译信号。Python 检测"def test"、"assert"、"pytest"三个信号词；Java 检测"@test"、"assert"、"junit"三个信号词；C++ 检测"assert"、"test"两个信号词。任一信号词出现即判定为有编译信号，评 85 分，否则评 45 分。这种启发式方法虽然无法替代真实编译，但能有效区分结构完整和明显残缺的生成代码。

（3）行覆盖率（_calc_line_coverage）：统计生成代码中覆盖信号词（if、else、case、assert、exception、null、none）的出现次数，结合源码符号总数计算覆盖率估算值。基础分 35 分，每增加一个信号词与符号数的比值贡献 20 分，上限 100 分。当源码无符号时返回默认 40 分。

（4）分支覆盖率（_calc_branch_coverage）：统计生成代码中分支信号词（if、else、case、boundary、edge）的出现次数。当源码有分支节点时，按公式 30 + (分支信号次数 / 分支节点数) × 35 计算；当源码无分支节点时，按 60 + 分支信号次数 × 1.5 计算。无分支节点时的高基础分反映了源码本身无分支的特殊情况。

（5）有效率（_calc_validity）：检测生成代码中的占位符信号。当文本包含"todo"时扣 20 分，包含"placeholder"时再扣 20 分，基础分为 88 分。这种设计反映了包含占位符的代码通常不完整，需要人工补充。

（6）检错率（_calc_defect_detection）：统计生成代码中缺陷检测信号词（invalid、error、exception、negative、overflow、boundary）的出现次数，每个信号词贡献 7 分，基础分为 40 分。这些信号词反映了测试代码是否覆盖了异常和边界情况。

所有评分结果通过 _clip 函数限制在 [0, 100] 范围内，保留两位小数。

4.4.2 综合均分计算与结果保存

综合均分为所有选定指标评分的算术平均值，保留两位小数。评估流程的入口函数为 evaluate_generation_output，该函数首先对源码执行 AST 解析获取符号信息（函数名列表和分支节点数），然后合并 test_case_code 和 unit_test_code 的文本，遍历用户选定的指标调用对应的计算函数，最终返回 MetricResult 列表。

评估结果通过 /api/v1/evaluation-result 接口写入。该接口接收 experiment_id 和 results 列表，调用 experiment_service.upsert_evaluation_results 更新实验记录的状态为"evaluated"，同时调用 storage_service.update_evaluation_record 将评估结果 JSON 写入数据库。

4.4.3 批量评估实现

批量评估支持对多个代码样本、多个模型、多种策略的组合进行批量实验。run_batch_experiment 函数按照"样本→模型→策略"的三重循环依次执行：创建实验记录、构建提示词、调用 LLM 生成、执行评估、更新实验状态。每个组合的执行结果记录为 BatchExperimentItemResult，包含样本 ID、实验 ID、语言、模型、策略、状态和综合评分。执行过程中单个组合失败不影响其他组合，失败信息记录在 error 字段中。

图 4-5 质量评估结果示例图

4.5 前端界面实现

4.5.1 核心页面实现

登录页（AuthView.vue）：提供注册和登录两个表单，用户输入用户名和密码后调用 authService 的 register 或 login 方法，成功后将 Token 存储到 localStorage 并触发 authenticated 事件通知 App.vue 更新状态。

图4-6 登录页

代码输入页（CodeInputView.vue）：提供语言选择下拉框、代码粘贴文本框和文件上传按钮。用户提交代码后，先调用 /api/v1/code-input/normalize 或 /api/v1/code-input/upload 接口进行规范化，再调用 /api/v1/ast/parse 接口执行 AST 解析，解析结果（符号列表和摘要）展示在页面下方。

图4-7 代码输入页

参数配置页（ConfigView.vue）：提供模型选择、提示策略选择、评估指标选择、源码选择等配置项。用户选择参数后可点击"预览提示词"按钮调用 /api/v1/prompt/build 接口查看生成的提示词内容，并支持在文本框中手动编辑。确认后点击"执行生成"按钮调用 /api/v1/generation/run 接口触发生成，生成完成后自动跳转到结果页。

图4-8 参数配置页

单实验结果页（ResultView.vue）：展示实验的基本信息（实验 ID、语言、模型、策略、状态）、评估指标评分图表和生成代码。指标评分使用 ECharts 柱状图展示，支持模型对比功能。导出功能支持 JSON、CSV（通过后端 /api/v1/export/download 接口）和 PDF（通过前端 pdfExport.ts 在浏览器端生成）三种格式。

图4-9 单实验结果页

研究结论页（ResearchInsightView.vue）：提供时间范围筛选控件，调用 /api/v1/research-report 接口获取聚合统计数据。页面包含 StrategyInsightPanel 组件，使用 ECharts 柱状图和折线图展示按语言、模型、策略三个维度的指标均值和综合均分，同时展示自动生成的结论摘要文本。

图4-10 研究结论页

数据管理页（DataManagementView.vue）：提供实验历史和源码历史的分页列表，支持按关键字搜索、编辑和删除操作。实验列表展示实验 ID、语言、模型、策略、状态和操作按钮，源码列表展示源码 ID、语言、文件名和操作按钮。

图4-11 数据管理页

4.5.3 可视化与导出实现

ECharts 可视化通过 MetricsChart.vue 和 StrategyInsightPanel.vue 组件实现。MetricsChart 组件接收指标评分数据，渲染柱状图展示各指标得分；StrategyInsightPanel 组件接收聚合统计数据，渲染分组柱状图展示不同维度的指标均值对比。图表配置采用响应式设计，数据更新时自动重新渲染。

PDF 导出通过 pdfExport.ts 实现，使用 jsPDF 库在浏览器端生成 PDF 文档。exportExperimentReportToPdf 函数接收实验报告数据，按章节排版输出：第一页包含报告标题、导出时间、实验信息、指标评分和模型对比数据；第二页包含生成的测试用例代码和单元测试代码。文档使用 A4 格式，自动处理分页和文本换行。

第5章 平台展示与实验验证分析

5.1 平台功能展示

5.1.1 用户认证功能展示

用户打开平台首页后，系统自动检测本地存储的 Token 是否有效。若未登录，页面展示登录/注册界面。用户在注册表单中输入用户名和密码，点击"注册"按钮完成账户创建并自动登录；在登录表单中输入已有账户信息，点击"登录"按钮进入主界面。登录成功后页面顶部显示当前用户名和"退出登录"按钮。

图 5-1 用户登录界面截图

5.1.2 代码输入与 AST 解析功能展示

用户在"代码输入"页面选择编程语言（Java/Python/C++），在代码文本框中粘贴源码或点击"上传文件"按钮选择本地代码文件。提交后系统自动执行代码规范化，并在页面下方展示 AST 解析结果，包括解析摘要（如"parsed 5 symbols: 2 functions, 1 classes, 0 methods, 2 branches"）和符号列表（显示符号名称、类型和行号）。解析后的源码和符号信息自动保存，供后续参数配置使用。

图 5-2 代码输入与 AST 解析结果截图

5.1.3 参数配置与测试用例生成功能展示

用户在"参数配置与生成"页面依次选择目标源码、LLM 模型、提示策略和评估指标。选择完成后点击"预览提示词"按钮，页面展示根据当前配置动态生成的提示词内容，用户可直接在文本框中编辑修改。确认配置后点击"执行生成"按钮，系统调用 LLM 生成测试用例。生成完成后页面展示 test_case_code 和 unit_test_code 两个代码区域，支持在线查看和一键复制。

图 5-3 参数配置与提示词预览截图

图 5-4 测试用例生成结果截图

5.1.4 结果展示与导出功能展示

在"单实验结果与导出"页面，用户输入实验 ID 查询实验结果。页面展示实验基本信息和评估指标评分的 ECharts 柱状图，直观呈现各指标得分。模型对比功能展示同一源码在不同模型下的生成结果对比，包括各指标评分和综合均分的排名。导出功能支持三种格式：JSON 格式导出完整的实验记录数据，CSV 格式导出结构化的指标评分表格，PDF 格式导出排版美观的实验报告文档。

图 5-5 质量评估指标柱状图

图 5-6 模型对比结果截图

.1.5 研究结论与数据管理功能展示

在"研究结论"页面，用户可设置时间范围筛选实验数据，点击"刷新"按钮后页面展示三个维度的聚合统计图表：按语言聚合的指标均值柱状图、按模型聚合的指标均值柱状图、按策略聚合的指标均值柱状图。每个图表下方展示综合均分和样本数量，页面底部展示自动生成的结论摘要。

在"数据管理"页面，用户可分页浏览实验历史和源码历史记录，支持按关键字搜索源码。每条记录提供编辑和删除操作按钮，删除操作需确认后执行。

图 5-7 研究结论-按语言聚合统计折线图

图 5-8 研究结论-按模型聚合统计折线图

图 5-9 研究结论-按策略聚合统计折线图

图 5-10 数据管理页面截图

5.2 实验设计与验证

5.2.1 实验目的与方案

本实验旨在验证平台的功能完整性和稳定性，并通过系统性实验对比不同编程语言、不同大语言模型、不同提示策略下生成的测试用例质量，得出最优的模型与策略组合。

实验方案设计如下：从 HumanEval-X 数据集中选取 Java、Python、C++ 三种语言各 50 个函数作为测试样本，分别使用 Gemini 3.0、GPT-4.0、Claude 3.5、Qwen 四个模型，采用零样本（zero_shot）、少样本（few_shot）、模块化（modular）三种提示策略进行测试用例生成，使用平台的质量评估模块对生成结果进行六维度评估（准确率、编译通过率、行覆盖率、分支覆盖率、有效率、检错率），记录并分析实验数据。

实验变量和控制变量如下：自变量为编程语言（3 个水平）、大语言模型（4 个水平）和提示策略（3 个水平）；因变量为六个质量评估指标的评分和综合均分；控制变量包括测试样本来源（统一从 HumanEval-X 数据集选取）、评估方法（统一使用平台的启发式评估算法）和生成参数（temperature 统一设为 0.2）。实验总组合数为 3 × 4 × 3 × 50 = 1800 次生成，通过平台的批量实验脚本（run_batch_compare.py）自动执行。

5.2.2 不同编程语言实验结果分析

对三种编程语言下生成的测试用例质量指标进行统计，结果如下表所示：

表 5-1 不同编程语言测试用例质量指标均值表

从表 5-1 可以看出，Python 语言的测试用例生成质量在所有指标上均优于 Java 和 C++，综合均分达到 68.77 分。Java 次之，综合均分为 63.86 分。C++ 的综合均分最低，为 59.95 分。

Python 语言生成质量最高的原因主要有三点：一是 Python 语法简洁，函数定义和调用关系明确，LLM 更容易理解源码结构并生成准确的测试代码；二是 Python 的测试框架（如 pytest）使用简单，assert 语句直观，LLM 生成符合测试规范的代码概率更高；三是 Python 的 AST 解析使用原生 ast 库，符号提取精度高于 tree-sitter 和正则解析，为提示词构建和评估提供了更准确的源码结构信息。

C++ 生成质量相对较低的原因在于：C++ 语法复杂，模板、指针、内存管理等特性增加了 LLM 理解源码的难度；C++ 的测试框架（如 Google Test）使用较为复杂，LLM 生成符合规范的测试代码难度更大；C++ 的 AST 解析依赖 tree-sitter，在部分复杂语法结构下可能回退到正则解析，符号提取精度有所降低。

图 5-9 不同编程语言综合均分对比柱状图

5.2.3 不同大语言模型实验结果分析

对四个大语言模型下生成的测试用例质量指标进行统计，结果如下表所示：

表 5-2 不同大语言模型测试用例质量指标均值表

从表 5-2 可以看出，GPT-4.0 在所有指标上均表现最优，综合均分达到 71.00 分。Claude 3.5 紧随其后，综合均分为 68.91 分。Gemini 3.0 综合均分为 65.60 分，Qwen 综合均分最低为 62.32 分。

GPT-4.0 表现最优的原因在于其强大的代码理解和生成能力，能够更准确地识别源码中的函数逻辑和边界条件，生成结构完整、覆盖全面的测试代码。Claude 3.5 在代码生成方面同样表现出色，尤其在有效率指标上接近 GPT-4.0，生成的代码占位符较少。Gemini 3.0 在编译通过率上表现尚可，但在准确率和检错率方面有提升空间。Qwen 作为国产模型，在中文语境下有优势，但在代码生成的精确度和完整性方面与 GPT-4.0 和 Claude 3.5 存在一定差距，主要体现在函数名命中率较低和异常边界覆盖不足。

各模型的优缺点总结如下：GPT-4.0 优点是代码理解准确、生成质量高，缺点是 API 调用成本较高；Claude 3.5 优点是生成代码有效率高、占位符少，缺点是部分场景下函数覆盖不够全面；Gemini 3.0 优点是编译通过率稳定，缺点是检错率偏低；Qwen 优点是中文理解能力强、响应速度快，缺点是代码生成精确度有待提升。

图 5-10 不同大语言模型综合均分对比柱状图

5.2.4 不同提示策略实验结果分析

对三种提示策略下生成的测试用例质量指标进行统计，结果如下表所示：

表 5-3 不同提示策略测试用例质量指标均值表

从表 5-3 可以看出，模块化提示策略的综合均分最高，达到 69.98 分，显著优于少样本策略的 65.90 分和零样本策略的 61.26 分。少样本策略在各指标上均优于零样本策略，但与模块化策略存在明显差距。

模块化策略效果最好的原因在于其分步引导机制：首先要求 LLM 识别源码中的函数和分支结构，这一步促使模型深入分析源码逻辑；然后要求设计测试场景，引导模型从测试角度思考覆盖策略；最后输出单元测试代码，确保生成结果结构清晰。这种分步推理的方式有效提升了 LLM 对源码的理解深度和测试代码的覆盖广度。

少样本策略通过上下文示例引导 LLM 按照特定模式生成测试代码，相比零样本策略有显著提升，尤其在准确率和编译通过率方面。但示例的固定性限制了策略的适应性，当源码结构与示例差异较大时，引导效果减弱。

零样本策略直接要求生成测试代码，缺乏结构化引导，LLM 可能遗漏部分函数或分支的测试，导致准确率和覆盖率偏低。但零样本策略的优势在于通用性强，无需准备示例数据，适用于快速验证场景。

提示策略优化的方向包括：结合少样本和模块化策略的优点，设计"少样本+模块化"的混合策略；根据源码语言和复杂度动态选择最优策略；引入链式思考（Chain-of-Thought）提示技术，进一步提升 LLM 的推理深度。

图 5-11 不同提示策略综合均分对比柱状图

5.2.5 综合实验结论

综合以上三个维度的实验结果，可以得出以下结论：

在编程语言维度，Python 语言的测试用例生成质量最高（综合均分 68.77），Java 次之（63.86），C++ 最低（59.95）。Python 的语法简洁性和测试框架易用性是生成质量优势的主要原因。

在模型维度，GPT-4.0 的综合表现最优（综合均分 71.00），Claude 3.5 次之（68.91），Gemini 3.0 居中（65.60），Qwen 相对较低（62.32）。GPT-4.0 在代码理解和生成精度方面具有明显优势。

在提示策略维度，模块化策略效果最好（综合均分 69.98），少样本策略次之（65.90），零样本策略最低（61.26）。分步引导机制有效提升了生成质量。

综合最优组合为：Python 语言 + GPT-4.0 模型 + 模块化提示策略。在该组合下，综合均分可达 78 分以上，各指标均处于较高水平。对于 Java 语言，推荐 GPT-4.0 + 模块化策略组合；对于 C++ 语言，推荐 Claude 3.5 + 模块化策略组合（Claude 3.5 在 C++ 代码生成上表现相对稳定）。

平台的实际应用效果验证了其功能完整性和实用性：用户可在平台上完成从源码输入到结果导出的完整实验流程，批量实验脚本支持大规模自动化测试，研究结论模块能够自动聚合历史数据并生成有参考价值的结论摘要。

5.3 平台性能测试

为验证平台是否满足非功能性需求中的性能指标，本节对平台在不同并发用户数下的响应时间和吞吐量进行测试，并检验平台长时间运行的稳定性。

测试环境：CPU 为 Intel Core i7-12700H，内存 16GB，操作系统 Windows 11，后端运行在 uvicorn 单进程模式，前端通过 Vite 开发服务器提供。测试工具使用 Apache Bench（ab）模拟并发请求。

测试方案：选取三个代表性接口进行测试——健康检查接口（GET /health）、源码列表接口（GET /api/v1/code-input/sources）和代码规范化接口（POST /api/v1/code-input/normalize）。分别模拟 1、5、10、20、50 个并发用户，每个并发级别发送 100 个请求，记录平均响应时间和请求成功率。

表 5-4 平台并发性能测试结果表

从表 5-4 可以看出，在 10 个并发用户以内，常规接口的响应时间均控制在 120ms 以内，远低于 2 秒的性能需求指标，请求成功率为 100%。当并发用户数增加到 20 时，响应时间有所上升但仍可接受，请求成功率维持在 99.5%。当并发用户数达到 50 时，代码规范化接口的响应时间升至 420ms，请求成功率下降至 97.2%，主要原因是 SQLite 在高并发写入时存在锁竞争。

LLM 生成接口的响应时间主要取决于外部 API 调用耗时，在 10 个并发用户下平均响应时间为 15-35 秒，满足 60 秒以内的性能需求。

图 5-12 平台响应时间与并发用户数关系折线图

稳定性测试：平台在连续运行 24 小时、累计处理 500 次生成请求后，内存占用从初始的 85MB 增长至 120MB，增长幅度在合理范围内，未发现内存泄漏问题。experiment_service 的内存缓存 _STORE 在大量实验记录下会占用额外内存，可通过定期清理历史记录缓解。