支持私有部署的即时通讯软件怎么验收？从内网到信创逐项自测

私有部署即时通讯软件的验收，最常见的失败不是系统跑不起来，而是验收单上只写了能登录、能发消息。上线后才发现断网时文件打不开、移动端推送依赖外网、信创终端能装但屏幕共享异常，或者出了问题没人说得清该由谁处理。

验收的对象不是一款软件，而是软件版本、部署环境、业务流程和运维责任的组合。支持私有部署的即时通讯软件，验收至少要走过七段：先定基线，再验内网部署、功能、安全、信创、性能和交付整改。每一段都要回答三个问题：怎么测，看到什么结果算通过，留下什么证据。像 喧喧IM这类支持私有部署的即时通讯软件，也可以直接拿这套清单做自测，再按实际交付版本裁剪。

验收前先定基线：把能用写成可判定条件

验收争议大多不是技术问题，而是标准没提前写。合同里写运行稳定、满足需求，验收时双方理解不同；写成在约定账号规模、并发量和网络条件下，消息发送成功率、时延、故障恢复时间达到多少，才有可判定的结果。阈值由业务、IT 和厂商在验收方案里共同确认，写进合同或附件，不要等到验收会上再补。

GB/T 25000.51-2016 把就绪可用软件产品的质量要求拆成功能性、性能效率、兼容性、易用性、可靠性、信息安全性、维护性、可移植性等维度，可以作为验收大纲的检查框架。它不是让每个项目都做全套测试，而是提醒验收不要只覆盖功能一项。

先划清验收对象和版本边界

验收对象要写到具体版本和组件，不能只写产品名称。服务端、消息中转服务、数据库、音视频服务、文档服务、移动端推送、接口网关、反向代理，哪些在本次交付范围内，哪些由甲方现有环境提供，都要列清楚。账号规模、组织层级、终端类型、网络区域、集成系统和管理员角色，也要提前划进范围。

版本边界同样要写清。以喧喧IM为例， 开源版与专业版的能力差异在官网分列，音视频会议、文档协同、组织隔离、LDAP 认证、IP 登录限制、服务端文件加密存储、数据库消息加密存储等列在专业版清单中。验收时不能拿演示环境、另一个版本或口头承诺代替交付版本。开源版也可以验收，但用例要按开源版实际能力裁剪。

用四张表把争议前置

清单	要写清的内容	验收时的用途
交付物清单	版本、组件、授权、安装包、接口、文档、培训、支持期限	防止演示版本与实际交付不一致
运行依赖清单	服务器、CPU、操作系统、数据库、中间件、端口、域名、证书、时钟源、外部服务	防止上线后才发现缺组件或存在出网依赖
验收用例清单	场景、前置条件、步骤、预期结果、证据	让测试可复现、结论可复核
责任与整改清单	安装、补丁、备份、故障响应、缺陷分级、复测时间	防止问题悬空、责任不清

四张表不需要写得厚，关键是每一条都能追到人、追到版本、追到证据。比如运行依赖清单里写了移动端推送，就要注明推送通道由谁提供、是否出网、断网后如何处理；写了文档协同，就要注明文档服务组件由谁部署、是否在本次验收范围。

验收环境要尽量贴近生产

验收环境越接近生产，结论越可信。CPU 架构、操作系统版本、数据库版本、中间件版本、客户端版本、网络策略和账号规模，至少要和目标环境一致。做不到全部一致时，写一份差异清单，说明差异会不会影响结论，以及上线前在哪里补测。

测试账号要覆盖真实角色，包括普通员工、部门管理员、跨组织用户、新入职和离职账号、移动端用户。测试数据也要接近业务上限，包含大文件、长文件名、特殊字符、中文路径和大量历史消息。验收组至少包含业务、IT 运维、安全和采购使用部门，厂商可以到场配合，但结果不能由厂商单方面记录。

内网部署验收：先证明离了公网还能跑

私有部署不等于断网可用。安装包放在内网，只说明安装包能拿到；登录、消息、文件、会议、推送、升级是否依赖外网，要逐项断网验证。很多项目在演示环境一切正常，切换到纯内网后才暴露外部依赖，原因就是验收时没有断开公网。

部署前检查服务器、端口和依赖

服务器配置要按目标账号规模和业务峰值准备。喧喧IM部署文档给出的 5000 人以下参考配置是 xxb、xxd 服务器各 16GB 内存、8 核以上，音视频服务器 8 核以上、带宽建议 8Mbps 以上。这个配置是准备环境的起点，不是性能结论，最终仍要以目标环境压测为准。详细步骤可查 喧喧IM安装升级手册。

