Apifox 新版本上线啦！

看看本次版本更新主要涵盖的重点内容，有没有你所关注的功能特性：

• 支持创建 MCP Client 以调试 MCP Server
• 支持创建「测试套件」
• 测试报告全面重构，支持结构化展示

• 调试能力持续升级

  • 支持查看 HTTP 版本、TLS 协议等网络信息
  • array 类型参数的子元素支持直接选择枚举值
  • 调试 SSE 接口时，支持 \r\n 换行符
• 支持导入 Hoppscotch 的 Collection
• 优化邀请他人加入项目的流程

• 用户反馈优化

  • 解决 MongoDB 数据库的密码包含特殊字符 % 时无法连接成功的问题
  • 解决绑定了手机号的用户无法通过“忘记密码”功能重置密码的问题

将 Apifox 更新至最新版，一起开启全新体验吧！

支持创建 MCP Client 以调试 MCP Server

Apifox 升级后，支持创建 MCP Client，开发者可以像调试 API 一样，直接调试 MCP Server 的Tools、Resources和 Prompts。同时支持STDIO和 Streamable HTTP 协议，并可自动配置 OAuth 2.0 认证流程，极大简化连接与认证流程，全面提升 AI Agent 的开发与调试效率。

更多关于 MCP 的内容，可以前往 帮助文档查看。

支持创建「测试套件」

Apifox 推出了「测试套件」功能，支持添加单接口用例和场景用例，并可在「静态」与「动态」两种模式间切换：

• 静态模式用于精确指定需要执行的测试项，内容不会变动，且支持灵活调整测试步骤的顺序。
• 动态模式可通过规则自动筛选需执行的测试项。每次运行时，系统会实时扫描项目，将所有符合条件的最新用例纳入执行。此模式下，仅可整体删除或修改过滤条件，无法单独删除组内的某个动态项。

场景用例侧重于测试流程的编排，测试套件则聚焦于灵活高效的测试执行，两者并非互相替代，而是分层协作，面向不同的使用场景，结合使用可以满足自动化测试的多样化需求。

更多关于测试套件的具体教程，可以查看往期内容《 测试用例越堆越多？用 Apifox 测试套件让自动化回归更易维护》。

测试报告全面重构，支持结构化展示

最新版本的 Apifox 对测试报告界面进行了全面重构，新版测试报告支持结构化展示所有测试步骤，让测试结果的层次关系更加清晰明了。用户可以快速定位每个测试步骤的执行情况和结果，从而更高效地分析测试问题，提升测试结果的可读性和分析效率。

调试能力持续升级

支持查看 HTTP 版本、TLS 协议等网络信息

更新 Apifox 后，开发者在调试接口时可直接查看 HTTP 版本、TLS 协议等详细网络信息，从而快速掌握接口请求的通信细节，有助于进行更精确的问题定位和性能分析。

同时，支持查看更详细的响应大小信息，包括 Body 和 Header 的大小，以及压缩前后的 Body 大小，便于判断 gzip 等压缩功能是否正常工作。

array 类型参数的子元素支持直接选择枚举值

调试接口时，如果 array 类型参数的子元素包含枚举值，用户可直接从列表中选择，无需手动输入，简化了配置流程，提升参数配置的便捷性与准确性，使接口调试更加高效流畅。

调试 SSE 接口时，支持 \r\n 换行符

Apifox 优化了 SSE 接口的调试体验。SSE 规范采用 \n\n 作为标准换行符，但一些实际业务中常用 \r\n （Windows 换行符） 进行分隔。Apifox 现已兼容并正确解析 \r\n 换行符，确保 SSE 流式数据能够以标准或非标准格式都能正确显示，帮助开发者更高效、准确地调试和验证 SSE 接口响应内容。

支持导入 Hoppscotch 的 Collection

Apifox 现已支持导入 Hoppscotch Collection 数据，帮助团队更便捷地将 Hoppscotch 项目迁移到 Apifox，进一步扩展了数据迁移的兼容性，降低迁移成本，提升团队协作的灵活性。

优化邀请他人加入项目的流程

