阅读视图

AI生成功能设计用例｜得物技术

2025年5月21日 13:31

一、AI背景

人工智能生成内容（AIGC，AI-Generated Content）技术的快速发展正在改变内容生产的方式，并逐渐渗透到各个行业，例如：在自媒体平台自动编写文案并发布，快速分析数据，写小说，画漫画等。强大的文本生成能力已经实现了生产力超过生产资料，提供了更加高效的生产力，将AI引入到工作中成为发展的方向。

目前公司编写测试用例为人工编写，存在手工编写用例的普遍痛点，例如：重新编写，费时费力，边界遗漏，兼容遗漏等。AI拥有自动生成文本并快速整合的能力，以AI辅助功能用例编写成为推动行业创新和效率提升的关键点。

AI编写用例的优点：

※ 效率提升

AI可以快速生成大量测试用例，显著减少人工编写所需的时间，提升整体测试效率。

※ 测试覆盖提升

AI能够自动识别潜在的测试场景和边界条件，从而提高测试覆盖率**，确保更全面的检测。

※ 一致性和准确性提升

AI生成测试用例具有较高的一致性和易理解性，减少人为错误，增强测试的可靠性和准确性。

AI热词：

二、设计方案

本部分介绍使用AI编写测试用例的的设计方案，包括使用流程和架构图。

AI编写用例流程图

AI编写用例架构图

三、设计核心介绍

本部分介绍如何使用AI辅助生成功能用例，详细讲解了从PRD文档->测试点->测试用例->Xmind用例->使用采纳，整条链路的核心设计与实现。

PRD文件解析器

平台支持飞书PRD文档中文本、多维表格、电子表格内容的解析，暂不支持对图片、流程图解析。文档读取分为6个步骤，分别为：获取飞书token、获取用户token、获取文件block列表、Table表格解析、电子表格解析、解析结果组装。以下主要介绍解析部分内容：

结构组成设计：

实现方案详情

※ 飞书文档读取

※ Table的提取与sheet表格的提取

Table提取：提取表格过程中需要将表格相关的块与子块关联绑定，递归解析所有的数据。并根据第一行各字段的长度<20做是否为表头判定，默认第一行为表头信息。

sheet提取：在飞书表格提取过程中需要使用多个递归，分别获取表格所有内容与元素

※ AI解析PRD文档：

PRD解析：通过与AI交互将文本内容解析为：需求关键字、测试背景、测试需求详情三部分，并按照特定字段将数据存储。

结构设计：

PRD解析结构设计

核心代码逻辑：

※ 获取关联测试需求业务背景：

根据PRD解析关键字信息匹配最相关的测试用例模块，使用向量和关键字双权重对RAG**模块做测试用例提取：

keyword_weight:0.3
vector_weight:0.7
同时设置AI模型准确度为0.85

匹配过程中分别针对不同的关键字，从RAG数据中提取热度最高的3个测试模块，合并后提取所有模块中热度最高的三个模块作为业务历史背景。

RAG提取架构设计

核心代码逻辑

模型设计

测试点生成器

测试点生成器为AI生成用例的核心，实现PRD到测试点的转换。生成过程中结合需求背景、关键字、需求详情、业务背景、测试分析等信息作为业务背景，以更准确的生成测试用例。核心结构如下：

结构组成设计

实现方案详情

模型设计

测试用例生成器

测试用例生成器为AI用例生成器，负责将AI测试点转换为Xmind测试用例，主要实现两个功能，第一步将AI测试点转换为markdown结构的测试用例，包括用例名称、前置条件、执行步骤、期望结果等。第二部负责将第一步测试用例转换为Xmind结构。

实现方案详情

※ 测试点解析生成markdown格式用例：

生成markdown格式用例

解析结果

※ AI markdown格式转换为Xmind结构用例

转换Xmind结构

生成结果

模型设计

知识库搭建

LLM大模型有通用的推荐能力，针对公司业务场景是无法准确识别相关功能的，针对“最后一公里”问题，平台使用搭建测试用例知识库的方式，以提升推荐准确度。

平台会以历史测试用例与业务需求文档作为历史业务背景。在推荐功能用例过程中自动匹配历史业务背景，以提升推荐准确度。

知识库搭建

※ 知识库涉及范围

※ 实现方案详情

Xmind测试用例转换知识库

业务文档转换知识库

※ 模型设计：

测试用例转换文本AI模型

业务文档转换业务文档模型

四、实现结果展示

五、总结 & 规划

目前平台侧已经实现自动生成功能用例的功能，实现了从 PRD自动解析->测试点生成-> Xmind用例生成->同步平台的完整流程。可以一定程度上提升用户编写用例效率。

后续规划

支持PRD文档图片/流程图等多模态数据解析
持续完善RAG模型与测试用例知识库的维护

往期回顾

1.从零实现模块级代码影响面分析方案｜得物技术

2.以细节诠释专业，用成长定义价值——对话@孟同学｜得物技术

3.得物可观测平台架构升级：基于GreptimeDB的全新监控体系实践

4.得物自研DGraph4.0推荐核心引擎升级之路

5.大语言模型的训练后量化算法综述 | 得物技术

文 / 执一

关注得物技术，每周更新技术干货

要是觉得文章对你有帮助的话，欢迎评论转发点赞～

