[测试工具] Axhub MCP：把 Axure PRD 变成测试用例

原创内容，未获授权禁止转载、转发、抄袭。

很多测试团队的需求文档和原型都放在 Axure 里。

原型能看，但如果想让 AI 直接分析页面、提取需求点、生成测试点，手工复制就比较麻烦。

Axhub MCP 解决的就是这件事。

它可以让 AI 通过浏览器读取 Axure 原型内容，再结合 Skill 生成结构化测试资产。

这篇记录一下安装方式，以及我怎么把用例助手相关能力封装成 Skill。

什么是 Axhub MCP

Axhub MCP 是一个基于Chrome扩展的Model Context Protocol (MCP) 服务器，专门为Axure原型设计而优化。它将您的Chrome浏览器转换为AI助手控制的自动化工具，特别针对Axure原型项目提供强大的搜索、分析和交互功能。

简单说，它可以把 Chrome 浏览器变成 AI 助手可以控制的自动化工具。

在 Axure 原型场景下，它可以帮助 AI 做这些事：

读取原型页面内容
分析 HTML 结构
提取页面文本
截取页面或元素截图
搜索原型中的特定内容
辅助生成需求点和测试点

核心能力主要有几类：

专为 Axure 优化：针对 Axure 原型项目做页面分析
AI 智能控制：让 AI 助手直接控制浏览器
语义搜索：基于 AI 搜索原型里的内容
高质量截图：支持页面和元素级截图
完整原型分析：提取 HTML、交互数据、文本内容
本地化部署：本地运行，保护数据隐私

安装

先看环境要求。

Node.js >= 18.19.0
npm 或 pnpm
Chrome/Chromium 浏览器

安装 Chrome 扩展

先安装 Axhub 的 Chrome 扩展。

可以参考官网的视频和说明：

text 复制代码

https://axhub.im/chrome/

安装 axhub-mcp-bridge

可以直接复制命令行安装。

也可以把命令发给 Cursor 等 AI Agent，让它代为安装。

Windows 用户：

bash 复制代码

npm i -g axhub-mcp-bridge

Mac OS 用户：

bash 复制代码

sudo npm i -g axhub-mcp-bridge
sudo chown -R $(whoami) /usr/local/lib/node_modules/axhub-mcp-bridge/dist
sudo chown -R $(whoami) $(dirname $(readlink $(which axhub-mcp-bridge)) | sed 's#/bin/#/lib/#')/axhub-mcp-bridge/dist 2>/dev/null || \
sudo chown -R $(whoami) "$(npm root -g)/axhub-mcp-bridge/dist"

如果使用 Edge 浏览器，还需要执行：

bash 复制代码

axhub-mcp-bridge register --edge

安装 MCP 到 Cursor

进入 Cursor 的 MCP 功能或设置。

等待服务启动后，点击"一键安装"。

使用方式

我的使用方式比较直接。

把用例编写的能力封装成 Skill。

先让 AI 读取 Axure PRD。

再提取功能点和测试点。

最后根据测试点生成详细测试用例。

》下面分析两个我的skill：

Skill 1：提取功能点和测试点

这个 Skill 用来读取 Axure PRD 链接，并输出：

模块
功能需求点
需求描述
测试点

Skill 内容如下：

md 复制代码

---
name: prd-requirement-get
description: Use Axure MCP to read a PRD URL, analyze as product and test expert, and output 模块、功能需求点、需求描述、各需求对应测试点 in strict markdown. Use when the user provides an Axure PRD link and asks for 需求点、测试点、功能需求分析、测试点分析、PRD分析.
---

# PRD 需求点与测试点提取

## 何时使用

- 用户提供 **Axure PRD 链接**（如 `http://prd.xxx/.../HTML/#id=xxx&p=xxx`）并要求输出需求点与测试点。
- 用户要求根据 PRD 做**全面需求分析**或**测试点分析**，且希望结果包含「功能需求点 + 需求描述 + 测试点」。

## 前置步骤（必须）

1. **使用 Axure MCP 读取 PRD**：用 `chrome_navigate` 打开用户提供的链接，再用 `get_page_markdown`（必要时带 `waitTime`）获取页面正文。
2. **理解与拆解**：结合 PRD 正文与页面结构，识别模块、流程、文案、按钮、异常说明等，作为需求与测试点依据。

## 概念约定

