公告

AI TestOps 7步全链路测试工作流

从实践到自动化：一个测试效率工具的诞生

一、产生原因

1.1 业务背景

在上一篇完成 AI 驱动 QA 方案重构后，为进一步提升执行效率，现决定将整套业务流程落地为自动化运行模式。初期我计划直接搭建专属平台实现全域落地，经过初步实践验证后发现，现阶段直接平台化落地体量偏大、落地成本较高。综合实际业务现状考量，最终确定先行通过技能编排完成工作流搭建，再依托 Hermes 等智能 Agent 能力串联打通全流程。下文将详细阐述整体落地实现方案。

在澳觅新零售业务中，每个迭代周期都需要对需求文档进行完整的测试分析：

需求分析：理解业务背景、功能模块、核心流程
测试点拆解：从需求中提取测试点，按优先级分类
测试用例生成：为每个测试点编写详细的测试用例
代码走查：审查代码实现是否符合需求
覆盖率分析：评估测试用例对需求和代码的覆盖程度
测试报告生成：汇总所有结果，输出专业报告

1.2 痛点分析

痛点	影响	量化
手工分析耗时	需求分析、测试点拆解需要大量时间	每个需求 2-4 小时
文档格式多样	HTML、PDF、Word 等格式需要人工转换	每次转换 10-30 分钟
代码走查困难	需要本地克隆代码，手动定位关键文件	每次走查 1-2 小时
报告格式不统一	不同人输出的报告格式不一致	沟通成本高
知识难以沉淀	测试经验无法复用	重复劳动

1.3 解决思路

目标： 将测试工作流自动化，减少人工干预，提高效率。

核心理念：

输入需求文档 → 自动输出测试报告
支持多种文档格式 → 自动识别和转换
代码走查自动化 → 远程访问 GitLab API
知识沉淀为 Skill → 可复用、可迭代

二、设计思路

2.1 整体架构

完整流程图

