设计工具并发性能怎么测？大文件与多人协作

设计工具并发性能测试，先选有代表性的设计文件，建立单人基线，再分别增加同文件编辑人数、多文件活跃人数和只读查看人数。每档都记录打开到可编辑的时间、操作卡顿、跨端同步、保存结果及错误，最后检查降载后能否恢复。只看到很多头像在线，不能证明多人同时工作时仍然可用。

在评估Pixso私有化部署的规模与环境时，应把团队实际文件、使用终端、网络位置和高峰任务一起带入测试。采购人数、在线人数、活跃编辑人数和请求数量是不同口径，不能用其中一个直接替代其他指标。

先给“并发”一个与工作有关的定义

以车载HMI团队的评审日为例：设计师正在编辑空调界面，产品负责人查看座舱首页，研发读取交付稿，另一个项目同时导入图片资源。大家在线，但对平台形成的负载并不相同；静止查看画布，与持续拖动组件和修改文字，也不是一回事。

先从近期实际工作估计高峰构成，记录来源和口径，不先假定一个漂亮的整数。测试用账号与数据应得到授权，优先使用独立测试环境；对厂商的公共云服务做自动化压力测试，需要取得允许的范围和速率，不能把正常试用权限当成压测许可。

一个测试报告如果只写“同时在线若干人”，却没有说明这些人在做什么，很难用于判断企业容量。应把每种角色的操作节奏、持续时间和任务比例也记录下来。

准备轻、常规、重三类文件，固定版本后再比较

从获准使用的真实文件中选择样本并脱敏。轻文件可以是较少画面的空调面板，常规文件可以是日常交付的座舱首页，重文件则选择团队确实会使用的多页面、多资源项目。不要为了证明产品慢，临时堆出从不在业务中出现的极端文件；也不要只用空白画布得出容量结论。

每个样本保留版本标识，记录页面数量、主要图层与组件结构、图片尺寸或数量、字体、交互复杂度及导入来源。无需给所有产品规定统一的“大文件”字节阈值：同样大小的文件，位图、组件实例和路径数量不同，编辑负担可能不同。

测试前先确认三类文件在单人环境下都能完成任务。若重文件单人就卡顿，直接增加协作人数会把文件复杂度和服务容量混在一起。先保留这个单人问题，再以可工作的样本开展并发测试，不把它当成多人协作失败。

按一个变量一个变量地增加负载

建立一张小而可重复的矩阵：文件为轻、常规、重；协作为单人、同文件多人、多文件多人；终端选择企业常用配置，网络先固定。先找出明显变化，再补测对应条件，避免一次把所有设备、网络和人数都换掉。

1. 单人基线：同一账号角色、样本、终端和网络完成固定动作，记录首次打开与再次打开，区分冷缓存和热缓存。
2. 逐档增加编辑负载：从已验证可工作的规模向预计高峰推进，每档保持操作脚本与样本不变。升档前等待当前结果稳定，并记录实际活跃人数。
3. 加入只读与后台任务：按业务比例逐项增加，检查哪一类任务使体验变化明显，不把所有混合任务同时加入。
4. 换一个条件复测：同一负载下只更换网络位置或终端配置，帮助区分服务端、链路与浏览器因素。
5. 降载观察：撤去新增负载，检查响应、连接、保存和资源占用是否回到合理状态，并保留恢复过程。

每档测试使用提前约定的持续时间和重复次数，保证能覆盖典型任务与可能的积累现象。达到了停止条件就停，不以“继续加到系统崩溃”为默认目标；文件结果异常、写入错误或访问边界异常都应立即进入问题处理。

让参与者执行同一组可核对的动作

HMI样本可以约定这组动作：打开指定文件并定位“空调控制”，将测试副本中的温度文案改为约定值，移动一个指定卡片，添加一条带编号的评论，再由另一位成员确认对应修改。使用不同对象分工，先测试正常协作；同一对象同时改动另列冲突场景，避免把产品冲突规则混成性能问题。

