验收 OA 集成的在线文档能力，不能把“在 OA 里能打开文件”当作通过标准。要验四层：文件与格式能否还原、权限是否按规则拦截、事件失败时可否判定与补偿、目标并发下延迟与失败率是否达标。每层写成“谁操作、看什么现象、留什么证据”，否则上线后的问题都会变成扯皮。
下面按“先定断言，再定用例，最后定签核”给出清单。文中能力描述以石墨办公文档中台私有部署（Shimo Office SDK，以下简称文档中台）的公开说明为限，接口字段与限制以部署版本的开发文档为准。
一、先定验收对象：四层断言，不是一张功能截图
四层各回答一个能用“通过/不通过”判定的问题，而不是拿一张“能打开”的截图交差。
| 验收层 | 只回答一个问题 | 通过证据 | 不通过先找谁 |
|---|---|---|---|
| 能力层 | 真实文件打开、编辑、导出再导入后是否还原 | 源文件、导出件、比对记录 | 实施方复现，接入方查特例 |
| 权限层 | 业务判定的可看可改可下载，在文档侧是否一致 | 四组账号操作记录与审计日志 | 先查身份映射，再查权限谁裁决 |
| 集成层 | 事件重复、乱序、丢失时可否判定与补偿 | 回调日志、重试记录、待处理队列 | 按发出、消费、补偿定位 |
| 容量层 | 目标峰值并发下打开耗时与保存失败率是否达标 | 压测脚本、监控曲线、口径说明 | 先核对口径，再看资源与配置 |
集成层与容量层最容易被跳过：前者正常网络下看不出问题，后者要专门造负载。能力边界对照文档中台私有部署产品页，多出入口职责见多系统接入方案。
二、能力层：PoC 用哪几类文件，每类看什么
原则两条：文件来自真实业务，不用供应商样例；每类文件对应一个可观察差异点，而不是笼统看“能否打开”。
- 公文与合同版式件：分页、页眉页脚、印章是否位移，用同一台打印机出 PDF 对比。
- 复杂表格：合并单元格、跨页表头、冻结行列、条件格式，导出再导入逐项核对。
- 含修订与批注的文件：修订痕迹、批注作者与时间是否保留，能否接受修订。
- 大文件与长文档：记录大小与页数，看打开耗时与保存是否超时。
- 扫描件 PDF 与 OFD：扫描件只当版式还原样本，不假设存在文字层；确需文字提取与检索，另立需求并与方案团队确认。OFD 抽检签章与版式。
每类留源文件、导出件、比对记录。判定标准要写成可抽查的句子，如“抽 3 页，页眉与表格线无位移”。文档中台提供高保真格式转换与还原、支持 OFD，还原程度仍用自己的文件验。
三、权限层：正向用例只证明了一半
只测“有权限的人能打开”等于没测。至少跑 4 组账号 × 4 个动作，负向用例权重高于正向。
| 账号类型 | 打开 | 编辑 | 下载/导出 | 分享 |
|---|---|---|---|---|
| 有编辑权 | 放行 | 放行，版本递增 | 按策略允许 | 按策略允许 |
| 只读 | 放行 | 拦截并说明原因 | 按策略，允许则记审计 | 拦截 |
| 无业务权限 | 拦截 | 拦截 | 拦截 | 拦截 |
| 已离职或已撤权 | 拦截 | 拦截 | 拦截 | 拦截 |
矩阵里两行最容易被简化：无业务权限的账号，要同时验“拦截”和“拦截有没有说明”；已离职账号，要验身份停用后矩阵是否仍然成立。撤权从发起到生效的时间差、编辑中被撤权的保存表现、审计日志能否按单据追溯，属于离职与撤权专项，另有专文展开；这里只要求把生效时间点记进证据。
文档中台托管既有权限体系并开放权限、版本、评论接口，但“谁能看哪份文件”仍由接入方决定，验的是两边判定是否一致。
四、集成层：用故障注入代替“应该没问题”
回调验收不能只看“收到一条通知”，要看四类异常。做法是接入方在测试环境主动注入故障。
- 幂等：同一事件投两次，业务系统只产生一次动作。
- 重试：失败后按约定重试，次数与间隔写进方案。
- 乱序：“关闭”先于“打开”到达时以谁为准，事先约定并写用例。
- 补偿：超限失败的事件进入待处理队列，有责任人和巡检频率。
同时把职责写进验收表：谁提供身份、谁决定权限、谁持有文件与版本、谁处理失败重试。文档中台把文档能力嵌入业务系统，不替代业务入口；接入方仍需设计身份、权限、事件通知与异常处理，空着的那格上线后就是没人认领的工单。接入方式上，前端 JSSDK 与 JSAPI 嵌页面，后端服务端 API 处理文件与转换，流程联动靠事件回调；三条路各有验收项，只验前端等于只验三分之一。
五、容量与签核：先对口径，再定判定线
并发是同时使用数，企业总用户数对应的是席位数，两者不能互相替代：用员工总数估并发，通常会高估，别直接拿它当并发。峰值并发从三处取数：单据发生量、登录与操作日志的时段分布、同类系统上线后的真实曲线。
压测跑三档：日常基线、预计峰值、1.5 倍峰值。每档只记三个数：打开成功请求的 p95 耗时、保存失败率、事件触发到业务系统落库的延迟。判定线按业务容忍度倒推，不套通用数值。官方并发计算器用于量级估算，最终以技术文档与 PoC 为准。计费按并发：商业版 30 并发起售、含 5 个应用接入，试用版 30 天、30 并发，见文档中台定价。
最后一层是判定：验收会开成“大家再看看”，多半是没提前定义严重级别。四档够用：阻断（数据丢失、越权、核心链路不可用）、严重（主功能可用但有绕行方案）、一般、建议。结论也分三档：通过＝无阻断无严重、负向权限全过；有条件通过＝无阻断、严重项有绕行方案并写明责任人与复验用例；不通过＝存在阻断或负向权限未解决，按同批用例重跑。
两条容易忽略的规则：首次失败后重试通过，不能记为通过，要标为不稳定单独跟踪；证据要能被第二个人重复执行，用例编号、操作、可观察结果、截图或日志、执行人与时间缺一项就算未验。演示截图与口头确认都不算证据。
常见问题
PoC 要测哪些文件？
至少五类：公文或合同版式件、复杂表格、含修订批注的文稿、大文件、扫描件 PDF；有 OFD 再补一类。扫描件只验版式还原，不假设能检索文字。每类留源文件、导出件、比对记录。
权限怎么验证？
做 4 组账号 × 4 个动作的正负矩阵，负向拦截权重更高，并要求每次拦截都有可读的说明；撤权从发起到生效的时间点要记进证据。
并发和延迟要不要压测？
要，但先定口径：并发是同时使用数，不是员工总数。再跑日常、峰值、1.5 倍三档，只记 p95 打开耗时、保存失败率、事件落库延迟。
如果你正在做 OA 与文档能力的集成，先把这份清单改成项目里的验收表：填上文件清单、账号清单、三档并发与判定线，再约联调。带着系统清单、典型文件和预估并发去预约演示，可把 PoC 范围与验收口径一次谈清。也可以先看私有化部署方案，了解部署形态与交付范围。