一、项目背景
1.1 问题痛点
在软件测试领域，测试用例的编写是一项耗时且繁琐的工作。传统的测试用例编写方式存在以下问题：

依赖人工经验：测试用例的质量高度依赖测试工程师的业务理解能力和经验水平
编写效率低下：针对一个功能模块，往往需要花费数小时甚至数天时间编写测试用例
覆盖不全面：容易遗漏边界条件、异常场景等重要测试点
文档同步困难：需求文档变更后，测试用例需要同步更新，容易产生不一致

1.2 解决方案
随着大语言模型（LLM）技术的快速发展，我们可以利用 AI 技术来辅助测试用例的编写。然而，仅仅依靠大语言模型和业务需求文档是不够的，因为：

大语言模型缺乏领域专业知识：通用大模型对特定业务领域的测试规则、边界条件、异常场景等了解有限
测试经验难以传承：资深测试工程师的经验和技巧往往难以系统化地传授给新人
测试质量参差不齐：不同测试工程师编写的测试用例质量差异较大，缺乏统一的标准

为了解决这些问题，本项目创新性地引入了测试技能库（Skill）作为核心组件，结合以下三大技术，实现了从需求文档自动生成高质量测试用例的功能：

RAG（检索增强生成）技术：通过向量数据库检索相关的业务需求文档
测试技能库（Skill）：构建领域特定的测试方法论和最佳实践库，这是本项目的核心创新
大语言模型：基于需求上下文和测试技能，生成高质量的测试用例

测试技能库的核心价值
测试技能库是连接业务需求和高质量测试用例的桥梁，它的重要性体现在：

经验沉淀：将资深测试工程师多年积累的测试经验、方法论、最佳实践系统化地沉淀下来，形成可复用的知识资产
质量保障：确保生成的测试用例遵循统一的测试标准，覆盖关键的测试场景（正向流程、边界条件、异常处理、安全验证等）
效率提升：新人可以通过技能库快速上手，无需从头学习所有测试规则
持续演进：技能库可以随着业务发展和测试经验的积累不断更新和完善
领域适配：针对不同的业务领域（如优惠券、营销活动、支付安全等），可以构建专门的测试技能库

通过测试技能库，我们实现了"业务需求 + 测试技能 = 高质量测试用例"的完整闭环，这是本项目区别于其他普通测试用例生成工具的核心竞争力。
二、实现思路
2.1 整体架构
工具采用模块化设计，主要包含以下核心模块：

文档处理模块：负责多格式文档的解析和文本提取
向量数据库模块：负责文档的向量化存储和相似度检索
测试技能库（Skill）：存储领域特定的测试方法论和最佳实践
测试用例生成模块：结合业务需求和测试技能，生成高质量测试用例
UI 交互模块：提供友好的 Web 界面供用户操作

2.2 核心技术栈

后端框架：FastAPI + Uvicorn
前端框架：Gradio
向量数据库：ChromaDB
文档处理：pdfplumber、python-docx、pandas、BeautifulSoup4
大语言模型：支持模型切换（百炼/自定义），内置百炼（DashScope）通义千问系列模型
编程语言：Python 3.8+

2.3 工作流程
markdown 体验 AI 代码助手 代码解读复制代码工具启动，加载测试技能库（Skill）
↓
用户上传需求文档
↓
文档格式转换（提取纯文本）
↓
文档向量化（业务需求 + 测试技能）
↓
用户输入测试需求
↓
向量相似度检索（同时检索业务需求和相关测试技能）
↓
智能融合（业务需求优先，测试技能补充）
↓
大语言模型生成高质量测试用例
↓
结果展示（Markdown/表格视图）

关键环节说明：

技能库预加载：工具启动时自动加载所有测试技能文件到向量数据库
双重检索：生成测试用例时，同时检索业务需求文档和相关的测试技能
智能融合：优先使用业务需求作为测试依据，使用测试技能补充边界、异常、安全、兼容性等场景
质量保障：通过测试技能库确保生成的测试用例遵循最佳测试实践

三、过程解析
3.1 向量数据库管理：单例模式实现
为了确保向量数据库的全局唯一性和线程安全，我们采用了单例模式来管理向量数据库实例。
python 体验 AI 代码助手 代码解读复制代码 # rag_skills_testcase/core/vector_store.py
class VectorDBManager:
"""向量数据库管理器，使用单例模式"""

