课程导入：学习目标、核心概念与整体框架

欢迎进入《无人基于历史数据的缺陷预测模型》课程。在软件工程与质量保障领域，“缺陷预测”并非新词，但传统方法高度依赖人工标注的历史缺陷数据。本课程的核心命题，是探讨当历史数据不可用、不完整、不可信或根本不存在时，如何构建有效的缺陷预测机制。本章作为全课程的起点，将明确学习目标、厘清核心概念、搭建整体框架，并深入剖析“无人基于历史数据”这一前提的真实含义与工程挑战。

1.1 学习目标：从“预测”到“预判”的能力跃迁

本课程的学习目标并非仅仅掌握几种算法或工具，而是建立一套在数据约束下依然有效的缺陷预测思维体系。完成本章及后续课程后，学习者应达到以下四个层次的目标：

1.2 核心概念：什么是“无人基于历史数据”

“无人基于历史数据”并非一个状态，而是一个相对约束。它包含三个递进的层次，理解这三个层次是后续所有方法选择的前提。

• 数据缺失（Missing）：系统有历史版本，但缺陷记录未保存、未结构化或丢失。例如，早期版本使用Excel记录缺陷，后因人员离职文件丢失。
• 数据不可信（Unreliable）：存在历史数据，但质量极差——标签错误率高、字段缺失严重、记录口径不一致。例如，同一缺陷被重复提交多次，或严重级别标注混乱。
• 数据不存在（Nonexistent）：项目是全新的，或技术栈、业务领域发生根本性变化，历史数据完全无法反映当前状态。例如，从单体架构迁移到Serverless架构。

需要特别强调的是，本课程讨论的“无人”并非指完全没有数据可用，而是指没有“可靠的、有标注的、与当前项目同分布的历史缺陷数据”。代码仓库本身、编译日志、运行时监控数据、代码静态特征等，都属于“非历史缺陷数据”，它们是我们解决问题的重要素材。

1.3 整体框架：三条技术路线与一条评估主线

本课程30章内容围绕“三条技术路线+一条评估主线”展开，形成完整的知识体系。

三条路线并非互斥，实际工程中往往组合使用。例如，一个新启动的金融交易系统，可以先用路线B对代码进行静态扫描，再结合路线A从同行业的开源项目中迁移模型，上线后切换至路线C进行动态调整。

1.4 案例拆解：一个真实的“无历史数据”场景

为帮助理解上述概念，我们来看一个典型的工程案例。

背景与约束：某中型互联网公司决定将核心业务系统从Java单体架构重构为Go微服务架构。重构后的代码库约50万行，由4个团队并行开发。公司有完善的缺陷追踪系统（Jira），但历史缺陷记录全部针对Java单体应用，且缺陷描述与代码模块的关联关系已失效。

初始现象与目标：重构后的系统上线前，测试团队需要在有限时间内（3周）识别出高风险模块，以便优先安排测试资源。但此时系统尚未运行，无运行时数据；历史缺陷数据因架构差异完全不可用。

关键输入数据：

• Git仓库中Go代码的提交历史（约2000次提交）
• 代码评审记录（约800条评论）
• 静态代码分析工具（如golangci-lint）的输出报告
• 各微服务的接口定义文件（Proto文件）

分析判断过程：

1. 首先，团队排除了直接使用历史缺陷数据的可能性——Java与Go的代码特征分布差异过大，直接迁移模型会产生严重的分布偏移。
2. 其次，团队采用路线B：对Go代码进行静态分析，提取圈复杂度、函数长度、依赖深度等20项特征，并计算每个微服务的“风险密度”。
3. 同时，结合路线A：从GitHub上找到3个同规模的Go开源项目，使用其缺陷报告训练一个基础模型，再通过领域自适应技术（如CORAL方法）对齐特征分布。
4. 最后，将静态分析结果与迁移模型输出进行加权融合，生成每个微服务的风险评分。

实际操作与结果：团队将风险评分最高的5个微服务标记为“高风险”，并安排测试人员进行重点代码审查。结果发现，其中4个微服务确实存在严重的设计缺陷（如循环依赖、未处理的并发访问），而评分最低的10个微服务中仅1个存在轻微问题。该方案在3周内完成了全部模块的风险排序，测试资源利用率提升了约40%。

风险与代价：该方案的主要代价是静态分析会产生一定的误报率（约15%），需要人工复核；迁移模型在初期存在偏差，需要两周的在线数据校准。

复盘经验：在无历史数据场景下，多信号融合比依赖单一方法更可靠。静态分析提供“代码内在质量”信号，迁移学习提供“外部经验”信号，两者互补。此外，人工抽样验证（即使样本量很小）对于校准模型至关重要。

1.5 常见误区与总结复盘

在本章最后，我们梳理几个初学者容易陷入的误区，并给出总结性建议。