- **模块**：文档中的页面/功能模块，如「登录页面」「用户管理」「医生钱包」。
- **功能需求点**：从 PRD 中提炼的、可验证的需求，需按以下类型覆盖（若 PRD 中存在）：
  1. **功能性需求**：系统要实现的具体功能（如「用户应能够注册账户」）。
  2. **安全性需求**：与安全相关的要求（如「密码应加密存储」）。
  3. **性能需求**：负载、响应时间、并发等（如「页面加载时间应小于 2 秒」）。
  4. **兼容性需求**：设备、浏览器、系统支持（如「支持主流浏览器」）。
  5. **用户体验需求**：提示、引导、易用性等（如「登录失败时需明确错误提示」）。
  6. **异常处理需求**：异常时的行为与恢复（如「接口超时应有友好提示和重试」）。

## 测试点覆盖要求

每个需求点下的测试点需尽量覆盖：

- **正向场景**：正常流程、合法输入、符合规则的操作（如正确账号密码登录成功）。
- **异常场景**：错误输入、接口失败、权限不足等（如错误账号密码登录失败）。
- **边界场景**：长度限制、临界值、空值、最大值/最小值等（如超长密码时系统反应）。
- **特殊场景**：特殊符号、emoji、Unicode、换行等（如输入 emoji 时系统是否正确处理）。

额外约定：

- **文本输入框**：测试点需包含中文、大小写英文、特殊符号、换行、emoji、Unicode，以及**长度限制**和**必填校验**。
- **具体文案**：测试点中需写出**完整文案**，如占位符：「请输入账号」。
- **错误提示**：测试点中需写出**完整错误提示内容**及动态部分，如：「账号或密码错误」。
- **系统行为**：多次失败后的恢复、日志记录等，需有对应测试点，保证行为与恢复能力可验证。
- **性能与兼容性**：针对不同设备、浏览器、系统，验证响应时间、负载、展示与功能是否正常。

## 输出格式（必须严格遵守）

输出**仅**包含以下结构，不得增加「总结」「说明」等额外段落。每条需求点格式固定如下。

```markdown
## 模块：[模块名称，如「账号登录」「医生钱包」]

## 需求点1：[需求点标题]
  需求描述：[一句或一段话描述该需求，说清系统应做什么、在什么条件下、产生什么结果]
  测试点：
  1. [测试点1，可注明正向/异常/边界/特殊]
  2. [测试点2]
  3. [测试点3]
  ...

## 需求点2：[需求点标题]
  需求描述：[同上]
  测试点：
  1. [测试点1]
  2. [测试点2]
  ...

## 需求点3：...
```

- 每个需求点必须有 **需求描述** 和 **测试点**，测试点用数字列表。
- 不输出「总结」「注意事项」「使用说明」等与示例无关的内容；输出结尾即为最后一个需求点的最后一条测试点。

## 示例（格式以本示例为准）

```markdown
## 模块：账号登录

## 需求点1：弱密码判断
  需求描述：登录时，系统需使用公司统一的校验工具判断输入的密码是否为弱密码。若判断为弱密码，应阻止用户登录，并给出相应的提示信息。
  测试点：
  1. 输入弱密码尝试登录，验证是否被正确识别并阻止。
  2. 验证弱密码提示信息的准确性："密码安全升级，您的登录密码已不符合最新的安全要求，请及时修改！"
  3. 弱密码判定逻辑覆盖所有公司定义的弱密码规则。

## 需求点2：密码三个月过期判断
  需求描述：登录时系统需检查密码是否过期，若已过期，则提示用户"您的登录密码已过期，请及时修改！"并提供跳转至密码修改页面的功能。
  测试点：
  1. 未过期密码登录：验证有效期内的密码可以正常登录。
  2. 过期密码登录：设置过期密码，验证登录时是否显示正确提示信息，并能成功跳转到密码修改页面。
  3. 密码修改后过期状态清除：修改过期密码后，再次登录验证密码过期提示是否不再出现。

## 需求点3：[下一个需求点标题]
  需求描述：[描述内容]
  测试点：
  1. [测试点内容]
  2. [测试点内容]
```

## 执行检查

输出前自检：

- [ ] 已通过 Axure MCP 打开并抓取用户提供的 PRD 链接内容。
- [ ] 已按「模块 + 需求点 + 需求描述 + 测试点」输出，且无多余章节。
- [ ] 需求点覆盖功能性/安全性/性能/兼容性/体验/异常等（按 PRD 实际存在选取）。
- [ ] 测试点覆盖正向、异常、边界、特殊；涉及文案与错误提示的已写完整原文。
- [ ] 格式与示例一致：`## 模块`、`## 需求点N`、`需求描述：`、`测试点：` 及数字列表。

Skill 2：根据测试点生成用例

这个 Skill 用来把第一步生成的需求点和测试点，继续转换成详细测试用例。

输出内容包含：

前置条件
测试步骤
预期结果
优先级

Skill 内容如下：