flowchart TD %% ===== 入口 ===== START([🚀 用户触发工作流]) --> INPUT subgraph INPUT["📥 Step 1: 需求输入与解析"] I1[上传需求文档 PRD / 需求描述 / 功能说明] I2[上传设计规格文档 技术设计 / API文档 / 数据库设计 可选] I3[提供代码仓库信息 GitLab项目+分支 / MR ID 可选] I1 --> PARSE[解析文档内容] I2 --> PARSE I3 --> PARSE end INPUT --> PREPROC subgraph PREPROC["⚙️ Step 0: 文档预处理"] P1{文档格式?} P1 -->|HTML/htm| P2[浏览器渲染提取内容 语雀/Confluence等富文本] P1 -->|PDF| P3[OCR / pymupdf 提取文本] P1 -->|Word| P4[python-docx 解析] P1 -->|Markdown/纯文本| P5[直接读取] P1 -->|URL| P6[web_extract 抓取] P2 --> PMD[保存为 .md] P3 --> PMD P4 --> PMD P5 --> PMD P6 --> PMD end PREPROC --> ANALYSIS subgraph ANALYSIS["📊 Step 2: 需求分析"] A1[提取功能模块列表] A2[梳理核心业务流程] A3[识别用户角色和权限] A4[分析输入输出参数] A5[提取业务规则和约束条件] A6[识别非功能性需求 性能/安全/可用性] A7[识别需求模糊点和潜在风险] A1 & A2 & A3 & A4 & A5 & A6 & A7 --> REPORT1[📄 输出: 结构化需求摘要] end ANALYSIS --> TESTPOINTS subgraph TESTPOINTS["🎯 Step 3: 测试点拆解"] T1[从需求分析结果提取测试点] T1 --> T2[按维度分类] T2 --> T2A[功能测试 正常业务流程] T2 --> T2B[边界测试 边界值/极值] T2 --> T2C[异常测试 异常输入/错误处理] T2 --> T2D[兼容性测试 不同环境/设备] T2 --> T2E[性能测试 响应时间/并发] T2 --> T2F[安全测试 权限控制/数据安全] T2A & T2B & T2C & T2D & T2E & T2F --> T3[定义优先级 P0 / P1 / P2 / P3] T3 --> REPORT2[📄 输出: 测试点清单] end TESTPOINTS --> TESTCASES subgraph TESTCASES["📝 Step 4: 测试用例生成"] TC1[为每个测试点生成用例] TC1 --> TC2[用例包含:] TC2 --> TC2A[用例编号 + 所属模块] TC2 --> TC2B[测试标题] TC2 --> TC2C[前置条件] TC2 --> TC2D[详细测试步骤] TC2 --> TC2E[测试数据] TC2 --> TC2F[预期结果] TC2 --> TC2G[优先级] TC2A & TC2B & TC2C & TC2D & TC2E & TC2F & TC2G --> TC3[覆盖正向+反向场景] TC3 --> REPORT3[📄 输出: 测试用例集] end TESTCASES --> CODEREVIEW subgraph CODEREVIEW["🔍 Step 5: 代码走查"] CR1{提供代码信息?} CR1 -->|否| SKIP_CR[⏭️ 跳过代码走查] CR1 -->|是| CR2{识别端类型} CR2 -->|服务端| SR1[从设计规格文档 提取API路径/服务名] SR1 --> SR2[curl 调用 GitLab REST API 搜索项目和分支] SR2 --> SR3[搜索相关代码] SR3 --> SR4[读取关键文件内容] CR2 -->|客户端 Android/iOS| CR3[使用用户指定的 项目名+分支] CR3 --> CR4[curl 调用 GitLab API 定位代码] SR4 & CR4 --> CR5[代码审查维度:] CR5 --> CR5A[功能实现一致性] CR5 --> CR5B[业务逻辑正确性] CR5 --> CR5C[API契约一致性] CR5 --> CR5D[潜在Bug] CR5 --> CR5E[安全问题] CR5 --> CR5F[性能问题] CR5A & CR5B & CR5C & CR5D & CR5E & CR5F --> CR6[生成走查报告] CR6 --> REPORT4A[📄 服务端代码走查报告] CR6 --> REPORT4B[📄 客户端代码走查报告] end CODEREVIEW --> COVERAGE subgraph COVERAGE["📈 Step 6: 覆盖率分析"] CV1[需求覆盖率分析 测试用例 vs 需求点] CV2[代码覆盖率分析 测试用例 vs 代码路径] CV3[识别未覆盖部分] CV4[提出补充建议] CV1 & CV2 & CV3 & CV4 --> REPORT5[📄 输出: 覆盖率报告] end COVERAGE --> FINAL subgraph FINAL["📋 Step 7: 测试报告生成"] F1[汇总前6步所有输出] F1 --> F2[生成完整报告:] F2 --> F2A[测试概览] F2 --> F2B[统计摘要] F2 --> F2C[需求分析详情] F2 --> F2D[测试用例详情] F2 --> F2E[代码走查结果] F2 --> F2F[覆盖率分析] F2 --> F2G[风险评估] F2 --> F2H[改进建议] F2A & F2B & F2C & F2D & F2E & F2F & F2G & F2H --> F3[格式化输出 Markdown 报告] end FINAL --> DONE([✅ 交付测试报告]) SKIP_CR --> COVERAGE %% ===== 样式 ===== classDef inputStyle fill:#2196F3,stroke:#1565C0,color:#fff classDef procStyle fill:#FF9800,stroke:#E65100,color:#fff classDef analysisStyle fill:#4CAF50,stroke:#1B5E20,color:#fff classDef testStyle fill:#9C27B0,stroke:#4A148C,color:#fff classDef codeStyle fill:#F44336,stroke:#B71C1C,color:#fff classDef reportStyle fill:#00BCD4,stroke:#006064,color:#fff classDef finalStyle fill:#FF5722,stroke:#BF360C,color:#fff class INPUT inputStyle class PREPROC procStyle class ANALYSIS analysisStyle class TESTPOINTS,TESTCASES testStyle class CODEREVIEW codeStyle class COVERAGE reportStyle class FINAL finalStyle