Apifox 对项目成员邀请流程进行了优化，除了链接邀请和邮箱邀请外，还支持直接从团队成员列表中选择成员加入项目，并可在邀请时同步设置项目权限，大幅简化了成员管理流程，让团队协作配置更加便捷高效。

用户反馈优化

解决 MongoDB 数据库的密码包含特殊字符%时无法连接成功的问题

根据用户反馈，我们已修复 MongoDB 数据库连接中存在的问题：当数据库密码包含特殊字符 % 时，Apifox 现能正确处理并成功建立连接，进一步提升了数据库连接功能的稳定性和兼容性。

解决绑定了手机号的用户无法通过“忘记密码”功能重置密码的问题

现在通过"忘记密码"功能可以正常重置密码，确保用户在需要时能顺利找回账号访问权限，提升账户安全管理功能的完整性与可用性。

了解更多

当然，Apifox 产品团队为大家带来的新功能远不止以上这些：

• 优化了前后置操作的界面
• 优化了测试报告列表，支持结构化展示、筛选
• 支持复制测试套件的分享链接
• 支持调整测试套件静态步骤内资源的顺序
• 导入 OpenAPI/Swagger 数据时，支持 Query 类型的 HTTP 方法和 additionalOperation
• 优化了变量预览弹窗的触发时间，让其有一个合理的延迟
• 在付费页进行续费时，逻辑更合理与友好
• 解决在接口返回的响应数据上点击右键，没有 Copy JSONPath 等功能的问题
• 解决当根目录的可见性为内部时，WebSocket 接口仍被发布到公开在线文档的问题
• 解决未绑定支付方式的团队无法被正确转入组织的问题

除了新增功能，我们也对产品细节和使用体验进行了优化，具体修改内容可点击「阅读原文」前往 Apifox 更新日志查看，有任何问题欢迎在Apifox 用户群与我们交流沟通。

同时，Apifox 提供企业私有化部署版本，通过本地化部署、客制化服务，协助企业进一步提升研发团队效能。

欢迎各位用户对 Apifox 继续提出使用反馈和优化意见，我们会持续优化更新，致力于为用户提供更优秀的产品功能和更极致的使用体验！

当项目中的接口测试用例和测试场景越积越多，单独管理和执行它们的成本会急剧上升。原本用于保障质量的自动化测试，自身反而成了维护的负担。

传统的维护方式是手动点选。当项目沉淀了大量用例和测试场景时，手动核对哪些该入库、哪些该回归，会成为沉重的体力成本。

Apifox「测试套件」通过动态模式解决了这个问题。它不再死板地记录 ID，而是保存一套筛选规则，例如按目录、标签、优先级等条件进行组合筛选。

在每次运行前，套件会根据筛选规则，自动组合所有符合规则的用例和测试场景。这意味着你只需专注于测试内容的编写和打标，新增的测试资产就会自动进入 CI/CD 流水线，真正实现无人值守的持续集成。

最终，所有执行项的结果会被汇总到一份聚合报告中，便于集中分析和定位问题。

创建并编排你的第一个套件

将 Apifox 更新到最新版本后，在「自动化测试」模块中，可以找到「测试套件」的分类。点击其右侧的 ... 按钮，选择「新建测试套件」。

在弹出的窗口中输入一个描述性的名称，配置相关的优先级或者标签，一个空的测试套件就创建完成了。

创建完成后，核心工作是向这个套件中添加内容。测试套件的内容可以是单个的「接口测试用例」，也可以是包含多个步骤的「测试场景」。

添加测试内容：静态与动态

点击「添加接口测试用例」或「添加测试场景」时，会看到「静态」和「动态」两种模式的选项。这两种模式决定了测试套件如何管理其包含的测试项，适用于不同的维护策略和测试目标。

静态模式，顾名思义，是精确地、不变地指定要执行的测试项。当你以静态模式勾选某些用例时，系统记录的是这些用例的唯一 ID。即使后续这些用例的源目录增加了新的用例，或者用例本身被移动，这个套件的执行范围也不会改变。它的确定性很高，确保了每次运行的内容完全一致。

动态模式则完全不同。它不记录具体的用例 ID，而是保存一套 “筛选规则”，例如 “某个目录下的所有用例” 或 “所有标签为「语义合法」的用例”。