md 复制代码

---
name: prd-testcase-write
description: Reads a markdown file containing 模块、功能需求点、需求描述、测试点, and outputs detailed test cases (前置条件/测试步骤/预期结果/优先级). Use when the user asks to convert 需求点与测试点 to 测试用例, or to write test cases from a 需求与测试点 markdown file.
---

# 需求点与测试点转详细测试用例

## 何时使用

- 用户提供一份**包含功能需求点和测试点的 Markdown 文件**（或指定路径），要求根据其内容编写**详细测试用例**。
- 用户要求将「需求点 + 测试点」转化为「前置条件、测试步骤、预期结果、优先级」格式的测试用例。

## 前置步骤（必须）

1. **获取输入文档**：若用户**未给出**或**未指定**包含需求点与测试点的 markdown 文件，则**直接返回**：「请提供需求点和测试点的markdown文件」；不再执行后续步骤。
2. **解析文档**：从该 markdown 中识别「模块」「需求点（含需求描述）」「各需求点下的测试点（编号列表）」。
3. **逐条转化**：为每个测试点编写一条测试用例，确保覆盖该文档中的**全部**需求点和测试点。

## 每条测试用例必须包含

- **前置条件**：执行该用例前需满足的条件（账号状态、数据环境、权限等）。
- **测试步骤**：用编号列出操作步骤，如「1. xxx 2. xxx 3. xxx」。
- **预期结果**：用编号列出与步骤一一对应的预期结果，如「1. xxx 2. xxx 3. xxx」。
- **优先级**：取值为且仅能为 **Highest**、**High**、**Medium**、**Low** 之一。

## 测试步骤与预期结果规则（必须遵守）

1. **编号一一对应**：预期结果中的编号 N 必须是「测试步骤 N」执行后的期望结果，不能错位。
   - 正确示例：**测试步骤**: 1. 在输入框中输入病案号 2. 点击查询按钮 → **预期结果**: 1. 输入成功 2. 成功查询到相应数据
   - 错误示例：**测试步骤**: 1. 在输入框中输入病案号 2. 点击查询按钮 → **预期结果**: 1. 按钮正确响应 2. 成功查询到相应数据（步骤1的预期应是「输入成功」）
2. **数量相等**：每条用例中「测试步骤」的条数与「预期结果」的条数必须相同（步骤有 3 条，则预期结果也必须有 3 条）。
   - 正确示例：步骤 1、2、3 → 预期结果 1、2、3
   - 错误示例：步骤 1、2、3 → 预期结果 1、2（缺少与步骤3对应的预期）
3. **无明确期望时**：若某步骤无明确可描述的期望结果，该条预期结果可写「无期望」。

## 输出格式（必须严格参照示例）

整体结构仅允许以下形式，不得增加「总结」「说明」「检查清单」等与示例无关的段落。

```markdown
# [模块名称，如「登录页面」]

## [需求点名称，如「弱密码判断」]
### [用例标题，建议以「验证」开头，概括该条测试点]
- **前置条件**: [具体条件]
- **测试步骤**: 1. [步骤1] 2. [步骤2] 3. [步骤3]
- **预期结果**: 1. [与步骤1对应的结果] 2. [与步骤2对应的结果] 3. [与步骤3对应的结果]
- **优先级**: Highest

### [下一条用例标题]
- **前置条件**: ...
- **测试步骤**: 1. ... 2. ...
- **预期结果**: 1. ... 2. ...
- **优先级**: High

## [下一个需求点名称]
### ...
```

- 一级标题 **#** 仅用于模块名。
- 二级标题 **##** 仅用于需求点名称（与输入文档中的需求点一致或对应）。
- 三级标题 **###** 仅用于单条测试用例标题（建议以「验证」开头，对应输入文档中的某一条测试点）。
- 每条用例下仅保留四个字段：**前置条件**、**测试步骤**、**预期结果**、**优先级**；冒号后保留一个空格（英文冒号 `:`）。

## 示例（格式以本示例为准）

**输入**（用户提供的需求点与测试点示例）：

```markdown
## 模块：登录页面

## 需求点1：弱密码判断
  需求描述：登录时，系统需使用公司统一的校验工具判断输入的密码是否为弱密码。若判断为弱密码，阻止用户登录，并给出相应的提示信息："密码安全升级，您的登录密码已不符合最新的安全要求，请及时修改！"
  测试点：
  1. 输入公司定义的所有类型的弱密码，验证是否被正确阻止登录。
  2. 验证弱密码提示信息的准确性与及时性。
  3. 确认在弱密码提示后，用户无法继续登录直至密码更改。

## 需求点2：密码有效期管理
  需求描述：在登录过程中检查密码是否已过期，过期则提供明确提示："您的登录密码已过期，请及时修改！"并提供跳转至密码修改页面的链接。登录时，如果密码在5天内将过期，显示弹窗："您的密码将于N天后过期，请及时修改"，其中N代表实际剩余天数。
  测试点：
  1. 使用已过期密码尝试登录，验证提示信息及跳转功能。
  2. 设置一个将在5天内过期的密码，验证是否收到正确且具体的过期提醒。
  3. 确保密码修改后，过期提示不再出现。
```