流程概览（简版）

flowchart LR S0[Step 0 文档预处理] --> S1[Step 1 需求输入与解析] S1 --> S2[Step 2 需求分析] S2 --> S3[Step 3 测试点拆解] S3 --> S4[Step 4 测试用例生成] S4 --> S5[Step 5 代码走查] S5 --> S6[Step 6 覆盖率分析] S6 --> S7[Step 7 测试报告生成] style S0 fill:#FF9800,stroke:#E65100,color:#fff style S1 fill:#2196F3,stroke:#1565C0,color:#fff style S2 fill:#4CAF50,stroke:#1B5E20,color:#fff style S3 fill:#9C27B0,stroke:#4A148C,color:#fff style S4 fill:#9C27B0,stroke:#4A148C,color:#fff style S5 fill:#F44336,stroke:#B71C1C,color:#fff style S6 fill:#00BCD4,stroke:#006064,color:#fff style S7 fill:#FF5722,stroke:#BF360C,color:#fff

三阶段演进路线图

flowchart LR P1[Phase 1 Skill 工具化 当前] -->|6个月| P2[Phase 2 Platform 平台化] P2 -->|12个月| P3[Phase 3 RAG 智能化] P1 --- P1D[✅ 7步工作流 ✅ HTML自动转换 ✅ GitLab代码走查 ✅ 报告自动生成] P2 --- P2D[🌐 Web UI 📡 API服务 👥 团队协作 💾 数据持久化] P3 --- P3D[🧠 向量检索 🎯 智能推荐 ⚠️ 风险预测 🔄 数据闭环] style P1 fill:#4CAF50,stroke:#1B5E20,color:#fff style P2 fill:#2196F3,stroke:#1565C0,color:#fff style P3 fill:#9C27B0,stroke:#4A148C,color:#fff

2.2 核心设计决策

决策1：HTML 自动转换

问题： 语雀、Confluence 等工具导出的 HTML 包含大量样式和脚本，无法直接分析。

方案： 使用浏览器渲染引擎提取内容。

# 核心思路
1. 使用 browser_navigate 打开本地 HTML 文件
2. 使用 browser_console 执行 JavaScript 提取内容
3. 通过 CSS 选择器定位主体内容（article、main 等）
4. 清理格式，保存为 Markdown

优势：

保留原始渲染效果
支持富文本内容（表格、列表、代码块）
无需安装额外依赖

决策2：GitLab API 直接调用

问题： GitLab MCP 工具依赖 MCP 服务器运行，不够稳定。

方案： 使用 curl 直接调用 GitLab REST API。

# 从配置文件读取连接信息
API_URL="http://gitlab.example.com/api/v4"
TOKEN="***"

# 搜索项目
curl -s -H "PRIVATE-TOKEN: $TOKEN" "$API_URL/projects?search=关键词"

# 读取文件内容
curl -s -H "PRIVATE-TOKEN: $TOKEN" "$API_URL/projects/:id/repository/files/:path/raw?ref=分支"

优势：

curl 是系统自带工具，无需额外依赖
GitLab REST API 功能完整
不依赖 MCP 服务器状态

决策3：Skill 知识沉淀

问题： 测试经验无法复用，每次都需要重新学习。

方案： 将工作流封装为 Hermes Skill。

# Skill 结构
name: testops-7step-workflow
description: AI驱动的7步全链路测试工作流
triggers:
  - 测试工作流
  - testops
  - 7步测试
category: software-development

优势：

知识可复用
支持迭代优化
跨会话持久化

2.3 技术实现

文档预处理模块