端口、域名、证书、时钟源和防火墙策略要在安装前对齐。以 Windows 一键安装包为例，部署文档要求放行 11443 和 11444 端口；实际端口以交付版本和部署拓扑为准。检查时要覆盖服务端到数据库、服务端到文件目录、客户端到服务端、客户端到音视频服务、管理后台到服务端几条链路，不能只在服务器本机访问 localhost。

还要检查磁盘空间、日志目录、备份目录、数据库账号权限和授权文件。授权导入不是走形式，授权到期、授权范围、账号数量限制都会影响上线后的使用。

安装与首次登录要留下证据

安装过程至少记录安装包完整性校验结果、版本号、安装路径、服务启动状态和后台登录结果。首次登录后立即确认默认管理员密码已修改，弱口令、共享管理员账号和长期不用的测试账号要在验收前处理掉。组织架构导入、用户登录、客户端服务器地址、移动端服务器地址，也要逐项验证。

验收证据可以是截图、录屏、命令输出、日志片段和测试记录表。单看一张后台首页截图，不能证明客户端能登录、消息能收发、文件能落盘。

断网测试要覆盖完整链路

断网测试要分两层做：先断开服务器到互联网的出站访问，再在客户端侧断开外网。只在服务器上断网，可能漏掉客户端自动更新、移动端推送、在线字体、地图和外部 AI 服务等依赖。

能力	断网后要确认什么	常见漏点
登录与组织架构	账号密码、LDAP/AD、单点登录是否仍可用	LDAP 服务器在外网或另一张网
单聊、群聊、文件	消息、图片、文件、表情能否正常收发	文件预览调用外部服务
搜索与历史消息	关键词搜索、历史记录能否返回	搜索服务或索引依赖外部组件
音视频会议	建会、入会、屏幕共享是否正常	信令、媒体或穿透服务在外网
移动端	登录、消息、推送、扫码是否正常	推送通道必须经过公网
客户端升级	内网能否获取升级包并完成升级	客户端默认访问官网更新地址
AI 与外围服务	AI 对话、地图、短信、邮件能否使用或关闭	主服务在内网，功能请求仍出网

任何一项必须出网，都要在验收报告里写成例外能力，注明用途、数据流向、审批人、替代方案和关闭策略。不能因为核心聊天能用，就把推送、升级、AI 等外围能力的出网依赖略过。

网络边界与客户端访问

客户端访问要从办公网、专网、VPN 和移动网络分别测试，至少覆盖实际用户会用的网络路径。反向代理或负载均衡场景要检查长连接、WebSocket、上传大小、超时时间和证书链，避免出现后台能打开、客户端频繁掉线的情况。

端口扫描和连接跟踪可以辅助确认有没有多余出站连接。验收通过的表现是：在约定网络边界内，客户端能稳定登录并完成核心业务；断开外网后，除已批准的例外能力外，聊天、文件、搜索等核心功能仍然可用。

功能验收：按真实协作链路走，不按功能表打勾

功能表只能说明有，不能说明好用、稳定、权限正确。验收用例要从员工一天的实际动作出发：登录、找人、发消息、传文件、开会、查记录、换设备。这样测出来的问题，才接近上线后的真实问题。

先测消息不丢、不乱、不漏

消息是即时通讯的基本盘，要覆盖单聊、群聊、@、回复、转发、撤回、离线消息、多端已读、消息顺序、重复消息和搜索。重点看边界：弱网、断网重连、长时间离线、超大群、频繁切换设备。

通过标准不是消息发出去了，而是消息不丢失、不重复、顺序可解释；发送失败有明确提示；重连后能补齐；多端已读状态一致。出现重复或乱序时，要记录发生条件、客户端版本、网络状态和服务端日志，不能只用一句偶发带过。

再测文件、会议和文档协同

文件要测单文件、文件夹、大文件、特殊文件名、中文路径、上传中断和下载失败。会议要测发起、加入、屏幕共享、麦克风、摄像头、弱网和多人同时发言。移动端要测后台切换、锁屏通知、离线消息和多端同步。

如果采购了在线文档协同，要单独验文档服务组件、字体、模板、并发编辑和版本保存，不能把能预览当成能协同编辑。文档协同往往依赖单独部署的组件，组件本身是否在目标环境验证过，要单独记录。

