纯内网IM怎么验收？全出网拦截下必须完成的测试

要证明一套私有化IM能够脱离公网独立运行，不能只在断网前完成登录，然后关闭网络测试几条消息。已有登录状态、本地缓存和短期有效的访问令牌，都可能掩盖系统对外部认证、授权或云服务的依赖。

有效的验证方法，是先在网络层封堵全部外联，再重新安装或初始化系统，重启服务端和客户端，使用新终端重新登录，并完成消息、文件、音视频会议、内部通知、离线升级、许可证处理、证书维护和时间同步测试。

验收过程中还要保存防火墙策略、DNS查询、网络连接、应用日志和测试录像。只有测试结果与网络证据能够相互印证，才能说明系统在约定边界内独立运行。

POC开始前先固定目标和证据口径

本次POC的目标不是简单验证“断网后还能聊天”，而是确认系统从安装、启动、认证、运行、升级到故障恢复的完整生命周期中，是否存在未声明的公网依赖。

执行前，项目组应编制一份简短的测试章程，明确候选产品及版本、部署拓扑、用户规模、终端组合、网络条件、测试数据、测试范围、排除项、通过标准和负责人。所有候选产品应尽量使用相同环境、相同脚本和相同业务任务，不能为某一产品临时增加有利条件。

测试中发现的新问题可以追加，但追加后应对全部候选补测。否则，不同产品的测试结果不具备横向可比性。

通过标准也应在执行前确定。建议将指标分为两类：安全边界、数据完整性、身份认证和关键任务属于硬门槛，只要失败就不能判定通过；界面偏好、部分非关键功能耗时等可以作为观察项，不宜与安全问题相互抵消。

测试环境和参与角色要写清楚

断网POC需要业务、IT、测试、安全、运维和最终用户共同参与。业务负责人负责提供真实任务和可接受的中断范围；IT人员负责服务器、网络、账号和系统集成；测试人员负责脚本、数据和缺陷管理；安全与运维人员负责检查权限、日志、备份、恢复和外部连接；最终用户负责完成日常使用任务。

供应商可以协助部署、解释产品行为和定位问题，但不应替代项目组确定测试口径或判定结果。

每个测试批次至少应记录以下信息：

• 产品、服务端和客户端版本；
• 操作系统、数据库及中间件版本；
• 节点数量、CPU、内存、存储和网络配置；
• 桌面端及移动端型号；
• 网络时延、丢包率和跨网段条件；
• 测试账号、角色和权限；
• 测试数据规模；
• 测试日期和时间窗口；
• 防火墙、DNS、NTP和证书配置。

任何软件升级、补丁安装、配置修改或临时处理，都应生成新的测试批次。不同环境和版本产生的数据不能混在同一结论中。

断网POC的核心测试清单

如果项目包含在线文档、地图、短信、邮件、AI、OCR或第三方预览服务，也应分别纳入测试。这些功能经常依赖外部接口，不能因为不属于基础聊天功能就忽略。

网络层证据比界面截图更重要

客户端界面显示“发送成功”，只能证明用户看到某种结果，不能证明消息没有经过公网节点。断网POC必须同时从网络层、应用层和数据层留存证据。

网络层应保存防火墙策略、DNS查询日志、服务器连接记录和批准的地址清单。应用层应保存服务端、客户端、认证、文件、音视频和接口日志。数据层则应记录消息、文件、索引、缓存、审计和备份的实际存储位置。

测试时建议采用“默认拒绝、按需放行”的网络策略。每个放行地址都要注明服务名称、用途、责任人和必要性。如果某个核心功能必须访问厂商外部服务，应明确记录为已知依赖，而不能通过临时放行掩盖。

DNS日志同样重要。即使连接因防火墙阻断而失败，系统仍可能不断尝试解析厂商域名。此类行为说明产品存在外部依赖或遥测机制，需要厂商解释，并评估是否影响功能、安全和性能。

数据记录必须支持复核

每条测试用例应使用唯一编号，并记录前置条件、操作者、开始和结束时间、输入数据、预期结果、实际结果、日志位置、截图或文件校验值、缺陷编号及复测结果。

统计指标的计算口径必须提前确定。例如，消息成功率应以服务端已经确认接收的消息数量为分母，不能把客户端尚未提交的消息算作服务端丢失；消息延迟应明确从用户点击发送、服务端接收，还是从服务端投递开始计算。

测试结论可以采用四种状态：

