2025QECon全球软件质量效能大会：基于知识驱动的智能测试用例生成探索与实践

王一勃｜58同城本地生活测试平台高级研发58同城高级Java研发工程师

，拥有多年一线研发与质量保障经验

。曾专注于AI代码辅助工具的研发，

深入探究AI技术的实现细节与潜在风险

。目前致力于将AI技术与软件测试深度融合，

主导构建智能测试解决方案，

通过大模型与自动化技术提升测试用例生成效率与缺陷定位精度，

为研发效能的全面提升提供核心支持

。王一勃58同城高级Java研发工程师目录CONTENTS03

高效准确的知识智能自更新01

AI用例生成的背景与挑战02

AI生成测试用例实践04

落地效果与展示05

未来与展望PART

01AI用例生成的背景与挑战测试报告分析

测试用例生成智能体（Agent）单元测试生成UI自动化测试未来... AI时代，

测试领域的新机遇测试数据生成理想需求文档大模型完美的测试用例需求文档大模型“答非所问

”“知识缺失

”“知识过时

”的测试用例

理想与现实：

大模型并非“银弹

”现实

模型缺乏深度的业务上下文理解

，导致对关键约束和边界条件的遗

漏

自然语言的模糊性与多样性

，

导致模型生成无效或错误的参数组

合

业务知识散落于多源异构的文档中

，

模型无法进行关联与整合，导致上下文缺失

隐性知识存在于团队成员的经验中

，

无法被模型利用

，

导致知识复用率极低

理想与现实：

大模型并非“银弹

”

在业务快速迭代的背景下

，

大模

型依赖的训练数据、知识库等往

往存在版本滞后

，

导致其无法获

取最新的业务规则与逻辑

，

生成

的测试用例与当前实际需求脱节

。知识孤岛语义鸿沟迭代僵化 AI用例生成面临的关键挑战2.深度理解如何让模型跨越语义鸿沟

，真正理解业务逻辑和隐含约束3.动态演进如何让智能知识体系与需求同步迭代保持内容不过时1.知识融合如何打破知识孤岛

，让模型具备全局业务视野PART

02AI生成测试用例实践测试用例生成业务可视化地图需求变更影响分析业务知识库UI自动化需求文档历史测试用例

历史执行链路图数据库向量库AI模型底座业务知识库

业务知识图谱数据清洗智能知识更新业务分类

用例生成平台架构设计服务层应用层数据层Rerank重排

关键词匹配语义匹配

双路召回需求获取

向量知识库的构建：

打破知识孤岛将长文档切分为有意

义的

知

识

片

段（Chunk）

，

并通过Embedding模型进行向量化

。这是实现语义搜索的关键

。数据存入向量数据库后

，在检索阶段，通

过

混

合

检

索

和Re

rank

，

提升召回的准确性

。清除无效内容

，

将多来源数据统一为Markdown格式

，便于模型识别和处理智能切块与向量化

向量数据库索引与检索优化多源知识输入

数据处理问题

原因剖析解决思路

构建统一知识接入层：对有API的系统实现自动化Webhook同步；对无API的（如本地文档），提供统一的文档管理中心

。

建立知识溯源与优先级机制

：为所有知识块添加来源元数据。检索根据知识来源（例如：

PRD

>

设计文档

>

历史经验）对召回结果进行动态加权排序

。

向量知识库的构建：

数据处理知识散落在不同用例平台

、文档中心、业务人员

，

缺乏统一的知识源

，

不同来源的文档存在内容冲突或版本不一致的问题在数据预处理阶段，针对不同格式构建数据处理智能体，将其统一解析为格式化的Markdown格式输出，减少模型理解成本

、提升模型识别准确性知识来源包含文本

、图像

、流程图、XMind等

，

大模型直接处理效果差数据格式多样

复杂的知识来源业务分类Agent业务知识库A业务知识库B业务知识库C数据源在知识库的构建和检索阶段，对于输入的需求，通过轻量级的业务分类智能体对需求进行分类，根据分类结果，确定需要操作的数据库，

同时在元数据中对数据打标

。

核心业务分类在知识库的构建阶段，按照核心业务的属性，在向量数据库层面