组织、权限和集成要一起测

组织架构要测新增、离职、调岗、批量导入和跨组织可见性。权限要测普通用户不能进入管理后台、部门管理员只能看授权范围、IP 登录限制只放行约定网段、组织隔离后不同组织看不到彼此通讯录。LDAP 或单点登录要测认证失败、账号不存在、密码修改后的同步。

接口和集成要拿真实业务系统联调，覆盖 OA、ERP 等系统的消息推送、回调、鉴权和失败重试。接口文档只能说明设计，联调才能证明消息送达、回执正确、异常可追踪。验收记录里要保留请求、响应、重试和告警样例，方便后续排查。

用例怎么写才可复测

字段	写法
编号	每个用例唯一编号，便于缺陷关联
场景	一句话说明要验证的业务动作
前置条件	账号、组织、网络、版本、测试数据
步骤	按实际操作顺序写，避免跳步
预期结果	写成可观察的现象，不写运行正常
实际结果	记录成功、失败、异常提示和日志
证据	截图、录屏、日志、接口返回
结论	通过、不通过、待复测

一个用例只验一个主要判断，预期结果要能由第三方复现。这样即使换人复测，也能得到相同结论。

安全验收：把加密拆成可检查的层

安全验收最容易停在厂商说有加密。加密不是一个开关，要分别看身份、传输、存储、权限、审计和漏洞处理。只看一张功能清单，无法判断数据在哪个环节被保护、由谁管理密钥、出问题后能不能追溯。

身份与权限

账号生命周期要测开通、停用、离职、调岗和密码重置。管理员要分角色，系统管理员、组织管理员、审计员不能共用同一个账号。普通账号尝试进入管理后台、修改他人资料、查看未授权组织通讯录，都应该被拒绝。

如果交付清单包含多因素认证、IP 登录限制、LDAP 或单点登录，要逐项验证失败场景和绕过场景。比如伪造来源 IP、使用离职账号、跨组织账号访问，都应该有明确拒绝和日志记录。

传输、存储与密钥

传输要确认客户端到服务端、客户端到文件服务、管理后台到服务端都走加密通道，证书有效、域名匹配、没有明文端口暴露。存储要分别看服务端文件、数据库消息和备份文件，确认数据目录权限、数据库账号权限和备份访问控制。

喧喧IM官网的 通讯安全能力列出了通信全加密、服务端文件加密存储、数据库消息加密存储、组织隔离、界面水印、IP 登录限制和 LDAP 认证，版本页把其中部分能力放在专业版。验收时要对着交付版本逐项核对，不能把官网页面当成已经交付。

密钥管理要问清楚：密钥由谁持有，是否支持轮换，备份是否加密，管理员离职如何交接。产品没有独立密钥管理界面时，至少确认数据目录、数据库和备份文件的访问控制，避免出现有加密但管理员能直接读取明文的情况。

审计、漏洞与合规边界

审计日志至少覆盖登录、失败登录、权限变更、管理员操作、文件上传下载和异常访问。日志要能按时间、账号、操作类型查询，留存期限和访问权限要明确。消息审计和聊天记录导出不是一回事，如果项目要求导出，必须在合同和交付清单里单独确认，不能默认。

漏洞处理要看扫描报告、渗透测试报告、依赖组件版本和补丁责任。操作系统、数据库、中间件的补丁由谁负责，应用本身的补丁由谁提供，响应时限是多少，都要写进责任清单。客户端安装包还应校验签名或哈希，防止被替换。

合规边界要分清。GB/T 22239-2019 的适用对象是信息系统或等级保护对象，不是单个软件；软件验收不能替代等保测评，等保测评也不能替代功能、性能和信创验收。国密要求同样要单独核对算法、协议、证书、密钥和密码应用材料，信创适配不等于国密合规。

如果启用 AI 对话、在线升级、移动推送、地图、短信等外围能力，要逐项确认数据流向和是否出网。主服务部署在内网，不代表所有功能都不出网；验收报告里要把这些能力列为单独检查项。

安全验收的输出

安全验收至少留下账号权限矩阵、加密配置截图、端口与证书检查记录、漏洞扫描报告、审计日志样例和未关闭风险清单。高危问题不应带病上线；暂时不能修复的，要有补偿措施、责任人和期限，并经过审批。

信创验收：别只看客户端能不能装上

