基于知识图谱的智能测试用例生成实践

当AI开始生成测试用例，为什么依然会漏测？

近年来，大模型技术快速发展，越来越多的测试团队开始尝试利用 AI 辅助测试设计。只需将需求文档、产品原型或接口文档上传给大模型，几秒钟内便可以生成数十甚至上百条测试用例。从效率角度来看，这无疑是一次巨大的提升。然而，在实际项目落地过程中，很多测试团队发现了新的问题：

• 同样的需求，多次生成的测试用例结果差异较大；
• 对复杂业务规则的理解不够深入；
• 跨模块、跨流程场景覆盖不足；
• 生成的测试用例看起来很多，但真正有效的测试点并不全面；
• 对需求变更缺乏持续追踪和关联分析能力。

究其原因，大多数AI生成测试用例方案本质上仍然属于：“文档 → 大模型 → 测试用例”模式。在这种模式下，大模型更多是在根据文档内容进行语义理解和经验推断。对于简单需求，这种方式已经能够取得不错的效果，但对于企业级业务系统而言，需求往往分散在多个来源之中：

• 产品需求文档
• 原型设计图
• 接口文档
• 数据库设计文档
• 流程图
• 业务规则说明
• 历史需求变更记录

这些信息共同构成了完整的业务知识体系。如果仅依赖大模型直接理解文档，往往难以建立完整的业务关联关系，也难以发现隐藏在流程、规则和状态流转中的测试场景。因此，越来越多的企业开始探索新一代测试设计模式：“需求文档 → 业务知识图谱 → 测试场景推理 → 测试用例生成”。

与直接生成测试用例相比，知识图谱首先完成的是对需求的结构化理解。系统会自动识别需求中的：业务实体、业务关系、流程节点、状态流转、业务规则、约束条件等信息，并构建完整的业务知识网络。在此基础上，通过规则推理和关联分析生成测试场景，再进一步生成测试用例。这种方式不仅关注“需求中写了什么”，更关注“业务之间存在什么关联”和“规则之间会产生什么影响”。因此能够发现更多传统方法容易遗漏的：状态流转场景、异常流程场景、权限控制场景、多条件组合场景、跨模块联动场景。

那么，对于一个真实业务系统，例如企业微信打卡功能，AI究竟是如何从需求文档一步步构建业务知识图谱，并最终生成高质量测试用例的呢？下面我们通过一个实际案例来进行分析。

知识图谱是如何构建的

以企业微信的「打卡规则配置」功能为例。管理员可以配置：打卡人员、打卡时间、打卡地点、WIFI打卡、考勤机打卡、外出打卡、拍照打卡、补卡申请、人脸识别等信息。从表面上看，这是一个配置页面，但对于测试设计来说，真正重要的并不是页面长什么样，而是隐藏在页面背后的业务知识。当AI接收到需求文档后，第一步并不是生成测试用例，而是完成需求知识解析。

1、 识别业务实体

首先，系统会识别需求中出现的核心业务对象，例如在打卡规则配置场景中：管理员、打卡规则、员工、打卡地点、WIFI、考勤机、打卡记录 、补卡申请、审批单、人脸识别、照片等，这些对象构成了业务系统中的核心实体。

2、 识别实体关系

仅有实体还不够，测试场景往往来自实体之间的交互关系，当这些关系建立后，系统已经能够初步理解业务流程。仍然以企业微信的打卡管理为例，系统识别出实体之间的业务关系：

3、识别业务属性

接下来，系统会提取每个实体的关键属性。例如：打卡规则包含

• 规则名称
• 打卡方式
• 允许迟到分钟数
• 允许早退分钟数
• 打卡时间段
• 打卡地点范围
• 是否开启拍照打卡
• 是否开启补卡申请
• 是否开启人脸识别

这些属性是后续边界值测试的重要来源。例如设置允许迟到10分钟，就天然包含：9分钟、10分钟、11分钟三个关键测试点。

4、识别业务规则

对于测试设计而言，最有价值的信息往往来自业务规则，例如需求文档中描述：

• 开启拍照打卡后必须上传照片
• 开启补卡申请后允许提交补卡
• 补卡申请必须经过审批
• 允许迟到10分钟
• 允许早退5分钟

系统会自动将这些规则结构化存储。如允许迟到10分钟：

Rule001

条件：

迟到时间 ≤ 10分钟

结果：

不记录迟到

5、识别状态流转

除了规则之外，状态变化也是测试设计的重要来源。例如补卡申请：待提交、待审批、审批通过、已补卡、审批拒绝，系统会自动识别这些状态机模型。每一次状态变化都可能对应测试场景。 例如：审批后修改、审批中撤回、已完成状态再次审批等，这些都是将来用于生成测试用例的依据。

当实体、关系、属性、规则以及状态流转全部抽取完成后，需求文档就不再是一堆零散的文字，而是被转换成一张完整的业务知识图谱。至此，AI真正完成了对需求的理解。

从知识图谱到测试用例

当需求文档被解析为知识图谱后，系统实际上已经完成了对业务的结构化理解。以企业微信的打卡规则配置为例，此时系统已经构建出了类似下面的业务知识网络：

系统需要进一步进行测试场景推理。可以从业务规则推理测试场景，也可以从业务属性推导边界场景或者从状态流转推理测试场景。我们来看一个从业务规则推导测试场景示例。 例如需求红存在一条规则：开启拍照打卡后，员工打卡必须上传照片，针对这个需求，在知识图谱中会有这样一条链路：打卡规则（开启）——拍照打卡（约束）——上传照片，系统自动识别：存在必填约束、存在上传行为、存在成功和失败两种结果，于是生成测试场景：

• 上传照片打卡
• 未上传照片打卡
• 上传损坏图片
• 上传超大图片
• 拍照权限关闭
• 拍照过程中断

从被测系统到知识图谱

除了分析文档生成知识图谱的模式外，针对缺少文档的企业，测吧知识图谱生成引擎，还提供了从被测系统生成知识图谱，一键式构建产品业务模型及知识图谱

爱测平台基于知识图谱的用例生成

测吧自研爱测智能化测试平台，已集成文档——知识图谱——测试用例相关智能体，企业只需上传相关的业务文档，即可以基于业务文档生成知识图谱，进一步生成高覆盖率的测试用例，欢迎大家预约体验。