AI赋能软件测试:大语言模型与机器学习在自动化测试与缺陷预测中的应用实践
1. 项目概述当AI遇见软件测试毕业设计又到了一年一度的毕业季对于计算机相关专业的同学来说毕业设计无疑是大学四年知识的一次综合大考。选题选得好不仅答辩轻松还能为简历添上浓墨重彩的一笔。最近几年我指导或评审的毕设中一个趋势越来越明显将前沿的AI技术特别是大语言模型与传统软件工程实践相结合。而“AI辅助下的软件测试”无疑是一个兼具创新性、实用性和研究价值的黄金赛道。这个选题的核心就是利用AI来赋能软件测试的全流程解决传统测试中耗时、费力且依赖经验的痛点。想象一下你不再需要手动编写成百上千行枯燥的测试用例代码AI可以根据需求文档自动生成你也不再需要像大海捞针一样在日志中寻找Bug的蛛丝马迹AI可以分析代码变更和历史缺陷数据智能预测哪里最容易出问题。这听起来像是未来但实际上借助如今开源的AI工具和成熟的框架一个本科生完全有能力在几个月内搭建出一个可演示、有深度的原型系统。它不仅仅是“用了个AI接口”那么简单而是涉及到需求分析、测试策略设计、模型选型与微调、系统集成以及效果评估等一系列完整的软件工程实践完美契合毕设的要求。接下来我将以一个完整的毕设项目为蓝本拆解从零到一构建一个“AI辅助软件测试平台”的核心思路、技术选型、实操步骤以及那些容易踩坑的细节。无论你是正在选题的同学还是希望了解AI如何落地测试领域的同行相信这篇长文都能给你带来实实在在的启发。2. 项目整体设计与核心思路拆解2.1 需求分析与目标定义做任何项目尤其是毕设这种“麻雀虽小五脏俱全”的系统明确边界和目标至关重要。我们不能做一个“万能测试AI”而是要聚焦于1-2个核心场景做深做透。基于标题我们可以锁定两个主要功能模块自动化测试用例生成输入可以是自然语言描述的需求如用户故事、接口文档如Swagger/OpenAPI、甚至是部分代码输出是结构化的、可执行的测试用例代码如Python的pytest脚本、Java的JUnit测试类。智能缺陷预测输入本次的代码变更Diff、历史缺陷数据、代码复杂度度量等输出风险提示标记出本次变更中缺陷高发的文件或模块。为什么是这两个场景首先它们代表了测试“事前”与“事后”的两个关键环节用例生成是预防缺陷的第一道防线缺陷预测是在开发过程中进行风险预警。其次它们对AI能力的要求有差异便于展示技术多样性。用例生成更依赖大语言模型的代码生成和理解能力缺陷预测则更偏向于传统的机器学习或深度学习模型对结构化数据的模式识别。最后这两个模块都有明确的输入输出易于设计评估指标如生成用例的通过率、预测缺陷的准确率/召回率方便在论文中展示成果。项目目标设定SMART原则具体的开发一个具有Web界面的原型系统集成上述两个核心功能。可衡量的对于用例生成实现针对简单RESTful API的需求描述生成可执行pytest脚本的准确率语法正确、能运行达到80%以上对于缺陷预测在某个开源项目历史数据上模型预测的AUC值达到0.7以上。可实现的基于开源大模型如ChatGLM3、Qwen、CodeLlama和机器学习框架如scikit-learn, LightGBM进行开发不依赖昂贵的商业API。相关的紧密围绕软件测试自动化和智能化主题。有时限的在毕设计划周期内完成核心功能开发、实验评估和论文撰写。2.2 技术栈选型与架构设计技术选型直接决定了开发难度和最终效果。我们的原则是优先选择生态成熟、社区活跃、易于集成和部署的开源方案。后端技术栈Web框架FastAPI。它是现代Python Web框架的佼佼者异步性能好自动生成交互式API文档Swagger UI对于需要前后端联调的毕设来说能节省大量时间。相比Django它更轻量、更灵活相比Flask它的异步支持和类型提示更现代。AI/ML核心大语言模型用于用例生成考虑到本地部署和微调的需求推荐ChatGLM3-6B或Qwen1.5-7B。它们对中文支持好在代码生成和理解任务上表现不错且有丰富的量化版本如int4可以在消费级显卡如RTX 4060 16G上流畅运行。如果硬件资源有限可以考虑更小的模型如CodeQwen1.5-1.5B专为代码优化。缺陷预测模型这是一个经典的二分类问题预测某次代码变更是否会引入缺陷。可以从简单的逻辑回归Logistic Regression、随机森林Random Forest开始效果不错且可解释性强。如果想尝试深度学习可以使用LightGBM或XGBoost它们在处理表格数据上通常优于神经网络。特征工程是关键可以从代码变更中提取特征如变更行数、修改文件类型、涉及开发者经验值、代码复杂度变化等。向量数据库可选但推荐如果我们想让用例生成更“智能”例如支持基于历史用例库的相似检索和增强可以引入ChromaDB或Milvus Lite。它们轻量、易用可以将历史需求-用例对存入向量库实现RAG检索增强生成提升生成用例的相关性和准确性。任务队列可选如果模型推理耗时较长为避免HTTP请求超时可以引入CeleryRedis来处理异步任务前端通过轮询或WebSocket获取结果。前端技术栈框架Vue 3或React。两者皆可选择你更熟悉的。对于快速原型也可以考虑Streamlit纯Python但定制性和美观度稍弱。UI库Element PlusVue或Ant DesignReact。提供丰富的现成组件能快速搭建出专业的后台管理界面。系统架构图逻辑层面整个系统可以设计为前后端分离的架构。前端提供用户界面用于上传需求文档、提交代码Diff、查看生成结果和预测报告。后端核心是一个FastAPI应用它内部集成了两个服务用例生成服务接收需求文本调用本地部署的LLM结合可能的向量检索结果生成测试用例代码并返回给前端。缺陷预测服务接收代码仓库地址或直接上传的Diff文件调用特征提取模块将特征输入训练好的预测模型得到风险评分和热点文件列表生成可视化报告。数据库方面可以用SQLite开发/演示或PostgreSQL生产存储用户操作记录、生成的历史用例、模型预测结果等。注意硬件是道坎。如果你的电脑没有独立显卡NVIDIA GPU运行6B/7B的模型会非常吃力纯CPU推理极慢。解决方案有1使用云平台的GPU实例按需付费注意成本2选择更小的模型如1.5B-3B参数3使用量化到更低精度如int4, int8的模型版本牺牲少量精度换取内存和速度的优化。务必在技术选型初期就验证模型在你的硬件上能否跑起来。3. 核心模块一AI驱动的自动化测试用例生成3.1 工作流程与Prompt工程这个模块的目标是让AI成为一个“测试工程师”它需要理解需求然后输出可执行的代码。其核心工作流程如下输入处理用户在前端输入一段自然语言需求例如“用户登录功能需要验证用户名和密码。用户名长度为6-18位密码需包含大小写字母和数字长度至少8位。登录成功返回token失败返回错误信息。”需求解析与增强可选系统可以首先对输入的需求进行标准化例如提取关键实体“用户”、“登录”、操作“验证”和约束条件“长度6-18”。更高级的做法是将需求文本向量化从向量数据库中检索出历史上类似的、已有人工编写的高质量测试用例将这些用例作为“参考范例”一同喂给AI。Prompt构建这是成败的关键。你不能简单地把需求扔给AI说“写个测试用例”。需要构建一个结构化的、包含角色、任务、格式要求和示例的Prompt系统提示词。一个有效的Prompt模板可能长这样你是一个资深的软件测试工程师擅长编写Python pytest测试用例。请根据以下功能需求生成对应的自动化测试用例代码。 【需求描述】 {user_input} 【输出要求】 1. 使用Python语言和pytest框架。 2. 测试函数名需清晰表达测试意图使用test_前缀。 3. 包含正向用例有效数据和反向用例无效数据。 4. 对输入参数的边界条件进行充分测试。 5. 代码中需包含必要的断言assert。 6. 假设被测试的函数/API已经存在你只需要生成测试代码。 7. 最终输出只包含代码不要有任何解释性文字。 【参考示例】 需求一个计算两个整数之和的函数add(a, b)。 生成的测试用例 python import pytest def test_add_positive_numbers(): assert add(1, 2) 3 def test_add_negative_numbers(): assert add(-1, -2) -3 def test_add_with_zero(): assert add(0, 5) 5 assert add(5, 0) 5 def test_add_invalid_input(): # 假设函数对非整数输入会抛出TypeError with pytest.raises(TypeError): add(a, 1)现在请根据上述【需求描述】生成测试用例。4. **调用LLM生成**将构建好的Prompt发送给本地部署的LLM如ChatGLM3获取其回复。 5. **后处理与返回**对AI返回的文本进行清洗提取出代码块通常位于python ... 之间进行简单的语法检查如使用ast模块解析然后将纯净的代码返回给前端。前端可以提供一键复制或直接下载为.py文件的功能。 ### 3.2 模型部署与集成实战 以部署 **ChatGLM3-6B** 模型为例展示如何将其集成到FastAPI后端中。 **步骤1环境准备与模型下载** bash # 创建虚拟环境 python -m venv venv source venv/bin/activate # Linux/Mac # venv\Scripts\activate # Windows # 安装基础依赖 pip install fastapi uvicorn pydantic # 安装ChatGLM3的推理库这里使用官方推荐的transformers库 pip install transformers torch # 如果需要使用量化版本以节省显存可以安装accelerate和cpm_kernels针对CUDA pip install accelerate cpm_kernels步骤2编写模型加载与推理服务创建一个文件llm_service.pyfrom transformers import AutoTokenizer, AutoModel import torch import warnings warnings.filterwarnings(ignore) class ChatGLMService: def __init__(self, model_pathTHUDM/chatglm3-6b): # 指定模型路径可以是Hugging Face模型ID也可以是本地下载的路径 print(f正在加载模型: {model_path}) self.tokenizer AutoTokenizer.from_pretrained(model_path, trust_remote_codeTrue) # 根据硬件情况选择加载方式 if torch.cuda.is_available(): self.model AutoModel.from_pretrained(model_path, trust_remote_codeTrue).half().cuda() self.model self.model.eval() else: # CPU模式非常慢仅用于演示或极小模型 self.model AutoModel.from_pretrained(model_path, trust_remote_codeTrue).float() self.model self.model.eval() print(模型加载完毕。) def generate_test_case(self, prompt, max_length1024): 根据prompt生成测试用例 try: # 使用模型的chat方式构建对话历史 # 这里我们简单地将整个prompt作为用户输入 response, history self.model.chat(self.tokenizer, prompt, history[], max_lengthmax_length, temperature0.2) # temperature调低使输出更确定、更稳定 return response except Exception as e: return f生成过程中发生错误: {str(e)} # 全局单例避免重复加载模型 llm_service ChatGLMService(model_path/path/to/your/local/chatglm3-6b) # 或使用 THUDM/chatglm3-6b 在线下载首次慢步骤3创建FastAPI路由创建main.pyfrom fastapi import FastAPI, HTTPException from pydantic import BaseModel from llm_service import llm_service import re app FastAPI(titleAI测试辅助平台API) class TestCaseRequest(BaseModel): requirement: str # 用户输入的需求描述 app.post(/generate-test-case/) async def generate_test_case(request: TestCaseRequest): 接收需求生成测试用例 user_input request.requirement # 构建Prompt这里简化了实际可以更复杂 system_prompt 你是一个资深的软件测试工程师... # 此处填入上文提到的完整Prompt模板 full_prompt system_prompt.replace({user_input}, user_input) # 调用LLM服务 raw_output llm_service.generate_test_case(full_prompt) # 后处理提取代码块 code_pattern rpython\n(.*?)\n matches re.findall(code_pattern, raw_output, re.DOTALL) if matches: generated_code matches[0].strip() else: # 如果没有找到代码块尝试提取看起来像代码的部分 generated_code raw_output.strip() # 简单的语法校验可选 # try: # ast.parse(generated_code) # syntax_ok True # except SyntaxError as e: # syntax_ok False # generated_code f\n# 语法检查警告: {e} return { requirement: user_input, raw_response: raw_output, generated_code: generated_code } if __name__ __main__: import uvicorn uvicorn.run(app, host0.0.0.0, port8000)运行python main.py访问http://localhost:8000/docs就能看到自动生成的API文档并可以测试接口了。实操心得Prompt是灵魂后处理是保障。迭代优化Prompt不要指望一次写出完美的Prompt。准备一批测试需求观察AI生成的代码针对性地调整Prompt。例如如果AI总忘记写import pytest就在Prompt里强调如果生成的断言太简单就要求它“包含对返回JSON结构中特定字段的断言”。温度Temperature参数对于生成代码这种需要确定性的任务将temperature设置得较低如0.1-0.3可以减少随机性让输出更稳定。对于需要创造性的场景如生成测试场景可以适当调高。后处理必不可少AI的输出可能包含多余的说明、markdown格式符号。用正则表达式精准提取代码块能极大提升用户体验。更进阶的做法是将生成的代码送入一个代码格式化工具如black进行美化。性能与缓存模型推理很慢。对于相同的需求输入可以在后端加入缓存机制如functools.lru_cache将(prompt, 参数)的哈希值作为key存储生成的代码下次相同请求直接返回大幅提升响应速度。4. 核心模块二基于机器学习的智能缺陷预测4.1 问题定义与特征工程缺陷预测本质上是一个二分类问题给定一次代码变更Commit预测它是否会导致缺陷Bug。我们需要将其转化为机器学习模型可以处理的数据。数据来源最理想的数据是开源项目的版本控制系统如Git和缺陷跟踪系统如Jira, GitHub Issues的关联数据。我们可以从GitHub上寻找目标项目如apache/kafka,spring-projects/spring-boot利用其丰富的提交历史和Issue记录。数据处理流程数据收集使用git log命令和GitHub API获取项目的所有提交记录以及标记为bug、fix的Issue。数据关联将修复Bug的提交通常提交信息中包含“fix #123”与引入Bug的提交关联起来。这是一个研究课题常用“SZZ算法”来近似定位引入缺陷的变更。对于毕设我们可以简化将一个提交之后一段时间内如6个月出现的、且与该提交修改的文件相关的Bug视为由该提交引入。这虽然不精确但足以构建一个可用的训练集。特征提取这是模型效果的决定性因素。可以从以下几个维度提取特征变更维度变更的行数增加、删除、修改、变更的文件数、变更文件的类型.java, .py, .js等、变更的目录深度。开发者维度提交者的经验在该项目的提交总数、距上次提交的天数、是否是核心贡献者。代码维度修改文件的代码复杂度如圈复杂度可用lizard等工具计算、文件的历史缺陷数、文件的年龄首次提交至今的天数。文本维度提交日志的长度、是否包含特定关键词如fix,bug,error可以用简单的词袋模型或TF-IDF提取特征。特征表示最终每个代码提交样本都表示为一个特征向量X对应的标签y是二进制的1表示有缺陷0表示无缺陷。4.2 模型训练、评估与部署我们使用经典的scikit-learn库来演示整个过程。步骤1准备数据与特征假设我们已经有了一个CSV文件commit_features.csv包含特征和标签。import pandas as pd from sklearn.model_selection import train_test_split from sklearn.preprocessing import StandardScaler # 加载数据 df pd.read_csv(commit_features.csv) # 假设最后一列是标签 is_buggy X df.drop(is_buggy, axis1) y df[is_buggy] # 划分训练集和测试集 X_train, X_test, y_train, y_test train_test_split(X, y, test_size0.2, random_state42, stratifyy) # 特征标准化对很多模型很重要 scaler StandardScaler() X_train_scaled scaler.fit_transform(X_train) X_test_scaled scaler.transform(X_test)步骤2训练与评估模型我们尝试几种不同的模型并选择表现最好的。from sklearn.linear_model import LogisticRegression from sklearn.ensemble import RandomForestClassifier from sklearn.metrics import classification_report, confusion_matrix, roc_auc_score, accuracy_score import matplotlib.pyplot as plt import seaborn as sns models { Logistic Regression: LogisticRegression(max_iter1000), Random Forest: RandomForestClassifier(n_estimators100, random_state42) } results {} for name, model in models.items(): model.fit(X_train_scaled, y_train) y_pred model.predict(X_test_scaled) y_pred_proba model.predict_proba(X_test_scaled)[:, 1] # 取正类的概率 accuracy accuracy_score(y_test, y_pred) auc roc_auc_score(y_test, y_pred_proba) report classification_report(y_test, y_pred, output_dictTrue) results[name] { model: model, accuracy: accuracy, auc: auc, report: report } print(f{name}: Accuracy {accuracy:.4f}, AUC {auc:.4f}) print(classification_report(y_test, y_pred)) # 可视化比较 fig, axes plt.subplots(1, 2, figsize(12, 4)) for idx, (name, res) in enumerate(results.items()): # 绘制混淆矩阵 cm confusion_matrix(y_test, res[model].predict(X_test_scaled)) sns.heatmap(cm, annotTrue, fmtd, axaxes[idx]) axes[idx].set_title(f{name} Confusion Matrix) axes[idx].set_xlabel(Predicted) axes[idx].set_ylabel(Actual) plt.tight_layout() plt.savefig(model_comparison.png) # 保存图片用于论文 plt.show()步骤3模型保存与部署选择AUC最高的模型假设是Random Forest将其保存下来并集成到FastAPI中。import joblib # 保存模型和标准化器 best_model results[Random Forest][model] joblib.dump(best_model, defect_predictor_rf.pkl) joblib.dump(scaler, feature_scaler.pkl) # 在FastAPI中加载和使用 class DefectPredictor: def __init__(self, model_pathdefect_predictor_rf.pkl, scaler_pathfeature_scaler.pkl): self.model joblib.load(model_path) self.scaler joblib.load(scaler_path) self.feature_names X.columns.tolist() # 需要保存特征列名顺序 def predict(self, commit_features_dict): commit_features_dict是一个字典键为特征名值为特征值 # 将字典转换为DataFrame并确保特征顺序与训练时一致 features_df pd.DataFrame([commit_features_dict], columnsself.feature_names) # 标准化 features_scaled self.scaler.transform(features_df) # 预测 probability self.model.predict_proba(features_scaled)[0, 1] # 预测为缺陷的概率 prediction self.model.predict(features_scaled)[0] return { is_buggy_predicted: bool(prediction), bug_probability: float(probability), risk_level: 高风险 if probability 0.7 else (中风险 if probability 0.3 else 低风险) } # FastAPI路由 app.post(/predict-defect/) async def predict_defect(commit_data: dict): # 前端需要按照特征名传值 predictor DefectPredictor() result predictor.predict(commit_data) return result注意事项数据不平衡与评估陷阱。数据不平衡在软件项目中干净的提交远多于有缺陷的提交标签y的分布通常是极度不平衡的如95%是05%是1。直接在这种数据上训练模型会倾向于把所有样本都预测为“无缺陷”也能获得很高的准确率但这毫无意义。解决方法使用过采样如SMOTE、欠采样或为类别赋予不同的权重如class_weightbalanced。更重要的是不要用准确率Accuracy作为主要评估指标而应使用精确率Precision、召回率Recall、F1-score和AUC。特征泄露确保特征中不包含“未来信息”。例如不能用“该文件在本次提交之后的缺陷数”作为特征。这会导致模型在训练时“作弊”在实际预测中完全失效。在线预测流程在实际系统中当开发者提交代码时需要自动提取本次提交的特征可以写一个Git钩子脚本或集成到CI/CD流水线中然后调用我们的预测API将结果反馈给开发者或标记在代码审查工具中。5. 系统集成、前端展示与效果评估5.1 前后端联调与界面设计后端API准备好后我们需要一个前端界面让用户评审老师能够直观地使用。以Vue 3 Element Plus为例展示核心页面的设计。用例生成页面(TestCaseGenerator.vue)组件一个大的文本输入框用于输入需求一个“生成”按钮一个代码编辑器组件如codemirror包装的组件用于高亮显示生成的Python代码。交互用户输入需求点击生成前端调用/generate-test-case/接口将返回的代码显示在编辑器中并提供复制和下载按钮。缺陷预测页面(DefectPredictor.vue)组件一个Git仓库URL输入框和一个“分析”按钮。或者一个文件上传组件允许用户直接上传本次的代码Diff文件git diff的输出。一个展示区域用于显示预测结果风险等级用不同颜色的标签显示、缺陷概率值、风险最高的文件列表可排序。一个图表区域可使用ECharts展示本次提交与历史提交的风险对比或文件级别的风险热力图。关键API调用示例前端// 使用axios调用用例生成接口 import axios from axios; const generateTestCase async (requirementText) { try { const response await axios.post(/generate-test-case/, { requirement: requirementText }); // response.data.generated_code 即为生成的代码 return response.data; } catch (error) { console.error(生成失败:, error); throw error; } }; // 调用缺陷预测接口 const predictDefect async (gitDiffText) { // 假设我们有一个后端接口可以接收diff并自动提取特征 const response await axios.post(/predict-from-diff/, { diff: gitDiffText }); // response.data 包含 is_buggy_predicted, bug_probability, risk_level 等 return response.data; };5.2 毕设核心效果评估与论文撰写系统做出来只是第一步如何科学地评估它并将过程、方法和结果清晰地呈现在毕业论文中才是获得高分的关键。对于AI用例生成模块的评估语法正确率随机选取N个需求生成测试用例检查生成的代码是否能通过Python语法解析ast.parse。计算通过的比例。功能正确率更关键为每个测试需求手动编写或确定一个“标准答案”测试套件。然后运行AI生成的测试用例看它们能否在正确的实现上通过在错误的实现上失败。这需要你构造一些简单的“被测函数”作为测试靶子。代码质量度量使用像pylint或flake8这样的工具评估生成代码的规范性如命名、注释、复杂度。与人工编写的测试用例进行对比。人工评估设计一个调查问卷邀请同学或导师对AI生成的用例和人工编写的用例在“可读性”、“完整性”、“边界覆盖”等方面进行盲评打分。使用统计方法如T检验分析是否存在显著差异。对于缺陷预测模块的评估标准机器学习指标在预留的测试集上计算模型的精确率、召回率、F1-score、AUC-ROC曲线。重点分析AUC值它衡量模型整体排序能力对不平衡数据很稳健。对比实验这是毕设的亮点。训练多个不同模型逻辑回归、随机森林、XGBoost、简单的神经网络在同一测试集上比较它们的性能。可以做一个对比表格放入论文。特征重要性分析对于树模型如随机森林可以输出特征重要性排序。分析哪些特征对预测缺陷贡献最大例如“修改文件的圈复杂度变化”是否比“开发者经验”更重要这个分析能提升论文的理论深度。论文结构建议绪论阐述研究背景软件测试成本高、AI发展、意义明确你的研究内容两个模块和目标。相关技术综述简要介绍软件测试、自动化测试、缺陷预测、大语言模型、机器学习分类算法等基础概念和技术。系统需求分析与设计详细描述两个功能模块的需求给出系统的总体架构图、模块划分和数据库设计如果有。系统实现这是核心章节。分小节详细描述用例生成模块的Prompt设计、模型部署与集成细节。缺陷预测模块的数据收集、特征工程、模型训练与优化的具体过程。前后端实现的关键技术选型和代码结构。实验与结果分析按照上述评估方法设计实验展示实验结果多用图表如混淆矩阵、ROC曲线、对比表格并对结果进行分析和讨论。务必指出当前系统的局限性如模型规模小导致生成用例不够复杂、预测模型在项目间泛化能力可能不足等这是严谨性的体现。总结与展望总结全文工作重申创新点和价值并提出未来可以改进的方向如引入更强大的代码专用大模型、尝试深度学习模型进行缺陷预测、与CI/CD工具深度集成等。6. 常见问题、避坑指南与资源推荐6.1 开发与部署中的典型问题Q模型下载慢或无法下载A使用国内镜像源。对于Hugging Face模型可以使用huggingface-cli命令指定镜像或者直接从国内平台如ModelScope下载。将模型提前下载到本地目录然后在代码中指定model_path为本地路径。Q运行LLM时显存不足CUDA out of memoryA这是最常见的问题。解决方案按优先级使用量化模型寻找并加载int4或int8量化版本的模型能大幅减少显存占用。减小模型尺寸换用参数量更小的模型如从6B换到1.5B。调整推理参数减少max_length生成的最大令牌数启用torch.cuda.empty_cache()定期清理缓存。使用CPU推理作为最后手段速度会慢很多但可以运行。Q生成的测试用例逻辑错误或无法运行A首先检查Prompt。确保在Prompt中提供了清晰、具体的输出格式要求和高质量的示例。其次可以尝试“链式思考Chain-of-Thought”Prompting让AI先输出测试设计思路再输出代码。最后在后端加入一个“沙箱”环境自动运行生成的测试用例在一个隔离的容器中如果运行失败将错误信息反馈给AI让它重新生成这属于更高级的Agent技术。Q缺陷预测模型在真实项目上效果很差A首先检查特征工程。特征是否真的与缺陷引入相关可以多读一些软件缺陷预测领域的论文借鉴他们的特征集。其次检查数据质量问题。你标注的“缺陷引入提交”准确吗噪声太大的数据会严重损害模型性能。可以采用更稳健的算法如随机森林本身抗噪能力较强或者进行严格的数据清洗。6.2 资源与工具推荐开源项目与数据集Defect Prediction DatasetsPromise Repository (http://openscience.us/repo/) 提供了经典的缺陷预测数据集。SZZ Implementations在GitHub上搜索“SZZ”可以找到多种语言实现的SZZ算法用于关联缺陷和提交。AI与ML工具Hugging Face / ModelScope获取预训练大模型的一站式平台。LangChain / LlamaIndex如果你想构建更复杂的AI应用链如RAG这些框架很有用但对毕设而言可能过重。Weights Biases (wandb)用于跟踪机器学习实验过程可视化超参数和指标让论文中的实验部分更专业。测试与代码分析工具lizard一个简单的代码复杂度分析工具支持多种语言可用于提取圈复杂度等特征。pytestPython测试框架也是你生成的测试用例的目标框架。SonarQube专业的代码质量管理平台其API可以获取丰富的代码度量元可作为高级特征来源。最后一点个人体会做这样一个AI测试的毕设最难的不是编码而是如何定义清晰的问题边界和设计科学的评估体系。避免陷入“为了用AI而用AI”的陷阱时刻问自己这个AI模块到底比传统方法好在哪里如何量化这个“好”把这些问题想清楚并在系统中体现出来你的毕设就成功了一大半。这个项目做下来你收获的将不仅仅是一个毕业设计更是一套完整的、关于如何将AI技术落地到具体工程问题的宝贵方法论。