def preprocess_documents(input_files):
    """预处理所有输入文档"""
    processed_files = []
    
    for file_path in input_files:
        file_ext = os.path.splitext(file_path)[1].lower()
        
        if file_ext in ['.html', '.htm']:
            # HTML 文件：自动转换
            md_path = html_to_markdown_via_browser(file_path)
            processed_files.append(md_path)
        else:
            # 其他格式：直接使用
            processed_files.append(file_path)
    
    return processed_files

代码走查模块

def code_review_via_gitlab(project_id, branch, keywords):
    """通过 GitLab API 进行代码走查"""
    
    # 1. 搜索相关代码
    for keyword in keywords:
        result = terminal(f"""
            curl -s -H 'PRIVATE-TOKEN: {token}' \
            '{api_url}/projects/{project_id}/search?scope=blobs&search={keyword}&ref={branch}'
        """)
    
    # 2. 读取关键文件
    for file_path in key_files:
        content = terminal(f"""
            curl -s -H 'PRIVATE-TOKEN: {token}' \
            '{api_url}/projects/{project_id}/repository/files/{encoded_path}/raw?ref={branch}'
        """)
    
    # 3. 生成走查报告
    return generate_review_report(findings)

测试报告生成模块

def generate_test_report(requirements, test_points, test_cases, code_review):
    """生成完整的测试报告"""
    
    report = f"""
# AI TestOps 测试报告

## 📋 测试概览
- **项目:** {project_name}
- **测试日期:** {date}
- **测试用例数:** {len(test_cases)}

## 📊 统计摘要
| 指标 | 数值 |
|------|------|
| 需求覆盖率 | {coverage}% |
| P0用例数 | {p0_count} |
| 严重问题数 | {critical_count} |

## 📝 详细报告
...
"""
    return report

三、成果价值

3.1 效率提升

指标	手工方式	自动化方式	提升
需求分析	2-4 小时	10-15 分钟	90%
测试点拆解	1-2 小时	5-10 分钟	90%
测试用例生成	2-3 小时	10-20 分钟	85%
代码走查	1-2 小时	15-30 分钟	75%
报告生成	30-60 分钟	5-10 分钟	85%
总计	6-12 小时	45-85 分钟	85%

3.2 质量提升

标准化

统一的测试报告格式
标准化的测试点分类（P0/P1/P2/P3）
规范的测试用例结构

完整性

自动覆盖所有需求点
系统性的测试点拆解
完整的代码走查维度

可追溯性

测试用例关联到具体需求
代码走查关联到具体功能
完整的审计轨迹

3.3 知识沉淀

Skill 复用

测试工作流封装为可复用的 Skill
支持跨项目、跨团队使用
持续迭代优化

经验积累

代码走查的最佳实践
测试点拆解的方法论
常见问题的处理模式

3.4 实际案例

案例：3029-闪购搜索词输入页运营模块

输入：

需求文档：闪购搜索词输入页运营模块需求设计.html
设计规格：设计规格-3029-闪购搜索词输入页运营模块.html
代码分支：uat

输出：

测试报告：AI-TestOps-测试报告.md
代码走查报告：代码走查报告.md
测试用例：18 个（P0:6, P1:5, P2:4, P3:3）
需求覆盖率：100%
代码符合度：72%

关键发现：

排序公式简化实现，未达到 V2 方案要求
业务过滤规则不完整
Redis 缓存设计符合需求

改进建议：

优化排序公式，实现指数形式
补充完整的过滤规则
实现换一批去重逻辑

四、产品演进路线

4.1 演进策略：三步走

┌─────────────┐    ┌─────────────┐    ┌─────────────┐
│   Phase 1   │ →  │   Phase 2   │ →  │   Phase 3   │
│   Skill     │    │  Platform   │    │   RAG       │
│   工具化     │    │   平台化     │    │   智能化     │
└─────────────┘    └─────────────┘    └─────────────┘

4.2 Phase 1：Skill 工具化（当前阶段）

目标： 将测试工作流封装为可复用的 Skill，快速验证价值。

成果：