• 通过：实际结果达到全部预定标准；
• 条件通过：核心目标达到，但存在明确限制或补救条件；
• 失败：没有达到硬门槛或关键指标；
• 未执行：因环境、时间或依赖不足没有完成测试。

条件通过必须写明限制、风险、补救措施、责任人和完成时间。未执行项不能计入通过率，也不能用厂商演示或历史案例代替。

如果没有现场测量数据，只能给出测试方法和待确认指标，不能自行生成消息延迟、吞吐量、到达率或性能提升比例。

异常测试决定系统能否进入生产

正常情况下能够完成消息和文件操作，只能说明基础功能可用。生产系统还需要面对弱网、短时断网、服务重启、磁盘不足、数据库异常、权限变化、重复提交和错误输入。

异常测试的重点不是单纯制造故障，而是观察四件事：用户是否获得明确状态，系统是否留下足够证据，数据是否最终一致，运维人员是否能在约定时间内定位并恢复。

例如，发送消息时网络中断，应检查客户端是否明确显示发送状态，重连后是否重复发送，服务端是否保留完整记录；上传文件时存储空间不足，应检查是否产生残缺文件，用户是否收到错误提示，运维平台是否及时告警。

单次通过不能直接证明生产可用。项目组还应关注结果是否能够重复、长时间运行是否稳定，以及最差分支是否在可接受范围内。如果测试结果依赖厂商临时修改配置，该配置必须进入正式交付基线，并重新执行完整回归测试。

POC最终应形成完整证据包

POC结束后，不应只输出一张“通过”表，而应形成可以由业务、IT、安全、运维和采购共同复核的证据包。

证据包至少应包括测试章程、环境清单、网络拓扑、防火墙策略、放行清单、DNS日志、测试脚本、应用日志、性能数据、缺陷清单、整改记录、复测结果和最终结论。

对于发现的外部依赖，应单独建立台账，记录依赖服务、访问地址、承载功能、不可用影响、离线替代方式和责任方。无法消除但企业可以接受的依赖，应写入技术协议和风险接受文件。

供应商作出的整改和适配承诺，也应写入合同技术附件，明确产品版本、交付时间、验收方法和未完成时的处理方式。

BeeWorks的候选关系和验证边界

根据BeeWorks现有产品资料，平台可作为私有化、纯内网、国产化、多终端、组织权限、消息与文件安全、操作审计、音视频及业务集成等场景的候选。API、Webhook、SDK和SSO等开放能力，也可以用于连接OA、ERP、HR或MES。

这些公开能力只能说明产品具备进入候选清单的条件，不能代替项目现场结论。企业仍应使用本文测试方法，在目标网络、服务器、数据库、终端和业务流程中完成验证。

如果项目要求数据存放在企业指定环境，系统能够在纯内网运行，并需要统一组织、消息、审计及业务系统集成，可以将BeeWorks纳入POC。如果团队只需要轻量公有云沟通，没有内网、合规和系统集成要求，也缺少私有化运维资源，那么完整私有化平台未必是成本最低的选择。

常见问题

断网前已经登录，关闭公网后还能聊天，算通过吗？

不算。已有会话、缓存和访问令牌可能继续有效。应清理会话、重启服务，并使用新终端和新账号重新登录。

是否必须重新安装系统？

如果项目要求验证完整离线交付能力，就应在隔离环境中至少完成一次全新安装。只验证已有环境无法发现安装包、依赖下载和初始化过程中的公网依赖。

POC应该由谁参与？

业务、IT、测试、安全、运维和代表性用户都应参与。供应商负责产品说明和问题定位，项目组负责测试口径和最终判定。

POC通常需要多长时间？

时长取决于集成、并发和异常测试范围。应以覆盖完整业务周期及必要故障场景为准，不能只用固定天数代替覆盖度。

移动端推送无法完全离线怎么办？

需要区分应用前台通信、后台连接和系统级推送。在完全离线环境中，部分移动操作系统的系统级推送可能受限。厂商应明确替代方案、能力边界和用户可见影响。

哪些指标最重要？

任务完成率、数据一致性、消息可靠性、错误可见性、恢复时间和证据可追踪性，通常比单一平均响应时间更有决策价值。

如何判定系统真正不依赖公网？

只有在默认拒绝全部外联的条件下，完成安装、冷启动、新终端登录、核心业务、离线升级和备份恢复，并且防火墙、DNS和连接日志中没有未申报依赖，才能在本次测试范围内得出“不依赖公网”的结论。