_instance = None
_lock = threading.Lock()

def new(cls, config, embedding_model):
with cls.lock:
if cls._instance is None:
cls._instance = super(VectorDBManager, cls).new_(cls)
cls._instance._initialize(config, embedding_model)
elif cls._instance.config != config or cls._instance.embedding_model != embedding_model:
# 如果配置或嵌入模型发生变化，重新初始化
cls._instance._initialize(config, embedding_model)
return cls._instance

def get_or_init(self, force_rebuild: bool = False):
with self._instance_lock:
if self._loading:
logger.info(" VectorDB is still loading...")
return None
if not force_rebuild and self._db is not None:
return self._db
try:
self._loading = True
self._db = init_vector_db_internal(self.config, self.embedding_model, force_rebuild)
self._initialized = True
return self._db
finally:
self._loading = False

设计要点：

使用双重检查锁定（Double-Checked Locking）确保线程安全
支持配置和嵌入模型变更时的重新初始化
添加了加载状态检查，防止重复加载

3.2 测试技能库（Skill）：沉淀测试专家经验
测试技能库是本工具的核心创新之一，它将测试专家的经验沉淀为可复用的知识，确保生成的测试用例既符合业务需求，又遵循最佳测试实践。
3.2.1 技能库结构
测试技能库采用分层设计，包含以下三个主要分类：
bash 体验 AI 代码助手 代码解读复制代码 test_skills/
├── general/ # 通用测试技能
│ ├── boundary_value_examples.md # 边界值与异常输入测试技能
│ └── error_code_validation_guide.md # 错误码与异常处理测试技能
├── domain_specific/ # 领域特定测试技能
│ ├── coupon_test_skills.md # 优惠券功能测试技能
│ ├── login_test_scenarios.md # 登录功能测试技能
│ ├── marketing_activity_test_skills.md # 营销活动通用测试技能
│ ├── payment_security_checklist.md # 支付安全测试技能
│ └── marketing_activities/ # 营销活动子目录
│ ├── full_discount_activity.md # 满减满折活动测试技能
│ ├── order_discount_activity.md # 联单折扣活动测试技能
│ └── ... # 其他活动测试技能
└── platform/ # 平台相关测试技能
└── mini_program_compatibility.md # 小程序兼容性测试技能

3.2.2 技能文件内容结构
每个技能文件都遵循统一的格式，包含以下内容：

标题：技能名称
基本规则：领域特定的业务规则和约束条件
测试要点：详细的测试点和要求
测试用例示例：具体的测试步骤和预期结果

以优惠券功能测试技能为例：
markdown 体验 AI 代码助手 代码解读复制代码 # 优惠券功能测试技能

0. 优惠券基本规则

核心规则

• 优惠券按照类型分红包券、优惠券
• 优惠券业务逻辑：创建券->发放券->用户手动领取/自动发放->用户使用
• 未支付退券逻辑：用户用券下单提交订单未支付，用户取消，优惠券原路返回到用户优惠券列表
• ...

1. 创建券功能测试

创建规则

• 券类型选择：红包券、优惠券
• 券名称：最长 10 个字
• 有效期：结束时间必须大于开始时间，大于系统当前时间
• ...

测试要点

• 验证券名称长度限制
• 验证有效期逻辑
• 验证优惠类型选择
• ...

3.2.3 技能库与业务需求的协同工作
测试技能库与业务需求文档协同工作的方式：

加载技能库：工具启动时自动加载所有技能文件到向量数据库，标记 `type: "skill"

加载业务需求：用户上传的业务需求文档标记 `type: "business"

联合检索：生成测试用例时，同时检索业务需求和相关测试技能

智能融合：

优先使用业务需求作为测试依据
使用测试技能补充边界、异常、安全、兼容性等场景
严禁将测试技能中未在业务需求提及的功能当作需求生成用例

3.2.4 设计要点

分层设计：通用技能、领域特定技能、平台相关技能三层结构清晰
可扩展性：易于添加新的测试技能文件
版本管理：支持技能库的持续更新和完善
metadata 标记：通过 type 字段区分业务需求和测试技能
权重控制：业务需求优先，测试技能补充，避免编造需求

3.2.5 技能库的实际应用效果
测试技能库在实际应用中展现出显著的价值，具体体现在以下几个方面：