，为每个核心业务大类（家庭服务

、精选等）创建了不同的知识库，通过将业务分离缩小知识检索范围，提高知识检索准度

。所有业务线的知识都存放在一个知识库里时

，一次检索就像是在整个图书馆里找一本书

，不仅速度慢

，而且极易受到干扰

。搜索“服务时间

”，可能会同时召回保洁阿姨的上门时间和维修师傅的上门时间，造成语义混乱

。

向量知识库的构建：

业务分类

意图识别前置

混合检索通过将向量检索的语义理解能力与关键词检索的精准匹配能力相结合

，充分利用二者优点，相互补充，确保在召回阶段同时覆盖语义相关性和信息关键性

。u向量检索：核心机制为语义相似度匹配

，可以根据检索意图进行同义

、换词等语义检索，但对关键步骤

、专有名词等文档检索效果差，导致核心信息缺失

。u关键词检索：通过检索关键词进行精准匹配，

匹配精准且速度快

。但无法理解语义，对不包含关键词的查询完全失效

。

向量知识库检索优化：

混合检索结果重排可以有效解决混合检索的问题，对候选文档列表进行精细化筛选和重新排序

。Rerank重排序模型对混合检索得到的候选文档列表进行处理

，计算问题与每个候选文档之间的相关性分数

，并按照分数对文档列表进行重新排序

。最后输出一个按照相关性降序排列的文档列表，保证最相关的文档排在最前面

。混合检索模式下

，不同检索模式检索到的文档片段质量不一

，存在大量相关但是并非最关键的文档片段

。直接把这些相关性与精度不足的知识交给大模型处理

，会大大降低最终结果的准确性

。

向量知识库检索优化：

结果重排

结果重排文档清洗与结构化处理（语义消歧

、指代消解

、冗余段落检测）需求语义分析与关键词提取向量检索结果上下文信息融合与增强查询历史需求和测试用例预构建历史需求和用例

向量知识库动态提示词优化与生成用例生成AgentAI智能测试用例需求文档导入及预处理（支持多种格式）向量检索召回排序开始

加入向量知识库后的业务流程业务逻辑碎片化l

向

量

检

索

只

能

找

"

相

似内

容

"，

无

法

理

解

"

登

录

→

支

付

"

等

步

骤

的强制顺序

，

容易生成逻辑错

误的用例l

业务规则隐藏在文本中

，

大模

型难以提取

"

VIP用户专属功能

"

等

约

束

条

件

，导

致

用

例

覆

盖

不准确上下文信息断裂l

向

量

库中

文

档

是

割

裂的，"

用

户权限

"

和

"

订单流程

"

的关联关

系丢失

，

无法生成全链路测试

用例l

隐含规则难以捕捉

，

大模型无

法

推断"

修改

密

码

后

需

重

新

登

录

"

等跨模块的业务逻辑影响面分析能力缺失l

需求变更时难以定位影响范围，向量检索无法准确回答

"

改了A

功

能

会

影响哪

些

用

例"

，导

致

盲目全量回归l

缺少版本追溯能力

，

无法快速

识

别"

新

增

功能需

要

哪

些

前

置

条

件"

，容

易

遗

漏

关

键

测

试

场

景

为什么还需要知识图谱？——跨越语义鸿沟010203

知识图谱建设数据来源数据清洗语义理解功能点步骤查询业务可视化地图变更分析UI自动化实体识别属性抽取跨文档指代消解多跳关系推理图语句转换实体建模图数据库MCP图谱生成智能化应用

图谱工程化需求文档动态UI树捕获历史测试用例历史业务链路语义分块文本去噪内容补全结构归一化

知识图谱的建设知识库+知识图谱双轮驱动获取相关文档片段获取业务逻辑路径业务需求

文档清洗处理业务知识图谱业务知识库关键词提取RAG增强相关的文档片段

相关的业务逻辑路径上下文信息融合与增强查询

动态提示词优化与生成用例生成AgentAI智能测试用例开始需求文档导入及预处理（支持多种格式）文档清洗与结构化处理（语义消歧

、指代消解

