Rocket.Chat SlackBridge 手动回归测试指南双向桥接的完整验证矩阵与源码解读【免费下载链接】Rocket.ChatThe Secure CommsOS™ for mission-critical operations项目地址: https://gitcode.com/GitHub_Trending/ro/Rocket.ChatSlackBridge 是 Rocket.Chat 提供的 Slack 双向桥接模块让一个 Rocket.Chat 工作区与一个或多个 Slack 工作区互通消息。由于它没有端到端自动化测试覆盖任何对桥接链路的改动都依赖真实 Slack 工作区、真实 bot 安装以及人工双端观察来回归验证。本指南以官方手动测试计划为主线逐项拆解配置前提、消息/编辑/删除/表情/频道生命周期五大验证矩阵并结合仓库源码说明每条用例背后的实现逻辑与预期失败原因帮助你快速搭建自己的回归测试流程。功能概览与代码位置SlackBridge 的职责是翻译两个平台的房间、用户与消息模型。桥接本体位于 apps/meteor/server/bridges/slack/ 目录核心文件按方向拆分SlackAdapter.ts — 处理Slack → Rocket.Chat方向的连接与事件onMessage、onReactionAdded/Removed、onChannelLeft等RocketAdapter.ts — 处理Rocket.Chat → Slack方向通过回调callback机制监听 Rocket.Chat 侧动作。RocketAdapter 在 registerForEvents 中把桥接挂进了四个全局回调afterSaveMessage、afterDeleteMessage、afterSetReaction、afterUnsetReaction。也就是说Rocket.Chat 侧的任何存消息/删消息/加表情/去表情动作都会触发 RocketAdapter 转发给 Slack。理解这一点就能明白下面矩阵中为何会出现大量预期失败——限制不来自 Rocket.Chat而来自 Slack 的权限模型。所有配置项声明在 slackbridge.ts管理后台的Admin → Settings → SlackBridge面板连接生命周期管理在 slackbridge.ts同名桥梁类。日志则由 logger.ts 输出按Connection、Class、Slack、Rocket四个 section 划分。测试前置条件配置项与连接模式配置项速查表在Admin → Settings → SlackBridge中逐项确认下列配置配置项说明SlackBridge_Enabled总开关必须开启。SlackBridge_UseLegacy选择连接模式见下文在你要测试的模式下运行矩阵。SlackBridge_APIToken仅 LegacyRTM模式使用。SlackBridge_BotToken、SlackBridge_SigningSecret、SlackBridge_AppToken仅 App 模式Bolt / Socket Mode使用。SlackBridge_Out_Enabled控制 Rocket.Chat → Slack 方向的消息是否外发方向上有任何消息要流动都必须开启。SlackBridge_Out_All/SlackBridge_Out_Channels决定哪些 Rocket.Chat 房间被桥接出去。SlackBridge_Reactions_Enabled控制双向表情传播的总闸门。SlackBridge_AliasFormat可选仅 Slack → Rocket.Chat 方向生效。%s会被替换成 Slack 用户名测试建议用%s (via Slack)。SlackBridge_FileUpload_Enabled控制文件传输默认开启。从源码看slackbridge.ts 中SlackBridge_Enabled默认值为false且 token 类设置全部标记为secret: true不会回显明文SlackBridge_UseLegacy默认true。需要注意SlackBridge_APIToken与 App 模式的三个 token 都是multiline: true——源码中的 connect 会按\n拆分 token 列表因此每行一个 token 就对应一条独立的 Slack 连接与 adapter。App 模式还要求三个 token 行数一致否则直接报错number of tokens are not the same。两种连接模式回归必须双跑两条连接通道使用不同的 Slack 事件管道同一个回归可能只在一侧出现因此改动任何涉及连接/事件订阅的代码时必须在两种模式下各跑一遍完整矩阵Legacy 模式SlackBridge_UseLegacy: true基于 RTMReal Time Messaging连接使用 API token。对应 connectLegacy 中的RTMClient事件监听。App 模式SlackBridge_UseLegacy: falseSlack App 使用 bot token signing secret app token走 Bolt / Socket Mode。对应 connectApp其中socketMode: true表示不暴露 HTTP 回调端口通过 WebSocket 接收事件。环境准备清单开始前你还需要一个 Slack 工作区可创建频道并安装/邀请 bot下文中统一称作rocketbot至少一对两边都存在且包含 rocketbot的频道以及一对两边都存在但不包含 rocketbot的频道——下面多个用例都依赖这个差异条件允许时准备第二个 Slack 用户部分行为只有在消息作者不是 bot 本尊时才会显现例如编辑用例中人类无法编辑 bot 消息。测试过程中持续盯住SlackBridge日志slackLogger/rocketLogger两个 section。多条预期失败只在日志里可见界面可能没有任何提示。如何阅读验证矩阵每张矩阵统一用两列定位用例Origin来源—— 被操作消息最初发布在哪一侧Action performed on操作侧—— 测试者实际在哪一侧执行动作。此外每个矩阵都必须在 rocketbot 不属于的频道上重复一遍这类频道双向都不应传播任何内容且不应报任何错误。矩阵一消息发送#OriginAction performed on预期结果1SlackSlack消息出现在关联的 Rocket.Chat 房间别名格式由SlackBridge_AliasFormat决定。2Rocket.ChatRocket.Chat消息出现在关联的 Slack 频道由 rocketbot 以发送者的用户名与头像发布。SlackBridge_AliasFormat只影响用例 1RocketAdapter 的 addAliasToMsg 会在 Rocket.Chat 消息上设置alias字段因此配置%s (via Slack)后Slack 用户alice发来的消息会显示为alice (via Slack)。用例 2 则完全忽略该设置——Rocket.Chat → Slack 方向调用 postMessage其中username取自发送者的 Rocket.Chat 用户名、icon_url取发送者头像 URL从而在 Slack 侧伪装出原发送者身份真正的系统用户仍是 rocketbotSlack 界面按username/icon_url呈现。操作建议设置好别名格式后带值跑一次用例 1再清空跑一次对比然后恢复原值再继续——后续矩阵都假设工作区处于正常配置。无 rocketbot 频道复测两种方向的任何消息都不会跨越频道边界。矩阵二消息编辑Slack 有两条硬性权限约束App 不能编辑非自己发布的消息人类用户不能编辑 bot 消息。因此四格中有两格是预期失败——把它们列出来是因为不崩溃、本地侧保持一致本身就是验收标准。#OriginAction performed on预期结果1SlackSlack编辑传播到 Rocket.Chat。2Rocket.ChatRocket.Chat编辑传播到 Slack。3SlackRocket.Chat预期失败。Rocket.Chat 本地显示编辑后的内容Slack 侧保持不变。chat.update会被拒绝因为该消息不是 bot 发的。4Rocket.ChatSlack预期失败。Slack 甚至不会为 bot 消息提供编辑入口。两个方向的实现差异正好解释这四格Rocket.Chat 侧用户编辑 Slack 来源的消息时RocketAdapter 会触发 Slack 的chat.update而 Slack 拒绝非本 bot 消息的更新请求chat.update权限限制于是出现用例 3 的只改一边反之 Slack 用户试图编辑 bot 消息用例 4时Slack 客户端层面就不给编辑按钮。Rocket.Chat 的编辑处理在 processMessageChanged其中通过updatedBySlack标志避免把 Slack 的编辑回声再发回 Slack。无 rocketbot 频道复测两边的编辑都只停留在本地。矩阵三消息删除用例 3 需要特别留意由谁删。Rocket.Chat 来源的消息在 Slack 侧是 rocketbot 发布的而 Slack 对普通成员不提供删除 App 消息的入口因此二选一用工作区 Owner 或 Admin在 Slack UI 删除——管理员可以删除任何消息包括 App 的消息用桥接配置所用的同一个 token调用chat.delete使调用者就是 rocketbot 本尊Legacy/RTM 模式用SlackBridge_APITokenApp/Socket Mode 用SlackBridge_BotToken。换用任何其他 token 会失败并返回cant_delete_message——那是用例 4 的失败场景不是用例 3 的。两条路径都会产生相同的message_deleted事件因此任选其一都是合法跑法。#OriginAction performed on预期结果1SlackSlack删除传播到 Rocket.Chat。2Rocket.ChatRocket.Chat删除传播到 Slack。3Rocket.ChatSlack删除传播回 Rocket.Chat——按上文说明用工作区管理员删除或用 rocketbot 自己的 token 调chat.delete。4SlackRocket.Chat预期失败。消息只在 Rocket.Chat 侧被删除Slack 侧保留因为chat.delete无法删除他人发布的消息。Slack → Rocket.Chat 的删除入口在 processMessageDeleted它优先按bot_id ts查找 Rocket.Chat 消息即 Rocket.Chat 来源的消息找不到则按slack-{channel}-{ts}命名规则回查 Slack 来源消息最后调用 Rocket.Chat 的deleteMessage完成本地删除。无 rocketbot 频道复测删除只停留在各自一侧。矩阵四表情 Reactions本矩阵要求开启SlackBridge_Reactions_Enabled。关键事实发送到 Slack 侧的表情由 bot 账户添加因此无论谁在 Rocket.Chat 反应Slack 侧展示的都是 rocketbot 的表情。#OriginAction performed on预期结果1SlackSlack表情出现在 Rocket.Chat 消息上。2Rocket.ChatSlack表情出现在 Rocket.Chat 消息上。3Rocket.ChatRocket.Chat表情出现在 Slack 消息上以 rocketbot 身份。4SlackRocket.Chat表情出现在 Slack 消息上以 rocketbot 身份。每个用例都要再验证一次移除表情同时确认表情不会回显到它的来源侧——桥接通过一张 reactions 映射表去重一旦出现重复计数就说明去重逻辑被破坏了。去重机制的源码依据非常清晰slackbridge.ts 中SlackBridgeClass构造时初始化了this.reactionsMap new Map()Slack 侧 onReactionAdded 在落地表情前先向映射表写入set{messageId}{reaction}键Rocket.Chat 侧 onSetReaction 则在传播前先尝试reactionsMap.delete该键——能删掉就说明这条表情来自 Slack直接 return 不再回发onUnsetReaction对unset{...}键的处理逻辑完全对称。SlackBridge_Reactions_Enabled开关回归设置状态预期结果关闭从两侧对 Slack 来源与 Rocket.Chat 来源的消息分别加表情——什么都不传播也不报错。开启重放同样的表情操作——按上方矩阵传播无需重启服务器。不重启即生效在源码中有印证isReactionsEnabled由 processSettings 中的settings.watch(SlackBridge_Reactions_Enabled, ...)动态缓存运行期切换无需重连。无 rocketbot 频道复测表情只停留在本地侧。矩阵五频道生命周期这些用例覆盖频道出现、消失、bot 加入/离开时桥接的行为。每完成一个步骤都要从两侧各发一条消息并确认传播结果。场景 A两边都存在频道但 rocketbot 不在 Slack 频道里确认两个方向都不传播任何内容。把 rocketbot 邀请进 Slack 频道。从 Slack 和 Rocket.Chat 各发一条——此时两个方向都应正常工作。场景 B频道只在 Rocket.Chat 存在在 Slack 创建同名频道并邀请 rocketbot。从 Rocket.Chat 发送——消息到达 Slack。从 Slack 发送——消息到达 Rocket.Chat。场景 C频道只在 Slack 存在邀请 rocketbot 进 Slack 频道。从 Slack 发送——Rocket.Chat 侧自动创建对应频道并接收消息。从 Rocket.Chat 发送——消息到达 Slack。自动建频道的逻辑在 addChannelRocket.Chat 若已有同名房间则直接复用并建立 import id 关联Slack 的#general会映射到 Rocket.Chat 的GENERAL否则按is_private决定创建c公开频道还是p私有频道。首次创建若失败并发消息竞争还会在 1 秒后重试一次。场景 D两边都存在且 rocketbot 已在频道中删除 Rocket.Chat 频道再从 Slack 发消息——行为等同只在 Slack 存在的场景频道会被重建。把 rocketbot 从 Slack 频道移除再从 Slack 和 Rocket.Chat 各发一条——两个方向都不传播且日志无任何报错。bot 被移除/频道退出的触发点在于 Slack 事件监听App 模式注册了channel_left与member_joined_channelSlackAdapter.ts其中channel_left通过 onChannelLeft →removeSlackChannel把频道从slackChannelRocketBotMembershipMap中摘除此后 RocketAdapter 在 onMessage 里因查不到getSlackChannel(rid)而continue消息自然不再外发。已知覆盖缺口上述矩阵是历史上沉淀下来的手工回归套件并刻意与之对齐。以下场景不在矩阵覆盖范围内在相关改动落地时值得手工补测文件上传SlackBridge_FileUpload_Enabled——涉及 SlackAdapter 的 processFileShare 与 RocketAdapter 的 processFileShare 两条链路前者下载 Slack 私有文件链接到 Rocket.Chat 上传存储后者把 Rocket.Chat 附件以 URL 形式发到 SlackSlack 历史导入/slackbridge-import斜杠命令实现在 slackbridge_import.server.ts逐频道把 Slack 历史消息、成员、主题与置顶批量搬入 Rocket.Chat线程消息postMessage中的thread_ts映射私有频道与私信DMSlackBridge_ExcludeBotnames过滤——SlackAdapter 的 processBotMessage 中bot 用户名若命中该正则则直接丢弃消息Remove Channel Links管理操作SlackBridge_Remove_Channel_Links对应方法 removeSlackBridgeChannelLinks需remove-slackbridge-links权限用于清除所有房间的 import id 关联同时桥接多个 Slack 工作区每个 token 设置按行一个 token。结语把源码当预言机整套矩阵的设计哲学是验证边界上的不变量有 rocketbot 的频道双向流动、无 rocketbot 的频道双向静默、Slack 权限墙两侧分别出现预期失败、表情与删除事件不会回环。跑用例前先读一遍 SlackAdapter.ts 与 RocketAdapter.ts把每个预期结果对应到具体的postXxx/processXxx方法与reactionsMap、slackChannelRocketBotMembershipMap等状态结构回归就会从对照表格打勾升级为边对照边理解因果。改动连接/事件订阅路径时务必按 配置 一节在 Legacy 与 App 两种模式下把矩阵完整各跑一遍——两条管道任何一个出了回归都只能靠这套人工流程兜底。【免费下载链接】Rocket.ChatThe Secure CommsOS™ for mission-critical operations项目地址: https://gitcode.com/GitHub_Trending/ro/Rocket.Chat创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
