学习笔记：知识图谱是什么，在测试里能干什么

哈喽，大家好～

这阵子我在折腾「用 AI 辅助测试」：把测试知识库切成片段喂给 AI，帮着生成测试用例；又通过 MCP 协议连上 bug 管理系统，让 AI 自动拉缺陷数据做分析。

但折腾的过程里，我反复撞到同一堵墙：用例、接口、脚本、bug 这些东西之间是怎么关联的，全靠人脑记。

做接口自动化的同学肯定熟：开发说「orderStatus 这个字段的类型要改」。然后呢？哪些接口在用它、哪些用例覆盖了它、哪些脚本的断言会挂------这些问题没有现成答案，只能翻记录、问同事、靠回忆。漏了一条，漏测就跟上了。

那么，能不能把这些散落在各个工具里的关系，变成一张能查的图？

这就是我最近学知识图谱（Knowledge Graph）的动机。这篇是学习记录：先弄懂它是什么，再看它在测试里能干什么。

一、知识图谱是什么：从三元组说起

知识图谱听起来玄乎，其实它存知识的最小单位特别简单，叫三元组 ：头实体 ---关系→ 尾实体。说白了就是一句「主谓宾」：

注意「麻辣火锅」在第一条里是结尾，在第二条里又成了开头。同一个实体被反复使用，知识就自己「缝」了起来。把成千上万条三元组接在一起，就得到一张网------节点是事物，连线是事物之间的关系，这就是知识图谱。

它和普通表格的差别也很直观：表格里只存一条条记录，谁跟谁有关系，得自己跨表翻；图谱把「谁和谁有什么关系」直接写在连线上，顺着线看就行。

把视角拉回测试。用例、接口、脚本、缺陷这些东西之间，本来就有实实在在的关系：用例覆盖需求、用例调用接口、接口包含字段、脚本实现用例、用例暴露缺陷。把这些画出来，就是一张测试知识图谱：

重点是图里那条虚线：「字段 → 用例」的影响关系，没有任何人手工登记过，它是顺着「字段 → 接口 → 用例 → 脚本」这条路径推导出来的。这正是图谱相对「把用例写成表格」的关键增量------它能把已有的关系串成一条你原来看不见的结论。

这些节点的数据来源，基本都是现成的：

回到开头那个场景。有了图谱，「orderStatus 类型要改」就不再是靠回忆的题，而是一次图查询。影响面像涟漪一样扩散：

一个字段被 3 个接口引用，这 3 个接口一共被 12 条用例覆盖，这 12 条用例又对应着 4 个自动化脚本------顺着线走一遍，回归清单就出来了。数字是举例，实际有多少取决于你的图，但查法完全一样。

最妙的是，起步根本不需要图数据库。一张三列的表就够了：

复制代码

头实体,关系,尾实体
orderStatus,属于,下单接口
orderStatus,属于,查询接口
orderStatus,属于,退款接口
下单接口,被调用,下单正常用例
下单接口,被调用,下单参数校验用例

「找受影响的用例」就是两次查询：先查所有「尾实体 = orderStatus」的行拿到接口，再拿这些接口当头实体查下一跳。用 Excel 筛选、或者 SQLite 里一条 SQL 都能跑。等关系规模上去了，再考虑 Neo4j 这类图数据库也不迟。

三步走：

计划先到这。等真的跑起来，踩到坑再来记录一篇。