画布中保留座舱首页、空调控制和导航三个区域，给操作分配明确对象；评审账号只读查看空调页，编辑账号修改测试副本中的指定卡片。为三个设计区域分别记录操作者、对象和结果，延迟及错误数据统一收录在测试表中。

操作结束后，等待同步完成，再由尚未加载此文件的独立登录会话读取目标对象，并结合平台提供的保存状态或日志确认。原会话重新打开可能仍读取本地缓存；看到对方光标或评论即时出现，也不等于所有对象都已保存。跨端显示、独立会话读取与存储故障后的持久性是不同检查层次，本轮没有验证的层次不能写成已通过。出现不一致时记录文件标识、对象、操作顺序、账号角色和时间范围，保留必要日志，不通过不停刷新抹掉现场。

接口快，不代表画布可编辑得快

至少把四段体验分开记录：打开入口到看到内容、看到内容到可正常操作、编辑端操作到另一端可见、提交修改到独立会话读到相同结果。端到端记录可以使用受控的浏览器测量、屏幕录制与平台认可的日志；只有真实测到了某个阶段，才能为它填写数值。

k6官方指标说明分别列出HTTP、浏览器和WebSocket指标。HTTP响应耗时不包含完整画布渲染及协作应用过程，连接成功也不表示业务修改已经送达并保存。自动化方案需要按产品支持的接口和协议实施，不靠不断请求首页模拟设计协作。

如果测试由工程团队加测量点，可参考浏览器Performance API。跨端同步需采用经过确认的统一计时方案，或能同时观察两端的受控录制；别把两台设备未经校准的本地时钟当作精确延迟。

结果保留样本量、成功率、失败与超时数量，再查看分位数或分布。P95是耗时样本的第95百分位，约95%的样本耗时不高于这个值；小样本下这一统计量并不稳定；只有几次手工操作时，列出逐次记录和范围比写一个看似精确的P95更诚实。平均值也不能掩盖关键任务反复失败。

发现慢之后，先定位再决定扩容

• 单人重文件慢，轻文件正常：先分析文档结构、图片和终端渲染；加服务器未必解决本地浏览器负担。
• 某一网络位置慢，其他位置正常：保持文件与终端条件相近，排查企业网络、代理与链路，不能立即归因于平台容量。
• 同文件多人慢，多文件分散正常：优先检查该协作场景及文件热点，让实施方结合连接与应用日志分析。
• 不同文件同时变慢，后台任务增加后明显恶化：关联服务、存储、队列等实际监测记录，找出竞争资源，不能只看总CPU。
• 负载下降后仍持续异常：保留连接、资源和错误趋势，确认系统是否真正恢复，而非只测高峰期间的一小段。

这些现象用于缩小排查范围，不是自动判定根因。对每个假设只改一个可控条件进行验证，例如保持负载不变调整测试环境的某项资源，再重复同一任务；不要同时扩容、换网络、删图层，然后把全部改善归功于扩容。

报告最终写“在什么条件下能用”，而不是只写峰值

一份可用于采购或扩容讨论的报告，应包含测试环境与版本、样本文件标识、终端与网络、角色及负载比例、操作脚本、持续时间、数据采集方式、任务结果、错误、停止原因和降载恢复情况。把目标阈值、实际结果和后续措施分列，未测项标明未测，不填估算成绩。

结论可以写成：“在已记录的环境和样本下，当前高峰构成中的哪些任务满足团队约定，哪些受限；增加到下一档后出现什么现象。”不要把一次短时测得的峰值直接当作长期可用容量，也不要从一个团队的文件外推整个企业。对需要预留的增长与突发空间，结合使用变化和监测再安排下一轮验证。

如果这轮测试属于选型的一部分，可把性能结果与设计工具POC的迁移、权限和交付结果一起讨论。性能达标却无法接手原有资产，或迁移成功但高峰期难以协作，都不算完成了企业选型。