**输出**（必须严格按此格式）：

```markdown
# 登录页面

## 弱密码判断
### 验证使用公司定义的弱密码是否被正确阻止登录
- **前置条件**: 用户已经创建了一个包含公司定义的弱密码的账户
- **测试步骤**: 1. 访问登录页面 2. 输入包含弱密码的账户名和密码 3. 点击登录按钮
- **预期结果**: 1. 正常打开登录页 2. 正常输入账户名和密码 3. 系统显示提示信息："密码安全升级，您的登录密码已不符合最新的安全要求，请及时修改！"，并阻止用户登录
- **优先级**: Highest

### 验证弱密码提示信息的准确性与及时性
- **前置条件**: 用户尝试使用弱密码登录
- **测试步骤**: 1. 访问登录页面 2. 输入包含弱密码的账户名和密码 3. 点击登录按钮
- **预期结果**: 1. 正常打开登录页 2. 正常输入账户名和密码 3. 系统即时显示准确的提示信息："密码安全升级，您的登录密码已不符合最新的安全要求，请及时修改！"
- **优先级**: Highest

### 验证在弱密码提示后用户是否无法继续登录
- **前置条件**: 用户尝试使用弱密码登录，并收到弱密码提示
- **测试步骤**: 1. 尝试再次点击登录按钮 2. 检查是否仍然阻止登录
- **预期结果**: 1. 无法点击登录按钮 2. 用户无法继续登录，系统阻止所有尝试，直到密码更改
- **优先级**: Highest

## 密码有效期管理
### 验证使用已过期密码登录时的提示信息及跳转功能
- **前置条件**: 用户的账户密码已过期
- **测试步骤**: 1. 访问登录页面 2. 输入账户名和已过期密码 3. 点击登录按钮
- **预期结果**: 1. 正常打开登录页 2. 正常输入账户名和密码 3. 系统显示提示信息："您的登录密码已过期，请及时修改！"，并提供跳转至密码修改页面的链接
- **优先级**: Highest

### 验证5天内即将过期密码的过期提醒
- **前置条件**: 用户的账户密码将在5天内过期
- **测试步骤**: 1. 访问登录页面 2. 输入账户名和密码 3. 点击登录按钮
- **预期结果**: 1. 正常打开登录页 2. 正常输入账户名和密码 3. 系统显示弹窗："您的密码将于N天后过期，请及时修改"，其中N为实际剩余天数
- **优先级**: Highest

### 验证密码修改后不再出现过期提示
- **前置条件**: 用户的账户密码已修改为新密码
- **测试步骤**: 1. 访问登录页面 2. 输入账户名和新密码 3. 点击登录按钮
- **预期结果**: 1. 正常打开登录页 2. 正常输入账户名和密码 3. 登录成功，系统不再显示过期提示信息
- **优先级**: Highest
```

## 编写与自检要求

1. **覆盖完整**：输入文档中的每一个「需求点」、每一条「测试点」都必须对应至少一条测试用例；不得遗漏。
2. **步骤可执行**：测试步骤应清晰、具体，便于执行者按步骤操作。
3. **预期可判定**：预期结果应明确，便于执行者判断通过/不通过。
4. **边界与异常**：若测试点涉及边界或异常场景，用例中需在步骤或预期中体现（如超时、空数据、权限不足等）。
5. **生成后自检**：
   - 逐条核对：每条测试点的意图是否都有对应用例覆盖。
   - 逐条核对：每条用例的「测试步骤」条数是否等于「预期结果」条数，且编号一一对应。
   - 若发现遗漏或不符合规则，必须补充或修改后再输出最终结果。

## 优先级取值建议

- **Highest**：核心业务流程、安全相关、阻断性缺陷相关。
- **High**：主要功能、重要异常与边界。
- **Medium**：次要功能、体验与兼容性。
- **Low**：辅助说明、极少触发的场景。

总结

Axhub MCP 负责读取 Axure 原型。

Skill 负责约束 AI 的输出格式和测试规则。

用例助手负责把结果继续转成测试用例和 XMind。

把这三步串起来，PRD 到测试资产的过程会更稳定。