未经得物技术许可严禁转载，否则依法追究法律责任。

从零实现模块级代码影响面分析方案｜得物技术

掘金专栏-得物技术

得物技术

2025年5月19日 12:00

一、名词解释

代码影响面（Code Impact Analysis）

是指在代码变更后，分析这些变更对系统中其他部分的影响范围。它帮助开发团队理解代码修改的潜在影响，从而减少意外问题并提高代码质量。

模块级

是指以模块（Module）为单位的代码组织、分析和管理的粒度。模块是代码的基本单元，通常包含一组相关的功能，可以是 JavaScript 文件、UI 组件、页面或其他功能单元。

二、背景 & 价值

在过往交易域稳定性建设中，我们完成了多项关键工作，包括后台应用拆分、历史债务重构、权限配置管控和核心H5页面定期巡检任务等。此外，我们还整合了前端监控平台的各类异常数据分析与告警能力，帮助提前发现系统性风险，以提升系统的整体稳定性。

通过对于以往故障案例的复盘，我们也识别出一些导致系统稳定性问题的潜在隐患，尤其是随着业务复杂度提升，单个版本往往涉及大量页面改动和复杂的依赖关系。现有的影响面评估方式难以全面覆盖这些变更，在这种情况下容易导致出现生产问题时止血时间的拉长，影响了系统的稳定性和用户体验。

在迭代发布视角下，代码影响面的分析尤为重要。每次迭代发布通常涉及多个功能或模块的更新，而这些更新可能会对系统的其他部分产生直接或间接的影响。

问题梳理

风险评估滞后

依赖人工经验判断改动影响面，在涉及多人协作和多个模块的团队开发或Monorepo等复杂场景下尤其低效。

信息维度割裂

现有研发协同平台以需求为纬度聚合研发相关信息，而前端稳定性保障则更需要以页面为纬度聚合迭代相关信息。

变更追踪困难

关键变更信息散落在群聊或各个系统中，缺乏一个统一的平台来聚合这些信息，导致信息同步和协作效率低下。

因此，我们希望实现一套自动化收集模块级代码影响面分析的方案，并以此评估版本需求发布对于系统整体稳定性的影响，从而提前确保重点模块能够得到有效的预警和监控，并创建相应的预案计划。

价值收益

研发自测能力提升

能够更精准地识别更改影响的页面或模块，确保需求影响范围符合预期。

测试覆盖率优化

结合变更影响，确保关键路径的完整测试，提升测试的有效性和覆盖率。

评估系统复杂度

有助于全面评估版本发布影响面范围；对系统各业务模块进行合理资源分配。

三、技术方案

代码影响面分析的完整方案分为多个关键步骤，通过这些步骤可以实现自动化收集模块级代码影响面分析，并评估版本需求发布对系统整体稳定性的影响。

具体可以参考下面的流程图了解👇：

详细设计

影响面分析引擎

通过结合代码变更、依赖关系、业务逻辑等多维度数据，帮助开发团队快速识别和评估代码修改的潜在影响，从而减少生产问题的发生，提升系统的稳定性和代码质量。

※ 依赖关系图构建

使用静态分析工具分析项目中模块的依赖关系
根据项目类型分别构建依赖关系图
展示变更模块对其他模块的影响路径

※ 代码变更分析

使用版本对比工具分析代码变更
基于DIFF数据，统计变更的函数和变量
根据依赖关系图，初步分析变更的影响范围

※ 影响范围标记

从变更点出发，追踪调用路径，标记所有受影响的节点
将影响范围分为模块、功能、接口和数据四类
解析文件路由信息，输出页面列表

根据简化后的代码，可以快速理解核心功能的实现原理。

class CodeEffectAnalyzer {  private fileImports: { [key: string]: FileImport[] };
    // 收集文件的导入依赖  private collectImports(filePath: string, ast: any): void {    traverse(ast, {      ImportDeclaration: ({ node }) => {        // 记录导入关系        node.specifiers.forEach((specifier) => {          this.fileImports[filePath].push({            filePath: path.resolve(path.dirname(filePath), node.source.value),            importedName: specifier.imported.name,            localName: specifier.local.name,          });        });      },    });  }
    // 分析文件，提取导出变量和函数  private analyzeFile(filePath: string): FileDetails {    const exports: FileExports = {};
    // 遍历 AST，提取导出项    traverse(ast, {      ExportDefaultDeclaration: (path) => {         exports['default'] = generate(path.node).code;      },      ExportNamedDeclaration: (path) => {        const declaration = path.node.declaration;        exports[declaration.id.name] = generate(path.node).code;      },    });        return { exports };  }    // 影响面分析检索  public analyzeImpact(affectedFiles: string[]): AffectedResult {    const analyzeImpactRecursive = (filePath: string): void => {      const { exports } = this.analyzeFile(filePath);      const modifiedList = Object.keys(exports); // 假设所有导出项都被修改      const referencedList: string[] = [];            // 找出引用了修改项的代码      for (const imported of this.fileImports[filePath] || []) {        if (modifiedList.includes(imported.importedName)) {          referencedList.push(imported.localName);          analyzeImpactRecursive(imported.filePath); // 递归分析影响面        }      }    };        // 分析每个受影响文件    for (const file of affectedFiles) {      analyzeImpactRecursive(file);    }  }}