AI Testing Agent

AI Testing Agent 是「AI 测研社」的第一个 AI 测试工程化实战项目，围绕一条完整的自动化测试研发流程展开：

需求文档 → 测试策略 → 测试用例 → 自动化脚本 → 测试执行 → 结果采集 → AI 失败分析 → 测试报告

这个项目尝试把自然语言测试需求转换成可以执行、验证和输出报告的自动化测试任务，并逐步实现页面、接口与数据库之间的多源数据校验。

项目目标不是让 AI 完全替代测试工程师，而是让 AI 负责理解需求和辅助分析，让 Playwright、Python 与 Pytest 负责稳定执行和精确验证。

这个项目解决什么问题

传统自动化测试通常存在以下痛点：

• 需求、用例、脚本和报告相互割裂：测试需求写在文档里，用例写在 Excel 中，脚本在另一套代码仓库，报告又是手动整理的——各环节数据不互通，变更时改一处忘一处。
• 测试用例依赖人工设计：用例覆盖度取决于测试人员的经验和投入时间，边界场景和异常路径容易被遗漏。
• 自动化脚本开发成本较高：从零编写 Playwright 或 Pytest 脚本需要投入大量时间，且不同项目之间结构差异大，难以形成标准模板。
• 测试失败后仍然需要人工定位：脚本挂了，需要手动翻日志、看截图、对比预期和实际结果，排查效率受限于个人经验。
• 不同项目的测试代码难以复用：脚本和页面结构强耦合，换一个被测系统往往意味着重新写一套。
• 测试结果缺少智能分析和风险判断：即便生成了 Pass/Fail 报告，也很难从失败结果中自动提炼出风险点和修复建议。

最终能够实现什么

当前已经实现 ✅

• 使用 Playwright 访问真实网页
• 根据配置采集指定页面字段并保存为 JSON
• 将实际结果与基准 JSON 自动比对
• 识别字段缺失、类型异常和值不一致
• 自动生成 JSON 和 Markdown 测试报告
• 将采集、标准化、比对和报告拆分为独立模块

正在开发 🚧

• 完成 SauceDemo 完整业务场景测试
• 页面数据与接口数据自动比对
• 使用大模型辅助分析测试失败原因

后续规划 📋

• 从需求文档或接口文档自动生成测试策略
• 使用 AI 生成结构化测试用例
• 自动生成 API 和 Playwright UI 自动化脚本
• 使用 Pytest 统一执行测试
• 页面、接口和数据库多源数据校验
• 接入 Pytest、Allure 与 Jenkins CI/CD
• 保存历史测试结果并展示趋势
• 通过 FastAPI + React 提供可视化管理界面

技术栈

分类	技术	状态
浏览器自动化	Playwright、Playwright MCP	✅ 已集成
编程语言	Python	✅ 已使用
测试框架	Pytest	🚧 集成中
配置与数据	YAML / JSON	✅ 已使用
测试报告	Markdown、JSON	✅ 已生成
AI 开发工具	Claude Code	✅ 已使用
可视化报告	Allure	📋 规划中
持续集成	Jenkins	📋 规划中
管理界面	FastAPI + React	📋 规划中

系统架构

目标架构

flowchart TD
    A["📄 需求文档 / 接口文档 / 页面信息"] --> B["🧠 AI 生成测试策略"]
    B --> C["📋 结构化测试用例"]
    C --> D["📝 API / UI 脚本生成"]
    D --> E["⚡ Pytest 统一执行"]
    E --> F["📊 结果采集与证据保存"]
    F --> G["🔍 基准数据比对"]
    G --> H["🤖 AI 失败分析"]
    H --> I["📄 测试报告（Markdown / JSON / Allure）"]

    style A fill:#dbeafe,stroke:#2563eb
    style B fill:#fef3c7,stroke:#d97706
    style C fill:#fef3c7,stroke:#d97706
    style D fill:#fef3c7,stroke:#d97706
    style E fill:#dcfce7,stroke:#16a34a
    style F fill:#dcfce7,stroke:#16a34a
    style G fill:#dcfce7,stroke:#16a34a
    style H fill:#fef3c7,stroke:#d97706
    style I fill:#dcfce7,stroke:#16a34a

🟡 = 正在开发或规划中，🟢 = 已完成

当前已实现的模块架构