✅ 7步全链路测试工作流
✅ HTML 自动转换
✅ GitLab API 代码走查
✅ 测试报告自动生成

价值：

效率提升 85%
知识可复用
快速迭代优化

局限：

依赖 AI Agent 执行
无法团队协作
无数据积累

实际案例:

AI-TestOps-测试报告.md

服务端代码走查报告.md

客户端代码走查报告-3029闪购搜索运营模块.md

4.3 Phase 2：Platform 平台化

目标： 将 Skill 转化为独立平台，支持团队协作。

4.3.1 平台架构

┌─────────────────────────────────────────────────────────────┐
│                    AI TestOps Platform                       │
├─────────────────────────────────────────────────────────────┤
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐         │
│  │   Web UI    │  │  API 服务   │  │  定时任务    │         │
│  └─────────────┘  └─────────────┘  └─────────────┘         │
├─────────────────────────────────────────────────────────────┤
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐         │
│  │ 文档解析    │  │ 测试分析    │  │ 代码走查    │         │
│  │ 引擎        │  │ 引擎        │  │ 引擎        │         │
│  └─────────────┘  └─────────────┘  └─────────────┘         │
├─────────────────────────────────────────────────────────────┤
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐         │
│  │ PostgreSQL  │  │    Redis    │  │ MinIO/OSS   │         │
│  │ 业务数据    │  │  缓存       │  │ 文件存储    │         │
│  └─────────────┘  └─────────────┘  └─────────────┘         │
└─────────────────────────────────────────────────────────────┘

4.3.2 核心功能

功能模块	说明	技术栈
文档管理	上传、解析、存储各类文档	FastAPI + PostgreSQL
测试工作流	7步自动化流程	Celery + Redis
代码走查	GitLab API 集成	httpx + GitLab REST API
报告管理	生成、存储、分享报告	Jinja2 + MinIO
团队协作	多人协作、权限管理	RBAC + JWT

4.3.3 关键特性

1. 任务队列化

# 异步执行测试工作流
@app.post("/api/v1/tasks")
async def create_task(request: TaskRequest):
    task = celery_app.send_task(
        'testops.run_workflow',
        args=[request.doc_path, request.branch]
    )
    return {"task_id": task.id}

2. 结果持久化

# 存储测试结果到数据库
class TestResult(BaseModel):
    task_id: str
    project: str
    branch: str
    test_cases: List[TestCase]
    coverage: CoverageReport
    created_at: datetime

3. 团队协作

多人同时执行测试任务
测试结果共享和评论
权限管理和审计日志

4.4 Phase 3：RAG 智能化（12个月）

目标： 引入 RAG（检索增强生成），实现智能化测试分析。

4.4.1 RAG 架构

┌─────────────────────────────────────────────────────────────┐
│                    RAG 智能测试系统                          │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ┌─────────────┐         ┌─────────────┐                   │
│  │  用户查询   │ ───────→ │  Embedding  │                   │
│  └─────────────┘         └─────────────┘                   │
│                                ↓                            │
│                         ┌─────────────┐                    │
│                         │  向量数据库  │                    │
│                         │  (Milvus)   │                    │
│                         └─────────────┘                    │
│                                ↓                            │
│  ┌─────────────┐         ┌─────────────┐                   │
│  │  LLM 生成   │ ←─────── │  检索 TopK  │                   │
│  └─────────────┘         └─────────────┘                   │
│         ↓                                                   │
│  ┌─────────────┐                                           │
│  │  智能回答   │                                           │
│  └─────────────┘                                           │
│                                                             │
└─────────────────────────────────────────────────────────────┘

4.4.2 知识沉淀

向量数据库内容：

数据类型	来源	用途
需求文档	PRD、设计文档	需求分析参考
测试用例	历史测试用例	测试点推荐
代码片段	GitLab 代码库	代码走查参考
缺陷记录	Jira/Bug 系统	风险预测
测试报告	历史测试报告	趋势分析

Embedding 策略：

