它在大模型与外部数据源、服务之间建立了标准化的通信通道，让静态的语言模型具备动态调用外部能力的基础设施。但开发一个 MCP Server，将测试服务、测试数据、测试工具暴露给大模型，成本极低——只需掌握 MCP Server 的开发方式。MCP 的类比是 USB Type-C：不同设备（模型）和不同外设（服务）通过同一标准接口互联。现有支持 MCP 的 Host（Claude Desktop、Cu

MCP 让大模型从"只会聊天"变成"能动手干活"。在测试场景中，这意味着大模型可以直接调用测试管理系统、缺陷管理系统、需求管理系统的接口，访问沉淀在这些系统中的测试资产，而不是每次都从零开始生成内容。Resources 是 MCP Server 的"文件柜"，存储文本文件、数据库 Schema、Git 仓库内容等，让大模型随时拉取背景知识，而不依赖对话历史。Prompts 的价值在于标准化：团队中

问题类别具体表现流程刚性缺乏灵活干预机制（暂停、参数调整、临时调试）等待时间长LLM 处理复杂任务耗时久，尤其高负载下产出不稳定受模型性能、输入数据、算力影响，质量不一致缺乏个性化流程与配置过于通用，无法适配不同项目需求反馈循环不足问题反馈机制迟缓，长期痛点未解阶段策略结果第一阶段从简单入手（Dify 智能体），化繁为简成功，用户接受度高第二阶段自研复杂系统，期望一步到位失败，用户弃用第三阶段提供

Playwright MCP Server 代表了 UI 自动化测试从"脚本驱动"到"AI 意图驱动"的范式革命。通过自然语言描述测试意图，大模型负责调用 Playwright 工具完成测试执行，测试工程师可以专注于场景设计和策略制定。这种工作模式不仅降低了自动化测试的入门门槛，更重要的是释放了测试工程师的创造力，使其能够投入更多精力到质量架构设计和业务价值挖掘中。

原始格式问题转换目标HTML 报告标签冗余，token 浪费结构化 JSONXML 报告结构完整但冗长按需过滤的精简 JSONMCP Server 为大模型提供延伸能力的趋势已成熟，但针对组织内部私有系统的定制化开发仍是刚需。从繁琐手动到 AI 驱动闭环显著提升效率与准确性测试工程师从"执行者"转变为"策略设计者"这种范式转变不仅解决了具体的技术痛点，更重要的是重新定义了测试工程师在 DevOps

但线程池会复用线程，复用的线程在创建时已经完成了变量复制，后续提交的任务拿到的是旧线程的变量值，而非当前父线程的值。模拟 10 个并发请求向线程池提交任务时，子线程输出的父线程名称与 index 无法一一对应——这在全链路压测中是致命的，会导致压测标记错乱。### TransmittableThreadLocal（TTL）：线程池场景的完整解决方案阿里开源的 TTL 在提交任务到线程池时，将当前父

性能项目中的模型可以归纳为五类：业务模型、容量模型、监控模型、分析模型、异常（失效）模型。五个模型各自解决不同的问题：- 业务模型：确定压力工具中的业务比例配置- 容量模型：确定系统设计容量的计算方式- 监控模型：确定需要监控的计数器范围- 分析模型：确定性能问题的分析路径- 异常模型：确定异常场景的设计方式全链路压测与普通压测在模型分类上没有区别，主要差异是：由于全链路压测在线上执行，对微服务、

在配置发送邮件通知，验证其正确性时，出现"553 mail from must equal authorized user"提示的错误；原因在于没有在"系统管理（Manage Jenkins）"的"系统设置（Configure system）"中"Jenkins Location"进行系统管理员邮件地址（System Admin e-mail address）配置；

理解 LLM 核心机制（FNN/RNN/CNN/Attention/Self-Attention）有助于测试工程师在序列任务和复杂依赖场景中更好地选择和使用模型。Token 是 LLM 处理文本的基本单位，掌握不同语言的 Token 估算方法，能有效评估模型的上下文限制，避免因 Token 溢出导致的幻觉问题。超参数（temperature、top_k、top_p 等）直接控制模型输出行为，测试工

全链路压测不是一套独立的方法论，它是性能容量场景中的一个具体落地案例，完全在 RESAR 性能工程的框架范围之内。。全链路压测在这五个部分中都有对应的工作内容，只是某些环节的工作量和复杂度更高。这五个部分不是严格的时序关系，而是对一个完整性能项目必须覆盖的维度的描述。无论采用瀑布模型、敏捷还是 DevOps，这五个部分都必须做到，否则性能项目的结果就是不可控的。