MCP赋能测试：Tools、Resources、Prompts三种能力的开发与应用

一、MCP 在测试场景的核心价值

MCP 让大模型从"只会聊天"变成"能动手干活"。在测试场景中，这意味着大模型可以直接调用测试管理系统、缺陷管理系统、需求管理系统的接口，访问沉淀在这些系统中的测试资产，而不是每次都从零开始生成内容。

MCP Server 对外暴露三种能力：Tools（工具调用）、Resources（知识库）、Prompts（标准化提示词模板）。

二、Tools：让大模型调用外部函数

Tools 是大模型的"功能按钮"，每个 Tool 有名字、描述和输入规则，大模型根据用户意图自动选择调用哪个 Tool。

开发方式（基于 FastMCP）：

python 复制代码

from mcp.server import FastMCP

mcp = FastMCP("TestTools")

@mcp.tool()
def run_test_case(case_id: str) -> dict:
    """根据用例ID执行测试用例，返回执行结果"""
    # 调用测试管理系统 API
    result = test_platform_api.run(case_id)
    return result

if __name__ == "__main__":
    mcp.run(transport='stdio')

MCP Host 配置（以 Claude Desktop 为例）：

json 复制代码

{
  "mcpServers": {
    "test-tools": {
      "command": "uv",
      "args": ["run", "--project", "/path/to/project", "python", "mcp_server.py"],
      "env": {"LOG_LEVEL": "INFO"}
    }
  }
}

配置完成后，大模型在对话中就能自动识别何时需要调用这个 Tool，无需用户手动触发。

三、Resources：注入动态知识库

Resources 是 MCP Server 的"文件柜"，存储文本文件、数据库 Schema、Git 仓库内容等，让大模型随时拉取背景知识，而不依赖对话历史。

开发示例（将本地文件作为 Resource）：

python 复制代码

@mcp.resource(
    uri="file:///project/test-cases/README.md",
    title="测试用例说明",
    description="项目测试用例的整体说明和规范",
    mime_type="text/markdown"
)
def get_test_readme():
    with open("project/test-cases/README.md", "r", encoding="utf-8") as f:
        return f.read()

Resources 与 RAG 的区别：RAG 是检索式的，每次根据查询动态检索相关片段；Resources 是主动注入的，大模型可以按需读取完整内容。两者可以配合使用------Resources 提供结构化的项目文档，RAG 提供历史需求的语义检索。

四、Prompts：标准化提示词模板

Prompts 是预设的"剧本"，让大模型收到任务时直接按标准格式输出，避免每次从头编写提示词。

开发示例（边界值测试用例生成器）：

python 复制代码

@mcp.prompt(
    name="testcase_gen",
    title="边界值测试用例生成器",
    description="根据输入的需求描述，采用边界值分析法设计测试用例"
)
def testcase_gen(message: str) -> list:
    return [
        {
            "role": "system",
            "content": """你是资深测试开发工程师，专精边界值分析法。
边界值原则：针对输入范围，测试 min、max、min-1、max+1、nominal、空值/无效。
输出格式：Markdown 表格（ID | 输入 | 预期 | 类型：正常/边界/异常）。"""
        },
        {
            "role": "user",
            "content": f"需求：{message}\n\n请基于边界值方法设计测试用例。"
        }
    ]

Prompts 的价值在于标准化：团队中不同成员调用同一个 Prompt，输出格式和质量保持一致，避免"每个人写的提示词效果不一样"的问题。

五、MCP Inspector：调试 MCP Server 的专用工具

MCP Inspector 是官方提供的开源调试工具，基于浏览器 UI，由两部分组成：

Inspector Client（前端，默认端口 6274）：发送请求、查看响应，可以手动测试每个 Tool/Resource/Prompt
MCP Proxy Server（后端代理，默认端口 6277）：桥接本地 MCP Server 和 Inspector，实时转发数据

安装和启动：

bash 复制代码

npm install -g @modelcontextprotocol/inspector
mcp-inspector

启动后访问 http://localhost:6274，可以在不依赖 Claude Desktop 等 Host 的情况下，直接测试 MCP Server 的每个接口是否正常工作。这是开发 MCP Server 时必备的调试手段。

六、FastMCP 的设计哲学：Docstring + Type Hints

FastMCP 充分利用了 Python 的两个特性，让开发 MCP Server 和写普通函数一样简单：

Docstring（三引号注释）→ 自动成为 Tool/Resource/Prompt 的描述字段，大模型通过这个描述判断何时调用。写法要求：见文知意，避免歧义。

Type Hints（类型标注）→ 自动生成参数 Schema，精确定义每个参数的类型和约束。

python 复制代码

@mcp.tool()
def query_defects(project: str, severity: str = "high") -> list:
    """查询指定项目的缺陷列表，按严重程度过滤"""
    # project: 项目名称
    # severity: 严重程度，可选 high/medium/low，默认 high
    return defect_system.query(project=project, severity=severity)

大模型调用时的决策过程：解析用户意图 → 匹配 Tool/Resource/Prompt 的描述 → 按 Type Hints 生成参数 → 发起调用。Docstring 越清晰，Type Hints 越精确，大模型的选择就越准确。

七、测试场景的落地方向

MCP Server 在测试工程中的典型应用场景：

接入测试管理系统：封装用例查询、执行触发、结果回写等接口，让大模型直接操作测试平台，无需人工中转。

接入缺陷管理系统：大模型分析测试日志后，直接调用 Tool 创建缺陷单，填写复现步骤和影响范围。

接入 CI/CD 流水线：触发构建、查询流水线状态、获取测试报告，让大模型参与到持续集成的反馈循环中。

封装数据工厂：将测试数据构造接口封装为 MCP Tool，大模型根据测试场景自动调用数据工厂生成所需数据。

MCP Client 不需要自行开发------Claude Desktop、Cursor、VS Code 的 Cline 插件都已内置 MCP Client，选择一个顺手的 Host 即可，测试工程师只需专注于 MCP Server 侧的业务封装。