、冗余段落检测）业务知识图谱（历史执行路径和功能点）向量检索

业务查询历史需求和用例向量知识库需求语义分析与关键词提取

完整的用例生成流程PART

03高效准确的知识智能自更新02

手动更新缺乏自动化更新机制

，要求团队成员投入大量精力

，去手动追踪

、解读散落各处的变更文档

，并将其转化为知识库能理解的格式

。03敏捷性难题依赖人工

、更新速度慢的知识系统

，其响应速度无法匹配业务的演进速度

，敏捷程度低

、影响整体功能迭代

。

新的挑战：

知识的“保鲜期

”知识的价值在于其时效性

。一旦知识库与业务实际情况脱节，AI便会基于过时的业务规则

、已废弃的功能点或陈旧的API定义来生成测试用例01

知识的时效性

知识智能自更新

统一入口

，智能分发•内部文档平台配置Webhook作为统一事件入口。•当文档发生新建

、内容更新或下线归档时，触发Dify工作流。•工作流根据事件类型，

自动分发至不同的处理链路。

全量处理，双库同步•所有处理过的数据，都会经过清洗

、格式化

、知识抽取（实体

、关系）等步骤。•最终结果会同步更新至知识库

(向量库)

和

知识图谱，确保两边数据的一致性。解决思路

先删后增的原子化更新机制：

不进行复杂的增量比对

，当收到更新通知

，系统会根据文档ID

，先将该文档关联的所有旧数据（向量块

、图谱关系）

全部删除

，然后将修改后的新文档作为一个全新的文档走一遍入库流程。

逻辑删除而非物理删除

：将数据标记为废弃状态

，而不是直接物理删除，

既能让用户在应用层检索不到过期知识，又完整保留了数据链路，便于未来审计或恢复。•内容修改难题：

用户只是修改了文档中的一句话

，我们是应该替换整个文档

，还是只更新变化的部分？如何确保知识库和知识图谱的数据版本能跟上？。•文档下线的问题：

一份文档被删除了

，如果直接在数据库里物理删除

，可能会导致依赖它的知识关系链断裂

，历史无法追溯。

难点攻坚：

过期知识的清理更新对象状态为废弃确定影响对象功能下线知识图谱知识库清理机制

检索检索解决方案：

基于Agent的关联构建对新文档进行数据清洗和关键词提取，在知识库中检索关联的历史文档片段汇总为新知识，对新知识按照实体和关系定义抽取三元组后，通过新知识中的核心实体

，去知识图谱里查询已有的相关实体

。将信息统一交给知识融合Agent进行分析生成关联性质的新关系，并提交给专家审核

，专家审核无误后进行数据入库操作

。

难点攻坚：

新增知识的增量融合数据入库新实体关系三元组专家审核新文档知识融合Agent关联的历史文档片段知识库

一个自我进化的知识闭环业务发展事件触发增量更新知识完善知识校准PART

04落地效果与展示AI用例召回率召回率衡量的是AI生成用例的覆盖能力，评估AI生成的用例集能够覆盖多少本该被测试的

、真实存在的功能点。AI需求覆盖率覆盖率衡量的是AI生成用例的全面性和完整性，评估AI生成的用例集在所有可能的测试场景中

，究竟覆盖了多大的范围。Q120.2%AI用例召回率Q132.7%AI需求覆盖率Q266.1%AI需求覆盖率Q262.8%AI用例召回率

落地效果-用例生成提效落地效果-业务提效用例生成效率提升衡量生成同等规模或同等覆盖度

的测试用例，AI所需时间与人工

所需时间的比例。人力成本节约率衡量在特定周期内（如一个项目

、

一个季度或一年），

因引入AI而

节省的人力工时及其对应的成本。人工生成2-3小时AI生成5-10分钟Q132.2%Q270.3%PART

05未来与展望测试智能体与自主测试将

测

试

用

例

和UI自

动

化

测

试

有

机结合起来

，

生成的测试用例可以直

接

作

为

UI自

动

化

的

输

入

，智

能体将能够自主理解这个意图

，

调用API、操作UI界面去执行测试，分析返回结果。多模态知识融合当

前

的

知

识

源