信创适配不是一张证书，也不是客户端能启动。例如喧喧IM的 信创适配说明可以作为核对起点，但它最终要回答的是：在目标 CPU、操作系统、数据库、中间件、浏览器、终端和外设组合下，完整业务能不能跑，性能能不能接受，升级维护有没有路径。

先列目标环境矩阵

层级	要核对什么	证据
服务端 CPU	型号、架构、核数、内存	厂商适配清单、目标机测试记录
服务端操作系统	发行版、版本、内核	安装日志、启动日志
数据库	类型、版本、驱动、字符集	连接测试、备份恢复记录
中间件与运行时	版本、依赖库、启动参数	启动日志、兼容性说明
客户端	CPU、操作系统、安装包、字体、输入法	真机安装和业务操作录屏
浏览器与移动端	版本、登录、文件、通知	实际终端测试记录
外设	打印机、扫描仪、摄像头、麦克风、USB Key	逐项连接和使用记录
安全软件	杀毒、终端管控、桌面管理	共存测试和冲突记录

矩阵要写到具体版本和型号，不能只写麒麟、统信兼容。同一个操作系统不同版本、同一类 CPU 不同架构，适配结果都可能不同。

适配证书要对着版本和型号核

麒麟软件的适配认证分为整机、部件、软件、外设四类，流程包括提交申请、适配测试、复测审核和证书发放，详见 麒麟软件生态适配认证说明。这说明认证有明确的对象和范围。拿到证书或适配清单时，要核对产品名称、版本、CPU 架构、操作系统版本、认证类型和有效期。

证书不能自动覆盖你单位的新版本、新机型或新组合。证书用来缩小范围，实测用来证明可用。销售发来的截图、第三方转载的兼容列表，都不如厂商官网可查询的条目和正式测试报告可靠。

在目标环境跑完整业务链路

信创环境要跑完整链路：安装、登录、组织同步、单聊群聊、文件上传下载、文件预览、搜索、音视频、屏幕共享、消息通知、客户端升级、卸载和重启。重点测在 x86 环境不容易暴露的问题，包括字体缺失、输入法、文件预览、打印、摄像头、麦克风、USB 外设、中文路径和特殊字符。

性能也要在信创环境重跑，不能拿 x86 的压测报告代替。依赖组件同样要在目标环境验证，例如在线文档协同如果依赖单独的文档服务，不能只验客户端。信创适配不等于安全合规，也不等于性能达标，这三件事要分开写结论。

没有目标环境时怎么做

可以借用或租用目标终端，使用厂商的适配实验室，或者先看测试报告、到货后再复测。只做部分验证时，验收结论写成有条件通过，列明未覆盖的型号和版本、可能的风险、补测时间和责任人。

性能与稳定性验收：用业务峰值和可复现脚本说话

性能验收最容易变成厂商演示：少量账号、短时间、小文件，结论是很流畅。这种结果不能支撑上线决策。验收要基于业务峰值，使用可复现的脚本和数据，记录原始指标。

先定义负载模型

负载模型至少写清在线用户数、并发发送用户数、群规模、每分钟消息量、文件大小和上传频率、音视频参会人数、接口调用量、峰值持续时间。数据从业务日志、历史峰值和上线计划里取，找不到就做保守假设并写明。

关键场景和指标

场景	观察指标	通过条件
登录风暴	登录成功率、登录耗时、CPU、内存、数据库连接数	达到约定成功率，错误有明确提示
峰值消息	发送成功率、P95/P99 时延、消息积压、服务端资源	达到约定阈值，无明显积压
大群和大文件	发送时延、上传下载耗时、磁盘 I/O、失败率	在约定文件大小和群规模下可用
搜索与历史消息	查询耗时、数据库负载、索引大小	达到约定响应时间，结果完整
音视频会议	入会成功率、音视频质量、带宽、丢包	在约定人数和网络条件下可用
长稳运行	内存增长、磁盘增长、错误率、日志轮转	观察期内无持续恶化

阈值要写进验收方案，不要拿别家项目的数字当自己的标准。压测数据要覆盖正常值、峰值和略高于峰值的场景，观察系统是先变慢、先报错，还是直接不可用。

故障与恢复要单独测

单机部署要重点验进程重启、服务依赖故障、网络抖动、断网重连、磁盘写满、数据库连接耗尽和告警通知。合同里没有多节点或故障转移，就不要按节点自动切换的承诺验收；合同里有，则单独设计切换和回切用例。