flowchart TD
    A["测试任务配置"] --> B["Config Loader"]
    B --> C["UI / API Collector"]
    C --> D["Normalizer"]
    D --> E["Comparator"]
    E --> F["Reporter"]
    F --> G["JSON / Markdown / Allure"]

各模块职责：

模块	职责	状态
Config Loader	加载并校验测试任务配置	✅ 已完成
Collector	从页面、接口或数据库采集数据	✅ 已完成
Normalizer	统一数字、文本、日期等格式	✅ 已完成
Comparator	将实际数据与基准数据进行比对	✅ 已完成
Reporter	生成测试结果和差异报告	✅ 已完成
LLM Analyzer	大模型辅助分析失败原因	🚧 开发中

确定性的测试逻辑仍然由 Python 完成，大模型主要用于理解测试需求、辅助生成任务以及分析异常原因。

当前项目进度

阶段	开发目标	状态
P0	跑通真实网页访问与元素读取	✅ 已完成
P1	页面字段采集并保存 JSON	✅ 已完成
P2	页面数据与基准 JSON 比对	✅ 已完成
P3	自动生成 Markdown 测试报告	✅ 已完成
P4	重构为配置驱动的通用框架	🟡 初步完成
P5	完成 SauceDemo 业务案例	🟠 下一阶段
P6	页面与 API 数据比对	⏳ 待开发
P7	页面、API、数据库多源校验	⏳ 待开发
P8	LLM 失败分析与用例生成	⏳ 待开发
P9	接入 CI/CD、Allure 与历史趋势	⏳ 待开发

项目输出示例

一次完整测试任务将产生以下结果：

generated/
├── actual.json        # 从测试目标采集到的实际数据
├── comparison.json    # 实际数据与基准数据的比对结果
└── report.md          # 面向测试人员阅读的 Markdown 测试报告

当前开发重点

目前正在进行两个方向的验证：

1. 使用第二个真实网站验证框架是否能够复用。
2. 增加 API 数据采集，实现页面与接口数据自动比对。

只有通过多个真实项目验证，才能判断这套架构是不是一个真正可复用的测试框架，而不只是针对单个网站编写的测试脚本。

适合哪些人

本专题适合：

• 希望从手工测试转向自动化测试的工程师
• 正在学习 Python、Pytest 与 Playwright 的测试人员
• 希望了解 Claude Code、MCP 如何应用于测试工作的人
• 希望建设企业数据校验和测试报告流程的测试负责人
• 想通过真实项目学习 AI 测试工程化的人

GitHub 项目

项目代码整理完成后，将在 GitHub 开放基础版本，包括：

• 基础测试框架
• 示例任务配置
• 页面数据采集
• JSON 基准比对
• Markdown 报告
• 安装与运行说明

GitHub 仓库：整理中，稍后开放

专题文章目录

🟢 已发布

• 从 0 到 1 创建 AI Testing Agent — 项目架构设计与核心组件详解

🟡 规划中

以下文章按照完整测试研发流程排序，目前已创建占位框架，后续持续补充正文。

• 项目介绍与整体架构 — 项目背景、设计目标与技术选型
• 从需求文档生成测试策略 — 使用 AI 从需求中提取测试范围和优先级
• 使用 AI 生成结构化测试用例 — 将测试策略转换为可执行的用例清单
• 自动生成接口测试脚本 — 基于测试用例自动生成 API 测试代码
• 自动生成 Playwright UI 测试 — 基于测试用例自动生成 UI 自动化脚本
• 使用 Pytest 统一执行测试 — 将 API 和 UI 测试统一纳入 Pytest 调度
• 自动采集测试结果与截图 — 执行过程中自动保存接口响应、日志和截图
• 使用 AI 分析测试失败原因 — 将失败日志和截图交给大模型分析
• 自动生成综合测试报告 — 汇总测试结果并生成 Markdown / Allure 报告
• Jenkins 持续集成与企业系统对接 — 接入 CI/CD 实现定时回归测试

持续更新

这个专题会持续记录 AI Testing Agent 从最小可运行案例，到多源数据校验与智能分析的完整开发过程。

内容不仅会展示最终代码，也会记录架构选择、失败尝试、重构过程和真实验证结果。

本专题持续更新中，欢迎通过评论区交流反馈。