智能测试用例生成系统

项目简介

本项目是一个智能测试用例生成系统。 系统支持根据需求描述自动生成结构化测试用例，并结合知识库、生成历史、样本治理与业务语义归类能力，形成“生成—沉淀—治理—复用”的闭环。

当前版本已经不只是简单的测试用例生成工具，而是一套包含生成、沉淀、治理、复用、归类与后台运维能力的完整系统。

当前版本核心能力

1. 自动生成测试用例

2. 需求输入增强

3. 知识库参考增强

4. 知识库治理能力

5. 后台管理能力

当前页面结构

系统页面由 web/app_shell.py 统一管理与路由，当前核心页面包括：

自动生成测试用例工作流

1. 用户输入需求

在 generate_cases.py 页面中，当前支持输入：

页面函数：

show_generate_page()

2. 系统推荐生成数量

系统根据需求内容自动评估复杂度，并给出推荐保底数量与推荐最高数量。

调用方法：

CaseGeneratorService.explain_case_count_recommendation(...)

所在文件：

services/case_generator.py

系统会结合以下信息进行评估：

输出内容包括：

3. 生成前参考知识库历史样本

在正式生成前，系统会从知识库中检索与当前需求最相关的历史测试用例。

调用方法：

KnowledgeService.get_relevant_reference_cases(...)

底层检索由 services/reference_retrieval_service.py 实现，核心是关键词权重倒排检索（TF-IDF），不是向量语义召回。完整链路：

  1. 需求清洗去噪：过滤掉「业务场景/前置条件/验收要点」的模板段，避免噪声词进入检索。
  2. 拆意图：整段需求放第一位，再切成若干子意图，每个子意图继承全局业务域/系统。
  3. 算关键词：jieba分词+词性标注，每个词按 tf × idf × 词性权 × 长度权 打分，得到关键词/业务对象/业务动作。
  4. 倒排索引召回候选：先按 IDF 留下有区分度的词，再去 case_term_index 按词权重 SUM(weight) 聚合排序，跨整库贪婪拿候选。
  5. 精排打分定相关强度：对候选逐条算分（业务域/系统匹配、业务对象/动作重合、标题/模块文本命中、核心高频词命中、新鲜度等），映射成 strong / medium / weak / none。泛词（查询/展示/用户等）不算语义命中，跨域严重直接判none。
  6. 多阶段补齐：主范围不足时扩量；绑定业务域/系统时若同系统内不够，放宽到跨系统补齐（跨系统只收 strong 强命中，绑定系统仍排前面）；最后才做模块相似兜底，绝不靠泛词硬凑。
  7. 去重+多样化+缓存：按签名去重、同模块弱相关防刷屏，结果进10分钟内存缓存。

页面展示：

4. 进入生成主流程

用户点击生成按钮后，系统会：

生成流程支持页面调整批次大小。

5. 批量生成测试用例

系统会将目标数量按批次拆分，并逐批生成。

核心逻辑位于：

services/case_generator.py

每一批会设定不同的生成焦点，例如：

这样可以让最终结果覆盖更多测试维度，而不是只集中在常规流程。

6. Agent 调用 AI 生成单批结果

每一批生成由 TestCaseAgent 负责。

所在文件：

agents/test_case_agent.py

核心流程包括：

  1. 获取参考上下文
  2. 构建Prompt
  3. 调用大模型接口
  4. 清洗并解析返回结果
  5. 标准化字段格式

7. 生成结果处理

生成完成后，当前支持：

每批生成结果还会先保存到生成历史表，便于：

知识库存储结构与检索逻辑

知识库不是一张表，是「主表+倒排索引+语料统计+词库」四层结构。一条用例进来后，会被拆成多种可检索形态分别存放。

层 表 作用
主表（原始用例） test_case_knowledge_base 存完整用例：名称/模块/步骤/预期/业务归类字段
关系表 test_case_knowledge_relations 用例↔业务域/系统的多对多关系，名称兜底用
倒排索引 case_term_index 把每条用例拆成「词→case_id→权重」，检索主力
语料统计 corpus_term_stats / corpus_meta 全库 IDF（词区分度），判断哪些词值钱
提取词库 extraction_vocab / extraction_alias 业务域/系统/对象/动作的规范词+别名，做归类与同义词归一

核心思想：主表负责“存”，倒排索引负责“找”，语料统计负责“判断词值不值钱”，词库负责“把同义说法归一”。

词是怎么被拆出来的

一条需求的检索链路（端到端）

需求文本
  └─ 清洗去噪（去markdown/套话标签）
      └─ 拆意图（整段+子意图，继承业务域/系统）
          └─ 每意图算关键词（jieba+语料IDF+词性权）
              └─ 倒排索引贪婪召回 case_id（按 SUM(weight)，IDF 选词）
                  └─ Python 精排打分 → strength(strong/medium/weak/none)
                      └─ 多阶段补齐（主范围 → 扩量 → 跨系统 strong → 模块兜底）
                          └─ 去重/多样化/排序 → 返回 N 条参考用例 → 注入生成上下文