# 文档分块和 Embedding
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain.embeddings import OpenAIEmbeddings

# 1. 文档分块
splitter = RecursiveCharacterTextSplitter(
    chunk_size=1000,
    chunk_overlap=200
)
chunks = splitter.split_documents(documents)

# 2. 生成 Embedding
embeddings = OpenAIEmbeddings()
vectors = embeddings.embed_documents([chunk.page_content for chunk in chunks])

# 3. 存储到向量数据库
milvus_client.insert(
    collection_name="test_knowledge",
    data=vectors
)

4.4.3 智能功能

1. 智能测试点推荐

# 基于历史相似需求推荐测试点
def recommend_test_points(requirement_doc):
    # 1. 检索相似需求
    similar_docs = vector_db.search(
        query=requirement_doc,
        top_k=5,
        filter={"type": "requirement"}
    )
    
    # 2. 获取关联测试用例
    test_cases = []
    for doc in similar_docs:
        cases = vector_db.search(
            query=doc.content,
            filter={"type": "test_case"}
        )
        test_cases.extend(cases)
    
    # 3. LLM 总结推荐
    recommendation = llm.generate(f"""
        基于以下历史测试用例，为新需求推荐测试点：
        
        新需求：{requirement_doc}
        
        历史测试用例：{test_cases}
    """)
    
    return recommendation

2. 风险预测

# 基于历史缺陷预测高风险模块
def predict_risk_modules(code_changes):
    # 1. 检索历史缺陷
    historical_bugs = vector_db.search(
        query=code_changes,
        filter={"type": "bug"}
    )
    
    # 2. 分析缺陷模式
    risk_patterns = analyze_bug_patterns(historical_bugs)
    
    # 3. 预测风险等级
    risk_score = calculate_risk_score(code_changes, risk_patterns)
    
    return risk_score

3. 智能问答

# 基于 RAG 的智能问答
def answer_question(question):
    # 1. 检索相关知识
    relevant_docs = vector_db.search(
        query=question,
        top_k=5
    )
    
    # 2. LLM 生成回答
    answer = llm.generate(f"""
        基于以下知识，回答用户问题：
        
        用户问题：{question}
        
        相关知识：{relevant_docs}
    """)
    
    return answer

4.4.4 数据闭环

┌─────────────────────────────────────────────────────────────┐
│                    数据闭环                                  │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  文档输入 → 测试分析 → 代码走查 → 测试报告 → 知识沉淀       │
│     ↑                                              │       │
│     └──────────────────────────────────────────────┘       │
│                                                             │
│  每次测试都会积累知识，系统越来越智能                        │
│                                                             │
└─────────────────────────────────────────────────────────────┘

4.5 技术选型

层次	技术	说明
前端	React + Ant Design	Web UI
后端	FastAPI + Celery	API + 任务队列
数据库	PostgreSQL	业务数据
缓存	Redis	会话、任务状态
向量数据库	Milvus / Pinecone	知识存储
Embedding	OpenAI / BGE-M3	文本向量化
LLM	GPT-4 / Claude	智能生成
文件存储	MinIO / OSS	文档存储
部署	Docker + K8s	容器化部署

五、总结

AI TestOps 7步全链路测试工作流是一个从实践中来、到实践中去的效率工具。

核心价值

效率提升 85%：将 6-12 小时的工作压缩到 45-85 分钟
质量标准化：统一的报告格式、测试点分类、用例结构
知识可复用：封装为 Skill，支持跨项目使用
持续迭代：基于实际使用不断优化

关键设计

HTML 自动转换：使用浏览器渲染提取内容，无需人工干预
GitLab API 直接调用：使用 curl 调用 REST API，稳定可靠
Skill 知识沉淀：将经验封装为可复用的 Skill

适用场景

需求测试分析
代码走查
测试报告生成
回归测试分析

posted on 2026-08-02 17:12 Ethan_feng 阅读(3) 评论(0) 收藏举报

刷新页面返回顶部