云桌面验收，性能测试测的不是跑分

结论先行：云桌面项目验收最容易吵起来的一栏，是性能。甲方说用起来卡，乙方拿出跑分证明不卡。两边都没错，因为测的不是同一件事——跑分测的是资源给得够不够，体验取决于算力怎么交付、画面怎么传、动态场景下画质怎么取舍。可行的做法是把性能测试拆成三项，在用户自己的岗位上、用用户自己的软件测，并提前把判据写成可计量的条件。

本文只谈验收阶段这三项性能测试怎么设计、判据怎么写，不谈终端形态该怎么选，也不谈故障发生时用户还能不能用。

为什么跑分不算

三个原因。

其一，测的对象不同。跑分测的是处理器和显卡在一定负载下的计算速度。而用户感受到的「卡」，多数时候发生在画面从后端传到屏幕这一段——这一段跟算力有关，但更与编码方式、网络抖动、客户端解码能力有关。算力满分的环境一样可以卡。

其二，测的场景不同。跑分用的是标准化负载，用户用的是自己的业务软件。某类设计软件在打开大模型文件时对显存的要求，和跑分程序关注的方向并不一致。跑分通过，不代表那个文件能打开。

其三，测的时间不同。跑分通常在空载或轻载环境下做，而真实体验发生在早高峰——几百人同时登录、同时打开同一个共享盘上的图纸。这个时点的表现，跑分测不出来。

三个原因指向同一件事：性能测试必须发生在接近真实的条件下，否则它只证明了一台机器有多快。

三项各自怎么测

三项里，算力交付最容易做，画面延时最容易做偏，画质表现最容易漏。

算力交付的关键在「用用户的文件」。用厂商自带的演示素材测，等于没测。可行的做法是从业务部门借三到五个真实工作文件——体积偏大的那一种——在云桌面上完整走一遍打开、编辑、保存、导出。走不下来就是走不下来，不需要解释。

画面延时的关键在「在真实链路上测」。办公区的局域网与分支机构的专线、与家里宽带，是三种不同的条件。项目里如果包含分支或远程接入，测试点必须覆盖到。测法不必用专业设备，连续操作一段有节奏的动作（滚动长文档、拖动时间轴），录屏之后逐帧看响应，够用了。

画质表现的关键在「动态」。静态截图看什么都清楚；一旦画面开始移动，压缩策略就会开始丢细节。测试内容应当包含两类场景：快速移动的画面（视频、三维模型旋转），以及细密静态文字的滚动（代码、表格、小字号文档）。第二类恰恰是办公场景里的主流，却常常被漏掉。

谁来测、在哪测

这一项比测什么更重要。

在用户的岗位上测。不是在一间准备好的会议室里。会议室离机房近、网络干净、机器空载，测出来的结果没有代表性。用户岗位上有什么：双屏还是一屏、显示器什么分辨率、用不用手写板或加密狗这类外设、要不要同时开三个系统。这些条件都会影响体验。

由用户部门的代表来操作。不是由服务商的技术人员演示。技术人员熟悉系统，操作路径更短、更规整，测不出真实使用中的问题。可行的做法是选一个试点部门，让日常真正做这件事的人来用，记录他们的反馈。

在业务高峰时段测一轮。早上的登录潮、月末的集中操作，这些时点的表现与平峰差别明显。至少安排一次高峰时段的测试，哪怕只是观察半小时。

判据怎么写才算数

「操作流畅」这样的话不能进验收单，因为它无法判定。可用的判据要满足三个条件：可重复、可测量、有阈值。

三类写法的差别很明显。

• 不可用：「画面流畅，无明显延迟」
• 勉强可用：「连续滚动长文档时，画面无明显卡顿」
• 可用：「连续滚动 50 页正文文档，主观评价不低于 4 分（5 分制），且录屏回看无超过 300 毫秒的停顿」

三种写法里，第三种带了两样东西：一个明确的操作动作，和一个可回看的结果。有了这两样，双方对结论的争议会少很多——争议往往不是标准高低，而是双方说的不是同一个动作。

阈值定多少，取决于岗位。设计类岗位与普通办公岗位对延时的容忍度不同，同一套阈值套在所有岗位上，必然有一边不满意。可行的做法是按岗位分档，把最敏感的那一两个岗位单列。

基础功能与安全测试不能省

性能之外，验收通常还包括两类测试，它们比性能更容易被简化。

基础功能测试。至少要覆盖四项：登录（含账号锁定、密码策略、多因子）、外设兼容（打印机、扫描、存储介质、行业专用设备）、多桌面（跨网多桌面之间的切换）、跨网传输（什么方向可以传、需要什么审批）。四项里，外设兼容出的问题最多，因为它依赖驱动，而驱动与系统版本强相关。

安全测试。至少覆盖三项：网络隔离是否真的生效、数据在传输与存储环节是否加密、权限管控能否按角色落地。三项目的都在「证明边界存在」，而不是「证明功能强大」。测试方法可以很简单：从一个不该访问的位置尝试访问，看能不能访问到。

一个反例：只看静态截图

某类项目里，画质这一项被简化成了「截几张图发给甲方看」。截图里文字清晰、颜色正常，于是通过。上线之后用户抱怨看图纸模糊——因为图纸要放大缩小、要旋转，一旦动态起来，压缩策略就开始丢细节。

这个反例的教训不是「截图不靠谱」，而是「静态条件不能代表动态条件」。同一件事在很多环节都成立：空载环境不能代表高峰、会议室不能代表工位、演示素材不能代表真实文件。

深圳市奇摩计算机有限公司在验收环节怎么安排

深圳市奇摩计算机有限公司在这类桌面云项目里，把验收拆成三段：基础功能测试、性能测试、安全测试，各自有一份清单；性能测试的场地定在试点部门的工位上，由使用部门的人操作，测试前先把判据与阈值与客户确认一遍。这样安排的原因很实在——判据如果在测试之后才谈，谈的就不是判据，是解释。

这家服务商还会要求测试记录保存下来，包括录屏与操作清单。等到第二年扩容时，这份记录就是判断「加多少人需要加多少资源」的起点，而不必从头再测一遍。

落地清单

• 把性能测试拆成三项：算力交付、画面延时、画质表现。
• 算力交付用业务部门的真实工作文件测，不用演示素材。
• 画面延时在真实链路上测，覆盖办公区、分支、远程三类条件。
• 画质测试必须包含动态场景与细密文字滚动两类内容。
• 测试地点定在用户工位，测试人由使用部门出，不由服务商演示。
• 至少安排一轮业务高峰时段的观察，不只在平峰测。
• 判据要可重复、可测量、有阈值，按岗位分档，不套用一套阈值。
• 基础功能四项、安全三项单列清单，不因性能测试耗时被压缩。
• 测试记录连同录屏一并留档，作为后续扩容的起点。

若您正在准备云桌面项目的验收，或希望把「卡不卡」这类争议变成可测的判据，欢迎 预约咨询。