把用例切成带权重的关键词建索引，需求来了也拆成关键词，按权重匹配找最相关的用例，核心是关键词权重倒排检索，不是整段切片做语义向量。

用例导入工作流

知识库治理页支持按模板 Excel 批量导入用例。

服务方法：

KnowledgeService.build_import_template()      # 生成可下载的导入模板 Excel
KnowledgeService.import_cases_from_excel(...)  # 从模板 Excel 导入用例

1. 下载导入模板

导入页提供可下载的模板 Excel（表头 + 一行示例），列与导入逻辑严格对齐：

用例名称 / 所属模块 / 前置条件 / 测试步骤 / 预期结果 / 用例等级 / 维护人(工号)

2. 导入与校验

3. 导入后自动提取关键词 + 自动建索引

导入保存后，系统会自动完成两件事，无需手动跑重建：

  1. 增量倒排索引：新用例立即被拆成词粒度倒排索引（_index_saved_cases），使其马上可被快速参考检索命中。
  2. 后台重建语料 IDF：导入会带来新词，新词拿不到真实 IDF 会影响权重。系统在后台重建全库语料 IDF，再用新 IDF 重新索引这批新用例，让权重跟上最新语料。

关键设计：

知识库治理工作流

系统提供独立的知识库治理页面，用于持续优化样本质量。

页面文件：

web/pages/knowledge_governance.py

服务文件：

services/knowledge_governance_service.py
services/knowledge_taxonomy_service.py

当前知识库治理页主要包括 3 个部分：

1. 样本治理

当前样本治理能力包括：

2. 单条 AI 修正

当前单条 AI 修正支持三种动作：

也就是既支持：

也支持：

3. 重复检测

当前重复检测能力包括：

4. 业务语义归类

当前业务语义归类能力包括：

当前说明逻辑为：

治理底层逻辑（怎么做到又快又不漏）

库治理不是人工一条条改，是一套自动化流程，围绕四件事。

1. 质量打分

服务方法：KnowledgeGovernanceService.score_case(...)

每条用例按一套规则打分，检查：

分数映射成 高 / 中 / 低 三档，并列出具体问题（如“步骤与预期条数不一致”“缺少业务域”）。先知道哪些用例有问题、问题在哪。

2. 业务语义归类回填

服务方法：KnowledgeTaxonomyService.batch_backfill_taxonomy(...)

很多历史用例只有标题和步骤，没有业务对象/动作/场景这些结构化标签。治理时批量扫出这些缺字段的用例，用规则（命中不了再用 AI 兜底）推断出业务对象、业务动作、场景类型、关键词，批量写回。

实现要点：纯 SQL 批量读 + CASE WHEN 批量写，不逐条 ORM，快 10 倍以上。

3. 业务域/系统自动绑定

服务方法：KnowledgeTaxonomyService.batch_bind_unbound_history(...)

历史数据很多没绑业务域（domain_id）和系统（system_id）。治理时先拉出所有已配置的业务域/系统映射表，再用 名称 + 别名 规则区分每条用例该归到哪个域/哪个系统，匹配不到的交给 AI 兜底，然后把 domain_id/system_id 写回。

原则：系统确实匹配不到时保持空值。

4. 查重 + 清洗

服务方法：KnowledgeGovernanceService.detect_duplicates(...)

给每条用例算一个签名（signature），识别重复/高度相似用例，清理冗余；同时规范化字段（优先级归一、文本清洗）。

为什么能跨全库跑得动

一句话：治理 = 自动给每条用例做质量体检打分、补全缺失的业务标签、自动绑定业务域和系统、查重清洗；全量数据用游标分批增量跑，规则优先、AI 兜底。

生成历史页当前能力

生成历史页当前支持：

另外，当前版本已对生成历史页增加页内轻量缓存，减少带来的重复查库卡顿。

日志中心与文件管理

日志中心

当前支持：

文件管理

当前支持：

用户管理

当前用户管理页已支持：

项目主要目录

/root/testcase
├── main.py
├── app_runtime.py
├── agents/
│   └── test_case_agent.py
├── services/
│   ├── case_generator.py
│   ├── knowledge_service.py
│   ├── knowledge_governance_service.py
│   ├── knowledge_taxonomy_service.py
│   ├── reference_retrieval_service.py
│   ├── corpus_keyword_extractor.py
│   ├── business_domain_service.py
│   ├── history_service.py
│   ├── log_service.py
│   ├── file_management_service.py
│   └── ...
├── web/
│   ├── app_shell.py
│   └── pages/
│       ├── generate_cases.py
│       └── knowledge_governance.py
├── database/
│   ├── connection.py
│   ├── models.py
│   └── repository.py
├── config/
│   └── settings.py
├── generated_cases/
├── logs/
└── cache/

运行入口

系统入口文件为：

testcase/main.py

主流程为：

常见启动方式：

cd testcase
streamlit run main.py

也可根据需要指定端口或监听地址。

总结

当前版本的项目已经形成完整闭环：

生成 → 沉淀 → 治理 → 再生成

它不再只是简单地把需求丢给模型生成，而是通过以下机制持续提升效果：

这也是当前系统持续提升生成质量和业务贴合度的核心机制。