备份恢复要恢复到干净环境，确认消息、文件、权限和配置都能回来。只看到备份文件生成不算通过，必须实际恢复一次并记录耗时。恢复时间目标和恢复点目标的实测值，要和约定值逐项对比。

压测报告要看什么

一份可用的压测报告至少包含环境、版本、拓扑、负载模型、测试脚本、数据量、原始指标、瓶颈分析、调优动作和复测结果。没有原始数据和脚本的报告，只能当参考。厂商演示环境的流畅体验，不能替代你单位目标环境的压测结论。

交付与整改：验收报告怎么写才算闭环

验收不是开一次会。它要有交付物、有缺陷分级、有整改复测、有明确的通过或不通过结论。报告写不清楚，后续扩容、升级、故障定责都会变成新的争议。

交付物清单

交付物至少包括安装包、授权文件、部署文档、管理员手册、用户手册、接口文档、端口清单、账号与权限矩阵、备份恢复手册、升级回滚手册、测试报告、适配清单、安全扫描报告、培训记录和支持联系方式。

开源版和专业版的支持范围不同，交付物清单要对应实际版本。文档不是越多越好，但缺了备份恢复、升级回滚和故障处理，运维就会在关键时刻失去依据。

缺陷分级和通过条件

级别	典型问题	处理要求
P0	数据丢失、无法登录、核心业务不可用、严重安全漏洞	验收前必须修复并复测
P1	主要功能不可用、无替代方案、性能严重不达标	修复或经审批的替代方案，限期复测
P2	局部功能异常、性能偏差、有临时绕行方案	明确责任人和整改期限，上线后复测
P3	易用性、文档、提示语等一般问题	可带条件通过，列入后续计划

通过条件建议写成：无 P0 和 P1；P2 有责任人和期限；所有用例有结论和证据；例外能力经过审批。不能修复的问题，要进入风险清单，不能口头承诺以后再说。

验收结论与上线后复盘

验收结论分为通过、有条件通过和不通过。有条件通过要写清未覆盖的范围、遗留风险、临时措施、补测时间和审批人。报告里要附版本号、部署拓扑、测试环境、用例统计、缺陷清单和证据索引。

上线后安排一段稳定观察期，例如 30 天，复盘登录成功率、消息失败率、性能峰值、故障次数和用户反馈。升级前做回归测试，尤其是信创终端、客户端版本和接口集成。验收报告不是给审计看的摆设，它是后续扩容、升级和故障定责的依据。

FAQ

私有部署 IM 验收一般要多久？

没有固定天数。环境准备、功能、安全、信创、性能和整改复测是不同阶段，范围越大、目标环境越多，周期越长。先把用例、准入条件和责任人定好，再排期。

纯内网部署，移动端推送和音视频还能用吗？

要在断网条件下实测。推送、音视频信令和媒体、客户端更新、AI 服务都可能涉及外部依赖。如果必须出网，写成例外能力，明确数据流向、审批人和替代方案，不能默认可用。

厂商有信创适配证书，还要实测吗？

要。证书有产品版本、CPU 架构、操作系统版本和认证类型的范围，你单位的目标环境不一定在覆盖范围内。证书用来缩小范围，实测用来证明可用。

等保测评能代替软件验收吗？

不能。等保对象是信息系统或等级保护对象，关注整体安全保护能力；软件验收关注版本、功能、性能、信创和交付。两者互补，不能互相替代。

开源版需要做同样的验收吗？

需要，但范围不同。开源版核心功能开放，专业版包含更多企业级能力。按实际交付版本裁剪用例，重点确认支持范围、升级路径和责任边界。

验收不合格怎么办？

按缺陷分级处理。P0 和 P1 先修复；P2 给临时方案和期限；复测通过再签收。不能修复的，走有条件通过或合同变更，写清风险和责任人。

参考依据

• GB/T 25000.51-2016《系统与软件工程 系统与软件质量要求和评价（SQuaRE）第51部分：就绪可用软件产品（RUSP）的质量要求和测试细则》。
• GB/T 22239-2019《信息安全技术 网络安全等级保护基本要求》，2019-05-10 发布，2019-12-01 实施。
• 麒麟软件生态适配认证类型与流程，http://www.kylinos.cn/eco/ecoPartner/partnerApply/index.html，2026-11-05 核验。
• 喧喧IM官网私有化部署、信创适配、通讯安全、版本与安装文档，2026-11-05 核验。