1. 测试用例质量显著提升

边界条件覆盖更全面：通过通用技能中的边界值测试方法，自动生成边界值、异常值等测试用例
异常场景考虑更周全：基于测试技能中的异常处理测试要点，确保覆盖各种异常情况
测试场景更系统化：遵循技能库中的测试方法论，生成的测试用例逻辑更清晰、结构更完整

1. 测试用例生成效率大幅提高

减少重复劳动：新人无需从头学习所有测试规则，可以直接复用技能库中的经验
缩短学习曲线：通过技能库，新人可以快速了解特定领域的测试要点
提高一致性：不同测试工程师生成的测试用例风格统一、标准一致

1. 领域知识的持续积累

经验传承：资深测试工程师的经验可以通过技能库传承给团队成员
知识沉淀：随着项目发展，技能库会不断丰富和完善
最佳实践固化：将经过验证的测试方法和技巧固化到技能库中

3.2.6 使用 Skill 的好处
使用测试技能库后，可以带来以下显著好处：

1. 测试用例质量显著提升

系统覆盖正向流程、边界条件、异常场景、安全验证等关键测试点
确保测试用例遵循统一的测试标准和最佳实践
测试用例质量稳定，不依赖个人能力

1. 测试经验系统化沉淀

将资深测试工程师的经验、方法论、最佳实践系统化地沉淀下来
形成可复用的知识资产，实现测试经验的传承
技能库可以随着业务发展和测试经验的积累不断更新和完善

1. 大幅提高测试效率

减少重复劳动，相同的测试规则无需反复考虑
新人可以通过技能库快速上手，无需从头学习所有测试规则
不同测试工程师生成的测试用例风格统一、标准一致
可以规模化应用，提高整体测试效率

1. 领域知识持续积累

针对不同的业务领域（如优惠券、营销活动、支付安全等），可以构建专门的测试技能库
随着项目发展，技能库会不断丰富和完善
将经过验证的测试方法和技巧固化到技能库中

3.2.7 与传统测试方法的对比

维度传统测试方法基于技能库的智能测试方法经验依赖高度依赖测试工程师个人经验经验沉淀为可复用的技能库测试质量质量参差不齐，依赖个人能力质量稳定，遵循统一标准覆盖全面性容易遗漏边界和异常场景系统覆盖正向、边界、异常等场景新人上手需要长时间学习和积累通过技能库快速上手知识传承依赖言传身教，容易流失系统化沉淀，持续积累效率重复劳动多，效率低自动化生成，效率高
3.2.8 技能库的建设方法论
建设高质量的测试技能库需要遵循一定的方法论：

1. 分层建设策略

先通用后特定：先建设通用测试技能，再逐步扩展到特定领域
从简单到复杂：从基础的测试要点开始，逐步完善和深化
迭代优化：根据实际使用效果持续优化和完善技能库

1. 技能文件编写规范

结构清晰：每个技能文件遵循统一的结构（基本规则、测试要点、测试用例示例）
内容实用：技能内容要贴近实际测试工作，具有可操作性
示例丰富：提供具体的测试用例示例，便于理解和参考

1. 持续维护和更新

定期评审：定期评审技能库内容，确保时效性和准确性
用户反馈：收集用户反馈，持续改进技能库
版本管理：记录技能库的变更历史，支持版本回滚

1. 团队协作建设

共建共享：鼓励团队成员共同参与技能库建设
知识分享：定期组织技能库分享和学习活动
激励机制：建立激励机制，鼓励贡献高质量的测试技能

通过以上方法论，可以建设一个高质量、可持续发展的测试技能库，为测试用例生成提供强大的支撑。
3.4 RAG 检索：相似度搜索与文档过滤
在生成测试用例之前，我们需要从向量数据库中检索与用户查询相关的文档片段，为大语言模型提供上下文。
python 体验 AI 代码助手 代码解读复制代码 # rag_skills_testcase/core/test_case_generator.py
def generate_cases_with_context(config: dict, vector_db, query: str, min_case_count: int = 10, max_case_count: int = 20) -> Tuple[str, str]:
# 相似度搜索
docs = vector_db.similarity_search(query, k=10)