又或者是 “所有标记为 P0 优先级的测试场景”。

在动态模式下，每次运行测试套件时，系统都会根据这套规则重新扫描整个项目，将所有当前符合条件的用例动态地纳入执行计划。这意味着，只要测试用例的属性（如所在目录、标签、优先级）符合规则，它就会被自动包含进来。

静态模式与动态模式：如何选择？

这两种模式没有绝对的优劣之分，而是服务于不同的管理需求。选择哪种模式，取决于你希望测试套件具备怎样的维护特性。

对于需要严格控制范围的专项测试，静态模式更可靠。而对于需要持续迭代、自动纳新的回归或冒烟测试，动态模式则能极大地降低维护成本。

为了更清晰地理解两种模式的差异，可以通过下表进行对比：

执行顺序与高级配置

添加完测试内容后，可以在编排列表中通过拖拽调整它们的执行顺序。

在执行项（测试场景）的右侧，可以对套件的运行行为进行更细粒度的控制。

例如，「遇到错误时」 选项可以决定当某个步骤失败后是继续执行、跳过当前轮次还是立即终止整个运行。「循环次数」则可以将整个套件重复执行多次，用于简单的稳定性测试。这些配置让测试套件不仅仅是一个用例的集合，更是一个可控的执行流程。

运行测试套件

构建好测试套件后，下一步就是执行它。Apifox 提供了从本地手动运行到云端自动化执行的多种方式，以适应不同阶段和环境的需求。

本地可视化运行

最直接的运行方式是在 Apifox 客户端界面中，点击「运行」按钮。这种方式会从本地机器发起请求，适用于在开发和调试阶段进行小规模、快速的测试验证。在运行配置界面，可以临时切换「运行环境」，或设置在运行结束后发送通知。

运行完成后，Apifox 会生成一份本次执行的测试报告，并在界面中以可视化方式展示。报告中会按执行顺序列出每一个接口测试用例和测试场景的结果，清晰标识成功和失败状态，点击具体测试项可查看更详细的报告。

通过 CLI 运行

当测试规模较大，或者需要在无图形界面的服务器上执行时，Apifox CLI 是更高效的选择。它是一个命令行工具，可以将 Apifox 中的测试能力延展到任何终端环境。

要使用 CLI 运行，首先需要安装 Apifox CLI，并确保其版本为最新。完成安装或升级后，可以在测试套件的「CI/CD」标签页中找到自动生成的命令行：

将这条命令复制到终端中执行，即可在命令行看到与图形界面一致的测试过程和结果。

运行结束后，它还会在当前目录下生成一个 apifox-reports/ 文件夹，里面包含了 HTML 格式的详细测试报告。

通过 CLI 运行的方式是实现 CI/CD 的基础。可以将这条命令集成到 Jenkins、GitLab CI 或 GitHub Actions 的脚本中，在代码合并等关键节点自动触发回归测试。

通过定时任务运行

Apifox 内置了「定时任务」功能。在测试套件的「定时任务」标签页，可以新建一个任务，设置其运行周期和运行环境。

与本地运行不同，定时任务需要指定在「自托管 Runner」上执行。

Runner 是一个可以由团队自行部署在内网服务器上的轻量级执行程序。使用 Runner 可以解决本地机器关机或网络不通导致定时任务失败的问题，并利用服务器更强大的计算资源来执行大规模测试。

设置好定时任务后，Apifox 会在指定时间自动调度 Runner 执行测试套件，并将运行历史和报告上传至云端。同时，可以配置失败通知，一旦线上接口出现异常，相关人员就能第一时间收到告警信息，及时介入处理。

总结

通过静态与动态两种编排模式，你既可以精确控制专项测试的执行范围，也能让回归测试随业务迭代自动更新，无需反复手动维护。配合本地运行、CLI 集成和定时任务等多种执行方式，测试套件可以灵活嵌入开发流程的各个环节——从开发阶段的快速验证，到 CI/CD 流水线的自动化回归，再到生产环境的定时巡检。

更多关于测试套件的知识可以前往 Apifox 帮助文档查看。现在就去试试创建你的第一个测试套件，将现有测试内容进行编排，逐步构建可持续运行的自动化回归体系。