# 去重处理
seen_sources = set()
unique_docs = []
for doc in docs:
src = doc.metadata.get("source", "")
if src:
if src in seen_sources: continue
seen_sources.add(src)
unique_docs.append(doc)
if len(unique_docs) >= 6: break

# 文档分类：业务需求 vs 测试技能
business_docs = [d for d in unique_docs if d.metadata.get("type") == "business"]
skill_docs = [d for d in unique_docs if d.metadata.get("type") == "skill"]
selected_docs = business_docs[:4] + skill_docs[:2]

设计要点：

使用 similarity_search 进行相似度检索
按文档来源去重，避免重复内容
区分业务需求文档和测试技能文档，分别检索
限制上下文数量，避免超过 Token 限制

3.5 提示词工程：结构化测试用例生成
为了让大语言模型生成高质量、结构化的测试用例，我们设计了详细的提示词。
python 体验 AI 代码助手 代码解读复制代码 SYSTEM_PROMPT = "你是一名资深 QA 工程师，请基于以下【需求上下文】和【测试目标】，生成结构化、可执行的测试用例。"

IMPORTANT_NOTES = """ 重要说明：
- 内容中标有 “[业务需求]” 的是本次需求描述，请严格以此为准。
- 内容中标有 “[测试技能]” 的是通用测试方法论，请用于补充边界、异常、安全、兼容性等场景。
- 严禁将 [测试技能] 中未在 [业务需求] 提及的功能当作需求生成用例！
- ** 如果 [业务需求] 中未匹配到本次需求，则认定是功能回归，匹配 [测试技能] 中相关场景生成用例 """

REQUIREMENTS = """ 严格要求：
1. 每条用例必须包含以下字段：
- "id": 用例编号，格式为 TC_模块缩写_序号（如 TC_BARGAIN_01）
- "module": 测试模块名称（如 “砍价活动”、“满减活动”）
- "title": 测试标题（≤20 字，简明描述目的）
- "precondition": 前置条件（若无则写 “无”）
- "steps": 操作步骤列表（≥2 步，每步为字符串，如 “1. 打开页面”）
- "expected": 预期结果（明确、可验证）
2. 必须覆盖以下场景（仅当需求上下文提及对应关键词时才生成）：
- 正向主流程（必选）
- 异常/边界输入（如需求提到 “输入框”“金额” 等）
- 登录状态：若需求提到 “登录”“检查是否登录”“调起登录”，必须覆盖 → 未登录、已登录、登录失败
- 跳转验证：若需求提到 “跳转”“进入页面”“点击进入”，必须验证目标页面是否正确
- 多端标注：若涉及 “小程序”“H5”“APP”，在 title 或 steps 中明确标注（如 “[小程序] 点击...”）
3. 严禁编造需求未提及的功能（如需求未提 “支付”，不可生成支付用例）
4. 若【需求上下文】完全不涉及【测试目标】，请返回：{"error": "未找到相关需求内容"}"""

OUTPUT_SPEC = f""" 输出规范：
- 生成 {case_count} 条高质量用例，宁缺毋滥
- 输出为 纯 JSON 列表，无任何额外文字、注释、前缀、后缀或 Markdown
- 字段顺序不限，但必须包含上述 6 个字段
- 使用标准中文标点，禁止英文冒号"""

设计要点：

明确区分业务需求和测试技能的用途
详细规定测试用例的字段和格式
列出必须覆盖的测试场景（条件触发式）
严格要求输出格式为纯 JSON 列表

3.6 多格式文档处理：HTML 解析与噪声过滤
项目支持多种格式的文档，包括 HTML、PDF、Word、Excel 等。对于 HTML 文档，我们实现了智能的文本提取和噪声过滤。
python 体验 AI 代码助手 代码解读复制代码 # rag_skills_testcase/scripts/convert_docs_to_txt.py
def _remove_noise_tags(soup):
"""移除 HTML 中的噪声标签"""
# 移除脚本和样式标签
for tag in soup(["script", "style"]):
tag.decompose()

# 移除 box 相关的元素（避免提取 box 上的文字）
for tag in soup.find_all(class_=re.compile(r'box', re.IGNORECASE)):
tag.decompose()
for tag in soup.find_all(id=re.compile(r'box', re.IGNORECASE)):
tag.decompose()

# 处理注释
for comment in soup.find_all(string=lambda text: isinstance(text, Comment)):
comment.extract()

return soup

设计要点：

移除